Unfortunately, there is no such intent in the Policy spec and I am reluctant to reopen
the Policy spec to add this.
Perhaps the functionality could be achieved by using a filter on the channel.
All the best, Ashok
On 1/24/2012 7:30 AM, Mike Edwards wrote:
Folks,
This is in respect of my Action item:
"2011-11-29-1 status=pending Mike to contribute a write up of the IBM position on the current proposals "
The "current proposals" go back to Ashok's contribution contained in
"Which SCA Policy Intents Apply to Eventing.doc" contained in the message
http://lists.oasis-open.org/archives/sca-assembly/201110/msg00014.html
1) What places can Policy apply to in SCA Event Processing?
There are in general 3 places where policy can apply:
- Producers
- Consumers
- Channels
2) What Policies can apply in SCA Event Processing?
a) Authentication
Channels can require Authentication
- authentication would apply to both Producers and Consumers that wish to connect to the Channel
- Producers and Consumers would not in general Authenticate to each other
b) Authorization
There is a potential for use of Authorization in relation to a channel, where a given Producer would
only be authorized to send specific message types and a given Consumer would only be authorised
to receive specific message types.
c) Confidentiality
This could apply to a Producer, Channel and Consumer.
It makes sense for it to apply to all 3 in the sense that it would mark that successful communication is
only going to occur if encryption is enabled on Producer & on Consumer. Meanwhile it providers
guarantees that messages in flight are encrypted.
I have heard expressed the idea that a given Channel might accept both encrypted and unencrypted
messages. This might lead us to invent another version of this intent - a "permissive" one that indicates
that some messages are encrypted and others not.
d) Integrity
Makes sense on Producer, Channel, Consumer.
e) Reliability
I suppose that in principle atLeastOnce, atMostOnce and exactlyOnce make sense, with the difficulty of
defining what this means in an environment where consumers can come and go over time.
Ordered is another separate policy that might apply.
f) Transactions
I think that the sending & the receipt of an event can in principle be transacted - this is done in SCA for
OneWay service/reference invocations already.
So transactedOneWay can apply to Producers and Consumers (only) - no effect on the message flow per se
but with an effect on the way in which the component itself interacts with the event message, exactly as
for OneWay service invocations.
Yours, Mike
Dr Mike Edwards Mail Point 137, Hursley Park STSM Winchester, Hants SO21 2JN SCA, Cloud Computing & Services Standards United Kingdom Co-Chair OASIS SCA Assembly TC
Chair UK ISO SC38 mirror committee (Cloud & SOA)
PEPPOL eProcurement team member
IBM Software Group
Phone: +44-1962 818014
Mobile: +44-7802-467431 (274097)
e-mail: mike_edwards@uk.ibm.com
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
