What do you do if your company has a Windows server that needs to interact with a service provider’s UNIX server? They’re two separate platforms, whose applications aren’t necessarily compatible with each other but they need to share and manipulate data between them. This requires the use of a distributed computing technology. Among others, there are technologies such as CORBA, EJB and RMI, which allow for the creation of client-server applications.
Web services are another one of these technologies. It makes use of HTTP (hypertext transfer protocol) and XML (extensible markup language). Web services allow you to take your application and convert it to a web application, allowing it to publish its results for other software applications. This will allow other devices, and even completely different platforms to access it and read its output. Since it’s based on XML, it is both platform and language independent, so an application written in C# and running on Windows can seamlessly interact with a service written in C and running on a Linux server. Though XML is simple and intuitive, it can be used to represent complex data or functions.
Web services are components of applications that are self-contained and self-described, which communicate using open protocols. They can be searched, located and then used by other applications. A web service component can be made for any type of application. The programming language the application was developed in is not a limitation either.
The web service architecture is made up of 3 basic elements that carry out the following tasks:
• Exchange of data between applications via HTTP
• Description and location of the web service
• Lookup service based on the description of the web service
These elements are known as SOAP, WSDL and UDDI respectively.
The typical invocation of a web service goes somewhat like this:
The client application will have to discover or locate a web service based on what it is trying to achieve or what type of data it is searching for. This is done by searching a service like UDDI. Once a service is located, we need to know how to invoke the service, what parameters will have to be provided in order to get the information that we require. For this we will need a description of the web service. The web service will then describe itself to the client application using WSDL.
Once the client understands the description of the web service, particularly how to invoke it, it will send its request using the SOAP protocol over HTTP. If the invocation was done correctly, web service will also reply, sending its response also using SOAP. If not, it may indicate the request sent to it was incorrect. This is a simplified explanation of how applications interact with each other via web services.
