hi simon...the scenario you presented is correct. as of right now, i'm putting the dataSource on the bean as a property and thus have access to it. but, i was hoping to be able to get the application context, then get the dataSource bean and configure it (no need to have it as a property then). but, when i do that, it hurls. i agree that the missing xsd is a problem. once i put a beanRefFactory in my app, it hurls due to the missing xsd. i understand decisions are made on frameworks and some people will agree, others not on the exposing of the application context. for me, if sca creates the spring context, sca should provide an api to retrieve the context. if i can't do that, i should be able to get the spring context using spring's api. just my 2 cents. with the holiday weekend coming up, i hope to try out policy approach that Ramkumar suggested. thx abe
----- Original Message ---- From: Simon Laws <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, August 28, 2008 5:24:54 AM Subject: Re: sca namespace in spring 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
