RE: Spec draft

Jean-Jacques,

I absolutely agree.  I think the MEPBMF is actually architectural rather
than SOAP specific.  In fact, it's actually a really great architectural
basis.  If SOAP hadn't created these things, we would have a great deal of
difficulty in talking about them in WSDL and other specs.  Now there's a
framework for all of this, and it will make ws progress more smoothly.  Of
course, maybe SOAP 1.2 would have shipped earlier, but that's a different
issue :-)

Cheers,
Dave

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Jean-Jacques Moreau
> Sent: Friday, October 04, 2002 8:37 AM
> To: David Orchard
> Cc: 'Newcomer Eric'; [email protected]; Glen Daniels
> Subject: 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]
> >
> >
> >
> >
>
>