Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: What does SOAP really add?
 > Is the out-of-box interop just for RPC-style SOAP (which is my present > understanding) or for messaging as well? Well, first I want to clarify that I do not see the difference as being RPC vs. Messaging. People do Async RPC *via* messaging all the time. I think it is more about. 1) Synchronous RPC vs. Asynchronous Message-based protocols 2) Opaque Binary Message Formats vs. (more) Easily Accessible XML In the case of Biztalk, messages are enveloped with SOAP, and may or may not map to a procedure call on the receiving server. These messages can be delivered over SMTP, HTTP, MSMQ, IBM MQ-Series -- I have seen examples of all four in production systems. Presumably JMS would work too, as long as there is a bridge. I believe that in most cases, the messages do *not* map to a procedure call in Biztalk -- Biztalk maps the incoming messages through XSLT or through "application integration components". There is a similar idea with BEA Weblogic server. When you create a Weblogic "web service", you basically write Java methods, and then expose those as endpoints. It's very similar to how you can expose any arbitrary C#, VB, etc. method as a "web service" by adding some attributes to the class definition. In BEA, your Java classes can either be exposed as SOAP endpoints, or through a custom XML mapping that you specify. (The same is true of C#, VB, etc. in VS.NET). As far as I know, SOAP is the default XML serialization in both platforms, but someone can use their own XML formats if they want. But anyway, to get to the comparison with Biztalk "message-oriented", BEA allows you to hook up your "web service" methods to listen/send on any infrastructure. Out-of-box I know they support JMS (which could be bridged with MQ-Series and MSMQ I suppose) and SMTP. So these two are independent issues: 1) How often do people expose their procedure calls as SOAP, and 2) How often do people expose non-procedural services through messages transported as SOAP? People deploy systems that do #2 but never do #1, and they deploy web services that do #1 but never #2. And of course, people deploy systems that do both. Considering that SOAP is the default out-of-box way for Biztalk and BEA Weblogic (and a number of other EAI products) to hook up to messaging transports, then you might be surprised how much use is being gotten from SOAP in non-RPC scenarios. > I see zero (even negative) benefit in the SOAP format for messaging. I > see lots of benefits in tools for people who want to stay away from the > markup, but not much more. Yeah, I think the benefit is mostly in tools. > So everybody's doing it? That's really not a sufficient answer to > people who aren't afraid of working with markup. That's Adam's point, though. Even if *you* aren't afraid of working with markup, you often end up working with people who are. I mean, the whole reason we use markup is because we have to work with people who won't use all of our proprietary binary data formats, right? Why does XML forbid the use of certain characters? SGML/ASN.1/MyFormat is much better, and "people are afraid of SGML" is not a good enough reason to justify XML -- or is it? XML strives to be a minimally-scoped, maximally-extensible, broadly-deployable syntax for people to get interop of data. SOAP envelope is an XML format that strives to be a minimally-scoped, maximally-extensible, broadly-deployable syntax for people to get interop of messages. Both are rather low-level pieces of the stack. We still need service description, contracts for conversation orchestration (i.e. "if I get message type a, then the sender will be expecting a message of type b in return, and then he will send back either c or d"), attachments, routing, and so on. All of these layers are going to assume that SOAP is the envelope format, just like SOAP assumes that XML is the message syntax. It's worth noting that BEA and Microsoft both have already shipped systems that use a layer above SOAP to specify orchestration of "conversations", so obviously both companies feel this is important. The two companies have done so using proprietary and incompatible syntaxes (as far as I know), which should give a good sense of why we (and IBM, HP, etc.) think it is important to engage ws-i.org to get some standards in these things. SOAP alone doesn't do much, and unless the layers on *top* of SOAP are standardized, then tools interop will suffer. Tools may not seem like such a big deal, but when you start layering attachments, routing, etc. then you will find very few people who want to write all of that themselves (and rewrite for every trading partner they take on). So I think that the standards and specs related to message-based architectures are *exactly* what the "web services" people are focused on. That is what "web services" is all about -- the loosely-coupled message-passing architectures that Adam talks about. I would also point out that this is very different from (but not necessarily in conflict with) REST. REST says that all data is exposed through a consistent interface, with every distinct information item being globally-addressable through "mediated views". "Web services" on the other hand, says that my data is exposed to you through a single address; the address of my mailbox outside the castle wall. You drop a message in my mailbox, my serf goes and gets it to deliver to me, and then I decide what (if anything) to put in a message back to you. You never know what goes on inside my fiefdom to produce the end message that you see. 
|
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
|
|||||||||
