WEB SERVICE STANDARDS

Singh et al. (2004) have stated that for any technology to be successful, the technology standards must be widely accepted. To enable such a wide acceptance, Web services standards and systems that implement those standards should have the following criteria:

 “A Web service should be able to service requests from any client regardless of the platform on which the client is implemented”.

 “A client should be able to find and use any Web service regardless of the service’s‎implementation‎details‎or‎the‎platform‎on‎which‎it‎runs”.

The main Web services standards cover the following areas:  Common markup language for communication.  Common message format for exchanging information.  Common service specification formats.

 Common means for service lookup.

Figure ‎2-2 illustrates a stack of the main standards on which Web services are generally based on:

Figure 2-2: The Web Services Technology Stack (Albreshne, Fuhrer & Pasquier, 2009)

2.4.1 Extensible Markup Language (XML)

The eXtensible Markup Language (XML) is a simple and flexible text based markup language. This standard is accepted throughout the computer industry as it facilitates the communication between service providers and requesters using a common language. XML is also independent of any platform or technology. Messages in XML can be exchanged over the Internet using standard Internet protocols such as HTTP (Guruge, 2003; Siddiqui, 2003a).

Tags enclosed in angled brackets are used to mark XML data; the tags contain the meaning of the data they mark. The XML tag usage is different from HTML, which is oriented to displaying data. Thus, unlike HTML, display is not intrinsic in XML (Cerami, 2002).

XML is a product of the W3C. Therefore, changes to it will be supported by all leading parties. This means that when XML evolves, Web services can also evolve without having concerns about compatibility (Singh et al., 2004).

2.4.2 Simple Object Access Protocol (SOAP)

As XML fills the need for a common language, the Simple Object Access Protocol (SOAP) solves the need for a common messaging format (Mitra & Lafon, 2007). SOAP enables different objects to communicate by exchanging messages. SOAP is an XML-based protocol that uses data encoding format and HTTP/SMTP to transfer messages. SOAP does not require any specific technology at its endpoints because of its independency of programming languages and platforms. Moreover, SOAP is also supported by leading industrial parties (Singh et al., 2004).

SOAP defines an envelope, which contains a SOAP body, where the message is included, and an optional header. The SOAP envelope, body plus header, is an XML document (Mitra & Lafon, 2007). Figure ‎2-3 illustrates a SOAP envelope:

2.4.3 Web Services Description Language (WSDL)

The role of the Web Services Description Language (WSDL) is to define a standard way for specifying the details of a Web service (Christensen et al., 2001). Details of Web service interfaces, bindings and other deployment details are specified using a general-purpose XML schema. That enables clients without prior knowledge of the service to use that Web service (Adams & Boeyen, 2002; Singh et al., 2004).

Figure 2-4: WSDL Service Description (Singh et al., 2004)

WSDL grammar describes Web services as a collection of communication endpoints, as shown in Figure ‎2-4. The exchanged data are specified as part of messages. Every action allowed at an endpoint is an operation. In addition, port types are grouped together collections of operations that are possible on an endpoint. The port types, operations as well as messages are all abstract definitions, which do not hold deployment-dependent details in order to enable

their reuse. A binding is specified by a protocol and data format specifications for a particular port type. A port is defined when a network address is associated with a reusable binding. A collection of ports, in turn, defines a service. Furthermore, WSDL specifies a common binding mechanism to bring together all protocols and data formats with an abstract message, operation, or endpoint (Singh et al., 2004).

2.4.4 Universal Description, Discovery, and Integration

(UDDI)

The Universal Description, Discovery, and Integration (UDDI) specification defines a standard way for registering, deregistering, and looking up Web services (Clement et al., 2004). UDDI is a standards-based specification for Web service registration, description, and discovery.

Figure 2-5: Role of Registry in a Web Service (Singh et al., 2004)

The main purpose of UDDI registry is to enable service providers to register their services with‎a‎“broker”‎and requesters to find services advertised by this broker. The role that UDDI plays between the service requester and the service provider ends when a requester finds the service; a service provider registers its services with the broker (i.e. UDDI registry). A service requester then searches for the

service requester binds directly with the service provider to use that service (Singh et al., 2004), as illustrated in Figure ‎2-5.

Using the UDDI specification, an XML schema is defined for applications wanting to use the registry. A service provider registering its Web service with a UDDI registry must provide service, business, binding and technical information about the service (Adams & Boeyen, 2002; Singh et al., 2004). This information is stored in a common format that contains three parts:

1. White pages that describe general business information such as name, description, phone numbers, etc.

2. Yellow pages that describe the business using terms of standard classifications (taxonomies), which follow standard industrial

categorisations in order to enable locating services by industry, category, or geographical location information.

3. Green pages that list the service, binding, and service-specific technical information.

Web services standards have been widely accepted throughout enterprises and the popularity of Web services is increasing because of the benefits they provide.