Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What Does SOAP/WS Do that A REST System Can't?
 On Fri, 01 Apr 2005 16:17:56 -0800, Tim Bray <Tim.Bray@s...> wrote: > On Mar 30, 2005, at 12:32 PM, Michael Champion wrote: > > > If on the other hand you are building systems that > > handle confidential information, mission-critical services, and have a > > bunch of legacy systems and protocols to integrate, I'd say the burden > > of proof is on anyone suggesting something other than WS at this > > point. > > When you say "WS" I assume you mean "SOAP+WSDL", given that more or > less everything else in WS-* is either not yet implemented, or not yet > standardized, or exists in multiple competing versions from different > vendor factions. Definitely SOAP, if you are bridging a bunch of legacy systems it's going to be desirable to have its protocol neutral headers to carry around information that you might have gotten with one protocol-specific field and need to get to the destination. WSDL is not anybody's favorite spec, but it's handy for ordinary mortals who just want their tool to generate that XML stuff so they don't to get their hands dirty with it. For better or worse there are a lot of those people lurking around, and the chances are you will have to deal with them at some point in your integration project. So, with some personal reluctance, I'd have to say that WSDL is part of the mix. WS-Security is an OASIS standard, and leverages XML Encryption which is a W3C Recommendation. I don't know for sure how field proven it is, but I'm comfortable saying that it makes sense to leverage all the thought and experience that went into it unless you KNOW that you can roll it yourself better than OASIS did. All those picky little details that it specifies are XML Encryption interop problems waiting to happen if you roll your own, AFAIK. WS-Addressing has been on the fast track at W3C after some pretty heavy-duty discussions and prototyping carried out by the major WS vendors. Again, if you have the pain that it addresses, does it make more sense to roll your own or go with the flow? I'm confortable suggesting that the burden of proof is on someone who thinks they can do it better, and still support the functionality it offers. OK, there's multiple versions of the WS specs for message reliability with different vendor factions on one side or the other. I guess you go with whatever your enterprise vendor supports; if you have to integrate across incompatible vendors, I guess you roll your own solution for this particular bit. ... or consult with an "integration tool integrator", sigh. As for everything else in WS-KitchenSink, I really don't know -- I haven't followed this stuff closely for more than a year. A lot of them may address problems that most people don't have yet, so the chaos there is irrelevant. A few general observations: Sure, they aren't "standardized", but neither are all sorts of specs that the XML world runs on: SAX, RSS, RDDL (increasingly in the MS world), and SOAP/WSDL 1.1 for that matter. The question is whether they have enough real world functionality and interoperability to make it more sensible to leverage them, roll your own, or wait for a Real Standard. That's a decision everyone just has to make for themselves. Also, I guess I really do think that anyone getting into an swamp such as, for example, the one which WS-Coordination / WS-AtomicTransaction / WS-BusinessActivity tries to drain, owes it to themselves to make VERY sure that they understand where the alligators are lurking better than the very smart and experienced people who have been working on the problem for some years now. Maybe your better answer is to build a bridge over the swamp rather than drain it, I wouldn't have any reason to disagree ... but that will offer you a whole new set of bleeding edge problems to answer, and a lot fewer resources to draw on to help you. I have no particular personal or Day Job stake in WS-*, but after this little thought experiment I do still think that anyone using XML and "building systems that handle confidential information, mission-critical services, and have a bunch of legacy systems and protocols to integrate" ought to be taking an extremely close look at that stuff. What's the practical alternative? It's not "rewrite everything with all key components conceived of as abstract resources that exchange XML representations, driven by hypermedia as the engine of application state" or whatever. Lotsa luck getting THAT by the executives :-) There might be some pragmatic way to leverage Plain ol XML and the Web more effectively than most organizations do now, but AFAIK the major success stories for this involve public information, non-mission critical services, and tend to be built from scratch for the Web. As Rich Salz has explained very lucidly earlier in this thread, you do NOT get industrial-strength security, reliability, etc. for free with your HTTP infrastructure. I'm pretty sure that the most currently viable alternative to WS-* is More Of The Same -- MQ/COM /CORBA/J2EE / armies of consultants / barrels of red ink that enterprises are trying to get away from. That provably kindof works, but is provably expensive. I don't know how that balances out vs WS-* on the burden of proof scale. I (personally) suspect that the long term answer to this will draw a lot from both the simpler, more evolutionarily stable ideas that REST tries to pin down and the complicated realities that WS-* attempts to wrap up in somewhat tidier bundle. The ideas that excite me involve (surprise, surprise) XML-capable DBMS to do the heavy lifting for transactions, reliability, authentication/access control, and interfacing to the legacy infrastucture. Patrick Thompson (then of Rogue Wave) and I (then of Software AG) were trying to interest people in a Ruple [XML Tuple Space prototype] / Tamino combination to do this a few years ago. In the very near future, <plug> the SQL Server 2005 Service Broker (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sqlsvcbroker.asp?frame=true) might hit a very similar sweet spot for "messaging in the database" while presenting a somewhat REST-like minimal and uniform interface to the client. </plug> . 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
