1. Crucial Patterns in Service- Oriented Architecture Jaroslav Král, Michal Žemlička Charles University, Prague

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. Further architecture services Portals Data stores Heads of composite services Process managers Generalized Petri places

10. 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

11. Data store in the sense of structured programming Data store as a tool of batch communication Many other possibilities Batch Applications Service Data store Service

12. 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

13. Implementation of data stores Via adding data tier to front-end gates Possibly as an extension of XSLT engine XSLT engine Messages Data source Optional user involvement

14. 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

15. 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

16. 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

17. Tuning of business processes

18. 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

19. Layers of SOSS, related Architecture services 1. Middleware 2. Middleware enhancements, FEG, Data Stores 3. Application services, FEG 4. Composite services, Head of composite service 5. Services orchestration, Process managers 6. System portal(s), Portals

20. 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)

21. 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

22. Generalized Petri Place GPP The structure of GPP GPP Supervision and control Input messages Output messages log User interface can be used by business partners to see process control

23. 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