Policy and issues 241, 242, 243, 244

[Peter Niblett <peter_niblett@uk.ibm.com>]

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