RE: Loose coupling is like pornography

Edwin,

Will this answer your concern?

Let's look at each message as a set of blocks, some of which are designated
headers and some of which are designated body parts (see XMLP).

Let's look at SOAP as a uniform way in which these blocks can be
encapsulated into an envelope.

Handlers and intermediaries that work on the headers (also body parts but
without changing them) are not affected by how you decide to structure the
message contents.

If you decide to do RPC-style SOAP with RPC-style encoding (which I consider
a devil in disguise) it would not affect the way in which all the layers
(RM, transactions, security, logging, etc) process the message and these
handlers/intermediaries are reusable across any application and message
schema.

So in my opinion that part of the problem is solved and should be put to
rest.

It still allows bad application design. But that's only because there is no
control over which message structure you can use. And this is also true for
HTML over HTTP. I could create an HTML page that only works with one
particular browser creating artificial dependency.

This is where best practices come in. I would definitely agree with you on
two points. I don't see what RPC-style encoding in SOAP 1.1 buys us, and
just like the WS-I propose, have elected to not use it. And I don't see what
RPC-style documents buy at all and think its redundant and we can leave well
without it in WSDL 1.2.

I know there's a proposal on the table to remove the abstract message
definition from WSDL 1.2 which would make it harder, thus less temption and
less common, to do API->RPC service definitions. Initially I had a few
concerns about it, but after corresponding with Roberto they were all
addressed. I believe that if Roberto's proposal was introduced in WSDL 1.2
it would give us a better specification that would better support these best
practices.

arkin


> Assaf,
>
> Using concrete use cases help! I think that you are making a point: HTTP
> + XML is not enough! Another proof of that is that, although XML and
> HTTP are pevasive technology, there are not a lot of web based
> application to application integration deployed out there.
>
> The question then is: can we extend HTTP + XML in a less intrusive way
> than the RPC-style SOAP allows to? Do we care?
>
> Edwin
>
> >
> > So I have a message with two parts and I want to encrypt one
> > using key A and one using key B, and I want to carry my
> > transaction identifier (like it or not, I need to talk to a
> > system that expects it), and I want to put an expiration time
> > that is calculated from my clock + time-to-live.
> >
> > So I have a bunch of message handlers that do all that for
> > me. And because there's a uniform way to represent where the
> > body goes and where the headers go, they can do that for any
> > SOAP message I sent. And at the other hand I have handlers
> > that can extract that information from the message without
> > having to understand the contents (the consumer does, though).
> >
> > Now I want to do that without SOAP. Plain XML over HTTP. But
> > these handlers don't have a place where to put all the
> > information. HTTP headers work, but they're not XML. So I
> > have to do a lot of binary coding there, just like we do with cookies?
> >
> > That's the value proposition of SOAP. It's a carrier
> > mechanism just like HTTP, but as opposed to HTTP the headers
> > are XML and the parts are XML, and they are all wrapped in an
> > XML envelope. Otherwise, quid pro quo.
> >
> > I just think SOAP is more XML-ized than plain XML over HTTP,
> > that's all. It costs a little, but we were discussing the
> > loosely coupled proposition and I think SOAP makes a better
> > loosely coupled proposition as far as message handlers are
> > concerned. (Plus some other benefits)
> >
>

Received on Friday, 10 January 2003 15:45:28 UTC