Archive for January, 2007

iWant?

I’ve been an Apple customer for the past few years (2 Computers, 2 iPods) so I took notice of the recent iPhone announcement. From the keynote footage and what I’ve read, it appears to be an innnovative, hi-spec device that moves the mobile phone industry forward. A lot of the discussion has been about the choice of an exclusivity deal with Cingular and a lack of third party applications for the phone. While I’d love an unlocked, totally extensible version of the iPhone, I’m not sure that’s where 90% of the customer base is. I also don’t happen to think that these limitations are what Apple wants. It has, for the moment ceded control of a product line to another company and that’s not a happy place to be. I’m guessing Apple have made concessions necessary to break into the market and if it can will shed them as soon as possible. I’d also be willing to place a small wager that many, many third party apps will become available but will include a very, very small number of VOIP solutions.

I think what is most interesting is what wasn’t said. I think it’s clear that we’ll see wider use of the multi-touch technology. Done right (I’m not sure what that’ll look like) it’ll change the computing industry too. It points to some form of larger, more ‘traditional’ Mac tablet, and quite possibly an entirely new user interface to go with it.

What’s even more important is the multiple mentions of ‘the Cloud’ and Apple’s clear lack of interest in dominating it (or perhaps even being a small part). A free .Mac subscription and new push IMAP from .Mac could have been bundled in for iPhone but instead they partnered with Yahoo! What the exact strategy they are following is unclear. As a ’server guy’ it makes perfect sense to me to have exchangeable services accessed from a common client but that requires open, documented standards and that’s not been Apple’s MO in recent years. There’s no .Mac API for others to use, no open development of new, shared APIs which makes me think they’ll be locked in with a couple of big partners… risky?

But back to the iPhone. Despite the limitations, do iWant one? Yes.

The [action] cannot be processed at the receiver

If you are writing a web service and come across the following message in a SOAP Fault or a stack trace then don’t go digging around trying to find the code that caused the fault, take heed of the following information:

“The [action] cannot be processed at the receiver” is the [reason] string for a WS-Addressing specification defined fault which a compliant WS-Addressing implementation may throw if the value of the wsa:Action header is not recognised. The most likely problem is therefore that the web services client put the ‘wrong’ value in the wsa:Action header.

Suggested course of action: Check the documentation of your web services server to determine what action value it is expecting for a given operation and set that explicitly in your web service client.

Next Page »


About

I’m David Illsley, I work in Web Services development at IBM Hursley, which involves work on the Apache WS Project, where I am a committer and PMC member. When not working with technology, I spend a lot of time on the backstage aspects of theatre, and a sadly decreasing amount of time reading.

a

Disclaimer

The postings on this site solely reflect the personal views of the author and do not necessarily represent the views, positions, strategies or opinions of IBM or IBM management.