SOA 1 Fundamentals

7/31/2019 SOA 1 Fundamentals

1/30

11

Service Oriented Architecture(SOA)

Subject Incharge

Pratidnya S. Hegde Patil

Books

2

Text Book

1. Service-Oriented Architecture (SOA): Concepts, Technology, andDesignby Thomas Erl

Reference Books

1. Service Oriented Architecture (SOA) For Dummies, 2nd Editionby Judith Hurwitz, Robin Bloor, Marcia Kaufman, Fern Halper

2. Service-Oriented Architecture: A Field Guide to Integrating XML

and Web Services (The Prentice Hall Service-Oriented ComputingSeries from Thomas Erl)by Thomas Erl

3. SOA Using Java Web Services by Mark D. Hansen


2/30

3

A CD Player Example

Take a CD for instance. If you want toplay it, you put your CD into a CD playerand the player plays it for you. The CDplayer offers a CD playing service. Whichis nice because you can replace one CDplayer with another. You can play thesame CD on a portable player or on yourexpensive stereo. They both offer thesame CD playing service, but the qualityof service is different.

Put Another Way

How would you rather pay the bill for your paperdelivery?

The paperboy comes to the door, demands $2 forthat week's paper. Do you...

1) Tell the paper boy where your wallet is, turnaround to let the paperboy get your wallet out ofyour 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


3/30

What Does that Mean?

SOA is built on loose-coupling. How do you dothat?

Tellobjects what to do, don't askthem for theirstate!

Clients want the $2--the paper boy doesn't care ifit's in your cookie jar or your wallet or in a checkor quarters or a $2 bill or 2 singles

Systems are the same--objects are microcosmsof systems!

Queries must be free of side effects: EitherCommand OR Query--not both!

Decoupling is a Good Thing!5

Application

layer

Services

interface

layer

Business

processlayer

Focus on the Business Process and Services

.NET J2EE Legacy

Source: Service-Oriented Architecture, Thomas Erl

orchestrationservice layer

business service layer

application service

layer

6


4/30

What are Services?

Bank tellers provide services to bank customers.

Different tellers may offer different services, and sometellers may be specifically trained to provide certain typesof services to the customer.

Typical services include:

Account management (opening and closing accounts).

Loans (application processing, inquiries about terms andconditions, accepting payments).

Withdrawals, deposits, and transfers.

Foreign currency exchange.

7

Several tellers may offer the same set of services toprovide load balancing and high availability.

What happens behind the counter does not matter to thecustomer, as long as the service is completed.

Processing a complex transaction may require the customerto visit several tellers and therefore implement a businessprocess flow.

Behind the counter are the IT systems that automate the

banks services. The services are provided to the customer via the tellers.

The services implemented by the IT systems must matchand support the services provided by the tellers.

8


5/30

A consistent approach to defining services on the ITsystems that align with business functions and processesmakes it easier for the IT systems to support the goals ofthe business and adapt more easily to providing the sameservice through humans, ATMs, and over the Web.

The same service can be accessed from customers at theATM, tellers on the office network, or Web users from theirPCs. The services are designed and deployed to match theservices that customers need.

The implementation environments for the services dontmatter; its the service thats important. Two or moreservices can easily be combined to create another service.

9

10


6/30

Conclusion of the bank example

The definition of software services aligns with thebusiness services that a bank offers to ensuresmooth business operations and to help realizestrategic goals such as providing ATM and Webaccess to banking services in addition toproviding them in the branch office.

Deploying services in the context of an SOAmakes it easier to compose services into simpleas well as complex applications, which can alsobe exposed as services that can be accessed byhumans and IT systems alike.

11

Business View - Services (SO of SOA)

The enterprise architecture perspective should befocused on the business needs in order to makesure IT serves the business and not vice versa.

SOA is a conceptual business architecture wherebusiness functionality, orapplication logic, ismade available to SOA users, or consumers, as

shared, reusable services on an IT network.Services in an SOA are modules of business orapplication functionality with exposedinterfaces,and are invoked bymessages.

12


7/30

In a NutShell

From the business point of view SOA is :

About analyzing the business to identify businessareas and business processes.

Followed by defining services to represent theseareas.

Services expose their capabilities through messageinterfaces.

The services can then be choreographed ororchestrated to realize the business processes.

The goal of SOA is to increase the alignment between

business and IT and achieve business agility theability to respond to changes quickly and efficiency.

13

Technical View - Architecture (A of SOA)

SOA is commonly thought of as an architecture or anarchitecture style that builds on loosely coupled,interoperable and composable components or softwareagents called services.

Services have well-defined interfaces based standardprotocols (usually web-services but most definitionsmention that it is not the only possible implementation) aswell as QoS attributes (or policies) on how these interfacescan be used by Service Consumers.

SOA definitions mention the basic communication patternfor SOA is request/reply but many definitions also talkabout asynchronous communications as well.

14


8/30

Loose coupling manifests itself in

the SOA paradigm as follows:

It helps to have an abstraction layer between the serviceproducers and service consumers.

Loose coupling promotes flexibility in changing the serviceimplementation without impacting the service consumers.

In the SOA approach, functionality is organized as a set ofmodular, reusable shared services. These services havewell-defined interfaces that encapsulate the key rules foraccessing the services. They're also built without makingany assumptions of who will use or consume these services.

Thus, they are loosely coupled to the consumer of theseservices.

15

Earlier Approaches vs SOA

Earlier approaches to building IT systems tended to directly usespecific implementation environments such as object orientation,procedure orientation, and message orientation to solve thesebusiness problems, resulting in systems that were often tied tothe features and functions of a particular execution environmenttechnology such as CICS, IMS, CORBA, J2EE, and COM/DCOM.Whereas in SOA business services (i.e., the services that anorganization provides to clients, customers, citizens, partners,employees, and other organizations) are the key organizingprinciple used to align IT systems with the needs of the business.

Previous approaches require you to focus more on the use of aspecific execution environment technology. Whereas serviceorientation lets you focus on the description of the businessproblem and services are developed better which aligns them withsolving business problems.

16


9/30

Earlier Approaches vs SOA

Previous implementations of SOA were based on a singleexecution environment technology. Whereas in SOA due toseparating the service interface from the executiontechnology, allows IT departments to choose the bestexecution environment for each job (whether its a new orexisting application) and tying them together using aconsistent architectural approach.

Separating the service description from its technologyimplementation in SOA means that businesses can thinkabout and plan IT investments around the realization ofoperational business considerations, as represented by the

description, more so than the capabilities of any individualproduct or software technology chosen to execute thedescription.

17

Earlier Approaches vs SOA The real value of SOA comes from the later stages of deployment, when

new applications can be developed entirely, or almost entirely, bycomposing existing services. When new applications can be assembled outof a collection of existing, reusable services, the best value for effort canbe realized (that is, the lowest cost and fastest time to results and bestROI).

Its easy to understand the benefit of reusing common business servicessuch as customer name lookup, ZIP Code validation, or credit checking.In a pre service oriented development environment, these functions mightbe performed by reusable code libraries or class libraries that are loaded

or linked into new applications. In SOA-based applications, commonfunctions such as these, as well as typical system functions such assecurity checks, transaction coordination, and auditing are insteadimplemented using services. Using services not only reduces the amountof deployed code, but it also reduces the management, maintenance, andsupport burden by centralizing the deployed code and managing access toit.

18


10/30

Service-Oriented Systems Require a Different

Development Approach

19

Defined (SOA)

Service Oriented Architecture as an architecturalstyle for building systems based on interactingcoarse grained autonomous components calledservices.

Each service expose processes and behaviorthrough contracts, which are composed of

messages at discoverable addresses calledendpoints.

The Services behavior is governed by policieswhich are set externally to the service itself.

20


11/30

SOA Components

21

Service

The central pillar of SOA is the service. A facility supplyingsome public demand.

Characteristics :

A Service should provide a high cohesion (focus onn asingle well-defined requirement) and distinct function.

Services should be coarse grained pieces of logic.

A Service should implement at least all the functionality

promised by the contracts it exposes. Service should satisfy autonomy. Autonomy means the

services should be self-sufficient, at least to someextent, and manifest self healing properties.

22


12/30

Contract

The collection ofall the messages supported by the Serviceis collectively known as the service's contract.

Characteristics :

The contract can be unilateral, meaning a closed set ofmessages the service chooses to provide.

A contract might also be multilateral or bilateral, that is,between a predefined group of parties.

The contract can be considered the interface of theService, like to interfaces of object in object orientedlanguages.

23

Endpoint

The Endpoint is an address, a URI, aspecific place where the service can befound and consumed.

A specific contract can be exposed at aspecific endpoint.

24


13/30

Message

Unit of communication in SOA.

Ex : http GET messages (part of the REST style) ,SOAPmessages, even SMTP messages are all valid messageforms.

Has a header and body.

The existence of the header allows for infrastructurecomponents to route reply messages (e.g. correlatedmessages pattern) or handle security better (see Firewallpattern).

25

Policy

Policy separates dynamic specification fromstatic/semantic specification. Policy representsthe conditions for the semantic specificationavailability for service consumers.

The unique aspects of policy are that it can beupdated in run-time and that it is externalized

from the business logic. The Policy specifydynamic properties like security (encryption,authentication, Id etc.) , auditing, SLA etc.

26


14/30

Service Consumer

A service consumer is any software thatinteracts with a service by exchangingmessages with the service.

Consumers can be either clientapplications or other neighboringservices. Their only requirement is thatthey bind to an SOA contract.

27

Emphasis on Interface

SOA has a total of four different components that deal withthe interface :

messages which are the parts of the interface,

contract which is the collection of the messages,

endpoint where the contract is delivered and

policy which governs the behavior of the endpoint.

The focus on interfaces is what gives SOA the ability to

create loose coupling, composable components, reuse andachieve the various design goals.

28


15/30

SOA

Service-oriented architecture is a way of designing,developing, deploying and managing systems, in which

Services provide reusable business functionality.

Service consumers are built using functionality fromavailable services.

Service interface definitions are first-class artifacts.

An SOA infrastructure enables discovery, composition,and invocation of services.

Protocols are predominantly, but not exclusively,message-based document exchanges.

29

Services

30


16/30

Services and Cost Efficiency

31

Services and Agility

32


17/30

Services and Adaptability

33

Services and Legacy Leverage

34


18/30

Components of a Service Oriented System

35

Three Basic Operations to Support Service-Oriented Systems

Service Discovery

Services repositories are queried forservices with desired characteristics.

Service Composition

Applications/service consumers are builtby integrating functionality provided byservices.

Service Invocation

Services are invoked and service code isexecuted.

36


19/30

Motivation for Service Oriented Architecture

(SOA)

Rapidly-changing business environment

Ubiquity of the Internet & WWW has led to emergence ofplatform-independent, web-based technologies as the standardbuilding blocks for enterprise integration.

There is an increase trend for sharing resource/data both withincompanies and among companies in a flexible/standardizedmanner.

In a service oriented approach, the complete value chain withinthe company is divided into small modular functional units, orservices.

A service oriented architecture focuses on how services aredescribed and organized to support the dynamic, automateddiscovery and use.

Companies and their sub-units should be able to easily provideservices. 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,

service, and

an optional service directory.

Application-to-application messaging is

used in the information exchange.

38


20/30

SOA Architecture First the service provider creates

a service and decides to expose itand publish it. Publishing is doneby posting the service informationon the service registory.

On the other side, a servicerequester, in need of a certainservice, searches the servicedirectory for one that meets thenecessary criteria.

Upon finding one and using theinformation available on theservice registory, the servicerequester is able to directlycontact the service provider in the

correct way to fulfill the businessneed.

39

Actors of SOA

A service is the atomic unit of SOA. It encapsulates a businessprocess.

Service Provider: Provider of services whose invocation contractand location are published & provide a stateless, locationtransparent business service.

Service Consumer: Consumer of services matching his or herbusiness need found in a service directory.

Service Registry: Directory for publishing and listing availableservices for consumers.

Benefits : Flexible, Scalable, Replaceable.

40


21/30

Requirements of SOA

Interoperability between different systemsand programming languages. (Usestandards; platform independent)

Clear and unambiguous descriptionlanguage

Retrieval of the service

Security41

What is Service Oriented?

Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply designparadigm for synchronous and asynchronous applications.

An application's business logic or individual functions aremodularized and presented as services for consumer/clientapplications.

What's key to these services is their loosely coupled nature;i.e., the service interface is independent of theimplementation.

Application developers or system integrators can buildapplications by composing one or more services withoutknowing the services underlying implementations.

For example, a service can be implemented either in .Net orJ2EE, and the application consuming the service can be ona different platform or language. 42


22/30

What is SOA? Conceptual view of SOA

G H I

J KL

SoftwareComponent

System (Platform).NET CRM JAVA KMS

Services

Business Process

A B C D E F

Application FrontendWeb Client, Rich Client, Enterprise Portal etc

43

SOA Characteristics or Principles1. Reusable: divide business logic into reusable services. Service offered by

one web service provider can be reuse in a WebApp or another web service.Web services are loosely coupled components which accelerates reuse.

2. Composable: facilitate the assembly of composite services. Services arecomposable that is reconcile the sub-operations into a single operationwhich is simply another form of reuse.

3. Stateless: minimize retained information specific to an activity. Service arenot allowed to store the state information as it will not allow the service tobe loosely coupled.

4. Discoverable: self-described so that they can be found and assessed.Services are discoverable that is for example a service registry provides adiscovery mechanism very much like a phone book allowing potentialrequestors to query and check for service providers.


23/30

SOA Characteristics or Principles Loosely coupled: minimizes dependencies between services. It is a

condition wherein a service acquires knowledge of another service but stillremaining independent of that service.

Contractual: adhere to agreement on service descriptions. For the servicesto interact they need to share a formal contract, that include : formaldefinition of service end point, each service operation, every input andoutput message supported by each operation, rules and characteristics ofthe service and its operation.

Autonomous: control the business logic they encapsulate. Services areautonomous that is self-governance and eliminating dependencies onother services.

Abstract: hide the business logic from the service consumers. The serviceabstract the underlying logic of its implementation but provide access toits functionality or operation through interfaces.

Characteristics SOA services have self-describing interfaces in platform-independent XML

documents. Web Services Description Language (WSDL) is the standardused to describe the services.

SOA services communicate with messages formally defined via XMLSchema (also called XSD). Communication among consumers andproviders or services typically happens in heterogeneous environments,with little or no knowledge about the provider. Messages between servicescan be viewed as key business documents processed in an enterprise.

SOA services are maintained in the enterprise by a registry that acts as adirectory listing. Applications can look up the services in the registry andinvoke the service. Universal Description, Definition, and Integration(UDDI) is the standard used for service registry.

Each SOA service has a quality of service (QoS) associated with it. Someof the key QoS elements are security requirements, such as authenticationand authorization, reliable messaging, and policies regarding who caninvoke services.

46


24/30

Why SOA?

The reality in IT enterprises is that infrastructure isheterogeneous across operating systems, applications,system software, and application infrastructure.

Some existing applications are used to run current businessprocesses, so starting from scratch to build newinfrastructure isn't an option.

Enterprises should quickly respond to business changeswith agility; leverage existing investments in applicationsand application infrastructure to address newer business

requirements; support new channels of interactions withcustomers, partners, and suppliers; and feature anarchitecture that supports entire business.

47

Why SOA?

SOA with its loosely coupled nature allowsenterprises to plug in new services or upgradeexisting services in a granular fashion to addressthe new business requirements,

Provides the option to make the servicesconsumable across different channels, and

exposes the existing enterprise and legacyapplications as services, thereby safeguardingexisting IT infrastructure investments.

48


25/30


26/30

SOAP, WSDL, UDDI

WSDL, UDDI, and SOAP are the fundamental pieces of the SOAinfrastructure. WSDL is used to describe the service; UDDI, toregister and look up the services; and SOAP, as a transport layerto send messages between service consumer and serviceprovider. While SOAP is the default mechanism for Web services,alternative technologies accomplish other types of bindings for aservice. A consumer can search for a service in the UDDI registry,get the WSDL for the service that has the description, and invokethe service using SOAP.

WS-I Basic Profile

WS-I Basic Profile, provided by the Web services Interoperability

Organization, is turning into another core piece required forservice testing and interoperability. Service providers can use theBasic Profile test suites to test a service's interoperability acrossdifferent platforms and technologies. 51

J2EE and .Net

Though the J2EE and .Net platforms are the dominantdevelopment platforms for SOA applications, SOA is not by anymeans limited to these platforms. Platforms such as J2EE not onlyprovide the framework for developers to naturally participate inthe SOA, but also, by their inherent nature, bring a mature andproven infrastructure for scalability, reliability, availability, andperformance to the SOA world.

Newer specifications such as Java API for XML Binding (JAXB),used for mapping XML documents to Java classes, Java API forXML Registry (JAXR), used for interacting with the UDDI registriesin a standard manner, and Java API for XML-based RemoteProcedure Call (XML-RPC), used for invoking remote services inJ2EE 1.4 facilitate the development and deployment of Webservices that are portable across standard J2EE containers, whilesimultaneously interoperating with services across other platformssuch as .Net. 52


27/30

Quality of services

Existing mission-critical systems in enterprises address advanced requirements such as security,reliability, and transactions. As enterprises start adopting service architecture as a vehicle fordeveloping and deploying applications, basic Web services specifications l ike WSDL, SOAP, andUDDI aren't going to fulfi ll these advanced requirements. As mentioned previously, theserequirements are also known as quality of services. Numerous specifications related to QoS arebeing worked out in standards bodies like the World Wide Web Consortium (W3C) and theOrganization for the Advancement of Structured Information Standards (OASIS). Sections belowdiscuss some of the QoS artifacts and related standards.

SecurityThe Web Services Security specification addresses message security. This specification focuses oncredential exchange, message integrity, and message confidentiality. The attractive thing aboutthis specification is it leverages existing security standards, such as Security Assertion MarkupLanguage (SAML), and allows the usage of these standards to secure Web services messages. WebServices Security is an ongoing OASIS effort.

Reliability

In a typical SOA environment, several documents are exchanged between service consumers andservice providers. Delivery of messages with characteristics like once-and-only-once delivery, at-most-once delivery, duplicate message elimination, guaranteed message delivery, andacknowledgment become important in mission-critical systems using service architecture. WS-Reliability and WS-ReliableMessaging are two standards that address the issues of reliablemessaging. Both these standards are now part of OASIS.

53

PolicyService providers sometimes require service consumers to communicate with certainpolicies. As an example, a service provider may require a Kerberos security token foraccessing the service. These requirements are defined aspolicy assertions. A policy mayconsist of multiple assertions. WS-Policy standardizes how policies are to be communicatedbetween service consumers and service providers.

OrchestrationAs enterprises embark on service architecture, services can be used to integrate silos ofdata, applications, and components. Integrating applications means that the processrequirements, such as asynchronous communication, parallel processing, datatransformation, and compensation, must be standardized. BPEL4WS or WSBPEL (WebServices Business Process Execution Language) is an OASIS specification that addressesservice orchestration, where business processes are created using a set of discrete services.WSBPEL is now part of OASIS.

ManagementAs the number of services and business processes exposed as services grow in theenterprise, a management infrastructure that lets the system administrators manage theservices running in a heterogeneous environment becomes important. Web Services forDistributed Management (WSDM) will specify that any service implemented according toWSDM will be manageable by a WSDM-compliant management solution.

Other QoS attributes such as coordination between partners and transactions involvingmultiple services are being addressed in the WS-Coordination and WS-Transactionspecifications, respectively, which are OASIS efforts as well.

54


28/30

Benefits of SOA

Service-oriented development provides the followingbenefits:

Reuse : The ability to create services that are reusable inmultiple applications.

Efficiency : The ability to quickly and easily create newservices and new applications using a combination of newand old services, along with the ability to focus on the datato be shared rather than the implementation underneath.

Loose technology coupling : The ability to model servicesindependently of their execution environment and createmessages that can be sent to any service.

Division of responsibility : The ability to more easily allowbusiness people to concentrate on business issues,technical people to concentrate on technology issues, andfor both groups to collaborate using the service contract. 55

Benefits of SOA While the SOA concept is fundamentally not new, SOA differs from

existing distributed technologies in that most vendors accept it and havean application or platform suite that enables SOA.

SOA, with a ubiquitous set of standards, brings better reusability of existing assets or investments in the enterprise and lets you createapplications that can be built on top of new and existing applications.

SOA enables changes to applications while keeping clients or serviceconsumers isolated from evolutionary changes that happen in the serviceimplementation.

SOA enables upgrading individual services or service consumers; it is notnecessary to completely rewrite an application or keep an existing systemthat no longer addresses the new business requirements.

Finally, SOA provides enterprises better flexibility in building applicationsand business processes in an agile manner by leveraging existingapplication infrastructure to compose new services. 56


29/30

Role of ESB in SOA

An ESB plays an important role in an SOA.At the base of its roles, it represents thebackbone and infrastructure capable ofconnecting service providers and serviceconsumers.

57

Role of ESB in SOA

Provides an integration infrastructureconsistent with the principles of SOA:

Enforces the use of explicit implementation-independent interfaces to define services withloose coupling.

Uses communication protocols that stresslocation transparency and interoperability.

Promotes the definition of services thatencapsulate reusable business functionalities.

Provides the means to manage the serviceinfrastructure.

58


30/30

Role of ESB in SOA

Operates in the distributed, heterogeneousenvironment because it:

Supports synchronous and asynchronouscommunication.

Uses standard interfaces and standardprotocols.

Centralizes control and distributes processing.

Supports mediation to formulate therequest/response as needed between different

parties without the need of change in any. Applies security and QoS to the SOA project.

59

Documents

SOA 1 Fundamentals