Enterprise Architecture & Service Oriented Architecture (SOA)

Service Oriented 'Architecture' (SOA)

By J. Schekkerman

Service-orientation presents an ideal vision of a world in which resources are cleanly partitioned and consistently represented. When applied to IT architecture, service-orientation establishes a universal model in which automation logic and even business logic conform to this vision. This model applies equally to a task, a solution, an enterprise, a community, and beyond.

By adhering to this vision, past technical and philosophical disparities are blanketed by layers of abstraction that introduce a globally accepted standard for representing logic and information. This level of standardization offers an enormous benefit potential for organizations, as many of the traditional challenges faced by ever-changing IT environments can be directly addressed through the application of these standardized layers.

For example, by shaping automation logic through service-orientation, existing investments can be leveraged, business intelligence can be accurately expressed, and inherent automation agility can be achieved. When coupled with the Web services technology platform, SOA offers a significant and real potential for manifesting these benefits.

SOA is an Architectural Style NOT an Architecture itself.

SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. So the term SOA is a littlebit misleading in this context.

This sounds a bit too abstract, but SOA is actually everywhere. Let's look at an example of SOA which is likely to be found in your living room. Take a CD for instance. If you want to play it, you put your CD into a CD player and the player plays it for you. The CD player offers a CD playing service. Which is nice because you can replace one CD player with another. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different.

The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems.

The results of a service are usually the change of state for the consumer but can also be a change of state for the provider or for both. After listening to the music played by your CD player, your mood has changed, say, from "depressed" to "happy". If you want an example that involves the change of states for both, dining out in a restaurant is a good one.

The reason that we want someone else to do the work for us is that they are experts. Consuming a service is usually cheaper and more effective than doing the work ourselves. Most of us are smart enough to realize that we are not smart enough to be expert in everything. The same rule applies to building software systems. We call it "separation of concerns", and it is regarded as a principle of software engineering.

So the term Service Oriented Architecture (SOA) is a littlebit misleading because SOA has less to do with architecture itself but is a style characteristic of architecture. But has all to do with a style of defining and structuring software functionality in terms of services. Several years ago we have seen the paradigm of component based software development (CBD). CBD was promising the same functionality as SOA is doing today, however CBD was difficult to implement with the tools at that time.

The Right Level of Granularity

Today there are several software vendors, tools & standards that support SOA, based on the underlaying idea and concept of web services. So SOA is a way of software development based on well defined services. Problem in the CBD world as well as the SOA world is the right level of granularity of the services. Defining the services very small with only a limited functionality is supporting reusability and flexibility but introduces a maintenance and governance as well as new testing problems and performance issues based on the network consumption of these services. Defining the services too large is delivering less or no reusability, less flexibility etc. but is better to maintain with less network ussage. Balancing between both and finding the right granularity is one of the key succes factors of SOA, hoever it is hard to do to find the right level of granularity and only a top-down approach derived from the definition of services in terms of the service oriented enterprise will deliver enough insight and overview about the principles and requirements and the functional decomposition of business services in terms of software services that supports that business.

The service-orientation ideal has sparked a movement that has positioned SOA as the next phase in the evolution of business automation. In the same manner in which mainframe systems were succeeded by client-server applications, and client-server environments then evolved into distributed solutions based on Web technologies, the contemporary, Web services-driven SOA is succeeding traditional distributed architecture on a global scale.

All major software manufacturers and vendors are promoting support for SOA—some even through direct involvement in the development of open standards. As a result, every major development platform now officially supports the creation of service-oriented solutions.

Be forewarned, though, that SOA makes impositions. A change in mind set is required, as business logic now needs to be viewed within a service-oriented context. Applying this context also requires a change in automation logic, as solutions now need to be built in support of service-orientation. Finally, a technical architecture capable of hosting service-oriented automation logic further introduces new technology and infrastructure requirements.

The SOA objectives

Technically, the foremost concept to understand is what we are trying to achieve with SOA. At the very bottom, SOA relies on basic units of application software, which automates one or more pre-defined business processes. In a simplistic scenario, the goal is to make these basic application units accessible to the client and also for these basic application units to talk to each other in a technology-neutral manner. In a more complex scenario, the goal is to sustain these basic application components and just change the underlying technology for improved efficiency. For example, one organization might have a “CustomerManagement” application component. The component offers some Services and the Insurance Department and the Marketing Department of the organization make use of the CustomerManagement. Now for improved efficiency, we must be able to migrate the CustomerManagement component to EJB without affecting the client of this component or event, we should be able to convert this component to a .NET component even though the client to this component is written using a different technology, Java per say.

Keeping these issues in mind, implementing SOA demands the following features:

Technology Independence: The Consumer of a Service component is completely independent of the technology of the Provider component and vice-versa.
Life-cycle Independence: Each of the Provider and Consumer Service components should be able to operate in a separate life- cycle.
Loose Coupling: The Service Consumer Component must define its specification independent of the Service Provider Component. The responsibility of aligning the two specifications is up to the Assembler component, which bridges the gap between two worlds.
Invokable interfaces: The Service interfaces must be invokable either locally or remotely. At the architecture level, we don’t really care how the interface is invoked.
Communication Protocol: A Service must be invokable by variety of protocol. The choice of protocol must not restrict the behaviour of the Service. Binding to a specific protocol must take place at run-time/deployment-time, and not at the design or development time.

Services in the context of SOA

Services in the context of SOA are defined as software application units that provide a distinct and atomic business process. Services do operate independent of the technology involved in the Consumer and the Service provider itself.
Although it is a new and novel concept to introduce the inter- operability of application units in a technology neutral way, the basic building of SOA relies on some of the proven methodologies such as Component Based Development. The Components do exist as the basic unit of the application performing a certain business operation itself or by collaborating with other components. What is unique to the SOA is how these components are invoked and also how the components interact with each other.

Having a sound Component based design helps any organization to newly implement or even migrate towards SOA in a smooth transition. In the following sections, we will elaborate on the concepts of Component Based Development and how it can be used alongside Service Oriented Architecture (SOA). Often we use the term SOA and Web Service interchangeably, which is not strictly correct. Web Service is one implementation of SOA wherein SOA really means a set of technology, which enables us to develop business functions as Components which can be invoked and used in a technology independent fashion.

The Process
In the previous section, we have outlined guidelines on identifying the reusable business processes across the organizations boundary. The outcome of this process can lead to the basic building blocks or Components that co-exist within an organization and perform one or more business operations.

Component Specification: In a technology neutral way like UML define the business functions. This must be technology independent. This just specifies what the interfaces are that the Component offers and what the Component dependencies are.
Interface Definition: Translation of the Functional Specification in a target platform language in a technology neutral way. For example, the interfaces can be elaborated using UML and translated into a programming language of choice such as Java.
Service Specification: Subscribing to 1..* functional interfaces. Services can collate multiple Component interfaces to provide a coarse-grained Service Definition. Again, this needs to be technology neutral.
Service Discovery and Registry: A mechanism for Registering Services to a registry. The Consumers use a Service Discovery mechanism and access the Services by looking up in the registry.
Technology binding: Consumer Components are inherently technology independent. We need to plug-in a technology binding mechanism to use a certain kind of interface exposed by the Service provider and its runtime instance technology. For example, we need to plug-in a technology layer into the Service Consumer to access a Service by using EJB or by using Web Service mechanism as is appropriate.

The following small example will clear the clouds. Let us assume that in a company we are to write a Payroll Management System which manages the Employee payroll records and posts the pay- slips to their home addresses using the Address manager component. Also there is another Component which looks after the employee welfare and sends out a gift check on the anniversary or birthdays of employees.

The component specification of the above components can be shown as in the next figure.

The Component Specification

Let us consider that we might want to offer a Service at a higher level called the “EmployeeService”, which can subscribe to both the Payroll Management and Welfare Management interfaces. The Service Definition for the EmployeeService might look like the following in figure.

The Service Specification

The interface definitions are still technology independent but can be translated in to a specific programming language such as Java. For example, the interface definition for the EmployeeService can look like the following in Java (Listing - 1). We have omitted the data type references from the diagram for simplicity

Tthe interface definition(there were two line breaks added to make it fit the page)
Note: The Exceptions listed above are very much application specific exceptions and avoid any technology specific exceptions.

Services Connections
So far we have defined the EmployeeService and its interfaces. We have seen that this interface definition is totally technology neutral. However, at deployment time we may decide to one or more instances of this Service supporting different communication protocol. There is no restriction that the same Service cannot offer more than one invocation protocol. Rather, in different situations it is more appropriate to offer multiple protocol support to provide service to different Consumers.
So far we had the Consumer component and the Service Component being specified and implemented in isolation. But there must be something in the middle to connect these two together. We discuss the missing bits as follows:

From a Logical Concept to a Physical Implementation
In OO concept, the great thing about interface concept is that multiple implementations of the same interface can co-exist. Binding to any particular implementation can happen at run-time or compile-time. Dynamic binding at runtime offers greater flexibility to switch between implementations based on context. For example, an AddressManager Component can be invoked remotely using Web Service based on XML-SOAP protocol or also can be invoked as a Pure Java component or EJB when it is invoked locally.
It is a good design pattern to separate the technology layer form the actual business logic and business operations. The business operations can be implemented as a standard Java class. The technology layer is solely responsible to implement the technology logic and infrastructural service calls. For example, in EJB technology, the technology layer will consist of the EJBs, which will interact with the container to manage transactions etc. However, the actual business logic may be delegated to another standard Java class.

Service Discovery and Registry
When a Service interface is implemented using a specific technology, the Service needs to publish itself to a registry for the Consumers to lookup and use the Service. This is implemented as another separate layer called Service Access Layer. This layer is responsible for looking up Services using certain lookup mechanism. For an EJB, this layer might perform a JNDI lookup and for Web Service this layer might use a Web Service Registry lookup.

Where Happens the Mapping
So far we have said that the Service consumer and the Service provider specification are independent of each other. This also meant that the data represented in both these domains can also be different. So there needs to be a mechanism to align these two worlds. An ideal place for this mapping to happen is the Service Access Layer. This layer can receive the data object from the Service consumer and then use the Service provider Transfer object to map data. Also this layer can convert any Exceptions generated into an appropriate one that is understood and defined in the Service consumer specification.

Who Implements the Layers, the Responsibilities
We have seen that layering the application based on “separation of concern” is a good way to achieve the loose-coupling between the Service consumer and the Service provider. We have identified the layers within Components carrying out different roles and responsibilities. Looking at the full picture, we can thus assign the responsibilities to the Service consumer and to the Service Provider.

The Service Provider component is responsible for providing all the above mentioned layers. A mistake often made is to make the Service Access layer as part of the Consumer, which creates a tight-coupling between the Consumer and the Provider in terms of technology.

These series of SOA sections are based on 2 articles of Benoy Jose, who is a web developer with over six years of experience in J2EE and Microsoft technologies. He is a Sun Certified programmer and enjoys writing technical and non-technical articles for various magazines and Samudra Gupta, who has more than 8 years of experience in the area of Java based application design and development. He works as an independent consultant in United Kingdom and at present provides consultancy in government tax regime and intelligence information system development.

The Top 5 SOA Adoption Pitfalls of 2005

By: Thomas Erl, author of “Service-Oriented Architecture: Concepts, Technology, and Design"

It’s been a tumultuous year in the world of SOA and we’re just at the beginning of rollercoaster ride. As organizations continue to re-examine the ever-shifting landscape of service design, service buses, service governance, and even just services, there are often mixed emotions. Many are confused as to the maturity and overall status of SOA in the IT industry, but there is definite sense of excitement around its touted potential to unite business and technology.
Many SOA initiatives were launched this year, each with its own set of goals and expectations. Some failed miserably, while others failed just a little. For many, the determining factor in fulfilling their original objectives was drawing upon the experience of those who had already survived projects with less fortunate results. These individuals lived to tell their stories and warn others of what lies ahead along the path toward SOA.
In our line of work we get pulled into various projects at different stages of completion. We’ve seen good SOA go bad and bad SOA get even worse. Problems can be fixed and mistakes can be undone, but of course there is always an impact to getting things back on the right track. The best course of action is, obviously, avoiding problems and mistakes in the first place.
Understanding the pitfalls others have fallen victim to puts you in a position from which you can form the extent of foresight required to chart a safer route down your own SOA roadmap. To help you get a head start, we have collected the five most common SOA adoption pitfalls of 2005.

5 NOT UNDERSTANDING SOA PERFORMANCE REQUIREMENTS
Loose coupling comes at a price. When implemented with Web services, SOA introduces layers of data processing as well as the associated performance overhead imposed by these layers. When starting out small, it is easy to build service-oriented solutions that function and respond as expected. As the scope increases and more functionality is added, the volume of message-based communication predictably grows. This is when unprepared environments can begin experiencing significant processing latency.
Critical to building a successful service-oriented solution is understanding the performance requirements of your solution and the performance limitations of your infrastructure ahead of time. This means testing (and, if necessary, strengthening) the message processing capabilities of your environments, and paying close attention to service design so as to achieve an acceptable balance between transmission rates, transmission sizes, and other service characteristics that can negatively affect solution performance.

4 NOT STARTING WITH AN XML FOUNDATION ARCHITECTURE
In the world of today’s SOA, everything begins with Web services. That statement has become a mantra of sorts within some organizations, but it is not entirely true. In the world of today’s SOA, everything, in fact, begins with XML. It is the standard from which multiple supplementary standards have evolved to form a de facto data representation architecture. It is this core set of standards that has fuelled the creation of the many Web services specifications that are now driving SOA.
So much attention is given to how data is transported between services that the manner in which this same data is structured and validated behind service lines is often neglected. This oversight can lead to an improper implementation of a persistent XML data representation layer. This layer is foundational to SOA and its weaknesses will have repercussions across any solutions built upon it.

3 NOT CREATING A TRANSITION PLAN
The chances of a successful migration will be severely diminished without the use of a comprehensive transition plan. Because the extent to which service endpoints are positioned within an enterprise can lead to a redefinition of an environment’s infrastructure, the affects of a poorly executed migration can be significant.
Transition plans allow you to coordinate a controlled phasing in of service-orientation and SOA characteristics so that the migration can be planned on a technological, architectural, and organizational level.
Typical components of an SOA transition plan include an impact analysis (that predicts the extent of change SOA will impose on existing resources, processes, custom standards, and technology), transition architectures (that map out a series of planned hybrid stages toward a target SOA), and a speculative analysis (that takes into account the future growth of Web services and supporting technologies).

2 NOT STANDARDIZING SOA
SOA, like any other architecture, requires the creation and enforcement of internal design standards for its benefits to be truly realized. For example, if one project builds a service-oriented solution in isolation from others, key aspects of its solution will not be in alignment with the neighboring applications it may be required to interoperate or share agnostic services with one day.
This can lead to many problems, including incompatible data representation, service contracts with irregular interface characteristics and semantics, and the use of non-complementary Web services extensions (or extensions being implemented in different ways).
SOA promotes a development environment that abstracts back-end processing so that it can execute and evolve independently within each application. However, standardization is still required to ensure consistency in design and interaction of services that encapsulate this back-end logic.

1 BUILDING SOA LIKE TRADITIONAL DISTRIBUTED ARCHITECTURE
The number one obstacle organizations have been facing when attempting to achieve SOA is building service-oriented solutions in the same manner in which traditional distributed solutions have been built, under the pretence that SOA is actually being achieved.
SOA is not CORBA + XML, nor is it ASP.NET + WSE. Service-orientation is not object-orientation, nor is it “close enough” so that building object-oriented component logic will always “fit right into” service-oriented solution environments. SOA is a distinct architectural model based on service-orientation, a distinct design paradigm. Understanding these distinctions is critical to building automation logic that is truly service-oriented and in alignment with where the SOA industry is moving on a global scale.

This section contains excerpts from “Service-Oriented Architecture: Concepts, Technology, and Design” by Thomas Erl (792 pages, Hardcover, ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2005). For more information, visit www.soabooks.com.

The Service Oriented Architecture Maturity Model

Companies are at different levels of maturity in the adoption and incorporation of Services-Orientation (SO). Some are just beginning to explore the world of SO using its technology instantiation: Web services. They are wrapping legacy functionality and exposing it for invocation for third-parties, clients, and business partners. This gets them into the game: they ramp up the development team, start the process of changing the corporate culture to better support SO, and take the first steps in the exploration of new technologies and the business capabilities that may be impacted.

The next step of SO adoption is when the initial testing of Web services has been successfully overcome and now the organization is beginning to integrate systems and applications using services. As proprietary protocols, glue code, and point-to-point connections give way to more open, standards-based protocols and interaction based on service descriptions that each system externalizes, we step into the realm of Service-Oriented Integration (SOI). In this world, the enterprise service bus reigns supreme: a mechanism for mediation, routing, and transformation of service invocations irrespective of the target service provider. It helps overcome many of the shortcomings associated with point-to-point connections.

Service Oriented Architecture Maturity Model

This SOA Maturity Model provides a framework for discussion between IT and business users about the applicability and benefits of SOA in an organization across five levels of adoption maturity.

Choreography of Services

With the growing popularity of Service Oriented Architecture (SOA) and Web Services, these diverse assets can be made available as individual enterprise services. How do we build and expose them as such and how do we leverage them in building new service-based applications or business processes? This is the problem Business Process Choreography tries to solve.

Web Services Choreography Interface (WSCI) is an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services. WSCI describes the dynamic interface of the Web Service participating in a given message exchange by means of reusing the operations defined for a static interface. WSCI describes the observable behavior of a Web Service. This is expressed in terms of temporal and logical dependencies among the exchanged messages, featuring sequencing rules, correlation, exception handling, and transactions. WSCI also describes the collective message exchange among interacting Web Services, thus providing a global, message-oriented view of the interactions.

SOA Related Links