RE: PROPOSAL: Drop interface/operation/(input|output)/@headers

> -----Original Message-----
> From: Jeffrey Schlimmer [mailto:jeffsch@windows.microsoft.com]
> Sent: Friday, October 31, 2003 9:01 AM
> To: David Orchard; Glen Daniels; paul.downey@bt.com; alewis@tibco.com
> Cc: www-ws-desc@w3.org
> Subject: RE: PROPOSAL: Drop 
> interface/operation/(input|output)/@headers
> 
> 
> > From: David Orchard
> > 
> > Indeed.  But how does WSDL express the difference between the
> > "application"
> > components and the "infrastructure" components?  I haven't seen any
> syntax
> > yet that shows this differentiation.  To a certain extent, 
> the problem
> is
> > that the "infrastructure" components are not targetted at the end
> > application, rather something else like the security handler of the
> > application.  
> 
> Is there a compelling need to distinguish message processing roles
> orthogonally to, or more generally than, SOAP actor/role?

I don't really know.  SOAP actor/role might be sufficient, though that
doesn't seem to be the current model.  Currently I don't see much use of
WSDL for expressing that a particular header must be targetted at a role.
Security is a good example where the role typically seems to be undefined or
set to ultimaterecipient.  I could see the role being used to differentiate
beween the application portion vs infrastructure by the endpoint.  I also
don't know whether role is an "abstract" thing like an interface, or a
concrete thing like a endpoint.  I could see an interface expressing that a
security header is required with a given message, and then the endpoint
saying that the security header role must be "securityhandler" as that's
they way it intends to disambiguate.  

I think it gets down to whether the ultimate recipient is the application or
the node.  And I think there are 2 questions be conflated: 1) Which
components must be present for delivery to the ultimate recipient address,
and 2) Which components are consumed by the application within the ultimate
recipient.  I think there are potentially 2 solutions: 1) Use role to
differentiate between roles within the ultimate recipient; 2) Use some new
construct to differentiate between "actors/intermediaries" within the
ultimate recipient.  A trivial #2 would be a sub-role of "application" or
"infrastructure".  These might also apply to intermediary nodes as well.

> 
> > As we (the industry and stds bodies) haven't really talked
> > about intermediaries in this context, there is no guidance on how to
> > structure wsdl nor whether to use soap:role to disambiguate.  
> 
> Agreed. Is @role 1:1 with intermediary? 

Good question.

> 
> > Nor is there
> > any guidance whatsoever on how to use WSDL in the face of
> intermediaries,
> > either in the message path or even within the ultimate receiver.
> 
> Agreed. Would it be sufficient to say transparent 
> intermediaries do not
> need WSDL, that opaque intermediaries would have their own WSDL, and
> that a single WSDL document expressed the aggregate requirements of a
> SOAP node implementing one or more distributed roles?

When you say "intermediaries", do you mean things targeted with Role, as you
asked earlier?  I think I agree with where you are going.  That the WSDL
defines the aggregate interface to a node with potentially multiple roles.
I ask the question earlier about how those roles are "bound" as well.

Cheers,
Dave