I guess your suggestion for starting simple is fine, and I guess implementation.das could get integrated with SCA Policy and DAS would have the necessary support, unless we find some bugs on the DAS side. I'll see if I can get to this in the coming weeks...
BTW, what transaction manager are we going to use in Tuscany ? Do we have any today ? On 8/27/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > 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] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
