OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrm] Message identifiers + multicast issue


Obviously the proposal for several message IDs arose from the lack of a CONVERSATION like notion. If so, it won't be sound to try to provide a workaround using several IDs. The workaround proposed by Paolo seems is already enough. 

As to the need of a CONTEXT for SERIALIZATION, and DUPLICATE ELIMATION, this is already considered by the notion of 'group' of WS-Reliability' (comparable to 'sequence' in 'WS-ReliableMessaging').

Finally, MESSAGE CORRELATION is a different aspect, which I guess is out of scope as well.
To conclude, we have in general to agree upon which of these and other aspects should really be addressed by WSRM TC, and which ones should be out of scope.

Regards, 
Eugene
-----Original Message-----
From: Tom Rutt [mailto:tom@coastin.com]
Sent: Donnerstag, 8. Mai 2003 15:37
To: Paolo Romano
Cc: wsrm
Subject: Re: [wsrm] Message identifiers + multicast issue


Paolo Romano wrote:
> Ok, a scenario where a single RM processor acts on behalf of several end
> users seems to me as well to be very common. Actually, like Dock said in
> his most recent mail, one alternative solution to using three message
> identifiers (i.e. MID+GID/SID) would be to enable the RM processor to
> represent multiple end-points. This is possible by using appropriately the
> FROM field in the Message Header. As an example, user x on sender A could
> fill the FROM field this way:
> <rm:From>userx.senderA@anyuri.com</rm:From>,
> while user y could fill it like :
> <rm:From>usery.senderA@anyuri.com</rm:From>,
> 
> Of course the syntax I chose is just to explain my idea, it could be
> surely different.
> What limits do you think there could be in using this approach?
> 
> One additional issue: One of the features which IMO lacks in the
> WS-Reliabilty spec is the multicast, i.e. the ability for a sender to
> deliver the same message to a set of recipients. This feature is absent
> also in IBM & co. WS-RM, while I believe it could be an interesting one.
> I wanted to have some feedbacks from the other members of the TC.
> 
> Thanks
> 
> Paolo
> 
> PS For Tom and who is taking minutes of teleconferences, my name is not
> Paulo as it is indicated in the minutes, but Paolo. Thank you.
> 
> 
> 
>> I think this is a common use case. Take the case of Sender A processing
>> purchase orders for 2 different customers ('x' & 'y) simultaneously.  It likes to
>> talk to Receiver B (a Warehouse company) in different steps, say, first
>> like do a inventory check, then a credit check, and finally an order. Sender
>> would like to create a group for each customer and hence there could be
>> 2 simultaneous group exchanges between node A and node B.
>>
>> That said, I agree that we should avoid having 2 different primary keys.
>> However, I'm not in favor of Doug's proposal on the call regarding
>> "depends on" concept. The problems I see there are:
>> i)   RM processors will act then as a  mini Workflow processors - we don't
>>       want to get into workflow stuff :)
>> ii) Could potentially have cyclical dependencies if not spec-ed out
>>      properly.
>> iii) Concept of one universal group preempts vendors doing implementation
>>      optimizations such as removing the message content (not the metadata)
>>      from the persistence store once the 'group' is complete.
>>
>> Some random thoughts how to achieve this are:
>> i) Get rid of MId and have GId/Sid set. Gid could be optional & SId
>>    is mandatory. If Gid is present, SId is the unique in that GId. If not,
>>    SId should be globally unique.
>> ii) Or, always mandate GId/SId and have a different semantics for
>>      GId '0'. GId '0' should be considered un-ordered sequences.
>>
>> Thoughts???
>>
>> -Sunil
>>
>>
>>
>>>which have to be ordered independently. This is why I consider redundant
>>>having two different identifiers (Group_id + Sequence_id), and I would
>>>prefer to use only one identifier for both duplicate elimination and
>>
>>
>>
>>>sequence ordering. The advantages of such an approach would be:
>>>implementation simplification and reduced "verbosity" => overhead.
>>>
>>>May be somebody can show us some use cases where the feature of having
>>>multiple groups of messages ordered is worthy the cost of using distinct
>>>identifiers for ordering and filtering out duplicates.
>>>
>>>Paolo
>>
>>
> 
One of the other reasons a simple sequence number is not enough, is that 
managing integers on the internet does not guarantee global uniqueness.

How does the receiver know which "sequence" a given integer is coming 
from.   With a globally unique Group ID providing context for the 
integer sequence numbers, there is not problem of confusing an integer 
from one Sequence with the same integer value from another sequence.

Tom Rutt
Fujitsu

-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]