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

[Matthew MacKenzie <mattm@adobe.com>]

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.