The idea of Web services has been floating around for a while, and we have seen many companies embracing the concept and moving ahead with implementation plans. Just like a Web application that consists of server-side code, a Web server, HTML pages, and a browser, Web services also consist of various components. Implementations of SOAP and UDDI have been in existence for a while. What caught my attention with Idoox's WASP (Web Application and Services Platform) was that it provides a single platform for creating, publishing, discovering, and using Web services.
WASP downloads come in two flavors. One is bundled with Apache Tomcat and the other is not, which means you have to manually configure it. I opted for the bundled version which was about 4.5 MB.
|"By using a familiar model and providing a series of utility scripts/tools, Idoox simplifies the entire creation and deployment process.|
The process of creating a Web service using WASP is similar to how you create a CORBA or RMI service. The first thing, obviously, is the business logic that you want to advertise as a service. This could be a simple Java class that makes some calculations or provides a message. This business logic will act as a server responding to requests made by various clients. Both the client and the server should be wrapped in a single package. The .jar files used by WASP are wasp.jar (which includes a variety of classes as implemented by idoox supporting SOAP, etc.), xerces.jar (Apache XML parser) and log4j (for application logging).
Web services describe themselves using a WSDL file, which is an XML-based file and can be created manually. WASP automates the process where the java2wsdl.sh (or java2wsdl.bat under Windows) will create the WSDL file based on the server code written in Java. The WSDL file is an important element of the framework. It contains information about the methods, input, output, binding, data types, and finally the service itself.
The next step is to create the stubs and skeleton files for the Web service. The concept here is the same as what you would do with a typical CORBA or RMI service (remember rmic?). The data transport would happen between the stub and the skeleton with marshalling happening on either side. Given the WSDL file and the package name, the services.sh script will create the stub and skeleton Java source files, which you will then compile.
The next step in the life-cycle of a Web service is to publish it or deploy it. WASP provides a utility script for that as well, called deploytool.sh. By providing the WSDL file, the package name for the service, a URL, and a name, the service will be deployed to Tomcat. Your client will instantiate and call the methods of the server class as if they were local classes. In reality, the call is being made to the local stub, which will in turn translate the call into a SOAP message sent to the server. This greatly simplifies the client application, as it does not have to get involved with the details of SOAP implementation.
Idoox provides a nice framework for working with Web services. By using a familiar model (i.e., CORBA and RMI) and providing a series of utility scripts/tools, it simplifies the entire creation and deployment process. The next release promises to support EJB wrapper generation and WAR deployment.
Check out the online Idoox tutorial for a great way to get started with WASP.
About the Author
Piroz Mohseni is president of Bita Technologies, focusing on business improvement through the effective use of technology. His areas of interest include enterprise Java, XML, and e-commerce applications.