Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Jtrix: Web services beyond SOAP

A new bag of tricks for developing Web services SOAP can't deliver

By Nik Silver, JavaWorld.com, 05/03/02

Jini and EJBs (Enterprise JavaBeans) provide a terrific basis for Simple Object Access Protocol (SOAP)-based Web services. But SOAP is just a slightly advanced form of remote procedure calling, and while Jini and EJBs are ideal for a trusted intranet environment, they are ill suited for the untrusted Internet. If you're building Web services, you should know the limitations of these standards and how Java can take you beyond them. In this article, I look at the wider scope of Web service concepts, where Jini and EJBs stop and an implementation called Jtrix advances.

An example Web service

Suppose you write a Web application with servlets and JSPs (JavaServer Pages) and you want to host it somewhere. You could take several steps in an ideal Web services world.

You could upload your war file to an HTTP service, which listens to HTTP requests. The HTTP service needs sufficient CPU time, disk space, and bandwidth to execute your application; therefore, it locates a hosting service, where it can live and work in such an environment. You tell the HTTP service that your uploaded file needs a servlet engine, so the HTTP service looks for a servlet engine service. When an HTTP service receives a request, it passes the request to the servlet engine for processing and then returns a response.

The HTTP service also handles scaling (finding more hosts when your site is busy) and redundancy (running several copies of your site code simultaneously, in case one fails). It also interacts with a DNS (domain name service) to ensure your domain details are updated.

In addition to these, your application requires certain services, such as a database, more disk space, and credit card authorization.

Web service limitations

SOAP-based Web services are insufficient for this model Web services environment. SOAP is essentially remote procedure calling; it returns data. But the HTTP service needs a hosting service (i.e., CPU time, disk space, and networking), so it must migrate itself and your war file to run in the ideal location described previously. CPU time, disk space and networking are not data. The service also needs a servlet engine, like Apache Tomcat, which must be local to the HTTP server to be efficient. Again, a servlet engine is not data.

More complications arise when your Website needs, say, a database. Given that the database is distributed (which it must be to scale or run over several machines), part of the database must be local to your application (for efficiency) while another part must be at a central data store. Once more, SOAP returns data but the Website needs an application part to be delivered and run, which is again more than data.

The key requirement

Although the traditional Web services model doesn't support these service types—HTTP, hosting, and servlet engine services—they are quite reasonable Web services. You should be able to offer an HTTP server as a Web service. And that server should be able to demand a servlet engine service (as well as an authentication engine, a logging engine, and so on). An ISP should be able to offer CPU time and disk space as a service as well.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.