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.

The key requirement, however, is hosting. If you (or an ISP) can host untrusted code, and those applications can interact safely, then code becomes mobile and everything else falls into place—the Web services market becomes less constrained. Suppose your Web application is the next Hotmail, a little service that suddenly sets the world alight. If you can buy disk space, scalability, and redundancy as services, then think how much easier it would be to develop Web services.

Jini and EJB limitations

Jini, EJBs, and RMI (Remote Method Invocation) are all client/server technologies. Both based on RMI, Jini focuses on delivering services and EJBs manage applications in controlled environments.

Looking back at our Website example, we want mobile (roving) code: we want to download and run an application part (e.g. servlet engine) or upload and run our application (e.g., to a machine offering CPU time and so forth, as a hosting service). Thanks to RMI, EJB-based applications are distributed, and Jini services offer downloadable code. But RMI only works when the client and server trust each other. By contrast, our Website example wants code roving to and from third parties outside such a trusted relationship.

EJBs usually do run within a trusted client network, so I will examine this trust requirement with reference to Jini next. The same issues relate to EJBs (and RMI components in general) if they need to run across untrusted networks.

Isolation issues

A Jini service must deliver to a trusted and trusting environment, on which version numbers are previously agreed. In Figure 1, Jini application A uses a Jini service. However, the stub downloads into the same class space as the original application. Suppose the application and the service both use parser.jar, but one uses version 0.9 while the other uses 1.0. This causes a conflict, and both the stub and the application render unusable.

Figure 1. A Jini service runs in the same classloader as the client application, requiring trust from both ends

Figure 2 shows a minimal improvement, where application B sets up a classloader to isolate the stub. But this is not symmetric. The stub remains at the application's mercy and must still trust the application.

Figure 2. Application B provides some protection for the client application

Problem summary

You can see these models—Jini and RMI—don't offer complete trust and isolation. Therefore, we have several problems:

  • The environment is not secure, which hobbles service opportunities
  • Lack of version isolation makes running arbitrary code difficult
  • An infinite loop or deadlock in the service's code could lock the application
  • Neither the application nor the service stub can use disk space without a complicated prior agreement on file space
  • Trust is still an issue

In all, this prevents anyone from offering a hosting Web service, which means you cannot call in arbitrary code to fulfill a Web service. You're reduced to SOAP-like remote procedure calls, which are severely limiting.

Jtrix: An alternative model

The Jtrix model addresses all these issues. As Figure 3 shows, it implements a model where each application has its own classloader. As such, each application is responsible for its own JARs, which are allocated exclusively to its own class space. The Jtrix runtime environment is called a node.

Figure 3. A Jtrix node enables symmetric trust

Communication between the application and the service occurs transparently via the mediator. The mediator protects the node from the applications and the applications from each other. It ensures that while primitives are copied, objects are only proxied. Applications might need to share some interfaces, but implementations are isolated.

Suppose Jtrix application D returns an interface IMoneyBag, and application C needs the interface without its implementation. If a method in IMoneyBag returns an actual object Coin, then C gets a proxy Coin object, courtesy of java.lang.reflect.Proxy. To C, it looks like a real Coin, but method calls are serialized back to D for handling. Any Coin object implementation held by C is independent of the implementation in D. This way, applications can use whichever class and JAR versions suit them.

Hosting service

The Jtrix model lets anyone run untrusted code; hence, you can offer hosting as a Web service. A Jtrix node can wait for an application or applications (HTTP service, plus war files and a servlet engine) to upload themselves and then let them work together without requiring mutual trust.

Security and resource control

In security terms, Jtrix enables symmetric sandboxing; that is, two applications are isolated from each other without either one being superior to the other. Jtrix also adds resource isolation and control.

For example, applet security often shuts off access to the file system. But suppose both applications (reasonably) want to use the file system. Jtrix can grant each classloader its own file system implementation, each mapped to its own isolated space. Application C can create a new File("/home/diane") entirely separate and transparent from D's file of the same name. Networking is similarly isolated and individually managed and monitored.

In addition to disk and network resources, threads are another resource you should carefully attend. The mediator enables much flexibility here. A method call from C to D will not lock up C if D enters an infinite loop. Timeouts bring C back to life, despite D's buggy code. If a call to D also requires a call back into C, then the mediator is smart enough to reuse C's original thread; therefore, it doesn't have to start a new thread, which can be expensive.

Meanwhile, a client application can also request that the mediator invoke a normally synchronous service method in an asynchronous manner. Or a service application can request that its response to a method call defer until a more convenient time. Application independence is powerful when taken to extremes. This is just some of the thread control Jtrix enables and implements.

Accountability

A hosting service is useless without billing capabilities, so accounting is important. Jtrix uses the Java Virtual Machine Profiling Interface (JVMPI) to measure memory and thread use. It also manages file system access and bandwidth, as mentioned earlier.

Thus, an application can be billed precisely according to its resource usage. So when charging for your Web service, you can build a business model that closely reflects usage. Anyone who has created a business model will know this is a rare event. Normally, hidden costs, such as hardware and staffing, make creating an accurate business model more complex. But you can factor out these hosting and runtime costs into an external service. The ISP or other hosting supplier calculates those costs and charges you in strict proportion.

Jtrix is for developers

When you think about Web services, you can too easily jump straight to Jini and EJB because they support SOAP-based services. But Web services can mean so much more, and you can still use Java's benefits. Jtrix is open source, so you can download it and investigate it further. And if you're developing the next killer app or service, you now have one more tool at your disposal.

Nik Silver has spent two years managing the Jtrix platform development team and open source community, and is responsible for almost all its documentation, from the highest conceptual level down to the Javadoc. Prior to that, he was a consultant and technical project manager for more than six years with one of the UK's leading Web agencies. In 1994, he received a PhD for work in the field of artificial intelligence.

Learn more about this topic