In the previous 2 articles, we learned how to build a simple JAX-WS web service and a client to interact with it without any introduction to web services concept and the technologies or protocols involved. This article is targeted to those who wants to know the basic concepts and technologies involved in building the web services. If you are already aware of how web services are evolved and the technologies involved, I suggest you to skip this, and wait for the next article on this series to know more about JAX-WS services.
Introduction to Web Services:
Web services are applications or application components that can be accessed by heterogeneous applications over network.
I have mentioned the term ‘heterogeneous’, meaning that any application (written in a programming language) can communicate with any other application(written in some other programming language) via a web service call, provided that both the applications follows certain standards and protocols. This sounds like ‘the B2B(Business to Business) or B2C(Business to Consumer) communication can be implemented easily by following some standards and protocols!! Well, that’s true, when you become proficient with technology involved and master the concepts.
So now, one may ask, What is B2B or B2C communication and why the industry need it? Is it the technology that facilitates this communication possible?
B2B communication could be imagined as exchanging a message between the applications involved or asking an application to execute a specific task, which might have several sub tasks and each one is shared among a set of computers connected through network. This is very much required in this heterogeneous world as many applications and day to day needs depend on this kind of interaction.
An Example of this scenario:
You want to pay your telephone/mobile bills on your the provider website. How do you do it? I am assuming these steps:
1. You login to provider website, use the option “make payment”.
2. Then you will be provided with a list of banker names retrieved from a third party payment gateway application, where you can choose your bank.
3. Then you will be taken to your bank website, where you login into bank with your bank credentials and make the payment
4. Return to the telephone provider website with a success or failure message.
In this example, three different applications are involved.
1. Your phone provider website
2. Third party payment gateway
3. Your banker’s application
I am sure, all the three applications are not developed and maintained by any of the above organizations and each of the application might have been developed in different technology and should be running in different environment and network. So, how are they communicating? what is the technology? what about the security? We will know about these in the following sections and in future posts.
I guess, now you should have realized the need for communication between different applications and the information exchange required between these applications.
Well, there are alternative technologies for this kind of communication other than web services. Let me quickly walk-through some of these technologies.
Brief History:
Before web services, the distributed application communication in the name of EDI (Electronic Data Interchange) use to happen using the famous technologies like DCOM (Distributed Component Object Model) from Microsoft, CORBA (Component Object Request Broker Architecture) from OMG and RMI (Remote Method Invocation) from Sun. All these technologies uses RPC (Remote Procedure Call) as the underlying mechanism for communication. RPC uses sockets for communication, sockets are not accessible if they are behind firewalls, this has reduced the application scope to intranet. Each of these technologies use a different protocol for communication. DCOM uses ORPC(Object Remote Procedure Call), CORBA uses IIOP(Internet Inter ORB protocol) and RMI uses jRMP(Java Remote Method Protocol). Because of the differences in the protocols, one application(implemented in DCOM) cannot talk to other application(implemented in either RMI or CORBA). The tight coupling between the client and server components in each of these implementations has given less chances for scaling the applications. RMI can be used only for communication between JAVA applications. The DCOM is often misunderstood that it can be used with only Microsoft platforms, even though it has ports supported with other platforms. The DCOM, CORBA are more complex in terms of their learning curve and/or implementation and their compatibility with each other. None of these technologies had got industry acceptance and the required support from the major vendors. This is one of the reason why these technologies did not succeed.
With this little background, you should have identified that there is need for some innovative technology which can simplify the distributed computing across applications.
Evolution of Web services:
Web services, the term was officially aired by Microsoft then CEO Bill Gates in a tech conference in the year 2000, though it was being discussed by many industry giants during that time.
If you have understood the problems mentioned above with alternative technologies the real problem for cross-application communication alternative is learning curve, complexity in the technology and industry acceptance. The industry acceptance is very much required for B2B or B2C communications, because that is the only way those applications can support those technology and provide support for it within their application. To gain this acceptance the technology need to be simplified.
Considering the above facts and needs, web services are built around the already accepted protocols and standards like TCP/IP, HTTP and XML. TCP/IP is the famous and widely accepted transport protocol on the web. HTTP is again the widely accepted application protocol. XML is considered as a standard platform-independent data description language. I would say XML invention is the one which boosted the web services adaption, the reason for this is that, XML document is a simple well-formed text document, which is very easy to interpret for any one and it is easy to describe the data and data types in XML format.
Web services technologies:
I assume the reader has basic understanding of TCP/IP, HTTP and XML, I will not be discussing them further. With these standard protocols/technologies in place, a team from Microsoft and Dave Winer from Userland Software come together to form a messaging protocol called SOAP(Simple Object Access Protocol).
SOAP(Simple Object Access Protocol):
SOAP is XML based message exchanging protocol specification, which is a successor to XML-RPC. XML-RPC is again a messaging protocol used to make remote procedure calls in the form of XML messages. While RPC calls are tightly coupled with the specific application technologies(because, the client need to create stubs to access the remote interface) the SOAP has helped to remove this tight-coupling by facilitating the message exchange through HTTP. SOAP is a platform-independent, language independent protocol for communication between applications.
IBM supported the idea of SOAP and started contributing for it’s standardization. Later on both IBM and Microsoft come up with a language called “Web Services Description Language(WSDL)” to describe the service being offered.
WSDL(Web Services Description Language or Web Services Definition Language):
The official definition of WSDL according to w3c is this:
“WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate”
WSDL is written in XML. It is an XML document, with the file extension ‘.wsdl’ describing how to call the web service, the functionality offered by web service, data structures used for input/output and the protocols and standards to follow. It serves the same purpose as a class file with multiple method signatures in object-oriented programming languages.
The latest version of WSDL is 2.0.
For more details on WSDL visit the w3c specification site at http://www.w3.org/TR/wsdl#_wsdl
With both SOAP(a message exchanging protocol) and WSDL(a service description language) in place, companies could create and describe their web services, but they still need some way to publish and locate the web services. Then again Microsoft, IBM and Ariba worked together and came up with a solution called Universal Description, Discovery and Integration famously called as UDDI.
UDDI (Universal Description, Discovery and Integration):
Universal Description, Discovery and Integration (UDDI, pronounced Yu-di?) is a platform-independent, Extensible Markup Language (XML)-based registry for businesses worldwide to list themselves on the Internet and a mechanism to register and locate web service applications.
UDDI is an open industry initiative, sponsored by the Organization for the Advancement of Structured Information Standards (OASIS), enabling businesses to publish service listings and discover each other and define how the services or software applications interact over the Internet.
UDDI was originally proposed as a core Web service standard. It is designed to be interrogated by SOAP messages and to provide access to Web Services Description Language (WSDL) documents describing the protocol bindings and message formats required to interact with the web services listed in its directory.
The latest version of UDDI is 3.0.2. If you are interested in the specification, visit http://uddi.org/pubs/uddi_v3.htm
With SOAP, WSDL and UDDI in place, the de-facto standard to implement web services is available. However, this standard had taken momentum only when the top brands(IBM, Microsoft along with Oracle, Sun and HP) committed to support this standard.
Web services have become famous because of cross-vendor support and attention to simplicity and flexibility of design.
Java and the Web Services:
As mentioned in the beginning, Java provided RMI as the approach to invoke remote procedure calls, that has facilitated inter-application communication among Java applications. They extended their RPC methodology to work with web services standards outlined by the industry folks and called it as JAX-RPC 1.0(Java API for XML based Remote Procedure Calls). But, as the industry was not just doing RPC based web services and also doing message-oriented web services, the later versions of JAX-RPC 2.0 is renamed to JAX-WS(Java API for XML based Web Services) with more enhancements to the technology.
With JAX-RPC/JAX-WS, as a web service provider, you will have to create a web service and create a WSDL and publish it on public registry. Service consumers will have to use the published WSDL to generate the stubs on the client side and make calls to the service using those Stubs.
There are two approaches to create a web service. Contract-first and implementation-first. In contract-first approach, we create a WSDL first and agree with consumers on the service interface and then provide implementation in accordance with the WSDL. In implementation first approach, we code for service implementation details, and then build WSDL out of the implementation and share the WSDL with the consumers
The current version of JAX-WS is 2.2.6. And it supports the following features.
1. Supports SOAP 1.1 and 1.2
2. Supports WS-I basic profile version 1.0 and 1.1
3. Supports HTTP binding, by which you can send XML messages over HTTP without SOAP envelope.
4. JAX-WS uses most of the Java SE 5.0 features, such as annotations, generics and etc.
5. JAX-WS uses JAXB for data-mapping or XML to Java object conversion and vice-verse.
6. Supports asynchronous functionality where is the initial versions of JAX-RPC only supports synchronous services.
7. Supports MTOM(Message Transmission Optimization Mechanism) for sending attachments with the web service call.
8. Supports SAAJ(Soap with Attachment API for Java) 1.3 specification.
Most of technologies mentioned in the above feature list are hidde from the developer perspective. However, interested readers can find the information on the net
That’s the brief story about web services and their evolution. Hope it helps someone!
References:
http://www.informationweek.com/news/6506480
http://en.wikipedia.org/wiki/Web_service
http://www.w3.org/TR/ws-arch/
http://www.w3schools.com/webservices/ws_intro.asp
http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc/index.html
