RE: [ws-caf] Moving on Addressing

From
Tony Fletcher <>
Date
2004-01-06T10:38:43+00:00
ID
002601c3d441$ae7805d0$
Thread
RE: [ws-caf] Moving on Addressing
Title: Message

Dear 
Greg and others,

 

In 
looking at this topic, it would be good to consider the work done on general 
application 'addressing' and routing in the UN/CEFACT Applied Technologies 
group.  They have produced a specification for a generic header that is 
defined in the abstract then examples given of mapping to non-ebXML, ebXML and 
EDI situations.  The specification is non-proprietary and open for public 
use and comment.  The Generic Header team would certainly appreciate any 
comments, and maybe the WS-CAF group could extend it specifically to the web 
service environment.

 

The 
specification may be downloaded from http://webster.disa.org/cefact-groups/atg/downloads/index.cfm

 

If you 
would like to enter into discussion / seek any clarification the team lead 
is Melanie Kudela from UCC () and the lead 
editor is John Duker of Proctor and Gamble ()

 

Best Regards     
Tony

A M Fletcher

Home: 35, Wimborne 
Avenue, IPSWICH  IP3  8QW

Tel: +44 (0) 1473 
729537   Mobile: +44 (0) 7801 948219

      
(also   &  
)

 

  

  
-----Original Message-----
From: Greg Pavlik 
  [mailto:] 
Sent: 05 January 2004 
  22:40
To: 
Subject: [ws-caf] 
  Moving on Addressing

  
What I would like to propose is that we consider 
  aligning CAF's addressing requirements with WSDL as closely as possible in 
  order to achieve four objectives: eventual migration to standardized 
  addressing, a useful way to talk about web services, addressing information 
  independent from the message bodies, and a static declaration of relationships 
  between port types in WSDL. I think we what we need to define is something 
  simple enough to satisfy the requirements of CAF and nothing more. I don’t 
  believe that we can make use of WS-Addressing in this context as it’s 
  currently a proprietary specification detached from any standards 
  efforts.

  
The formal technical details of whatever we do can 
  be hashed out in a working group. For now, I’d like to put some ideas on the 
  table and make there is a consensus that we need something more than what is 
  in the current submitted specifications. First, I'd like to make it clear why 
  each of these objectives is important.

  
Standards Alignment

  
Obviously, we want broad interoperability with as 
  much infrastructure as possible. This objective is perhaps the most difficult 
  since there currently is no standard mechanism for SOAP message addressing, so 
  I assume that it is a goal rather than a requirement. However, there is 
  movement in this area in the WSDL working group and I propose that we use WSDL 
  as the basis of our addressing solution in so far as possible. If all goes 
  well, we can work to achieve broad interoperability as well as ease of 
  consumption of addressing instructions by endpoint infrastructure and 
  intermediaries. In the worst case, we will have our own addressing solution in 
  the end, but one that makes sense.

  
Referencing Web Services

  
We have to have a way to talk about services, 
  since services consume the messages we are sending around. The current 
  submitted CAF documents use a URL to represent a service (a bit of a 
  simplification, but basically accurate). This is not useable as multiple 
  services may share the same URL. There is also an extensibility element that I 
  presume is meant to act like an Object Key in CORBA, but that is meaningless 
  to web services and should be avoided. It would be better to use something 
  that is based on WSDL. For our purposes, the most important outcome of current 
  WSDL deliberations is this: the wsdl20:ServiceType may be used as the basis 
  for providing service references. A service element provides complete 
  definition of the service itself and is a perfectly useful mechanism for 
  establishing dynamic relationships between services; we could also provide 
  "strongly typed" references in message payloads. This group needs to formally 
  resolve whether it will be dependent on WSDL 2.0 or WSDL 1.1; I believe that 
  we can make this work for referencing with WSDL 1.1 if we require that the 
  service implement only a single PortType.

  
Addressing Information In SOAP 
  Body

  
If you look at the schema for WS-CAF, the 
  addressing information is passed around in the SOAP body. This is bad for a 
  number of reasons. It creates brittle solutions (eg, demarshalling errors in 
  the SOAP body can not be addressed). More importantly, it's simply a bug to 
  include system level instructions in SOAP bodies. We should move the 
  addressing information to SOAP headers. There are no standardized headers, so 
  we will need to invent some in the short run. If standardization occurs, we 
  can move pick up those addressing header definitions. We could make do with 
  the following headers:

    
  MessageOriginator: Originator of the SOAP message. May be a service 
  reference.

    
  MessageDestination: (Final) destination of the SOAP message. Must be a 
  service reference.

    
  ReplyDestination: Destination for asynchronous reply. Must be a service 
  reference.

    FaultDestination: 
  Destination for faults. Must be a service reference. Note that CAF doesn’t 
  respect any fault rules, so we’ll need to mull this over a 
  bit.
    MessageId :A unique 
  identifier for the message of type URI.

  
    MessageReference: 
  A reference to a MessageId. This may be used for 
  correlation.

  
A brief example is included in the end of this 
  email.

  
Establishing Relationships Between 
  Services

  
The consumer of the specifications as they stand 
  is left to interpret the relationship between operations defined in different 
  abstract WSDL definitions. It would be desirable for both human users and for 
  tools to define formal relationships between those operations as a 
  full-fledged message exchange pattern that are machine interpretable, or at 
  the very least communicate what the messages that the operations send 
  asynchronously. Of course the specification text could (and should) spell out 
  the relationships, but this is less useful since the web services runtime 
  platform is barred from automating any of the addressing functions. There is 
  no way to do this at all in WSDL, so I’m going to punt on this one and suggest 
  we wait for a few months to see if there are any developments to help us here 
  since this is nonessential to a functioning runtime.

  
Example SOAP Header (not quite correct for 
  simplicity):

  
 <!--[endif]--><s:header>
       
  <caf:messageOriginator>
               
  <wsdl:service
                
        
  interface=“caf:ActivityService"
                      
  binding=“caf:SOAPActivityService“>
                     
  <wsdl:endpoint>
                            
  <wsoap:address location=http://www.someurl.com/example/>
                    
  </wsdl:endpoint>
              
  </wsdl:service>
       
  </caf:messageOriginator>
      
  …
      
  <wsmd:messageId>http://someguid 
  </wsmd:messageId>
</s:header>

  
Note that this allows us to talk unambiguously 
  about services and messages. Presumably, other headers would include a reply 
  destination and a fault destination, though the two may be redundant. And of 
  course the addressing directives are not a part of the SOAP 
  body.

  
Again, I would like us to have a subgroup that 
  deals with these issues in detail, so please regard this as a launching point 
  for those discussions only.

  
<!--[if 
  !supportEmptyParas]--><!--[endif]-->

  
Greg