Activity Management and Composition

1. PART IV - contemporary SOA Activity Management and Composition

2. 1. Message Exchange Patterns

3. Message Exchange Consideration • Every task automated by a Web service can differ • nature of the application logic being executed • the role played by the service • Regardless of how complex a task is, almost all require the transmission of multiple messages. • The challenge lies in coordinating these messages in a particular sequence so that the individual actions performed by the message are executed properly and in alignment with the overall business task

4. MEP • Message exchange pattern (MEP)is a template that establishes a pattern for the exchange of messages between SOAP nodes. • Generalized to Web services, a message exchange pattern is a template that establishes a pattern for the exchange of messages between two communicating parties. • MEP definitions will therefore be used by several technologies in the Web services architecture: • communication protocols such as SOAP • description languages such as WSDL

5. Primitive MEPs: Request-response • The request-response MEP establishes a simple exchange in which a message is first transmitted from a source (service requestor) to a destination (service provider). Upon receiving the message, the destination (service provider) then responds with a message back to the source (service requestor).

6. Case Study 4.1.1 In the Service compositions section, we provided an example where the TLS Accounts Payable Service, upon receiving an invoice submission from a vendor, enlists the TLS Vendor Profile Service to validate the invoice header information.

7. Case Study 4.1.1 [segue] The MEP used in this situation is the standard request-response pattern, where a response from the Vendor Profile Service is expected once it receives and processes the original request. The Accounts Payable Service requires a response to ensure that the header details provided in the invoice submission are valid and current Failure to validate this information terminates the Invoice Submission Process and results in the Accounts Payable Service responding to the vendor with a rejection message.

8. Primitive MEPs: fire-and-forget • This simple asynchronous pattern is based on the unidirectional transmission of messages from a source to one or more destinations

9. Fire-and-forget MEP variations • The single-destination pattern, where a source sends a message to one destination only. • The multi-cast pattern, where a source sends messages to a predefined set of destinations. • The broadcast pattern, which is similar to the multi-cast pattern, except that the message is sent out to a broader range of recipient destinations.

10. Case Study 4.1.2 The TLS Accounts Payable Service contains a rule that when an invoice header fails validation, an e-mail notification is generated. To execute this step, the Accounts Payable Service sends a message to the Notification Service. This utility service records the message details in a notification log database. (These records are used as the basis for e-mail notifications, as explained in the next example.) Because the message sent from the Accounts Payable Service to the Notification Service requires no response, it uses a single-destination fire-and-forget MEP

11. Complex MEPs • Primitive MEPs can be assembled in various configurations to create different types of messaging models, sometimes called complex MEPs. • A classic example is the publish-and-subscribe model

12. The publish-and-subscribe messaging model is a composite of two primitive MEPs • Step 1 could be implemented by a request-response MEP, where the subscriber's request message, indicating that it wants to subscribe to a topic, is responded to by a message from the publisher, confirming that the subscription succeeded or failed. • Step 2 then could be supported by one of the fire-and-forget patterns, allowing the publisher to broadcast a series of unidirectional messages to subscribers.

13. Case Study 4.1.3 The utility Notification Service periodically generates and distributes notification messages for a number of different topics. Messages from outside vendors that fail validation, for example, are first logged in a dedicated notification repository. At the end of every working day, the Notification Service queries this repository to retrieve all failed submissions. It then summarizes specific pieces of information from the query results and uses this data to populate a broadcast notification message. This message is subsequently sent to a list of subscribers consisting primarily of specialized accounting services . These services record the notification data into various profile and account records. Some pass the notification on as an e-mail to select accounting personnel.

14. MEPs and WSDL • MEPs play a larger role in WSDL service descriptions as they can coordinate the input and output messages associated with an operation. ( esempio ) • WSDL defines several combination of input and output as part of a PortType description: • Input-Output Operations. • Input-Only Operations. • Output-Input Operations. • Output-Only Operations.

15. WSDL support : Request-response operation • Upon receiving a message, the service must respond with a standard message or a fault message.

16. WSDL support : Solicit-response operation • Upon submitting a message to a service requestor, the service expects a standard response message or a fault message.

17. WSDL support : One-way operation • The service expects a single message and is not obligated to respond.

18. WSDL support : Notification operation • The service sends a message and expects no response.

19. Punti Chiave 4.1 • An MEP is a generic interaction pattern that defines the message exchange between two services. • MEPs can be composed to support the creation of larger, more complex patterns. • The WSDL specifications support specific variations of common MEPs.

20. 2. Service ACTIVITY

21. Service activity • In service-oriented solutions, each task can involve any number of services. • The interaction of a group of services working together to complete a task can be referred to as a service activity

22. Simple or primitive activity • A simple or primitive activity is typified by synchronous communication and therefore often consists of two services exchanging information using a standard request-response MEP

23. Complex activities • Complex activities, on the other hand, can involve many services (and MEPs) that collaborate to complete multiple processing steps over a long period of time

24. Service Activity and SOA • Activities represent any service interaction required to complete business tasks. • The scope of a service activity is primarily concerned with the processing and communication between services only

25. Case Study 4.2.1 1. The initial sender, RailCo's Invoice Submission Service, transmits the invoice message 2. The message is first received by a passive intermediary, which routes the message according to environmental conditions. The message subsequently arrives at TLS's Accounts Payable Service. 3. The Accounts Payable Service acts as a controller and initiates a service composition to begin processing the message contents. It begins by interacting with the Vendor Profile Service to validate invoice header data and attaches the invoice document to the vendor account. 4. The Accounts Payable Service then extracts taxes, shipping fees, and the invoice total. It passes these values to the Ledger Service, which updates various ledger accounts, including the General Ledger 5. Finally the activity ends, as the Accounts Payable Service completes its processing cycle by sending a response message back to RailCo

26. Punti Chiave 4.2 • An activity is a generic concept used to represent a task or a unit of work performed by a set of services. • The scope of primitive activities can be limited to the completion of simple MEPs. • Complex activities are common within SOAs and exist as part of any non-trivial service-oriented application

27. 3. COORDINATION

28. COORDINATION • Every activity introduces a level of context into an application runtime environment. • Something that is happening or executing has meaning during its lifetime, and the description of its meaning (and other characteristics that relate to its existence) can be classified as context information. • The more complex an activity, the more context information it tends to bring with it. • The complexity of an activity can relate to a number of factors, including: • the amount of services that participate in the activity • the duration of the activity • the frequency with which the nature of the activity changes • whether or not multiple instances of the activity can concurrently exist

29. Coordination framework • provide a means for context information in complex activities to be managed, preserved and/or updated, and distributed to activity participants.

30. Example

31. Collect Equipment chuck bob Prepare Water jim Wash the car Car wash simple task

32. I chuck chuck II II bob bob III jim jim III Car wash steps Locate bucket. - Locate sponge. Locate hose

33. Car wash considerations • In this scenario, the bucket availability status is considered context information that I managed. • Because a separate context manager was in place, Chuck was alleviated of the responsibility of remembering and communicating the context information to Bob. • This liberate Chuck to continue with his other work. • It also saved Bob from having to directly locate and communicate with Chuck to get the context information. • Finally, my knowledge of who was doing what in this car washing process also would be classified as context information.

34. This service controls a composition of three other services that each play a specific part in the management of context data. Coordinator service model WS-Coordination establishes a framework that introduces a generic service based on the coordinator service model

35. Coordinator service • Protocol-specific services • These services represent the protocols supported by the coordinator's coordination type. • Activation service • Responsible for the creation of a new context and for associating this context to a particular activity • Registration service • Allows participating services to use context information received from the activation service to register for a supported context protocol • Coordination service. • The controller service of this composition

36. In poche parole …..

37. Coordination type • Each coordinator is based on a coordination type, which specifies the nature and underlying logic of an activity for which context information is being managed. • The WS-Coordination framework can be utilized by different coordination types. • WS-AtomicTransaction • WS-BusinessActivity • Coordination type extensions provide a set of coordination protocols

38. Coordination protocol • The actual process that a coordinator uses to communicate with an application is defined by the coordination protocol chosen by the application. • The coordination protocol defines a series of messages between the coordinator and each application that is participating in the coordination. • In a single coordination, each participating Web service application can request to use a different protocol when communicating with the coordinator

39. Coordination Context • A context created by the activation service is referred to as a coordination context • The coordination context contains all of the coordination-related information for a coordinated process and is defined in a SOAP message by the CoordinationContext element in the SOAP message header. • can contain the following information: • Expiration value • Identifier (unique) that represents the activity • Coordination type Defines the type of coordination process that the coordination context has been defined for. • Registration service Address of the service from which another Web service can request entry into the coordinated process. • Other coordination-specific information The Coordination-Context element is extensible and can be used to carry other application-specific information relating to the coordinated process.

40. Coordination Partecipants • service that wants to take part in an activity managed by WS-Coordination must request the coordination context from the activation service. • It then can use this context information to register for one or more coordination protocols. • A service that has received a context and has completed registration is considered a participant in the coordinated activity.

41. The instantiated process This invitation consists of the context information the application service originally received from the activation service. Upon a successful registration, a service is officially a participant. The registration service passes the service the location of the coordinator service, with which all participants are required to interact. Any Web service in possession of this context information may issue a registration request to the registration service. This allows the service to enlist in a coordination based on a specific protocol. Via a CreateCoordinationContext request message, it asks the activation service to generate a set of new context data. Once passed back with the ReturnContext message, the application service now can invite other services to participate in the coordination. The coordination service composition is instantiated when an application service contacts the activation service

42. The completion process The application service can request that a coordination be completed by issuing a completion request message to the coordination service. The coordinator, in turn, then issues its own completion request messages to all coordination participants. Each participant service responds with a completion acknowledgement message

43. Coordination and SOA

44. Case Study 4.3.1 As shown in Figure coordination is applied to the following steps: 3. The Accounts Payable Service uses the Vendor Profile Service to validate the invoice header data. If the data is valid, the invoice document is attached to the vendor account.4. The Accounts Payable Service extracts taxes and shipping fees from the invoice document. These values, along with the invoice total, are submitted to the Ledger Service. The Ledger Service is responsible for updating the General Ledger and numerous sub-ledgers, such as the Accounts Payable Ledger. In the previous case study example, we established the individual process steps that comprised a complex activity. Once the processing of this activity enters the TLS environment, TLS employs a context management system to coordinate the flow of the message through its internal services.

45. A message construct used to request the creation of a context <CreateCoordinationContext> <ActivationService> <wsu:Address> http://www.examples.ws/activation </wsu:Address> </ActivationService> <RequesterReference> <wsu:Address> http://www.xmltc.com </wsu:Address> </RequesterReference> <CoordinationType> http://schemas.xmlsoap.org/ws/2002/08/wstx </CoordinationType> </CreateCoordinationContext> The ActivationService element defines the address of the service that will create (activate) the context. The RequesterReference element contains the address to which the response message should be sent. The CoordinationType construct indicates which type of coordinator we would like to create. The use of the http://schemas.xmlsoap.org/ws/2002/08/wstx URI ndicates that we are requesting an atomic transaction coordination type, as specified in the WS-Transaction specification.

46. Key Points 4.3 • Complex activities tend to introduce the requirement for context data and the subsequent need for this data to be managed and coordinated at runtime. • WS-Coordination provides a context management framework using a standardized service composition headed by a coordinator service. • Specialized implementations of this framework are realized through the use of coordination types, such as WS-AtomicTransaction and WS-BusinessActivity. • By introducing an activity management layer to SOA, coordination promotes service composability and supports the controlled composition of complex activities

47. 4. BUSINESS TRANSACTION (BT)

48. Transaction • Termine generico che si riferisce ad ogni attività che crea, aggiorna o cancella i dati in un database • Quando un set ordinato di operazioni è “modulato” come una transazione allora tutto l’insieme è visto come “one logic operation” • Gli effetti della transazione si vedono quando questa unica operazione logica si è conclusa con successo • Se l’operazione fallisce allora non è successo niente

49. ACID • In generale le proprietà delle transazioni sono conosciute come proprietà ACID, ossia che assicurano Atomicità, Consistenza, Isolamento e Persistenza (Durabilità). • Ad esempio un sistema di gestione di basi di dati, conduce le transazioni in modo da garantire la consistenza dei “data records” anche quando vengono eseguite più operazioni in concorrenza su di essi.

50. ACID properties of data • Atomic • L’atomicità rappresenta il fatto che la transazione è un’unita indivisibile di esecuzione; o vengono resi visibili tutti gli effetti di una transazione, oppure la transazione non deve avere alcun effetto. Viene quindi seguito un approccio “tutto o niente” dove non è possibile lasciare la transazione in uno degli stati intermedi attraversati durante l’elaborazione • Consistent • richiede che al termine della transazione tutti i dati manipolati siano coerenti con la semantica della transazione stabilita da una logica di business. • Isolated • richiede che l’esecuzione di una transazione sia completamente indipendente dalla contemporanea esecuzione di altre transazioni. In un ambiente distribuito l’isolamento nasconde anche gli stati intermedi di una transazioni rendendoli inaccessibili dall’esterno. • Durable • richiede che l’effetto di una transazione che abbia eseguito il commit correttamente non venga più perso.