sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [ASSEMBLY-233] Define how Policy works for SCA Eventing
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 24 Jan 2012 15:30:12 +0000
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]