Re: Protocol independence

Geoff Arnold wrote:

> So exactly how does CapeClear implement this architecture?
> 
> http://www.capeclear.com/images/tempimages/diagram.gif

You' need to ask Jorgen or Annrai that.


> If such configurations become common, no sane programmer or network 
> architect
> will ever rely upon varying message semantics based on protocol or HTTP
> method. Even if the SOAP 1.2 spec does not preclude it, best practice
> will deprecate it......

Shifting semantics is a red-herring, but is interesting to wonder 
about in Heisenberg Uncertainty kind of way.

I've built this type of system (protocol i/o onto messaging 
backbone). Indeed I'm working on one at the moment.

IMO we're asking the wrong questions regarding protocols and 
semantics, plus I'm concerned the ws-arch is over-simplifying 
matters of transportation to a degree.

First off there are at least three sets of semantics involved:

  * PIs in SOAP message headers
  * payload
  * message content

SMOP: depending on where you are in such a system the headers and 
payloads change. These system tend to look like a succession of 
envelopes being added and taken away. In a real system it's a 
fiction to pretend that the envelopes and paylaods are static.

No-one expects the meaning of the core content to change. We've been 
through this with the JAS/FIPA AA Geoff, and we both know it can be 
done. The /real/ issue here is getting WS-arch to adopt a uniform 
content model; I'm sure you and Frank have good ideas in that 
direction :)

IMO, the important distinction between application and transport 
protocols is that application protocols have actors, however dumb. 
Any webservice predicated on SOAP actors using application protocols 
is actually dealing with two pairs of actors - a SOAP actor and a 
protocol actor at either end - the key point being that in these 
circumstances communications between the SOAP actors are always 
intermediated by the protocol actors who will have their own set of 
speech acts which may or may not coincide with the SOAP actors' 
intentions. A WS-arch without a representation of application 
protocol actors has ghosts in the system. Imagine Hamlet without 
Rosencrantz and Guildernstern, or Othello without Iago.

On the other hand, transport protocols are delivery boys, not 
messenger boys. They just grunt and signal to each other and do not 
have the linguistic sophistication of either SOAP headers or 
application protocol action words.

WS-arch needs to factor these application protocol actors in its 
model or I suspect we'll end up with a debacle similar to location 
transparency - ie a handsome architecture, but fully busted from any 
perspective that has to do with building, testing, depoying or 
running a webservice. At the very least WS-arch runs the risk of 
obfuscating things for the people that will build the systems - if 
there's any question that application protocols can't be entirely 
abstracted away, then doing so is impractical. This needs to be 
considered from an engineering perspective and some questions must 
be asked of WS architecture:

  * does eliminating protocol actors make systems easier to build, 
deploy, operate?

  * is it reasonable to ask developers and business people to define 
system spanning protocols on the timescale of a sofware project (and 
with webservices we're often talking about weeks)?

  * is it ever a good idea to ignore protocol actors in the first 
place?

After all, much of what drives people to web services is the proven 
ability to get systems interoprating using current application 
protocols and structured messages.

Personally I like the notion of being able to instrument existing 
protocols with SOAP advice rather than creating a protocol neutral 
layer 8 and risk throwing the baby out with the bathwater, if not 
the bath itself. All we're after on the ground are decent content 
models and a way to get end to end SLAs operating in a manner than 
is visible when things go wrong in the chain (at the moment the key 
areas needing SLAs are security and delivery). Aside from those 
issues, there is another SMOP: having discrete SOAP headers and 
non-embedded content offers the potential for serious performance 
improvements in processing SOAP by inducing a micro-document 
architecture into web services processors. Having everything in a 
single XML document was never a good idea.


Bill de hÓra

-- 
Sorry, I don't know the word "sorry".- SHRDLU

Received on Wednesday, 9 April 2003 14:41:39 UTC