Understanding Web Services

-SatyaPrakash

Web Service is defined by W3C as a software system for making different computers interact. The computers may have different operating systems, different inner structure, but the logic of Web Service should make it possible for them to interact and make operations. This is the most general definition. But in practice,

Web Services usually make use of following:
     • SOAP as messaging envelope format
     • WSDL as service description format
     • UDDI for defining metadata that is used for service discovery
     • WS-Security that defines standards for security issues
     • WS-Reliable Messaging as the protocol for reliable messaging

These are the standards proposed by Organization for the Advancement of Structured Information Standards (OASIS) and W3C. Web Services Interoperability Organization (WSI) also creates some applications and tools to enhance Web Services interoperability. Web Service development based on these standards is supported by different implementation platforms such as .Net and J2EE.
                         In short, Web Services are a combination of a discovery system (UDDI), a description system (WSDL) and the Web Services themselves.
The discovery system (UDDI) is used by a hosting business to enter information describing themselves, publishing taxonomy along with the descriptions (WSDL) of services they provide. This allows another business to find their service by searching with some criteria. It also supports category-based search options.
After an appropriate service is found, a description (WSDL) is demanded. This description contains:
       • Operations included in the service
       • Input and output messages for each operation

The main benefits of the Web Services are:
       • Decoupling of service interfaces from implementations and platform considerations
       • The enablement of dynamic service binding
       • Increase in cross-language, cross platform interoperability

A Minimalist Model of A Web Service
In the core of Web Services, there are three basic elements:

• The Service. This is a software that is able to process an XML document it receives through some combination of transport and application protocols. The inner structure of the service is irrelevant. It is only necessary that it responds to a special format of XML files.

• For the service to interpret the information in XML documents there must be a shared description of an XML request-response format. This is described in an XML Schema. WSDL is commonly used but not necessary.

• The address of the service using a certain protocol. This is necessary to access the service. It can be an address for TCP or HTTP protocol but not necessarily is.

The fourth element is an envelope for the XML document. It is optional but very helpful, for example for putting additional information such as security and routing. SOAP envelopes are commonly used standard.
SOAP has two parts: A header that keeps all system information, and a body that contains the XML document to be processed by the Web Service. If we look at this simplistic model of the Web Services technology, it seen that this technology is very simple in its core.

The Roles
In Web Services, there are three roles and their operations.
A service registry keeps track of recorded services.
A service provider can create a Web Service and its service definition or publish the service with a service registry.
A service requester can find the service from registry to get WSDL service description and a service URL or bind to the service and invoke it.

Web Services programming stack
To understand the operations of Web Services, let us have a look at The Web Services programming stack. This stack is a collection of standardized protocols and application programming interfaces (APIs) that lets individuals and applications locate and utilize Web Services. Layers in the stack correspond to operations made by one of three roles above. First three layers are crucial to the system. The remaining layers are optional and will be used as business needs require them.

Below is a list of Web Services programming stack layers:
1) Network layer is at the bottom of the stack. It is the place of the protocol to transfer messages. Most often used such protocol is HTTP.

2) Messaging layer comes after the network layer. It is the communication platform between Web Services and their clients. All operations, publishing, finding, binding, and invoking is accomplished by sending messages. Most widespread message protocol is XML-based SOAP.

3) Service description layer. This is where service description rules are applied. WSDL is used for this purpose. Service providers describe their available Web Services to clients.

4) Service publication layer. This layer is about a service provider making its WSDL document available. UDDI can be used, but it is not necessary. Just sending an email attaching your WSDL document is considered as publishing.

5) Service discovery layer. This layer is where a service requester gets someone's WSDL document. UDDI is a possible interface, but receiving an e-mail with a WSDL document is also considered as discovery.

There are also higher level layers that are yet to be commonly used and standardized.

Common Misconceptions
As Web Services gained popularity, there appeared several misunderstandings about the concept. We are going to focus on main misconceptions about Web Services below.
1) Web Services are message oriented: There are two main middleware approaches in terms of interaction models. One is message-oriented middleware (MOM), which includes Web Services. The other is object-oriented middleware that is very different in nature. Applications that are based on CORBA or Enterprise Java Beans belong to this category. The interaction models determine most things about a system.

2) Web Services are not distributed objects: Web Services are very similar to distributed objects in the sense that they both have a certain description language, they incorporate well-defined network interactions, and they bear similar mechanisms for registering and discovering available components. However, Web Services are not distributed objects.

In a distributed object system, every object, with the exception of singleton objects, go through the following life cycle:
     • On demand, a factory creates the object instance
     • The consumer who wanted the creation performs various operations on the object instance
     • Sometime later, either the consumer releases the instance or the runtime system garbage collects it

3) Web Services are not RPC for the Internet: Remote Procedure Calling is done through a network abstraction for remotely executing procedure calls in a certain programming language. This low level operation requires the caller to identify the remote procedure, to decide which state must be provided to the procedure at invocation time, and what form to use to present the results to the caller at completion time.

4) Web Services do not need HTTP: Web Services do not depend on the transport protocol that is used. SOAP messages may well be transported through plain TCP or UDP, or even SMTP by e-mail. There are also alternatives such as MQSeries or Java messaging service (JMS) to name a few. These technologies can also be combined. For example a SOAP package that comes to the system through HTTP may be automatically forwarded to a certain server through TCP or JMS. Web Services are not specifically designed for HTTP, though HTTP is most commonly used.

5) Web Services does not need Web Servers: There was a discussion whether to drop the “Web” from Web Services. Terms such as service-oriented architectures, service-oriented integration do not mention “Web”, because they are independent of Web Servers. Early Web Services have exploited Web servers' application-server functionality, but now there are several toolkits that let you develop and integrate Web Services without using Web server infrastructures.

What is Web Service

-Satya Prakash

 The Internet has become something it never has been. We are connected to every other in a way that has never been in human history. This is a web of information, interaction, but at the same time it is a web of possibilities. Possibilities of friends, collaboration, learning and also a possibility of service providing and consuming. Business-to-business (B2B) relations through computer networks have a comparably long history, but a history with a separation of protocols, languages, standards. But The Web is one. With its user and producer-friendliness, HTML became universal, as well as XML that is similar. And a technology of a more connected world is being developed: Web Services.

                                          Simply put, Web Services are service requesting and providing, by sending and receiving messages of some format. The messages are commonly XML formatted. Most desired features of Web Services are interoperability between different systems, perfect security and quality (as it is for business use), easy interpretation and implementation.

BASIC CONCEPTS
Let us look at some basic concepts concerning this technology.

A human friendly format: XML
                                       In Web Services, many message formats are based on Extensible Markup Language (XML) which is a very general purpose markup language that is used in variety of applications. In every XML file, there are entities that are structured as a tree. It is a method of representing information that is both human readable and machine readable. Positive attributes of XML are:

         • Being both human and machine-readable
         • Unicode support, thus supporting nearly every human language
         • The tree structure is very appropriate for computer science abstractions
         • Names and values are openly written, making it a self documenting format
         • The format allows efficient parsing

And its weaknesses:
        • Its redundant, unnecessarily long format is a problem for efficient storage and transmission
        • With the same reason, every XML parser must check a file's format thoroughly to prevent errors
        • In XML there is no data type such as int or float, everything must be expressed through strings
        • The hierarchical model of XML is limited, compared to relational models such as databases. Representing non-hierarchical data in XML is difficult.

 Message format: SOAP
                         Web Services generally use SOAP as a message envelope format. Simple Object Access Protocol (SOAP) is a messaging protocol that is based on XML used usually with HTTP. The original acronym was dropped with version 1.2 as it was misleading, it became only SOAP. SOAP forms the second layer of Web services protocol stack, more abstract layers build on it. These are “service description” protocols such as WSDL, and “service discovery protocols” such as UDDI.
                                      Most widely used messaging pattern of SOAP is Remote Procedure Call (RPC). In fact, SOAP evolved from XML-RPC that was only capable of RPC messaging. SOAP was designed by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein in 1998. Its specifications are currently maintained by XML Protocol Working Group of W3C. It was intended to be a protocol to allow software applications to interact on the internet or any network.

Let us look at an example SOAP request and response:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails xmlns="http://warehouse.example.com/ws">
<productID>007</productID>
</getProductDetails>
</soap:Body>
</soap:Envelope>

Above is a SOAP formatted request example. It uses the operation “getProductDetails” to get information about the product with ID 007. This message is independent of the operating system or any inner structure of the server.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
<getProductDetailsResult>
<productName>Toptimate 3-Piece Set
</productName>
<productID>007</productID>
<description>3-Piece luggage set.Black Polyester.</description>
<price>96.50</price>
<inStock>true</inStock>
</getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>

This is the response of the server. The operation is realized, and product details are returned to the client. SOAP messages are text based and very easy to read. This is also a weakness as a limitation to transfer speed, because the messages are very long and this may affect network performance. Some other technologies such as CORBA use binary format and do not bear this weakness. This is a general problem of XML-based protocols.

Transferring messages: HTTP
                                  SOAP messages are transferred using Hypertext Transfer Protocol (HTTP). HTTP is a method used to transfer or convey information on the World Wide Web. Its original purpose was to provide a way to publish and retrieve HTML pages. It is also used to transfer XML files and XML-based file formats such as SOAP.
HTTP is used between clients and servers as a request/ response protocol. The connecting agent, a client, a web browser, or any other end-user application, is described as the “user agent”. The destination server is called the origin server. Resources such as HTML files and images are stored or created in the server. In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels.

Service description: WSDL
                                  Web Services Description Language (WSDL) is an XML based language for communicating descriptions of Web Services. WSDL defines services as a collection of “ports” that receive and send “messages”. But these are taken as abstract concepts and separated from their concrete use or instance.
                                                        A “port” is a network address that can be reused through binding. A “port type” is an abstract collection of supported operations. A “service” is a collection of ports. “Message” is defined as abstract definitions of data that is transferred. WSDL describes the public interface for a particular Web Service by using these concepts.
WSDL is generally used with SOAP. If a client program connects to a Web Service, it can get the WSDL to understand what operations are available on the server. Special data types are written in WSDL in XML Schema format. Then SOAP messages are used for calling the functions on the server.

A universal registry: UDDI
                                    There is a standard registry for Web Services. It is Universal Description, Discovery, and Integration (UDDI). UDDI is an XML-based list of businesses. It was written in August 2000, and it is sponsored by OASIS. It is like a platform or market that different businesses find each other's services and interact over the Internet. Every business registers on the following:

              • White Pages that include addresses, contact information
              • Yellow Pages that include sectoral categorizations based on standard classifications
              • Green Pages that include technical information about the services proposed

UDDI is queried by SOAP messages. Clients send SOAP messages to the UDDI to get service descriptions in WSDL. And then, using the protocol bindings and message formats described in WSDL documents, the client can use any service that is offered in UDDI by several businesses.