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


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

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

Subject: Policy and issues 241, 242, 243, 244

It seems to me that the are two questions that lie underneath these 4 issues, and that rather than try and pick them off one by one, we need to answer these questions. Otherwise we may find we find ourselves revisiting earlier issues as we proceed with later ones.

1. What do event bindings mean?
2. How do we specify policy for events?

In a normal service/reference case, my understanding is that bindings have two main functions
a) To force the use of a particular comms protocol - especially useful when talking to a component that is in some sense "external" to the assembly.
b) As a place where you can attach interaction policySets.

Turning to events, I had originally thought that we would reuse the same approach as with the service/reference case, and have bindings on producers and consumers that behave the same way (though you might have some slightly different policies).

Things are made more complicated by the existence of channels, since we now have the explicit producers and consumers that are wired to the channel, and the implicit producer and consumer that are provided by the channel. So it seems there are two ways to go:

A. Explicitly model the producer and consumer of a channel - and in fact allow a channel to have multiple producers/consumers, and have separate bindings for each producer/consumer. Anything received by any of the consumers of a channel would by default be distributed out through all its producers, though this could be subject to implementation policies on the channel. You could then attach interaction policies to the channels producer/consumer bindings.  This approach has the nice feature that it  matches what happens with services/references.  We would need to work though a set of policy scenarios of the sort that Ashok proposed to see if this would work.  However in raising and immediately resolving  issue 242 it looks as though you rejected this approach.  

That would leave

B. The channel becomes the point of connection external to the assembly, so we don't have bindings on producers and consumers, and we only have a single binding on the channel - this takes care of point a) above. We would then need a way to attach policySets to the producers and consumers  in the absence of them having bindings (I don't know enough about SCA policy to know if this is possible or not). I think we would also want explicitly modelled producers/consumers on channels so we can attach different policySets - but again this is something we need to examine when looking at policy scenarios.

In the light of this I don't understand the requirement for issue 244.  I can see a policy scenario where you might want to create an assembly that has a channel that is wired to two different downstream consumers, and you want to specify different policy interactions on both of those wires (at the channel end).  That would seem to me to be something that should be an architected capability of the assembly model (though one could make implementation of it OPTIONAL) rather than something that would have to be done via extensibility. The way to do it, following option B, would be to have two explicit producers on the channel and to attach policySets directly to the producers (rather than via bindings).

 Is this what is behind the statement that "some implementations may wish to support multiple bindings on a single channel" or is there something else?

Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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