Jean-Sebastian , thanks so much for commenting on this. It's good to know that much of these features are under consideration for Tuscany. I didn't actually have a specific Use Case around the @fedactiv notation, I was just trying to use that as a illustrative purpose. I'll take a look at the jira around security, It looks like your approach to transaction management is a good one, I will take a look at the threads, and see if I can add anything useful to the conversation. <mailto:[EMAIL PROTECTED]> Regards Jeff
________________________________ From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Wed 2007-09-05 17:16 To: tuscany-user@ws.apache.org Subject: Re: Client requested features Was: Policy samples? (showcasing the "killer feature" of separation of concerns) Hi Jeff, Thanks for some very good and useful input! I added some comments inline. [snip] Anderson, Jeff T (CA - Toronto) wrote: > This is great news, that ties into an e-mail that I was just formulating this > morning concerning additional features that have been requested for our client > the list isn't quite complete, by thought I would share it with you as most > of it concerns the policy framework implementation at least in my opinion. > > An FYI to everyone on the list... > I'm currently working with a major Canadian FSI client to develop a SOA > platform based largely on Tuscany 9.1. Services are currently being > developed and tested for the platform, with plans to go into production by > the end of this year. > > Great! It's very encouraging to start seeing projects like yours using Tuscany! > I've just finished holding a architecture workshop where we discussed the > benefits of our platform (largely based on Tuscany) to various technical > stakeholders across the greater organization. Representative stakeholders > were given the chance to prioritize what they consider to be the most > important features that they would want to see in the platform. I have > decided to share this with this list, as I believe that the majority of most > of these requirements could be handled through a future version of Tuscany. > > Currently the biggest feature requested is a service lifecycle mechanism that > is capable of supporting both POJO/local method invocation as well as remote > WSI basic interoperable mechanisms. Key to this feature would be the ability > to transparently switch from a local/POJO to a remote/WSI interoperable model > without impacting business service code. > > Specifically we are looking for Tuscany to allow us to support the following > 1) security-would like to be able to specify participation in existing > security context much like the mechanisms provided by WS security, > WS-secconv, and related specifications. However, current implementations of > Web services stacks makes it difficult to evolve a local component to a true > web service and back again without having to follow a completely different > security model. We believe Tuscany to be a excellent location to access a > policy driven framework that allow us to specify security requirements of the > service either using annotations, SCDL configuration, or some other method. > Soap headers, or local security context could interact with the security > policy dependent on each of the SCA binding used to wire together the various > services. > Some ekids to xamples could be the use of a @Fedactive annotation to declare > that a services capable of issuing messages containing security tokens such > as those described by WS-security and WS-trust. Within a local binding, the > annotation could still declare a need for the service to issue explicit > security tokens, although the token may be passed using a different mechanism. > It would be ideal to have this model follow a more framework approach, with > the explicitly defined plug-in architecture allowing third-party vendors to > integrate Tuscany to their own vendor suite. > We now have an early implementation of the policy model, XML and annotation processors and APIs to populate the model, and ways for the runtime to determine which policies should apply where. So now is a good time to come up with the specific policies you need. I'm happy to see concrete use cases for this area, hoping that they'll help shape our Policy framework... and at the same time will give you what you need :) Could you send an example of what the @Fedactive annotation would look like? what attributes and what they mean, and what you'll expect the particular policy implementation to do? how will it compare or relate to the security policies described in the SCA spec? Speaking of the SCA spec, I have created JIRA http://issues.apache.org/jira/browse/TUSCANY-1651 to track the work on the security policies described in the SCA Policy Framework spec, hoping to get an initial implementation of these policies in our 1.0 release. I'm not sure yet if @Fedactive / a WS-FedActive policy will need its own JIRA or not, but JIRA-1651 could be used to help document and frame that work as well. We can always create new linked JIRAs as this work develops. > > 2) transaction/compensation-I realize that the SCA specification is little > more vague/not finalized concerning this, however this is one of the most > important features requested from our client. Again I envision using the > policy framework to define a transaction setting such as > @NotRequired,@Supported etc. For local bindings this would simply allow the > typical distributed transaction mechanisms to reverse any resources held > within a transaction lock. For a more traditional remote Web services > environment where resource control is the exception rather than the rule, an > additional annotation of @compensator would allow service developer to > declare the compensation transaction required whenever the appropriate > binding container declares that a part of the transaction has failed. Again > I believe the mechanisms of the model would vary depending on the binding > mechanism used. For remote , WSI-Basic interoperable services can use WS -- > atomic. For local, services would have the option of leveraging the the > compensation model or integrate into the existing container distributed > transaction manager. I realize that people In Tuscany are hesitant to start > working on this kind of work until the spec has more details around > transactions. However I believe the majority of this implementation could go > forward without being impacted by the spec. Annotations may change but the > mechanisms for handling transactions are fairly well-known and can be > stabilized early on. > We have started to discuss this on this list in [1] and [2]. Here's where I think we are at the moment: - Until the Transaction policy spec is finalized, we'll come up in Tuscany with something really simple. I'm thinking about an implementation policy intent which will say "transaction / noTransaction" (i.e. my implementation requires a transaction or not) and an interaction policy intent like "suspend / propagate" or something like that. - In a standalone environment we can use an open source TM, I have suggested JOTM. - In a server environment already equipped with a TM, we'll need to use the TM in place, I believe that the Tuscany/Geronimo integration already has code to do that. We've not discussed WS-atomic transaction yet, but it seems like the way to go for WS binding. It will work too with the SCA binding as it leverages the WS binding. [1] http://www.mail-archive.com/tuscany-user@ws.apache.org/msg01655.html [2] http://www.mail-archive.com/tuscany-user@ws.apache.org/msg01692.html > > Some other features not specifically reliant on the policy framework that are > also important to our clients... > 3) advanced orchestration/BPEL-the ability to create composites and > references that can take advantage of the BPEL capability will become a > requirement as our client starts to adopt our platform, which is based on > Tuscany, across the enterprise. I understand that some integration work is > going on with a BPEL container (can't remember the name) but the more that > this work is extended to be a robust solution, and the more likely it is that > our plan will adopt this BPEL container gardening going for another vendor > backed product. > Yes we have started to work with the Apache ODE project to support SCA BPEL components in Tuscany. I'd really like to have this integration working for our 1.0 release... > 4) tighter/more robust Spring integration- the ability to share application > contexts between components, plus others, another resource on my team is > going to comment on this a little bit more as he is a little bit closer to > the issue > Looks like this is now being discussed on our dev list at [3]. [3] http://www.mail-archive.com/[EMAIL PROTECTED]/msg22732.html > ..Much appreciated to any of you out there who's had the chance to take a > look at this list, if anyone out there can provide comments on when/if they > feel that Tuscany will be in a position to start tackling some of these > requirements that would be great. > Regards > Jeff > > > -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ----------------------------------------- ************************************************************************************** Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank you. Information confidentielle: Le présent message, ainsi que tout fichier qui y est joint, est envoyé à l'intention exclusive de son ou de ses destinataires; il est de nature confidentielle et peut constituer une information privilégiée. Nous avertissons toute personne autre que le destinataire prévu que tout examen, réacheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci. ****************************************************************
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
