You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by "Anderson, Jeff T (CA - Toronto)" <je...@deloitte.ca> on 2007/08/30 16:07:38 UTC
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 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:for.svkrish@gmail.com]
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 <sk...@gmail.com> 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.
****************************************************************
RE: Client requested features Was: Policy samples? (showcasing the "killer feature" of separation of concerns)
Posted by "Anderson, Jeff T (CA - Toronto)" <je...@deloitte.ca>.
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.
<ma...@fedactiv> Regards
Jeff
________________________________
From: Jean-Sebastien Delfino [mailto:jsdelfino@apache.org]
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/tuscany-dev@ws.apache.org/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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
-----------------------------------------
**************************************************************************************
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.
****************************************************************
Re: Client requested features Was: Policy samples? (showcasing the
"killer feature" of separation of concerns)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 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/tuscany-dev@ws.apache.org/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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: Client requested features Was: Policy samples? (showcasing the "killer feature" of separation of concerns)
Posted by haleh mahbod <hm...@gmail.com>.
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/tuscany-dev@ws.apache.org/msg19404.html
Haleh
On 8/30/07, Anderson, Jeff T (CA - Toronto) <je...@deloitte.ca>
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:for.svkrish@gmail.com]
> 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 <sk...@gmail.com> 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: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
Re: How is Tuscany currently being used?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Thanks a lot for sharing this. It helps us and everybody on the list to
understand how Tuscany is used out there!
What do people think about creating a page on the Tuscany Wiki where
Tuscany users could document their usage scenarios?
Anderson, Jeff T (CA - Toronto) wrote:
> Just wondering if anybody out there on the list could provide some comments on how they are using Tuscany with in their organization or are planning to within the foreseeable future?
> It would be great to get an understanding of whether anybody plans to use Tuscany in production within the foreseeable timeframe, are merely evaluating it for various prototypes, are currently looking at it for high-level research. Getting a high-level understanding of what kinds and solutions are trying to be solved with Tuscany would be great also. Providing this kind of information IMHO would really help to give a sense of how people are envisioning the use of Tuscany and how/when people are considering Tuscany to be used as a product that is ready for "prime time use", like spring, and other ubiquitous open-source products.
>
> As an example of the kind of information that I think would be beneficial to many on the list I will go first.
>
>
> Currently working for a consulting firm with a major financial services Institute in Canada to implement a mix of retail and commercial banking services. We plan to go into production by the end of this quarter, we have finished the majority of implementation, conducted functional and performance testing (with very good results) and plan to do a limited deployment with a small subset of users within a couple of months. We are currently deploying Tuscany on websphere 6.1, Solaris 10, and taking advantage of a combination of Web services bindings/SDO as well as local/spring bindings. An interesting wrinkle is that we are also basing all of our service interfaces on the IFX banking standard, which breaks SDO in a couple of places.
>
> Thanks in advance for sharing
>
> regards
>
> Jeff
>
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
How is Tuscany currently being used?
Posted by "Anderson, Jeff T (CA - Toronto)" <je...@deloitte.ca>.
Just wondering if anybody out there on the list could provide some comments on how they are using Tuscany with in their organization or are planning to within the foreseeable future?
It would be great to get an understanding of whether anybody plans to use Tuscany in production within the foreseeable timeframe, are merely evaluating it for various prototypes, are currently looking at it for high-level research. Getting a high-level understanding of what kinds and solutions are trying to be solved with Tuscany would be great also. Providing this kind of information IMHO would really help to give a sense of how people are envisioning the use of Tuscany and how/when people are considering Tuscany to be used as a product that is ready for "prime time use", like spring, and other ubiquitous open-source products.
As an example of the kind of information that I think would be beneficial to many on the list I will go first.
Currently working for a consulting firm with a major financial services Institute in Canada to implement a mix of retail and commercial banking services. We plan to go into production by the end of this quarter, we have finished the majority of implementation, conducted functional and performance testing (with very good results) and plan to do a limited deployment with a small subset of users within a couple of months. We are currently deploying Tuscany on websphere 6.1, Solaris 10, and taking advantage of a combination of Web services bindings/SDO as well as local/spring bindings. An interesting wrinkle is that we are also basing all of our service interfaces on the IFX banking standard, which breaks SDO in a couple of places.
Thanks in advance for sharing
regards
Jeff
-----------------------------------------
**************************************************************************************
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.
****************************************************************