Re: Adding support for Security Policies to Tuscany Web 2.0 extensions
On Wed, Sep 17, 2008 at 1:26 AM, Simon Laws [EMAIL PROTECTED] wrote: Hi Luciano Good to hear you thinking along these lines. Taking the scenario motivated approach will help improve policy support generally I think. I've put comments that come immediately to mind in line. Once you think we have a good handle on the initial scenarios we could start making some itests to explore them. Simon On Wed, Sep 17, 2008 at 12:27 AM, Luciano Resende [EMAIL PROTECTED] wrote: I have started some research around using Policy to enable some security capabilities to Tuscany Web 2.0 extensions, and have identified some initial scenarios as listed below: Scenarios: Web 2.0 application requires that a user get authenticated before it can access the application. Intent: authentication This is the reference side right? What sort of technologies are you thinking about here. authentication.message, authentication.transport? We should look at the various strategies we would expect to experience talking to real world services. This may incude things like cookie handling. These Web2.0 applications use a number of different protocols, e.g. Atom, Jsonrpc, RSS, but are mostly based on HTTP so I'd be interested in how we provide some commonality across these bindings. I am, for example, keen to work with you to extend org.apache.tuscany.sca.policy.authentication.basic to these bindings. We can evaluate this once I have it implemented it further. Once difference I noticed is that you were doing a lot of work on the Binding Servlet Listner, and after starting using this approach, I'm investigating the possibility to move the code from the binding servlet to a interceptor and share this with all the web 2.0 bindings. (I guess more generally It would be interesting to see if there is common HTTP binding function across these Web2.0 bindings but that's a different subject) After starting some changes on the Binding Servlet Listener, I realized there are indeed lots of communality between all these, and I'm investigating now using a interceptor to handle this in a common way across all web 2.0 bindings. Web 2.0 application requires that all communication between client/server be done using SSL. Intent: authentication.transport? confidentiality? integrity? Good question, confidentiality sounds good, compared to what I had in my local changes (Intent: ssl) A given service, exposed using a web 2.0 binding requires user authentication. A given operation, exposed using a web 2.0 binding requires user authentication. The other thing that comes to mind is looking at the difference between container based security configuration and the way that this interacts with the binding and policy configuration. So two scenarios A given service, exposed using a web 2.0 binding requires user authentication and is deployed into a container where security is configured A given service, exposed using a web 2.0 binding requires user authentication and is deployed into a container where security is not configured I'm focusing on the second scenario, as this seems to be the way our web 2.0 applications are mostly used. But the design, that is described in more details in [1] should cover both scenarios. [1] http://tuscany.apache.org/sca-java-bindinghttp.html Are there any Web2.0 protocol specific security semantics that we need to be aware of? The different Web 2.0 Protocols rely on HTTP for security, except maybe by the Google GData Binding that would have some specific APIs to handle Google authentication and SSO. Please let me know if you have other scenarios in mind. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
[jira] Updated: (TUSCANY-2600) Provide ITEST for the recent Spring Implementation changes
[ https://issues.apache.org/jira/browse/TUSCANY-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2600: - Patch Info: [Patch Available] Provide ITEST for the recent Spring Implementation changes -- Key: TUSCANY-2600 URL: https://issues.apache.org/jira/browse/TUSCANY-2600 Project: Tuscany Issue Type: Improvement Components: Java SCA Spring Implementation Extension Affects Versions: Java-SCA-Next Environment: Windows XP SP2, IBM JDK 1.5 Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next Attachments: TUSCANY-2600-Part1.patch, TUSCANY-2600-Part2.patch Provide Itest for the recent changes in Spring Implementation module. 1. Support for import/ element. 2. Support for constrctor-arg/ element. 3. Accessing the Application Context from anywhere. 4. Support for ref element. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2644) Remove non UTF-8 Character from SCA-API LICENSE file
Remove non UTF-8 Character from SCA-API LICENSE file Key: TUSCANY-2644 URL: https://issues.apache.org/jira/browse/TUSCANY-2644 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.3.2 Environment: All Reporter: Simon Laws Fix For: Java SCA-1.3.3 A non-UTF8 (r) character has crept into the LICENSE file of the module sca-api. Remove it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2643) composite scope handled incorectly
[ https://issues.apache.org/jira/browse/TUSCANY-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Bigot updated TUSCANY-2643: -- Attachment: second-solution.patch After some discussions with slaws on IRC, I think this solution is better. The behavior implemented is now the following : an implementation instance is linked to a component. i.e. - if more than one component whose scope is composite share the same componentType (even inside an unique composite), each one will have its own implementation instance. - if more than one composite instance (i.e. component whose implementation is implementation.composite) are instances of the same composite (they share the same type) and if this composite contains a component whose scope is composite, these will share the same implementation instance. composite scope handled incorectly -- Key: TUSCANY-2643 URL: https://issues.apache.org/jira/browse/TUSCANY-2643 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-Next Environment: Svn revision 704493 Reporter: Julien Bigot Attachments: first-solution.patch, second-solution.patch Scope composite is not handled correctly. The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for. If the two components have a different ComponentType, this will likely lead to a segfault. I have implemented another behavior. With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created. This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2600) Provide ITEST for the recent Spring Implementation changes
[ https://issues.apache.org/jira/browse/TUSCANY-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2600: - Attachment: TUSCANY-2600-Part2.patch Provide ITEST for the recent Spring Implementation changes -- Key: TUSCANY-2600 URL: https://issues.apache.org/jira/browse/TUSCANY-2600 Project: Tuscany Issue Type: Improvement Components: Java SCA Spring Implementation Extension Affects Versions: Java-SCA-Next Environment: Windows XP SP2, IBM JDK 1.5 Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next Attachments: TUSCANY-2600-Part1.patch, TUSCANY-2600-Part2.patch Provide Itest for the recent changes in Spring Implementation module. 1. Support for import/ element. 2. Support for constrctor-arg/ element. 3. Accessing the Application Context from anywhere. 4. Support for ref element. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2642) Spring SCA Reference does not get resolved in multiple context scenario
Spring SCA Reference does not get resolved in multiple context scenario --- Key: TUSCANY-2642 URL: https://issues.apache.org/jira/browse/TUSCANY-2642 Project: Tuscany Issue Type: Bug Components: Java SCA Spring Implementation Extension Affects Versions: Java-SCA-Next Environment: Windows XP SP2, IBM JDK 1.5 Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next The SCA References in Spring Application Context does not get resolved in case of using a multiple context scenario using bean id=beanRefFactory class=org.springframework.context.support.ClassPathXmlApplicationContext constructor-arg list valueMETA-INF/sca/context-multiple/CalculatorService-context.xml/value /list /constructor-arg /bean the references inside CalculatorService-context.xml does not get resolved here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2641) Enhancements to Tuscany Logging and tracing
[ https://issues.apache.org/jira/browse/TUSCANY-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639575#action_12639575 ] Raymond Feng commented on TUSCANY-2641: --- The patch looks good to me. Please go ahead to commit it. Enhancements to Tuscany Logging and tracing --- Key: TUSCANY-2641 URL: https://issues.apache.org/jira/browse/TUSCANY-2641 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Environment: All Reporter: Dan Becker Attachments: TUSCANY-2641.patch As mentioned on the developer mailing list: Regarding the Tuscany tracing-aspectj module: 1) Break out some of the logging and trace pointcuts into the runtime configuration file (aop.xml). Currently the trace points are compiled into the module. Users must recompile to trace other than * org.apache.tuscany.sca..*.*(..) methods. It would be nice if this were in the config file. Then users interested in just one thing, say Java introspection, could change this to org.apache.tuscany.sca.interfacedef.java.impl.*Introspection*, and this would take effect without recompiling. 2) Add a few pointcuts to look at constructors and static initializers. 3) Make a few explicit timing pointcuts and aspects for those who want to time certain Tuscany transactions, methods, or constructors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2600) Provide ITEST for the recent Spring Implementation changes
[ https://issues.apache.org/jira/browse/TUSCANY-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2600: - Attachment: TUSCANY-2600-Part1.patch Provide ITEST for the recent Spring Implementation changes -- Key: TUSCANY-2600 URL: https://issues.apache.org/jira/browse/TUSCANY-2600 Project: Tuscany Issue Type: Improvement Components: Java SCA Spring Implementation Extension Affects Versions: Java-SCA-Next Environment: Windows XP SP2, IBM JDK 1.5 Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next Attachments: TUSCANY-2600-Part1.patch, TUSCANY-2600-Part2.patch Provide Itest for the recent changes in Spring Implementation module. 1. Support for import/ element. 2. Support for constrctor-arg/ element. 3. Accessing the Application Context from anywhere. 4. Support for ref element. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Should Tuscany support Injection of service references through Constructors
Mike Edwards wrote: Ramkumar R wrote: Hi All, I came across this requirement, while working with Spring, but I believe this topic also holds good for Java implementations. Spring supports Constructor Injection by allowing to inject properties and objects via the constructors. Not sure if Tuscany should support this feature? As SCA+Spring depends on Tuscany runtime for binding and dependency injections. I believe currently Tuscany supports injection of service references through getter setter methods. This question arises because the biggest benefit of setter injection is that it allows for circular dependencies. Circular dependencies are actually pretty common. If you have a UserService that needs to get information about an employer from CompanyService and the CompanyService needs information about employees from UserService, right there you have a circular dependency. In general I find a lot of circular dependencies between service methods, but with complex object models it is possible to have circular dependencies elsewhere. So considering the circular dependency issue, I believe it would be a bad idea to support the same in Tuscany. Like to hear from the community for more insight on this topic and how we should go about it. -- Thanks Regards, Ramkumar Ramalingam Folks, The SCA Java specification explicitly supports constructor based injection of both properties and references, so Tuscany should support this. From the OASIS SCA Java specification - sca-javacaa-1.1-spec-cd01.pdf Lines 94-97: 2.1.4 @Reference Accessing a service using reference injection is done by defining a field, a setter method parameter, or a constructor parameter typed by the service interface and annotated with an @Reference annotation - note the explicit description of constructor parameter This is made clear in the formal definition of the @Reference annotation in section 8.15 (line 1375). The same applies to the @Property annotation (Section 8.14, line 1311). Currently, the SCA Spring specification says nothing about constructor injection, but I have raised a number of issues against that specification to fix this and other problems. Yours, Mike. There are some use cases that need constructor injection. If an implementation requires an injected reference or property to be set once only and never changed, constructor injection is a convenient way to ensure this. I don't think there is any problem with constructor injection and circular dependencies. In the example given, CompanyService instances would be injected with UserService proxies, and UserService instances would be injected with CompanyService proxies. This does not create circularity, because CompanyService and UserService instances don't refer to each other directly. Simon
[jira] Created: (TUSCANY-2643) composite scope handled incorectly
composite scope handled incorectly -- Key: TUSCANY-2643 URL: https://issues.apache.org/jira/browse/TUSCANY-2643 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-Next Environment: Svn revision 704493 Reporter: Julien Bigot Attachments: first-solution.patch Scope composite is not handled correctly. The actual behavior is to return the same implementation instance for all call to a service of a component whose scope is composite. In the case where there is more than one component with composite scope, this means that the first implementation instantiated is returned regardless of the actual component one is looking for. If the two components have a different ComponentType, this will likely lead to a segfault. I have implemented another behavior. With my patch, when using a service of a composite implementation, the name of the component is used as a unique ID, this is still not optimal as two components can have the same name inside two different composite or if more than one instance of a given composite are created. This does not scale well too as a map is used. The straightforward solution would be to have the implementation instance referenced in the Component class. but as this class is defined in the tuscany::sca::model namespace, I'm not sure it is Ok to modify it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2355) CONTINUED Need help again on binding to external web service with login authentication
[ https://issues.apache.org/jira/browse/TUSCANY-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639357#action_12639357 ] Marina Deslaugiers commented on TUSCANY-2355: - Hi again Simon, I am confused for the true long time before answering to you. I was (am still) overloaded at the time you sent me this good news. As you know now I am still looking at SCA but I am working on our prototype. For that matter, as we did not succeded in connecting to the nursery with HTTP basic authentication using Tuscany we have changed our's mind to use - in a first time - web services without authentication. It would be very interesting indeed to try connecting to WS with that kind of authentication and we did not completely give up with that option. Actually, the problem is that I am very late with the prototype whose coding has to be complete before the end of october. Furthermore the prototype uses Tuscany 1.1 incubating and it could be dangerous to change our Tuscany version now (I guess this will be necessary to benefit of the new authentication) ; so, unless you can provide me with very precise guide on how implementing with you new solution and it does require not too much changes, I regret not to be able to do it - at least now - (maybe next year will give me this opportunity). Please, let me know and thanks again. Best regards, Marina. CONTINUED Need help again on binding to external web service with login authentication --- Key: TUSCANY-2355 URL: https://issues.apache.org/jira/browse/TUSCANY-2355 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.1 Environment: Windows XP, Eclipse 3.3.2 , tuscany incubating 1.1 , java 6 Reporter: Marina Deslaugiers Fix For: Java-SCA-Next Attachments: Aspen.tcpdump, MDSP-SMSSenderEnablerSEI-V2_0.wsdl, Support.tcpdump, WSmediawebtranslatorwebsms.composite Hi, As planned this morning, we have made directly test with the person responsible of web service Nursery support to users. We have detected various problems. I attach (I hope joined files will actually be sent otherwise please let me know) two sniff files at the TCP level on communication with the web server Nursery: - The first one (see Aspen.tcpdump) corresponds to TCP frames sent by Tuscany that does not work - The second one (see Support.tcpdump) corresponds to TCP frames sent by the Nursery support -after modification (correction) of the Tuscany frames- that does work Following are the differences and explanations reported by the person responsible for the Nursery WS support: 1) the namespaces used in SOAP BODY are not in conformity with the WSDL. Indeed, one can find the value http://translatewithsms; as the pseudo namespace _ns_. Replacing that value with the one defined in the WSDL say http://com.osa.mdsp.enabler.sei/SMSEnabler/V2_0/SMSSenderSEI;, the SOAP frame works Note that I realized that translatewithsms is the package name of my Eclipse project (containing in particular java client, interfaces etc. files). 2) at HTTP level, the web service in the Nursery is protected by Basic Authentication ; but the Authorization header is not sent by Tuscany (NB: at the current state, we cannot know whether it is actually a problem EXCEPT if Tuscany uses pre-emptive authentication mecanisms 3) Note that Tuscany sends the authentication credentials(user/password) using WS-Security that is not taken into account by the Nursery platform. This is not a problem however, credentials are not operate. NB: tcpdump files can be opened with WireShark http:// www.wireshark.org/download.html I might be responsible for these problems as I have probably made mistakes in coding (at least regarding the policy expression). Please can you help me in correcting. Thanks you very much. Regards, Marina. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Should Tuscany support Injection of service references through Constructors
Ramkumar R wrote: Hi All, I came across this requirement, while working with Spring, but I believe this topic also holds good for Java implementations. Spring supports Constructor Injection by allowing to inject properties and objects via the constructors. Not sure if Tuscany should support this feature? As SCA+Spring depends on Tuscany runtime for binding and dependency injections. I believe currently Tuscany supports injection of service references through getter setter methods. This question arises because the biggest benefit of setter injection is that it allows for circular dependencies. Circular dependencies are actually pretty common. If you have a UserService that needs to get information about an employer from CompanyService and the CompanyService needs information about employees from UserService, right there you have a circular dependency. In general I find a lot of circular dependencies between service methods, but with complex object models it is possible to have circular dependencies elsewhere. So considering the circular dependency issue, I believe it would be a bad idea to support the same in Tuscany. Like to hear from the community for more insight on this topic and how we should go about it. -- Thanks Regards, Ramkumar Ramalingam Folks, The SCA Java specification explicitly supports constructor based injection of both properties and references, so Tuscany should support this. From the OASIS SCA Java specification - sca-javacaa-1.1-spec-cd01.pdf Lines 94-97: 2.1.4 @Reference Accessing a service using reference injection is done by defining a field, a setter method parameter, or a constructor parameter typed by the service interface and annotated with an @Reference annotation - note the explicit description of constructor parameter This is made clear in the formal definition of the @Reference annotation in section 8.15 (line 1375). The same applies to the @Property annotation (Section 8.14, line 1311). Currently, the SCA Spring specification says nothing about constructor injection, but I have raised a number of issues against that specification to fix this and other problems. Yours, Mike.
