Re: Client requested features Was: Policy samples? (showcasing the killer feature of separation of concerns)
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
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 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. 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
RE: Client requested features Was: Policy samples? (showcasing the killer feature of separation of concerns)
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