SOA

(Service Oriented Architecture)

Reda Bendraou

1

Plan

•IS &

Architecture: Historical evolutions

•

IT Planning

•SO

A (Software O

riented Architecture)

•SO

A: Key Concepts –

Reference Model

–Business Processes

–Services

–ESB

–BPM

N/BPEL

•

SOA: Transversal Aspects (m

ethodology, security, monitoring, reporting, etc.)

•

SOA: Feedbacks from

the industry

•W

rap-up!

2

IS & Architecture: Historical evolutions

3

IS & Architecture: H

istorical evolutions

•M

ainframes

–U

nique Server, all the application aspects/layers are deployed on the same

server (Monolithic)

•Plus: Reliability and consistency

•flaw

s: costly, hard to maintain

•Client/Server –

GU

I deported on the customer’s m

achines –

Introduced because of the decrease in PC prices –

Modules on the client side=> needed to be updated for each IS evolution •

Plus: Server side get less solicited •

flaws: costly to m

aintain the client side

•W

eb Applications / Internet –

Client side: only need a browser!

–E-com

merce em

ergence •

Plus: client side is generated on the server side, no need to update clients •

flaws: Load on the server side

4

IS & Architecture: H

istorical evolutions

•N

-Tiers –

Processors and Mem

ory getting cheaper and cheaper –

Application’s modules are deployed on different servers for m

ore scalability •

Plus: more robustness, perform

ance, •

Flaws: the IS is now

scattered in different locations; becomes harder to get the

global state of the system, to m

aintain consistency , Harder to have a global

image of the IS

•Cloud Com

puting –

The notion of “Pay as you Go”, Processors, M

emory, H

D, Apps

–N

otion of SaaS (Software As A Service, ex. Custom

er Relationship M

anagement (CRM

))& PaaS (Plateform

As A Service, Server + DB, etc.)

•Plus : H

igh Performance and robustness, econom

ical model

•Flaw

s: juridical gaps, Data outsourcing, security, dependability to the Internet,

Single Cloud of Failure, Web services calls are very costly!!!

5

IS & Architecture: H

istorical evolutions

•Current IS reflect quite w

ell the technological evolutions –

Many different m

odules, technologically heterogeneous, m

ultiplication of data sources, notion of Silos, layers (we build on

top of existing layers) => erosion of the IS

User m

achine

Heavy Client W

eb Browser

Application A Application B

Application C

6

Challenges

•H

omogenize this notion of Silos (Repositories of data)

•Constant need for Agility –

More productivity

–M

ore reactivity in integrating and absorbing new IS (acquisitions)

7

Challenges

•Q

oS : quality of service •

System’s global Perform

ance

•Creating Value !!!

8

IT Planning

9

IT Planning: Definition

•IT Planning is a process to establish clear objectives for IT organizations that link directly back to the enterprise's strategic business goals.

•Allow

s to continuously drive the IT progression/ Evolution •

Quite sim

ilar to the Urbanism

domain

–processes

–Layers

–N

otion of districts

10

IT Planning : 2 principal rules

•Application’s m

odules must be focusing on one and only

one aspect/ functionality of the system

–A road m

ap is needed to reach each module’s goal

•Loosely coupling / H

igh consistency –

Between applications

–Betw

een application’s modules

–Betw

een module's classes/services

11

IT Planning: the reference model

Business Technology

Business Processes and docum

ents

Functions

Softs and Data

Physical infrastructure

12

IT Planning: Challenges

•To m

aintain horizontal and vertical coherence

–To be able to concretize Enterprise’s new

objectives •

At least to say if it is feasible or not

–IT Planning could have as a m

ain goal just to know about the

existent system!

13

IT Planning Vs. Enterprise Architecture

•Enterprise Architecture –

Set of processes and objects –

Softs and infrastructure that supports the IS system

=>IT Planning

–Tools, m

ethodologies and concepts used to concretize the Enterprise’s objectives

–EA = the target

–IT Planning= the process

14

IT Planning: Process

•To m

ap the existent system (cartography)

•

Define the target (EA)

•

Enterprise Architecture

•O

bjects (data) •

Processes (and events) •

Services

•Physical Infrastructure

•Technological choices

•Progression roadm

ap

•Project m

anagement

15

Two w

ays

•Big-Bang or Progressive Big-bang not realistic for com

plex systems

16

IT Requirements

•Business Requirem

ents –

Agility: quickly integrate new processes

–G

lobal vision of the system

–Reduce costs

•

Technical Requirements

–M

ore reusability –

Loosely coupling (Event-Driven Architecture, Asynchronous calls,

etc.) –

Security , transactions, QoS

–M

aintaning coherence of Data repositories

=>N

ext, how SO

A could be the answer to these requirem

ents

17

SOA

(Service Oriented Architecture)

18

SOA: Service O

riented Architecture

•A softw

are architectural style in which the enterprise’s

business processes play a primary role. They

orchestrate the execution of services provided by application’s com

ponents

19

A Good Architecture is…

•M

odular =>Minim

izing interactions / dependencies •

Standard=> use of standards (best practices)

•E

volvable =>A

gile •

Survivable

=> Back-up / S

ecurity aspects

20

SOA is not…

•A technology –

An approach, a vision, architectural style…

•SO

A is not Web Services

•

SOA doesn’t necessarily im

ply the use of EAI/ESB

•SO

A is not the solution for all your performance issues

21

SOA: Key Concepts

22

SOA: Reference Architecture

23 Credit to IBM

SOA: D

esign Principles Thom

as Erl

•Service description in a standard language

•Services loosely coupled

•The right abstraction of services (granularity)

•Reuse of services

•Stateless

•A directory of w

eb services (search)

•Services com

position

24

Combining SO

A + EDA

•ED

A (Event-Driven Architecture): An architectural style

where softw

are components com

municate in an

asynchronous way using the publish/subscribe paradigm

25

SOA Com

ponents

•XM

L –

Standard for data exchange

•Business Processes –

BPMN

/BPEL •

Modeling/Execution languages for business processes

•

Services –

Reusable and autonomous functionalities

–Can be of different kind (authentication, functional, security, etc.)

–W

eb Services (SOAP, W

DSL, U

DD

I, etc.)

•EAI=>ESB –

Data integration in the IS

–Very helpful in SO

A but not mandatory

•

Methodology –

No consensus so far

26

Business Processes

27

Business Process

"a structured, measured set of activities designed to produce a specific output for a

particular customer or m

arket. It implies a strong em

phasis on how w

ork is done w

ithin an organization, in contrast to a product focus’s emphasis on w

hat. A process is

thus a specific ordering of work activities across tim

e and space, with a beginning and

an end, and clearly defined inputs and outputs: a structure for process actions. Processes are the structure by w

hich an organization does what is necessary to

produce value for its customers.“

By Thomas D

avenport (1993). Process Innovation: Reengineering work through

information technology. H

arvard Business School Press, Boston

28

Business process

•D

escribes the business concerns and not the system it self

•A process can be transversal to m

any applications, organization's departm

ents, etc.

29

Business process categories

•Custom

er processes: directly bring value to the customer

–ex : on line shopping, delivery etc.

•

Sustaining processes : indirectly bring value to the custom

er –

ex : Updating the online catalogue, delievery

•

Enabling processes : for managing internal services (not

related to the customer)

–Em

ployee salaries, printing, monitoring etc.

30

Business Process Modeling / Execution languages

•BPM

N (Business Process M

odeling Notation): O

MG

standard for business process m

odeling (the UM

L equivalent to BP)

•W

S4BPEL (Business Process Execution Language for Web Services ):

XML-based dialect for w

eb service orchestration

•Autom

atic generation from BPM

N tow

ards BPEL –

Attention: difference in abstraction levels –

One necessarily a one to one m

apping between BPM

N and BPEL

•

For Hum

an interaction activities => The BPEL4People solution

31

Example w

ith BPMN

32

Choreography Vs. Orchestration

•Choreography –

Coordinating and synchronizing the execution of many business

processes running concurrently and exchanging messages (ex.

WS-CD

L language)

•O

rchestration –

Coordinating the execution of many services of the sam

e business process (using BPEL for instance)

33

Choreography Vs. Orchestration Choreography

Orchestration

34

SOA/BPM

offer

•Com

mercial tools

–IBM

WPS (W

ebSphere Process Server) => IBM Business Process

Manager

–O

racle SOA Product line

–TIBCO

ActiveMatrix

–Jboss (jBPM

) –

Enterprise Architecte –

Modelio

–M

agicDraw

•O

pen Source –

Intalio BPMS

–JBO

SS BPM

–Apache O

DE

–Active BPEL

–Sun G

lassfish

35

Notion of Service

36

Service

•A processing unit w

hich provides an interface described in a standard and neutral language (technology independent) and w

hich is physically deployed on a m

achine

37

Service

•Interface: contains 1 to N

methods

•Reusable unit

•M

ust have a QoS assigned to it

•

Can be a provider/consumer of service

38

Categories of Services

•Business Entity Services –

Provides methods to m

anipulate Business entities –

Make sure that business constraints are enforced

•Business Services –

Provides methods that realize a specific business functionality.

Usually it needs to call business entity services for that

•Technical Services –

Provides technical services •

Authentication services •

Mailing, printing, etc,

39

Service Contract

• D

efines the service’s methods: signature, protocols,

and QoS

–W

SDL (SO

AP) ans W

AD

L (REST)

40

How

to identify Services

•O

ne of the most im

portant aspects in SOA

•Service G

ranularity is fundamental

–D

etermines the service reusability

•

SOA’s success depends on % of service reusability

•

Too fine grained: –

Many interactions => Perform

ance issues •

Too coarse grained –

No reusable

=>Need to find a good balance

41

How

to identify Services?

•For a better identification of services, w

e need to conciliate 2 approaches –

Top-down and bottom

-up

42

How

to identify Services

•N

o need to publish all the identified services: –

Each a service implies a cost and a risk

–Avoid services proliferation

•Exam

ple the “Service Litmus Test” by IBM

43

Orchestration Vs. Propagation of Services

•Prom

ote Orchestration

Propagation

Orchestration

44

Enterprise Service Bus (ESB)

45

ESB in SOA

•A m

edium for integrating the different com

ponents of the enterprise’s IS (applications, resources, directories, etc.)

•U

se standard protocols –

SOAP, W

SDL, binding H

TTP and JMS

–

WS-ReliableM

essaging, WS-Transaction, etc.

–

Orchestration avec BPEL

•

It’s not mandatory in a SO

A architecture but can be of a great help

46

ESB Vs EAI

•EAI :H

ub and Spoke based solution –

Do not scale(centralized)

–SPO

F (single point of failure) –

Use of proprietary protocols

•

ESB: next generation of EAI –

Distributed

–U

se only standards

•ETL et EII, have different objectives

47

ESB: Architecture

48

ESB: Why use them

?

•U

se of standards –

XML, JM

S, JCA, JMX.

•A faster integration of new

modules and services

•

Use of directories for discovering and using services –

Eases the routing of messages betw

een the modules

•Service based architecture

49

The ESB offer

•Com

mercial Products

–IBM

Websphere ESB

–O

racle Enterprise Service –

TIBCO Business W

orks

•O

pen Source –

Apache ServiceMix, Synapse

–M

ule –

JBoss ESB –

Glassfish (sun open ESB)

–Spring Integration

50

ETL (Extract / Transform / Load)

•U

sed for handling the transfer of a big amount of data

between different applications

–Routing, extraction, transform

ation

ETL

DW

H

Data-

marts

Extract

Transform

Load

Appli-

cation

Appli-

cation

Référen

ciels

51

BPMN

(Business Process M

odeling Notation)

52

BPMN

?

•A graphical language for business process m

odeling

•An O

MG

standard, Ver2.0 Since 2011

•BPM

N m

odels can used to generate BPEL (Business Process Execution Language) code

•It’s not a m

ethodology or a framew

ork

53

BPMN

: Notations

•Key Concepts

54

BPMN

: Notations

55

•Represent a w

ork to be done in the process •

Can be: –

Atomic (a task)

•Ex. Send Invoice

–

Composite (Sub-process)

•Com

posed of other activities

–

Repetitive

BPMN

: Activity

56

BPMN

: Event

•Event: som

ething that may happens during the process

execution

•An event can start, interrupt or ends an execution flow

•

Notation

57

BPMN

: Events

•Start Events say w

hen the process should start

•Interm

ediate Events are triggered after the start of a process and before it finishes

•End Events designate the end of the process

58

Intermediate Events: Exam

ples

•W

hen receiving the « Voting Response» message, start

« Increment Tally » activity

•

When the event is attached to the activity this m

eans that triggering the event w

ill interrupt its execution 59

BPMN

: Gatew

ays

•Control the execution flow

of the process (convergence or divergence points)

60

BPMN

: Gatw

ays, Examples

•Exclusive choice

•Inclusive choice, m

any options possible at the sam

e time

•

Concurrent execution

61

BPMN

: Connectors

•Sequence is used to determ

ine the execution order betw

een activities

•M

essage Flow: to show

how m

essages flow

in the process

•To link artifacts to object flow

62

BPMN

: Connectors, Example

•Exam

ple of connectors: Association and Sequence

63

BPMN

: Conclusion

•A m

odeling language for comm

unicating and reasoning around business processes

•A source for generating BPEL code

•N

ot always im

plemented correctly by tools

64

BPMN

: Refences

•BPM

N O

fficial Page

http://ww

w.bpm

n.org/ •

BPMN

Wikipedia

http://en.w

ikipedia.org/wiki/Business_Process_M

odeling_N

otation •

BPMN

Specification (v2.0 Beta 2)

http://ww

w.om

g.org/spec/BPMN

/Current/ •

BPMN

Specification (v1.2 Formal)

http://w

ww

.omg.org/spec/BPM

N/1.2/

•BPM

N Exam

ples (v2.0 Beta 2)

http://ww

w.om

g.org/spec/BPMN

/2.0/examples/PD

F 65

WS-BPEL ou BPEL

(WS-Business Process Execution Language)

66

BPEL Historical

•W

SFL, May 2001 (IBM

) The Web Services Flow

Language

•XLAN

G, M

ay 2001 (Microsoft)

•

BPEL 1.0, July 2002 (BEA, IBM, M

icrosoft) A merger of W

SFL and XLAN

G

•

BPEL4WS 1.1, M

arch 2003 (BEA, IBM, M

icrosoft, SAP, Siebel) The specification subm

itted to OASIS

•

WS-BPEL 2.0, M

arch 2007 (OASIS: 39 com

panies as mem

bers of the technical com

mittee) The first version of the

"standard" blessed by a standards organization

67

WS-BPEL

•A standard for describing the orchestration (execution) of w

eb services •

Comes w

ith traditional programm

ing languages constructs –

sequence, alternative, iteration –

variable, affectation, scoping variables –

exceptions

•

It’s a reusable definition in form of W

DSL

–The process (BPEL code) is considered as a service its self and can be part of a m

ore complex process (other BPEL code)

68

WS-BPEL: H

ow it W

orks?

69

BPEL file

BPEL Interpreter

Structure of a BPEL code: Example

<process>

<!– web services participating in the process-->

<partnerLinks> ... </partnerLinks> <!- Variables used by the process--> <variables> ... </variables> <!- used for asynchronous calls--> <correlationSets> ... </correlationSets> <!- exceptions handlers --> <faultH

andlers> ... </faultHandlers>

<!- handlers for transactions in “recovery” mode -->

<compensationH

andlers> ... </compensationH

andlers> <!- event handlers--> <eventH

andlers> ... </eventHandlers>

<!- Flux d’activités du processus --> (activities)*

</process> 70

WS-BPEL: Liste of d’activity kinds

“Basic activities” <invoke> sends a m

essage to a port of a partner <receive> blocking w

ait of a message

<reply> sends a message replying to a

received message (by <receive>)

<wait> blocks the execution for a given

duration or until an instant <throw

>, <rethrow> throw

s an exception <assign> assigns a value to a variable <exit> term

inates the process <com

pensate> executes the compensate field

<link> expresses dependencies between

activities (may have a transition condition)

<empty> nop

“Structured activities” <sequence> sequential execution <flow

> parallel execution <if> conditional execution (else branch is m

andatory) <w

hile>, <repeatUntil>, <forEach>

iteration <scope> defines an activity w

ith its own

variables, handlers, ... <pick> blocks the execution until a m

essage/timeout occurs

71

Example using BPEL w

ith a graphical editor

PartnerLink

PartnerLink

PartnerLink

72

Mapping BPM

N vers BPEL

Possible mapping

73

BPEL: Advantages

•Ensure interoperability

•A clear separation betw

een the business logic (BPMN

) and the process execution –

More agility to enterprises

•

The entire process can be viewed as Service

74

BPEL: Limits

•BPEL still no that m

ature concerning security issues and Tasks requiring hum

an interactions

•But som

e standard has been issued: –

WS-Policy

–W

S- Hum

anTask –

WS-Reliability, W

S-Security, …

–…

75

- Transversal Aspects

76

SOA: M

ethodology

•M

any proprietary solutions

•Exp. Praxèm

e Method, or IBM

’s SOA (SO

MA) m

ethod

•Alw

ays combine a m

ix between bottom

-up and top-down

77

SOA: M

ethodology

•Top-D

own

–

Model business processes and business entities

–

Decom

pose the system into functional blocks around the business

entities –

Refine the business process into a more detailed version w

ith a clear distinction betw

een human tasks and autom

ated tasks (future services)

–Align the new

ly discovered services with the existing blocks (softw

are com

ponents)

–Explicitly m

odel what w

e call Pivot Objects (objects exchanged betw

een the different application of the inform

ation system)

78

SOA: M

ethodology

•Bottom

-Up

–

Identify the different services already implem

ented by the system’s

components

–

Façade these services with the new

process activities

–Create connectors and adaptors if needed

79

QoS Q

uality of Service

•Aim

: define for each service a probe to monitor the

following inform

ation –

Service Info •

Service name

•Version

•Sem

antics Description

–

Service State •

Inactive, busy, stopped, in error state, over solicited

–Service M

etrics •

Num

ber of requests, time to answ

er, requests that resulted to error state

–Service’s interdependency w

ith other services

80

QoS

•These indicators w

ill be used to: –

Count the number of w

eb service requests for reporting matters

–

Anticipate scalability issues and switch the flow

to other servers if needed

–W

atch SLA constraints (Service Level Agreement)

–

Check services versions (date end of service)

–Follow

the process from end to end

81

BAM: Business Activity M

onitoring

•Live process execution

•Allow

s a better reactivity in case of issues

•A good w

ay to anticipate a blocking state

82

BAM: Business Activity M

onitoring

83

BAM O

ffer

•Com

mercial tools

–IBM

Websphere Business M

onitor –

BEA Aqualogic BPM

–O

RACLE BAM

–TIBCO

BusinessFactor & O

psFactor

•O

pen-source •

Pentaho BI •

Spago BI

84

Security

•XM

L Encryption (W3C): M

essage level confidentiality •

XML Signature (W

3C): Message level integrity, non

repudiation •

XML Key M

anagement System

or XKMS (W

3C):XML based

PKI •

Security Assertions M

arkup Language or SAM

L (OA

SIS): SSO

(Single SignOn), Authentication and Authorization

•W

S-Security (OA

SIS): SOAP m

essage security •

XACM

L (OA

SIS): Access control and policy managem

ent •

WS-Trust (O

ASIS): Trust m

anagement

•W

S-Policy (W3C): Policy m

anagement

•W

S-SecureConversation (OA

SIS): Secure session m

anagement

•XBCF (O

ASIS): Biom

etrics •

SPML (O

ASIS): Service provisioning

•Project Liberty (Sun etc): Federated identity

•W

S-Federation (MS, IBM

): Federated identity

85

SOA: Success &

Failure Stories

86

Some Projects

Domain

Project Type

Infrastructure N

br of Services

QoS

Charges J/H

state

Bank Redesign

JEE, JSF, XML, +

Framew

orks Open

source

<20 Critical

4500 Prod

Stock Exchange

Project .N

ET, smart Client

<20 Critical

1200 Prod

Insurance Redesign

JEE, + Framew

orks O

pen source

>500 Critical

>20000 Prod

Services Projet

JEE, + Framew

orks O

pen source

<20 Critical

2000 Prod

87

Dom

inique Vauquier, Author of the Praxeme Institute

•M

ain Mistakes to avoid?

it’s to see SOA only from

the technological angle and to focus only on W

eb Services. SOA is, first and before all, about

business processes, activities and human interactions.

88

Chadi Sassine, SOA responsible @

IBM G

BS

•W

hat kind of Design errors are you facing in SO

A projects? ‘ I observed an accum

ulation (anarchic) of web

services as well as the difficulty to link them

to the business processes and enterprise’s objectives. They should be aligned on the business”

89

Why SO

A projects fail?

•Lack of team

’s adhesion to the SOA Vision

•

Tools are not mature enough

•

No dissociation betw

een SOA and W

S

•Abusing of W

eb Services instead of focusing on Business Processes

•Scalability issues (the Service m

odel is quite costly)

90

Success Factors

•U

se of Components (loosely coupled)

•

Putting in place a comm

ittee for watching that SO

A Principles are alw

ays applied and followed by the developm

ent teams

•

Use of best practices and docum

ent them inside the organization

•

In earlier development stages, define KPI (Key Perform

ance Indicators) and im

plement them

in the furtur system. This w

ill help w

atching continuously the system’s perform

ance and QoS.

91

Advantages et drawbacks

Advantages •

adaptive Architecture •

Reuse of code (components)

•U

se of standards •

Better activity but in the long run (don’t expect results in the short term

) D

rawbacks

•Tools are not m

ature enough •

Latency •

Hard to im

plement som

etimes

•Q

os hard to check sometim

es

92

Next Step?

93

Références

•La série de livres sur SO

A de Thomas Erl

–w

ww

.thomaserl.com

•

Livres –

Open source SO

A in Action, de Jeff Davis, édition M

anning, 2009 –

Open source ESB in Action, de Tijs Radem

akers , édition M

anning, 2009 –

SOA (édition D

unod) –

Essential Business Process Modeling (M

/ Havey –O

’Reilly) –

SOA, le guide de l’architecte d’un SI agile, D

unod •

Sites: –

http://ww

w.soa-consortium

.org/

•Les articles / Présos de W

illy Goldgew

itch, expert ESB - Valtech

94