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.