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

Arkin
 
You said ...
 
>>>I would like the WSA to focus on the generic WS SOA - do one thing and do
it right. That should also include treating the Web as information resource,
and it should also include enabling the use of WS SOA for e-commerce.<<<
Agreed, but unless you have clear statement of the scope of what you are
trying to deliver - in this context treating the Web as both an information
resource and as a technology to support, as Michael put it, "a universal,
low-cost transport mechanism for any sort of information or request" - then
you will not be able to easily assess the quality of the result.
 
>>>But I agree, we also need an architecture for eCommerce. Something that
is more specific to e-commerce with very specific usage guidelines and best
practices. For example, in e-commerce we would probably not look at
component integration, it's not interesting. In BPMI we are thinking about
an architecture for BPMS, and certainly component integration is interesting
in that regard (and also e-commerce). So you end up having architectures for
specific domains that are based on very generic architectures.<<<
Agreed, but let's identify the domains first and define their scope.
 
>>>What about ebXML? If they were interested in adopting the WS SOA, would
it not be a good place to work on an architecture for e-commerce?<<<
This might be hard to do in practice since ebXML is in OASIS and the WS SOA
is in the W3C. Also ebXML already has an "architecture for ecommerce" in the
solution it has developed. Seeking convergence would be a good idea ...
although I have no idea on how to make it happen.
 
David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Monday, February 24, 2003 6:45 PM
To: Burdett, David; Cutler, Roger (RogerCutler); 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: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Monday, February 24, 2003 4:21 PM
To: Assaf Arkin; Burdett, David; Cutler, Roger (RogerCutler); Champion,
Mike; www-ws-arch@w3.org
Subject: RE: A question for our leaders (was RE: AR023.7.1 (was Re: Dead
trou t


Arkin
 
Merriam Webster defines architecture as follows ...
 
1 : the art or science of building; specifically : the art or practice of
designing and building structures and especially habitable ones
2 a : formation or construction as or as if as the result of conscious act
<the architecture of the garden> b : a unifying or coherent form or
structure <the novel lacks architecture>
3 : architectural
<http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=architectural>
product or work
4 : a method or style of building
5 : the manner in which the components of a computer or computer system are
organized and integrated 
 

I think you are assuming definition "1" which is the art/science of how to
do architecture. I don't think we are doing this. I think we are doing
something closer to a "4" or a "5". 
 
I'm assuming art. Not so sure about the science ;-)
 

Actually I like 2 and 5 equally well. If I understand 2 correctly then in
the context of building a computer system it translates to 5.
 
Additionally, if the WSA doesn't do the "architecture for eCommerce" or the
architecture for treating the web as an information resource then who will,
and when do you think it will be complete? 
 
I would like the WSA to focus on the generic WS SOA - do one thing and do it
right. That should also include treating the Web as information resource,
and it should also include enabling the use of WS SOA for e-commerce.
 
But I agree, we also need an architecture for eCommerce. Something that is
more specific to e-commerce with very specific usage guidelines and best
practices. For example, in e-commerce we would probably not look at
component integration, it's not interesting. In BPMI we are thinking about
an architecture for BPMS, and certainly component integration is interesting
in that regard (and also e-commerce). So you end up having architectures for
specific domains that are based on very generic architectures.
 
What about ebXML? If they were interested in adopting the WS SOA, would it
not be a good place to work on an architecture for e-commerce?
 
arkin
 
David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Monday, February 24, 2003 11:09 AM
To: Burdett, David; Cutler, Roger (RogerCutler); 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 actually think there is one 'architecture' for solving all design
problems, and variety of 'architectures' for solving specific design
problems.
 
If you go to architecture school you learn about that one architecture. It
is generic enough to let you build bridges, hospitals and parking lots,
because it is very generic. I think the WSA should devise an architecture
like that.
 
On the other hand, if you build a loft for residence as opposed to a
dual-home dwelling there are different constraints you would use. All lofts
are built based on three common paradigm, and loft architects have specific
experience in that domain and are probably not hte people you would contact
to build a bridge or a hospital.
 
I don't think we need to overload the WSA with 'an architecture for
e-commerce', but we definitely need some place to design such an
architecture that could use those artifacts that are only interesting for
e-commerce (e.g. SOAP, WS-RM, WS-Security) and also expand on those concepts
that are specific to e-commerce but of no interest to WS in general (e.g.
UBL, DBNs, etc).
 
arkin
 

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Monday, February 24, 2003 10:44 AM
To: Cutler, Roger (RogerCutler); 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



Let's think about architectures for creating buildings. Can a reasonable
person actually maintain that there is only *one* architecture that is
correct for solving any design problem. I don't think so. If that was the
case then all buildings would look exactly the same.

I also think it is fairly obvious, that if you have "architectural design
briefs" with different needs and requirements then you need different
architectures. This is why a hospital looks different from a factory and
from a home. They all have different needs.

Now to the WSA. I think that we have two sets of "design briefs" we need to
satsify: 
1. For the web as a huge information resource, and 
2. As a low cost transport of documents for eCommerce 

Now a lot of the stuff can be common between the two. A door or a window in
an hospital, factory or home, can be the same. Similarly there are many
similarities between a message sent to request a representation of a
resource and a message sent to a business partner containing a business
document. But they are not the SAME!

So let's make this separation explicit and move forward. Anyone disagree? 

David 

-----Original Message----- 
From: Cutler, Roger (RogerCutler) [ mailto:RogerCutler@chevrontexaco.com
<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
<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 <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
<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
<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
<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.