Capitalizing on SOA Wisconsin

provided by: 
Originally published at Internet.com

Service Oriented Architecture (SOA) is another strategic milestone in the enterprise architecture world. Many enterprises fuel the myth that surmount the today's SOA mantra. Is it real or hypothetic? Are CTOs and CIOs responsible for this hype? The questions remain unanswered. Most of the time, one does not look past his previous attempts towards the solutions he delivered and learn from his drawbacks. Enterprises bet on SOA, but how do you implement a successful SOA today in your company? There are some adhoc SOA implementations available; they may not potentially transform the way IT and businesses colloborate. But, do these implementations reap the real benefits of a SOA? This is just a question of time.

Managing services, processes, and IT assets is always a challenge for huge enterprises due to its heterogenous nature. Multiple technologies (J2EE, .NET, Legacy, and so forth) and disparate applications (SAP, IBM, Oracle, and so on) rule an enterprise, leading to integration chaos. Web services are becoming vogue for implementing Enterprise SOA. Also, Web services help in overcoming the integration complexities faced by 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 which 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 about why and where SOA and Web services can do the magic for enterprises. To be precise, SOA is not the silver bullet, but 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 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 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 case of patterns, benefits exceed consequences, whereas in anti-patterns, consequences exceed benefits. But, anti-patterns are becoming a way of life in software development, as they are a more compelling form of patterns.

Why do you talk about patterns in SOA? The bottom line for this discussion is that you spent more money in maintaining software than 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.

SOA: Is It a Strategy or Business Practice?

Today, enterprises talk about SOA as its backbone in streamlining its businesses and provide seamless connectivity to its customers. A service is a basic unit in the SOA world. SOA is all about segregating services and its associated behavior, to reuse and leverage its capabilities exponentially. It addresses many of today's enterprise's problems that include security, manageability, interoperability, and so forth.

SOA is a design blueprint that helps enterprises achieve their goals in a more pragmatic way.

SOA Is Not Web Services

Web services can be one of the realizations of SOA, but not the only one. Web services are becoming more mature and efforts are made to use them as an integration tool; these facts drive the adoption of Web services for SOA. SOA strongly emphasizes loose coupling, which is a natural fit for Web services. The reason is so obvious and practical: Web services are becoming the lingua franca of the services paradigm.

SOA Is Not ESB

Forrester Research is quoted as saying the following: "An enterprise service bus (ESB) is a software infrastructure that enables service-oriented architecture (SOA) by acting as an intermediary layer of middleware through which a set of reusable business services are made widely available. An ESB helps enterprises obtain the value of SOA by increasing connectivity, adding flexibility that speeds change, and providing greater control over use of the important resources it binds. The wide range of mediation services that can be provided by an ESB fit into a broader architecture pattern, which may be partly or wholly implemented, depending on the breadth of actual requirements. Any enterprise looking to implement SOA should evaluate what form of ESB would be required, and begin to take the initial steps to exploit this key emerging technology."

Nothing in SOA demands an ESB. But, ESB could potentially enable SOA with its current support for standards and its wide acceptance among SOA solution implementers. In a nutshell, SOA is more than ESB or Web services.

Pain Points

Some of the pain points faced by today's enterprises are outlined below. * Ad hoc integration silos * Legacy application maintenance and upgrades * Centralized security challenges *