For one, there is no SOAP or XSD. Chance of success just went up 10x because of that alone. Second, all the header cruft would not be in the XML document. Developers wouldn't be impaling themselves with generated code, schema problems, parser problems, etc.
Those headers would be *much* easier to parse (one would assume). Much less chance to cut ourselves on interop.
I would assume that some faction of REST/POX will eventually want to do something like this. In a previous post on HTTP, XML, REST, and $100, I mentioned event driven architecture (EDA). I don't see that happening without either this or the equivalent of what the WS-* world has (I saw on Tim Bray's blog EDA is being revisited in WS-* land). Including the headers in the XML document is what makes WS-* awful IMHO. With POX + HTTP Extensions (or something like it), the service developer would have the power of owning the XML contract outright (just has to be a well formed XML doc). You could add complexity as you went (via HTTP extensions), and the XML wouldn't change. Setting/Reading the headers could be set via configuration in relatively simple (compared to WS-*) frameworks. Seems like appropriate separation of concerns to me.
Obviously, web servers would have to evolve (plugins), but this path actually seems plausible - I just don't see WS-* resulting in a workable integration solution.
What's the catch?
2 comments:
As much as I hate the Evil Empire, I think what you've described (POX payload in an envelope of HTTP extensions) is basically the road SOAP went down. Much like J2EE, I think the danger is in gold-plating. Rather than trying to solve a well-scoped problem well, the temptation appears to be to solve every problem.
Obviously the XML payload should only contain the data and all the other stuff should be out-of-band with respect to the data. Ruby on Rails seems to have embraced a trade-off of simplicity for less complexity. While XSD seems like a cool idea (as did ASN.1), I think it adds more complexity than benefit.
One of the big problems with all of these solutions is that they try to specify away the difficulties with interoperability. As we've seen, even agreeing on data types is unworkable. But even if they did get rid of the syntactic differences, the semantic differences would still remain.
For example, two systems may use the exact same representation of mailing addresses, but what if one system stores both billing and shipping address but the other only stores one? No amount of protocol specification will resolve that problem and it can not be solved in the general case. That is a specific problem of the integration between two specific systems.
It's been a while since I've been up-to-date on these things, but from a cursory glance the POX/REST guys have got it right.
I agree that simplicity is the goal. That is why I hate WS-*. It is the most needlessly complex stuff I have ever seen. The sooner it is declared a failure and the industry embraces some flavor of a RESTful approach, the better IMHO.
My day-to-day world is dominated by an event driven system. It uses JMS pub/sub and XML to provide the event driven layer. What I love about this system is it is the first I have worked on that allows the services to just not care who the client is. In short, it is not RPC/P2P based and for the first time I've seen a way out of the n(n-1) services integration problem. Services implement business logic, where the events come from or go is configured.
So I think REST (specifically for me just POX and HTTP) is the way to go, but it is fundamentally P2P/Request-Reply. This results in all sorts of complexity being exported to the clients (e.g., guaranteed delivery).
Since I am such a proponent of event driven architecture I'm interested in expanding its usage outside of JMS. The WS-* folks have a number of specifications in this area. I think that is great except for the fact that I loathe WS-* ;)
So in order to get to an event driven architecture / pub sub style integration with HTTP and POX you are going to need some sort of infrastructure layer contract. The 2 options that I see are either embedding it in the POX like WS-* or sticking it in HTTP Headers. Not yet knowing much about the cons of using HTTP Headers for this, theoretically, I'd much prefer to see this infrastructure layer contract in the HTTP Headers so it isn't mixed in with the XML (which leads to nothing but panic).
Post a Comment