Re: Fwd: Dynamic service references (summary)
On Tue, Dec 13, 2011 at 9:31 AM, ant elder antel...@apache.org wrote: I've committed some changes so that you can use some Tuscany versions of the OASIS ComponentContext and ServiceReference interfaces. There's an example of them being used to dynamically alter a Web service reference URL at: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/testing/itest/dynamicRefURI/src/main/java/org/apache/tuscany/sca/itest/HelloworldClient.java I've not yet added this to all the OASIS ComponentContext methods (eg getServiceReferences) and there is now some rationalization of the Tuscany interfaces and classes I think we should do (eg ServiceReferenceExt among others), but this gives an idea of what we could do. I've not done anything with wiredByImpl either as i'm still not sure its terribly useful. I did have a look at changing ComponentContext.getServiceReferences method to support this but it doesn't seem so easy so it continues to return ServiceReference objects and they'd need to be cast to TuscanyServiceReference to get the Tuscany specific function. ...ant
Re: Fwd: Dynamic service references (summary)
On Fri, Dec 9, 2011 at 2:24 PM, Simon Laws simonsl...@googlemail.com wrote: On Fri, Dec 9, 2011 at 2:16 PM, ant elder antel...@apache.org wrote: On Fri, Dec 9, 2011 at 2:04 PM, Simon Laws simonsl...@googlemail.com wrote: On Fri, Dec 9, 2011 at 1:46 PM, ant elder antel...@apache.org wrote: On Thu, Dec 8, 2011 at 5:39 PM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Dec 8, 2011 at 4:22 PM, ant elder ant.el...@gmail.com wrote: On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant Ant I like the idea of being able to prod things into the service reference. I have two immediate thoughts that are not well formed - Could we remove the cast by providing a Tuscany specific ComponentContext for wireByImp impls. We already have the Tuscany RuntimeComponentContext. - Are there binding specific things we will want to do. Nothing comes to mind just yet although policy configuration might be a possibility. The main issue with the current cast is that its casting to an impl class so just using some existing or new interface to have the setBindingURI method and casting to that would be better, and that allows adding whatever else we think of that might be useful to expose to users. I guess an alternative or addition would be to define a Tuscany specific annotation to get hold of the Tuscany specific context instead of using the OASIS annotation. ...ant IIRC the OASIS annotation code is smart enough (or can be made that way) to inject the right thing based on the Type of the field to be injected. We could gate this algorithm based on whether the reference is marked as wire by impl. I.e. are you allowed to affect the wiring from within the implementation. The assembly spec says this about wiredByImpl If set to true it indicates that the target of the 353 reference is set at runtime by the implementation code (e.g. by the code obtaining an endpoint 354 reference by some means and setting this as the target of the reference through the use of 355 programming interfaces defined by the relevant Client and Implementation specification).If 356 @wiredByImpl is set to true, then any reference targets configured for this reference MUST be 357 ignored by the runtime. [ASM40006] I've never been sure whether implementation here refers to the component implementation or the component implementation type (the infrastructure code) or either. I supposed there's nothing stopping us from making the feature available regardless of whether wiredByImpl is set but. if nothing else, we could use it to explain what wiredByImpl is for. The issues I have with having wiredByImpl control whether or not this is possible are that it defaults to false and if its true then you can't have a default for the reference defined in the SCDL (asm40006). Perhaps I don't understand the reasoning behind those but it seems more useable the other way around to me. ...ant That's what I was saying at the end (I think) that we make the facility available regardless but turning wiredByImpl on means that you have to use it. It you don't turn wiredByImpl on you can either set the reference through the new API or rely on the target in the SCDL. I've committed some changes so that you can use some Tuscany versions of the OASIS ComponentContext and ServiceReference interfaces. There's an example of them being used to dynamically alter a Web service reference URL at:
Re: Fwd: Dynamic service references (summary)
On Thu, Dec 8, 2011 at 5:39 PM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Dec 8, 2011 at 4:22 PM, ant elder ant.el...@gmail.com wrote: On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant Ant I like the idea of being able to prod things into the service reference. I have two immediate thoughts that are not well formed - Could we remove the cast by providing a Tuscany specific ComponentContext for wireByImp impls. We already have the Tuscany RuntimeComponentContext. - Are there binding specific things we will want to do. Nothing comes to mind just yet although policy configuration might be a possibility. The main issue with the current cast is that its casting to an impl class so just using some existing or new interface to have the setBindingURI method and casting to that would be better, and that allows adding whatever else we think of that might be useful to expose to users. I guess an alternative or addition would be to define a Tuscany specific annotation to get hold of the Tuscany specific context instead of using the OASIS annotation. ...ant
Re: Fwd: Dynamic service references (summary)
On Fri, Dec 9, 2011 at 1:46 PM, ant elder antel...@apache.org wrote: On Thu, Dec 8, 2011 at 5:39 PM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Dec 8, 2011 at 4:22 PM, ant elder ant.el...@gmail.com wrote: On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant Ant I like the idea of being able to prod things into the service reference. I have two immediate thoughts that are not well formed - Could we remove the cast by providing a Tuscany specific ComponentContext for wireByImp impls. We already have the Tuscany RuntimeComponentContext. - Are there binding specific things we will want to do. Nothing comes to mind just yet although policy configuration might be a possibility. The main issue with the current cast is that its casting to an impl class so just using some existing or new interface to have the setBindingURI method and casting to that would be better, and that allows adding whatever else we think of that might be useful to expose to users. I guess an alternative or addition would be to define a Tuscany specific annotation to get hold of the Tuscany specific context instead of using the OASIS annotation. ...ant IIRC the OASIS annotation code is smart enough (or can be made that way) to inject the right thing based on the Type of the field to be injected. We could gate this algorithm based on whether the reference is marked as wire by impl. I.e. are you allowed to affect the wiring from within the implementation. The assembly spec says this about wiredByImpl If set to true it indicates that the target of the 353 reference is set at runtime by the implementation code (e.g. by the code obtaining an endpoint 354 reference by some means and setting this as the target of the reference through the use of 355 programming interfaces defined by the relevant Client and Implementation specification).If 356 @wiredByImpl is set to true, then any reference targets configured for this reference MUST be 357 ignored by the runtime. [ASM40006] I've never been sure whether implementation here refers to the component implementation or the component implementation type (the infrastructure code) or either. I supposed there's nothing stopping us from making the feature available regardless of whether wiredByImpl is set but. if nothing else, we could use it to explain what wiredByImpl is for. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Fwd: Dynamic service references (summary)
On Fri, Dec 9, 2011 at 2:04 PM, Simon Laws simonsl...@googlemail.com wrote: On Fri, Dec 9, 2011 at 1:46 PM, ant elder antel...@apache.org wrote: On Thu, Dec 8, 2011 at 5:39 PM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Dec 8, 2011 at 4:22 PM, ant elder ant.el...@gmail.com wrote: On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant Ant I like the idea of being able to prod things into the service reference. I have two immediate thoughts that are not well formed - Could we remove the cast by providing a Tuscany specific ComponentContext for wireByImp impls. We already have the Tuscany RuntimeComponentContext. - Are there binding specific things we will want to do. Nothing comes to mind just yet although policy configuration might be a possibility. The main issue with the current cast is that its casting to an impl class so just using some existing or new interface to have the setBindingURI method and casting to that would be better, and that allows adding whatever else we think of that might be useful to expose to users. I guess an alternative or addition would be to define a Tuscany specific annotation to get hold of the Tuscany specific context instead of using the OASIS annotation. ...ant IIRC the OASIS annotation code is smart enough (or can be made that way) to inject the right thing based on the Type of the field to be injected. We could gate this algorithm based on whether the reference is marked as wire by impl. I.e. are you allowed to affect the wiring from within the implementation. The assembly spec says this about wiredByImpl If set to true it indicates that the target of the 353 reference is set at runtime by the implementation code (e.g. by the code obtaining an endpoint 354 reference by some means and setting this as the target of the reference through the use of 355 programming interfaces defined by the relevant Client and Implementation specification).If 356 @wiredByImpl is set to true, then any reference targets configured for this reference MUST be 357 ignored by the runtime. [ASM40006] I've never been sure whether implementation here refers to the component implementation or the component implementation type (the infrastructure code) or either. I supposed there's nothing stopping us from making the feature available regardless of whether wiredByImpl is set but. if nothing else, we could use it to explain what wiredByImpl is for. The issues I have with having wiredByImpl control whether or not this is possible are that it defaults to false and if its true then you can't have a default for the reference defined in the SCDL (asm40006). Perhaps I don't understand the reasoning behind those but it seems more useable the other way around to me. ...ant
Re: Fwd: Dynamic service references (summary)
On Fri, Dec 9, 2011 at 2:16 PM, ant elder antel...@apache.org wrote: On Fri, Dec 9, 2011 at 2:04 PM, Simon Laws simonsl...@googlemail.com wrote: On Fri, Dec 9, 2011 at 1:46 PM, ant elder antel...@apache.org wrote: On Thu, Dec 8, 2011 at 5:39 PM, Simon Laws simonsl...@googlemail.com wrote: On Thu, Dec 8, 2011 at 4:22 PM, ant elder ant.el...@gmail.com wrote: On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant Ant I like the idea of being able to prod things into the service reference. I have two immediate thoughts that are not well formed - Could we remove the cast by providing a Tuscany specific ComponentContext for wireByImp impls. We already have the Tuscany RuntimeComponentContext. - Are there binding specific things we will want to do. Nothing comes to mind just yet although policy configuration might be a possibility. The main issue with the current cast is that its casting to an impl class so just using some existing or new interface to have the setBindingURI method and casting to that would be better, and that allows adding whatever else we think of that might be useful to expose to users. I guess an alternative or addition would be to define a Tuscany specific annotation to get hold of the Tuscany specific context instead of using the OASIS annotation. ...ant IIRC the OASIS annotation code is smart enough (or can be made that way) to inject the right thing based on the Type of the field to be injected. We could gate this algorithm based on whether the reference is marked as wire by impl. I.e. are you allowed to affect the wiring from within the implementation. The assembly spec says this about wiredByImpl If set to true it indicates that the target of the 353 reference is set at runtime by the implementation code (e.g. by the code obtaining an endpoint 354 reference by some means and setting this as the target of the reference through the use of 355 programming interfaces defined by the relevant Client and Implementation specification).If 356 @wiredByImpl is set to true, then any reference targets configured for this reference MUST be 357 ignored by the runtime. [ASM40006] I've never been sure whether implementation here refers to the component implementation or the component implementation type (the infrastructure code) or either. I supposed there's nothing stopping us from making the feature available regardless of whether wiredByImpl is set but. if nothing else, we could use it to explain what wiredByImpl is for. The issues I have with having wiredByImpl control whether or not this is possible are that it defaults to false and if its true then you can't have a default for the reference defined in the SCDL (asm40006). Perhaps I don't understand the reasoning behind those but it seems more useable the other way around to me. ...ant That's what I was saying at the end (I think) that we make the facility available regardless but turning wiredByImpl on means that you have to use it. It you don't turn wiredByImpl on you can either set the reference through the new API or rely on the target in the SCDL. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Fwd: Dynamic service references (summary)
On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant
Re: Fwd: Dynamic service references (summary)
On Thu, Dec 8, 2011 at 4:22 PM, ant elder ant.el...@gmail.com wrote: On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash n...@apache.org wrote: ant elder wrote: This is good and i will have a go in 2.x to see if a similar approach works there. But i can't help thinking its a slightly convoluted approach and as we have more flexibility in 2.x to add more APIs I wonder if we should just add a more direct API method to set the URIs with extra methods on Node, or also perhaps something like being able to do: ((TuscanyServiceReference)serviceReference).setURI(uri)? +1 for providing a more convenient solution in 2.x. A setURI() method would only work for certain binding types. Perhaps this could be generalized to use some kind of notion of endpoint. There's also the mysterious wiredByImpl notion from the SCA spec. It might be good to use that as the base concept for this capability. Ok i had a quick stab at this in r1211944 and 1211945 which enables setting the binding URI of a ServiceReference by casting it to org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and calling setBindingURI. Eg ServiceReferenceHelloworld sr = componentContext.getServiceReference(Helloworld.class, helloworldService); ((ServiceReferenceImpl)sr).setBindingURI(http://localhost:8080/HelloworldService/Helloworld;); return client: + sr.getService().sayHello(name); Obviously its not ideal to be casting to a that impl class and it should rather have an API/SPI interface to cast to. I haven't done a whole lot of testing but that that seems to work ok, can anyone see any obvious issues? ...ant Ant I like the idea of being able to prod things into the service reference. I have two immediate thoughts that are not well formed - Could we remove the cast by providing a Tuscany specific ComponentContext for wireByImp impls. We already have the Tuscany RuntimeComponentContext. - Are there binding specific things we will want to do. Nothing comes to mind just yet although policy configuration might be a possibility. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Fwd: Dynamic service references (summary)
This is good and i will have a go in 2.x to see if a similar approach
works there. But i can't help thinking its a slightly convoluted
approach and as we have more flexibility in 2.x to add more APIs I
wonder if we should just add a more direct API method to set the URIs
with extra methods on Node, or also perhaps something like being able
to do: ((TuscanyServiceReference)serviceReference).setURI(uri)?
...ant
-- Forwarded message --
From: Simon Nash n...@apache.org
Date: Wed, Dec 7, 2011 at 1:04 PM
Subject: Re: Dynamic service references (summary)
To: u...@tuscany.apache.org
Millies, Sebastian wrote:
Thank you very much for all your help, Simon.
You're very welcome. I'm glad this is working for you now.
I summarize here the result of this discussion for everyone's benefit:
For dynamic web service endpoints, get a wsdl for the web service and define
a service reference with interface.wsdl using wsdl.binding and a dummy
URI in the binding.ws element.
One small point--it doesn't need to be interface.wsdl. It should also work
if you use interface.java.
Simon
sca:reference name=bapiCostcenterGetList requires=sca:authentication
sca:interface.wsdl
interface=urn:functions#wsdl.interface(ZWS_BAPI_COSTCENTER_GETLIST) /
sca:binding.ws
wsdlElement=urn:functions#wsdl.binding(ZWS_BAPI_COSTCENTER_GETLISTBinding)
uri=dynamicURI /
/sca:reference
At run time get the service reference, serialize it to XML, replace the
dummy URI with the real endpoint URI, deserialize the reference and call the
service method. The serialization coding goes like this:
public String serializeServiceReferenceXML( ServiceReferenceT sr )
throws IOException
{
ServiceReferenceImplT sri = (ServiceReferenceImplT) sr;
return sri.toXMLString();
}
public ServiceReferenceT deserializeServiceReferenceXML( String
serializedSR )
throws Exception
{
StringReader reader = new StringReader( serializedSR );
XMLStreamReader xmlReader =
XMLInputFactory.newInstance().createXMLStreamReader( reader );
ServiceReferenceImplT sri = new ServiceReferenceImplT( xmlReader );
return sri;
}
The deserialized reference will work also when using policy sets (I have
tested
that with basic authentication).
For background on the changes that have been made to the 1.x trunk to make
this possible, refer to TUSCANY-3984.
-- Sebastian
IDS Scheer Consulting GmbH
Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev
Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany -
Registergericht/Commercial register: Saarbrücken HRB 19681
http://www.softwareag.com
