Re: [regrep] Proposed changes to ebMS Binding and HTTP Binding

["David RR Webber" <david@drrw.info>]

Matt,

All good.

I was just pointing out that when you pull a chunk of pages out of the
spec',
replacing them with a couple of diagrams that show how this can be
attained instead - makes a lot of sense - and is non-disruptive to
the overall picture that people need to take away from the spec' -
which is 'how do I use registry effectively?'.

So I'd suggest the Interop style use case as one diagram, and then
the other diagram is the SOAP based exchanges you detail here
below - one is B2B integration, the other is information grid
integration.

That should IMHO make a better story with less - than we had
before - with the ebMS hardwired as part of registry  - that people
always struggled to understand why!

Thanks, DW

----- Original Message ----- 
From: "Matthew MacKenzie" <mattm@adobe.com>
To: "'David RR Webber'" <david@drrw.info>; "'Duane Nickull'"
<dnickull@adobe.com>; "'Farrukh Najmi'" <Farrukh.Najmi@Sun.COM>
Cc: <regrep@lists.oasis-open.org>
Sent: Monday, December 20, 2004 1:18 PM
Subject: RE: [regrep] Proposed changes to ebMS Binding and HTTP Binding


> Your interop may have shown that X & Y work, but what it did not show was
> why and who would actually do that.
>
> As Farrukh says, we can do all this with SOAP.  Why bother complicating it
> with extra bindings and extra requirements for us to maintain said
binding?
>
> My suggestion to Farrukh when we chatted about removing the ebMS binding
was
> to at some point provide the option of plugging in WS-Reliability to the
> SOAP binding.  In reality, this brings ebRR pretty darn close to ebMS3 in
a
> much more elegant fashion than requiring a full MSH. That is all a
registry
> client would really need. Customer demand for asynchronous searching has
> always been a bit soft :-)  It only makes sense if you were implementing
> your own distributed search over non-federated registries.
>
> -Matt
>
> -----Original Message-----
> From: David RR Webber [mailto:david@drrw.info]
> Sent: Monday, December 20, 2004 12:10 PM
> To: Duane Nickull; Farrukh Najmi
> Cc: regrep@lists.oasis-open.org
> Subject: Re: [regrep] Proposed changes to ebMS Binding and HTTP Binding
>
> Farrukh,
>
> The ebMS support was there for historical reasons.
>
> As we have shown in the XML2004 Interop - using
> ebMS and Registry together with the http-binding works
> beautifully to provide integration with ebMS and Registry
> services and enterprise level messaging delivery controlled
> by CPA.
>
> Perhaps we can add a diagram showing this use case
> as a way to illustrate using ebMS with Registry in future
> and explain why a direct interface to registry is therefore
> redundant.  There's some sample diagrams in the
> Interop PPT that could be adapted for this.
>
> Persons wanting to route registry content thru ebMS
> can obviously place content directly onto an ebMS
> server outbound queue for delivery that way - such
> as output from registry an event handler(s).
>
> One question though - what about large federated
> queries that are possibly asynchronous?  Is there still
> a case for sending these via the more formal mechanisms
> that ebMS provides?    The use case above though I think
> could be extended through a query handler to provide
> support for this too...
>
> Thanks, DW
>
> ----- Original Message ----- 
> From: "Duane Nickull" <dnickull@adobe.com>
> To: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>
> Cc: <regrep@lists.oasis-open.org>
> Sent: Monday, December 20, 2004 12:00 PM
> Subject: Re: [regrep] Proposed changes to ebMS Binding and HTTP Binding
>
>
> > I fully support it.  It makes sense.
> >
> > Duane
> >
> > Farrukh Najmi wrote:
> >
> > >
> > > Here is a breath of fresh air. I am for once proposing reducing scope
> > > instead of increasing it for 3.0 specs :-)
> > >
> > > 1. Based on implementation experience I think we should drop the ebMS
> > > binding from the RS spec for the following reasons:
> > >
> > > -It is out of date and underspecified. In its current form of
> > > specificity and accuracy it is unimplementable.
> > >
> > > -It would take major work to align it with ebMS 3.0 and define
> > > template CPAs for registry and client
> > >
> > > 2. Based on implementation experience I think we should drop bindings
> > > for all registry protocol methods that require HTTP POST from ebRS for
> > > the following reasons:
> > >
> > > -Sending protocol messages over HTTP POST without SOAP is pointless
> > > since we need to duplicate functionality of the SOAP Header. This is
> > > very non-standard in other similar specifications.
> > >
> > > -SOAP Binding is already supporting any such protocol messages over
> > > HTTP POST
> > >
> > > -It is not good to have two similar but different ways of implementing
> > > the same protocol
> > >
> > > Note that one side effect of (2) is that we can now remove the
> > > SignatureList element from RegistryRequestType and
> > > RegistryResponseType since they were there to carry signatures when
> > > there was no SOAP envelope (totally non-standard practice).
> > >
> > > I have discussed this with Matt who is an expert on both issues and he
> > > supported my proposal.
> > >
> > > Does any one have any objections to above proposals (1) and (2)?
> > >
> >
> > -- 
> > ***********
> > Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
> > Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
> > Chair - OASIS eb SOA TC -
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa
> > ***********
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.
> php.
> >
> >
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the
> OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.
> php.
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>