CSC/ECE 517 Fall 2010/ch6 6j ss

Service-Oriented Architecture }| A few years ago, it was realized that eventually software capabilities are going to be delivered and consumed as services. Implementing them as tightly coupled systems was definitely an option, but, a service-based interface was required between the point of usage to the portal, device or another end-point. Thus, there was the need of a service-oriented architecture that would facilitate the management of delivery, acquisition, consumption etc in terms of services that are related. This hinted at changes in how software life cycle is managed —right from requirements specifications as services, designing these services, acquisition and outsourcing in the form of services, asset management of services, and so on. Thus, after moving from modules to objects, to components, now was the time to move to services. This wiki chapter aims at providing an introduction to the vast and growing field of Service Oriented Architecture. The chapter also discusses the different design patterns[1] currently in practice for the field of Service-Oriented Architecture. The utilization of the concepts of coupling[2] and cohesion[3] in Service-Oriented Architecture are described. SOA is contrasted with a similar concept called Enterprise Architecture. Introduction Service-oriented architecture (SOA) is a collection or set of services communicating with each other. Two or more services can communicate either via a simple data passing system or could be coordinating on some activity. For these kind of communications to be possible between the services, some means to connect the various services is required. Service-oriented architectures were existing in the past and are not a new thing. Many people are familiar with the use of DCOM [4] or Object Request Brokers (ORBs) [5] which are based on the CORBA[6] specification.These are the first service-oriented architectures deployed for practical applications. The following section gives a brief description about the evolution of SOA: Evolution of SOA In many respects, SOA is an evolution based on the component-based development (CBD). It, in fact, is a quantum leap in bringing business and information technology into closer alignment by supporting business processes. The SOA services are made visible to the consumer, but, the underlying components are kept transparent. The Internet and XML standardization efforts demanded a service definition and description published by a service provider (SP) that could be located and invoked by a service consumer (SC). The service description can be implemented by different service providers, each offering various choices of qualities of service (QoS). The invocation can be across Internet or intranet in a distributed object connotation and standards such as WSDL[7] and SOAP[8] have been created. The roles of SC and SP are illustrated in the following figure: Figure 1: Service Provider and Service Consumer in a SOA Terminologies Services A service is a specific function (business function). For instance, analyzing an individual's credit history or processing a purchase order. It can either provide a single discrete function, such as converting one type of currency into another, or it can perform a set of related business functions, such as handling the various operations in an airline reservations system. Services performing a related set of business functions are said to be coarse grained. Multiple services work in a coordinated way. This aggregated service can be used for a more complex business requirement. Connections Web services is the most likely connection technology of SOAs. Web services essentially use XML to create a robust connection. A web service can be defined as a service that communicates with clients through a set of standard protocols and technologies. These are standardized and are implemented in platforms and products from various vendors, giving clients and services an opportunity to communicate in a consistent way across a wide spectrum of platforms and operating environments. The important concept is service. Web Services are the set of protocols by which Services are discovered, published and put to use in a technology neutral, standard form. Service Oriented Architecture Often is the case that one person's needs being met by capabilities offered by someone else. In the world of distributed computing, this scenario can be thought of one computer agent’s requirements being met by a computer agent belonging to a different owner. A one-to-one correlation is not not necessarily needed between these needs and capabilities. SOA is a view of architecture focusing on services as the action boundaries between the needs and capabilities in order to service discovery and re-purposing. Thus, Service Oriented Architecture (SOA) can be defined as a paradigm for organizing and utilizing distributed capabilities that may be in different ownership domains and implemented using various technology stacks. SOA is not only an architecture of services (seen from a technology perspective). It includes the policies, practices, and frameworks to ensure the right services are provided and consumed. Example This example depicts how an information system scenario could benefit from a migration to SOA. Consider an organization that has an application using three business processes using the same functionality. Figure 2: Three business processes within one company duplicating functionality The main disadvantages in the above scenario are: The company pays to implement the same functionality multiple times. Maintainence issues : Consider the situation wherein, a manager wants to deny a user access to all three processes.This requires three different procedures (one for each of the applications). This system can be made efficient if common tasks are shared across all three processes. This requires decoupling the functionality from each process or application and making a standalone authentication and user management application that could be accessed as a service. Thus, the service itself is being repurposed, and, applications and the company owning it can now have a central point for maintaining it. This shows a simple example of Service Oriented Architecture in practice. The following diagram depicts the same: Figure 3: Three business processes repurposing one service for common tasks Discussion Benefits of SOA The following are the primary reasons which encourages an enterprise to take SOA approach: Reusability: SOA allows reuse of business services by enabling developers within an enterprise and/or across enterprises to take the code developed for existing business applications, convert them as web services, and then reuse it to meet new business requirements. This results in huge savings in the cost and time for application development. The more business services get built and get incorporated into different applications, the more are the benefits of reuse. Interoperability: One of the main objectives of SOA is to allow clients and services to communicate and understand each other independent of the platform they use. This objective is met when clients and services have a standard and consistent way of communicating with each other. Web services are used for this purpose. Scalability: SOA stresses on having few dependencies between the requesting application and the services it uses. Thus, services tend to be coarse-grained, document-oriented, and asynchronous. Coarse-grained services have the advantage of offering a set of related business functions, a document-oriented service accepts a document as input instead of a numeric value or Java object and an asynchronous service doesn't require the client to wait while it performs its processing. This relatively limited interaction from a client for communicating with a coarse-grained, asynchronous service, provides the scope for applications using these services to scale without increasing the communication load on the network. Flexibility: SOA discourages sharing semantics, libraries, and often sharing state. This makes it easier for the application to evolve and keep up with changing business requirements. Cost Efficiency: As SOA is a standards-based approach, it results in less costly solutions since the integration of clients and services doesn't require the in-depth analysis and unique code of customized solutions. Also, because ervices ins an SOA are less costly to maintain and easier to extend. Also many enterprises have a lot of the Web-based infrastructure for a web services-based SOA, further limiting the cost. The biggest cost saving of all comes from the reusability feature of SOA. Agility: Services can now be delivered quickly and need not depend on the larger projects common in the organization. The business can understand systems and requires simpler user interfaces calling on services. This in turn, speeds up the time-to-market. Promotes good design as the service is designed independent of who its consumers are or will be. Eases documentation and testing by separating them from the issues of the implementation. It should be noted that SOA doesn't provide the bebefits mentioned below: Simple software engineering Free integration or interoperability Technology independence Vendor independence The ultimate architecture for the modern enterprise Challenges Maintaining metadata related to the services is difficult as each service involves various messages used in communicating and an application can involve many such services, generating a huge number of messages. Also, services are delivered by different organizations within the company or different companies and this needs SOA Governance. SOA space lacks testing. This indicates that investment is required in a testing framework that would help find the culprit in the architecture. As more services get added for extensibility of the system, security models might require changes. Coming up with appropriate levels of security is a concern. SOA with Web Services result in addition of XML layers, requiring XML parsing and composition. Applications run slower and require more processing power when used without Remote Procedure Calls(RPC) [9] and thus, increase costs. SOA Principles There is a set of 10 principles for SOA. The first four are based on Don Box's four tenets. These principles are as listed below: Explicit boundaries: Services are inextricably tied to messaging in that the only way into and out of a service are through messages. This means that everything a service would require for its functionality should be passed to it when it is invoked. Shared Contract and Schema, not Class: The service consumer and a service provider involved in the contract should have everything they need to consume or provide the service and should not rely upon each other for any kind of reuse. Policy- Driven: Since a service can be accessed from various consumers, a policy mechanism is needed. The functional aspects are described in the service interface, and, policies specify the orthogonal, non-functional capabilities and needs. Autonomous: It should be possible to change and deploy, version and manage services independent of each other. The consumers need not quickly adapt to the new version. Wire Formats: A service must be accessible independent of the platform, as long as the platform supports the exchange of messages adhering to the service interface and policies. Document-Oriented: Documents are used to send data to interact with services. These documents might contain redundant information. Loosely-Coupled: As far as possible, components must be loosely coupled which enables extensibility, easier maintainence and a better system. But it is not always possible. Standard-complaint: Standards for technical aspects like data formats, metadata, transport and transfer protocols etc, must be followed. Vendor Independent: It should be possible to build a service provider or service consumer using any technology supporting the appropriate standards. Metadata - Driven: The metadata artifacts in the SOA should be discoverable, retrievable and interpretable at both design and run time. Design Patterns in SOA Design Patterns describe common problems with their solutions that can be applied repeatedly under a set of constraints. The collection of SOA design patterns forms a master pattern language applicable in various combination and sequences. Compound patterns comprising of multiple individual patterns is also possible. SOA has a huge number of design patterns which can be divided into the following categories: Foundational Inventory Patterns Logical Inventory Layer Patterns Inventory Centralization Patterns Inventory Implementation Patterns Inventory Governance Patterns Foundational Service Patterns Service Implementation Patterns Service Security Patterns Service Contract Design Patterns Legacy Encapsulation Patterns Service Governance Patterns Capability Composition Patterns Service Messaging Patterns Composition Implementation Patterns Service Interaction Security Patterns Transformation Patterns Common Compound Design Patterns A more elaborate list and description of these patterns is available at SOA website[10]. As it can be seen, the SOA design pattern catalog is very broad. These patterns provide design techniques ranging from adjusting minute validation logic in a service contract to design strategies and help structure pools of services across an entire enterprise. An SOA initiative requires attention to the various design details associated with every service delivered, while not loosing the big picture. Design patterns help maintaining this balance by helping overcome common obstacles that have historically inhibited or derailed SOA project plans. Working with SOA patterns Here are a few guidelines for utilizing the SOA design patterns to their maximum extent: Patterns should be viewed with a Strategic Context Governance has to be considered Patterns can be applied to various extents Some patterns can be evolutionary Patterns can relate to other patterns Every pattern is not suitable for everyone Coupling in SOA Coupling specifies the degree of dependency between 2 or more modules. As we know, coupling can be classified as Loose Coupling and Tight Coupling. Loose coupling can be defined as the state in which the impact of change (change in consumers, providers, or cross-cutting policies) is minimized across dependencies. Loose coupling is important across units of deployment, whereas tight coupling is sufficient within a unit of deployment. The essence of SOA is building composite distributed systems efficiently. In order for the distributed components to be reusable, reliable, available, scalable and fault tolerant, an appropriate level of loose coupling is needed. The impact of any change or modification and failures should be minimum on the landscape of a system as a whole. Loose coupling provides this property by defining and describing interaction patterns between components and technologies involved. Loose coupling also brings the advantage of versionability in SOA. If A and B depend on each other, loose coupling is needed only when A may version independently from B. That is, if A and B are versioned together, loose coupling between them is unnecessary. Services in SOA require described interfaces. This provides a measure of loose coupling as the service dependency isn't a software to software dependency; rather it is N software to interface dependencies. This shows the importance of individual interface contracts. If an interface contract allows anything, then it has tight coupling between components. There is no one way to build useful distributed systems that are completely decoupled, rather a variety of choices have to be considered based on various aspects of the systems. A property of a system can become a trade-off compared to other properties. For example, an asynchronous service usually requires the client open up its address space for a "callback" which increases the coupling. Also, loosely couple Web Services wait for messages via queuing mechanism before taking action. A large number of such services would be required to exceed the system load. So, tight coupling them can be considered. New mechanisms to switch loosely coupled Web Services to tightly coupled Web Services to avoid system overloads of scarce resources are being considered. In summary, Loose coupling manifests itself in the SOA paradigm as follows: Creates an abstraction layer between the service producers and service consumers. Promotes flexibility in making changes to the service implementation without impacting the service consumers. In the SOA approach, functionality is organized as a set of modular, reusable shared services that have well-defined interfaces and encapsulate the key rules for accessing the services. They're also built without making any assumptions of who will use or consume these services. Cohesion in SOA Cohesion is defined as the measure of the relationship between the functionality expressed aby a module and the module itself. It is contrasted with the concept of coupling. High cohesion correlates to loose coupling. Cohesion can be classified into various types. Below mentioned are the three "good" types of cohesion identified over the years: Functional Cohesion: An individual module does only one thing, resulting in low coupling and reusability. Sequential Cohesion: A module carries out several ordered tasks. Communication Cohesion: A module carries out multiple operations based on the same input and lacks any prescribed ordering requirements. The following are identified forms of "bad" cohesion: Procedural Cohesion: This is similar to Sequential Cohesion with different data to work on for each task. Temporal Cohesion: A module's tasks are related only by time. Logical Cohesion: Modules sharing common implementations are grouped. Coincidental Cohesion: A module's tasks are related only when residing in the same module. In today's vernacular, low cohesion is termed as coarse-grained. "Buy a car" and "run credit history" are examples of two such coarse-grained services offered in an SOA. SOA's success requires adopting "course-grained" services that can be plug-n-played with other sources interchangeably. But it is very much possible that within coarse-grained services, such as buy a car, there may be smaller or finer-grained services like Check Inventory, Schedule Detailing, etc. that make up the larger service, buy a car. Thus SOA and high cohesion as a principle aren't incongruent with each other. High cohesion is rather the foundation of creating coarse-grained services which is the fundamental element of creating a successful SOA implementation. Enterprise Architecture Vs SOA An enterprise architecture (EA) is defined as a conceptual blueprint defining the structure and operation of an organization. The enterprise architecture determines how an organization can achieves its current and future objectives effectively. An enterprise architecture has the following four perspectives: Business perspective: This defines the processes and standards used by the business on a day-to-day basis. Application perspective: This defines the interactions among the processes and standards used by the organization. Information perspective: This defines and classifies the raw data (such as document files), that the organization requires. Technology perspective: This defines the hardware, operating systems, programming, and networking solutions used by the organization. Such an EA offers the following benefits: Better decision making. Organizations can adapt better to changing demands or market conditions. Eliminates inefficient and redundant processes. Optimizes the use of organizational assets. Minimizes employee turnover. Both SOA and EA are used for the benefit of the organization. These two concepts are often confused. The following section discusses how these two concepts are similar, and how they differ. Similarities and Differences between SOA and EA The different domains in SOA and EA architecture overlap. But the domains in SOA are a subset of that of EA. For instance, SOA models and develops services and the components that realize them, while the EA architecture deals with SOA-specific artifacts along with other components, packages, and systems for the whole enterprise. The following table shows the mapping between the architecture domains of SOA and EA: ARCHITECTURE DOMAIN SOA STACK EA FRAMEWORK Business Business process Business architecture Applications Services and components Appliaction architecture Operations Quality of Service, security, monitoring, and infrastructure Technology architecture Data Data architecture Information architecture Integration and Middleware Integration architecture / ESB Technology architecture The following are the similarities between SOA and EA: Both address similar architectural domains. Both intend to align IT closely with business. Both require input based on business objectives. Both involve similar strategies and planning activities. While EA architecture domains focuses on the macro level, the SOA architecture domains work on a micro level. To be specific, EA tends to focus on defining business components, while SOA focuses on business services. EA deals with application frameworks and enterprise applications and SOA with only service modeling. EA deals with enterprise-level infrastructure including servers, databases, etc. while SOA is for the Enterprise Service Bus. EA addresses enterprise integration patterns and when they should be used. SOA provides a services based integration approach. Role of SOA in EA As we can see from the above section, though both SOA and EA serve the same purpose, SOA is not same as EA. Instead, SOA can play a role in most of the domains/perspectives of an EA. SOA is one of the best tools for the success of EA projects. SOA bridges EA with the solution architecture and implementation by using layered service components across business and application models, and technology implementation. SOA helps EA to overcome its challenges. Some of these challenges are as listed below: Reduced stakeholder participation. Modeling the Big picture. Producing meaningful models and conceptual abstractions. Difficulties in EA management life cycle and governance. Thus, for the smooth and efficient working of an EA, SOA should be an integral part of the EA. Service Oriented Enterprise, Service Oriented Applications/Systems and Service Oriented Infrastructure are a few examples of how SOA can be adopted in an EA.