Raymond,
Comments inline...
Raymond Feng wrote:
Hi,
Let's look at a use case:
Assuming we have a deployable composite as follows.
<composite ...>
<component name="MyComponent">
<service name="MyService>
<binding.ws .../>
</service>
</component>
</composite>
When this composite is deployed to the SCA domain, then "MyService"
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: <tuscany-dev@ws.apache.org>
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]
