Comments inline.
[snip]
Amita Vadhavkar wrote:
I have not worked on the latest DAS-SCA integration so far, and am quite
sure Lucinao
will have good pointers in this area. But looking at the current
tuscany-implementation-das, can see the following possible.
Yes, I guess the idea is to:
- access Data inside an SCA component declared with <implementation-das>
- let the application developer annotate the component implementation
and services with transaction policy intents to indicate what he wants
in terms of transaction
So take this as my attempt to understand
intents/policySets
and DAS-SCA integration :)
DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand
contains org.apache.tuscany.sca.assembly.Service dasService.
Using dasService, requiredIntents on the Service can be found.
There are two categories of policy intents in SCA:
- implementation policy intents - used to indicate requirements of the
component implementation (authorization for example, i.e. you must be
authorized to execute my implementation)
- interaction policy intents - used to configure how a component will
interact with others (confidentiality for example, i.e. messages
exchanged with my component must be encrypted)
I think that the same will have to apply to transactions as well, the
DAS implementation will probably have to deal with intents specified on
both services and the implementation itself.
org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these
intents. DAS
internally can configure DASConfig reflecting the intents specified , so
that DAS instance
construction happens with correct attributes. Based on these attributes DAS
transaction control
will occur (if intent is TransactionControl).
Intent TransactionControl can be qualified as say, 1) Container Transaction
Control,
2) DAS Transaction Control.
Can you describe this a bit more to help me understand what you mean by
Container transaction control vs DAS transaction control?
Advantage of having intent attached to a service will be, using different
intents for different services
of same component.
Yes, different services -> different interaction policies
Questions:
What will be the policySets here?
Say, if policySet/intent "Container Transaction Control" mandates that the
implementation should expose
getConnection() so that container Runtime can use it, how this mandate can
be achieved?
Not sure at all yet. A PolicySet translates an Intent to the
corresponding configuration of the underlying runtime, so it really
depends on what the DAS + SCA runtime will expect.
[snip]
On 8/20/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
Folks,
Sorry to cut across the discussion about Transaction support in DAS, but
are folks aware of the proposal for Transaction support in SCA?
....which leads to the entertaining question of how the DAS transaction
support relates to the SCA transaction support.
The problem at the moment is that the SCA spec group only has an
unpublished draft of the Transaction support spec. The intention is to
publish an updated draft in the near future.
However, I can say that the SCA spec mechanism is based on the use of
Intents to apply transactional characteristics to SCA components.
I've seen several exchanges on the list already from people interested
in some support for transactions... So since the spec is not ready yet,
how about starting now with something really simple like an
implementation policy intent that would just say:
- transaction - i.e. my implementation must run as part of a transaction
- noTransaction - i.e. I don't want to run as part of a transaction
It may look simplistic, but will help us understand the end to end
story, work on the necessary plumbing and integration with a transaction
manager etc. and we can always add more later and adjust the details of
the intents and policySets when the spec is ready.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
