Tuesday, August 24, 2010

Web services past, present and future

What is a Web service? There are multiple definitions or understandings about Web services, one can argue Google search as a Web service, meaning a service offered via Web, same way Amazon retailer site can be also considered as a Web service, because it offers a way to buy and sell product over the Web, or application to application communication through open protocol like SOAP can be also considered as Web service. However, here my main focus is SOAP based Web services, meaning application to application communication.

In the distributed system, remote service invocation is not a new thing at all, even in the early papers on operating system design discussed about remote procedure calls or RPC. In fact they have provided sound architecture to implement RPC. Later, people wanted to develop more complex and application aware middleware to have distributed communication, among them CORBA and Java RMI became two commonly used technologies. Nevertheless, due to complexity of CORBA and domain dependency of Java RMI (only within JAVA) people tend to find other alternatives. Introduction of XML into the industry influenced lot on this effort. Then, people realized XML as the future communication media, in fact Bill Gates also believed XML going to be the dominant media for applications communication.

As a results of long collaboration between IBM and Microsoft (and also some other companies), SOAP came into the industry as a way of building application communication middleware. IBM started its implementation of SOAP based web service middleware and later donated that to Apache Software Foundation and which became Apache SOAP, and started Web service community around Apache. Apache SOAP was very simple and assumed to be proof of concepts; people really liked Apache SOAP and started to use it to application integration, then demanded a set of new features, which leads to have an array of Web service standards and specifications. In addition a set of Web service bodies to enforce satisfaction of specifications. At that time there were multiple Web service frameworks out there, Apache had Apache SOAP and Apache Axis, and Microsoft had Indigo (later renamed to .Net), Oracle, Sun, BEA, HP and few other companies had their own implementations.

One of the natures of any application is need of evolving and revolving, same thing happen to Web services, where it started as a simple set of standards, but today there are a number of standards. As a matter of fact Web service has become somewhat complex for average people. Even though there are hundreds of Web service specifications, there is no single Web service framework which implements all the standard, according to my understanding Axis2 is the only open source Web service framework implement highest number of standards, and of course Microsoft is leading in commercial market.

One of the main barrier of Web services is the complexity of WSDL, both WSDL 1 and WSDL 2 are little too complex to understand. In addition other standard like Security, Reliability and Addressing are way too complex for simple usages. That is something, standard bodies need to consider about.

Way back in 2004 when we started Axis2, one of the key goal was to have less than 1 MB size for the distribution, but, due to supported specifications and features it is way too big and complex. I have seen number of concerns on the mailing lists. I think this is true for any product, when they keep adding features, application become complex and size become larger.
Within a short period of time, Web services have made big impact to the industry, where most use Web service as a way of application integration. In addition most applications offer a Web service interface to access the service (e.g., Google, Amazon, Weather), which help to write custom components and application. Above all, with cloud computing, Web service became one of the standard ways to manage and monitor cloud based services. Simply, Web services have won the market today. But what will happen in the future …..

I think, due to complexity of Web service, people tend to find other alternatives or ways to reduce the complexity of Web services, but one thing is obvious that is XML will remain unchanged. In the future regards REST will play a major role, even today some believe REST is better than SOAP, which is in fact true for some scenarios, but when it comes to complex scenarios REST is not there to support them. Simply need additional specifications to handle addressing, security and etc… which will end up being yet another SOAP based Web service framework. As a Web service lover, I still believing in Web services, but I would like it to be simple and easy to use, yet provide what industry need.