On Wed, Aug 27, 2008 at 3:45 PM, Ramkumar R <[EMAIL PROTECTED]> wrote:
> 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 > Hi Abraham Before we get into the details of policy I'd like to make sure I really understand the scenario here. You have two beans OrganizationServiceBean dataSource You expose the OrganizationServiceBean as an SCA component with a composite file that has a component that looks something like <component name="OrganizationService"> <implementation.spring location="Organization-spring-context.xml"/> </component> You implement OrganizationServiceBean with code that retrieves the dataSource bean from the application context manually in order to configure it. Something like class OrganizationServiceImpl { public void doSomething(){ ApplicationContext applicationContext = (ApplicationContext)ContextSingletomeBeadFactoryLocator.getInstance("beanRefFactory.xml").useBeanFactory("beanRefFactory").getFactory(); dataSource = applicationContext.getBean("dataSource"); dataSource.setUsernamePassword(???); } } Is this anyway near correct. I can't imagine that we restrict a developers access to spring framework APIs on purpose. That would seem like a bad idea. So this should work. The problem comes down to this XSD location which doesn't work for me either b.t.w so we need to understand that. Simon
