Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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
- Proprietary implementations
- Adoption of premature technologies
Over the past decade, enterprises have seen many architectures or paradigms that tried to address some of these issues. But, none of them succeeded in their efforts to gain mind-share in streamlining the processes that involved simplifying application integration.
Service Orientation: Evolution or Revolution?
Businesses have to transform rapidly to provide a much healthier atmosphere for customers to sustain in this technology-driven world. Service orientation is an evolution by theory, but revolution by practice. Enterprises must not miss this opportunity to take advantage of SOA. This calls for a major rejuvenation of how businesses operate within an enterprise. For example, IT is a major asset to an enterprise. It is also considered to be backbone of any enterprise. Complexity of IT varies on the size of the enterprise. Managing such complex IT is a challenge to many of the enterprises due to the heterogeneity of applications, platforms, and so on.
The evolution is from Web services to business services to SOA. Services are the least common denominator in the SOA world.
SOA Vision
Enterprises have to identify their core assets and capitalize on them. SOA comes with a built-in thought process that helps simplify the integration points faced by an enterprise.
SOA Implementation Life Cycle
A typical approach to visualizing SOA implementation life cycle could be depicted as shown in Figure 1. The stages in this life cycle could overlap and recur as the project progresses and matures. There could be different facets to this life cycle, but the underlying concepts remain the same. Design, Develop, Deploy, and Manage is a traditional life cycle methodology followed in most of the IT project implementations, but overlap and recurrence happening at all phases of this life cycle is unique to SOA implementation.
Figure 1. SOA Implementation Life cycle
SOA Standards
Currently, there are a number of products that can enable SOA and provide value to business. SOA-based Web services products are sought after for early adoption. SOA standards are at infancy level. However, it leverages existing Web services standards as they are mature enough to implement a successful SOA.
The SOA Reference Model has been defined at OASIS with Adobe Systems, NEC, and Fujitsu as the founding members of this Technical Committee. This group recently published a public review draft version of Reference Model for Service Oriented Architecture 1.0 (SOA-RM) specification. The details of this specification can be found at http://www.oasis-open.org/committees/download.php/16628/wd-soa-rm-pr1.pdf. This group is focused on developing a core reference model to guide and foster the creation of specific service oriented architectures.
Summary
This article outlined some of the compelling reasons for going the SOA way and tried to address some of its core benefits. The Gartner Group predicts that “By 2008, SOA will be a prevailing software engineering practice, ending the 40-year domination of monolithic software architecture.” Enterprises should capitalize on SOA because they are the key drivers in today’s marketplace.
References
Web Services Architecture W3C Working Group Note: http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
OASIS SOA Reference Model TC: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
About the Author
Arulazi Dhesiaseelan is a senior developer in the Global Delivery India Center (GDIC) of HP Services, Bangalore. He has a Master’s Degree in computer applications from the PSG College of Technology in India. He has six years of focused IT experience. He was involved in the UDDI4J project hosted at http://uddi4j.org. He has extensively worked on Web service technologies such as WSDL, UDDI, and SOAP. Currently, Arulazi is involved in developing mobile device management solutions for HP’s Service Delivery Platform (SDP). He can be reached at aruld@acm.org.
