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

How about including a phrasing that allows both in the body of the WSA
document, but specifying how to do it in the appendixes that deal with
different models for implementation (or architecture styles).

In the REST section it should describe one that uses HTTP bindings and the
action is encoded in the URL.

In the 'other' (what do we call it?) it shoudl describe one that uses SOAP
and the action is contained in the message.

I agree that guidelines/criteria would be useful, in fact I would liket to
see both sections including guidelines for when to select which one. But
that may open up a can of worms ;-)

arkin

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Monday, February 24, 2003 8: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 14:25:31 UTC