RE: Spec draft

David,
 
To my mind, all very good comments and suggestions.  I'll work on incorporating them.
 
Thanks!
 
Eric

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Thursday, October 03, 2002 3:46 PM
To: Newcomer, Eric; www-ws-arch@w3.org
Subject: RE: Spec draft


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