[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]