Jeff, Thank you for your valuable feedback. With the work going on for release .99 and release 1.0 this email might not have been noticed.
I have created JIRAs 1666 through 1669 for your requested features. I will also add the JIRAs to release discussion page for 1.0 [1], although some of these seem to be longer term enhancements. Any contribution is welcomed. on BPEL integration with Tuscany: Apache Ode team started BPEL integration with Tuscany and an initial version was checked into svn[2]. More needs to be done though. [1] http://cwiki.apache.org/TUSCANY/java-sca-10-release-contents.html [2] http://www.mail-archive.com/[EMAIL PROTECTED]/msg19404.html Haleh On 8/30/07, Anderson, Jeff T (CA - Toronto) <[EMAIL PROTECTED]> 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. > > 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 examples 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. > > 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. > > 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. > > 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 > > ..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 > > > > > > ________________________________ > > From: Venkata Krishnan [mailto:[EMAIL PROTECTED] > Sent: Thu 2007-08-30 04:40 > To: tuscany-user@ws.apache.org > Subject: Re: Policy samples? (showcasing the "killer feature" of > separation of concerns) > > > > Hi, > > The policy framework implementation is underway. We have some basic > things > in place which allows the inclusion of policy intents and policysets into > an > assembly model. There is simply sample policy that we have put in place > along with the echo-binding-extension sample to test this basic framework. > This is a part of the recent 0.99 release. > > We shall be very soon adding support for some security policies with our > ws > bindings. So you must soon be able to see the basic authentication > support > coming out thro the ws bindings. Other than this, adding audit logging > could be something we can try out for implementation policies support. > > Thanks. > > - Venkat > > On 8/30/07, Skip Schuler <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I'm currently evaluating SCA and Tuscany. I really like much of what > I've > > seen so far, especially when experimenting with the assembly model and > > different bindings. What I'd like to know more about is the policy > > framework. I think the clear separation of concern that SCA promotes is > a > > "killer", however I don't see any good resources or samples. I've > checked > > the documentation link on the Tuscany site, and I've tested with Tuscany > > Java version 0.91.. > > > > So my questions are: > > > > (1) Are there policies available for me and my services (to leverage and > > test)? If so, which and how (guidelines)? > > > > (2) A particular use case I have is to (a) reference a web service > > protected > > by basic authentication, and (b) add audit logging to certain services > > (invocations). I was thinking these were candidates for policies, > however > > I'm not sure how to approach this... Thoughts? > > > > > > Thanks. > > > > > > > > ----------------------------------------- > > ************************************************************************************** > 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] >
