You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/05/16 10:26:05 UTC
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 bindings model object
Posted by Mark Combellack <mc...@apache.org>.
This problem has now been fixed in SVN revision r657009
Thanks,
Mark
> -----Original Message-----
> From: Mark Combellack [mailto:mcombellack@apache.org]
> Sent: 16 May 2008 11:26
> To: tuscany-dev@ws.apache.org; simonslaws@googlemail.com
> 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:simonslaws@googlemail.com]
>
> > 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 bindings model object
Posted by Mark Combellack <mc...@apache.org>.
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:simonslaws@googlemail.com]
> 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 bindings model object
Posted by ant elder <an...@apache.org>.
On Sat, Jun 7, 2008 at 12:48 PM, ant elder <an...@apache.org> wrote:
>
>
> On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws <si...@googlemail.com>
> 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 bindings model object
Posted by ant elder <an...@apache.org>.
On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws <si...@googlemail.com>
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: Endpoint model design, was: Endpoints
Posted by Simon Laws <si...@googlemail.com>.
Hi
So apart from these minor comments you like it;-) I think you are several
chapters ahead of me here. This Endpoint model is my first effort at
addressing some of the issues at hand and adding some function over the top
of the model we already have without breaking the existing model. Now I know
a little more it's clear that we need to review the way that bindings are
used and, in particular, the way that they drive wire creation. For me
personally this was too big a piece to bite off in the first instance.
Hopefully we can iterate to something that satisfies both of us. I've put
some comments in line.
Simon
On Tue, Jun 10, 2008 at 7:00 PM, Jean-Sebastien Delfino <js...@gmail.com>
wrote:
> Simon Laws wrote:
> ...
>
>> I've created an itest (late-reference-resolution) to show how late
>>>
>>>> resolution could be done using endpoint resolvers.
>>>>
>>> ...
>
> I've spent some time looking at that test and the following classes:
> Endpoint
> EndpointFactory
> Endpoint
> EndpointResolver
> EndpointResolverFactory
> EndpointResolverFactoryExtensionPoint
> EndpointWireImpl
>
> I'd like to suggest the following alternate design:
>
> A) Endpoint has two many relationships with other model objects IMO, and
> when I put it in a UML diagram I noticed that it duplicates a number of
> existing model relationships and mixes real attributes and setter accessors
> for derived attributes or relationships:
> getCandidateBindings()
> getSourceBinding()
> getSourceCallbackBinding()
> getSourceComponent()
> getSourceComponentReference()
> getTargetBinding()
> getTargetComponent()
> getTargetComponentService()
> getTargetName()
> setSourceBinding(Binding)
> setSourceCallbackBinding(Binding)
> setSourceComponent(Component)
> setSourceComponentReference(ComponentReference)
> setTargetBinding(Binding)
> setTargetComponent(Component)
> setTargetComponentService(ComponentService)
> setTargetName(String)
That may be true. I wasn't heading for model perfection I was aiming for
something that worked and that allowed me to better understand the model as
it stands today without breaking it. I added the things to Endpont that I
needed given the model and processing as it stands with a view to removing
any that weren't as we polish the model further.
>
> I thought that Endpoint could just boil down to:
> interface Endpoint<B extends Binding> {
> B getBinding();
> void setBinding(B);
> }
I think we are talking about different things. This strikes me as a resolved
endpoint in that you already know what the binding is going to be. I am
concerned about representing an unresolved target so that it can be resolved
at a later date. Maybe I chose the wrong term when I called it Endpoint and
I'm confusing you. Should we have a Target model instead?
>
> with a Endpoint (0..n) --> (1) Binding relationship. No big invention here
> that looks like a WSDL endpoint.
>
> B) I think that Endpoints are specific to protocols/middleware/binding
> types. They all have a URI plus additional derived binding-specific fields.
> The normal extension mechanism that we use to handle Binding extensions
> should apply to Endpoints here too (allowing you to provide a specific
> Endpoint implementation extension for WebService, EJB, JMS etc.)
>
I think that the way that you resolve endpoints may be specific to a
particular binding type and that the concept of a resolved endpoint is
specific to a binding type. I don't agree that the Endpoint model itself has
to be specific to a binding. However I think your mental model of an
endpoint includes some binding specific data that maybe the binding provider
could use for configuration. So I guess we are thinking about different
parts of the problem. Hopefully we can bring them together!
>
> C) I was envisioning ReferenceEndpointProvider and ServiceEndpointProvider
> interfaces, mirrored on the current ReferenceBindingProvider and
> ServiceBindingProvider but working with Endpoints instead, giving you the
> ability to handle invocations in an endpoint specific way, on an endpoint
> basis (allowing you to manage connection pools for example, which we can't
> really do at the moment with the Binding based design).
So was I but Raymond didn't like that (see previous thread) so I changed it.
Again I wasn't considering that an endpoint would be involved during
invocation which I think is what you are suggesting.
>
> D) Resolution of the address of a target could be done when initializing
> /resolving the Endpoint model, at EndpointProvider.start() time, or at
> invocation time. When done at model initialization/resolution time, the
> outcome of the resolution would be visible in the domain assembly model,
> providing useful feedback to the domain administrator.
>
Agreed. This is the flexibility I have added.
> E) The late-reference-resolution itest uses a static global to implement
> its dynamic lookup. I think that shows that the current EndpointResolver SPI
> does not give it enough context to do that kind of resolution. I think that
> the Endpoint model should be able to obtain a pointer to the top level
> domain composite for example. It would be easy to do if it used the
> ArtifactProcessor mechanism that we're already using for other model
> objects, you could just use the ModelResolver passed to
> ArtifactProcessor.resolve() to get it for example.
>
It's just a test! The EnpointResolver is free to use whatever mechanism it
likes in order to resolve a target name to a target service. This is likely
to involve some remote call to a registry somewhere that is holding this
information. If the local model of the domain already knew the answer then
late binding processing would not be required. I wrote a test registry with
a global static just so that I didn't have to extend the domain manager with
a query to do target lookup functions. I haven't got to that yet.
> F) Finally I think it is important to allow a model populated with resolved
> Endpoints to be saved into a correct composite expressing the same
> information with <binding> elements. That's important IMO to be able to
> communicate the resolved composite using a standard SCA form without
> inventing a new non-standard dialect for this.
This currently works because resolved endpoints are turned back into
bindings on the reference. As I said, this first foray into Endpoint
modeling was specifically intended leave the rest of the model and
associated processing intact.
>
> -- Sebastien
>
Endpoint model design, was: Endpoints
Posted by Jean-Sebastien Delfino <js...@gmail.com>.
Simon Laws wrote:
...
>> I've created an itest (late-reference-resolution) to show how late
>>> resolution could be done using endpoint resolvers.
...
I've spent some time looking at that test and the following classes:
Endpoint
EndpointFactory
Endpoint
EndpointResolver
EndpointResolverFactory
EndpointResolverFactoryExtensionPoint
EndpointWireImpl
I'd like to suggest the following alternate design:
A) Endpoint has two many relationships with other model objects IMO, and
when I put it in a UML diagram I noticed that it duplicates a number of
existing model relationships and mixes real attributes and setter
accessors for derived attributes or relationships:
getCandidateBindings()
getSourceBinding()
getSourceCallbackBinding()
getSourceComponent()
getSourceComponentReference()
getTargetBinding()
getTargetComponent()
getTargetComponentService()
getTargetName()
setSourceBinding(Binding)
setSourceCallbackBinding(Binding)
setSourceComponent(Component)
setSourceComponentReference(ComponentReference)
setTargetBinding(Binding)
setTargetComponent(Component)
setTargetComponentService(ComponentService)
setTargetName(String)
I thought that Endpoint could just boil down to:
interface Endpoint<B extends Binding> {
B getBinding();
void setBinding(B);
}
with a Endpoint (0..n) --> (1) Binding relationship. No big invention
here that looks like a WSDL endpoint.
B) I think that Endpoints are specific to protocols/middleware/binding
types. They all have a URI plus additional derived binding-specific
fields. The normal extension mechanism that we use to handle Binding
extensions should apply to Endpoints here too (allowing you to provide a
specific Endpoint implementation extension for WebService, EJB, JMS etc.)
C) I was envisioning ReferenceEndpointProvider and
ServiceEndpointProvider interfaces, mirrored on the current
ReferenceBindingProvider and ServiceBindingProvider but working with
Endpoints instead, giving you the ability to handle invocations in an
endpoint specific way, on an endpoint basis (allowing you to manage
connection pools for example, which we can't really do at the moment
with the Binding based design).
D) Resolution of the address of a target could be done when initializing
/resolving the Endpoint model, at EndpointProvider.start() time, or at
invocation time. When done at model initialization/resolution time, the
outcome of the resolution would be visible in the domain assembly model,
providing useful feedback to the domain administrator.
E) The late-reference-resolution itest uses a static global to implement
its dynamic lookup. I think that shows that the current EndpointResolver
SPI does not give it enough context to do that kind of resolution. I
think that the Endpoint model should be able to obtain a pointer to the
top level domain composite for example. It would be easy to do if it
used the ArtifactProcessor mechanism that we're already using for other
model objects, you could just use the ModelResolver passed to
ArtifactProcessor.resolve() to get it for example.
F) Finally I think it is important to allow a model populated with
resolved Endpoints to be saved into a correct composite expressing the
same information with <binding> elements. That's important IMO to be
able to communicate the resolved composite using a standard SCA form
without inventing a new non-standard dialect for this.
-- Sebastien
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
Posted by Simon Laws <si...@googlemail.com>.
On Sun, Jun 8, 2008 at 8:45 AM, ant elder <an...@apache.org> wrote:
> On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws <si...@googlemail.com>
> 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 bindings model object
Posted by ant elder <an...@apache.org>.
On Sat, Jun 7, 2008 at 12:46 PM, Simon Laws <si...@googlemail.com>
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 bindings model object
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jun 3, 2008 at 4:37 PM, Simon Laws <si...@googlemail.com>
wrote:
>
>
> On Wed, May 21, 2008 at 2:56 PM, ant elder <an...@gmail.com> wrote:
>
>> On Fri, May 16, 2008 at 9:26 AM, Simon Laws <si...@googlemail.com>
>> 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.
>
> EndpointWire.getInvocationChains()
> EndpointResolver.resolve() (was EndpointProvider.start())
> maybe do some generic endpoint resolution
> for each candidate binding
> Find the binding endpoint resolver
> binding endpoint provider.resolve()
> if (resolution successful)
> endpoint is successfully resolved
> break
>
> To make this work I need to maintain a EndpointResolver factory to be able
> to get the appropriate resolver for each candidate binding and also to fluff
> up the EnpointResolverImpl that has been provided as an extension.
>
> Simon
>
>
I've gone ahead an renamed EndpointProvider to be EndpointResolver and I've
created a separate extension point for it. The endpoint resolver can apply
generally to an endpoint or to the candidate bindings within that endpoint.
So you can either do your endoint resolution in a general way or in a
binding specific way. Our main code path remains the same as it was before,
i.e. if the reference target can be resolved locally then the enpoint is
created but immediately used to select a candidate binding which is placed
in the reference binding list. Endpoint resolvers are only created if an
endpoint can't be resolved at build time.
I've created an itest (late-reference-resolution) to show how late
resolution could be done using endpoint resolvers.
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.
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 bindings model object
Posted by Simon Laws <si...@googlemail.com>.
On Wed, May 21, 2008 at 2:56 PM, ant elder <an...@gmail.com> wrote:
> On Fri, May 16, 2008 at 9:26 AM, Simon Laws <si...@googlemail.com>
> 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.
EndpointWire.getInvocationChains()
EndpointResolver.resolve() (was EndpointProvider.start())
maybe do some generic endpoint resolution
for each candidate binding
Find the binding endpoint resolver
binding endpoint provider.resolve()
if (resolution successful)
endpoint is successfully resolved
break
To make this work I need to maintain a EndpointResolver factory to be able
to get the appropriate resolver for each candidate binding and also to fluff
up the EnpointResolverImpl that has been provided as an extension.
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 bindings model object
Posted by ant elder <an...@gmail.com>.
On Fri, May 16, 2008 at 9:26 AM, Simon Laws <si...@googlemail.com>
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 bindings model object
Posted by Simon Laws <si...@googlemail.com>.
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 bindings model object
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments below.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Friday, May 16, 2008 1:26 AM
To: <tu...@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
>