Re: Policy samples? (showcasing the killer feature of separation of concerns)
Two comments inline. Venkata Krishnan wrote: 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. I have created the following JIRA for this work: http://issues.apache.org/jira/browse/TUSCANY-1651 It should help people interested in the security policy track progress, add comments, or if people are interested in helping out with this work, attach tests or implementation code :) I have targeted the JIRA for the Tuscany SCA-1.0 release, which I'd like to get out in a few weeks. 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. An initial implementation of the Policy framework is available now, so you should be able to develop your own logging/auditing policy extension and plug it in the framework. The APIs to do that are still a little rough I think but trying them will help everybody get what they want in terms of policy, if you're interested. To see how a policy is implemented see the Encryption sample policy classes in java/sca/samples/binding-echo. IMO a logging policy would make another good sample for an implementation policy (i.e. a policy that you attach to a component implementation). -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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.
Client requested features Was: Policy samples? (showcasing the killer feature of separation of concerns)
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
Policy samples? (showcasing the killer feature of separation of concerns)
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.
