SOAP-based Web Services

Editor's Notes

• #4: To describe in simple words what Web services are sometimes a LEGO example is being used. Conceptually think about a child who gets his first box of LEGO and throws the little blocks on the floor. He gets little bits and builds something out of them, then he breaks it and makes something new. Every time he rebuilds something of a different shape with a different set of characteristics. Those small building blocks are the Web services and where they come from are the existing Web applications. Think of Web applications that fit into the client-server paradigm, except that the clients are not people but other Web applications.
• #5: Web services are software systems that are also designed to be accessed using web protocols, but that are intended to be used by other software applications rather than directly by end users (machine-to-machine interaction). The API allows programmers to use predefined functions to interact with the software system, instead of writing them from scratch. Think about a Java class which might be viewed as providing services (instance variables and methods) for use by other software in a program. APIs in general can use any means of communication they wish (not necessarily over network). Web APIs are used in the context of Web development, they are available over Internet. They can be virtually considered as a synonym to Web Services. By using Web Services your Web-application can publish its function or message to the rest of the world.
• #6: Following the learning from comparison approach let's see how web services, web applications and APIs are related to each other. We have learned about Web applications which are software systems that are designed to be accessed by end users through browsers or other web client software. Web services are software systems that are also designed to be accessed using web protocols, but that are intended to be used by other software applications rather than directly by end users (machine-to-machine interaction). The API allows programmers to use predefined functions to interact with the software system, instead of writing them from scratch. Think about a Java class which might be viewed as providing services (instance variables and methods) for use by other software in a program. APIs in general can use any means of communication they wish (not necessarily over network). Web APIs are used in the context of Web development, they are available over Internet. They can be virtually considered as a synonym to Web Services. By using Web Services your Web-application can publish its function or message to the rest of the world. http://e-culture.multimedian.nl/demo/session/api/search?query=gogh&view=exhibit&https%3A%2F%2Fblue-sea-697d.quartiers047.workers.dev%3A443%2Fhttp%2Fwww.vraweb.org%2Fvracore%2Fvracore3%23source=https%3a%2f%2fblue-sea-697d.quartiers047.workers.dev%3a443%2fhttp%2fe-culture.multimedian.nl%2fns%2frijksmuseum%2f&indent=true&display=thumbnail&display=label&display=https%3A%2F%2Fblue-sea-697d.quartiers047.workers.dev%3A443%2Fhttp%2Fwww.vraweb.org%2Fvracore%2Fvracore3%23creator&display=https%3A%2F%2Fblue-sea-697d.quartiers047.workers.dev%3A443%2Fhttp%2Fwww.vraweb.org%2Fvracore%2Fvracore3%23location.creationSite&searchPath=abstract show CHIP example of how the data is displayed
• #7: It is possible to build completely new applications by combining Web services. These applications are called mashups. Example of a mashup: Wikipediavision, a site that shows in semi-realtime where anonymous edits to Wikipedia are originating from. It combines Google Maps and a Wikipedia API.
• #11: Machine-to-machine interaction - Web services are used to provide services to software applications. The data they provide is intended as input to a software program that does something amazing with this data - Interaction is happening over a network - because these services are intended to be accessed using Web protocols and technologies, they are called Web services. - Another keyword in this definition is interoperable.
• #12: Connect existing software – The focus of Web services is on simplifying the integration of heterogeneous applications on different platforms, implemented in different languages and residing within the same organization or across multiple organizations. Thus the driving factor for the Web services is the interoperability between all these systems. Reusable application-components – Web services can offer application-components that can be included in other applications like: currency conversion, weather reports, or language translation as services.
• #13: The name Big Web Services is given by Richardson and Ruby, the authors of the first book on the alternative solution - RESTful Web services. RESTful or REST-compliant Web services (those conforming to the REST constraints) look like the Web. Their purpose is to create, retrieve, update, and delete information resources. Big Web Services allow for arbitrary complex set of operations on resources but they typically don't work like Web though some Big Web Services can be compliant with REST. SOA is an architectural style or pattern for building distributed systems that deliver application functionality as services to either end-user applications or other services. Web service is a kind of SOA implementation.
• #14: Technologies that enable distributed computer systems to communicate with one another have been around for a long time. e.g. CORBA Common Object Request Broker Architecture, DCOM Distributed Component Object Model, Java RMI Remote Method Invocation, RMI over IIOP Java RMI style programming using CORBA IIOP for communication. But Web services are easiest to implement than many other approaches because they are based on commonly used existing standards (protocols and data formats), in particular, HTTP and XML. At their lowest levels Web services are typically based on transmitting XML documents between clients and servers via HTTP. XML is used to format data into a document that all interacting application know how to process. HTTP clients and servers are available for all major programming languages and operating system/hardware platforms, and the default HTTP port 80 is commonly left open by default in most firewall configurations. This communication mechanism provided by sending XML documents over HTTP connections allows for interoperability. Big Web Services have three basic platform elements:SOAP to transport data, WSDL to describe Web services, UDDI to publish and find Web services.RESTful Web services rely upon the concept of the URI. Often as an alternative to XML, they use a lightweight JSON (JavaScript Object Notation) format for messages exchange between client and server. It is possible to provide WADL file describing every resource by RESTful service. RESTful services have simpler interfaces thus WADL is not nearly as necessary to these services as WSDL is to RPC-style SOAP services.
• #15: SOA can be conceptualized as containing 3 roles and 3 operations (publish, find and bind). Service provider – develops the service interface and implementation and deploys the service so that it is available to be invoked over a network. The service provider also creates a service description and publishes that service description with one or more service brokers (publish operation). The service description describes everything that a service requester must know to invoke the service made available by the service provider. This information typically includes the format for the request message, the format for the response message (if any) and where to send the request message. Service broker – accepts requests from service providers to publish information about the services they want to make available. The information published includes the type of the service, a description of the service, and the location where the service can be invoked. The service requester can then query the service broker to find a particular service (find operation). An analogy to the service broker is a phone book. A company publishes information on a particular service they are providing in a phone book. In turn, people look in the phone book to find companies providing that same service. People find the company that published their service and use the contact information to request the service from that company. Service Requester – uses the service broker to find services that match some set of criteria. The service requester can then use the service description to connect to the service and invoke it (bind operation).
• #16: This type of architecture allows to achieve the following properties: separation of concerns - each functional unit is then exposed as a separate service which achieves a separation of concerns. Each service handles a specific concern (task). In SOA applications are integrated via the service interface not the service implementation. The separation of interface from implementation is intended to allow service consumer applications the ability to interoperate with service provider applications regardless of whether their underlying implementations are compatible (interoperability). As a result the applications are loosely coupled. loose coupling among interacting software applications - the benefit of loosely coupled applications lies in their ability to survive evolutionary changes in their structure and implementation. reusability of services - these services can then be orchestrated together to form any number of different business processes. If a company finds that it is more cost-effective to use a service provided by a different company than maintain their own, they can quickly swap out that service. The system can also be designed to dynamically choose among different service providers (if they have the same service interface) based on price or even some other policy such as performance or reliability.
• #17: The interaction illustrated is accomplished through the exchange of XML documents. The publish and find operations of the UDDI registry and the Web service are invoked using the exchange of SOAP messages. SOAP messages and WSDL documents are both instances of XML documents and the data SOAP messages contain is also XML.
• #19: A SOAP message is an ordinary XML document that consists of an envelope that describes a message and how to process it, data encoding rules for describing data types (based on XML Schema) and a set of rules for how to make remote calls (remote procedure calls RPC or messages) and get responses. The main elements of the SOAP message are:an envelope that identifies the XML document as a SOAP message (notice the xmlns:env namespace in the example). It should always have the value of: "http://www.w3.org/2001/12/soap-envelope". The namespace defines the Envelope as a SOAP Envelope. If a different namespace is used, the application generates an error and discards the message. SOAP envelope contains two main parts:a(n optional) header (the metadata) that provides (application-specific) information about the message. The actual contents of the header are not specified by the SOAP standard but the basic idea is that the header may be available to SOAP intermediaries that may process the message as it goes from the sender to the receiver, as well as being available to the actual receiver. Headers are typically used to transmit authentication or session management data. body contains the message itself (the data). A Body element contains call and response information – the mandatory element within SOAP Envelope. The optional SOAP Fault element contains errors and status information for a SOAP message. Both the header and the body contain application specific XML content. The contents of Header and Body elements are application defined and not a part of the SOAP specifications.
• #20: RPC is very much like making a standard HTTP request to a Web application, where the client makes a call to the service and then waits for the response. An example shows an RPC-style SOAP request message and the response message from the method: request for a ticket price on a particular date and a corresponding result. An example uses a method getPrice which encapsulates a number of parameters: departing, arriving, departureDate. The corresponding method and parameter tags are namespaced by the service name. In the response message there is only ever one parameter tag representing the return value of the method getPriceResponse.
• #21: The examples above represent an implementation of the RPC-Style Architecture according to the classification by Richardson and Ruby. An RPC-style Web service accepts an envelope full of data from its client, and sends a similar envelope back. What kind of envelope e.g. HTTP or SOAP is not important to classification. Just about every SOAP service is an example of an RPC-style.
• #22: In contrast to RPC messaging is asynchronous. A message is sent but the client does not wait for the response (similar to the asynchronous XMLHttpRequest in Ajax systems). The more interesting scenarios typically involve multiple messages exchange between SOAP sender and ultimate SOAP receiver following request-response pattern. Continuing with the travel scenario an example shows another type of SOAP message returned in response about prices. This response seeks to refine some information in the request, namely the choice of airports, giving a list of alternatives.
• #23: SOAP provides a model for handling faults in processing of message. Faults are reported within env:Fault element which has two mandatory sub-elements env:Code which places the fault in an appropriate category and a human-readable explanation of the fault env:Reason. Example shows that it is an env:Sender fault which indicates that is is related to some syntactical or inappropriate information in the message. In this case it is expected that the sender has to take a corrective action.
• #24: SOAP messages may be exchanged using a variety of underlying protocols (e.g. HTTP or email). However in most cases they use HTTP as the underlying transfer protocol. HTTP binding makes use of GET and POST Web methods: HTTP POST is used for conveying SOAP messages in the bodies of HTTP request and response messages (SOAP-specific aspect is that a SOAP message in the request body has to be processed); and HTTP GET is used in HTTP request to return a SOAP message in the body of response (no SOAP message in the request body). As the slide shows our RPC example is carried in an HTTP Post Request. The destination URL is split between the request line which contains the argument /priceService/getPrice identifying the procedure to be invoked and the host address. Since a SOAP message is being sent the content-type field is set to application/soap+xml.
• #25: RPC return in the example embedded in an HTTP response indicates a successful completion . If an error occurs processing the request, the HTTP binding specification requires that a HTTP 500 “ Internal server error ” be used with an embedded SOAP message containing a SOAP fault indicating the server-side processing error.
• #28: <portType> A set of operations supported by one or more endpoints <binding> A protocol and data format specification for a particular port type concrete level - specifies how the abstract level is implemented. Concrete level gives a Web address at which the operations of a port type can be invoked and specifies how the messages that are exchanged through that address are bound to a specific transport protocol (e.x. HTTP) . Binding describes concrete communication protocol and data format specification for a particular port type . Port is a combination of a binding and network address. A WSDL document defines services as collections of ports.
• #29: The slide shows a simplified fraction of a WSDL document. It shows an abstract definition of a request and response message for our travel example and the definition of a port type. The <message> element defines the data elements of an operation. Each message can consist of one or more parts and the associated data types. The parts can be compared to the parameters of a function call in a traditional programming language.The <portType> element defines "pricesPT" as the name of a port, and "getPrice" as the name of an operation.The "getPrice" operation has an input message called "intineraryMsg" and an output message "intineraryRespMsg".Compared to traditional programming, getPricePT is a function library, "getPrice" is a function with "intineraryMsg" as the input parameter, and intineraryRespMsg as the return parameter.
• #31: In the example, the port "prices" defines a one-way operation called "setPrice". The "setPrice" operation allows input of new price message using a "newPrices" message with 4 input parameters. No output is defined for the operation.
• #32: A service gives a name to a set of ports. Each port specifies the address at which the operations of a particular port can be invoked together with the binding to be used. Taken together the ports of a service host a set of related operations that are offered to customers. The port getPricesRPCPort identifies a particular binding b1 and the Web address at which messages that use that binding are to be sent.
• #33: WSDL bindings defines the message format and protocol details for a Web service. Suppose in our travel scenario we want all operations of port type 'pricesPT' to be invoked with RPC-style SOAP messages sent using HTTP. Then we might declare the binding b1 as shown in the slide. The binding element has two attributes: name - defines the name of the binding and type - points to the port for the binding. The child soap:binding is an example of an extension of WSDL that provides information specific to that binding. The soap:binding element has two attributes - style and transport. The style attribute can be "rpc" or "document". For our travel example we use rpc. Transport is SOAP messages on top of HTTP protocol.The operation element defines each operation that the port exposes. Attribute “ name ” gives the name of the operation. It is important to keep in mind that the elements input and output inside the binding element are not themselves SOAP messages. Instead these are descriptions from which the actual SOAP messages are constructed. You must also specify how the input and output are encoded. In this case we use "encoded". A fault child should describe the fault message but it is omitted.
• #34: Key functional concepts for working with UDDI are UDDI Registry, UDDI data model and programmatic interfaces.
• #35: White pages: Basic information about the Company Basic contact information A unique identifiers for the company tax IDs (2) Yellow pages: This has more details about the company, and includes descriptions of the kind of electronic capabilities the company can offer to anyone who wants to do business with it. It uses commonly accepted industrial categorization schemes, industry codes, product codes, business identification codes and the like to make it easier for companies to search through the listings and find exactly what they want. (3) Green pages: This category contains technical information about a web service. This is what allows someone to bind to a Web service after it's been found. This includes: The various interfaces The URL locations Discovery information and similar data required to find and run the Web service. NOTE: UDDI is not restricted to describing web services based on SOAP. Rather, UDDI can be used to describe any service, from a single web page or email address all the way up to SOAP, CORBA, and Java RMI services.
• #36: The UDDI specification defines core data types. These data types are defined in several XML schemas, which together form a base information model and interaction framework of UDDI registries. They include:A description of a service ’ s business function (called the businessService) Information about the organization that published the service (businessEntity) The service ’ s technical details (bindingTemplate), including a reference to the service ’ s programmatic interface or API, and The binding template represents the actual implementation of the web service. Various other attributes or metadata such as taxonomy, transports and protocol definitions, digital signatures, etc. (tModels). Value sets including identifier systems, categorization systems and namespaces. Structured categorizations using multiple value sets called "categorization groups ” . tModel stands for technical model. tModels can be used to represent classification information which can then be added into interface tModels to make search easier, and finally,
• #37: The UDDI specification defines core data types. These data types are defined in several XML schemas, which together form a base information model and interaction framework of UDDI registries. They include:A description of a service ’ s business function (called the businessService) Information about the organization that published the service (businessEntity) The service ’ s technical details (bindingTemplate), including a reference to the service ’ s programmatic interface or API, and The binding template represents the actual implementation of the web service. Various other attributes or metadata such as taxonomy, transports and protocol definitions, digital signatures, etc. (tModels). Value sets including identifier systems, categorization systems and namespaces. Structured categorizations using multiple value sets called "categorization groups ” . tModel stands for technical model. tModels can be used to represent classification information which can then be added into interface tModels to make search easier, and finally,
• #38: These are query and update languages. Requestors can use Inquiry Interface to find and retrieve information from the registry. Providers (businesses) can use Publisher Interfaces to enter information into the registry, to store and update it.Inquiry and publishing functions represent the core data management tools of a UDDI registry.
• #44: In RESTful approach we use the following (example) URIs as the destination of the corresponding standard HTTP methods: http://example.com/users/ (HTTP method GET) http://example.com/users/id/ <user-id> (HTTP method GET) http://example.com/users/name/ <user-name> (HTTP methods GET, PUT, DELETE, POST)
• #47: - transparency and independence - using SOAP the same message in the same format can be transported across a variety of middleware systems which may rely on HTTP but also on many other transports (These may change along the way). - existence of tools to hide the complexity - mature SOAP engines and WSDL tools effectively hide the perceived complexity from the application programmer and integrator - security - security concepts are much better specified and deployed in SOAP-based protocols than in native HTTP protocols. Weaknesses Big Services - rudimentary processing protocol . HTTP protocol is used just as a tunneling protocol to enable remote communication through firewalls, but it is not used to convey the semantics of the service interaction. - complexity - too often Big Web Services are used for a job that HTTP could handle just fine. The effect is that HTTP is reduced to a transport protocol for an enormous XML payload. - heavyweight architecture for distributed object access - do not get the benefits of resource-oriented services . They are not addressable, well connected, don't respect uniform interface. Many of them are stateless though. - opaqueness - understanding one does not help you to understand the next one.
• #49: Strengths RESTful Web Services considered simple because REST leverages existing well-known W3C standards (HTTP, XML, URI). such lightweight infrastructure where services can be built with minimal tooling is inexpensive to acquire. No need to develop custom-client software since the developers can begin testing using ordinary Web browser. addressability - no need for a registration to a (centralized) repository, URIs can be bookmarked. it is known how to scale a stateless RESTful Web service to serve a very large number of clients, thanks to the support for caching, clustering and load balancing built into REST. using lightweight message formats, e.g. JSON allows to optimize the performance of a Web service. Weaknesses RESTful Web Services bound to one protocol: HTTP POST and GET are the only two verbs that can be used in the method attribute of an XHTML form. for idempotent requests having large amounts of input data it is not possible to encode such data in the resource URI, as the server will reject such “ malformed ” URI (request-URI too long). POST method does not suffer from these limitations. security issues: REST doesn't cover all web services standards, like Transactions, Security, Addressing, Trust, Coordination,