W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

RE: Draft Resolution for Issue 41

From: Jacek Kopecky <jacek@systinet.com>
Date: Sun, 10 Mar 2002 23:06:09 +0100 (CET)
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
cc: amr.f.yassin@philips.com, <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.44.0203102303010.25645-100000@mail.idoox.com>
 Stuart,
 I think you should forward your email to the WS-architecture WG 
because IMHO the XMLP WG doesn't need to provide "the one 
standard extension" for this problem (and many other). 8-)
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Fri, 8 Mar 2002, Williams, Stuart wrote:

 > Jacek, Amr,
 > 
 > I think we have to say that SOAP 1.2 does not provide *any* normative means
 > to identify the target "program, service or object". However, SOAP
 > extensibility, specifically the ability to define the syntax and semantics
 > of SOAP extension headers, enables the definition of SOAP extensions that
 > may provide such means.
 > 
 > Personally, in the long run I think we have to give app-designers *one*
 > standardised extension to do this kind of thing. Giving too many to choose
 > from threatens interoperability and giving none threatens interoperability
 > because in the absense of any guidance folks will roll their own.
 > 
 > Regards
 > 
 > Stuart
 > 
 > > -----Original Message-----
 > > From: Jacek Kopecky [mailto:jacek@systinet.com]
 > > Sent: 08 March 2002 16:29
 > > To: amr.f.yassin@philips.com
 > > Cc: xml-dist-app@w3.org
 > > Subject: Re: Draft Resolution for Issue 41
 > > 
 > > 
 > >  Amr,
 > >  I prefer solution 2. In some cases putting the target URI in the
 > > envelope may be undesirable (security considerations, for
 > > example) or even impossible (when the source does not know/care 
 > > where exactly the message goes after reaching some intermediary).
 > >  Even WS-Routing by Microsoft, for example, does not make it 
 > > mandatory for the source to specify the final target, although it 
 > > is possible.
 > >  Best regards,
 > > 
 > >                    Jacek Kopecky
 > > 
 > >                    Senior Architect, Systinet (formerly Idoox)
 > >                    http://www.systinet.com/
 > > 
 > > 
 > > 
 > > On Fri, 8 Mar 2002 amr.f.yassin@philips.com wrote:
 > > 
 > >  > Jacek,
 > >  > 
 > >  > Shall we add it to the core or make it optional?
 > >  > 
 > >  > Solution 1: (Add it to the core)
 > >  > "Modify (Part 1 Section 7: Use of URI in SOAP) to reflect that the 
 > >  > envelope SHOULD include the target URIs especially if the 
 > > application uses 
 > >  > intermediaries and make it part of the XMLP core."
 > >  > 
 > >  > 
 > >  > Solution 2: (Make it application dependent)
 > >  > "It is the responsibility of the application designer to 
 > > provide the 
 > >  > appropriate target URIs at the appropriate points of the 
 > > message path, or 
 > >  > of a routing extension, not of the SOAP core."
 > >  > 
 > >  > What do you think?
 > >  > 
 > >  > Amr Yassin
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > Jacek Kopecky <jacek@systinet.com>
 > >  > 03/07/2002 02:37 PM
 > >  > 
 > >  >  
 > >  >         To:     AMR F Yassin/BRQ/RESEARCH/PHILIPS@AMEC
 > >  >         cc:     xml-dist-app@w3.org
 > >  >         Subject:        Re: Draft Resolution for Issue 41
 > >  >         Classification: 
 > >  > 
 > >  > 
 > >  > 
 > >  >  Amr, 
 > >  >  I'm afraid the text you quote does not address the issue. I 
 > >  > think the proposal should rather be to say: 
 > >  >  "While the target URI is not normatively in the envelope, if an 
 > >  > application uses intermediaries, it must configure somehow 
 > >  > (either statically or using dynamic routing protocol) the message 
 > >  > path. Part of this configuration is the successive target URIs. 
 > >  > Therefore it is the responsibility of the application designer to 
 > >  > provide the appropriate target URIs at the appropriate points of 
 > >  > the message path, or of a routing extension, not of the SOAP 
 > >  > core."
 > >  >  What'dya think? 8-)
 > >  > 
 > >  >                    Jacek Kopecky
 > >  > 
 > >  >                    Senior Architect, Systinet (formerly Idoox)
 > >  >                    http://www.systinet.com/
 > >  > 
 > >  > 
 > >  > 
 > >  > On Thu, 7 Mar 2002 amr.f.yassin@philips.com wrote:
 > >  > 
 > >  >  > Hi,
 > >  >  > 
 > >  >  > I was assigned to write down a proposal to resolve issue 41. 
 > >  >  > 
 > >  >  > <Issue_41>
 > >  >  > The target (program, service or object) URI (TBD) is 
 > > not mentioned in 
 > >  > any 
 > >  >  > normative way in the SOAP envelope. While this does not 
 > > conflict with 
 > >  > the 
 > >  >  > requirements, I believe it's an important (and possibly 
 > > debatable) 
 > >  >  > decision. This decision precludes sending an RPC 
 > > invocation through an 
 > >  >  > intermediary that uses different protocol bindings for 
 > > sending and 
 > >  >  > receiving XP messages. [1]
 > >  >  > </Issue_41>
 > >  >  > 
 > >  >  > Proposal:
 > >  >  > 
 > >  >  > I propose to close this issue since it was addressed in 
 > > Part 1 section 
 > >  > 2.1 
 > >  >  > and 2.2
 > >  >  > 
 > >  >  > <Sec_2.1>
 > >  >  > A SOAP node can be the initial SOAP sender, the 
 > > ultimate SOAP receiver, 
 > >  > or 
 > >  >  > a SOAP intermediary, in which case it is both a SOAP 
 > > sender and a SOAP 
 > >  >  > receiver.
 > >  >  > ...
 > >  >  > A SOAP node MUST be identified by a URI
 > >  >  > </Sec_2.1>
 > >  >  > 
 > >  >  > 
 > >  >  > <Sec_2.2>
 > >  >  > In processing a SOAP message, a SOAP node is said to 
 > > act in one or more 
 > >  > 
 > >  >  > SOAP roles, each of which is identified by a URI known 
 > > as the SOAP role 
 > >  > 
 > >  >  > name. 
 > >  >  > </Sec_2.2>
 > >  >  > 
 > >  >  > 
 > >  >  > ________________________________________
 > >  >  > Amr Yassin      <amr.f.yassin@philips.com>
 > >  >  > Research Member
 > >  >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > > 
 > 
Received on Tuesday, 12 March 2002 00:37:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT