I suppose we should be thankful for web services: we are no longer considered aliens when speaking about service oriented architecture (SOA). In fact, it's even cool to talk about SOA. The company I work for has even recieved RFPs that require SOA. The unfortunate side-effect of all this is that SOA is now often understood as synonomous with web services. This despite the fact that web services are not particularly well suited for the task.

A Simple Definition

Review of Services

Implementation

Why mention CORBA? Well, CORBA was the first serious OO-based SOA. Second, it has a lot in common with web services. And, finally, thanks to it's past popularity, the lessons to be learned from the CORBA experience should resonate with many of us.

Interfaces

WSDL and OMG IDL are meta-languages whereas Java is a real language. The distinction is fundamental because it is the interface that enables the semantics.

Java Interfaces

Java interfaces are polymorphic and the methods have strongly-typed parameters, return types and exceptions. These notions extend to all other classes and interfaces in the language.

If using RMI, an interface's implementing class (aka proxy, or stub) has an associated ClassLoader. This is a powerful feature because we can choose which class to load based on its ClassLoader. If we don't trust the ClassLoader, we don't load the class. Jini 2.0 takes this further by providing means for establishing proxy trust on a per proxy basis. With these mechanisms, a service client can safely load never-seen-before classes.

WSDL and OMG IDL

There are two main problems with langugage-independent IDLs. The first is that history has shown it is hard to reliably achieve correct behavior at the endpoints. And secondly, as I hope to show, an unacceptable number of architecture-critical features are lost. In Java you can make use of semantically meaningful design patterns. For example, the event pattern is based on sources and listeners. The RemoteEventListener class has the semantics of the Remote object. Additionally, objects are serializable (or not) for a semantic reason, e.g., Socket can't be serialized and the language enforces it.

Java includes JAAS, a complete language-based security model. This is not a high-level add-on; it's built into, and enforced by the language. There's no question how the security patterns will behave when properly used.

Jini Extensible Remote Invocation (JERI) provides a highly-customizable RMI programming model. JERI provides a set of patterns for establishing communication transports, for establishing per method constraints (most notably security constraints), and for exporting them to remote clients. JERI provides a protocol-independent, secure means of performing RMI-style interactions with remote services. This is much more convenient and reliable than a protocol-based, language-mapped system can provide.

Meta-language interface definitions lose all these capabilities.

An Example

public interface Cookie {
  String getCookie(int select) throws java.rmi.RemoteException;
}

But (a small part of) the WSDL reveals problems:

<message name='CookieService_getCookie_Response_Soap'>
    <part name='response' type='xsd:string'/>
</message>
<message name='CookieService_getCookie__Request_Soap'>
    <part name='p0' type='xsd:int'/>
</message>
...
<operation name='getCookie' parameterOrder='p0'>
    <input message='tns:CookieService_getCookie__Request_Soap'/>
    <output message='tns:CookieService_getCookie_Response_Soap'/>
    <fault name='RemoteException' message='tns:RemoteException'/>
</operation>

First off, there's an obvious difference in complexity and readability. It's trivial to write a Java interface but even a simple interface is daunting in WSDL. Thank God there's tools that usually work.

Secondly, and most important, Java's strong-typing means an int will actually be sent and recieved. Both service end-points are Java so the protocol is irrelevant and the "mapping" is always consistent via Java object serialization. If a malicious client sends a bogus message, the service still throws IllegalArgumentException or RemoteException. By contrast, WSDL end-points are undefined, so the protocol is all we've got. We are ensured of the formatting on the wire, but we have no idea what happens if type='xsd:int' is incorrectly mapped or unmapped.

If you as a service writer, happen to be using JERI, then you get the benefit of controlling both service endpoints through mobile code. This means that even if you are using a custom protocol, you are in control of how objects are marshalled and unmarshalled on both ends of the wire. You no longer have to put your service's reliability into the hands of some unknown entity on the far end of the wire. You don't need to worry about endpoints that might be out of compliance with the protocol, that might have bugs you can't fix, that might not support the same version of the protocol, or that might even be malicious.

Stories We've Heard

"But the XML stream is ASCII so I can see what's going on." So when was the last time you had to crack a JRMP stream? Readable protocols may be good for debugging in the absence of middleware support, but if you still require human-readable protocols in your application, then you have more serious problems. Anyway, are SOAP suds any simpler to read than JRMP? And if you really want readability, Jini and JERI can give you an ASCII stream if you want one.

"But in practice, the end-points are Java anyway." If so, then why go to all this trouble? You're still at the mercy of the endpoint implementations.

"But I can us HTTP/HTTPS for the transport." With Jini you can use HTTP/HTTPS if you want to. JERI makes it quite easy to do so.

"But everyone else is using it." When it comes to fads, software technologists are no better than teenagers. We chase the latest thing in hopes it will solve our problems. We falsely assume the next new technology is a step forward. The facts are that we work on hard problems, that technology doesn't always take forward steps, and that "everyone else" are often wrong.

Pedagogical Grid Computing Example

A grid needs a point of entry:

public interface Grid {
    public JobId submit(JobSpecification jobSpec,
                        UserSpecification userSpec,
                        RemoteEventListener callback)
        throws RemoteException, GridException;
    // other methods ...

Notice the semantic richness of this example. Furthermore, the use of dynamic callbacks makes for a much more powerful application. This is beyond the reach of web services. Inside the Grid cloud, the argument for real objects is stronger still:

public interface Task {
    public void prepare(Object o) throws Exception;
    public void setRunnable(Runnable runnable);
    public void addListener(RemoteEventListener
                            listener);
    // other methods ...
}

Here's an example of the Active Object Pattern for distributed objects. Again, this is way beyond the capabilities of web services but dramatically increases the power of a grid application. Anyone familiar with Jini is probably thinking, "what about JavaSpaces?" Indeed, JavaSpaces is an ideal grid service technology that would be very difficult to leverage in a web services-based grid solution.

Some Miscellaneous Ranting

Web Services breaks one of the key doctrines identified in the classic "Note on Distributed Computing": Local vs. remote objects. The argument made by Waldo, Wolrath, et. al., is that there is a fundamental difference between local and remote objects and any distributed system that attempts to hide that difference is fundamentally flawed. At the time, CORBA was the example of remoteness-hiding, but we can substitute web services and make the same points.

After all this, it seems amazing that the Globus group would use Web Services as the basis for a globally distributed system!

Some Conclusions

Web services has begun to slide down into the trough of disillusionment. For reference, Jini appears to have passed through the trough of disillusionment and is climbing up the slope of enlightenment. (These are my estimates. You can see exactly how the Gartner Group evaluates them for only $495). How deep will the web services trough be? Will it find a niche after enlightenment? I think so.

Web Services is a great integration technology (like a modern EDI). It provides a "common backplane" for weaving together disparate functions and allowing them to work together. For the IT department, web services is a Godsend. In that universe, the endpoints can be managed to ensure true interoperability. Whether web services is better at this than something else, say Jini, is a arguable. For example, if there's a degree of dynamic behavior, if services may come and go, then Jini would be better. If the environment is static, then web services is great.

Web services is a good tool for exporting non-web services to a web environment. In the IT world, a web-based SOA has the advantage of utilizing a browser as the client. This can ease development, but there are still problems. For example, one must standardize on a set of browser primitives or require a baseline browser. Furthermore, the client is fairly limited in what it can do computationally. With Jini, the proxy and the UI are actually written by the service provider and dynamically downloaded to the client as needed. There is a base JVM requirement, but in practice, this tends to be easier to manage than the browser problem. Furthermore, the proxy can contain significant sophistication that goes beyond what a web service application can provide.