OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


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
> >
> > -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 -
> ***********
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]