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
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
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.