1 / 23

Crucial Patterns in Service-Oriented Architecture

Crucial Patterns in Service-Oriented Architecture. Jaroslav Král, Michal Žemlička Charles University, Prague. Service oriented system. An overloaded concept or often wrongly assumed to be a buzzword only In our sense

fayre
Download Presentation

Crucial Patterns in Service-Oriented Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • Fine grained (chatty), disclosing implementation details, changing, … • Not understandable for users (not user oriented) • It is crucial for the design of agile business processes and often solves the point 1 • 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 Data store Service 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 Optional user involvement Data source XSLT engine Messages

  14. Composite services • Head of the composite service: FEG with more than one distinguished service Services accessible from outside via EG only Head of composite service: Extended FEG EG Services outside the composite service Compositeservice

  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 • Middleware • Middleware enhancements, FEG, Data Stores • Application services, FEG • Composite services, Head of composite service • Services orchestration, Process managers • 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 placesare used in the theory of parallel processes

  22. Generalized Petri Place GPP The structure of GPP Supervision and control GPP 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

More Related