RE: A question for our leaders (was RE: AR023.7.1 (was Re: Dead trou t

Let's assume the concensus is that the action should be included in the SOAP
header when SOAP messages are communicated and possibly also encrypted (and
I buy into all the arguments made by David in favor of this approach).

The WSA does not mandate using only SOAP, it is intentionally defined to
allow other technologies to exist. So this is clearly a recommendation when
using SOAP. Perhaps SOAP would not allow any other usage, but that's a
matter for the SOAP working group to decide.

I would think the best way to attack this is for the WSA should define an
architecture that makes no such restriction and allow both use cases. For
example, when describing a Web service that has HTML as the front-end and
uses HTTP GET. Let's say that tommorrow we decide to use WSDL to define Web
service portals - we would want to have the capability to use HTTP GET and
let HTTPS deal with the encryption.

On the other hand, within a B2B interaction we would benefit if everybody
does it the exact same way. Maybe the service provider doesn't think putting
the action name in the SOAP header is important, but the service requester
does. So for interoperability reasons it would be best if we define the
proper way of doing it for a given application. I believe this falls in the
jurisdiction of WS-I and similar organizations.

It is then a matter of how many use cases SOAP allows. Even if SOAP adopts
variant 6, it is still possible to encode the action in the URI and have a
meaningless action header. So it's not a usage SOAP or the WSA can enforce
in anyway, but a recommended best practice could well deal with that
(including proper explanations and examples).

I just don't think this particular constraint falls in the jurisdiction of
the WSA.

arkin


> -----Original Message-----
> From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@chevrontexaco.com]
> Sent: Monday, February 24, 2003 9:38 AM
> To: Burdett, David; Assaf Arkin; Champion, Mike; www-ws-arch@w3.org
> Subject: RE: A question for our leaders (was RE: AR023.7.1 (was Re: Dead
> trou t
>
>
> I agree.
>
> However, as illustrated by the "visibility" permathread, I think that we
> are going to have a heck of a time reaching consensus on the guidelines
> -- unless we are willing to accept a "consensus" that includes a
> strongly dissenting opinion.  Personally I would like to work toward
> this objective and stop running over the same material that has no
> resolution over and over and over and ...
>
> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Monday, February 24, 2003 10:58 AM
> To: Assaf Arkin; Burdett, David; Champion, Mike; www-ws-arch@w3.org
> Subject: RE: A question for our leaders (was RE: AR023.7.1 (was Re: Dead
> trou t
>
>
>
> Assaf
>
> I agree, but can we, as a group, also agree that there are two different
> use cases that have different requirements and therefore require
> differing solutions. Really, the analysis we need to do, is identify
> what is common and what is different and explicitly propose an
> "architecture" for solving both. Would that make sense.
>
> I agree that we should have phrasing that allows both, but "leaving it
> to the implementation to decide which works best" is two weak.
> Alternatively, I suggest that: 1. We define two architectural
> approaches: one which follows the REST style for encoding the operation;
> and the other where the operation information is stored in the body 2.
> Provide guidelines/criteria which helps an implementation decide which
> to use
>
> David
>
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Sunday, February 23, 2003 4:21 PM
> To: Burdett, David; Champion, Mike; www-ws-arch@w3.org
> Subject: RE: A question for our leaders (was RE: AR023.7.1 (was Re: Dead
> trou t
>
>
>
>
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> > Behalf Of Burdett, David
> > Sent: Sunday, February 23, 2003 3:56 PM
> > To: Champion, Mike; www-ws-arch@w3.org
> > Subject: RE: A question for our leaders (was RE: AR023.7.1 (was Re:
> > Dead trou t
> >
> >
> >
> > Mike
> >
> > Thanks for the feedback. I suppose that the motivation for my asking
> > this question, is that there are various requirements for using web
> > services for business that, although they may seem minor, have some
> > major architectural implications. Here are three examples:
> >
> > 1. Semantic free URIs
> > In an earlier email, I suggested that if you want to keep the content
> > of a message sent to a web service confidential, then you should not
> > put ANY sensitive information such as the operation to be carried out
> > on the message in the URI
>
> I think there are valid use cases where it is easier to include that
> information in the URI, e.g. a catalog service. If there's no
> requirement for security, auditing, etc then why complicate it. An HTTP
> GET would be simpler to implement/use in this case.
>
> However, enforcing that model goes against business requirements, and
> the points you make are very valid. I would suggest a phrasing that
> allows both uses but leaves it to the implementation to decide which
> works best, and ideally making that decision in the protocol bindings.
>
> Maybe something like:
>
> There is no requirement that all information pretaining to the operation
> be captured in the URL, for example, to allow such information to be
> contained in the message body and encrypted.
>
> arkin
>
> >
> > 2. Use of non-HTTP Protocols
> > I really think that SMEs (Small to Medium Enterprises) will want to
> > provide a Web Service capability using email protocols rather than
> > HTTP. The EDI use
> > case at in the WSA Usage Scenarios document is a good example of this.
> > Also, within an enterprise, other non-HTTP protocols could be used
> such as
> > MQ Series. This is suggested in the Transport section of the Web
> Services
> > Architecture Document.
> >
> > 3. Preservation of Message Integrity
> > Many messages sent to web services providing a business function will
> > be digitally signed, probably with XML Dsig, as they provide a
> > *persistent* record of the origin and authenticity of the message that
>
> > lasts after the transport of the message is complete. For example, you
>
> > could store the message in a database or file system without losing
> > any integrity information.
> >
> > The conclusion I draw from these example requirements is that you have
>
> > to put all the semantic information required to process a message
> > actually
> > *inside* the message. If information is contained at the
> > transport level as
> > Mark and others have suggested, then it MUST be a copy.
> >
> > Thoughts?
> >
> > David
> >
> >
> >
> > -----Original Message-----
> > From: Champion, Mike [mailto:Mike.Champion@softwareag-usa.com]
> > Sent: Thursday, February 20, 2003 5:56 PM
> > To: www-ws-arch@w3.org
> > Subject: RE: A question for our leaders (was RE: AR023.7.1 (was Re:
> > Dead trou t
> >
> >
> >
> > >
> > >
> > > -----Original Message-----
> > > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > > Sent: Thursday, February 20, 2003 2:02 PM
> > > To: Dave Hollander (E-mail); Mike Champion (E-mail)
> > > Cc: www-ws-arch@w3.org; 'Cutler, Roger (RogerCutler)'; Mark Baker
> > >
> > > A question for our leaders ...
> > >
> > > To what extent is the requirement to develop a Web Services
> > > Architecture that supports the needs of business/ecommerce a formal
> > > objective of this activity?
> >
> > The answer is "yes, of course."  Oddly enough, the Requirements don't
> > say this as explicitly as I remembered, maybe because we "just knew"
> > that the objective is to support the needs of business.
> >
> > What the Requirements doc does say is: "Of course, it is also
> > important to recognize that an important motivation for the product of
>
> > this Working Group is to support the needs of enterprises that use Web
>
> > services for the purpose
> > of engaging in e-business."
> >
> > This is clearly not just an academic exercise; an intellectually pure
> > architecture that doesn't actually have real-world implementations or
> > reflect practical business knowledge would not meet the requirements
> > of this activity.
> >
> > Of course, one would be forgiven for not getting that impression from
> > this mailing list :-)  But that's the price we pay (and benefit we
> > get) from doing the technical work in public.
>
>

Received on Monday, 24 February 2003 13:32:00 UTC