W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

RE: Spec draft

From: David Orchard <dorchard@bea.com>
Date: Thu, 3 Oct 2002 12:46:08 -0700
To: "'Newcomer, Eric'" <Eric.Newcomer@iona.com>, <www-ws-arch@w3.org>
Message-ID: <015401c26b15$85a3b960$1b0ba8c0@beasys.com>
Eric,
 
First off, thank you very much!  This is great stuff!  My comments are:
 
1. I'd like to have more of the SOAP and WSDL architectural elements, like
MEPs, Bindings, Modules and features.  One approach we could take is to look
at having a section in the extended web services architecture on
MEPs/Bindings/features.  This would duplicate some of the SOAP 1.2 work, the
idea is to get that work into the arch doc.  Then we can talk about how
features map to SOAP and WSDL through MEPs and Bindings.  
 
1a. Another approach is to move the notion of features higher up in the
architecture, say before the extended arch diagram.  We could say something
like "The extended web services architecture provides for concrete use of
features.  Features are .....  They can be realized by MEPs and Bindings,
and described in WSDL.  The following diagram shows an extended architecture
with a variety of places that features can be bound to.
 
2. We could probably use the protocol stack of the 3-stack diagram as a
starting point for an expansion of the wire stack 
 
3. I don't know if we've modelled infrastructure services very well. Take
something like WS-Coordination.  It has defined services exchanged for
startup and takedown of coordination.  And then contexts are transferred
during regular service invocation.   So it defines a few features (startup
and takedown) with their MEPs and it also defines a feature and a particular
binding (soap headers for contexts).  I think we need to have a way of
expressing this notion.
 
4. The "transport" box is probably poorly named.  HTTP is a transfer
protocol, not a transport, and we'd like to have HTTP included.  Perhaps we
could change it from "transport" to "protocol"?  
 
5.  I'd like to start a list of features, as well as sample incarnations.
I'm sure there will be lots, so I'll just start with a smattering of them: 
 
- correleted response - 1 solution is a binding that is HTTP, and another is
an MEP is 2 requests with a correlation ID SOAP Module
- long running transaction - one MEP is a series of reqests between two
nodes with a conversation ID SOAP Module
- reliable message - one MEP is a series of requests between two nodes with
an acknowledgement SOAP Module
- message authentication - one binding is HTTP auth, another is a SOAP
Module with username/password, x.509 etc. (ws-security)
- message confidentiality - one binding is HTTPS, another is a SOAP Module
with encryption.
- message integrity - one solution is a SOAP Module with encryption
 
Cheers,
Dave
 
 -----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Newcomer, Eric
Sent: Thursday, October 03, 2002 4:28 AM
To: Newcomer, Eric; www-ws-arch@w3.org
Subject: RE: Spec draft



Hi,
 
I just want to be clear about what I've just sent...
 
It's not finished by any means, and needs considerable further polishing.
I'm hoping we can discuss the approach during the call later today, which
is:
 
o  Start with the basic triangle diagram and explain it
o  Add some context to the diagram to show the relationship of services and
operations
o  Explain the major artifiacts, roles and operations depicted in the basic
illustration
o  Add an illustration of an "extended" architecture, including the
"orthogonal" aspects of quality of service, management, and transactions
 
If this approach seems ok, or at least basically on track, we can then
proceed to flesh out the extended architecture diagram.  The extended
architecture is, of course, based on technologies that extend the basic
architecture, consistent with the approach taken to date with Web services
specifications.
 
A big question in all of this is the relationship of examples to the
abstract discussion -- should we include more examples of technologies that
are used to implement the architecture early on?  Or address that in
subsequest sections in which we more completely start filling in the
"boxes"?
 
Thanks in advance for your attention and comment.
 
Eric

-----Original Message-----
From: Newcomer, Eric 
Sent: Wednesday, October 02, 2002 11:07 PM
To: www-ws-arch@w3.org
Subject: Spec draft


Hi,
 
Apologies for sending this out a bit late in the week, and for its rough
shape, but I wanted to at least get a draft out before tomorrow's call.
 
Attached for review and comment is a zip file with an html text and three
diagrams.  The draft is focused on trying to capture the consensus on the
triangle diagram as a starting point for a basic Web services architecture,
and the descriptions of that diagram and architecture.  It also includes a
diagram and some text around what I've called the extended Web services
architecture (as a placeholder anyway), which can be fleshed out as we go
along.
 
I also incorporated a large portion of the text Heather sent along with the
diagrams, excluding what seemed to be tutorial or informative text that
would belong in an introductory section.
 
This section would replace the "bottom up architecture" section in the
current editor's draft.  I did not make any other changes to the previous
draft.
 
Talk with you tomorrow.
 
Regards,

Eric 

 



 <http://www.iona.com/> IONA Logo

Eric  <mailto:eric.newcomer@iona.com> Newcomer
CTO 


END 2 ANYWHERE

200 West Street 
Waltham, MA 02451
USA

Tel (781) 902-8366 
Fax (781) 902-8009 
 <mailto:Eric.Newcomer@iona.com> Eric.Newcomer@iona.com

 

 



Received on Thursday, 3 October 2002 15:50:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT