Summary
Does service oriented architecture mean Web Services? Is Web Services even appropriate as an SOA technology? These and other issues are explored in this post.

---

Advertisement

This post is based on a Birds of a Feather I gave at JavaOne. Thanks to Michael Ogg, CTO of Valaran Corporation, for an earlier presentation that this is based on.

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

There are a lot of 'definitions' for web services ranging from simple to complex. I like to keep things simple and I believe complexity is often introduced to justify the approach being used. About the simplest definition I have seen for Service Oriented Architecture is an architecture based on services, where a service is a distributed resource that is accessed in accordance with its interface. The keys are the distributed nature, the importance of the interface, and the hiddeness of the resource, whether it be data or program, or both.

Review of Services

A service exposes its behavior (resources) via its interface. The service can be accessed via request-reply or asynchronous messaging, it can have autonomous behavior (e.g., events), and it can be a client to other services. A key point is that the interface is a contract for the service's semantics: A service with this interface behaves like this. The implementation is, well, an implementation detail. You don't know how it was implemented or what language was used, as long as it satisfies the service's contract. So, are all services that follow this pattern equal?

Implementation

All the hype about Java Web Services is just that. It's irrelevant whether Java is used in the implementation. The very name, "Java Web Services," is absurd. True, just as with CORBA, using Java makes implementation almost possible. And mostly thanks to Java, some of the tools are possibly quite good. But the point remains: That a service happens to be implemented in Java is merely an implementation detail.

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

Web services defines service interfaces using WSDL, an XML-based language. CORBA uses OMG IDL to define its interfaces. Jini defines interfaces using Java. (Jini can be thought of as the "native" Java SOA.) So all three use some form of IDL. Does that mean they are all the same?

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

A Java interface is part of a type system, so interface foo cannot be confused with interface bar even if all their methods have identical signatures. In web services, there's no guarantee that a lookup will get the right thing back. All you are doing is using names.

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

Both OMG IDL and WSDL use language bindings and naming conventions to simulate strong-typing. Thanks to this, all CORBA services and clients are interoperable. That is, except when using different ORBs, or different IDL compilers. Then all bets are off. Why should Web Services be any different? Meta-language-based middleware cannot, by definition, agree on the language at the end-points, therefore it must agree on the protocol. Protocol-based middleware can not be protocol-independent, so you must ask yourself this fundamental question. Which is better: language-independence or protocol-independence? How you answer will define the nature of the SOA you build.

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

A simple example compares interface languages and their consequences. The Java interface is straightforward:

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

Why do people base their SOA on Web Services? We've heard many stories.

"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

I had to look it up: "pedagogical" means for teaching purposes. This isn't a real world grid solution but it demonstrates some reasons why web services is not an ideal grid computing technology. In fact, Grid computing is a perfect Jini application, but somehow it got hijacked as The Web Services Killer App.

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

If you believe in the power of objects, then you probably realize that although it has "methods," WSDL is more like a data type (in the C struct sense) than an object. Much though I dislike CORBA, Web Services is a step backward. There is no polymorphism or class inheritance. Web Services breaks the Einstein Simplicity Doctrine: "Everything should be made as simple as possible, but not simpler." Web services is less simple than CORBA but weaker in many respects, and we all know CORBA is not simple!

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

I'd venture a guess that web services was the dominant topic at the last two JavaOne conferences. If you measured the number of sessions or the number of attendees, I bet web services would win hands down. Clearly the technology is enjoying widespread interest, but I saw no indication that there was widespread understanding or satisfaction. As developers are getting familiar with web services, they seem to be experiencing a degree of dissatisfaction and even disillusionment. This is a part of the normal emerging technology hype cycle as defined by the Gartner Group. The hype after introduction reaches a crescendo at the Peak of Inflated Expectations and then drops into the Trough of Disillusionment as reality sets in. The early adopters share their painful experiences and drive the interest level back down with their tales of caution. If the technology has merit, it will find its true niches and gain mainstream acceptance on the Slope of Enlightenment. Eventually it will be supplanted with some new and better technology after reaching its Plateau of Productivity.

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.

Web services are not good for complex systems including service ecologies (SOA). For very simple service interactions, web services may be sufficient, but they may not be justified due to the cost of implementation and deployment. The bottom line is that there are too many important characteristics lost due to the design assumptions of hiding remoteness and providing language-independence. If you are considering employing SOA, then consider what's been written here, and consider a pure Java and Jini approach over Web Services for building your Service Oriented Architecture.

Talk Back!

Have an opinion? Readers have already posted 3 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Sean Landis adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Sean Landis is a technologist and programmer interested in, among other things, mobile and distributed sytems, location-based services, and skiing.