Jtrix: Web
services beyond SOAP
Tutorial Details:
Jtrix: Web services beyond SOAP
Jtrix: Web services beyond SOAP
By: By Nik Silver
A new bag of tricks for developing Web services SOAP can't deliver
ini 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 m
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Jtrix: Web
services beyond SOAP
View Tutorial: Jtrix: Web
services beyond SOAP
Related
Tutorials:
 Clean up your wire protocol with SOAP, Part 1 - JavaWorld March 2001
Clean up your wire protocol with SOAP, Part 1 - JavaWorld March 2001
|
Clean up your wire protocol with SOAP, Part 2 - JavaWorld April 2001
Clean up your wire protocol with SOAP, Part 2 - JavaWorld April 2001
|
Clean up your wire protocol with SOAP, Part 3 - JavaWorld June
2001
Clean up your wire protocol with SOAP, Part 3 - JavaWorld June
2001
|
XML messaging, Part 2 - JavaWorld June
2001
XML messaging, Part 2 - JavaWorld June
2001
|
Clean up your wire protocol with SOAP, Part 4 - JavaWorld July
2001
Clean up your wire protocol with SOAP, Part 4 - JavaWorld July
2001
|
XML messaging, Part
3
XML messaging, Part
3
|
Axis: The next generation of Apache SOAP
Axis: The next generation of Apache SOAP
|
Cache SOAP services on
the client side
Cache SOAP services on
the client side
|
Jtrix: Web
services beyond SOAP
Jtrix: Web
services beyond SOAP
|
Sun boosts
Sun boosts enterprise Java
|
Publish and find UDDI tModels with JAXR and
WSDL
Publish and find UDDI tModels with JAXR and
WSDL
|
Axis-orizing objects for SOAP
Axis-orizing objects for SOAP
|
The Java Web Services Tutorial
This tutorial is a beginner\'s guide to developing Web services and Web applications using the Java Web Services Developer Pack (Java WSDP).
|
SAAJ: No strings attached
SAAJ: No strings attached
|
Call on extensible RMI
Call on extensible RMI
|
WS-Specifications
WS-Specifications
The WS-Specifications build a composable architecture to form an environment for complex Web Service applications. Different vendors, such as BEA, IBM, Microsoft, RSA Security and SAP, have joined forces to lay the foundation of secure
|
Excerpt from Apache Axis Live
Excerpt from Apache Axis Live
This chapter, "Getting Started with the Apache Axis Project," you will take "a brief look at what Axis is and how it implements some of the SOAP services.
|
Free SOAP Monitor
Membrane SOAP Monitor is a free Web Services development tool for inspecting and manipulating SOAP messages. It acts as a SOAP proxy between a consumer and a producer. SOAP messages can be intercepted, viewed and modified.
|
The JavaTM Web Services Tutorial
A beginner's guide to developing Web services and Web applications on the Java Web Services Developer Pack
|
Integrating Java Open Single Sign-On in Pluto
This article shows how to integrate Java Open Single Sign-On in Apache\'s Pluto portlet container.
|
|
|
|
