Service Oriented Architecture (SOA

)

Subject Incharge Pratidnya S. Hegde Patil
1

Books
Text Book
1.

Service-Oriented Architecture (SOA): Concepts, Technology, and Design by Thomas Erl

Reference Books
1.

Service Oriented Architecture (SOA) For Dummies, 2nd Edition by Judith Hurwitz, Robin Bloor, Marcia Kaufman, Fern Halper Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services (The Prentice Hall Service-Oriented Computing Series from Thomas Erl) by Thomas Erl SOA Using Java Web Services by Mark D. Hansen

2.

3.

2

1

A CD Player Example
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.
3

Put Another Way
How would you rather pay the bill for your paper delivery? The paperboy comes to the door, demands $2 for that week's paper. Do you... 1) Tell the paper boy where your wallet is, turn around to let the paperboy get your wallet out of your back pocket, he pulls $2 out of your wallet, closes it, puts it back in your pocket. OR 2) Give him $2. -Source, IEEE
4

2

What Does that Mean?
SOA is built on loose-coupling. How do you do that? Tell objects what to do, don't ask them for their state! Clients want the $2--the paper boy doesn't care if it's in your cookie jar or your wallet or in a check or quarters or a $2 bill or 2 singles Systems are the same--objects are microcosms of systems! Queries must be free of side effects: Either Command OR Query--not both! Decoupling is a Good Thing! 5

Focus on the Business– Process and Services
Business process layer

Services interface layer

orchestration service layer business service layer application service layer

Application layer

.NET

J2EE

Legacy
Source: Service-Oriented Architecture, Thomas Erl

6

3

Foreign currency exchange. 7 Several tellers may offer the same set of services to provide load balancing and high availability. Different tellers may offer different services. Typical services include: Account management (opening and closing accounts). The services are provided to the customer via the tellers. Withdrawals. inquiries about terms and conditions. 8 4 . and transfers. Processing a complex transaction may require the customer to visit several tellers and therefore implement a business process flow. The services implemented by the IT systems must match and support the services provided by the tellers. and some tellers may be specifically trained to provide certain types of services to the customer. Behind the counter are the IT systems that automate the bank’s services. as long as the service is completed. Loans (application processing. What happens behind the counter does not matter to the customer. accepting payments).What are Services? Bank tellers provide services to bank customers. deposits.

and over the Web. 9 10 5 . ATMs. The services are designed and deployed to match the services that customers need. or Web users from their PCs. it’s the service that’s important.A consistent approach to defining services on the IT systems that align with business functions and processes makes it easier for the IT systems to support the goals of the business and adapt more easily to providing the same service through humans. The same service can be accessed from customers at the ATM. tellers on the office network. The implementation environments for the services don’t matter. Two or more services can easily be combined to create another service.

” 12 6 . 11 Business View . Deploying services in the context of an SOA makes it easier to compose services into simple as well as complex applications. or application logic.Services (SO of SOA) The enterprise architecture perspective should be focused on the business needs in order to make sure IT serves the business and not vice versa. reusable services on an IT network. is made available to SOA users. and are invoked by messages.Conclusion of the bank example The definition of software services aligns with the business services that a bank offers to ensure smooth business operations and to help realize strategic goals such as providing ATM and Web access to banking services in addition to providing them in the branch office. or consumers. as shared. “SOA is a conceptual business architecture where business functionality. which can also be exposed as services that can be accessed by humans and IT systems alike. “Services” in an SOA are modules of business or application functionality with exposed interfaces.

Architecture (A of SOA) SOA is commonly thought of as an architecture or an architecture style that builds on loosely coupled. Followed by defining services to represent these “areas”. interoperable and composable components or software agents called services. 13 Technical View . Services expose their capabilities through message interfaces. 14 7 . Services have well-defined interfaces based standard protocols (usually web-services but most definitions mention that it is not the only possible implementation) as well as QoS attributes (or policies) on how these interfaces can be used by Service Consumers.In a NutShell From the business point of view SOA is : About analyzing the business to identify business areas and business processes. The services can then be choreographed or orchestrated to realize the business processes. SOA definitions mention the basic communication pattern for SOA is request/reply but many definitions also talk about asynchronous communications as well. The goal of SOA is to increase the alignment between business and IT and achieve business agility – the ability to respond to changes quickly and efficiency.

These services have well-defined interfaces that encapsulate the key rules for accessing the services. and message orientation to solve these business problems. functionality is organized as a set of modular. partners. resulting in systems that were often tied to the features and functions of a particular execution environment technology such as CICS. In the SOA approach. the services that an organization provides to clients. J2EE. Previous approaches require you to focus more on the use of a specific execution environment technology. Whereas service orientation lets you focus on the description of the business problem and services are developed better which aligns them with solving business problems. and other organizations) are the key organizing principle used to align IT systems with the needs of the business. IMS. citizens. reusable shared services.Loose coupling manifests itself in the SOA paradigm as follows: It helps to have an abstraction layer between the service producers and service consumers. procedure orientation. they are loosely coupled to the consumer of these services. Thus. Loose coupling promotes flexibility in changing the service implementation without impacting the service consumers. They're also built without making any assumptions of who will use or consume these services. customers..e. Whereas in SOA business services (i. employees. CORBA. 16 8 . 15 Earlier Approaches vs SOA Earlier approaches to building IT systems tended to directly use specific implementation environments such as object orientation. and COM/DCOM.

reusable services. and auditing are instead implemented using services. but it also reduces the management. Separating the service description from its technology implementation in SOA means that businesses can think about and plan IT investments around the realization of operational business considerations. 18 9 . When new applications can be assembled out of a collection of existing. or credit checking. the best value for effort can be realized (that is. more so than the capabilities of any individual product or software technology chosen to execute the description. It’s easy to understand the benefit of reusing common business services such as customer name lookup. as well as typical system functions such as security checks. and support burden by centralizing the deployed code and managing access to it. In SOA-based applications. In a pre service oriented development environment. by composing existing services. maintenance. as represented by the description. 17 Earlier Approaches vs SOA The real value of SOA comes from the later stages of deployment. Using services not only reduces the amount of deployed code. when new applications can be developed entirely. these functions might be performed by reusable code libraries or class libraries that are loaded or linked into new applications. Whereas in SOA due to separating the service interface from the execution technology. or almost entirely. the lowest cost and fastest time to results and best ROI).Earlier Approaches vs SOA Previous implementations of SOA were based on a single execution environment technology. common functions such as these. ZIP Code validation. transaction coordination. allows IT departments to choose the best execution environment for each job (whether it’s a new or existing application) and tying them together using a consistent architectural approach.

20 10 . which are composed of messages at discoverable addresses called endpoints. The Service’s behavior is governed by policies which are set externally to the service itself.Service-Oriented Systems Require a Different Development Approach 19 Defined (SOA) Service Oriented Architecture as an architectural style for building systems based on interacting coarse grained autonomous components called services. Each service expose processes and behavior through contracts.

“A facility supplying some public demand. and manifest self healing properties.SOA Components 21 Service The central pillar of SOA is the service. Services should be coarse grained pieces of logic. Autonomy means the services should be self-sufficient. 22 11 . at least to some extent. Service should satisfy autonomy. A Service should implement at least all the functionality promised by the contracts it exposes.” Characteristics : A Service should provide a high cohesion (focus onn a single well-defined requirement) and distinct function.

like to interfaces of object in object oriented languages. between a predefined group of parties. a specific place where the service can be found and consumed. that is. A specific contract can be exposed at a specific endpoint. a URI.Contract The collection of all the messages supported by the Service is collectively known as the service's contract. 24 12 . meaning a closed set of messages the service chooses to provide. A contract might also be multilateral or bilateral. The contract can be considered the interface of the Service. Characteristics : The contract can be unilateral. 23 Endpoint The Endpoint is an address.

SLA etc. Policy represents the conditions for the semantic specification availability for service consumers. Ex : http GET messages (part of the REST style) . correlated messages pattern) or handle security better (see Firewall pattern). authentication. The unique aspects of policy are that it can be updated in run-time and that it is externalized from the business logic. 26 13 .Message Unit of communication in SOA. auditing. Id etc. 25 Policy Policy separates dynamic specification from static/semantic specification. Has a header and body. The existence of the header allows for infrastructure components to route reply messages (e. The Policy specify dynamic properties like security (encryption. even SMTP messages are all valid message forms.g.SOAP messages.) .

contract which is the collection of the messages. composable components. The focus on interfaces is what gives SOA the ability to create loose coupling. endpoint where the contract is delivered and policy which governs the behavior of the endpoint. 28 14 . 27 Emphasis on Interface SOA has a total of four different components that deal with the interface : messages which are the parts of the interface.Service Consumer A service consumer is any software that interacts with a service by exchanging messages with the service. Consumers can be either client applications or other “neighboring” services. reuse and achieve the various design goals. Their only requirement is that they bind to an SOA contract.

and invocation of services. but not exclusively. in which Services provide reusable business functionality. Protocols are predominantly. Service consumers are built using functionality from available services. composition. message-based document exchanges. 29 Services 30 15 . developing. deploying and managing systems.SOA Service-oriented architecture is a way of designing. An SOA infrastructure enables discovery. Service interface definitions are first-class artifacts.

Services and Cost Efficiency 31 Services and Agility 32 16 .

Services and Adaptability 33 Services and Legacy Leverage 34 17 .

Service Invocation Services are invoked and service code is executed.Components of a Service Oriented System 35 Three Basic Operations to Support ServiceOriented Systems Service Discovery Services repositories are queried for services with desired characteristics. 36 18 . Service Composition Applications/service consumers are built by integrating functionality provided by services.

automated discovery and use. In a service oriented approach. and an optional service directory. or services. web-based technologies as the standard building blocks for enterprise integration. the complete value chain within the company is divided into small modular functional units.Motivation for Service Oriented Architecture (SOA) Rapidly-changing business environment Ubiquity of the Internet & WWW has led to emergence of platform-independent. Application-to-application messaging is used in the information exchange. service. Companies and their sub-units should be able to easily provide services. There is an increase trend for sharing resource/data both within companies and among companies in a flexible/standardized manner. A service oriented architecture focuses on how services are described and organized to support the dynamic. 38 19 . Other business units can use these services in order to implement their business processes. 37 SOA Architecture A basic SOA architecture is composed of a service provider.

39 Actors of SOA A “service” is the atomic unit of SOA. location transparent business service. a service requester. Publishing is done by posting the service information on the service registory. • Service Consumer: Consumer of services matching his or her business need found in a service directory. It encapsulates a business process. 40 20 . • Service Provider: Provider of services whose invocation contract and location are published & provide a stateless. Benefits : Flexible. searches the service directory for one that meets the necessary criteria.SOA Architecture First the service provider creates a service and decides to expose it and publish it. the service requester is able to directly contact the service provider in the correct way to fulfill the business need. Scalable. • Service Registry: Directory for publishing and listing available services for consumers. Upon finding one and using the information available on the service registory. Replaceable. in need of a certain service. On the other side.

For example.e. Application developers or system integrators can build applications by composing one or more services without knowing the service’s underlying implementations. 42 21 .Net or J2EE.Requirements of SOA Interoperability between different systems and programming languages. the service interface is independent of the implementation.. What's key to these services is their loosely coupled nature. (Use standards. i. a service can be implemented either in . An application's business logic or individual functions are modularized and presented as services for consumer/client applications. and the application consuming the service can be on a different platform or language. platform independent) Clear and unambiguous description language Retrieval of the service Security 41 What is Service Oriented? Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications.

4.What is SOA? Conceptual view of SOA Web Client. Composable: facilitate the assembly of composite services. Services are composable that is reconcile the sub-operations into a single operation which is simply another form of reuse.NET CRM JAVA KMS System (Platform) 43 SOA Characteristics or Principles 1. Service offered by one web service provider can be reuse in a WebApp or another web service. 3. Service are not allowed to store the state information as it will not allow the service to be loosely coupled. Stateless: minimize retained information specific to an activity. Services are discoverable that is for example a service registry provides a discovery mechanism very much like a phone book allowing potential requestors to query and check for service providers. Enterprise Portal etc Application Frontend Business Process L J K A B C D E F G H I Services Software Component . Reusable: divide business logic into reusable services. Discoverable: self-described so that they can be found and assessed. 2. Rich Client. 22 . Web services are loosely coupled components which accelerates reuse.

Applications can look up the services in the registry and invoke the service. For the services to interact they need to share a formal contract. Services are autonomous that is self-governance and eliminating dependencies on other services. rules and characteristics of the service and its operation. Definition. and Integration (UDDI) is the standard used for service registry. Universal Description. Characteristics SOA services have self-describing interfaces in platform-independent XML documents. Autonomous: control the business logic they encapsulate. with little or no knowledge about the provider. Some of the key QoS elements are security requirements. every input and output message supported by each operation. Each SOA service has a quality of service (QoS) associated with it. Contractual: adhere to agreement on service descriptions. Abstract: hide the business logic from the service consumers. Communication among consumers and providers or services typically happens in heterogeneous environments. The service abstract the underlying logic of its implementation but provide access to its functionality or operation through interfaces. such as authentication and authorization. 23 . It is a condition wherein a service acquires knowledge of another service but still remaining independent of that service. reliable messaging. and policies regarding who can 46 invoke services. SOA services communicate with messages formally defined via XML Schema (also called XSD).SOA Characteristics or Principles Loosely coupled: minimizes dependencies between services. Messages between services can be viewed as key business documents processed in an enterprise. SOA services are maintained in the enterprise by a registry that acts as a directory listing. each service operation. that include : formal definition of service end point. Web Services Description Language (WSDL) is the standard used to describe the services.

Provides the option to make the services consumable across different channels. leverage existing investments in applications and application infrastructure to address newer business requirements. 47 Why SOA? SOA with its loosely coupled nature allows enterprises to plug in new services or upgrade existing services in a granular fashion to address the new business requirements. partners. Enterprises should quickly respond to business changes with agility. thereby safeguarding existing IT infrastructure investments.Why SOA? The reality in IT enterprises is that infrastructure is heterogeneous across operating systems. applications. system software. support new channels of interactions with customers. 48 24 . so starting from scratch to build new infrastructure isn't an option. Some existing applications are used to run current business processes. and feature an architecture that supports entire business. and exposes the existing enterprise and legacy applications as services. and suppliers. and application infrastructure.

49 A typical SOA infrastructure To run and manage SOA applications. and logging. 50 25 . This service architecture can provide a business rules engine that allows business rules to be incorporated in a service or across services. In addition. The service architecture also provides a service management infrastructure that manages services and activities like auditing. billing.To implement SOA. the architecture offers enterprises the flexibility of having agile business processes. enterprises need an SOA infrastructure that is part of the SOA platform. enterprises need a service architecture Several service consumers can invoke services by sending messages. An SOA infrastructure must support all the relevant standards and required runtime containers. These messages are typically transformed and routed by a service bus to an appropriate service implementation. and changes individual services without affecting other services.

Newer specifications such as Java API for XML Binding (JAXB). WSDL is used to describe the service. While SOAP is the default mechanism for Web services. used for mapping XML documents to Java classes.Net Though the J2EE and .SOAP. alternative technologies accomplish other types of bindings for a service. Java API for XML Registry (JAXR). while simultaneously interoperating with services across other platforms such as . 52 26 . and invoke the service using SOAP.Net platforms are the dominant development platforms for SOA applications. availability. A consumer can search for a service in the UDDI registry. and SOAP. bring a mature and proven infrastructure for scalability. is turning into another core piece required for service testing and interoperability. WSDL. as a transport layer to send messages between service consumer and service provider. used for invoking remote services in J2EE 1. WS-I Basic Profile WS-I Basic Profile. to register and look up the services. and performance to the SOA world. used for interacting with the UDDI registries in a standard manner.Net. SOA is not by any means limited to these platforms.4 facilitate the development and deployment of Web services that are portable across standard J2EE containers. get the WSDL for the service that has the description. provided by the Web services Interoperability Organization. and SOAP are the fundamental pieces of the SOA infrastructure. UDDI. Platforms such as J2EE not only provide the framework for developers to naturally participate in the SOA. and Java API for XML-based Remote Procedure Call (XML-RPC). UDDI. 51 J2EE and . by their inherent nature. Service providers can use the Basic Profile test suites to test a service's interoperability across different platforms and technologies. reliability. UDDI WSDL. but also.

atmost-once delivery. basic Web services specifications like WSDL. guaranteed message delivery. The attractive thing about this specification is it leverages existing security standards. Web Services for Distributed Management (WSDM) will specify that any service implemented according to WSDM will be manageable by a WSDM-compliant management solution.Quality of services Existing mission-critical systems in enterprises address advanced requirements such as security. respectively. 54 27 . reliability. these requirements are also known as quality of services. duplicate message elimination. Delivery of messages with characteristics like once-and-only-once delivery. several documents are exchanged between service consumers and service providers. such as Security Assertion Markup Language (SAML). Both these standards are now part of OASIS. WS-Policy standardizes how policies are to be communicated between service consumers and service providers. Orchestration As enterprises embark on service architecture. a service provider may require a Kerberos security token for accessing the service. and allows the usage of these standards to secure Web services messages. where business processes are created using a set of discrete services. and UDDI aren't going to fulfill these advanced requirements. and message confidentiality. services can be used to integrate silos of data. This specification focuses on credential exchange. WSBPEL is now part of OASIS. message integrity. must be standardized. Numerous specifications related to QoS are being worked out in standards bodies like the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS). and transactions. data transformation. and compensation. SOAP. Web Services Security is an ongoing OASIS effort. These requirements are defined as policy assertions. applications. As mentioned previously. A policy may consist of multiple assertions. WSReliability and WS-ReliableMessaging are two standards that address the issues of reliable messaging. Integrating applications means that the process requirements. Reliability In a typical SOA environment. Sections below discuss some of the QoS artifacts and related standards. and acknowledgment become important in mission-critical systems using service architecture. which are OASIS efforts as well. such as asynchronous communication. 53 Policy Service providers sometimes require service consumers to communicate with certain policies. and components. As enterprises start adopting service architecture as a vehicle for developing and deploying applications. Management As the number of services and business processes exposed as services grow in the enterprise. BPEL4WS or WSBPEL (Web Services Business Process Execution Language) is an OASIS specification that addresses service orchestration. As an example. Security The Web Services Security specification addresses message security. parallel processing. Other QoS attributes such as coordination between partners and transactions involving multiple services are being addressed in the WS-Coordination and WS-Transaction specifications. a management infrastructure that lets the system administrators manage the services running in a heterogeneous environment becomes important.

Benefits of SOA Service-oriented development provides the following benefits: Reuse : The ability to create services that are reusable in multiple applications. with a ubiquitous set of standards. Loose technology coupling : The ability to model services independently of their execution environment and create messages that can be sent to any service. along with the ability to focus on the data to be shared rather than the implementation underneath. SOA enables upgrading individual services or service consumers. technical people to concentrate on technology issues. Finally. 28 . SOA enables changes to applications while keeping clients or service consumers isolated from evolutionary changes that happen in the service implementation. SOA. Efficiency : The ability to quickly and easily create new services and new applications using a combination of new and old services. Division of responsibility : The ability to more easily allow business people to concentrate on business issues. SOA provides enterprises better flexibility in building applications and business processes in an agile manner by leveraging existing 56 application infrastructure to compose new services. SOA differs from existing distributed technologies in that most vendors accept it and have an application or platform suite that enables SOA. and for both groups to collaborate using the service contract. it is not necessary to completely rewrite an application or keep an existing system that no longer addresses the new business requirements. 55 Benefits of SOA While the SOA concept is fundamentally not new. brings better reusability of existing assets or investments in the enterprise and lets you create applications that can be built on top of new and existing applications.

At the base of its roles. 58 29 . Provides the means to manage the service infrastructure. it represents the backbone and infrastructure capable of connecting service providers and service consumers. Promotes the definition of services that encapsulate reusable business functionalities.Role of ESB in SOA An ESB plays an important role in an SOA. 57 Role of ESB in SOA Provides an integration infrastructure consistent with the principles of SOA: Enforces the use of explicit implementationindependent interfaces to define services with loose coupling. Uses communication protocols that stress location transparency and interoperability.

Role of ESB in SOA Operates in the distributed. Centralizes control and distributes processing. 59 30 . Applies security and QoS to the SOA project. Uses standard interfaces and standard protocols. heterogeneous environment because it: Supports synchronous and asynchronous communication. Supports mediation to formulate the request/response as needed between different parties without the need of change in any.

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.