Chapter #11 Web Service— Software Design and Architecture Specialization University of Alberta

Photo by David Monje on Unsplash

This passage introduces the concept of web services as a means of exposing and accessing services through web technologies. Before the widespread use of web services, integrating various software components in complex systems was challenging and labor-intensive. Enterprise Application Integration (EAI) with the help of middleware facilitated interactions between software, reducing the complexities of multiple connections. However, implementing EAI for business-to-business (B2B) interactions posed challenges related to identifying the middleware owner, managing security, and protecting data from external influence.

To address these challenges, web services were introduced as a solution for B2B interactions, implementing a specific set of standards and protocols for service implementation over the web. These services are defined by the World Wide Web Consortium (W3C) as “a software system designed to support interoperable machine-to-machine interaction over a network.”

This passage discusses key components and protocols involved in web services:

1. Web Infrastructure: Web services are built on top of web infrastructures, starting with TCP as the networking protocol, which ensures reliable and ordered communication. HTTP is used for sending information and interacting with clients, offering a strong foundation for platform independence and interoperability, making it compatible with various machines.
2. Invoking (SOAP): To use a specific service, a service requester must invoke it. This is done using SOAP, a protocol specification based on XML, enabling services to send information to one another. SOAP messages in XML format facilitate communication between systems coded in different languages and on different platforms.
3. Describing (WSDL): Services need to describe their interfaces for interaction to occur. Web Service Description Language (WSDL) is the standard protocol for describing service interfaces, written in XML. WSDL descriptions provide a machine-readable format, allowing service requesters to bind to the interface. Binding generates the necessary code for interacting with the service, making it easier when the service interface is described unambiguously in WSDL.
4. Publishing and Discovery (UDDI): Service providers use Universal Description, Discovery, and Integration (UDDI) to publish descriptions of their services. Service requesters can discover services by searching through WSDL descriptions and other aspects of the service, enabling them to find and use the services they need.
5. Composition (WS-BPEL): Various standards can be built on foundational standards like SOAP, WSDL, and UDDI for web services. These standards often have the “WS” prefix, such as WS-Security for security and WS-Coordination for coordinating service activities. WS-BPEL (Business Process Execution Language) is one such standard that facilitates service composition. It allows developers to combine existing services to create new composite services, which can be built from basic services or other composite services.

Service Invocation (SOAP)

SOAP (Simple Object Access Protocol) is a standard for communication in web services, using XML messages. It is designed to enable interactions between service requesters and service providers in a standardized and interoperable way. SOAP defines the structure of XML messages for invoking operations from remote web services, facilitating the exchange of data and instructions between clients and servers. This standardization ensures that both parties can understand and communicate effectively.

SOAP messages consist of the following components:

• Envelope: Every SOAP message is enclosed in an envelope, which identifies it as a SOAP message. The envelope is mandatory.
• Header: The header is an optional part of the SOAP message used to provide contextual information, such as client details or routing information.
• Body: The body of the SOAP message contains the essential information that the service provider needs to determine which service to execute and the required input parameters. The body is a mandatory component.

Two styles of SOAP messaging exist, and SOAP does not dictate which one to use. Both styles are commonly employed for web service communication, providing flexibility and adaptability in various scenarios.

SOAP messages are transmitted over a transport protocol, with HTTP being a commonly used option. When using HTTP, SOAP messages are sent via HTTP POST, and the HTTP protocol determines where to send the request, as this information is not directly included in the SOAP message itself. Upon receiving a POST request, HTTP can return the response or a simple acknowledgment that the request has been received.

Messaging can be synchronous or asynchronous. In synchronous messaging, the service request waits for a response before continuing, potentially leaving the program idle if the web service’s availability or response time is a concern. Asynchronous messaging, on the other hand, allows the code to continue executing, enabling it to process the message when it returns from the service provider.

A basic SOAP request is implemented through the following steps:

1. The client code initiates a local call to a stub.
2. The stub converts the request into a SOAP message.
3. The SOAP message is then packaged into an HTTP request and sent to the service provider.
4. Upon receipt, the HTTP server passes the content to a SOAP router, which determines the appropriate server stub and delivers the message.
5. The server stub utilizes the information in the SOAP message to make an appropriate method call.
6. Once the service code handles the request, the process is reversed to send the response.

Messaging Patterns

There are four basic messaging patterns for SOAP, each serving a specific purpose in interactions:

1. Request-response: In this pattern, the service requester sends a message to the server and awaits a reply from the service provider. It is a synchronous process that can be implemented over HTTP.
2. Solicit-response: This pattern involves the service provider making a request to the service requester. It is often used for synchronous confirmations.
3. One-way: In this messaging pattern, the service requester sends a request to the service provider without expecting a response. It is used for asynchronous communication, often for simple notifications that the service requester is operational.
4. Notification: The notification pattern is used when the service provider sends a notification to the requester without expecting a response. This pattern is suitable for event-based systems with publishers and subscribers and is also implemented asynchronously.

While SOAP has been a significant component of early web services, its stateless nature and certain disadvantages, such as XML encoding overhead and limited data type accommodation, have led to its replacement in many applications by more direct HTTP-based methods, including RESTful web services. Despite these drawbacks, SOAP’s neutrality and XML-based structure allowed for cross-platform and cross-language data interaction, contributing to the early consensus on web services.

Service Description (WSDL)

In web services, the Web Service Description Language (WSDL) serves as a standard for describing the interface of a web service, enabling SOAP messages to locate services and understand how to interact with them, including the necessary parameters. WSDL descriptions, written in XML, can be read either programmatically or by developers, providing insights into the structure of the service.

WSDL was developed through the collaboration of Microsoft, IBM, and Ariba, amalgamating various attempts at standardization. Similar to method signatures in object-oriented programming, WSDL descriptions outline the structure of a request, the required input parameters, the expected output data, the location for sending SOAP messages, the transport protocol to be used, and more.

By making WSDL descriptions machine-readable, service requesters can automatically generate the required code for interfacing with a service provider, a process known as binding, whether done automatically or by the developer. Once the binding process is completed, the service requester can invoke the service using SOAP messages structured with the aid of the WSDL descriptions.

WSDL Description

WSDL (Web Service Description Language) is a modular language used to define interfaces or multiple interfaces in web services. WSDL descriptions can be combined with other WSDL specifications by importing their descriptions, facilitating the creation of new interface descriptions. Various versions of WSDL have been developed, with differences in terminology and structure while maintaining similar underlying concepts.

Some key components of a WSDL 2.0 description include:

1. Types: Describing data types used, developers can define abstract data types in XML, although this part may not be necessary when basic data types available in XML are used.
2. Interfaces: Describing interfaces to services in terms of operations, message exchange patterns (request-response, solicit-response, one-way, notification) are outlined. Interfaces were previously referred to as portTypes in WSDL 1.2. Interfaces remain abstract until they are bound to concrete implementations necessary for using web services.
3. Bindings: Determining how SOAP messages are translated into XML, specifying the form of messages, and outlining the transport protocol for sending SOAP messages. This includes specifying document-style and RPC-style interactions.
4. Services: Bringing together interfaces and bindings, services assign them to endpoints or ports located with URIs.

WSDL allows for robust, modular, and extensible service descriptions, facilitating reuse through fine-grained descriptions. It enables the import of other WSDL documents, granting access to data types or interfaces in the imported WSDL description. While WSDL facilitates interoperability between different platforms over the Internet, its XML-based approach, like other aspects of web services, incurs computational costs due to the encoding and parsing of XML, presenting a significant disadvantage.

Service Publication and Discovery (UDDI)

Web services require effective publishing and discovery mechanisms to enable developers to locate services for application development and facilitate the utilization of created services. While the internet initially facilitated service discovery through search engines, dedicated frameworks for service publishing emerged to address this need. One of the pioneering frameworks for publishing is Universal Description, Discovery, and Integration (UDDI).

Initially developed in 2000 by Ariba, Microsoft, and IBM, UDDI is currently managed by the Organization for the Advancement of Structured Information Standards (OASIS), a non-profit organization overseeing various open standards. UDDI was designed as a protocol for publishing and discovery, intended to specify a universal registry and broker of web services using XML and WSDL for organizing data about the web services and their provisioning methods.

Although UDDI is not a mandatory component for implementing web services and is not tied to a specific registry, it remains a valuable standard for connecting service requesters and service providers. When the services to be used and their binding are known, a discovery mechanism may not be required. Conversely, if a service is developed for specific applications and can be directly bound to those applications, it may not need to be published. However, UDDI serves as a crucial mechanism for bringing service requesters and service providers together.

Overview of UDDI

UDDI serves as a platform that enables service providers to publish their services to a UDDI registry, allowing potential service requesters to search the registry and discover the services they require. The discovery process involves searching elements within the WSDL description or other service and service provider descriptions. Facilitating the connection between service providers and service requesters is a crucial aspect of establishing an effective service ecosystem.

Once the desired service is identified, the service requester can bind to it using the WSDL descriptions. This binding process involves generating the necessary code for the required messaging patterns, allowing the service requester to establish a connection with the service. Subsequently, the service requester can invoke the service, initiating the interaction with the service provider and utilizing the functionalities provided by the web service.

The process of publishing web services involves registering information about the service with a UDDI registry, including details about the service provider, the service itself, and technical descriptions of the service. A Uniform Resource Identifier (URI) is assigned to the service by the UDDI registry, serving as a unique reference for invoking the service. The information encapsulated in the UDDI standard is categorized into white pages, yellow pages, and green pages, storing business information, industry details, and technical service specifications, respectively. These categories correspond to data structures, including businessEntity, businessService, bindingTemplate, and tModel.

UDDI specifies web services for publishing, allowing service providers to add, delete, and modify entries in the registry through SOAP messages. Discovery is also facilitated through SOAP messages, with commands like find_business, find_service, find_binding, and find_tModel used for searching services. Service requesters utilize these commands to obtain information about the service interface, enabling them to dynamically bind to the service. Often, the complexities of publishing and discovery are abstracted from developers, who typically use web portals to search for services.

Dynamic binding can be a complex, run-time activity, creating challenges for developers in terms of anticipating errors, exceptions, and contract management. While discovery is typically performed by human developers, binding is monitored and tested by them. It is crucial for the interface description to be unambiguously defined to facilitate automated binding effectively.

Service Composition (BPEL)

The process of composition in web services involves coordinating multiple services and providing a unified interface. Services can be composed of other services, allowing the creation of higher-level services through the combination of lower-level functionalities. Despite the ease of composition in web services, handling exceptions and coordinating service invocations in a predetermined order remain essential aspects of the process.

Middleware services can be challenging to compose due to the lack of standardized interfaces, necessitating the development of wrappers to facilitate the interaction between components and middleware. In contrast, web services are more easily composed as they are accessed in similar ways, although challenges related to combining services still exist, albeit in a more manageable manner.

Business processes can be effectively mapped to activity diagrams, with the beginning and end points of a process representing the exposure of the composite service to service requesters. Business Process Execution Language (BPEL) serves as the standard high-level composition language for web services, enabling the composition of compatible services into a business process that is exposed as a service. BPEL supports various basic operations, including “if-then-else” decisions and other logical functionalities from different programming languages and wrappers.

Additionally, web services are associated with coordination, wherein a process coordinates the activities of two or more services. Composition differs from coordination as it exposes a collection of actions as another service. The next module in the specialization will focus on REST architecture.

Ibrahim Can Erdoğan

LINKEDIN

YOUTUBE

UDEMY