CSC/ECE 517 Fall 2010/ch6 6j SO

Service-oriented architecture

Introduction

SOA (service-oriented architecture) has become a buzzword of late. The World Wide Web Consortium (W3C) refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. Only a technical person can understand this definition. A simplified version of this definition would be -

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. The combination of services - internal and external to an organization - makes up a service-oriented architecture.

Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive into the details, let us step back and examine the context for the evolution of SOA. To do that, we have to simply look at the challenges faced by the developers over the past few decades and observe the solutions that have been proposed to solve their problems.

The Problem

Early programmers soon realized that writing software was becoming way too complex. They realised the need of reusing some of the code they were rewriting. Researchers had a new mantra: go-to considered harmful. They introduced the concept of modular design. Modular design deals with the use of routines, sub routines and functions in order to organize and execute specific sets of instructions which helped programmers to reuse their code. This concept was again OK for smaller programs. But as the size and the complexity increased this started to create a maintenance nightmare. When a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. Also, here we lay stress only on the steps of execution, but we are hardly bothered about the data for which all these has been done. This laid the groundwork for thinking new concepts, which would give absolute data security and OOPs evolved.

To solve these problems researchers proposed object-oriented software. Again, as software complexity grew, developers realized that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.

Key Components of SOA

The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, dynamic discovery, and web services. Each of these plays an essential role in SOA.

Service

A service in SOA is an exposed piece of functionality with three properties:

1. The interface contract to the service is platform-independent.

2. The service can be dynamically located and invoked.

3. The service is self-contained. That is, the service maintains its own state.

A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if some one was looking for a credit-card authorization service, he might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, he would select a service (see Figure below). The last property of a service is that the service be self-contained.

Message

Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.

Dynamic Discovery

Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:

1. Scalability of services; you can add services incrementally.

2. Decouples consumers from providers.

3. Allows for hot updates of services.

4. Provides a look-up service for consumers.

5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

Web Service

Although the concepts behind SOA were established long before web services came along, web services play a major role in a SOA. This is because web services are built on top of well-known and platform-independent protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is the combination of these protocols that make web services so attractive. Moreover, it is these protocols that fulfill the key requirements of a SOA. That is, a SOA requires that a service be dynamically discoverable and invokeable. This requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service have a platform-independent interface contract. This requirement is fulfilled by XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is why web services lie at the heart of SOA.

Benefits of SOA

SOAs offer the following advantages over other approaches:

• They offer business services across the platforms.

• They provide location independence.

• Services need not be at a particular system or particular network.

• Completely loosely coupled approach.

• Authentication and authorization support at every level.

• The search and connectivity to other services is dynamic.

Short-term benefits of implementation:

• Enhances reliability.

• Reduces hardware acquisition costs.

• Leverages existing development skills.

• Accelerates movement to standards-based server and application consolidation.

• Provides a data bridge between incompatible technologies.

Long-term benefits of implementation:

• Provides the ability to build composite applications.

• Creates a self-healing infrastructure that reduces management costs.

• Provides truly real-time decision-making applications.

• Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners.

Benefits from the perspective of Business Value

• Ability to more quickly meet customer demands.

• Lower costs associated with the acquisition and maintenance of technology.

• Management of business functionality closer to the business units.

• Leverages existing investments in technology.

• Reduces reliance on expensive custom development.

Areas in SOA Implementation where OO Concepts are used

As service oriented architecture gains popularity, it is starting to prove beneficial in places where OOP was inadequate. However, this does not mean an end to the OOP paradigm. Significant OOP principles are required by SOA architects to create interfaces to distributed applications. The main areas where OO concepts come into picture are

1. Interface Orientation The interfaces should be at a higher level of abstraction from service implementation and should be able to provide well defined interfaces in an implementation-independent manner. There should be a comprehensive, uniform service specification with stable and well managed contracts.

2. Interoperability This is of prime concern to ensure seamless integration of applications in a heterogeneous environment. So they have to be interoperable, standard-based interfaces. Such technical standardization, coupled with business standardization will make SOA more effective.

3. Autonomy and Modularity An effective SOA architecture divides the existing architecture into autonomous sub systems. Care is to be taken that resources and functions are grouped together to ensure high cohesion and reduced runtime dependencies through a loosely coupled communication system.

Cohesion in SOA

Cohesion, a quality to be maximized, focuses on the relationships between the activities performed by each module. There are different forms of coupling cohesion. The following three of these forms are considered safe -

• Functional cohesion occurs when a module does only one thing. Such modules that also display low coupling are highly reusable because they are self-contained and largely independent of any surrounding code.

• Sequential cohesion occurs when a module carries out several tasks, and the input of one task feeds into another, perhaps modifying the data as it passes through. A sequentially cohesive module or service is often a wrapper around other modules or services, chaining them together to perform a larger function.

• Communicational cohesion is when a module carries out multiple operations based on the same input or output data. Such cohesion often results from the desire to operate only once on a complex set of data, calculating in one pass everything that the rest of the application might possibly want to retrieve or derive from it.

In contrast to the “good” forms of cohesion, the following four forms are frowned upon:

• Procedural cohesion is similar to sequential cohesion except that the data feeding each of the tasks is different. Such cohesion often results from artificially grouping activities of an application together into catch-all functions in a misguided attempt to reduce coupling.

• Temporal cohesion occurs when a module’s tasks are related only by the time they’re carried out. Such modules cause maintenance problems if one of the tasks needs to be performed at a different time.

• Logical cohesion is a condition in which a module’s activities are grouped together because they appear to be able to share common implementations. This results in a strange or awkward interface for the module, thereby punishing all of its users, just to ease the implementer’s job.

• Coincidental cohesion represents the bottom of the cohesion barrel, in which a module’s tasks are related only by the fact that they reside together in that module.

Coupling in SOA

Coupling is a measure of interdependencies between modules, which should be minimized. Hence, quality systems tend to exhibit “loose” rather than “tight” coupling. The following forms are referred to as normal coupling -

• Data coupling occurs when modules pass data between each other, such as when a variable is passed as a parameter to a function call.

• Stamp coupling is like data coupling but with composite parameters. The difference is that the composite structure’s fields are passed somewhat invisibly. Passing a whole structure allows the called module to manipulate all fields contained therein, which can be undesirable if the module really only needs access to one or two fields.

• Control coupling occurs when one module knows something about and passes information that’s intended to control the logic of another. Such an arrangement make it harder to change the decisions, and also implies reduced module cohesion as well.

The following forms are to be avoided -

• Common coupling occurs when two modules share a common data area, such as global variables. Consider the services that share directories, registries, or databases.

• Content coupling describes the situation in which one module directly refers to another’s innards. Modern form is generally known as implementation coupling, in which one module depends on the implementation details of another. It means that changes to one module or service will almost certainly require modifications to the other.

• Interface coupling refers to the degree to which one module depends on another’s interface. Objects and packages generally offer multiple methods, and it’s not unusual for code using an object or package to depend on many or all of its methods.
  

Design Patterns in SOA

A ‘service’ is the main design element of service oriented architecture. It encapsulates existing application logic and can be dynamically combined to form business processes. Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at a business-related level of granularity using widely applied standards. The OO design principles and design patterns which come in very handy when designing services are

1. Service loose coupling

This design principle promotes the independent design and evolution of a service’s logic and implementation. But it still guarantees baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences. Coupling should be such that runtime dependencies should be reduced to a minimum.

2. Service Abstraction

Abstraction emphasizes the need to hide as much of the underlying details of a service as possible. This contributes in preserving the loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

3. Service Reusability

Reuse is a core part of typical service analysis and design processes, and also forms the basis for key service models. It emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

4. Service Autonomy

The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

5. Service Composability

As the level of sophistication and complexity in the design of a service grows, the ability to effectively compose services is a critical. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition.

Service Oriented Architecture in contrast with Enterprise Architecture

Similarities

SOA and EA domains share many similarities.

• Both address similar architectural domains.

• Both are intended to closely align IT with business.

• Both use input based on business objectives.

• Both require similar strategies and planning activities.

Differences

While the focus of the EA architecture domains is on the macro level, the SOA architecture domains work on a micro level. More specifically:

• EA focuses on defining business components, while SOA focuses on business services.
• EA deals with application frameworks and enterprise applications, while SOA's scope is on service modeling only.
• EA deals with enterprise-level infrastructure including servers, databases, and so on, while SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
• EA addresses enterprise integration patterns and when they should be used, including point-to-point integration; file transfer, and other traditional application integration approaches. SOA provides an integration approach based on using services. Though the SOA approach to integration may prove to be the most flexible and recommended approach, you should consider it as one of the approaches EA needs to define and support.

Service Oriented Architecture	Enterprise Architecture
Focus on ‘service’	Focus on business components
Scope limited to service modeling	Also focuses on Application frameworks
Focus on infrastructure providing services, ie Enterprise Service Bus	Deals with enterprise level infrastructure components like servers, databases, etc.
Provides an integration approach based on using services	Addresses integration patters like point-to-point integration; file transfer, and other traditional application integration approaches

Example

SOA has had a huge effect not only on the server side but also on the clients meant for using services. A very vivid illustration of this is the ability of most modern browsers to subscribe to RSS feeds.

Clients must have strongly constructed communications services. Any communication standard (example XML-RPC) has to be implemented on both sides to achieve proper communications.

The main controller of each client application must be capable of launching various runtime environments. This is done via launching one or more virtual machines that can interpret scripting languages or consume bytecode.

Most modern clients have some form of data persistence and state management. This usually works in conjunction with the clients’ communications services to allow the controller to use cached resources rather than attempting to synchronize states if communications are down. Additionally, rendering and media functionality specific to one or more languages is used to ensure the view of the application is built in accordance with the intentions of the application developer.

SOA Implementation using J2EE

Service-oriented architectures are used to implement composite applications that offer location transparency and segregation of business logic. These two key features allow replacement or modification of individual components in the composite application without affecting other components or the process as a whole. Moreover, you can independently specify alternative paths through which the various parts of the composite application exchange messages.

The J2EE platform provides web services support through the new JAX-RPC 1.1 API, which supports service endpoints based on servlets and enterprise beans. JAX-RPC 1.1 provides interoperability with web services based on the WSDL and SOAP protocols. In addition to numerous web services APIs, the J2EE 1.4 platform also features support for the WS-I Basic Profile 1.0. The WS-I Basic Profile standards allow web services to overcome the barriers of different programming languages, operating systems, and vendor platforms so that multiple applications can interact. This makes it an ideal platform to implement SOA.

Using J2EE as a development platform, a web service client can access J2EE applications as: 1. The client can access a web service created with the JAX-RPC API and at the backend, JAX-RPC uses a servlet to implement the web service. 2. A web service client can also access a stateless session bean through the service endpoint interface of that bean. Web service clients cannot access other types of enterprise beans.

SOA can be used for internal corporate applications as well as to expose services to external clients.

The basic functional units of this architecture are:

• External clients: These can include Web-based clients, mobile clients, or clients coded in the .NET environment, Perl, or any other programming language. All of these clients send requests for various services.

• Corporate firewall: Based on its security policies corporations have firewalls between its intranet and the Internet, restricting incoming packet information.

• Web Services Gateway: It a middleware component that provides an intermediary framework between Internet and intranet environments during web service invocations. It is possible to safely externalize a web service so that it can be invoked by clients from outside the firewall. It provides security (basic authorization) on the individual methods of a web service, as well as for the gateway as a whole. Using the Web Services Gateway, a request from the client can be transformed into any messaging protocol required by your service.

• EJB web services: With the EJB 1.4 specification, web services endpoints can be modeled as stateless session beans.

• Data access interfaces: This layer is responsible for interacting with the EIS and returning data back to corresponding EJB web service methods in the format that those methods expect.

• Mainframe based Services: Existing mainframe-based services can be exposed as web services, thus revealing them to the outside world. Web service clients interact with EJB web services using the HTTP-based SOAP protocol, and the EJB methods post requests to an MQSeries queue via the JMS protocol.

Conclusion

Though software developers have gained experience over the last decades, they're yet to solve the mysteries of software complexity. As complexity grows, researchers find more innovative ways to answer the call. SOA, in combination with web services, is the latest answer. Application integration is one of the major issues companies face today; SOA can solve that. System availability, reliability, and scalability continue to bite companies today; SOA addresses these issues. Given today's requirements, SOA is the best scalable solution for application architecture.

In nutshell, a Service-Oriented Architecture (SOA) addresses software infrastructure challenges for organizations that require more flexible applications and systems, and greater alignment of IT with business goals. SOA blurs the traditional application and organizational boundaries, allowing businesses to leverage new and existing investments in applications, system development and ubiquitous Internet infrastructure inside and outside of the enterprise. These benefits are delivered not by just viewing service architecture from a technology perspective and the adoption of Web Service protocols, but require the creation of a Service Oriented Environment that is based on the following key principals we have articulated in this article;

• Service is the important concept. Web Services are the set of protocols by which Services can be published, discovered and used in a technology neutral, standard form.
• SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed.
• With SOA it is critical to implement processes that ensure that there are at least two different and separate processes—for provider and consumer.
• Rather than leaving developers to discover individual services and put them into context, the Business Service Bus is instead their starting point that guides them to a coherent set that has been assembled for their domain.

References

[1] M. Page-Jones, The Practical Guide to Structured Systems Design, 2nd ed., Prentice-Hall, 1988.

[2]. J. Martin and C. McClure, Structured Techniques for Computing, Prentice-Hall, 1985.

[3] M. Page-Jones, The Practical Guide to Structured Systems Design, 2nd ed., Prentice-Hall, 1988.

[4] Bell, Michael, "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. pp. 3, 2008.

[5] Channabasavaiah, Holley and Tuggle, Migrating to a service-oriented architecture, IBM DeveloperWorks, 16 December 2003.

[6] Enterprise SOA. Prentice Hall, 2005

[7] Brayan Zimmerli Business Benefits of SOA, University of Applied Science of Northwestern Switzerland, School of Business, 11 November 2009

[8] "SOA services still too constrained by applications they represent". zdnet.com. 2009-06-26.

[9] Erl, Thomas. Serviceorientation.org – About the Principles, 2005-2006

[10] SOA Manifesto Official Website Date Accessed: 25 November 2010.

[11] Service Oriented Architecture, Randy Heffner & Larry Fulton, Forrester Research Inc, May 2006

[12] Emerging SOA Standards: SCA/SDO And JBI Multiple Alternatives Aim To Ease SOA Implementation, Mike Gilpin, Forrester Research Inc., March 2006