- 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>
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 UTC