The enterprise as app server

A succinct explanation of why IBM lumps together business process, web services and grid computing comes in the shape of this great quote from WebSphere director of marketing Scott Hebner: "We're positioning the enterprise as being the next-generation app server."

What a marvelous image! It precisely expresses the ultimate end in mind when adopting a service-oriented architecture: a fully joined-up enterprise computing infrastructure that provides the foundation for automating all of its business processes. The quote comes in the midst of an interesting InfoWorld interview published Wednesday.

Another IBMer who's been making some succinct points this week is Bob Sutor, in a CNET column titled The five biggest myths about web services. I particularly enjoyed this comment dealing with Myth #2, that web services are too disruptive to adopt: "Actually, organizations are moving toward web services because IT operations can be so disruptive so much of the time today."
posted by Phil Wainewright 2:24 AM (GMT) | comments | link

The client is king

Periods of creativity and innovation are often also times of chaos and anarchy. Web services clients seem to be entering such a period. I was surprised to see O'Reilly author Simon St. Laurent describing this as unwelcome fragmentation in a recent email discussion just published to the site's Editors List. The idea that all web applications must be confined to the browser presentation environment seems to me to be a sure way to hold back the necessary evolution of the Web from a passive publishing environment into a platform for doing things.

I find it very exciting that developments like Macromedia Flash MX, the W3C's XForms and Microsoft's XDocs — which I mentioned last week — along with other more adventurous creations such as DreamFactory, are all opening up new ways of managing connected functionality. The driver for all this, as I've outlined in my ASPnews column this week, is user choice: "The only sensible place to leave control of the applications is at the periphery, where the users are. After all, it's the users who, at the end of the day, call the shots."

Users want choice, adaptability and control, and if the standard browser doesn't give them what they want, they'll work around it one way or the other. That may be a scary, unpredictable and inefficient way of doing things, but it's how human beings make progress. The end results will be worth it.
posted by Phil Wainewright 11:38 AM (GMT) | comments | link

Making the shift to services

Software vendors sell products, not services, and they'll have tremendous difficulty adjusting to the service delivery ethos of on-demand computing. That is why, as CNet recently described, it is Amazon and Google who have been pushing the envelope of web services. I concur with Timothy Appnel's observation: "... interesting to note that two service providers are driving real Web service adoption and not software vendors such as Microsoft and IBM. (Could this be an indication of a significant shift in the industry?)."

My experience from watching the faltering evolution of the application service providers industry these past several years is that software vendors massively underestimate the challenges of online service delivery in three significant respects (thanks to Doug Kaye for prompting me to think this through afresh in preparation for a discussion we had on the topic yesterday):

1. Service provisioning — It is immensely difficult for a product vendor to appreciate the complexity and costs of metering, billing, settlement, service level monitoring, compensation and ongoing customer support associated with service provision (even more so in a multi-tiered environment).


2. Continuous relationship — Software (and indeed information techology as a whole) has traditionally been delivered in batch mode as part of a strictly finite project, which has allowed vendors to get into the habit of simply walking away from unresolved implementation problems and performance shortfalls rather than dealing with them. A service provider can never walk away. Delivering a service means taking full responsibility for the reliable operation and ongoing fitness of the complete offering.


3. Componentization — A service-oriented architecture allows customers to assemble applications as composite bundles of functionality from the best providers. Web services standardization and a robust shared Internet infrastructure favors those vendors who unbundle applications into their component functionality.

Software vendors are all in the same boat here, because every one of them faces the same difficult adjustment from a packaged product mentality to an online service mentality. But the funny thing is that they're in a minority among the wider business community, most of whom already live or die by the quality of service they deliver to their regular customers (think banks, advertising agencies, retailers, etc, etc).

The competitive battleground is beginning to shift away from the product specifications of the underlying infrastructure, and is moving up to the end-to-end business processes that web services enable. If that trend is set to continue, then we can indeed envisage a future in which existing service provider businesses become the go-ahead companies that set the pace of innovation, while beleaguered software vendors struggle to understand how to keep up with them.
posted by Phil Wainewright 6:14 AM (GMT) | comments | link

The natives are RESTful

SOAP is not a prerequisite for web services, as eWeek reminded its readers yesterday in a report filed from last week's SD East conference. It seems the alternative merits of REST — which were amply discussed in these pages earlier this year — are still being fiercely debated.

The reappearance of the SOAP vs REST debate is a welcome reminder to all those who seek certainty in standards that life is never as simple as that. I think this is a good context in which to highlight the following words from the W3C's recently published Web Services Architecture reference document, which put the web services triumvirate of so-called foundation standards firmly in their place (well, two of them at least, since UDDI doesn't even merit a mention in this passage):

"Our definition of the term 'Web services' does not presuppose the use of SOAP as a packaging format or a processing model. Nor does it presuppose the use of WSDL as a service description language. There are, and will be in the future, plenty of Web services that use raw HTTP as a data transfer protocol and some mutually agreed-upon XML format as the message content. The Web Services *reference architecture* does, however, assume that the higher levels of the Web services protocol stack are built on the foundation of SOAP and WSDL.

"This 'blessing' of SOAP and WSDL is not logically necessary, since some other mechanism could be defined to gather XML message components into a single package ..."

Most developers will use SOAP simply because it's easier and all the toolkits support it. But there may be circumstances, as I noted in one of those earlier postings, when they will gain a better end result if they then go back and refactor SOAP out of the implementation in favor of REST. That's why it's useful to keep this debate alive, if only to remind developers that there is — and always will be — an alternative.
posted by Phil Wainewright 11:05 AM (GMT) | comments | link