You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/07/24 20:49:53 UTC
Distributed domain support in 0.92 was: SCA 0.92 release?
To get the distributed domain support up to a level that is suitable for
including in the next release I think we need to make the node configuration
and management more dynamic.
Scenarios
--------------
The current scenario being used to test distributed support is the
calculator-distributed sample where the CalculatorComponent runs in nodeA
and the AddComponent and SubtractComponent run on NodeB and NodeC
respectively. This is a simple stand alone application and I think we should
continue with it.
There has also been conversation on the list about how the distributed
domain can help when working in a web app environment. What are the salient
points here we need to consider?
SCA Binding
------------------
Currently the code uses JMS to implement the default remote SCA binding. The
remote SCA binding is used when the system finds that two components that
are wired together locally are deployed to separate Nodes. As an alternative
it would be good to support web services here also and have this fit in with
the new SCA binding mechanism that Simon Nash has been working on.
To make a web services SCA binding work we need an EndpointLookup interface
so that components out there in the distributed domain can locate other
components that they are wired to.
Node Management
---------------------------
Currently each node runs in isolation and starts a local SCA domain
configured from .topology and .composite files. It would be good to define
NodeMaganement interfaces so that this information can be provided remotely
and so that the node can expose remotely accessible management interfaces,
for example.
Join a domain
Start/Stop domains and components in domains
Retrieve domain topology and topology changes relevant to the node
Retrieve default domain URIs for this node
Record any events that occur in the domain (could be offered as a feed)
The domain management interface Ant has recently been added that may help us
shape this. Also Sebastien's work to allow local domains to be modified more
dynamically should help make this work.
Distributed Domain Management
-----------------------------------------------
The notion of a distributed domain running across a series of nodes gives
us the opportunity to provide some centralized control, for example
Accept configuration changes
Notify interested nodes/domains that configuration changes are available
Record the endpoints of services offered by each Node/Domain
Collect together events that occur in nodes (again could be offered as a
feed)
For both NodeManagment and DistributedDomainManagement, SCA itself seems to
provide a good foundation for implementing the various management services
that are required. This is how the implementation to date implements its
component registry. Defining such components allows us to provide different
implementations, for example, we could retain the file based management we
have now for batch operation and create network based management components
for dynamic runtime environments.
Anyhow, if anyone has any thoughts about what is required or wants to get
involved in moving this forward then you are most welcome
Simon
Re: Distributed domain support in 0.92 was: SCA 0.92 release?
Posted by Simon Laws <si...@googlemail.com>.
On 7/27/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 7/24/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > To get the distributed domain support up to a level that is suitable for
> > including in the next release I think we need to make the node configuration
> > and management more dynamic.
> >
> > Scenarios
> > --------------
> > The current scenario being used to test distributed support is the
> > calculator-distributed sample where the CalculatorComponent runs in nodeA
> > and the AddComponent and SubtractComponent run on NodeB and NodeC
> > respectively. This is a simple stand alone application and I think we should
> > continue with it.
> >
> > There has also been conversation on the list about how the distributed
> > domain can help when working in a web app environment. What are the salient
> > points here we need to consider?
> >
> > SCA Binding
> > ------------------
> > Currently the code uses JMS to implement the default remote SCA binding.
> > The remote SCA binding is used when the system finds that two components
> > that are wired together locally are deployed to separate Nodes. As an
> > alternative it would be good to support web services here also and have this
> > fit in with the new SCA binding mechanism that Simon Nash has been working
> > on.
> >
> > To make a web services SCA binding work we need an EndpointLookup
> > interface so that components out there in the distributed domain can locate
> > other components that they are wired to.
> >
> > Node Management
> > ---------------------------
> > Currently each node runs in isolation and starts a local SCA domain
> > configured from .topology and .composite files. It would be good to define
> > NodeMaganement interfaces so that this information can be provided remotely
> > and so that the node can expose remotely accessible management interfaces,
> > for example.
> > Join a domain
> > Start/Stop domains and components in domains
> > Retrieve domain topology and topology changes relevant to the node
> > Retrieve default domain URIs for this node
> > Record any events that occur in the domain (could be offered as a
> > feed)
> >
> > The domain management interface Ant has recently been added that may
> > help us shape this. Also Sebastien's work to allow local domains to be
> > modified more dynamically should help make this work.
> >
> > Distributed Domain Management
> > -----------------------------------------------
> > The notion of a distributed domain running across a series of nodes
> > gives us the opportunity to provide some centralized control, for example
> > Accept configuration changes
> > Notify interested nodes/domains that configuration changes are
> > available
> > Record the endpoints of services offered by each Node/Domain
> > Collect together events that occur in nodes (again could be offered
> > as a feed)
> >
> > For both NodeManagment and DistributedDomainManagement, SCA itself seems
> > to provide a good foundation for implementing the various management
> > services that are required. This is how the implementation to date
> > implements its component registry. Defining such components allows us to
> > provide different implementations, for example, we could retain the file
> > based management we have now for batch operation and create network based
> > management components for dynamic runtime environments.
> >
> > Anyhow, if anyone has any thoughts about what is required or wants to
> > get involved in moving this forward then you are most welcome
> >
> > Simon
> >
> A few more thoughts
>
> I am building a few interfaces to formalize the messages involved in
> getting the distributed runtime going in its more dynamic guise. Generally I
> want to accommodate the case where the nodes of the distributed domain can
> run based either on configuration from file or from a central distributed
> domain management function. So I want the interfaces to be implementable in
> each node or to be proxyable to a distributed domain management function.
> The flexibility in the way that the distributed domain runs should be
> achievable by choosing different implementations for the management
> components. I say should as I don't have an end to end demo working of this
> dynamic approach yet. All help gratefully received;-)
>
> SCABinding
> ------------------
> Ant has started work on making the WebService binding work without WSDL
> which will make the work on getting the remote SCABinding up much easier.
> For endpoint discovery we need something like
> ServiceDiscovery
>
> - FindServiceEndpoint(distributedDomainUri, serviceName)
> - RegisterServiceEndpoint(distributedDomainUri, serviceName, url)
>
> This could also be bought into play in the special case of each Node
> discovering the endpoint of the distributed domain management function. In
> the case where that configuration is not available locally you would expect
> a remote endpoint to be provided
>
> Node Management
> ---------------------------
>
> The minimum interface for node management could look something like
> Node
>
> - start(nodeName)
> - stop()
> - JoinDomain(distrbutedDomainUri)
> - DomainNodeConfigurationChange(distributedDomainUri)
>
> So the node operation can be started or stopped. Starting a node would
> cause it to go and discover and register with the distributed domain
> management service. The node can be asked to join a domain and it can be
> notified if there are any domain configuration changes that affect it.
> Changes would be retrieved by the node form the distributed domain. Changes
> would be provided to the domain implementation at the node though an
> interface like
> DomainNode
>
> - createDomainNode(distributedDomainUri)
> - SetBaseUri(distributedDomainUri, protocol, uri)
> - AddContribution(distributedDomainUri, contributionUri)
> - RemoveContribution(distributedDomainUri, contributionUri)
> - AddComponent(distributedDomainUri, componentUri)
> - RemoveComponent(distributedDomainUri, componentUri)
> - StartDomainNode(distributedDomainUri, distrbutedDomainUri)
> - StopDomainNode(distributedDomainUri, distributedDomainUri)
> - StartComponent(distributedDomainUri, componentUri)
> - StopComponent(distributedDomainUri, componentUri)
>
> I'm not sure how much of this interface should be offered remotely by a
> node. Initially the configuration will be offered en masse and only the node
> will be interested in pushing configuration through this interface and on
> into the various interfaces offered by Tuscany already. I'm a little
> confused by the granularity that is intended for incremental updates but
> that is a separate thread.
>
> Distributed Domain Management
> -----------------------------------------------
> Distributed Domain
>
> - GetDomainNodeConfiguration(distributedDomainUri, nodeUri)
> - RegisterNode(nodeUri)
>
> This is minimal as currently I expect the distributed domain management to
> simply accept node registrations and then provide their configuration on
> request. I.e. no incremental updates in the first instance.
>
> I'll implement these interfaces in the distributed package and welcome any
> feedback.
>
> Simon
>
>
> I've checked the first pass of these interfaces in [1]. Needless to say
they are different from the previous post as I've split them up a bit.
Anyhow feedback welcome. The most interesting issue raised in doing this is
around contribution provision and the nature of updates that can be made to
these contributions. I'll start a separate thread on that. Now onto
providing some basic implementation behind this in order to bring up the
calculator-distributed sample again.
Simon
[1]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/
Re: Distributed domain support in 0.92 was: SCA 0.92 release?
Posted by Simon Laws <si...@googlemail.com>.
On 7/24/07, Simon Laws <si...@googlemail.com> wrote:
>
> To get the distributed domain support up to a level that is suitable for
> including in the next release I think we need to make the node configuration
> and management more dynamic.
>
> Scenarios
> --------------
> The current scenario being used to test distributed support is the
> calculator-distributed sample where the CalculatorComponent runs in nodeA
> and the AddComponent and SubtractComponent run on NodeB and NodeC
> respectively. This is a simple stand alone application and I think we should
> continue with it.
>
> There has also been conversation on the list about how the distributed
> domain can help when working in a web app environment. What are the salient
> points here we need to consider?
>
> SCA Binding
> ------------------
> Currently the code uses JMS to implement the default remote SCA binding.
> The remote SCA binding is used when the system finds that two components
> that are wired together locally are deployed to separate Nodes. As an
> alternative it would be good to support web services here also and have this
> fit in with the new SCA binding mechanism that Simon Nash has been working
> on.
>
> To make a web services SCA binding work we need an EndpointLookup
> interface so that components out there in the distributed domain can locate
> other components that they are wired to.
>
> Node Management
> ---------------------------
> Currently each node runs in isolation and starts a local SCA domain
> configured from .topology and .composite files. It would be good to define
> NodeMaganement interfaces so that this information can be provided remotely
> and so that the node can expose remotely accessible management interfaces,
> for example.
> Join a domain
> Start/Stop domains and components in domains
> Retrieve domain topology and topology changes relevant to the node
> Retrieve default domain URIs for this node
> Record any events that occur in the domain (could be offered as a feed)
>
>
> The domain management interface Ant has recently been added that may help
> us shape this. Also Sebastien's work to allow local domains to be modified
> more dynamically should help make this work.
>
> Distributed Domain Management
> -----------------------------------------------
> The notion of a distributed domain running across a series of nodes gives
> us the opportunity to provide some centralized control, for example
> Accept configuration changes
> Notify interested nodes/domains that configuration changes are
> available
> Record the endpoints of services offered by each Node/Domain
> Collect together events that occur in nodes (again could be offered as
> a feed)
>
> For both NodeManagment and DistributedDomainManagement, SCA itself seems
> to provide a good foundation for implementing the various management
> services that are required. This is how the implementation to date
> implements its component registry. Defining such components allows us to
> provide different implementations, for example, we could retain the file
> based management we have now for batch operation and create network based
> management components for dynamic runtime environments.
>
> Anyhow, if anyone has any thoughts about what is required or wants to get
> involved in moving this forward then you are most welcome
>
> Simon
>
A few more thoughts
I am building a few interfaces to formalize the messages involved in getting
the distributed runtime going in its more dynamic guise. Generally I want to
accommodate the case where the nodes of the distributed domain can run based
either on configuration from file or from a central distributed domain
management function. So I want the interfaces to be implementable in each
node or to be proxyable to a distributed domain management function. The
flexibility in the way that the distributed domain runs should be achievable
by choosing different implementations for the management components. I say
should as I don't have an end to end demo working of this dynamic approach
yet. All help gratefully received;-)
SCABinding
------------------
Ant has started work on making the WebService binding work without WSDL
which will make the work on getting the remote SCABinding up much easier.
For endpoint discovery we need something like
ServiceDiscovery
- FindServiceEndpoint(distributedDomainUri, serviceName)
- RegisterServiceEndpoint(distributedDomainUri, serviceName, url)
This could also be bought into play in the special case of each Node
discovering the endpoint of the distributed domain management function. In
the case where that configuration is not available locally you would expect
a remote endpoint to be provided
Node Management
---------------------------
The minimum interface for node management could look something like
Node
- start(nodeName)
- stop()
- JoinDomain(distrbutedDomainUri)
- DomainNodeConfigurationChange(distributedDomainUri)
So the node operation can be started or stopped. Starting a node would cause
it to go and discover and register with the distributed domain management
service. The node can be asked to join a domain and it can be notified if
there are any domain configuration changes that affect it. Changes would be
retrieved by the node form the distributed domain. Changes would be provided
to the domain implementation at the node though an interface like
DomainNode
- createDomainNode(distributedDomainUri)
- SetBaseUri(distributedDomainUri, protocol, uri)
- AddContribution(distributedDomainUri, contributionUri)
- RemoveContribution(distributedDomainUri, contributionUri)
- AddComponent(distributedDomainUri, componentUri)
- RemoveComponent(distributedDomainUri, componentUri)
- StartDomainNode(distributedDomainUri, distrbutedDomainUri)
- StopDomainNode(distributedDomainUri, distributedDomainUri)
- StartComponent(distributedDomainUri, componentUri)
- StopComponent(distributedDomainUri, componentUri)
I'm not sure how much of this interface should be offered remotely by a
node. Initially the configuration will be offered en masse and only the node
will be interested in pushing configuration through this interface and on
into the various interfaces offered by Tuscany already. I'm a little
confused by the granularity that is intended for incremental updates but
that is a separate thread.
Distributed Domain Management
-----------------------------------------------
Distributed Domain
- GetDomainNodeConfiguration(distributedDomainUri, nodeUri)
- RegisterNode(nodeUri)
This is minimal as currently I expect the distributed domain management to
simply accept node registrations and then provide their configuration on
request. I.e. no incremental updates in the first instance.
I'll implement these interfaces in the distributed package and welcome any
feedback.
Simon
Re: Distributed domain support in 0.92 was: SCA 0.92 release?
Posted by Simon Laws <si...@googlemail.com>.
On 7/24/07, Simon Laws <si...@googlemail.com> wrote:
>
> To get the distributed domain support up to a level that is suitable for
> including in the next release I think we need to make the node configuration
> and management more dynamic.
>
> Scenarios
> --------------
> The current scenario being used to test distributed support is the
> calculator-distributed sample where the CalculatorComponent runs in nodeA
> and the AddComponent and SubtractComponent run on NodeB and NodeC
> respectively. This is a simple stand alone application and I think we should
> continue with it.
>
> There has also been conversation on the list about how the distributed
> domain can help when working in a web app environment. What are the salient
> points here we need to consider?
>
> SCA Binding
> ------------------
> Currently the code uses JMS to implement the default remote SCA binding.
> The remote SCA binding is used when the system finds that two components
> that are wired together locally are deployed to separate Nodes. As an
> alternative it would be good to support web services here also and have this
> fit in with the new SCA binding mechanism that Simon Nash has been working
> on.
>
> To make a web services SCA binding work we need an EndpointLookup
> interface so that components out there in the distributed domain can locate
> other components that they are wired to.
>
> Node Management
> ---------------------------
> Currently each node runs in isolation and starts a local SCA domain
> configured from .topology and .composite files. It would be good to define
> NodeMaganement interfaces so that this information can be provided remotely
> and so that the node can expose remotely accessible management interfaces,
> for example.
> Join a domain
> Start/Stop domains and components in domains
> Retrieve domain topology and topology changes relevant to the node
> Retrieve default domain URIs for this node
> Record any events that occur in the domain (could be offered as a feed)
>
>
> The domain management interface Ant has recently been added that may help
> us shape this. Also Sebastien's work to allow local domains to be modified
> more dynamically should help make this work.
>
> Distributed Domain Management
> -----------------------------------------------
> The notion of a distributed domain running across a series of nodes gives
> us the opportunity to provide some centralized control, for example
> Accept configuration changes
> Notify interested nodes/domains that configuration changes are
> available
> Record the endpoints of services offered by each Node/Domain
> Collect together events that occur in nodes (again could be offered as
> a feed)
>
> For both NodeManagment and DistributedDomainManagement, SCA itself seems
> to provide a good foundation for implementing the various management
> services that are required. This is how the implementation to date
> implements its component registry. Defining such components allows us to
> provide different implementations, for example, we could retain the file
> based management we have now for batch operation and create network based
> management components for dynamic runtime environments.
>
> Anyhow, if anyone has any thoughts about what is required or wants to get
> involved in moving this forward then you are most welcome
>
> Simon
>
A few more thoughts
I am building a few interfaces to formalize the messages involved in getting
the distributed runtime going in its more dynamic guise. Generally I want to
accommodate the case where the nodes of the distributed domain can run based
either on configuration from file or from a central distributed domain
management function. So I want the interfaces to be implementable in each
node or to be proxyable to a distributed domain management function. The
flexibility in the way that the distributed domain runs should be achievable
by choosing different implementations for the management components. I say
should as I don't have an end to end demo working of this dynamic approach
yet. All help gratefully received;-)
SCABinding
------------------
Ant has started work on making the WebService binding work without WSDL
which will make the work on getting the remote SCABinding up much easier.
For endpoint discovery we need something like
ServiceDiscovery
- FindServiceEndpoint(distributedDomainUri, serviceName)
- RegisterServiceEndpoint(distributedDomainUri, serviceName, url)
This could also be bought into play in the special case of each Node
discovering the endpoint of the distributed domain management function. In
the case where that configuration is not available locally you would expect
a remote endpoint to be provided
Node Management
---------------------------
The minimum interface for node management could look something like
Node
- start(nodeName)
- stop()
- JoinDomain(distrbutedDomainUri)
- DomainNodeConfigurationChange(distributedDomainUri)
So the node operation can be started or stopped. Starting a node would cause
it to go and discover and register with the distributed domain management
service. The node can be asked to join a domain and it can be notified if
there are any domain configuration changes that affect it. Changes would be
retrieved by the node form the distributed domain. Changes would be provided
to the domain implementation at the node though an interface like
DomainNode
- createDomainNode(distributedDomainUri)
- SetBaseUri(distributedDomainUri, protocol, uri)
- AddContribution(distributedDomainUri, contributionUri)
- RemoveContribution(distributedDomainUri, contributionUri)
- AddComponent(distributedDomainUri, componentUri)
- RemoveComponent(distributedDomainUri, componentUri)
- StartDomainNode(distributedDomainUri, distrbutedDomainUri)
- StopDomainNode(distributedDomainUri, distributedDomainUri)
- StartComponent(distributedDomainUri, componentUri)
- StopComponent(distributedDomainUri, componentUri)
I'm not sure how much of this interface should be offered remotely by a
node. Initially the configuration will be offered en masse and only the node
will be interested in pushing configuration through this interface and on
into the various interfaces offered by Tuscany already. I'm a little
confused by the granularity that is intended for incremental updates but
that is a separate thread.
Distributed Domain Management
-----------------------------------------------
Distributed Domain
- GetDomainNodeConfiguration(distributedDomainUri, nodeUri)
- RegisterNode(nodeUri)
This is minimal as currently I expect the distributed domain management to
simply accept node registrations and then provide their configuration on
request. I.e. no incremental updates in the first instance.
I'll implement these interfaces in the distributed package and welcome any
feedback.
Simon