Thoughts on Web Services, part 2: It’s not Remoting
When I started using SOAP on Java, I had a simple goal:
I wanted to expose my business interfaces via SOAP. I wanted the WSDLs to be generated automatically, and I wanted the value objects I used as parameters to be converted automatically. Most of all, I didn’t want to change my business interface just to support a remoting protocol. After all, I might want to support another protocol in a year or so, and did not want to change it again then.
Now, almost half a year later, I am starting to realize that it is not so simple. SOAP isn’t just another remoting protocol, such as Java RMI, Caucho’s Hessian Burlap, or .NET remoting. Using such a framework is pretty easy: just implement a specific interface, or extend a subclass, fire up a server process, and you’re done. It is so easy, because these protocols are centered around their respective languages: they support the language natively.
Unfortunately, this goes both ways: remoting frameworks only support the features of their respective frameworks. You can’t do multiple class inheritance in Java RMI, nor create an enumerated type using JDK 1.4, for example.
Web Services, on the other hand, are mostly based on XML. While is is possible to express an XML document in a OO language using something like DOM, there are some differences between XML and OO classes. The article Rethinking the Java SOAP Stack has an excellent summary on the conceptual differences between these two models. I will just mention two of the nine listed there:
- Most importantly, an XML document is a tree structure, while an class structure is a (cyclic) graph. This means that you cannot simply serialize your objects to XML; you have to do some careful translation. In fact, this translation is so complicated that the Alpine folks refer to it as Object/XML mapping, to mare it comparable to the Object/Relational nightmare.
- The language of XML Schema is much richer than the object model of Java. Thus, you simply cannot express all schema constructs within Java. For example, you cannot create restricted types in Java the way you can in a schema.
In summary, I think that we can safely say that a XML Service Architecture is a whole different beast than the good old remoting frameworks that we know and love. The question that remains is if it isn’t remoting, than what is it? We will find out in future posts.