Web Services - separation of definition and implementation

Understanding Web Services. Services has been in our desktops for years. If you have a PC ,
Go to Control Panel --> Administrative Tools --> Services. The web is taking an evolutionary leap to adapt this software architecture which has been very successful in our desktops.

What is a web service ?
In my approach in trying to understand what a web service is we go to the basics,
find a definition of what a web service is. Here is the definition from the W3C web site
(http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/).
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

From the definition above we can infer the following:
1. interoperable machine to machine -- no mention of the OS of the machine
2. The service is described in a machine-processable format -- WSDL
3. Uses SOAP messages -- HTTP with an XML serialization.

These are the characteristics of what a web service should be. We must take that in consideration whenever we create or architect a web service.

What comes first the WSDL or the Web Service ?
Learning the definition above i have come to question how i create web services. I have created different web services and have used the following approaches. There are two approaches for creating a Web Service in Java

1. Top Down Approach
In this approach you create the WSDL (Web Services Description Language -- the machine
processable format) file first.
2. Bottom Up Approach
In this approach you write the service implemenation first in Java or any programming
language and a tool will help you generate the WSDL describing the service.

I must say that it is really quick an easy creating web services using the Bottom Up approach.
IBM WSAD and RAD supports it. Apache Axis has has the Java Web Service files. (jws -- http://ws.apache.org/axis/java/user-guide.html#JWSJavaWebServiceFilesInstantDeployment)
The approach was fine until we try to consume the web services in different platforms. This is a major issue because you create a web service so that it will be interoperable with other platforms. Another issue is that you tie up your service definition to your service implementation, the WSDL is generated based on the service implementation. In my opinion, web services should have separation of definition and implementation. The consumers of the web service should not be affected by any implementation changes. The service definition needs to be re-generated if there was change to the service implementation. This means that it will impact the consumers of the web service.

I recommend creating web services using the Top-Down approach. Create the definition of the
web service first. This will help you think thru the overall design of the web service that you are trying to expose. Generate the implementation from the service definition. This way, you can implement in Java, .Net or any other language but the web service definition will remain the same and will be consumed the same.

A SOAP for cleaning
Taking the definition above of what a web service is, we can say that SOAP is much as a cornerstone of web services as WSDL. SOAP uses XML messages so that the consumer and service provider can communicate. Right now SOAP offers us a lot of good to formalize the use of XML as means for web services to communicate BUT one there is one drawback that is not a real fit for the future of web services as many web service developers like me come to realize.

SOAP Encoding -- Section 5 Encoding of the SOAP 1.1 Specification (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383512) . Right now when creating a WSDL you have two choices in specifying the type of the SOAP Messages of a portType's binding, those are "literal" and "encoded".

If you choose "literal" (which is the recommended type) it means that the XML SOAP Messages
refers to a concrete specification of what will appear in the SOAP Messages. The XML SOAP Message will be validated against the concrete specification defined in the WSDL if the XML SOAP message does not match the specification, the message will be discarded and the web service will return a "fault" without having to do any other work.

If you choose "encoded" it means that the XML SOAP Messages refers to an abstract specification that will be made concrete by applying the rules defined by SOAP Encoding. There will be no validation of the the XML SOAP Message format and the message will be processed by the underlying service implementation.

The issue with an encoded message type for portType's binding is that the you will not know that the message request is invalid until you actually process the request.

Enjoy creating web services!

Comments

Popular posts from this blog

OAuth 1.0a Request Signing and Verification - HMAC-SHA1 - HMAC-SHA256

Spark DataFrame - Array[ByteBuffer] - IllegalAurmentException

Gensim Doc2Vec on Spark - a quest to get the right Vector