Message identifiers + multicast issue

[Paolo Romano <romanop@dis.uniroma1.it>]

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
>
>