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

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

Farrukh,

OK - excellent suggest.

Thanks, DW

----- Original Message ----- 
From: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>
To: <regrep@lists.oasis-open.org>
Sent: Monday, December 20, 2004 1:32 PM
Subject: Re: [regrep] Proposed changes to ebMS Binding and HTTP Binding


> David RR Webber wrote:
>
> >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!
> >
> >
> Hi David,
>
> I think your suggestion is better suited for a Technical Note rather
> than a normative spec.
>
> It would be best if we kept our specs as lean as possible with normative
> content and the
> try an dcontain the non-normative content to the Introduction chapter
> for the purpose of
> provding a setting the stage for the reader for the more complex
> normative content.
>
> >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.
> >
> >
> >>
> >>
> >
> >
> >
> >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.
> >
> >
> >
>
>
> -- 
> Regards,
> Farrukh
>
>
> 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.
>
>