So you want an SOA? Edge East preso

Yesterday I presented at Web Services Edge East on the topic of getting started with service orientation and an SOA.
It was standing room only, which says as much about the size of the room as the popularity of the topic But nonetheless it seemed like a good turnout, and I got a lot of questions and request afterward for a copy of the presentation. (Please send me an email if you’d like a copy, too.)
You can also find a link to the article I wrote for Web Logic Developer’s Journal on my Sys-Con author’s page. The presentation is pretty much based on the article.
And the material in both the article and the presentation was based on early drafts of the book I wrote with Greg Lomow, which my editor tells me is doing pretty well so far.
A lot of questions came up about how to get started designing services, about the capabilities of an ESB with respect to SOA infrastructure, and the relationship of business process management to services.
It really seems like there are a lot of definitions of SOA and ESB out there in the marketplace right now. But as I pointed out in the presentation, I think that the definitions will eventually have to settle down onto what’s established in the marketplace.
For example, Credit Suisse has an SOA in production with more than 700 services, processing about a billion transactions a year. Here’s David Chappell’s presentation on SOA that references Credit Suisse and a reference to the often cited Gartner study on the Credit Suisse SOA (sorry but unless you pay you only get the first paragraph).
Deutsche Post is another company building a large scale SOA. Their success to date is being watched carefully throughout the industry, and they are members (along with IONA and several others) of JSR 208, the Java Business Integration specification effort.
These real projects, meeting real business requirements every day, are the kinds of things that will make SOAs and ESBs real, and provide the foundations for the real definitions once the hype settles down.

WS-CAF Meeting in Newcastle

Last week Arjuna Technologies hosted a very productive WS-CAF meeting, co-sponsored by Codeworks, an economic development agency for the North East of England. Codeworks has launched a program with Arjuna specifically for promoting the adoption of Web Services in the North East area together with Arjuna.
WS-CAF members from Arjuna, Choreology, IONA, Oracle, and Sun Microsystems participated in a very productive meeting. We processed more than 100 issues on the WS-Context and WS-CoordinationFramework specifications, and laid out a schedule for progressing both specs toward new drafts.
The next face to face is planned for April 28-29 in New Orleans, held at the end of the next OASIS Symposium.
At the Gartner Application Integration and Web Services Summit last November in Florida, Gartner analysts Charles Abrams and Darryl Plummer called WS-CAF one of the three most important advanced Web services specifcations efforts underway at OASIS. Similarly, OASIS CEO Patrick Gannon highlighted WS-CAF in his presentation at this month’s Web Services on Wall Street event.
The WS-Context member of the WS-CAF family provides a standard definition for a shared context data structure, and defines a context management service. Context in Web services is important especially for composite applications that run potentially across multiple deployment environments and languages.
The WS-Coordination Framework spec defines a software agent with which Web services in a composite can register and thereby participate in one of many protocols. Protocol types include two phase commit, long running actions, business processes, atomic transactions, business activities, business transactions, publish/subscribe, and simple REST style.
When a Web service in a composite registers with a coordinator for a protocol, the Web service becomes a participant in a larger unit of work capable of sharing context and results.
Interdependent services can comprise new and larger applications, and when they do, infrastructure level functionality is required to assure common behavior across multiple implementation platforms. Simple interoperability is sufficient for many applications; but many others implicitly (or explicitly for that matter) require high availability, reliability, security, and transactional behaviors to get the job done right.