Vasters on SOA

{

A small time ago I admitted that SOA is still a bit elusive to me as this ubiquitous need we were all unaware of having. Multiple marketing machines are in full swing with it, however, and it's hard to separate useful and useless facts, much less fact and fiction.

I found a lengthy article on java.sun.com which should prove to be more technical (and therefore more useful) but meanwhile I'm also beginning to find some other questions similar to my own.

Clemens Vasters writes in his blog:

" When you look at what’s being advertised as “serviced oriented architecture”, you see either the marketing-glorified repackaging of Ethernet, TCP/IP, and LDAP (“Enterprise Service Bus”), or architectural blueprints that looks strikingly similar to things that people have been doing for a long time with DCE, CORBA, J2EE, COM, or mainframe technologies. What’s different now is that it is easier, cheaper and likely more productive to create bridges between systems. "

A Bill Simser responds:

"Indeed at the lower levels of the architecture stack the base concepts of SO have been around as good practices for years. However, we as an industry haven't been applying these base concepts consistently or properly across solutions so it's somewhat academic. If calling them SOA means that people now pay attention to them and somehow feel better about using them, then that's reason enough for me to accept that SOA exists. "

And finally, visiting his blog, I read something that gels the concept a bit more clearly as he speculates on how SAP might have been implemented in a SOA world:

"But what if the architects for SAP had applied SOA from the get-go? The actual architecture would have been defined as several aggregations of financial capabilities (like accounts, money movements, and so on) with appropriate service contracts. It would have also included a collection of capability that would be needed by the finance functions of a typical organization, again with appropriate service contracts. It would have have included some UI capabilities (Web Parts if they were really on the ball) that could consume these services (and indeed other services from different providers) and have the "appearance" of a traditional "application". However, as architects we would recognize that what the user thinks is the "application" is really just a thin facade to the orchestrations of functions they need. An important additional capability is to easily orchestrate other services that are not part of SAP (for example, a service with AMEX to get your credit card statements that can augment expense reports)."

Definitely food for thought, with my own response as follows:

Relating to your speculating about SAP, however, a few things come to mind. First, a different way of thinking when it comes to enterprise applications. You are right when you say that "traditional" thinking lies around task automation rather than loosely coupled "services" that are stitched together by consuming applications (or environments).

But how much of development revolves around loosely coupled services versus automation? Has the nature of the application changed to justify all the force behind service orientation? In one sense I can see it: the elegance of separate, contractual, modular partners, on the other I see architecture astronauts [http://www.joelonsoftware.com/articles/fog0000000018.html] building a massive framework that ultimately doesn't propel us.

All this talk of "contracts" and "services" and so on, and I contrast this with Amazon ECS - making requests for XML formatted data over HTTP: simple, elegant, and effecient.

The journey continues, but it's midnight and tomorrow's coming fast.

}