Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Raymond, Comments inline... Raymond Feng wrote: Hi, Let's look at a use case: Assuming we have a deployable composite as follows. should be available over the Web Service binding. Let's assume that the deployed URI is http://localhost:8080/MyComponent/MyService. Now it becomes interesting: Is "MyService" available for SCADomain.getService(MyService.class, "MyComponent/MyService")? If so, which binding should be used? Yes, the intention is that it is available. The binding that should be used is (one of) the bindings expressed by the service - in this case it's the web service binding. The binding should be compatible with the binding on the reference that wants to use it If the answer is yes, I think by the SCA spec, only Web Service binding is available to access MyService. Then the service proxy returned from SCADomain.getService(...) will be a self reference with a Web Service binding and the binding URI should be the SAME as the calculated service binding URI, i.e., http://localhost:8080/MyComponent/MyService. (I think the binding URI for the self reference is not correctly filled today and that's why the $self$ comes into the binding providers' faces). This is correct according to the SCA spec. The other option is that if the service doesn't have a SCA binding, SCADomain.getService(...) will throw ServiceUnavailableException. Nope, this should not happen unless the reference demands some different binding (eg JMS). Even then the exception looks wrong "IncompatibleServiceException" would be nearer the mark. Incompatibility could occur for a variety of reasons, incluing interface mismatch or Intent/Policy incompatibility. Thanks, Raymond - Original Message - From: "Matthew Sykes" <[EMAIL PROTECTED]> To: Sent: Wednesday, June 06, 2007 12:31 PM Subject: Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. Any ideas on how this could be implemented without forcing the bindings to understand $self$ references? Thanks. ant elder wrote: I think its actually a bug in the jsonrpc binding that its using the component self reference, but that aside, this still seems odd to me. Just because a particular binding is on a service how can it be sure that that same binding will work as a reference? Some binding's don't support references, some have different attributes for services or references, on some binding's the URI may include the reference name so this would end up including $self$ in the URI. ...ant On 5/18/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, The self references are created to support the ComponentContext.createSelfReference() in a consistent way as regular references. In your case, if the binding.jsonrpc is declared under the component, then the component can only be assessed over jsonrpc binding (not even SCA binding). And the component will be exposed as a json-rpc service. So invoking the json-rpc reference handler is the correct behavior from the client side. Thanks, Raymond -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Sebastien, I should say that I'm working on a default binding that replaces the Tuscany implementation. The URI isn't changed but new references are created with target URIs that are unknown to the binding implementation on the service side. CompositeBuilderImpl.createSelfReferences creates new references for each service and sets the name to $self$.. Later wireComposite iterates over each of the references and finds the new $self$ references and associates it with the default binding. On paths where SCARuntime.getService is called, createSelfReference eventually follows and the Reference passed back to the caller is one that holds generated uri. As the reference's target URI doesn't point to a service exposed at that URI, invocations through the reference are failing. I can see how I might work around this in the binding but I'm not sure that I should have to. ;) Thanks. Jean-Sebastien Delfino wrote: Matthew Sykes wrote: I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. I'm trying to understand the problem that you're running into, and I'm not sure why the URI would change. A new "self" reference created in CompositeBuilderImpl.createSelfReferences actually points to the original bindings of the service that the reference is created for. So as far as I can tell, the URI used by the reference is the same (meaning exactly the same object) as the URI declared on the service's binding. So if the URI changes there's a bigger problem, as it's probably going to break the service itself... Are you actually seeing the URI change? do you have a test case that I could use to debug that? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Hi, Let's look at a use case: Assuming we have a deployable composite as follows. be available over the Web Service binding. Let's assume that the deployed URI is http://localhost:8080/MyComponent/MyService. Now it becomes interesting: Is "MyService" available for SCADomain.getService(MyService.class, "MyComponent/MyService")? If so, which binding should be used? If the answer is yes, I think by the SCA spec, only Web Service binding is available to access MyService. Then the service proxy returned from SCADomain.getService(...) will be a self reference with a Web Service binding and the binding URI should be the SAME as the calculated service binding URI, i.e., http://localhost:8080/MyComponent/MyService. (I think the binding URI for the self reference is not correctly filled today and that's why the $self$ comes into the binding providers' faces). The other option is that if the service doesn't have a SCA binding, SCADomain.getService(...) will throw ServiceUnavailableException. Thanks, Raymond - Original Message - From: "Matthew Sykes" <[EMAIL PROTECTED]> To: Sent: Wednesday, June 06, 2007 12:31 PM Subject: Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. Any ideas on how this could be implemented without forcing the bindings to understand $self$ references? Thanks. ant elder wrote: I think its actually a bug in the jsonrpc binding that its using the component self reference, but that aside, this still seems odd to me. Just because a particular binding is on a service how can it be sure that that same binding will work as a reference? Some binding's don't support references, some have different attributes for services or references, on some binding's the URI may include the reference name so this would end up including $self$ in the URI. ...ant On 5/18/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, The self references are created to support the ComponentContext.createSelfReference() in a consistent way as regular references. In your case, if the binding.jsonrpc is declared under the component, then the component can only be assessed over jsonrpc binding (not even SCA binding). And the component will be exposed as a json-rpc service. So invoking the json-rpc reference handler is the correct behavior from the client side. Thanks, Raymond -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Matthew Sykes wrote: I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. I'm trying to understand the problem that you're running into, and I'm not sure why the URI would change. A new "self" reference created in CompositeBuilderImpl.createSelfReferences actually points to the original bindings of the service that the reference is created for. So as far as I can tell, the URI used by the reference is the same (meaning exactly the same object) as the URI declared on the service's binding. So if the URI changes there's a bigger problem, as it's probably going to break the service itself... Are you actually seeing the URI change? do you have a test case that I could use to debug that? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. Any ideas on how this could be implemented without forcing the bindings to understand $self$ references? Thanks. ant elder wrote: I think its actually a bug in the jsonrpc binding that its using the component self reference, but that aside, this still seems odd to me. Just because a particular binding is on a service how can it be sure that that same binding will work as a reference? Some binding's don't support references, some have different attributes for services or references, on some binding's the URI may include the reference name so this would end up including $self$ in the URI. ...ant On 5/18/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, The self references are created to support the ComponentContext.createSelfReference() in a consistent way as regular references. In your case, if the binding.jsonrpc is declared under the component, then the component can only be assessed over jsonrpc binding (not even SCA binding). And the component will be exposed as a json-rpc service. So invoking the json-rpc reference handler is the correct behavior from the client side. Thanks, Raymond -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
I think its actually a bug in the jsonrpc binding that its using the component self reference, but that aside, this still seems odd to me. Just because a particular binding is on a service how can it be sure that that same binding will work as a reference? Some binding's don't support references, some have different attributes for services or references, on some binding's the URI may include the reference name so this would end up including $self$ in the URI. ...ant On 5/18/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, The self references are created to support the ComponentContext.createSelfReference() in a consistent way as regular references. In your case, if the binding.jsonrpc is declared under the component, then the component can only be assessed over jsonrpc binding (not even SCA binding). And the component will be exposed as a json-rpc service. So invoking the json-rpc reference handler is the correct behavior from the client side. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Friday, May 18, 2007 9:32 AM Subject: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding > Debugging TUSCANY-1292 it looks like one part of the problem is that > CompositeBuilderImpl.createSelfReferences creates a new self reference for > each service on a component and adds every binding from that service into > the new reference. That results is a JSON-RPC reference provider get used > which seems strange to me but I don't completely understand what the > createSelfReferences is trying to do. Does anyone understand this more and > know if this is the correct behaviour or not? > > ...ant > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Hi, The self references are created to support the ComponentContext.createSelfReference() in a consistent way as regular references. In your case, if the binding.jsonrpc is declared under the component, then the component can only be assessed over jsonrpc binding (not even SCA binding). And the component will be exposed as a json-rpc service. So invoking the json-rpc reference handler is the correct behavior from the client side. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Friday, May 18, 2007 9:32 AM Subject: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding Debugging TUSCANY-1292 it looks like one part of the problem is that CompositeBuilderImpl.createSelfReferences creates a new self reference for each service on a component and adds every binding from that service into the new reference. That results is a JSON-RPC reference provider get used which seems strange to me but I don't completely understand what the createSelfReferences is trying to do. Does anyone understand this more and know if this is the correct behaviour or not? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Debugging TUSCANY-1292 it looks like one part of the problem is that CompositeBuilderImpl.createSelfReferences creates a new self reference for each service on a component and adds every binding from that service into the new reference. That results is a JSON-RPC reference provider get used which seems strange to me but I don't completely understand what the createSelfReferences is trying to do. Does anyone understand this more and know if this is the correct behaviour or not? ...ant
