You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/05/27 18:21:05 UTC
Discovery-based SCA Domain for OSGi RFC 119
Hi,
We have been discussing the idea to use p2p protocols to manage an SCA
domain. There are some interesting use cases coming up as I look into the
dynamicity perspective for the OSGi RFC 119 implementation using
Tuscany/SCA.
To use SCA domain to manage a collection of OSGi frameworks so that the OSGi
services can see each other as follows:
1) Discover remote OSGi services provided by other OSGi frameworks. In SCA
term, the information about the published services (domain-level component
services) is managed by the SCA domain. The service metadata of interest is
the service endpoints, associated properties and policies. Such data can be
exchanged across the nodes using a p2p or centralized coordinator.
2) Synchronize between the OSGi frameworks for the states of the services
via the SCA domain. For example, if a property for a remote OSGi service
exposed to SCA domain is updated, the change will be reflected to the OSGi
service which is an SCA proxy in the client-side OSGi service registry.
In OSGi, we look up the service references from the service registry with
the name of the service interface together with a LDAP-style filter which
matches against the service properties. Mapping to SCA, it's like the
domain-level autowiring or wiredByImpl which allows the references to be
resolved within the SCA domain with some matching criteria.
As the starting point, I'm thinking of making the SCA service registry
remotely accessible. It can serve the service descriptions to SCA nodes or
clients. The service registry can be managed by an SCA domain manager which
receives publication of services from the nodes. The other option is to use
p2p protocol to build a distributed group of the nodes and exchange the
service metadata within the group. With a distributed service registry, we
can resolve the SCA references which uses the SCA wiring
(componentName/serviceName/bindingName) within the SCA domain. It also
allows us to deal with domain-level autowiring.
I start to play Tomcat Tribes which provides a set of simple APIs to use IP
Multicast to build a group of members. I got a Tribe sample working in my
environment. The other interesting project is ZooKeeper from Apache Hadoop
(http://hadoop.apache.org/zookeeper/). We will use the Extension
Point/Extension pattern to make the p2p layer pluggable.
Thoughts?
Thanks,
Raymond
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by ant elder <an...@gmail.com>.
On Tue, Jun 2, 2009 at 4:41 PM, Raymond Feng <en...@gmail.com> wrote:
> A few comments:
>
> 1) The interface should probably be in core-spi module instead of assembly.
> It's the runtime behavior instead of a model.
> 2) We should use it as a utility (instead of a static) from the
> UtilityExtensionPoint which can be looked up from the
> ExtensionPointRegistry. This allows different impl to be plugged in.
>
Sure, i've no problem with those. Just to explain though, right now
I'm trying to do minimal work on the actual code so we don't get any
attachment to this approach till we've finished discussions and
iterated over a few attempts of using it. Right now i expect no one
would care if this impl was chucked out and completely rewritten, if
it was all perfection with javadoc and pluggable impls and
comprehensive testcases etc that may not be the case.
...ant
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Raymond Feng <en...@gmail.com>.
A few comments:
1) The interface should probably be in core-spi module instead of assembly.
It's the runtime behavior instead of a model.
2) We should use it as a utility (instead of a static) from the
UtilityExtensionPoint which can be looked up from the
ExtensionPointRegistry. This allows different impl to be plugged in.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Tuesday, June 02, 2009 1:10 AM
To: <de...@tuscany.apache.org>; <an...@apache.org>
Subject: Re: Discovery-based SCA Domain for OSGi RFC 119
>> In r780938 i've committed an this EndpointRegistry interface, and an
>> impl of the interface, not sure how long we'd keep that impl for as-is
>> but it gives something simple to get going with for now. I did add
>> getters as it helps with debugging for now, and it does still include
>> the EndpointReferences while we decide if they're really needed here
>> or not.
>>
>> ...ant
>>
>
> Thanks Ant.
>
> Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Simon Laws <si...@googlemail.com>.
> In r780938 i've committed an this EndpointRegistry interface, and an
> impl of the interface, not sure how long we'd keep that impl for as-is
> but it gives something simple to get going with for now. I did add
> getters as it helps with debugging for now, and it does still include
> the EndpointReferences while we decide if they're really needed here
> or not.
>
> ...ant
>
Thanks Ant.
Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Giorgio Zoppi <gi...@gmail.com>.
I guess that the main point for have a distributed endpoint resolution
or at least
my motivation is to be able to detect faults and trying to have an
architecture scalable and fault resilent (yes, i know a lot of work is
needed for accomplish that goal). Instead i'd use a centralized
domain is for enforcing QoS policies, both options might to be present
in order to allow the SOA IT Architect a right choice that fits its
needs.
Just 1c,
Giorgio.
--
Quiero ser el rayo de sol que cada día te despierta
para hacerte respirar y vivir en me.
"Favola -Moda".
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Simon Laws <si...@googlemail.com>.
Can we leave them in for the time being. I'm finding it useful for
testing at the moment. A central place where I can look at what
endpoint references are active as I mess about with the builders.
Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by ant elder <an...@gmail.com>.
On Tue, Jun 2, 2009 at 9:08 AM, Simon Laws<si...@googlemail.com> wrote:
> snip...
>
>> 1) Do we need to register the endpoint references? For callbacks, we can
>> just publish the endpoint for the callback.
>
> Not now but his was for the future if we need to establish what
> endpoint references are out there when a new service gets added.
> Corner case so we can ignore for the time being. Maybe we should just
> record them during the "find"
>
What is the status of the endpoint references in the EndpointRegistry?
Looking at the code nothing is using the findEndpointReference or
getEndpointReferences methods so i wonder if we should remove the
methods until we have a need for them?
...ant
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Simon Laws <si...@googlemail.com>.
snip...
> 1) Do we need to register the endpoint references? For callbacks, we can
> just publish the endpoint for the callback.
Not now but his was for the future if we need to establish what
endpoint references are out there when a new service gets added.
Corner case so we can ignore for the time being. Maybe we should just
record them during the "find"
> 2) We may need to have a method to return all published endpoints.
Yep, We may also need general domain query function see 3)
> 3) The key of the endpoints is probably the structural URI of the service
> binding.
+1, we need to make this work. From 2) it would be handy if the whole
model were presented that way so
http://localhost:8080/mydomain/mycompositecomponent/mycomponent
gives you info about a component and
http://localhost:8080/mydomain/mycompositecomponent/mycomponent/myservice/mybinding/
gives you info about an endpoint.
Regards
Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by ant elder <an...@apache.org>.
On Mon, Jun 1, 2009 at 4:43 PM, Raymond Feng <en...@gmail.com> wrote:
> Comments inline.
>
> --------------------------------------------------
> From: "Simon Laws" <si...@googlemail.com>
> Sent: Monday, June 01, 2009 5:44 AM
> To: <de...@tuscany.apache.org>; <an...@apache.org>
> Subject: Re: Discovery-based SCA Domain for OSGi RFC 119
>
> [[snip]]
>
>>
>> What I would like to see is a simple registry style interface for
>> handling endpoint information, e.g.
>>
>> public interface EndpointRegistry {
>> void addEndpoint(Endpoint2 endpoint);
>> void removeEndpoint(Endpoint2 endpoint);
>> void addEndpointReference(EndpointReference2 endpointReference);
>> void removeEndpointReference(EndpointReference2 endpointReference);
>> List<Endpoint2> findEndpoint(EndpointReference2 endpointReference);
>> List<EndpointReference2> findEndpointReference(Endpoint2 endpoint);
>> }
>>
>> Two reasons, firstly we need to be able to ask the "domain" questions
>> about endpoints. Secondly I'm interested at the moment as we need to
>> understand how to ask endpoint resolution questions in order to finish
>> off the endpoint code. For example, one of the changes that is still
>> outstanding is support for serialization required by callable
>> references, this could help here also.
>>
>
> Yes, this is what I have in mind too. A few comments.
>
> 1) Do we need to register the endpoint references? For callbacks, we can
> just publish the endpoint for the callback.
> 2) We may need to have a method to return all published endpoints.
> 3) The key of the endpoints is probably the structural URI of the service
> binding.
>
>> The 1.x domain manager provides a whole raft of "interfaces" already.
>>
>> put/get contribution
>> put/get node configuration
>> put/get deployed composite (defines composite/node association)
>> get composite configuration for individual node
>>
>> There are other things as well, e.g. there are file handling
>> interfaces, but not sure what it is for.
>>
>> In the grand scheme of things we still need these but in many of our
>> scenarios I think we are expecting these interfaces to be called
>> automatically rather than manually though a web gui.
>
> +1.
>>
>> Simon
>
>
In r780938 i've committed an this EndpointRegistry interface, and an
impl of the interface, not sure how long we'd keep that impl for as-is
but it gives something simple to get going with for now. I did add
getters as it helps with debugging for now, and it does still include
the EndpointReferences while we decide if they're really needed here
or not.
...ant
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Raymond Feng <en...@gmail.com>.
Comments inline.
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Monday, June 01, 2009 5:44 AM
To: <de...@tuscany.apache.org>; <an...@apache.org>
Subject: Re: Discovery-based SCA Domain for OSGi RFC 119
[[snip]]
>
> What I would like to see is a simple registry style interface for
> handling endpoint information, e.g.
>
> public interface EndpointRegistry {
> void addEndpoint(Endpoint2 endpoint);
> void removeEndpoint(Endpoint2 endpoint);
> void addEndpointReference(EndpointReference2 endpointReference);
> void removeEndpointReference(EndpointReference2 endpointReference);
> List<Endpoint2> findEndpoint(EndpointReference2 endpointReference);
> List<EndpointReference2> findEndpointReference(Endpoint2 endpoint);
> }
>
> Two reasons, firstly we need to be able to ask the "domain" questions
> about endpoints. Secondly I'm interested at the moment as we need to
> understand how to ask endpoint resolution questions in order to finish
> off the endpoint code. For example, one of the changes that is still
> outstanding is support for serialization required by callable
> references, this could help here also.
>
Yes, this is what I have in mind too. A few comments.
1) Do we need to register the endpoint references? For callbacks, we can
just publish the endpoint for the callback.
2) We may need to have a method to return all published endpoints.
3) The key of the endpoints is probably the structural URI of the service
binding.
> The 1.x domain manager provides a whole raft of "interfaces" already.
>
> put/get contribution
> put/get node configuration
> put/get deployed composite (defines composite/node association)
> get composite configuration for individual node
>
> There are other things as well, e.g. there are file handling
> interfaces, but not sure what it is for.
>
> In the grand scheme of things we still need these but in many of our
> scenarios I think we are expecting these interfaces to be called
> automatically rather than manually though a web gui.
+1.
>
> Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Simon Laws <si...@googlemail.com>.
>>
>> To make any of this work we need to design an interface that the
>> domain provides for the runtime to work with. Has this process started
>> (I don't see anything obvious in the code base)? If not lets start a
>> discussion so we can coordinate activity.
>>
>> Simon
>>
>
> I don't think it exists yet either, so yes lets try come up with that
> interface. Do you have something in mind you could post or should i
> try to come up with a strawman?
>
> ...ant
>
What I would like to see is a simple registry style interface for
handling endpoint information, e.g.
public interface EndpointRegistry {
void addEndpoint(Endpoint2 endpoint);
void removeEndpoint(Endpoint2 endpoint);
void addEndpointReference(EndpointReference2 endpointReference);
void removeEndpointReference(EndpointReference2 endpointReference);
List<Endpoint2> findEndpoint(EndpointReference2 endpointReference);
List<EndpointReference2> findEndpointReference(Endpoint2 endpoint);
}
Two reasons, firstly we need to be able to ask the "domain" questions
about endpoints. Secondly I'm interested at the moment as we need to
understand how to ask endpoint resolution questions in order to finish
off the endpoint code. For example, one of the changes that is still
outstanding is support for serialization required by callable
references, this could help here also.
The 1.x domain manager provides a whole raft of "interfaces" already.
put/get contribution
put/get node configuration
put/get deployed composite (defines composite/node association)
get composite configuration for individual node
There are other things as well, e.g. there are file handling
interfaces, but not sure what it is for.
In the grand scheme of things we still need these but in many of our
scenarios I think we are expecting these interfaces to be called
automatically rather than manually though a web gui.
Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by ant elder <an...@apache.org>.
On Mon, Jun 1, 2009 at 11:28 AM, Simon Laws <si...@googlemail.com> wrote:
> Would I be right in saying that the two node itest doesn't work at the
> moment in lieu of getting the domain function working again?
Yes thats right it doesn't work as the domain function doesn't exists
yet. When it runs and starts the client node this message is output:
01-Jun-2009 12:44:18
org.apache.tuscany.sca.assembly.builder.impl.ComponentReferenceEndpointReferenceBuilderImpl
WARNING: Component reference target not found, it might be a remote
service running elsewhere in the SCA Domain: Composite =
{http://itest}HelloworldClient Service = HelloworldService
(its output twice for some reason i've not investigated)
and then there's an NPE when the reference is invoked.
>
> To make any of this work we need to design an interface that the
> domain provides for the runtime to work with. Has this process started
> (I don't see anything obvious in the code base)? If not lets start a
> discussion so we can coordinate activity.
>
> Simon
>
I don't think it exists yet either, so yes lets try come up with that
interface. Do you have something in mind you could post or should i
try to come up with a strawman?
...ant
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Simon Laws <si...@googlemail.com>.
Would I be right in saying that the two node itest doesn't work at the
moment in lieu of getting the domain function working again?
To make any of this work we need to design an interface that the
domain provides for the runtime to work with. Has this process started
(I don't see anything obvious in the code base)? If not lets start a
discussion so we can coordinate activity.
Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by ant elder <an...@apache.org>.
On Fri, May 29, 2009 at 4:52 PM, Raymond Feng <en...@gmail.com> wrote:
> I have some concerns over the proposed approach to use one JVM to find out
> how the SCA domain works. IMO, it might lead us to oversimplified
> assumptions. I would rather start with two JSE standalone nodes that are
> part of an SCA domain. Using Tomcat webapp also has the risk to mix non SCA
> domain related issues into the picture.
>
> 1) One JVM running with one Node (standalone)
> 2) One JVM running with multiple Nodes (webapp or OSGi)
> 3) Multiple JVMs running 1 or 2 in the same SCA domain
>
> We already have some stories for 1 and 2. The simplest form for 3 would be
> two JVMs with each running with a standalone Node.
>
> Thanks,
> Raymond
>
I've no problem with doing both (2) and (3). Not sure we need to start
with (3) as if we can't have two nodes within the same JVM working
then (3) isn't going to be going either is it? And (2) will be much
easier to work with while debugging, and I'd worry that if we don't
try (2) till later doing just (3) may make it more complicated than
necessary to do (2). Also, part of the point of the tomcat approach is
to end up with something interesting for a release. If we end up with
just a testcase showing two standalone JVMs in a domain its not really
all that exciting, whereas having an SCA enabled Tomcat that supports
dynamic installation and update of contributions seems pretty cool and
useful to me.
How about we try both (2) and (3) in parallel?
...ant
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Raymond Feng <en...@gmail.com>.
I have some concerns over the proposed approach to use one JVM to find out
how the SCA domain works. IMO, it might lead us to oversimplified
assumptions. I would rather start with two JSE standalone nodes that are
part of an SCA domain. Using Tomcat webapp also has the risk to mix non SCA
domain related issues into the picture.
1) One JVM running with one Node (standalone)
2) One JVM running with multiple Nodes (webapp or OSGi)
3) Multiple JVMs running 1 or 2 in the same SCA domain
We already have some stories for 1 and 2. The simplest form for 3 would be
two JVMs with each running with a standalone Node.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Friday, May 29, 2009 3:43 AM
To: <de...@tuscany.apache.org>
Subject: Re: Discovery-based SCA Domain for OSGi RFC 119
> On Thu, May 28, 2009 at 11:39 AM, Simon Laws <si...@googlemail.com>
> wrote:
>
>> I'd like to expand a little on what actual scenarios are being
>> discussed here.
>
> This discussion may well go on and on without achieving much as
> happened in some previous discussions without specific objectives so
> as a concrete scenario as what i'd like to get working is the SCA
> domain used by the new Tuscany Tomcat integration which would work as
> follows:
>
> - The tomcat instance would be a domain. It could also be useful for a
> Tomcat instance to contain multiple domains or be part of a wider
> domain but i'd like to leave those complications to later.
>
> - SCA contributions (webapps and jars/zips etc) can be added during
> runtime so the domain needs to support adding and starting
> dynamically. Stopping, updating, and removing would be good too but
> that can be left till later
>
> - The domain is running within a single JVM so it doesn't need any
> remote distribution technology which helps keep things simple
>
> - It would be great to also get the SCAClient API able to talk to the
> Tomcat domain from a JSE client. I guess thats a slightly different
> topic but it might be useful to keep it in mind
>
> This seems simple and familiar enough that we'll all be able to
> understand it and we have most of that in place now other than being
> able to wire across the Tuscany Nodes so it should be easy enough to
> implement and test as we work out and agree on what to do for the
> domain. I don't think it matters if it uses the "node or domain
> centric" approaches that have been mentioned, or uses the existing
> Node classes or some new Domian APIs and interfaces, we just need to
> get something working so we can show some progress.
>
> Does anyone want more detail on any of that? Or disagree with having
> this as something to achieve?
>
> ...ant
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Raymond Feng <en...@gmail.com>.
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Friday, May 29, 2009 5:56 AM
To: <de...@tuscany.apache.org>
Subject: Re: Discovery-based SCA Domain for OSGi RFC 119
[[snip]]
> I'm not totally thrilled about bringing in the old domain manager code
> right now, i wont get in the way but i don't think its helpful. We can
> see the code already as its in 1.x and take bits from there if
> required so i don't see the need to bring it up in 2.x yet. Why i
> don't like this is because it comes with a large amount of baggage and
> to get it going would mean taking all that on right away without
> getting any sort of common understanding or consensus on what we need
> or are trying to support, and as we've seen over and over it can be
> real hard to remove or substantially redesign something once its
> committed. I was hoping this time we'd take small incremental baby
> steps getting consensus and specific testcases working one by one.
>
As we discussed on the other thread, the SCA domain manager is useful to
provide an administrative view of the
SCA domain. It also provides the capability to assemble contributions into
one or more deployable composite applications
that can be run Nodes. Even though the 1.x SCA domain manager works in a
static manner, the core of the functions
can be reused in the case that some of the metadata are dynamically
discovered or updated. The idea to model related
pieces in the SCA domain as RESTful resources are also very appealing too.
I personally +1 to bring it up to 2.x.
[[snip]]
>>> - The domain is running within a single JVM so it doesn't need any
>>> remote distribution technology which helps keep things simple
>>
Yes or no. SCA domain is naturally distributed. Modeling it after a single
JVM may prevent us seeing the big picture.
>> I'd like to look at this but it can be done outside of this tomcat
>> exercise.
>>
>
> Sure i agree and i'd planned on in parallel to the tomcat work
> continuing to also using the two-nodes-itest as a very simple JSE
> testbed, and we come come up with more simple testcases as the
> scenarios are developed.
+1 to decouple the Tomcat work from the SCA domain. I'm leaning to use two
nodes approach.
>
> ...ant
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by ant elder <an...@apache.org>.
Overall thats sounds great. A couple of comments inline.
...ant
On Fri, May 29, 2009 at 1:36 PM, Simon Laws <si...@googlemail.com> wrote:
> It's always a good idea to try things out. I'd like to help and in
> particular I'm interested in what is specific to Tomcat and what
> constitutes more general interfaces/patterns for managing
> contributions/composites/nodes. I'm looking for the APIs and the
> crossover to the more general distributed domain. To aid that I'd like
> (us) to bring in the domain manager code in parallel. If nothing else
> we can steal bits of code from it.
>
I'm not totally thrilled about bringing in the old domain manager code
right now, i wont get in the way but i don't think its helpful. We can
see the code already as its in 1.x and take bits from there if
required so i don't see the need to bring it up in 2.x yet. Why i
don't like this is because it comes with a large amount of baggage and
to get it going would mean taking all that on right away without
getting any sort of common understanding or consensus on what we need
or are trying to support, and as we've seen over and over it can be
real hard to remove or substantially redesign something once its
committed. I was hoping this time we'd take small incremental baby
steps getting consensus and specific testcases working one by one.
> Comments in line
>
> On Fri, May 29, 2009 at 11:43 AM, ant elder <an...@apache.org> wrote:
>> On Thu, May 28, 2009 at 11:39 AM, Simon Laws <si...@googlemail.com> wrote:
>>
>>> I'd like to expand a little on what actual scenarios are being
>>> discussed here.
>>
>> This discussion may well go on and on without achieving much as
>> happened in some previous discussions without specific objectives so
>> as a concrete scenario as what i'd like to get working is the SCA
>> domain used by the new Tuscany Tomcat integration which would work as
>> follows:
>>
>> - The tomcat instance would be a domain. It could also be useful for a
>> Tomcat instance to contain multiple domains or be part of a wider
>> domain but i'd like to leave those complications to later.
>
> Sounds ok.
>
>>
>> - SCA contributions (webapps and jars/zips etc) can be added during
>> runtime so the domain needs to support adding and starting
>> dynamically. Stopping, updating, and removing would be good too but
>> that can be left till later
>
> Right, this is the point about understanding what we mean by dynamic.
> There is the perfectly reasonable scenario of incremental deployment
> that is enabled by supporting late binding through a registry without
> going all the way to dynamic updates.
>
>>
>> - The domain is running within a single JVM so it doesn't need any
>> remote distribution technology which helps keep things simple
>
> I'd like to look at this but it can be done outside of this tomcat exercise.
>
Sure i agree and i'd planned on in parallel to the tomcat work
continuing to also using the two-nodes-itest as a very simple JSE
testbed, and we come come up with more simple testcases as the
scenarios are developed.
...ant
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Simon Laws <si...@googlemail.com>.
It's always a good idea to try things out. I'd like to help and in
particular I'm interested in what is specific to Tomcat and what
constitutes more general interfaces/patterns for managing
contributions/composites/nodes. I'm looking for the APIs and the
crossover to the more general distributed domain. To aid that I'd like
(us) to bring in the domain manager code in parallel. If nothing else
we can steal bits of code from it.
Comments in line
On Fri, May 29, 2009 at 11:43 AM, ant elder <an...@apache.org> wrote:
> On Thu, May 28, 2009 at 11:39 AM, Simon Laws <si...@googlemail.com> wrote:
>
>> I'd like to expand a little on what actual scenarios are being
>> discussed here.
>
> This discussion may well go on and on without achieving much as
> happened in some previous discussions without specific objectives so
> as a concrete scenario as what i'd like to get working is the SCA
> domain used by the new Tuscany Tomcat integration which would work as
> follows:
>
> - The tomcat instance would be a domain. It could also be useful for a
> Tomcat instance to contain multiple domains or be part of a wider
> domain but i'd like to leave those complications to later.
Sounds ok.
>
> - SCA contributions (webapps and jars/zips etc) can be added during
> runtime so the domain needs to support adding and starting
> dynamically. Stopping, updating, and removing would be good too but
> that can be left till later
Right, this is the point about understanding what we mean by dynamic.
There is the perfectly reasonable scenario of incremental deployment
that is enabled by supporting late binding through a registry without
going all the way to dynamic updates.
>
> - The domain is running within a single JVM so it doesn't need any
> remote distribution technology which helps keep things simple
I'd like to look at this but it can be done outside of this tomcat exercise.
>
> - It would be great to also get the SCAClient API able to talk to the
> Tomcat domain from a JSE client. I guess thats a slightly different
> topic but it might be useful to keep it in mind
I think this is enable by whatever APIs we make available from the
domain so you're right to include it.
>
> This seems simple and familiar enough that we'll all be able to
> understand it and we have most of that in place now other than being
> able to wire across the Tuscany Nodes so it should be easy enough to
> implement and test as we work out and agree on what to do for the
> domain. I don't think it matters if it uses the "node or domain
> centric" approaches that have been mentioned,
I don't think it matters either. But what matters is that we are aware
that there are two approaches and be clear which ones we are using in
each situation as they imply slightly different capabilities and will
help us develop the domain APIs
or uses the existing
> Node classes or some new Domian APIs and interfaces, we just need to
> get something working so we can show some progress.
Getting something working to show the scenario is great and we can all
prod it and learn.
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by ant elder <an...@apache.org>.
On Thu, May 28, 2009 at 11:39 AM, Simon Laws <si...@googlemail.com> wrote:
> I'd like to expand a little on what actual scenarios are being
> discussed here.
This discussion may well go on and on without achieving much as
happened in some previous discussions without specific objectives so
as a concrete scenario as what i'd like to get working is the SCA
domain used by the new Tuscany Tomcat integration which would work as
follows:
- The tomcat instance would be a domain. It could also be useful for a
Tomcat instance to contain multiple domains or be part of a wider
domain but i'd like to leave those complications to later.
- SCA contributions (webapps and jars/zips etc) can be added during
runtime so the domain needs to support adding and starting
dynamically. Stopping, updating, and removing would be good too but
that can be left till later
- The domain is running within a single JVM so it doesn't need any
remote distribution technology which helps keep things simple
- It would be great to also get the SCAClient API able to talk to the
Tomcat domain from a JSE client. I guess thats a slightly different
topic but it might be useful to keep it in mind
This seems simple and familiar enough that we'll all be able to
understand it and we have most of that in place now other than being
able to wire across the Tuscany Nodes so it should be easy enough to
implement and test as we work out and agree on what to do for the
domain. I don't think it matters if it uses the "node or domain
centric" approaches that have been mentioned, or uses the existing
Node classes or some new Domian APIs and interfaces, we just need to
get something working so we can show some progress.
Does anyone want more detail on any of that? Or disagree with having
this as something to achieve?
...ant
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Simon Laws <si...@googlemail.com>.
I'm getting a little be more of a warmer feeling about this exercise
in that we are now able to talk rationally about some concrete
scenarios....
1/ Deploying a statically configured distributed domain build of stand
alone nodes (what we can do today)
2/ Deploy an SCA domain within in a webapp container, e.g. Tomcat
(presumably we want to be able to do the same thing in Geronimo)
3/ Deploy an SCA domain that spans a number of distributed OSGi runtimes.
I'm just pointing out that being able to list how we want to use this
allows us to spot common or distinct features and importantly that
there is plenty of room here for everyone who is interested in helping
out.
Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Simon Laws <si...@googlemail.com>.
On Thu, May 28, 2009 at 5:26 PM, Raymond Feng <en...@gmail.com> wrote:
> In addition to the domain centric vs node centric view, there are
> potentially two different level of functions that are provided by the SCA
> domain.
>
> 1) Deployment: Manage SCA contributions, composites and node configurations.
>
> This is the deployment manager that helps SCA assemblers/deployers to
> partition the domain composite into smaller composite applications that can
> be deployed a specific runtime unit. For example, the administrator can
> starts with a deployable composite. The domain manager can then find the
> required contributions based on the import/export. The composite application
> can then be allocated a node. It ends up with a configuration for a node.
Sounds good. I think this is what the domain manager does today.
>
> A node can have a fixed configuration to a given composite application. Or
> the domain can assign a composite application to the node dynamically based
> on the capability of the node (such as implementation/binding/policy types).
Agreed. We haven't done this dynamic assignment to date. Probably not
the top of the list this time as we should probably think about the
wiring dynamicity first as per you RFC119 type scenarios. Interesting
point though
>
> In a node-centric view, node configurations can be manually crafted
> (programmatically or via node.xml) or locally discovered (from the
> classpath).
I would be pretty handy also if the node could tell the domain what
it's configuration is without manual file editing, e.g. what it's name
is, what ports is provides for what protocols etc.
> In a domain-centric view, node configurations are received from the domain
> (by connecting to the domain deployment manager or taking a pre-built xml
> document).
>
> 2) Runtime: Share service descriptions so that we can perform SCA
> domain-level wiring. This can be done in "online" mode or "offline" mode.
>
> Online mode: There is a live service registry (centralized or distributed)
> that keeps up-to-date information of the domain-level service descriptions.
Yes, that's what we don't have today.
> Offline mode: The domain-level service descriptions are pre-built (or even
> pre-resolved) and a SNAPSHOT of that is used. For example, some XML
> documents (such as a deployment composite with all the SCA endpoints)
> resolved are used to store the domain metadata.
And in this case the configuration is static?
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Raymond Feng <en...@gmail.com>.
In addition to the domain centric vs node centric view, there are
potentially two different level of functions that are provided by the SCA
domain.
1) Deployment: Manage SCA contributions, composites and node configurations.
This is the deployment manager that helps SCA assemblers/deployers to
partition the domain composite into smaller composite applications that can
be deployed a specific runtime unit. For example, the administrator can
starts with a deployable composite. The domain manager can then find the
required contributions based on the import/export. The composite application
can then be allocated a node. It ends up with a configuration for a node.
A node can have a fixed configuration to a given composite application. Or
the domain can assign a composite application to the node dynamically based
on the capability of the node (such as implementation/binding/policy types).
In a node-centric view, node configurations can be manually crafted
(programmatically or via node.xml) or locally discovered (from the
classpath).
In a domain-centric view, node configurations are received from the domain
(by connecting to the domain deployment manager or taking a pre-built xml
document).
2) Runtime: Share service descriptions so that we can perform SCA
domain-level wiring. This can be done in "online" mode or "offline" mode.
Online mode: There is a live service registry (centralized or distributed)
that keeps up-to-date information of the domain-level service descriptions.
Offline mode: The domain-level service descriptions are pre-built (or even
pre-resolved) and a SNAPSHOT of that is used. For example, some XML
documents (such as a deployment composite with all the SCA endpoints)
resolved are used to store the domain metadata.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Thursday, May 28, 2009 3:39 AM
To: <de...@tuscany.apache.org>; <an...@apache.org>
Subject: Re: Discovery-based SCA Domain for OSGi RFC 119
[[snip]]
> A) domain centric
>
> Start domain
> Add contributions to domain
> Start node given domain URL/Node ID
> Node pulls contribution from domain
> Node resolves unresolved endpoint references via the domain (using
> some iface TBD) - this is not in our code today
>
> B) Node centric - this is not in our code today
>
> Start domain (could be part of the nodes or the container the nodes
> run in and hence started automaitcally)
> Start a node given domain URL/Node ID
> Add a contribution to the node
> Node registers itself with the domain (using some iface TBD)
> Node registers information from deployed composites with the domain
> (using some iface TBD)
> Node resolves unresolved endpoint references via the domain (using
> some iface TBD)
>
> I'd like to be able to do both of these so that, as well as what we
> can do today, I can just fire up nodes with contributions and have
> them be part of the domain, i.e no need to manually configure domain.
>
> Above is just a first step that makes management more node centric and
> allows for incremental construction of a domain via late reference
> resolution. It doesn't say anything about a really dynamic domain,
> e.g. where wires can come and go. So lets be clear about what we mean
> when we are talking about dynamic behaviour and extend this list
> accordingly.
>
> Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by ant elder <an...@apache.org>.
On Thu, May 28, 2009 at 11:39 AM, Simon Laws <si...@googlemail.com> wrote:
> Regardless of the interesting technical choices we could make to allow
> us to build a co-operating group of nodes the important first step is
> more architectural in nature and I think embodied in these two
> thoughts...
>
> snip..
>>> As the starting point, I'm thinking of making the SCA service registry
>>> remotely accessible. It can serve the service descriptions to SCA nodes or
>>> clients. The service registry can be managed by an SCA domain manager which
>>> receives publication of services from the nodes.
>
> ...snip...
>
>> itest\nodes\two-nodes-test which starts to try to use two Nodes in a
>> simple inVM domain,
>
> I'd like to expand a little on what actual scenarios are being
> discussed here.. E.g from our *many* previous conversations on this
> subject.
>
> A) domain centric
>
> Start domain
> Add contributions to domain
> Start node given domain URL/Node ID
> Node pulls contribution from domain
> Node resolves unresolved endpoint references via the domain (using
> some iface TBD) - this is not in our code today
>
> B) Node centric - this is not in our code today
>
> Start domain (could be part of the nodes or the container the nodes
> run in and hence started automaitcally)
> Start a node given domain URL/Node ID
> Add a contribution to the node
> Node registers itself with the domain (using some iface TBD)
> Node registers information from deployed composites with the domain
> (using some iface TBD)
> Node resolves unresolved endpoint references via the domain (using
> some iface TBD)
>
> I'd like to be able to do both of these so that, as well as what we
> can do today, I can just fire up nodes with contributions and have
> them be part of the domain, i.e no need to manually configure domain.
>
> Above is just a first step that makes management more node centric and
> allows for incremental construction of a domain via late reference
> resolution. It doesn't say anything about a really dynamic domain,
> e.g. where wires can come and go. So lets be clear about what we mean
> when we are talking about dynamic behaviour and extend this list
> accordingly.
>
> Simon
>
Good points, I need to mull on this some more before responding. In
the meantime I will point out that the two-nodes-test is as it is
right now just because the Tuscany "Node" is all we have to play with
and not because the testcase is intentionally trying to promote a
"Node centric" view.
While we think about all this its worth being aware of what the spec
says: http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.pdf
Some relevant sections are:
4770 B.10 Domain
3738 11.7 Dynamic Behaviour of Wires in the SCA Domain
3597 11.3 Installed Contribution
3629 11.4 Operations for Contributions
There's not much guidance on dynamic operation, 11.7 does say:
3738 For components with references which are at the Domain level,
there is the potential for dynamic
3739 behaviour when the wires for a component reference change (this
can only apply to component
3740 references at the Domain level and not to components within
composites used as implementations):
There are only two mentions of a "node" in the specs that i've found:
1198 composite can run in different operating system processes and
they can even run on
1299 different nodes on a network.
and
3330 An SCA Domain represents a complete runtime configuration,
potentially distributed over a series
3331 of interconnected runtime nodes.
Both of those use node with a lowercase 'n' so maybe we shouldn't be
considering the existing Tuscany Node as such a first class construct.
...ant
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by Simon Laws <si...@googlemail.com>.
Regardless of the interesting technical choices we could make to allow
us to build a co-operating group of nodes the important first step is
more architectural in nature and I think embodied in these two
thoughts...
snip..
>> As the starting point, I'm thinking of making the SCA service registry
>> remotely accessible. It can serve the service descriptions to SCA nodes or
>> clients. The service registry can be managed by an SCA domain manager which
>> receives publication of services from the nodes.
...snip...
> itest\nodes\two-nodes-test which starts to try to use two Nodes in a
> simple inVM domain,
I'd like to expand a little on what actual scenarios are being
discussed here.. E.g from our *many* previous conversations on this
subject.
A) domain centric
Start domain
Add contributions to domain
Start node given domain URL/Node ID
Node pulls contribution from domain
Node resolves unresolved endpoint references via the domain (using
some iface TBD) - this is not in our code today
B) Node centric - this is not in our code today
Start domain (could be part of the nodes or the container the nodes
run in and hence started automaitcally)
Start a node given domain URL/Node ID
Add a contribution to the node
Node registers itself with the domain (using some iface TBD)
Node registers information from deployed composites with the domain
(using some iface TBD)
Node resolves unresolved endpoint references via the domain (using
some iface TBD)
I'd like to be able to do both of these so that, as well as what we
can do today, I can just fire up nodes with contributions and have
them be part of the domain, i.e no need to manually configure domain.
Above is just a first step that makes management more node centric and
allows for incremental construction of a domain via late reference
resolution. It doesn't say anything about a really dynamic domain,
e.g. where wires can come and go. So lets be clear about what we mean
when we are talking about dynamic behaviour and extend this list
accordingly.
Simon
Re: Discovery-based SCA Domain for OSGi RFC 119
Posted by ant elder <an...@gmail.com>.
On Wed, May 27, 2009 at 5:21 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> We have been discussing the idea to use p2p protocols to manage an SCA
> domain. There are some interesting use cases coming up as I look into the
> dynamicity perspective for the OSGi RFC 119 implementation using
> Tuscany/SCA.
>
> To use SCA domain to manage a collection of OSGi frameworks so that the OSGi
> services can see each other as follows:
>
> 1) Discover remote OSGi services provided by other OSGi frameworks. In SCA
> term, the information about the published services (domain-level component
> services) is managed by the SCA domain. The service metadata of interest is
> the service endpoints, associated properties and policies. Such data can be
> exchanged across the nodes using a p2p or centralized coordinator.
>
> 2) Synchronize between the OSGi frameworks for the states of the services
> via the SCA domain. For example, if a property for a remote OSGi service
> exposed to SCA domain is updated, the change will be reflected to the OSGi
> service which is an SCA proxy in the client-side OSGi service registry.
>
> In OSGi, we look up the service references from the service registry with
> the name of the service interface together with a LDAP-style filter which
> matches against the service properties. Mapping to SCA, it's like the
> domain-level autowiring or wiredByImpl which allows the references to be
> resolved within the SCA domain with some matching criteria.
>
> As the starting point, I'm thinking of making the SCA service registry
> remotely accessible. It can serve the service descriptions to SCA nodes or
> clients. The service registry can be managed by an SCA domain manager which
> receives publication of services from the nodes. The other option is to use
> p2p protocol to build a distributed group of the nodes and exchange the
> service metadata within the group. With a distributed service registry, we
> can resolve the SCA references which uses the SCA wiring
> (componentName/serviceName/bindingName) within the SCA domain. It also
> allows us to deal with domain-level autowiring.
>
> I start to play Tomcat Tribes which provides a set of simple APIs to use IP
> Multicast to build a group of members. I got a Tribe sample working in my
> environment. The other interesting project is ZooKeeper from Apache Hadoop
> (http://hadoop.apache.org/zookeeper/). We will use the Extension
> Point/Extension pattern to make the p2p layer pluggable.
>
> Thoughts?
>
> Thanks,
> Raymond
>
I think this could be really realy good for Tuscany, OSGi/RFC119
asside, a dynamic distributed SCA domain will make Tuscany a much more
compelling SOA solution.
I've tried Tribes too. One thing i read about Tribes (in a
presentation i can't find again right now but will keep looking) is
that its not designed for many-to-many communication (i guess because
its for moving http sessions around a tomcat cluster?), so that may be
relevant depending on what we need to do.
There's also https://shoal.dev.java.net/ which looks quite good. And
theres the Distributed Hash Table approach that Giorgio has talked
about on the ML before with using
http://overlayweaver.sourceforge.net/. That actually sounds like quite
an easy approach - if the service registry is just a map of endpoint
objects keyed by endpoint uri then using a distributed hashtable would
make it pretty simple and overlayweaver would handle all the
distribution and discovery for us.
This is quite a complicated area though and we've not been able to get
much consensus on what to do in the past, so could we break it down in
to several smaller pieces that may make it easier? For example, it
sounds like we're starting to agree on having some sort of registry so
could we have that as a separate piece to get going first without
needing all the RFC119 and P2P complications? Yesterday I committed
itest\nodes\two-nodes-test which starts to try to use two Nodes in a
simple inVM domain, if we got that going would it help at all as a
stepping stone for whats needed by RFC119?
...ant