[
Lists Home |
Date Index |
Thread Index
]
> 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.
|
