[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Categories of Web Service messages: data-oriented v

• To: "'Mark Baker'" <distobj@a...>
• Subject: RE: Categories of Web Service messages: data-oriented v
• From: Michael Brennan <Michael_Brennan@A...>
• Date: Mon, 4 Feb 2002 15:38:35 -0800
• Cc: xml-dev@l...

> From: Mark Baker [mailto:distobj@a...]

<snip/>

> > Not quite. HTTP will only let you express one action for 
> the entire message.
> > We routinely use rich messages that bundle a number of 
> actions together to
> > minimize network roundtrips. (I believe I've heard SOAP 
> developers refer to
> > this as "box-carrying".)
> 
> Heh, that's "boxcarring", as in trains 8-)

Heh, heh. What's the appropriate emoticon for "foot in my mouth".

Well, now I know where this term comes from. All this time I just thought
SOAP developers were all very bad spellers.  :-)

> The complexity of boxcarring RPC calls is huge because you don't know
> anything about those calls.  HTTP supports a related, but much simpler
> feature called "pipelining".  It's simpler primarily because the HTTP
> methods have known behaviour.  For example, it is known that you can
> pipeline as many GET methods as you like, because they can be 
> assumed to
> be free of side effects.  This is not the case for an arbitrary RPC
> method.

Yes, I'm familiar with pipelining. A client could use that technique with us
rather than doing the boxcarring. We don't mandate the boxcarring. But this
raises the bar a bit for many implementors; most programmers are more
comfortable with an explicit send a request/wait for response model. So we
offer the boxcarring as an option. The issue of side effects is an important
one, of course. Any real world message sent to us is likely to have side
effects (e.g. a request to update data associated with a contact, or another
real world scenario almost all of our customers use -- forward some sales
leads from a CRM system and have our system kick off some workflow to
distribute these leads among partners). This is the key reason we support
hierarchically nested commands -- a nested command has some implicit
dependency on the containing command, so we use the construct to avoid
having any dependency on the ordering of commands within a message. Commands
should not have any dependencies on side effects from a sibling command, but
may have dependencies on side effects from a child command (or vice versa --
the dependency and order of execution of the related commands is specified
on our side, not within the message).

• Prev by Date: Re: Categories of Web Service messages: data-oriented v
• Next by Date: Re: "Smart ASCII" -> XML for authoring?
• Previous by thread: RE: looking for XML vendor in Santa Clara
• Next by thread: RE: Categories of Web Service messages: data-oriented v
• Index(es):
  • Date
  • Thread