- From: Mark Little <mark.little@arjuna.com>
- Date: Sun, 16 Oct 2005 15:53:29 +0100
- To: John Kemp <john.kemp@nokia.com>
- CC: "Conor P. Cahill" <concahill@aol.com>, Mark Nottingham <mark.nottingham@bea.com>, WS-Addressing <public-ws-addressing@w3.org>
Understood. However, you can't profile the usage of just the URI, when the EPR is more than that. Each (set of) ReferenceParameter(s) is typically defined on a per URI basis and in fact provided by the service. So in many cases I think an alternate URI will be useless, because an alternate EPR is what is required. Mark. John Kemp wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >I think the point Conor is trying to make is that without the ability to >put multiple addresses into an EPR (ie. via XML schema >maxOccurs="unbounded") at the WS-Addressing specification/schema layer, >no-one can profile the usage of this functionality. > >And I agree with the requirement BTW. > >- - JohnK > >ext Mark Little wrote: > > >>I agree with the requirement. I just disagree that it's so fundamental >>that it has to be within WS-Addressing. >> >>Mark. >> >> >>Conor P. Cahill wrote: >> >> >> >>>While the particular example that I gave could be considered a >>>profile of how one uses an EPR, the fact is that the basic >>>data structure of the EPR, as it currently stands, does not >>>allow such a profile by only permitting (and requiring) >>>a single URI in a single-occurance element called address. >>> >>>I think that by loosening this requirement to allow >>>multiple address elements, the spec then becomes >>>profilable to support different situations. >>> >>>EPRs are a method of describing how to reach a logical >>>endpoint for the destination of one or more messages, >>>it makes alot of sense (IMHO) to allow such a container >>>to have multiple addresses. >>> >>>Conor >>> >>>Mark Little wrote on 10/16/2005, 3:37 AM: >>> >>> >>> >>>>Hi Conor. Wouldn't that be something to layer on WS-Addressing? WS-QoS >>>>or WS-HighAvailability/WS-Group perhaps? The same requirements have >>>>certainly arisen in other distributed systems/architectures in the past >>>>and been often been tackled as an abstraction on top of baseline >>>>addressing, e.g., by introducing the notion of a logical group address. >>>>For example, in CORBA they introduced the notion of an Interoperable >>>>Logical Group Reference (IOGR) within the Fault Tolerant specification >>>>(http://www.omg.org/cgi-bin/doc?formal/04-03-21) which allowed them to >>>>do pretty much what you describe. >>>> >>>>One of the problems with putting this within the baseline addressing >>>>infrastructure is that it's not as simple as just adding multiple EPRs. >>>>You need to think about what the "fail-over" policy is (essentially why >>>>and when do I use one EPR over another?): what's good for one >>>>client/application may not be good for another, particularly when you >>>>consider things like service consistency and split-brain scenarios. >>>> >>>> >>>So I >>> >>> >>>>think if we went down that route within WS-Addressing we'd either spend >>>>a long time developing the right framework to handle all of this, or >>>>we'd come up with something basic which will eventually be >>>> >>>> >>>superceded by >>> >>> >>>>something like a WS-Group because it doesn't cope with all of the use >>>>cases. >>>> >>>>Mark. >>>> >>>> >>>>Conor P. Cahill wrote: >>>> >>>> >>>> >>>>>Mark Nottingham wrote on 10/15/2005, 4:35 PM: >>>>> >>>>> >>>>> >>>>>>Conor, >>>>>> >>>>>>We discussed this as part of a number of WD issues, including; >>>>>> http://www.w3.org/2002/ws/addr/wd-issues/#i009 >>>>>> http://www.w3.org/2002/ws/addr/wd-issues/#i026 >>>>>> >>>>>> >>>>>While both of these have a somewhat similar feel to them they >>>>>are not the same issue. I'm not talking about different >>>>>protocols/ports, nor about multiple eprs. >>>>> >>>>>I am simply talking about providing alternative physical >>>>>destination URIs that are all intepreted as the same logical >>>>>destination URI so that the client has alternatives should >>>>>there be a problem using one of them. >>>>> >>>>>The intent is that only one logical message is sent to >>>>>one logical entity while giving the sender some level >>>>>of optimization/recovery should one of the physical >>>>>endpoints not be available. >>>>> >>>>>I'm simply asking to allow <Address> to be multi-occurance >>>>>within the EPR whit the definition that all such elements >>>>>in a single EPR equate to the destination URI of the one >>>>>logical entity described by the EPR. >>>>> >>>>>We need this kind of functionality in dealing with the hundreds >>>>>of millions of clients that we have in the real world that >>>>>talk to different instances of the same service, frequenqly >>>>>depending upon their geographic location, network status, etc. >>>>> >>>>>Our work-around is to send multiple EPRs, but I think this >>>>>is a pretty painful workaround (lots of duplication of data >>>>>and the client now has to compare the multiple EPRS that they >>>>>get back to figure out which two are really the same EPR with >>>>>just a different addresss). >>>>> >>>>>Of note: this is *implementation* feedback, not just spec reading >>>>>feedback. In our implementation we find the need for this (and >>>>>feel that others, when the get to the point of supporting real >>>>>world situations will also need this -- not all, but many). >>>>> >>>>>Conor >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.4 (Darwin) >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > >iD8DBQFDUlatmNJiOOM57NMRAlLyAKCjpVZWDq/hdK3OUzC1jKYIRAx5sACeMgIz >vzqAOIp4TUEl3FEYT6hGFrc= >=R4Tj >-----END PGP SIGNATURE----- > >
Received on Sunday, 16 October 2005 14:53:50 UTC