Please see my comments below.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[EMAIL PROTECTED]>
Sent: Friday, May 16, 2008 1:26 AM
To: <tuscany-dev@ws.apache.org>
Subject: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed
operation and extension implementations - was: Re: Request to propogate the
value of a references target= attribute on its associated bindings model
object
...snip
The two sets of SPIs could co-exist for a while with BindingProviders
working with bindings and ServiceProviders (I just made up that name)
with
service endpoints.
--
Jean-Sebastien
At r656959 I've just enabled some changes to take a step toward using an
Endpoint representation in the model as an alternative to using cloned
bindings as the representation of valid reference targets. It's not
replacing the cloned binding approach just yet, to avoid breaking
anything,
but is the first step on the road. This is what I have done.
Made a new Endpoint model type
+100. The schema kind of mixes the binding/endpoint concept together. I
think it's much cleaner to add the endpoint model to represent the
outbound/inbound addresses.
Created a separate factory for it (separate as I though the model may need
to be pluggable as some point)
Would it be possible to just add the create method the AssemblyFactory?
Created a new EndpointProvider type and associated factory.
I assume the "EndpointProvider" is a system utility that match/resolve the
endpoints based on the reference/service binding configurations. If so, I
suggest that name it differently such as EndpointResolver and we can just
have the interface and default impl (no factory is required). We use the
term Provider for binding/implementation extensions to provide their
specific logic into Tuscany.
Created an Endpoint module to provide a provider implementation.
Created an Endpoint wire to trap attempted calls over unresolved endpoints
Separated off the Endpoint builder code into a new builder class. Same
code
but easier to identify.
Added an endpoint collection to references
Used the Endpoint in the wire builder in place of the old internal target
structure. The logic is weaved in to the existing logic as follows.
For references with no target, put the binding into reference binding as
before
I think it would be better to create an endpoint for the reference without
target. There could be two cases, autowiring and binding with explicit URI
to external services.
A few examples will help, for example:
<reference name="myRef" target="C1/S1">
<binding.x/>
<binding.y/>
</reference>
<reference name="myRef" target="C1/S1 C2/S1">
<binding.x/>
<binding.y/>
</reference>
<reference name="myRef">
<binding.x/>
<binding.y/>
</reference>
<reference name="myRef">
<binding.x uri="http://x"/>
<binding.y uri="http://y"/>
</reference>
Create an Endpoint for all explicit reference targets
For resolved endpoints (Endpoints where the target is resolved) put the
binding into reference bindings, i.e. the same as before
For unresolved endpoints create an endpoint provider and a wire. We don't
have unresolved targets in tuscany (except in the sca binding test) so
should not happen. If you do put a target name in that can't be matched
with
a service you'll get a warning.
If there is no Endpoint module on the classpath it will not create a
provider or a wire hence disabling any Endpoint based processing. The
Endpoint model will still be used though
As part of this change I've updated the logic that looks for target names
in
binding uri. It's now applied to all binding types which I believe is what
the spec says, There is though an issue here. I'll raise a separate
thread.
There are also a couple of thoughts I had.
Can we make the CompositeBuilderImpl have just one constructor?
Should builders be pluggable?
I've used some of the CompoisteActivator functions in the EndpointWire
that
could do with moving into the activator interface.
Simon
