crucial patterns in service-oriented architecture
Post on 25-Jan-2016
38 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related