Hi Abraham, I beleive Tuscany policies should help your scenario, probably you need to evaluate the same.
Let me give some brief on policies and direct you with some samples available to demostrate the same. Before we jump into policies, we need to understand what are non-functional properties in SOA as shown in the paragraph below: In Service Oriented Architecture, the non-functional properties of services and their connections, such as security and fault tolerance, should be defined separately from their functional properties (i.e., business logic) because different applications use services and connections in different non-functional contexts. For example, an application may unicast messages to a service, and another may manycast messages to multiple replicas of the service to improve fault tolerance. The separation between functional and non-functional properties improves the reusability of services and connections. It also enables the two different properties to evolve independently, and improves the ease of understanding application architectures. This contributes to higher maintainability of applications. Now lets see what are Policies in Tuscany: Policy is mainly used to impose non-functional properties like security, logging, authentication etc., that can be applied to service components or to the interactions between service components represented by services and references. An example of a policy is that messages exchanged between a service client and a service provider be encrypted, so that the exchange is confidential and cannot be read by someone who intercepts the conversation. In SCA, services and references can have policies applied to them that affect the form of the interaction that takes place at runtime. These are called interaction policies. Service components can also have other policies applied to them which affect how the components themselves behave within their runtime container. These are called implementation policies. In SCA, policies are held in policySets, which may contain one or many policies, expressed in some concrete form. Each policySet targets a specific binding type or a specific implementation type. In Tusany, all the policy related definitions can be defined in definitions.xml file. Tuscany follows the SCA policy framework specification [1] and extension specific policy detail contained in the other SCA specifications [2]. SCA separates the process of describing non-functional behaviour into 2 parts. Intents and policy sets. - Intents allow the composite application designer to describe what is required in an abstract way, for example, Authentication, confidentiality etc. without getting into the details of how that might be achieved. - Policy sets allow the deployer desbribe how the intents will actually be achieved. So the policy set that "applies to" the authentication intent may configure our Axis2 based web services binding to use web services security techniques to ensure that incoming messages contain a username token which is then authenticated. Samples to Refer: Please refer to sample helloworld-ws-service-secure[3] and helloworld-ws-reference-secure[4] for the complete implementation of security policy applied over the web services binding. [1] http://www.osoa.org/download/attachments/35/SCA_Policy_Framework_V100.pdf?version=1 [2] http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications [3] http://svn.apache.org/repos/asf/tuscany/java/sca/samples/helloworld-ws-service-secure [4] http://svn.apache.org/repos/asf/tuscany/java/sca/samples/helloworld-ws-reference-secure On Tue, Aug 26, 2008 at 6:14 PM, Abraham Washington <[EMAIL PROTECTED]>wrote: > hi Ramkumar... > > > > 1. The userName/passwords are encrypted and passed to the operation on the > spring bean. so, no, the values are set after the spring application > context is deployed. > > > > 2. I'm not too familar with policies, so i'm not sure how that will work. > if you can point me down the right path, that's beneficial. > > > > it may be a backdoor from sca's perspective. i'll have to think more about > that. but, our company uses spring/hibernate extensively and we can grab > the context as needed. for cases like this, it's helpful. > > > > maybe sca/spring is not a good fit. our company is evaluation soa > technologies and we are committed to spring/hibernate. > > > > thx abe > > > > > ----- Original Message ---- > From: Ramkumar R <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, August 26, 2008 6:24:25 AM > Subject: Re: sca namespace in spring > > Hi Abraham, > Thanks for sharing the same, few question comes to my mind after looking at > your scenario, when i look things from the SCA perspective..... > > 1. Are you looking to update the dataSource values (userName/password), > just before the spring application context is deployed into the SCA domain. > In such cases, would it not be possible to set the dataSource values > (userName/password) > using the component property being set in the composite? > > 2. In case, if you feel that these values are non-functional properties. > how about applying policies for the spring components? > > For me accessing the application context from the runtime (as you have > requested) after its been deployed in the SCA domain looks like a backdoor > entry to the component deployed as services. Not sure if the SCA specs > supports this. Will check on this one and get back to you. > > -- > Thanks & Regards, > Ramkumar Ramalingam > > -- Thanks & Regards, Ramkumar Ramalingam
