1. The Web services framework

1. PART III - WEB SERVICES AND PRIMITIVE SOA 1. The Web services framework

2. Framework • A technology framework is a collection of things. (objects) • It can include • one or more architectures • technologies • concepts • models • sub-frameworks

3. Web Services Framework (I) • an abstract concept defined by standards organizations and implemented by (proprietary) technology platforms • “core building blocks” that include Web services, service descriptions, and messages • a communications agreement centered around service descriptions based on WSDL • a messaging framework comprised of SOAP technology and concepts

4. Web Services Framework (II) • a service description registration and discovery architecture sometimes realized through UDDI • a well-defined architecture that supports messaging patterns and compositions • a second generation of Web services extensions (also known as the WS-* specifications) continually broadening

5. Relazioni strutturali

6. Punti chiave 3.1 • First- and second-generation technologies, along with design-agnostic concepts and implementation-neutral architectures, form an abstract Web services framework. • The fundamentals of this framework are in alignment with the core characteristics of primitive SOA.

7. 2. Services (as Web services)

8. Web Service classification • a temporary classification based on the roles it assumes during the runtime processing of a message • a permanent classification based on the application logic it provides and the roles it assumes within a solution environment SERVICE ROLE SERVICE MODELS

9. Service roles • A Web service is capable of assuming different roles, depending on the context within which it is used. • A service is therefore not labeled exclusively as a client or server, but instead as a unit of software capable of altering its role, depending on its processing responsibility in a given scenario. • It is not uncommon for a Web service to change its role more than once within a given business task. • It is especially not uncommon for a Web service within an SOA to assume different roles in different business tasks.

10. Service role : provider • The Web service is invoked via an external source, such as a service requestor • The Web service provides a published service description offering information about its features and behavior

11. Service Role : requestor • Any unit of processing logic capable of issuing a request message that can be understood by the service provider is classified as a service requestor. • A Web service is always a service provider but also can act as a service requestor. • A Web service takes on the service requestor role under the following circumstances: • The Web service invokes a service provider by sending it a message [GO] • The Web service searches for and assesses the most suitable service provider by studying available service descriptions

12. Services swapping roles – Case Study 3.2.1

13. Intermediaries • Web services communication is based on the use of messaging paths because once a service provider submits a message, it can be processed by multiple intermediate routing and processing agents before it arrives at its ultimate destination. • Web services and service agents that route and process a message after it is initially sent and before it arrives at its ultimate destination are referred to as intermediaries or intermediary services. • Because an intermediary receives and submits messages, it always transitions through service provider and service requestor roles [GO]

14. Types of intermediaries • passive intermediary, • is typically responsible for routing messages to a subsequent location • It may use information in the SOAP message header to determine the routing path, • Either way, what makes this type of intermediary passive is that it does not modify the message.[GO]

15. Active intermediaries • Like passive intermediary services, active intermediaries also route messages to a forwarding destination. • Prior to transmitting a message, however, these services actively process and alter the message contents • Typically, active intermediaries will look for particular SOAP header blocks and perform some action in response to the information they find there. • They almost always alter data in header blocks and may insert or even delete header blocks entirely [GO]

16. Case Study 3.2.2 Passive Intermediary After shipping a TLS order, RailCo's Invoice Submission Service transmits a message containing an electronic invoice. The first TLS Web service to receive the message is a passive intermediary called the Load Balancing Service. Its purpose is to provide load balancing logic by checking the current processing statistics of available TLS servers. When the server with the lowest usage is identified, this passive intermediary routes the message accordingly. Upon receiving the message from the Invoice Submission Service requestor, the passive Load Balancing intermediary acts as the service provider. After it has determined where the message is to be forwarded to, it changes its role to service requestor to forward the invoice document to the destination Accounts Payable Service provider.

17. Case Study 3.2.3 Active Intermediary TLS employs a number of active intermediaries. The Internal Policy Service, for example, examines the message to determine whether it is subject to any internal policy restrictions. If it is, the active intermediary inserts a new header block containing one or more policy rules used by subsequent service providers. As with the passive intermediary example, the active intermediary transitions through service provider and service requestor roles before finally forwarding the message to the appropriate TLS service provider.

18. Initial sender and ultimate receiver • Initial senders are simply service requestors that initiate the transmission of a message. • Therefore, the initial sender is always the first Web service in a message path. • The counterpart to this role is the ultimate receiver. • This label identifies service providers that exist as the last Web service along a message's path

19. These three physical services created four logical roles to complete two service requestor-to-service provider transmissions. There was, however, only one Web service that initiated the transmission. This was the Invoice Submission Service, and it is therefore considered the initial sender. Similarly, there was only one Web service that ended the overall activity, which makes the Accounts Payable Service the ultimate receiver. Case Study 3.2.4 Expanding on the previous example that demonstrated the use of a passive intermediary, let's take a look at all the services involved in that message exchange. In this scenario, we had the RailCo Invoice Submission Service (acting as the service requestor) initiating the message transmission. By receiving the message, the Load Balancing intermediary acts as the service provider. Upon routing the message, the intermediary temporarily assumes the service requestor role and sends the message to the Accounts Payable Service, another service provider

20. Service Composition • This particular term does not apply to a single Web service, but to a composite relationship between a collection of services. • Any service can enlist one or more additional services to complete a given task. Further, any of the enlisted services can call other services to complete a given sub-task. Therefore, each service that participates in a composition assumes an individual role of service composition member[GO] • The concept of service composability is very important to service-oriented environments • In fact, service composition is frequently governed by WS-* composition extensions, such as WS-BPEL and WS-CDL, which introduce the related concepts of orchestration and choreography, respectively

21. Case Study 3.2.5 When the TLS Accounts Payable Service receives an invoice, it invokes a series of additional services to fully process the invoice contents: It first uses the Vendor Profile Service to validate the invoice header data and link the invoice document to a vendor account. Next, the Accounts Payable Service extracts taxes and shipping fees and directly logs all amounts into the appropriate A/P accounts. Finally, the Accounts Payable Service passes the Ledger Service the invoice total, which it uses to update the General Ledger.

22. Service models • The manner in which services are being utilized in the real world, though, has led to a classification based on the nature of the application logic they provide, as well as their business-related roles within the overall solution. • These classifications are known as service models

23. Business service model • as fundamental building blocks for the representation of business logic • to represent a corporate entity or information set • to represent business process logic • as service composition members

24. Utility service model • as services that enable the characteristic of reuse within SOA • as services that promote the intrinsic interoperability characteristic of SOA • as the services with the highest degree of autonomy

25. Case Study 3.2.6 • In the examples we've gone through so far in this lesson, we've described eight Web services. Six of these are business services, while the other two are utility services, as follows: • Accounts Payable Service = business service • Internal Policy Service = utility service • Invoice Submission Service = business service • Ledger Service = business service • Load Balancing Service = utility service • Order Fulfillment Service = business service • Purchase Order Service = business service • Vendor Profile Service = business service • The Load Balancing and Internal Policy Services are classified as utility services because they provide generic functionality that can be reused by different types of applications. The application logic of the remaining services is specific to a given business task or solution, which makes them business-centric services.

26. Controller Service Model • to support and implement the principle of composability • to leverage reuse opportunities • to support autonomy in other services

27. Case Study 3.2.6 In our previous example we demonstrated how the Accounts Payable Service initiated and coordinated a service composition consisting of two additional composition members. That would classify the Accounts Payable Service as a controller service. The fact that we already labeled this service as a business service does not conflict with this new classification; a single service can be classified as more than one service model

28. Punti chiave 3.2 Key points • Web services can be labeled using temporary and permanent classifications. • Temporary classifications relate to roles assumed by a service at runtime. • For example, an intermediary service can transition through different roles while processing a message. • Service models refer to permanent classifications that represent the logic housed by the service, as well as its role within the overall solution. • A service can belong to more than one service model.

29. 3. Service descriptions (with WSDL)

30. WSDL definitions enable loose coupling between services

31. Case Study 3.3.1

32. Service endpoints and description • A WSDL describes the point of contact for a service provider, also known as the service endpoint or just endpoint. • Provides a formal definition of the endpoint interface • requestors wishing to communicate with the service provider know exactly how to structure request messages • Establishes the physical location (address) of the service.

33. WSDL document consisting of abstract and concrete parts that collectively describe a service endpoint

34. Abstract description (I) • Establishes the interface characteristics of the Web service without any reference to the technology used to host or enable a Web service to transmit messages. • By separating this information, the integrity of the service description can be preserved regardless of what changes might occur to the underlying technology platform

35. Abstract description (II) • Parent portType section • provides a high-level view of the service interface. • Each operation represents a specific action performed by the service. • An operation consists of a set of input and output messages. • Much like component methods, operations also have input and output parameters. Because Web services rely exclusively on messaging-based communication, parameters are represented as messages.

36. Concrete description (I) • For a Web service to be able to execute any of its logic, it needs for its abstract interface definition to be connected to some real, implemented technology. • Because the execution of service application logic always involves communication, the abstract Web service interface needs to be connected to a physical transport protocol. • This connection is defined in the concrete description portion of the WSDL file, which consists of three related parts

37. Concrete description (II) • binding describes the requirements for a service to establish physical connections. • In other words, a binding represents one possible transport technology the service can use to communicate. • SOAP is the most common form of binding, but others also are supported. • A binding can apply to an entire interface or just a specific operation. • Related to the binding is the port, which represents the physical address at which a service can be accessed with a specific protocol. • This piece of physical implementation data exists separately to allow location information to be maintained independently from other aspects of the concrete description. • Within the WSDL language, the term service is used to refer to a group of related endpoints. The term "port" is being renamed "endpoint" in version 2.0 of the WSDL specification

38. Case Study 3.3.2 • The TLS Accounts Payable Service was created to receive invoices submitted by numerous vendors. • Its associated service description therefore has a simple abstract description consisting of one interface definition that contains a single operation called SubmitInvoice. • Specified within the operation is one input and one output message. • The input message is responsible for accepting the invoice document from a vendor service requestor (such as the RailCo Invoice Submission Service). • The output message is used by the Accounts Payable Service to send a message of acknowledgement indicating that the submitted invoice document has been successfully received and that its contents are valid. • The concrete part of this service description simply binds the operation to the SOAP protocol and provides a location address for the Accounts Payable Service.

39. Metadata (I) • We've established that the abstract and concrete descriptions provided by a WSDL definition express technical information as to how a service can be interfaced with and what type of data exchange it supports. • WSDL definitions frequently rely on XSD schemas to formalize the structure of incoming and outgoing messages. • Another common supplemental service description document is a policy. • Policies can provide rules, preferences, and processing details above and beyond what is expressed through the WSDL and XSD schema documents.

40. Metadata (II) • We have up to three separate documents that each describe an aspect of a service: • WSDL definition • XSD schema • Policy • Each of these three service description documents can be classified as service metadata, as each provides information about the service.

41. Service contracts • Service description documents can be collectively viewed as establishing a service contract • a set of conditions that must be met and accepted by a potential service requestor to enable successful communication

42. Semantics Description • provide sufficient semantic information in a structured manner so that, in some cases, service requestors can go as far as to evaluate and choose suitable service providers independently. • greater importance when dealing with external service providers, where your knowledge of another party's service is limited to the information the service owner decides to publish. • efforts are currently underway (primarily by the W3C) to continually extend the semantic information provided by service description documents

43. Service description advertisement and discovery • locate the latest versions of known service descriptions • discover new Web services that meet certain criteria • When the initial set of Web services standards emerged, this eventuality was taken into account. This is why UDDI formed part of the first generation of Web services standards. Though not yet commonly implemented, UDDI provides us with a registry model worth describing.

44. Service description locations centralized in a registry These registries can be searched manually and accessed programmatically via a standardized API.

45. Private and public registries • Public registries accept registrations from any organizations, regardless of whether they have Web services to offer. • Once signed up, organizations acting as service provider entities can register their services. • Private registries can be implemented within organization boundaries to provide a central repository for descriptions of all services the organization develops, leases, or purchases.

46. UDDI registry records (I) • Business entities • Each public registry record consists of a business entity containing basic profile information about the organization (or service provider entity). • Included in this record are one or more business service areas, each of which provides a description of the services offered by the business entity. • Business services may or may not be related to the use of Web services.

47. UDDI registry records (II) • Registry records store binding information in a separate area, called the binding template. • Each business service can reference one or more binding templates. • The information contained in a binding template may or may not relate to an actual service. (For example, a binding template may simply point to the address of a Web site. ) • If a Web service is being represented, then the binding template references a tModel. • The tModel section of a UDDI record provides pointers to actual service descriptions

48. Basic Structure of UDDI business entity record

49. Case Study 3.3.3 At any given time there are several concurrent development and integration projects underway at TLS. Almost every project results in the creation of new services. Some are developed as part of service-oriented solutions, while others originate from legacy adapters and ancillary services appended to older distributed systems. The net result is a constantly growing pool of unmanaged services. After a year-end review of past development initiatives, it was discovered that several project teams had inadvertently built Web services with very similar functionality. To avoid a recurrence of redundant effort, a private registry was created . Project teams responsible for any currently active service descriptions were required to register their services in the registry (and this registration process became part of the standard development lifecycle from there on).

50. Punti chiave 3.3 • The WSDL definition is divided into two parts: the abstract description that defines the service interface, and the concrete description that establishes the transport and location information. • The two other primary service description documents are XSD schemas and policies. • Service descriptions can be dynamically discovered by humans or applications, using private or public service registries.