What are Web Services Quotes from Alonso et

What are ‘Web Services’? (Quotes from Alonso et al. ) • ‘A form of distributed information system’ (p. 1) • ‘“a software application identified by a URI, whose interfaces and bindings are capable of being discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols”’(p. 124, quoting Web Service Architecture Requirements document (Oct. 2002) at W 3 C) 3

Web Services & Middleware (Quote from Alonso et al. ) • ‘In middleware terms, a service is a procedure, method, or object with a stable, published interface that can be invoked by clients. • The invocation, and this is very important, is made by a program. Thus, requesting and executing a service involves a program calling another program. ’ (p. 131, their emphasis) 4

Objectives for this topic o o Understanding Web services In order to understand Web services, we need to take a step back and look at the way middleware and enterprise application integration technology has been evolving in the last decades. Only so we will then be able to understand Web services. The most popular version of Web services (SOAP, UDDI, and WSDL) is a very poor and limiting view on what true Web services should be. Alternative proposals such as eb. XML, x. CBL, or Rosetta. Net provide a much deeper insight on what is needed for electronic commerce through Web services. Putting Web services into perspective o We will go over the basic Web service technology available today and discuss SOAP, UDDI and WSDL in detail. o We will also discuss what can be done with these specifications and what is missing nowadays for them to be truly useful tools for electronic commerce. o The course aims at developing a critical understanding of Web technology and its possibilities today. The goal is for participants to be able to look at current and future developments with enough background to be able to judge how much of a contribution they are and what their true potential is. Modified from original ©Gustavo Alonso, ETH Zürich. 5

Sub-topics Layers and Tiers § Why Middleware & Why not client/server The Service World § Motivation for changes to middleware model § Bottom-up & Top-down thinking Messages, Documents, and Processes § Asynchronous coordination The WWW Protocols That make it all happen § SOAP (Simple object access protocol) § UDDI (Universal discovery description & integration) § WSDL (Web services description language) ©Gustavo Alonso, ETH Zürich. 6

Layers and tiers Client Application Logic Resource Manager Presentation layer Client is any user or program that wants to perform an operation over the system. Clients interact with the system through a presentation layer o The application logic determines what the system actually does. It takes care of enforcing the business rules and establish the business processes. The application logic can take many forms: programs, constraints, business processes, etc. o The resource manager deals with the organization (storage, indexing, and retrieval) of the data necessary to support the application logic. This is typically a database but it can also be a text retrieval system or any other data management system providing querying capabilities and persistence. Business rules Business objects Client Server Business processes Database Persistent storage ©Gustavo Alonso, ETH Zürich. o 7

A game of boxes and arrows o o There is no problem in system design that cannot be solved by adding a level of indirection. There is no performance problem that cannot be lessened by removing a level of indirection. Modified from original ©Gustavo Alonso, ETH Zürich. o o Each box represents a part of the system. Each arrow represents a connection between two parts of the system. The more boxes, the more modular the system: more opportunities for distribution and parallelism. This allows encapsulation, component based design, reuse. The more boxes, the more arrows: more sessions (connections) need to be maintained, more coordination is necessary. The system becomes more complex to monitor and manage. The more boxes, the greater the number of context switches and intermediate steps to go through before one gets to the data. Performance suffers considerably. System designers try to balance the flexibility of modular design with the performance demands of real applications. Once a layer is established, it tends to migrate down and merge with lower layers. 8

One tier: fully centralized o 1 -tier architecture o o Server ©Gustavo Alonso, ETH Zürich. The presentation layer, application logic and resource manager are built as a monolithic entity. Users/programs access the system through display terminals but what is displayed and how it appears is controlled by the server. (These are “dumb” terminals). This was the typical architecture of mainframes, offering several advantages: Þ no forced context switches in the control flow (everything happens within the system), Þ all is centralized, managing and controlling resources is easier, Þ the design can be highly optimized by blurring the separation between layers. 9

Two tier: client/server 2 -tier architecture Server ©Gustavo Alonso, ETH Zürich. o As computers became more powerful, it was possible to move the presentation layer to the client. This has several advantages: Þ Clients are independent of each other: one could have several presentation layers depending on what each client wants to do. Þ One can take advantage of the computing power at the client machine to have more sophisticated presentation layers. This also saves computer resources at the server machine. Þ It introduces the concept of API (Application Program Interface). An interface to invoke the system from the outside. It also allows designers to think about federating the systems into a single system. Þ The resource manager only sees one client: the application logic. This greatly helps with performance since there are no client connections/sessions to maintain. 10

API in client/server o o Client/server systems introduced the notion of service (the client invokes a service implemented by the server) Together with the notion of service, client/server introduced the notion of service interface (how the client can invoke a given service) Taken all together, the interfaces to all the services provided by a server (whethere application or system specific) define the server’s Application Program Interface (API) that describes how to interact with the server from the outside Many standardization efforts were triggered by the need to agree to common APIs for each type of server’s API service interface service server service interface resource management layer ©Gustavo Alonso, ETH Zürich. 11

Technical aspects of the 2 tier architecture o There are clear technical advantages when going from one tier to two tier architectures: Þ take advantage of client capacity to off-load work to the clients Þ work within the server takes place within one scope (almost as in 1 tier), Þ the server design is still tightly coupled and can be optimized by ignoring presentation issues Þ still relatively easy to manage and control from a software engineering point of view o However, two tier systems have disadvantages: Þ The server has to deal with all possible client connections. The maximum number of clients is given by the number of connections supported by the server. Þ Clients are “tied” to the system since there is no standard presentation layer. If one wants to connect to two systems, then the client needs two presentation layers. Þ There is no failure or load encapsulation. If the server fails, nobody can work. Similarly, the load created by a client will directly affect the work of others since they are all competing for the same resources. ©Gustavo Alonso, ETH Zürich. 12

The main limitation of client/server o Server A o Server B If clients want to access two or more servers, a 2 -tier architecture causes several problems: Þ the underlying systems don’t know about each other Þ there is no common business logic Þ the client is the point of integration (increasingly fat clients) ©Gustavo Alonso, ETH Zürich. o Þ The responsibility of dealing with heterogeneous systems is shifted to the client. Þ The client becomes responsible for knowing where things are, how to get to them, and how to ensure consistency This is tremendously inefficient from all points of view (software design, portability, code reuse, performance since the client capacity is limited, etc. ). There is very little that can be done to solve this problems if staying within the 2 tier model. 13

Three tier: middleware 3 -tier architecture o o o ©Gustavo Alonso, ETH Zürich. In a 3 tier system, the three layers are fully separated. The layers are also typically distributed taking advantage of the complete modularity of the design (in two tier systems, the server is typically centralized) A middleware based system is a 3 tier architecture. This is a bit oversimplified but conceptually correct since the underlying systems can be treated as black boxes. In fact, 3 tier makes only sense in the context of middleware systems (otherwise the client has the same problems as in a 2 tier system). 14

Middleware o clients Middleware or global application logic o Local resource managers middleware o Server A ©Gustavo Alonso, ETH Zürich. Server B Middleware is just a level of indirection between clients and other layers of the system. It introduces an additional layer of business logic encompassing all underlying systems. By doing this, a middleware system: Þ simplifies the design of the clients by reducing the number of interfaces, Þ provides transparent access to the underlying systems, Þ acts as the platform for intersystem functionality and high level application logic, and Þ takes care of locating resources, accessing them, and gathering results. But a middleware system is just a system like any other! It can also be 1 tier, 2 tier, 3 tier. . . 15

Technical aspects of middleware o o The introduction of a middleware layer helps in that: Þ the number of necessary interfaces is greatly reduced: • clients see only one system (the middleware), • local applications see only one system (the middleware), Þ it centralizes control (middleware systems themselves are usually 2 tier), Þ it makes necessary functionality widely available to all clients, Þ it allows to implement functionality that otherwise would be very difficult to provide, and Þ it is a first step towards dealing with application heterogeneity (some forms of it). The middleware layer does not help in that: Þ it is another indirection level, Þ it is complex software, Þ it is a development platform, not a complete system ©Gustavo Alonso, ETH Zürich. 16

A three tier middleware based system. . . External clients middleware system External client internal clients control connecting logic user logic middleware 2 tier systems wrappers ©Gustavo Alonso, ETH Zürich. Resource managers 2 tier system Resource manager 17

N-tier: connecting to the Web client N-tier architecture Web browser Web server HTML filter o presentation layer application logic layer middleware resource management layer information system ©Gustavo Alonso, ETH Zürich. o o N-tier architectures result from connecting several three tier systems to each other and/or by adding an additional layer to allow clients to access the system through a Web server The Web layer was initially external to the system (a true additional layer); today, it is slowly being incorporated into a presentation layer that resides on the server side (part of the middleware infrastructure in a three tier system, or part of the server directly in a two tier system) The addition of the Web layer led to the notion of “application servers”, which was used to refer to middleware platforms supporting access through the Web 18

N-tier systems in reality INTERNET FIREWALL internal clients Web server cluster LAN middleware application logic LAN, gateways LAN resource management layer middleware application logic LAN database file server ©Gustavo Alonso, ETH Zürich. application Wrappers and gateways LAN additional resource management layers 19

The service world Browser user program app server 1’ wrappers Branch 1 ©Gustavo Alonso, ETH Zürich. user program Front end MIDDLEWARE WEB SERVER user program o The WWW suddenly opened up software systems that had remained hidden within the IT organization of a company The nature of the interaction did not change. Behind the WWW there is the same client/server model as in basic RPC. However, the WWW made everything much easier, cheaper and efficient Þ integration at the level of user interface became possible Þ services could be accessed from anywhere in the world Þ the clients could now be not just an internal or selected user but anybody with a browser app server 1 o Branch 2 20

Remote clients client stored procedure client embedded SQL client browser XML FIREWALL WEB SERVER user defined application logic API user defined application logic database resource manager API database management system ©Gustavo Alonso, ETH Zürich. 21

Business to Business (B 2 B) FIREWALL INTERNET wrappers Resource X Resource Y ©Gustavo Alonso, ETH Zürich. user program Service 2 user program Front end MIDDLEWARE WEB SERVER Service 1 user program Service B user program Service A Front end MIDDLEWARE WEB SERVER wrappers Resource 1 Resource 2 22

Two competing views of Web services bottom up: application integration top down: business exchanges ©Gustavo Alonso, ETH Zürich. 23

WS architecture: application integration o o o A popular interpretation of Web services is based on IBM’s Web service architecture based on three elements: Service requester: The potential user of a service Service provider: The entity that implements the service and offers to carry it out on behalf of the requester Service registry: A place where available services are listed and which allows providers to advertise their services and requesters to query for services The goal is just-in-time integration of applications by discovering and orchestrating network-available services ©Gustavo Alonso, ETH Zürich. 24

How is it ‘bottom up’? o o o The Web service architecture proposed by IBM is based on two key concepts: Þ architecture of existing synchronous middleware platforms Þ current specifications of SOAP, UDDI and WSDL The architecture has a remarkable client/server flavor It reflects only what can be done with Þ SOAP (Simple Object Access Protocol) Þ UDDI (Universal Description and Discovery Protocol) Þ WSDL (Web Services Description Language) UDDI SOAP WSDL ©Gustavo Alonso, ETH Zürich. 25

2000 eb. XML TM eb. XML architecture ©Gustavo Alonso, ETH Zürich. 26

How is eb. XML ‘top down’? 2000 eb. XML TM o The eb. XML (electronic business XML) architecture tries to describe all elements and steps of a commercial exchange, including the characteristics of the technology that supports those exchanges. Its goals are an attempt at: ü Providing a view for integration of business processes among ad-hoc or established independent business partners by electronic means ü Reducing the need for collaborative business partners to have individual and expensive prior agreement on how to integrate business processes ü Providing a high-level business-centric view of distributed e-business processes ü Supporting and representing business processes independent of the technical solution ü Providing and supporting a library of common, standard intra-business processes ü Allowing for both business processes and enabling technologies to evolve independently while retaining long-term investments in both ü Integrating with new and legacy systems throughout the enterprise ü Leveraging existing technologies and standards ©Gustavo Alonso, ETH Zürich. 28

Background for these views o o o The IBM’s Web service architecture follows traditional middleware architecture and it is very tied in spirit to conventional middleware It interprets electronic commerce as an essentially synchronous activity where a client requests services (in the middleware sense) from a server. If necessary, a name and directory service infrastructure (the registry) is available for matchmaking between clients and servers in this interpretation This view of Web services focuses on the low level mechanisms necessary to implement Web services. It does not say anything about how these mechanisms map to real business exchanges ©Gustavo Alonso, ETH Zürich. o The eb. XML electronic business architecture predates the efforts around Web services. It sees electronic commerce as an asynchronous sequence of message exchanges o eb. XML has inherited many ideas from the EDI (Electronic Data Interchange) world as one of the main supporters of eb. XML is the same organization that is in charge of EDI. As such, its main interest is standardizing business processes and business operations o eb. XML contains a much richer vocabulary and deeper understanding of business relations that uses to establish what the low level technology should do. As a result, it is far more encompassing than IBM’s Web service architecture 29

Extending information systems to communicate through the Internet ©Gustavo Alonso, ETH Zürich. 30

The next step. . . o The next step in that progression leads immediately to the notion of Web services as considered in IBM’s Web service architecture. Þ The notion of service in the conventional middleware is now translated into the notion of Web service based on the access channel to that service (the service in fact can be a pre-existing middleware service, e. g. , stored procedures in databases made available as Web services) Þ The only thing that changes from the middleware and enterprise application integration world is that a few details need to be changed so that they match the needs of exchanges through the Internet rather than a LAN: • XML as the data representation format • SOAP as a protocol wrapper to allow conventional communication protocols of middleware platforms to cross the Internet and firewalls (essentially turns invocations into document exchanges) • WSDL as the XML version of IDLs (plus a few other things) • UDDI as the WWW version of basic name and directory services ©Gustavo Alonso, ETH Zürich. 31

Messages & Queues

Synchronous Execution invoking execution thread invoked execution thread blocking period request response Web Services: Concepts, Architectures and Applications by Alonso et al. © 2004 by Springer Verlag Berlin Heidelberg 2004 Ch. 2, Fig 13, § 3. 2 33

Asynchronous Execution invoking execution thread invoked execution thread remains active queue fetch put queue Web Services: Concepts, Architectures and Applications by Alonso et al. © 2004 by Springer Verlag Berlin Heidelberg 2004 Ch. 2, Fig 14, § 3. 3 34

The message world ©Gustavo Alonso, ETH Zürich. 35

©Gustavo Alonso, ETH Zürich. 36 Using Workflows with eb. XML ©BEA

Documents rather than methods o o o When exchanges occur as documents, the emphasis is no longer on the mechanisms for sending and receiving documents (there are many to choose from) but on the contents of the documents and how to interpret them. The arrival of documents is not a function or a method call. It is not even a service request as such but one element of a business process. Hence, in addition to specifying the format for the documents and the semantics for the contents of the documents, it is necessary to agree on what documents are needed to get things done, i. e. , the business process that defines the interaction between the participants. The basic document exchange standard is the Electronic Data Interchange (EDI), a set of common data format standards developed in the late 1970 s. Þ EDI is a collection of basic data elements (e. g. , a price) that can be combined to form composite data elements, which are then combined into functionally related units called data segments (e. g. , the complete description of an item), and finally grouped into transaction sets (minimal meaningful unit for document exchanges between companies, e. g. , an invoice or a purchase order) Þ Additional standards (EDIFACT, X 12) describe how to use transaction sets as part of concrete business processes. ©Gustavo Alonso, ETH Zürich. 37

Processes rather than service calls “The x. CBL 3. 5 Change. Order document is a buyer-initiated document that can be used to change an existing Order already received and responded to by a seller. The document can be used to make changes to header level information, change line items, cancel line items, add line items, etc. Note that if an Order. Response has not been received for a given Order, a Change. Order is not necessary (an Order with a purpose of “Replace” should be used). Similarly, if an entire order is to be cancelled (regardless of whether a response has been received or not) an Order with a purpose of “Cancellation” should be used. ” x. CBL 3. 5 Order Management Recommended Use, Version 1. 0 November 19, 2001 ©Gustavo Alonso, ETH Zürich. 38

The next step. . . o The next step for message based electronic commerce is to take advantage of the Internet to improve electronic commerce: e. g. , eb. XML and the many attempts at producing an XML version of EDI. Note, these efforts also include linking to the standardization efforts around XML and Web services. However, the final goal is still the standardization of business exchanges rather than the standardization of the low level mechanisms used to implement those exchanges. Þ With this interpretation, there is no client server flavor to the exchanges. Business interactions occur between trading partners Þ Middleware architectures are not obvious in these proposals. One assumes they are there to implement the business processes but they do not determine the specification of the exchanges Þ There is much concern with the semantics of business exchanges than with the syntax (unlike in the Web services architecture which is purely syntactic) Þ Many concepts that are unknown in the Web service architecture play an important role in these architectures: role of the participant, business agreement, automatic enforcement of business agreements, conversations, business protocols, integration of business processes, etc. ©Gustavo Alonso, ETH Zürich. 39

Advantages of queues in EAI o o Queuing management systems completely detach the two sides of an interaction as there is no direct call but a document exchange This makes the development of both sides of the interaction (e. g. , client and server) completely independent and very flexible The interaction can be defined in terms of the document to exchange rather than the interface to invoke. This is a more natural approach in the business world where interactions tend to be document based From the scheduling point of view, it is much easier to deal with messages than with synchronous invocations. ©Gustavo Alonso, ETH Zürich. o o o Technically, the infrastructure necessary to deal with messages is simpler than the infrastructure necessary to deal with synchronous calls. Especially if there are no fancy features added to the queues. Queues also have the advantage of being easily adaptable to communicate with external systems, even systems outside the organization (e. g. , plug a queue to an e-mail address) When working with messages, the effort in describing the interaction goes into the description of the message or document within the message. This can be done without knowledge of how the message will be processed. 40

Message based interaction o o Message based interaction has several advantages over synchronous systems, particularly when the interaction involves different organizations and typical business transactions (where the response might not be immediate). Message based interaction has less of a client server flavor and more of an exchange of information between partners, this affects not only the way the interaction is implemented (as interconnected business processes) but also the technology used for that purpose. If the messages are standardized, then it is possible to create off-the-shelf systems that can process such messages. This was the original goal of EDI but the technology was not yet there. The Internet, XML, and the whole notion of Web services will probably now help to make this goal a reality at a lower cost and with less effort than was required before. Message based interaction is behind many of the most comprehensive models for electronic commerce (eb. XML, x. CBL, etc. ) and will certainly have a decisive influence on how SOAP, WSDL and UDDI will evolve in the future. ©Gustavo Alonso, ETH Zürich. 42

o o Any synchronous middleware introduces a tight coupling between the caller and the called. Name and directory services help to minimize the effects of this coupling but the tight connection between components is nevertheless there. It also creates considerable problems when trying to implement certain properties or manage the interaction between client and servers (fault tolerance, availability, etc. ) The first systems to provide alternatives were TP-Monitors which offered two choices: Þ asynchronous RPC: client makes a call that returns immediately; the client is responsible for making a second call to get the results Þ Reliable queuing systems (e. g. , Encina, Tuxedo) where, instead of using procedure calls, client and server interact by exchanging messages. Making the messages persistent by storing them in queues added considerable flexibility to the system client service call get results Client stub o Server stub Queues in TP-Monitors server service return results RPC support Input queue Output queue external application Reliable queuing system Output queue Input queue external application ©Gustavo Alonso, ETH Zürich. 43

Queuing systems o client Input queue o Output queue o Reliable queuing system Monitoring Administration Persistent storage Input queue o Output queue o external application ©Gustavo Alonso, ETH Zürich. Queuing systems implement asynchronous interactions. Each element in the system communicates with the rest via persistent queues. These queues store messages transactionally, guaranteeing that messages are there even after failures occur. Queuing systems offer significant advantages over traditional solutions in terms of fault tolerance and overall system flexibility: applications do not need to be there at the time a request is made! Queues provide a way to communicate across heterogeneous networks and systems while still being able to make some assumptions about the behavior of the messages. They can be used when embedded (workflow, TP-Monitors) or by themselves (MQSeries, Tuxedo/Q). 46

Simple Object Access Protocol (SOAP)

What is SOAP? o o The Simple Object Access Protocol (SOAP) was initiated by W 3 C in 1999. SOAP 1. 0 was entirely based on HTTP, and the following version, SOAP 1. 1 (May 2000), was more generic since it included other transport protocols. The first draft of SOAP 1. 2 was presented in July 2001 and is now a “Recommendation”. SOAP covers the following four main areas: Þ A message format for one-way communication describing how a message can be packed into an XML document Þ A description of how (the XML document that makes up) a SOAP message should be transported through the Web (using HTTP) or e-mail (using SMTP). Þ A set of rules that must be followed when processing a SOAP message and a simple classification of the entities involved in that processing. It also specifies what parts of the messages should be read by whom and how to react in case the content is not understood Þ A set of conventions on how to turn an RPC call into a SOAP message and back as well as how to implement the RPC style of interaction (how the client side RPC call is translated into a SOAP message, forwarded, turned into a server side RPC call, the reply converted into a SOAP message and returned to the client) ©Gustavo Alonso, ETH Zürich. 50

The background of SOAP o o SOAP was originally conceived as the minimal possible infrastructure necessary to perform RPC through the Internet: Þ use of XML as intermediate representation between systems Þ very simple message structure Þ mapping to HTTP for tunneling through firewalls and using the Web infrastructure The idea was to avoid the problems associated with CORBA’s IIOP/GIOP (which fulfilled a similar role, but used a non-standard intermediate representation and had to be tunneled through HTTP anyway) The goal was to have an extension that could be easily layered on top of existing middleware platforms to allow them to interact through the Internet rather than through a LAN, as is typically the case. Hence the emphasis on RPC from the very beginning (essentially all forms of middleware use RPC at one level or another) Eventually SOAP started to be presented as a generic vehicle for computer driven message exchanges through the Internet and then it was open to support interactions other than RPC and protocols other than HTTP. This process, though, is still on-going. ©Gustavo Alonso, ETH Zürich. 51

Structure of a SOAP message ©Gustavo Alonso, ETH Zürich. 52

SOAP messages o o o SOAP is based on message exchanges Messages are seen as envelopes where the application encloses the data to be sent A message has two main parts; header and body, which both can be divided into blocks SOAP does not specify what to do with the header and the body, it only states that the header is optional and the body is mandatory The use of header and body, however, is implicit. The body is for application level data. The header is for infrastructure level data ©Gustavo Alonso, ETH Zürich. SOAP Envelope SOAP header Header Block SOAP Body Block 53

For the XML fans (SOAP, body only) XML name space identifier for SOAP serialization XML name space identifier for SOAP envelope <SOAP-ENV: Envelope xmlns: SOAP-ENV="http: //schemas. xmlsoap. org/soap/envelope/" SOAP-ENV: encoding. Style="http: //schemas. xmlsoap. org/soap/encoding/"> <SOAP-ENV: Body> <m: Get. Last. Trade. Price xmlns: m="Some-URI"> <symbol>DIS</symbol> </m: Get. Last. Trade. Price> </SOAP-ENV: Body> </SOAP-ENV: Envelope> From the: Simple Object Access Protocol (SOAP) 1. 1. W 3 C Note 08 May 2000 ©Gustavo Alonso, ETH Zürich. 54

From the: Simple Object Access Protocol (SOAP) 1. 1. W 3 C Note 08 May 2000 SOAP example, header and body <SOAP-ENV: Envelope xmlns: SOAP-ENV="http: //schemas. xmlsoap. org/soap/envelope/" SOAP-ENV: encoding. Style="http: //schemas. xmlsoap. org/soap/encoding/"/> <SOAP-ENV: Header> <t: Transaction xmlns: t="some-URI" SOAP-ENV: must. Understand="true"> 5 </t: Transaction> </SOAP-ENV: Header> <SOAP-ENV: Body> <m: Get. Last. Trade. Price xmlns: m="Some-URI"> <symbol>DEF</symbol> </m: Get. Last. Trade. Price> </SOAP-ENV: Body> </SOAP-ENV: Envelope> ©Gustavo Alonso, ETH Zürich. 55

The SOAP header o o o The header is intended as a generic place holder for information that is not necessarily application dependent (the application may not even be aware that a header was attached to the message). Typical uses of the header are: coordination information, identifiers (for, e. g. , transactions) and security information (e. g. , certificates) SOAP provides mechanisms to specify who should deal with headers and what to do with them. For this purpose it includes: Þ SOAP role attribute (previously called “actor”): who should process that particular header entry (or header block). The “role” can be either: none, next, ultimate. Receiver. ‘None’ is used to propagate information that does not need to be processed. ‘Next’ indicates that a node receiving the message can process that block. ‘ultimate. Receiver’ indicates that the header is intended for the final recipient of the message Þ must. Understand attribute: with values true/false (previously 1/0), indicating whether it is mandatory to process the header. If a node can process the message (as indicated by the “role” attribute), the must. Understand attribute determines whether it is mandatory to do so. Þ New in SOAP 1. 2 is also the relay attribute (forward header if not processed) ©Gustavo Alonso, ETH Zürich. 56

The SOAP body o o The body is intended for the application specific data contained in the message A body entry (or a body block) is syntactically equivalent to a header entry with attributes role = ultimate. Receiver and must. Understand = true Unlike for headers, SOAP does specify the contents of some body entries: Þ mapping of RPC to a collection of SOAP body entries Þ the Fault entry (for reporting errors in processing a SOAP message) The fault entry has four elements (in 1. 1): Þ fault code: indicating the class of error (version, must. Understand, client, server) Þ fault string: human readable explanation of the fault (not intended for automated processing) Þ fault actor: who originated the fault Þ detail: application specific information about the nature of the fault ©Gustavo Alonso, ETH Zürich. 57

SOAP Fault element (v 1. 2) o o o In version 1. 2, the fault element is specified in more detail. It must contain two mandatory sub-elements: Þ Code: containing a value (the code of the fault) and possibly a sub-code (for application specific information) Þ Reason: same as fault string in 1. 1 § This string can be provided in different languages: <env: Text xml: lang="en-US">Header not understood</env: Text> <env: Text xml: lang="fr">En-tête non compris</env: Text> and may contain any of the following optional elements: Þ Node: the URI identifying the node producing the fault (if absent, it defaults to the intended recipient of the message) Þ Role: the role played by the node that generated the fault Þ Detail: as in 1. 1 Errors in understanding a mandatory header are responded using a fault element but also include a special header indicating which one of the original headers was not understood. ©Gustavo Alonso, ETH Zürich. 58

Message processing o o o SOAP specifies in detail how messages must be processed (in particular, how header entries must be processed) Þ Each SOAP node along the message path looks at the role associated with each part of the message Þ There are 3 standard roles: none, next or ultimate. Receiver (as mentioned above) Þ Applications can define their own message roles Þ The role determines who is responsible for each part of a message If a block doesn’t have a role associated with it, it defaults to ultimate. Receiver If a must. Understand flag is included, a node that matches the specified role must process that part of the message, otherwise it must generate a fault and not forward the message any further SOAP 1. 2 includes a relay attribute. If present, a node that does not process that part of the message must forward it (i. e. , it cannot remove the part) The use of the relay attribute, combined with the role next, is useful for establishing persistence information along the message path (like session information) ©Gustavo Alonso, ETH Zürich. 59

From TRPC to SOAP messages RPC Request SOAP Envelope SOAP header Transactional context SOAP Body RPC Response (one of the two) SOAP Envelope SOAP header Transactional context Name of Procedure Input param 1 Input param 2 ©Gustavo Alonso, ETH Zürich. SOAP Body Return parameter SOAP Body Fault entry 60

Mapping SOAP to a transport protocol ©Gustavo Alonso, ETH Zürich. 61

HTTP as a communication protocol o o HTTP was designed for exchanging documents. It is almost like e-mail (in fact, it uses RFC 822 compliant mail headers and MIME types) Example of a simplified request (from browser): GET /docu 2. html HTTP/1. 0 Accept: www/source Accept: text/html Accept: image/gif User-Agent: Lynx/2. 2 libwww/2. 14 From: eggs@spam. com * a blank line * o Request methods: GET (retrieve data), POST (append information), PUT (send information), DELETE (remove information), . . . File being requested (docu 2. html) and version of the protocol used List of MIME types accepted by the browser Information about the environment where the browser is running E-mail or identifier of the user (provided by the browser) End of request ©Gustavo Alonso, ETH Zürich. 62

HTTP server side o Example of a response from the server (to the request by the browser): HTTP/1. 0 200 OK Date: Wednesday, 02 -Feb-94 23: 04: 12 GMT Server: NCSA/1. 1 MIME-version: 1. 0 Last-modified: Monday, 15 -Nov-93 23: 33: 16 GMT Content-type: text/html Content-length: 2345 * a blank line * <HTML><HEAD><TITLE>. . . </TITLE>. . . etc. o The server is expected to convert the data into a MIME type specified in the request (“Accept: ” headers) ©Gustavo Alonso, ETH Zürich. Protocol version, code indicating request status (200=ok) Date, server identification (type) and format used in the request MIME type of the document being sent Header for the document (document length in bytes) Document sent 63

Parameter passing o The introduction of forms for allowing users to provide information to a web server required the modification of HTML (and HTTP), but it provided a more advanced interface than just retrieving files: POST /cgi-bin/post-query HTTP/1. 0 Accept: www/source Accept: text/html Accept: video/mpeg Accept: image/jpeg. . . Accept: application/postscript User-Agent: Lynx/2. 2 libwww/2. 14 From: mickey@mouse. com Content-type: application/x-www-form-urlencoded Content-length: 150 POST request indicating the CGI script to execute (post-query) GET can be used, but requires the parameters to be sent as part of the URL: As before * a blank line * &name = Gustavo &email= alonso@inf. ethz. ch. . . ©Gustavo Alonso, ETH Zürich. Data provided through the form and sent back to the server 64

SOAP and HTTP o o A binding of SOAP to a transport protocol is a description of how a SOAP message is to be sent using that transport protocol The typical binding for SOAP is HTTP SOAP can use GET or POST. With GET, the request is not a SOAP message but the response is a SOAP message, with POST both request and response are SOAP messages (in v 1. 2, v 1. 1 mainly considers using POST). SOAP uses the same error and status codes as those used in HTTP so that HTTP responses can be directly interpreted by a SOAP module ©Gustavo Alonso, ETH Zürich. HTTP POST SOAP Envelope SOAP header Transactional context SOAP Body Name of Procedure Input parameter 1 Input parameter 2 65

From the: Simple Object Access Protocol (SOAP) 1. 1. W 3 C Note 08 May 2000 In XML (a request) POST /Stock. Quote HTTP/1. 1 Host: www. stockquoteserver. com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV: Envelope xmlns: SOAP-ENV="http: //schemas. xmlsoap. org/soap/envelope/" SOAP-ENV: encoding. Style="http: //schemas. xmlsoap. org/soap/encoding/"> <SOAP-ENV: Body> <m: Get. Last. Trade. Price xmlns: m="Some-URI"> <symbol>DIS</symbol> </m: Get. Last. Trade. Price> </SOAP-ENV: Body> </SOAP-ENV: Envelope> ©Gustavo Alonso, ETH Zürich. 66

From the: Simple Object Access Protocol (SOAP) 1. 1. W 3 C Note 08 May 2000 In XML (the response) HTTP/1. 1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV: Envelope xmlns: SOAP-ENV="http: //schemas. xmlsoap. org/soap/envelope/" SOAP-ENV: encoding. Style="http: //schemas. xmlsoap. org/soap/encoding/"/> <SOAP-ENV: Body> <m: Get. Last. Trade. Price. Response xmlns: m="Some-URI"> <Price>34. 5</Price> </m: Get. Last. Trade. Price. Response> </SOAP-ENV: Body> </SOAP-ENV: Envelope> ©Gustavo Alonso, ETH Zürich. 67

All together HTTP POST SOAP Envelope SOAP header Transactional context SOAP Body Name of Procedure Input parameter 1 SERVICE REQUESTER Input parameter 2 SERVICE PROVIDER Procedure HTTP Acknowledgement HTTP engine SOAP engine HTTP engine RPC call SOAP engine SOAP Envelope SOAP header Transactional context SOAP Body Return parameter ©Gustavo Alonso, ETH Zürich. 68

SOAP summary o o o SOAP, in its current form, provides basic mechanisms for: Þ encapsulating messages into an XML document Þ mapping the XML document to a SOAP message and turn it into an HTTP request Þ transforming RPC calls into SOAP messages Þ simple rules on how to process a SOAP message (rules have become more precise and comprehensive in v 1. 2 of the specification) SOAP takes advantage of the standards surrounding XML to resolve problems of data representation and serialisation (it uses XML Schema to represent data and data structures, and it also relies on XML for serialising the data for transfer). As XML becomes more powerful and additional XML standards appear, SOAP can take advantage of them by simply indicating what schema and encoding is used as part of the SOAP message. Current schema and encoding are generic but soon there will be vertical standards implementing schemas and encoding tailored to a particular application area (e. g. , the efforts around EDI, Electronic Data Interchange) SOAP is a very simple protocol intended for transferring data from one middleware platform to another. In spite of its claims to be open (which are true), current specifications are very tied to RPC and HTTP. ©Gustavo Alonso, ETH Zürich. 69

Alsonso et al. B o o k S l i d e s Web Services: Concepts, Architectures and Applications by Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju © 2004 (Springer-Verlag) ISBN 3 -540 -44008 -9 ‘Graduate course on Web services [Gustavo Alonso, Cesare Pautasso]. Graduate course given at the University of Lappeenranta, Finland. August 9 -13, 2004. ’ http: //www. inf. ethz. ch/personal/alonso/Web. Serv ices. Book & http: //www. inf. ethz. ch/personal/alonso/Webbook/Lappeenranta-graduate-course. zip� 70