Service Oriented Architecture - polito.itsofteng.polito.it/01CIT/slides/SOA.pdf · Service Oriented Architecture Paolo Falcarin 2 From Components to ... have made it more practical

1

Service Oriented Architecture

Paolo Falcarin

2

From Components to (Web) Services

Requires a client library

Client / ServerExtendableStateless

FastSmall to medium granularity

Loose coupling via Message exchanges Policies

Peer-to-peerComposableContext independent

Some overheadMedium to coarse granularity

2

3

Towards a Service-Oriented Architecture

Function orientedBuild to lastProlonged development cycles

FromFrom ToTo

Coordination oriented Build to changeIncrementally built and deployed

Application silosTightly coupledObject orientedKnown implementation

Enterprise solutionsLoosely coupledMessage orientedAbstraction

4

SOA (Service Oriented Architecture)

SOA IS AN ARCHITECTURAL STYLE WHOSE GOAL IS TO ACHIEVE

LOOSE COUPLING AMONG INTERACTING

SOFTWARE AGENTS

(from xml.com)

3

5

Large Firms Implementing SOA

Implemented/(ing) SOANo plans

58% of 612 organizations polled by CIO Magazineimplemented or plan to implement SOA

CIO Magazine March 2006

6

SOA Growth

Forrester: 70% of global enterprises have adopted or will adopt SOA

Hayward, S “Position 2005: Service Oriented Architecture Adds

Flexibility to Business Processes”Gartner, Inc. Feb 2005

“SOA will provide the basis for 80% of new development projects by 2008”

Dr. Chris Harding, “Modeling SOA Implementation”

The Open Group

4

7

Service Oriented Architecture “The SOA models the business as a collection of self-contained services that are available across the enterprise that can be invoked through standard protocols both internally and externally.” (Hohpe)

•Services are course grained collections of functionality rather than small components.

•Services are factored out of their applications to eliminate duplicated functionality.

•Services are run-time shareable functions.

8

SOA = Web Services• Service-Oriented Architecture (SOA): An IT

architectural style based on the concept of a collection of services that communicate and coordinate with each other in an enterprise-level, distributed computing environment.

• Service: A self-contained, reusable function that is invoked through well-defined interfaces and is independent of the context, state or location of other services or applications.

• Reuse: Services encapsulate business functions that are located and reused at run-time.

Key SOA Concepts/

5

9

• Coarse-Grained: Granularity is the level of detail at which an item is viewed or described. Services tend to be Coarse-Grained where as an API is fine-grained.

• Loose Coupling: Service provider and consumer need no knowledge of how the other is implemented resulting in minimal dependencies. Generally implies asynchronous messaging.

• SOA Governance: The organization and processes to ensure optimal reuse of services and enforcement of policies (eg. Business design, technical design, application security).

Key SOA Concepts

SOA = Concepts and Principlesnot Technology

10

• Web Services: A specific implementation of SOA that uses standard Web protocols to connect services together via XML messages. Most commonly used scenario is synchronous request/response pattern.

• Message Oriented Middleware (MOM): A category of inter-application communication software that relies on asynchronous message passing as opposed to a request/response metaphor. (e.g. MQ-Series)

• Enterprise Service Bus: Message Oriented Middleware that provides a robust asynchronous transport service for XML messages and standard Web services protocols.

Key SOA Technologies

SOA is not a new concept – but new technologies, like Web services, have made it more practical

6

Migrating Information Systems to SOA

12

Two Approaches to SOATop Down – Business-centric

Start with high-level picture of Business ProcessesDecompose processes – look for redundancy, Service candidatesBest approach to demonstrate business value

Bottom Up – Technology-centricStart by looking at existing IT capabilitiesLook for redundant coarse-grained functions to expose as ServicesPrioritize with 80/20 rule – Expose the 20% functionality that is used 80% of the time

7

13

UserInterface

Security

Reporting

Workflow

Business RulesProcessing

Correspondence

Entity Mgmt

Core BusinessLogic

From a survey on Industrial Insurance

AppsOnly about 30%

Unique Business Logic

Bottom-Up: Identify Redundant Functions

14

UserInterface

Security

Reporting

Workflow


Correspondence

Entity Mgmt

Core BusinessLogic

70% Redundant Functions Common to Most Business

Applications


8

15

UserInterface

Security

Reporting

WorkflowBusiness Rules

Processing

Correspondence

Entity Mgmt

Core BusinessLogic

UserInterface

Security

Reporting


Processing

Correspondence

Entity Mgmt

Core BusinessLogic

UserInterface

Security

Reporting

Workflow


Correspondence

Entity Mgmt

Core BusinessLogic

Multiplied times many apps…Lots of redundant functionality

to build and maintain


WHAT CAN WE DO?

16

UserInterface

UserInterface

UserInterface

Reporting


Core BusinessLogic

Security

Correspondence

Core BusinessLogic

Workflow

Entity Mgmt

Core BusinessLogic

WebFacing

InfoDelivery

BusinessRules

SecurityCorresp. Workflow EntityMgmt

Security

Workflow

Correspondence

Entity Mgmt

Reporting


Processing

Entity Mgmt Security

Reporting


Correspondence

SHARED SERVICES

INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE INTERFACE

Tight Coupling?X

Build Functions as Services

9

17

Message Bus (asynchronous)

Core BusinessLogic

Core BusinessLogic Core Business

Logic

WebFacing

InfoDelivery

BusinessRules


SHARED SERVICES


INTERFACE INTERFACE

INTERFACE

Build Functions as Services

18

Core BusinessLogic

Core BusinessLogic Core Business

Logic

WebFacing

InfoDelivery

BusinessRules


Message Bus (asynchronous)

SHARED SERVICES

XML


INTERFACE INTERFACE

INTERFACE

Build Functions as ServicesLOOSE COUPLING

XML

XML

XMLXMLXML XML

XML over MOM or XML/SOAP

10

19

BUSINESS APPLICATION SERVICES•Not shared across multiple processes•Very specific business logic•Uses services from lower levels

INFRASTRUCTURE FRAMEWORK SERVICES•Generalized, shareable technology•Programmable, no native business logic•Some relevance to developers

BUSINESS FRAMEWORK SERVICES•Shared across multiple business processes•Broad business logic•Highly relevant to developers

INFRASTRUCTURE FOUNDATION SERVICES•Highly standardized technology•Broadly shareable, no business logic•Not very relevant to developers

Example:Accounts Receivable

Example:Business Process Mgmt

Example:Security

Example:Enterprise Service BUS

Service ClassificationsHigh

Low

Rel

evan

ce to

Dev

elop

ers

20

BUSINESS APPLICATION SERVICES (Common Apps)

INFRASTRUCTURE FRAMEWORK SERVICES

BUSINESS FRAMEWORK SERVICES

INFRASTRUCTURE FOUNDATION SERVICES

•Accts. Receivable•Accts. Payable•Inspections•Permits & Licensing

•Claims Mgmt•Pension Mgmt•Provider Bill Processing•Customer Relationships

•Finance & Budget•Purchasing & Assets•Safety Mgmt•HR

•In-Correspondence•Out-Correspondence•Info Delivery

•Work Flow/BPM (app)•Business Rules (app)•Entity Mgmt (app)

•Personalization (portal)•Content Mgmt (portal)•Payment Processing

•Web Facing (portal)•Portal Servers•App Servers (.NET)

•Work Flow/BPM (engine)•Business Rules (engine)•Shared Security

•Entity Mgmt (engine)•Active Metadata•Message Routing

•Service Bus•XML Cache•Data Exchange

•Directory services•Networks•Load balancing

•Storage•Computing Platforms•Databases

Services Examples

11

21

Increasing levels of encapsulation

Code reuse

Language

ObjectsPlatforms

Components

Frameworks

Applications

Abstraction

Time

22

SOA fosters AgilityAgility is the ease with which an organisation can change

Highly agile organisations react quickly to changes in the market, thus getting ahead of the competition

Software evolutionIf the system cannot evolve, the business cannot react to changes

Software evolution entailscosts and risks

Evol.Dev.

12

23

AgilityUnprecedented levels of change

often unanticipatedVirtual organizations

Interacting applications belong to multiple administrative domains Internal applications increasingly exchange functions with the external of the enterprise Many potential providers can be found for each required functionWeb based interactions become pervasive

24

Yet another middleware?Execution is distributed . . .. . . but also costs and risks are distributedOrganization ability to evolve business

depends on the marketplace ability anticipate trends and needs and provide the right services at the right time does not depend on ability of a software vendor to change a piece of software

Services are realized by softwareneed for development / maintenancethis is a vendor concern

Shared risks (SLAs)

13

25

Striving for agility

Agility

Decentralization of componentsDynamicity of bindings

Monolithic

Distributed

Cross domain

Modular

26

Striving for agility

Agility

Decentralization of componentsDynamicity of bindings

Monolithic

Distributed

Cross domain

Compile time

Deploy time

Run time

On demand

Modular

14

27

What SOA brings inOpen infrastructures where “pieces of functionality” are published as services

come with a contract for clients specifying QoSServices appear dynamically

they must be discoveredThey run in their own domainsNew services built by composing services, which may live in external domains

late bindingexecution time discovery

28

What SOA brings inNot just web servicesNot all Web services fit into an SOA

e.g., fine-grained RPC-type services

Not all SOAs use Web services technologye.g., message-oriented middleware technology

Services may must beDerived from business requirements

Typically expressed as business processes

Sufficiently coarse-grained toEnable workflow-oriented assembly

15

29

Many new challenges for software engineering

Service engineeringe.g. contract based specification

Publishing, searching and negotiatione.g. syntactic vs.semantic discovery, policy-driven resource allocation

Compositione.g. balancing dynamicity and safety

Validatione.g. limitations of traditional testing

Truste.g. the role of run-time self checking

SOA and Web Services

16

31

SOA as “On Demand” Computing

Use software as you needMuch lower setup time, forget about

InstallationImplementationTrainingMaintenance

Scalable and effective usage of resourcesProvisionBilled on true usageParallelism (CPU, Storage, Bandwidth…)

32

New Paradigms in SOAAn application is NOT a single system running on a single device and bounded by a single organizationObject <=> XML DocumentMessages and Services

As opposed « distributed objects »Exchanges becomes peer-to-peer

Asynchronous communicationsConcurrency becomes the norm

our languages/infrastructures did not plan for it

17

33

SOA

34

Message Based InteractionAll interaction between components is through messagesGenerally XML messages

18

35

“Bus”Conceptual artifact

To get you away from the point to point mentalityA strategy for integrating applications together at runtime using MOM.

(like the bus/ backplane in a PC)

36

BrokerA dispatcher of messages

Many varieties and variations

19

37

QueuesQueues are key to making this work

38

SOA vs. Web services

What is it?

Interface standardArchitectural Style

Web serviceSOA

20

39


Early use

New developmentComposite Apps

Legacy WrappingEAI

Web servicesSOA

40


Predominant/ default interaction

Request/ReplySynchronous

Publish/SubscribeAsynchronous

Web serviceSOA

21

41

SOA and Web service co-existing

Service Registry

Service Provider

Service Consumer

WSDLSOAP

WSDLSOAP

42

Loose Coupling: Intermediaries

Decoupling is achieved by introducing an ‘intermediate form’Full application decoupling requires intermediate forms for Technology, Destination, Syntax, Semantics, Identity and Domain Ontology

22

43

What Makes a Good Intermediary ?

It doesn’t change as rapidly as its clients.

It is non proprietary.

It is evolvable.

It is simple to use.

44

Examples of Intermediaries

Integration Brokers Message QueuesEnterprise Service Bus (ESB)

Need for Asynchronous Web Services!

23

45

WS-NotificationBrings enterprise quality publish and subscribe messaging to Web services

Loosely coupled, asynchronous messaging in a Web services context

WS Notification exploits WS Resource framework and other Web services technologiesDirect and Brokered notificationTopics and Topic SpacesMore on subscribeUse of WS-Notification in WS-RF

46

WS-Notification Family of Documents

WS-Notification is a family of documents:Publish-Subscribe for Web services– Whitepaper describing roles, concepts, terms, etc.

Base Notification– Basic interfaces: Producer, Consumer, Subscription

Topics– Topics and TopicSpaces model in XML– Topic Expression Dialects

Brokered Notification– Mechanisms of Publish and the Broker role

24

47

Consumer

Producer

Subscriber

WS-Notification: Base Notification

subscribe

subscribe

S

notify

EPR

Defines the Basis for the familyDirect notification: Three primary rolesSubscriber deals directly with the producer of the Notifications

indicates interest in a particular “Topic” by issuing a “subscribe”request

An EPR to the subscription is returnedProducer is responsible fordetecting situation and creating the notificationSubscriptions that matchreceive the notification

48

Similar roles as in direct, adding ‘Broker’RoleBroker (intermediary) permits decoupling Publisher and Subscriber

Subscriber indicates interest in a particular “Topic” by issuing a “subscribe” request“Subscriptions” are WS-Resources

Various subscriptions are possibleNew role: Publisher

need NOT be a Web ServicePublisher detects situation:

Publishes the Notification to a brokerBroker responsible for disseminating notifications

examines current subscriptions for matchBrokers may provide “value add”

“Transform” or “interpret” topicsFederate to provide scalability

Broker

Subscriber

WS-Notification: Brokered Notification

Publisher

subscribe

subscribe

S S S

notify

notify

notify

notify

25

49

4. Introduction to the WS - * specifications

Web Service AddressingWeb Service PolicyWeb Service Transactions

WS – CoordinationWS – AtomicTransactionWS - BusinessActivity

Web Service Reliable MessagingWS – ReliableMessagingWS – ReliableMessaging Policy

Web Service Security

50


Web Service Addressingprovides transport-neutral mechanisms to address Web Services and messages.

Web Service Policy Frameworkdefines a base set of constructs that can be used and extended by other Web Services specifications to describea broad range of service requirements and capabilities.

WS – CoordinationDescribes an extensible framework for providing protocols that coordinate the actions of distributed applications

26

51


Web Service Reliable MessagingDescribes a protocol that allows messages to be deliveredreliably between distributed applications in the presenceof software component, system or network failures. Theprotocol is described in a transport-independent manner.

Web Service SecurityProvides comprehensive solutions to secure Web Service communication. In general these issues are addressed:

– Authentication– Authorization– Secure Messaging– Secure data access– Denial of service

BPEL

27

53

SOA and BPMSOA is about constructing software components that can be reused in context unknown at design time

Composition versus Extension (OO)BPM is about being able to precisely model and possibly change the context in which enterprise components are usedBut how the two meet?

54

BPM in SOATwo approaches

Event Oriented–BPML, BPEL–Pi-Calculus (Also Event Calculus)

Activity Oriented–WfMC–Petri nets

28

55

Web service/BPEL Orchestration

You can get a similar effect with Web services orchestration.

56

A very simple exampleA buyer orders some goods from a supplierThe supplier performs a series of steps to fulfill the order

Approve the orderUpdate the order entry systemUpdate the billing system…

29

57

Orchestration languages

They allow us to implement complex services which involve:

Long running (from a few hours to a few months), And event driven business logic

They are not about modeling Business Processes by themselves

Different orchestration (i.e. different services) can run within the same business process And vice versa

58

A Business Process can be Viewed as a Multi-Party Choreography of Peer Services

User Activity

Buyer Supplier SFA Salesperson

Start

ERP

MappingRouting QuoteRFQ RFQ RFQ

Order Order

Order

Invoice

AccountsAccount

SalesTax.com CreditCheck.com

Orders

BillingInvoice

SalesOrder

Events

Activity

InformationEntity

30

59

Services in a SOA are orchestrated (BPEL)

Quote ServiceOrchestration Definition

RFQ

Nack

Quote

SalesTax

<<send>>quoteupdateDB

Transition

Message flow

RFQ

QuoteOk?

NosendNack

Order

<<invoke>>calculateSalesTax

<<invoke>>GetQuote

Ok?No

EntityState

Entity

<<receive>>RFQ

60

A Choreography Provides a Model of the Event Flow Between Activities

Buyer Supplier(Self)

Order Entry

POAckPO

BTA1

OpA1

POAckPO

Manager

OpA2

Salesorder

Start

Wit1

POPO

Billing

Failure Success

[BusinessFailure] [Success]

31

61

Orchestration vs ChoreographyOrchestration

« … is an emerging [concept] that would give programmers a way to formally describe processes underlying business applications so that they can be exposed and linked to processes in other applications »

ChoreographyIs a concept that specifies how these processes are linked together across the enterpriseChoreography can be « active » when mapping and routing are necessary

They are both a form of Coordination

62

Putting BPM and SOA togetherThe foundation is becoming sound with strong theoretical supportLot of work to be done on Stateful ServicesSemantic Web standards add:

Shared ontologies in OWL-SSemantic Interfaces (WSDL-S)Formal unambiguous semantic for intefaces and dataFundamental for reaching automatic service composition and adaptation

32

63

SOA is a New Computing ParadigmNot as a new name for

APIComponent

A genuine set of concepts with which we can construct new kinds of software

This is as significant if not more than Object Orientation

In particular SOA forces us to think about enabling the same piece of code to be leveraged

by large numbers of consumers in unforeseen context

64

ReferencesExisting BPEL Runtimes:

ActiveBPEL [http://www.activebpel.org]Eclipse BPEL [http://www.eclipse.org/bpel]Orchestra – ObjectWeb- JONAS J2EE app server

Workflow Runtime:Windows Workflow Foundation[http://msdn.microsoft.com/workflow]

WS - * Frameworks:WS Apache [http://ws.apache.org]WS Apache Pubscribe Microsoft WSE

[http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx