Cart
[Home] [By Thread] [By Date] [Recent Entries]
> XML-RPC when used in relatively simple and small environments, I have > deep qualms about using RPC in general on any large scale over any long > period of time. RPC is brittle, breakable, etc. - we've been over that > before. > Loose coupling is central to the nature of Web services-based > application integration. That's why it seems to me that the right model > for XML in Web services is a message-oriented, document-based one rather > than one based on remote procedure calls. OK, I hope you are reading this wrong. Bosworth is certainly making a point in *favor* of XML message-passing formats like SOAP vs. things like RMI, but is in no way making a case for REST. The "loosely-coupled" in this comment comes from async and XML-based messages. This is the Biztalk model. I'm not saying that Bosworth isn't a believer in REST; just that the particular scenario described here is not one that REST advocates find terribly comforting. > there's a notion of a framework worth discussion, but to be honest, I > can't see any real benefit. A vocabulary for fault codes? (Okay, a > second wave of hype.) Are you asking what benefit SOAP brings vs. everyone just rolling their own XML serialization/envelope formats? The basic answer is that it allows out-of-box interop (well, usually) so things like VS.NET can work with BEA, and BEA can work with Apache, and so on. This doesn't negate the value of loose-coupling -- it is still beneficial to do loose-coupled async architectures even if the message/document format is not SOAP. But the fact that 90% of clients and servers support automatic SOAP mappings mean that SOAP is a safe bet for an XML novice trying to whip up a loosely coupled architecture in a hurry. Furthermore, messages that use SOAP format will presumably be able to work with future infrastructure that does WS-Routing, DIME, and so on. These other layers of the "protocol stack" have to be able to depend on some consistent features, and will naturally target something like SOAP rather than try to support every naked XML format that anyone cooks up. > the same kinds of questions. Now I wonder if maybe I should just wait > for the Web Services hype to fade, and hope that XML (with REST, or > something similar) gets a second chance afterward. Honestly, I think the best way to grok what all of the fuss is about is to try building some mock systems with imaginary (but realistic) business partners. Pretend that your company has a PeopleSoft on Oracle system you have to talk to, and your boss just bought a BEA Weblogic server for your department, and you have to provide aggregated information from the PeopleSoft HRMS on-demand to anyone who sends you the appropriate JMS message. Your two main customers are departments that use Microsoft SQL Server, so you have to be able to prove interop with them (rather than just declare, "it uses XML so it is interoperable, as long as those other idiots do the right thing.")
|
