CSC/ECE 517 Fall 2009/wiki2 16 agummad

Abstract

Service-oriented Architecture, abbreviated SOA represents a new generation of distributed computing platform. As such, the architecture spans many things that were developed alongside the development of the architecture itself, such as its own design paradigms and design principles, design pattern catalogs,pattern languages, a distinct architectural model, and related concepts, technologies, and frameworks. The article provides a brief overview of the principles of SOA and weighs in the salient features of its architectural design patterns.

Introduction

SOA is essentially a collection of services. These services operate in the general sense by effectively communicating with each other. This communication could fall within a broad range of possibilities from exchanging information in the form of data or coordinating and interoperating with each other to implement a combination service. Thus there must be standardized ways that facilitates communication between such services[1]. These services are now architect-ed or rather combined in such a way that they encourage interoperability, loose coupling and extensibility of the services that play their respective roles as ingredients of the bigger service[1].

Principle of Operation

In a typical SOA arrangement, a service consumer sends a service request message to a service provider. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. A service provider can also be a service consumer.

Extending this principle, SOA attempts to fabricate an architectural model that aims to enhance the efficiency, and productivity of an enterprise. They do this by "positioning services as the primary means through which solution logic is represented in support of the realization of the strategic goals associated with service-oriented computing" [1].

Thus, within an SOA, services that make up blocks of the architecture are made up of of unassociated, loosely coupled units of functionality. Each service implements one specific one action, for example, automated filling in of applications or viewing of a bank statement, or placing an online booking or airline ticket order. For communication mechanisms between individual services, instead of services embedding calls to each other in their source code, a more generic approach for communication is used. These services use defined protocols that describe how services exchange and parse messages, using description meta-data. We will explore the importance of meta data in a following section.

To make this assorted mixture of functionality work, the developer now associates software functionality - the services in a non-hierarchical arrangement (in contrast to a class hierarchy) using a software tool that contains a complete list of all available services, their characteristics, and the means to build an application utilizing these sources. This process is called orchestration of services.

Importance of Meta-Data

For all these layers of functionality and different services to inter operate seamlessly, one would rely on meta data to describe not only the characteristics of each of these services, but also the data that flows between them and makes them work. For this purpose initial implementations used XML extensively in SOA to structure data as it flows from one service to another.[4] In later implementations, WSDL describe the services themselves, while SOAP describes the communications protocols. Based on the history of working with various description languages to facilitate metadata transfer between different services, the following are the ideal criteria identified for metadata[4],

• The metadata should come in a form that software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity.
• The metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort.

The goal of having an SOA is to allow users to combine together, linearly or otherwise, fairly large chunks of functionality from existing services to form ad-hoc applications. The larger the chunks of the functionality, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may prove a harder case for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of implementing an architecture like this is that the marginal cost of creating the nth application in the combination is low, as all of the software required already exists to satisfy the requirements of other applications.

Web Services and their Relationship to SOA

Modern web services implement a service-oriented architecture. Web services in their general mode of operation, attempt to make typical services, serving as functional building-blocks for a larger combination, accessible over standard Internet protocols. Since the operation is over-the-internet, the combination is independent of platforms and programming languages. Each SOA building- block service can play one or both of the following roles:
Service Provider
: The service provider creates a web service. He would also publish its interface and access information to the service registry. Each provider must then decide which services to expose and makes decisions about use charges, security easy availability etc[4].
Service requester
The service requester or Web service client locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its Web services. Which service the service-requesters need, they have to take it into the Brokers, then bind it with respective service and then use it. They can access multiple services, if the service provides multiple services.[4]

SOA Patterns

Significance of Patterns

Patterns in general provide a proven solution to a common problem that is individually documented in a consistent format and usually as part of a larger collection[1] Design pattern are now a fundamental part of architecting various IT related services. In its simplest sense , these patterns provide common reusable ways to solve general problems that come up in implementing/ IT products by virtue of better design. Patterns in the IT world that revolve around the design of automated systems are referred to as design patterns.

Thus, an IT design pattern is not a finished end – of – the – line design that can be transformed directly into code. Rather, It provides a description or a template about how to solve a problem, and therefore this template that can be used in many different situations. 
Design patterns are helpful because they represent field-tested and industry – accepted solutions to common design problems, and since their quality is prove, their consistent application tends to naturally improve the quality of system designs.

• Provide a methodology to organize design knowledge and decision making intelligence
• By virtue are repeatable templates which can be put to use by most IT professionals involved with design.
• Are extensively used to ensure consistency in how IT systems are designed and built
• Can be used as educational aids by documenting specific aspects of system design (regardless of whether they are applied)
• Are usually flexible and optional (and openly document the impacts of their application and even suggest alternative approaches)
• Enrich the vocabulary of a given IT field because each pattern is given a meaningful name




These patterns are not specific to any language, vendor, platform or industry, these are simple techniques that help in overcoming well documented problems faced while attempting to achieve the strategic goals associated with SOA. The SOA design patterns collectively “master pattern language”. This allows a framework where patterns can be effectively combined in various combination and sequences. We highlight key design pattern types for the SOA architecture and provide examples patterns for each type. These can be found enumerated in [3]. The reader is encouraged to go through the entire catalog of service patterns.

Patterns for Collection of Services

A service inventory represents a collection of independently developed and standardized services, These services according to service orientation such that they become interoperable. This architecture allows a pool of services that can be used to assemble and augment compositions of services repeatedly.

Inventory Boundary Patterns

One of the biggest decisions a project team faces when starting an SOA initiative is determining the appropriate scope of a service inventory is probably one of the most critical decisions that are taken by a project team before starting an SOA initiative. The Enterprise Inventory and Domain Inventory design patterns help address this decision making process by providing alternative approaches for the problem. The Enterprise Inventory pattern establishes an enterprise-wide service inventory. Implementing this pattern guarantees that all of the services will be owned and evolved by the same group or department, which is the ultimate in centralized governance.Although ideal, this approach is often not realistic, especially for larger organizations.

The Domain Inventory pattern is an alternative pattern which encourages the approach whereby the enterprise is divided into segments (domains), each of which represents a meaningful scope. Services delivered into this architectural segment are subject to the same design standards and governance practices, allowing them to be evolved independently from neighboring domain inventories in the same enterprise. Although the use of this pattern can introduce the need for a cross-domain data model to facilitate inter-operation between domains, additional patterns (such as Cross-Domain Utility Layer, Dual Protocols, and Inventory Endpoint) that help reduce this impact.

Inventory Structure Patterns

Regardless of its scope, within the boundary of a service inventory, certain design patterns are applied to ensure a consistent structure and service orientation. For example, Logic Centralization positions reusable services as the sole or primary contact points for the logic they represent. This is further supported by the Service Normalization pattern that fosters service autonomy by reducing the amount of functional overlap between individual service boundaries to establish more of a “normalized” inventory.

The Service Layers pattern (and related, specialized layer patterns) can be used to further organize a service inventory into a set of logical layers, each of which is based on a different classification of service.

Patterns for Service Design

Each service within the SOA maintains its individuality and exists as a standalone software program, autonomous yet still fully geared to participate in larger service aggregations. When designing a service architecture, numerous challenges need to be taken care of, especially when shaping this architecture according to service-orientation design principles, such as Service Statelessness and Service Loose Coupling.

Fundamental Service Design

The established “separation of concerns” theory needs to be applied at the very basic level of service design ( this principle applies to the design of every computer program in general)This theory explains that a larger problem is decomposed into its constituent parts in a methodical way such that we can clearly identify how corresponding solution logic should be partitioned into services. To accomplish this within service combination in the SOA, a series of base patterns have emerged. These patterns now form a fundamental "pattern language" as explained above. Examples of these basic patterns are Functional Decomposition and Service Encapsulation, both of which help determine what type of logic does and does not belong in a service.

Service Implementation Design and Governance

Service Façade is a key design pattern that is frequently applied to the initial design of the service architecture. This pattern "wedges a component between the service contract and the core service logic to establish a point of abstraction"[3]. This establishes an architectural foundation which can be used by other more specialized SOA patterns.

For example, Service Decomposition (one of the service governance patterns) allows a coarse-grained service to be split up subsequent to its deployment. Other governance patterns, such as Proxy Capability and Distributed Capability ensure that this decomposition of one service into two or more does not impact the contract (technical interface) of the original service.

Service Contract Design and Governance

A key design pattern that helps increase the longevity of service contracts is Contract Denormalization. This pattern basically explains how capabilities with overlapping functional scopes can be added to a service contract without badly affecting service or inventory architectures.

Alternatively, multiple groups of consumers can be accommodatedby the Concurrent Contracts pattern. This pattern describes how entirely separate contracts can be created for the similar service logics. These kinds of scenarios occur due to security restrictions or a need to split up policy alternatives for governance.Part of these governance patterns includes various contract versioning design techniques to minimize the impact of having to introduce new contract versions or support multiple versions of the same contract.

Challenges in adopting SOA

Albeit the advantages of SOA, the adoption of its architectural and design priciples are not trivial. Some of the challenges that exist are enumerated below.

• One of the common challenges faced involves managing messages generated by each service. SOA-based environments can include many services that exchange messages to perform tasks. Depending on the design, a single application may generate millions of messages. Managing and providing information on how services interact is a complicated task.
• Another challenge is the lack of testing in SOA space. There are no tools sophisticated enough to provide testability of all the services in a typical architecture
• Another challenge relates to providing appropriate levels of security. Security models built into an application may no longer suffice when the capabilities of the application are exposed as services that can be used by other applicationsAs SOA and the WS-* specifications practitioners constantly expand, update and refine their output, there is a shortage of skilled people to work on SOA-based systems, including the integration of services and construction of services infrastructure.

SOA efforts are routinely initiated by internal IT delivery organizations, and some of these improperly introduce concepts to the business so it remains misunderstood. The adoption starts meeting IT delivery needs instead of those of the business, so the result is an organization with superlative laptop provisioning services, instead of one that can quickly respond to market opportunities. Business Leadership also becomes convinced that the organization is executing on SOA well.

Criticisms of SOA

Most of the criticisms of SOA draw from the assumption by most people that SOA is just another term for Web Services. For example, some critics of SOA observe that adoption of SOA strategies results in introducing XML parsing and composition. In the absence of native or binary forms of Remote Procedure Call (RPC), applications could run slower and require more processing power, increasing costs.

• Another factor critical to the development of SOA is that WS-* standards and protocols (WSDL and the like) are still evolving (e. g., transaction, security), and therefore the adoption of SOA may be introducing potential risks
• Some critics also feel SOA is merely an obvious evolution of currently well-deployed architectures (open interfaces, etc).
• The ability to easily modify systems is sometimes omitted from IT system design. Many systems, including SOAs, hard-code the operations, goods and services of the organization, thus restricting their online service and business agility in the global marketplace.

References

1. www.socpatterns.com – Edited by Thomas Erl
2. www/whatissoa.com – Edited by Thomas Erl
3. Introducing SOA Design Patterns – Thomas Erl
4. Wikipedia.com

Appendix

:

• A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services
<
• WSDL: Web Service Description Language - similar to XML but nextgen of transferring metadata
• SOAP: Simple Object Access Protocol
• metadata : Data about data
• RPC : Remote Procedure Call