Re: Spec draft

A big +1 for incorporating MEPs, Bindings, Modules and Features 
into the architecture. I have come to think that, although they 
have their origins in the XMLP WG, somewhat by accident (hmm... 
hard work?), they are actually more generally applicable than to 
just SOAP. I think other people have come to that conclusion as well.

Jean-Jacques.

David Orchard wrote:
> 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: [email protected] [mailto:[email protected]]On
> Behalf Of Newcomer, Eric
> Sent: Thursday, October 03, 2002 4:28 AM
> To: Newcomer, Eric; [email protected]
> 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: [email protected]
> 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:[email protected]> Newcomer
> CTO 
> 
> 
> END 2 ANYWHERE
> 
> 200 West Street 
> Waltham, MA 02451
> USA
> 
> Tel (781) 902-8366 
> Fax (781) 902-8009 
>  <mailto:[email protected]> [email protected]
> 
>  
> 
>