- 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