Re: 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 bin
On Sun, Jun 8, 2008 at 8:45 AM, ant elder [EMAIL PROTECTED] wrote: On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I've created an itest (late-reference-resolution) to show how late resolution could be done using endpoint resolvers. In the itest BindingScaEndpointResolverImpl it says I can cheat here because... could you say a little about how a real use of this could work? And what do you think about having some code somewhere - in an itest or module somwhere - which demonstrates that? I'd be happy to help write that, I'm asking as in runtime-tomcat i need to do the same thing but haven't been able to figure out how its intended to be done for real. ...ant The real use of this involves writing more code. The late binding feature is one way of catering for scenarios where, for example, the domain is not completely configured when the first composite is run. To make this work a registry needs to provide the information required for references to locate services at runtime, i.e. service name, contract, intents/policies and target URL. The EnpointResolver provides a plug point where runtime or binding specific code can be put to do this reference resolution. I haven't done any work on the service side. I think the domain or the runtime can collate service information generically without it being done at a service or binding level. Time will tell. Runtime-tomcat is an example of where this kind of approach can be useful. Here the driving requirement is to support a contribution deployment step where a war is simply dropped into tomcat/webapps. The normal semantics of this are that the webapp is immediately available. It could be argued that this is a specious scenario because even if a web app is available from the Tomcat point of view SCA components in the war won't operate correctly until all references are satisfied. However I think this is a common enough deployment scenario that we should investigate it. Regards Simon
Re: 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 bin
On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I've created an itest (late-reference-resolution) to show how late resolution could be done using endpoint resolvers. In the itest BindingScaEndpointResolverImpl it says I can cheat here because... could you say a little about how a real use of this could work? And what do you think about having some code somewhere - in an itest or module somwhere - which demonstrates that? I'd be happy to help write that, I'm asking as in runtime-tomcat i need to do the same thing but haven't been able to figure out how its intended to be done for real. ...ant
Re: 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 bin
On Tue, Jun 3, 2008 at 4:37 PM, Simon Laws [EMAIL PROTECTED]
wrote:
On Wed, May 21, 2008 at 2:56 PM, ant elder [EMAIL PROTECTED] wrote:
On Fri, May 16, 2008 at 9:26 AM, Simon Laws [EMAIL PROTECTED]
wrote:
...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
Created a separate factory for it (separate as I though the model may
need
to be pluggable as some point)
Created a new EndpointProvider type and associated factory.
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
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
Last week i updated the runtime-tomcat module to use this Endpoint code to
get the Tomcat deep integration with webapps talking to each other as
being
discussed in [1] and [2]. Its a complete hack at the moment but at least
gives a start at something more real to be talking about in those threads.
You can try it by building the runtime-tomcat module, and the doing a mvn
dependency:copy-dependencies
- in tomcat conf/catalina.properties add the runtime-tomcat jar and
dependencies:
common.loader=${catalina.home}/lib,${catalina
.home}/lib/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/dependency/*.jar
- in tomcat conf/server.xml add the TuscanyHost class name to the
localhost
definition, eg:
Host name=localhost appBase=webapps
className=org.apache.tuscany.sca.runtime.tomcat.TuscanyHost
unpackWARs=true autoDeploy=true
xmlValidation=false xmlNamespaceAware=false
Now you can deploy webapps to tomcat without needing to include _any_
Tuscany stuff in the webapp - no tuscany jars or web.xml config. You can
try
it with the calculator-webapp and calculator-ws-webapp samples, delete all
the jars and Tuscany web.xml config from the webapps and delete the
subtract
component and impl from the calculator-ws-webapp and it should all still
work with the caclulator-ws-webapp using the subtract component in the
calculator-webapp sample.
...ant
[1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
[2] http://apache.markmail.org/message/l7pgz2sxuitdhmxm
I've been thinking about Raymond's suggestion for changing the
EndpointProvider to be EndpointResolver. My only slight qualm is that target
resolution is not performed during what Tuscany refers to as the resolve
phase other than that it sounds OK. Thoughts?
There was also a suggestion that the factory mechanism should be removed
which I'm less keen on. I created the EndpointProvider(Resolver) as a
provider of endpoints that people could create an implementation of to do
resolution for all candidate bindings in the endpoint. I also had it in the
back of my mind to allow binding spcific endpoint providers so that the
developer of the endpoint provider can perform the
Re: 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 bin
On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I've updated all the code that used EndpointProviders. This includes runtime-tomcat but I was unable to get this running following Ant's instruction on this thread. It maybe that I did something wrong so I'll give it another go a little later. What is the problem you get? ...ant
Re: 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 bin
On Sat, Jun 7, 2008 at 12:48 PM, ant elder [EMAIL PROTECTED] wrote: On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws [EMAIL PROTECTED] wrote: snip I've updated all the code that used EndpointProviders. This includes runtime-tomcat but I was unable to get this running following Ant's instruction on this thread. It maybe that I did something wrong so I'll give it another go a little later. What is the problem you get? I've just tried this, there was a problem with the runtime-tomcat META-INF/services file being out of date with the package moves, i've updated this and it now all works ok for me following the instructions in that earlier email in this thread. ...ant
Re: 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 bin
On Wed, May 21, 2008 at 2:56 PM, ant elder [EMAIL PROTECTED] wrote:
On Fri, May 16, 2008 at 9:26 AM, Simon Laws [EMAIL PROTECTED]
wrote:
...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
Created a separate factory for it (separate as I though the model may
need
to be pluggable as some point)
Created a new EndpointProvider type and associated factory.
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
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
Last week i updated the runtime-tomcat module to use this Endpoint code to
get the Tomcat deep integration with webapps talking to each other as being
discussed in [1] and [2]. Its a complete hack at the moment but at least
gives a start at something more real to be talking about in those threads.
You can try it by building the runtime-tomcat module, and the doing a mvn
dependency:copy-dependencies
- in tomcat conf/catalina.properties add the runtime-tomcat jar and
dependencies:
common.loader=${catalina.home}/lib,${catalina
.home}/lib/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/dependency/*.jar
- in tomcat conf/server.xml add the TuscanyHost class name to the localhost
definition, eg:
Host name=localhost appBase=webapps
className=org.apache.tuscany.sca.runtime.tomcat.TuscanyHost
unpackWARs=true autoDeploy=true
xmlValidation=false xmlNamespaceAware=false
Now you can deploy webapps to tomcat without needing to include _any_
Tuscany stuff in the webapp - no tuscany jars or web.xml config. You can
try
it with the calculator-webapp and calculator-ws-webapp samples, delete all
the jars and Tuscany web.xml config from the webapps and delete the
subtract
component and impl from the calculator-ws-webapp and it should all still
work with the caclulator-ws-webapp using the subtract component in the
calculator-webapp sample.
...ant
[1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
[2] http://apache.markmail.org/message/l7pgz2sxuitdhmxm
I've been thinking about Raymond's suggestion for changing the
EndpointProvider to be EndpointResolver. My only slight qualm is that target
resolution is not performed during what Tuscany refers to as the resolve
phase other than that it sounds OK. Thoughts?
There was also a suggestion that the factory mechanism should be removed
which I'm less keen on. I created the EndpointProvider(Resolver) as a
provider of endpoints that people could create an implementation of to do
resolution for all candidate bindings in the endpoint. I also had it in the
back of my mind to allow binding spcific endpoint providers so that the
developer of the endpoint provider can perform the endpoint resolution in an
binding specific way. The processing would go something like.
Re: 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 bin
On Fri, May 16, 2008 at 9:26 AM, Simon Laws [EMAIL PROTECTED]
wrote:
...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
Created a separate factory for it (separate as I though the model may need
to be pluggable as some point)
Created a new EndpointProvider type and associated factory.
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
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
Last week i updated the runtime-tomcat module to use this Endpoint code to
get the Tomcat deep integration with webapps talking to each other as being
discussed in [1] and [2]. Its a complete hack at the moment but at least
gives a start at something more real to be talking about in those threads.
You can try it by building the runtime-tomcat module, and the doing a mvn
dependency:copy-dependencies
- in tomcat conf/catalina.properties add the runtime-tomcat jar and
dependencies:
common.loader=${catalina.home}/lib,${catalina
.home}/lib/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/*.jar,/Tuscany/SVN/trunk/modules/runtime-tomcat/target/dependency/*.jar
- in tomcat conf/server.xml add the TuscanyHost class name to the localhost
definition, eg:
Host name=localhost appBase=webapps
className=org.apache.tuscany.sca.runtime.tomcat.TuscanyHost
unpackWARs=true autoDeploy=true
xmlValidation=false xmlNamespaceAware=false
Now you can deploy webapps to tomcat without needing to include _any_
Tuscany stuff in the webapp - no tuscany jars or web.xml config. You can try
it with the calculator-webapp and calculator-ws-webapp samples, delete all
the jars and Tuscany web.xml config from the webapps and delete the subtract
component and impl from the calculator-ws-webapp and it should all still
work with the caclulator-ws-webapp using the subtract component in the
calculator-webapp sample.
...ant
[1] http://apache.markmail.org/message/2i6gtkveapk3n4nr
[2] http://apache.markmail.org/message/l7pgz2sxuitdhmxm
Re: 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 bin
More comments in line... Simon 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? Yep, we could do that. Am going to hold back for a little while on this in case we decide we need the extra flexibility. 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. I'm not opposed to changing the name but this is function that I expect others to be provided in a pluggable way without having to change the core Tuscany functionality. How would this work without a factory? 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. Autowiring and binding with URI that equates to a target component service name are considered as references with a target and have and endpoint constructed. Bindings with explicit URI that don't equate to the name of a component service are currently not represented by an endpoint. We could create and endpoint in this latter case but I didn't want to upset the current code that covers this case. You are, I think suggesting, we move to the next level where we represent all combinations with Endpoints. I was nervous about taking that step in the first instance. A few examples will help, for example: reference name=myRef target=C1/S1 binding.x/ binding.y/ /reference = Endpoint with a target name of C1/S1 and candidate bindings X and Y reference name=myRef target=C1/S1 C2/S1 binding.x/ binding.y/ /reference = Enpoint with a target name of C1/S1 and candidate bindings X and Y Enpoint with a target name of C2/S1 and candidate bindings X and Y reference name=myRef binding.x/ binding.y/ /reference Autowire set on the component or composite = zero or one Endpoints with candidate bindings X and Y Autowire not set = no Endpoint reference name=myRef binding.x uri=http://x/ binding.y uri=http://y/ /reference Assuming that there is no component call X or Y = No Endoints. Although I agree that in this case we could create an Endpoint representation. Another case: reference name=myRef binding.x uri=C1/S1 http://x// /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
RE: 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 bin
Hi, I've just tried building the latest trunk of Tuscany and I'm getting a compile failure in the new endpoint module. The error I am getting is: [INFO] [INFO] Error for project: Apache Tuscany SCA Default Endpoint Implementation (during install) [INFO] [INFO] Compilation failure /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tuscan y/sca/binding/sca/EndpointTestCase.java:[109,32] package org.apache.xml.serialize does not exist /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tuscan y/sca/binding/sca/EndpointTestCase.java:[110,32] package org.apache.xml.serialize does not exist Is anyone else seeing this issue or is it just me? Thanks, Mark -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: 16 May 2008 09:26 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 Created a separate factory for it (separate as I though the model may need to be pluggable as some point) Created a new EndpointProvider type and associated factory. 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 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 _
RE: 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 bin
This problem has now been fixed in SVN revision r657009 Thanks, Mark -Original Message- From: Mark Combellack [mailto:[EMAIL PROTECTED] Sent: 16 May 2008 11:26 To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: RE: 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 Hi, I've just tried building the latest trunk of Tuscany and I'm getting a compile failure in the new endpoint module. The error I am getting is: [INFO] [INFO] Error for project: Apache Tuscany SCA Default Endpoint Implementation (during install) [INFO] [INFO] Compilation failure /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tusc an y/sca/binding/sca/EndpointTestCase.java:[109,32] package org.apache.xml.serialize does not exist /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tusc an y/sca/binding/sca/EndpointTestCase.java:[110,32] package org.apache.xml.serialize does not exist Is anyone else seeing this issue or is it just me? Thanks, Mark -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: 16 May 2008 09:26 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 Created a separate factory for it (separate as I though the model may need to be pluggable as some point) Created a new EndpointProvider type and associated factory. 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 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 _
Re: 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 bin
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
