Crucial Patterns in Service-Oriented Architecture

Jaroslav Král, Michal ŽemličkaCharles University, Prague

Service oriented system An overloaded concept or often wrongly

assumed to be a buzzword only In our sense

A collection of software objects (services) behaving like the services in human society

More than one unsettled request at a time No inherent master-slave hierarchy

Loosely related Forming a virtual p2p network

Communication of services enabled by a middleware

Confederations and alliances

Confederation the communication partners need not be looked for to

be able to start communication as they know each other

A broad collection of cases, e-government, majority of ERP system, global information systems

Less strict requirements on the use of standards SOAP document encoding and user oriented service

interfaces possible

Alliance –, e-commerce on web

We will discuss mainly confederations Application of solutions in alliances usually possible

SOA and legacy systems Legacy systems must be often

integrated, examples: Information systems of particular offices in e

government Collaborating IS of co business partners

E.g. SCM an CRM or collaborating health service institutions

The best known way of the integration is the integration of the legacies as services into a confederation

Interfaces between legacies need not be satisfactory as they are

1. Fine grained (chatty), disclosing implementation details, changing, …

2. Not understandable for users (not user oriented)

It is crucial for the design of agile business processes and often solves the point 1

3. Features not supported by middleware Complex communication rules User involvement into the communication

Possible solution –Front-end gate (FEG) A generalized adapter transforming

unsatisfactory interface, there an be different FEGs for specific groups of parers

An specific service supporting the design of architecture

XSLT can be used

Portals and front-end gates

Portal can be implemented using the same technology as FEGś It can be good to have more than one FEG as well as portals

Portals and FEG have specific roles

They are used as architecture building tools

We call them architecture services They typically are developed as

white boxes, often from scratch

Further architecture services

Portals Data stores Heads of composite services Process managers Generalized Petri places

The crucial pattern of SOA

The construction of SOA as an structure consisting of the services of two types application services (basic functionality) architecture services used to design and implement system architecture

Data store in the sense of structured programming

Data store as a tool of batch communication

Many other possibilities

Batch Applications

ServiceData store

Service

Why data stores in SO Some algorithms are too complex to be executed online.

The components implementing such algorithms must then work in batch mode and their outputs must be stored in a data store possibly implemented as a specialized data-oriented service

The communication must be supervised and possibly committed/blocked by users. It is typical for business processes.

Data store services can be used to implement sophisticated communication schemas (e.g. more complex than publish-subscribe)

There can be reasons to change dynamically the destination of a message due the facts known to users only

Implementation of data stores

Via adding data tier to front-end gates Possibly as an extension of XSLT

engine

XSLT engine

Messa

ge

s

Data source

Optional user involvement

Composite services

Head of the composite service: FEG with more than one distinguished service

Head of composite service: Extended FEG EG

Services accessible from outside via EG only

Services outside the composite service

Composite service

Business processes use - requirements Enabling agile changes caused changing

business conditions, insufficient process control data quality and growing experience

User orientation of interfaces Process owner should commit risky process steps Various experts should understood the process

details to be able resolve business incidents e.g. at a court

It is desirable not to lost business intelligence or experience included in existing business process models written in languages different from BPEL

Implementation: Service Business Manager Process enactment

A new service P called Process manager is generated on the request process owner PO, P provides the interface for PO

A process control structure C is generated inside P (typically in BPEL) using process parameters. A process model M from a repository of process models can be used in this phase

Process execution C is interpreted and P sends service request messages

to services able to perform them PO can optionally generate C without using the

repository of process models PO can supervise the process, change it or commit

process steps The implementation fulfils above requirements

Tuning of business processes

Easy screen prototypes If the messages are in XML and

user interface uses a good browser we can easily simulate a service S not implemented yet by rediredicting the messages for S to user portal able to answer the messages properly

Verified in practice A very useful solution

Layers of SOSS, related Architecture services

1. Middleware2. Middleware enhancements, FEG, Data

Stores3. Application services, FEG4. Composite services, Head of composite

service5. Services orchestration, Process

managers6. System portal(s), Portals

Observation Very similar constructs in different layers

FEG, Head of Composite Service and Portal in application services, composite service and user interfaces

Data Stores and Process Managers in middleware enhancement and service orchestration

The concept of architecture service is very powerful and admits a flexible use

The large scale structure in SOSS is rather the matter of use than of program conctructs (compare classes and objects in object oriented systems)

Summary of the capabilities of architecture services Basic capabilities

Supervising by process owners Transforming tuples of input messages onto tuples of

output messages Data store Message routing Logging

All the discussed cases are therefore a specific subclasses of the general concept - Generalized Petri place.

Petri places are used in the theory of parallel processes

Generalized Petri Place GPP

The structure of GPP

GPP

Supervision and control

Input message

s

Output messages

log

User interface can be used by business partners to see process control

Most important Service-Oriented Patterns Architecture Services (front-end

gates, portals, process managers, extended gates, generalized Petri places) and Application Processes

Screen Prototypes User-Oriented Interfaces of services Not discussed No central service like

UDDI in large scale global SOSS