[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: Comments inline: David RR Webber wrote: >Farrukh, > >The ebMS support was there for historical reasons. > > This only adds to the argument it should be taken out IMO. The reason we architected it in was a realization that we needed at least one common message protocol for all components in order to facilitate communication (lowest common denominator). This was done before SOAP matured. As someone who has worked on various registry implementations, I have only once come across one set of requirements that concluded eb MS was the right answer. This was before the WS-I's Basic Profile and Basic Security Profile were done. If I were writing the architecture again today, I would favor using those for a variety of reasons. ebXML MS is simply too heavy weight IMO. A lot of people talk about convergence, but I feel that we actually need both eb MS and SOAP. SOAP is ideal and well thought out for use cases like communicating with the registry while the eb MS is better suited for long running collaborations and processes. Right tool for the right job etc.. Anyways - if we don't have it in the specification, it doesn't preclude someone from adding it on themselves. The hooks are there in the FreebXML registry to do this at a later date. Duane >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. > > >> >> > > > > -- *********** 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 ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]