Ronan Bradley's FinanceTech Directions

Ronan Bradley

The 3 SOA styles and product selection

user-pic
Vote 0 Votes

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.

2 Comments

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.

Nice post Ronan. Inspired me to post something on my blog about decision services.

Ronan Bradley's blog on infrastructure technology news and trends in the retail banking, captial markets and beyond.

Ronan Bradley

Ronan Bradley has specialized in business integration technologies and their application for over 15 years, View more

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT