Service Oriented Architectures (SOAs) are another strategic milestone in the enterprise architecture world, but many enterprises continue to fuel the myth that surrounds the SOA mantra. Is it real or hypothetical? Are CTOs and CIOs responsible for this hype? The questions remain unanswered. As is so often the case, many firms fail to look past their previous attempts at solutions they have strived to deliver and learn from the drawbacks.

Enterprises bet on SOA, but how do you implement a successful SOA today in your company? There are some ad hoc SOA implementations available; they may not potentially transform the way IT and businesses colloborate, but do these implementations reap the real benefits of an SOA? It's really just a question of time.

Managing services, processes, and IT assets is always a challenge for huge enterprises due to their heterogenous nature. Multiple technologies (J2EE, .NET, Legacy, and so forth) and disparate applications from the likes of SAP, IBM, Oracle, and so on rule an enterprise, leading to integration chaos.

Web services are becoming vogue for implementing Enterprise SOA. Web services also help in overcoming the integration complexities faced by the traditional Enterprise Application Integration (EAI) approach. The rationale behind this proposal is to leverage an enterprise's existing expertise in building solutions and align to SOA principles, which could potentially help to overcome traditional problems that require state-of-the-art integration.

Defining SOA

The W3C Web Services Architecture Working Group defines SOA as a form of distributed systems architecture that is typically characterized by the following properties:

• Logical view: The service is an abstracted, logical view of actual programs, databases, business processes, and the like, defined in terms of what it does, typically carrying out a business-level operation.
• Message orientation: The service is formally defined in terms of the messages exchanged between provider agents and requester agents, and not the properties of the agents themselves. The internal structure of an agent — including features such as its implementation language, process structure, and even database structure — are deliberately abstracted away in the SOA. By using the SOA discipline, one does not and should not need to know how an agent implementing a service is constructed.

  A key benefit of this concerns so-called legacy systems. By avoiding any knowledge of the internal structure of an agent, one can incorporate any software component or application that can be "wrapped" in message handling code that allows it to adhere to the formal service definition.

• Description orientation: A service is described by machine-processable meta data. The description supports the public nature of the SOA: Only those details that are exposed to the public and important for the use of the service should be included in the description. The semantics of a service should be documented, either directly or indirectly, by its description.
• Granularity: Services tend to use a small number of operations with relatively large and complex messages.
• Network orientation: Services tend to be oriented toward use over a network, though this is not an absolute requirement.
• Platform neutral: Messages are sent in a platform-neutral, standardized format delivered through the interfaces. XML is the most obvious format that meets this constraint.

W3C nicely sums up this definition of SOA in its Web Services Architecture Working Group Note dated 11 February 2004. W3C clearly mentions why and where SOA and Web services can do the magic for enterprises. To be precise, SOA is not the silver bullet, but rather a discipline by principle.

You can refer to http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#service_oriented_architecture for a more detailed assessment from the W3C.

SOA Patterns

Patterns are very pervasive in any enterprise-grade solution implementation. Historically, patterns help architects overcome FFP (frequently faced problems) during the solution design. Although there are multiple ways of solving a problem, patterns are much more plausible than most of the approaches.

A pattern starts with a problem and documents a repeatable, successful solution to it. The solution may have benefits, consequences, and related solutions. It is factual that anti-patterns do exist. Anti-patterns are destructive solutions that present more problems than they elucidate. They are natural extensions to design patterns.

In the case of patterns, benefits exceed consequences, whereas in anti-patterns, consequences exceed benefits. Still, anti-patterns are becoming a way of life in software development, as they are a more compelling form of patterns.

Why do we talk about patterns in SOA? The bottom line for this discussion is that enterprises almost always end up spending more money in maintaining software than they do in developing software. This is critical to the success of any SOA implementation. Typically, anti-patterns help in solution re-factoring, migration, upgrading, and re-engineering; all are potential areas where an enterprise can start looking at a SOA-based approach for problem solving.

Page 2: SOA: Is It a Strategy or Business Practice?