[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
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:email@example.com] Sent: Monday, December 20, 2004 12:10 PM To: Duane Nickull; Farrukh Najmi Cc: firstname.lastname@example.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" <email@example.com> To: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM> Cc: <firstname.lastname@example.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.