Ronan Bradley's Roads to SOA« SOA chat: Oracle integrates its own products, how far Telecoms have got with SOA and Dun and Bradstreet claim SOA delivers reuse | Main | Who owns service reuse? »
September 12, 2006The 3 SOA styles and product selection
SOA addresses such a broad problem domain that it is obvious that there must be significantly different architectural patterns or styles within SOA – each best suited to address different types of integration problem and within any organization it is likely that multiple styles will need to coexist. Understanding these distinctions in the context of your organization is clearly crucial to evaluating which products (or custom coded alternatives) should be used for a specific project. Equally, ensuring that the products selected for different SOA products work well together will be essential to ensuring SOA works across the organization.
Oracle published a white paper over the summer which described at a high level some of what I would call styles and they call “Value Patterns” emerging among their customers adopting SOA. These styles are:
• SOA based integration
• Modern, composite application development
• Modernising mainframe and legacy applications
The first two styles were also well described by Brenda Michelson back when she was with Patricia Seybold before launching out as Elemental Links Inc, in “Service Oriented World: Cheat Sheet” (Brenada calls SOA based integration “flow” style integration):
“The two primary styles of SOA used in business solution development are composite application development and flow. In composite applications, the user interaction drives a request for one or many services. Most of the service invocations are synchronous in nature. A composite application typically serves one business domain. Composite applications are often delivered in a portal.
In flow, business process and/or events drive the service invocations. The service invocations are a mix of asynchronous and synchronous; however, the overall flow is usually long running and asynchronous. A flow typically crosscuts business domains and often extends outside of the enterprise. "
(Oracle’s third style I am afraid I simply don’t buy as a different style: mainframes and legacy application modernisation may be the requirement but it isn’t a value pattern in itself. Although it does make sense to make the distinction at product selection as most vendors/products are either very mainframe focused or not at all.)
The style selected of course reflects the type of solution you are trying to create but it is often also influenced by the expertise within the organization which may reflect the problem domain or be an accident of history: if there is a strong background in EAI, flow will tend to be favored; if application servers are the preferred platforms, composite application development may feel more natural.
The three styles also drive very different technical requirements which strongly links back to product selection as products will tend to specialize in one style and provide weak(er) support for the others. This is of course at odds with the normal marketing hype of “Universal SOA platform for all known problems”.
Even in the case of Oracle, IBM et al, while their portfolio may include solutions for each style, it is very unlikely that a single product can address more than one style and the degree of integration between the products is then the issue. This is probably why Oracle stressed the level of integration within their latest releases as I previously commented on and why there is still a need to consider best of breed products unless the big vendor can really prove the strength of each product and their complete portfolio.
Posted by rbradley in
Enterprise Service Bus
• Market trends
• SOA concepts
|
Digg This|
Add to del.icio.us
Trackback Pings
TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/676
Its' good to know that there is only two styles of architecture in that field. I long feared that there was as much as vendors'number on the market ( plus consulting people ).
But are you sure that your " flow " style is really SOA-based ? There are decades now that IT people try to build exchanges between business-specialized systems, and it always consisted of flows. Long before SOA.
I think the all-Service approach is only one way out of so much that have to consider there is suppliers of infos and consumers of infos, and that suppliers should comply with consumers needs through well-formed interfaces.
And most of times, these past decades of RPC, CORBA, EAI, Web Services, ESB and SOA only taught to us that at the IS Enterprise level the rule is division of work. That is to say you have specialized skilled peoples requesting specialized IT tools and systems for their internal use, and building their specialized relationship to the customer.
The hard thing is requesting from those budget-owning business people to let IT people make connections with other similar business entities in the company. IT people toil to be at the same time the IT suppliers of each business division's solution and the regulators of end-to-end exchanges throughout the company, thanks to their contracting interfaces.
Whether it is Service-based ( aka req/rep ou pull ) links or Event-based ( aka pub/sub or push ) links, the flow is about circulating information througout the enterprise and outside. So whatever the style be SOA or flow-like or composite application oriented the real thing is having common end-to-end processes starting from external customer business events and encompassing all the needs of the different division in the company.
Don't you agree that the most probable is that you have combinations of service-orientation and event-orientation to build up end-to-end IT processes in support of business processes ? And that the two styles you mention are not architecturally exclusive, as the SOA hype seems to impose, but complementary in a comprehensive and complex organisation.
Posted by: ltl at September 14, 2006 02:39 PM
Nice post Ronan. Inspired me to post something on my blog about decision services.
Posted by: James Taylor at September 15, 2006 06:45 PM
Post a comment
Subscribe to feed
