Hi,
Thank you for sharing your thoughts with us. It's indeed a very interesting
usage of Tuscany/SCA. Please see some comments inline.
Raymond
--------------------------------------------------
From: "Hinde Bouziane" <[EMAIL PROTECTED]>
Sent: Wednesday, June 18, 2008 7:04 AM
To: <[email protected]>
Subject: dynamic assembly and deployment in SCA Tuscany Java implementation
Dear All,
I'm a post-doc working on implementing an abstract
spatio-temporal component model on top of SCA/Tuscany Java
implementation v. 1.2. The main particularity of the model is that it
offer an assembly approach, based on describing spatial (provides/uses)
and temporal (data-flow and control flow) dependencies between
components. In this implementation, components are SCA components. The
assembly of components follows a dynamic approach. That means, the
structure of an application is modified during the
execution. Components are added/removed/connected/disconnected,mainly
depending on temporal dependencies.
Can you provide us a real-world use case for this theory to help us better
understand the requirements?
Independently of the particular usage of SCA/Tuscany implementation
for this work, we are facing some issues regarding dynamic
creation/removal of components for execution on distributed
resources. We aim to find a help to resolve these issues.
Before I cite encountered issues. I would like just to mention what I
understand from the usage of SCA/Tuscany to execute an application on
distributed resources. If I'm wrong, please do not hesitate to
correct me.
* To execute an application in SCA a set of XML descriptors have to be
provided to describe: components and connections, nodes hosting
components, domain content.
Actually, we only need the following information to execute a SCA composite
application:
1) The deployable top-level composite (resolved in the SCA domain)
2) A collection of SCA contributions (archives containing artifacts, such as
a JAR or ZIP) which are required by the composite.
1+2 is the install image and it's the input to the node. The node will be
responsible to run the composite application.
* The domain has a view of (or part of) the application structure and
its deployment through nodes. The domain is responsible to find a
service when this latter is asked.
The domain also knows about the contributions by URL.
* A node looks like a container encapsulating one or more
components. These components are grouped inside a composite
representing the node.
Node is modeled as a composite at this point. It configures the base URIs
for the bindings. The node also references the deployable composite.
* The set of defined nodes determines the deployment and placement
constraints of components (example: if tow components are defined
inside a node, they will be created within the same JVM).
Components are defined in composite, not node. It should be potentially
possible that a node only picks a subset of the components in the deployable
composite.
* To execute an application, a domain is first launched. Second, nodes
are launched on targeted machines. Each node registers itself in the
domain. Last, the execution can be launched for example by a client
program invoking services on deployed components.
Not necessarily. The domain is more an administrative concept. We have a
web-based domain manager in Tuscany today. It's responsibility is to
build/resolve the install image. The install image can be then saved to an
XML file so that it can be loaded without the presence of the domain
manager. Even though the domain manager can provide a button to start a node
(push the install image to a node), the node can pull the install image from
a URL (either live from the domain manager or pointing to a pre-saved file).
The node doesn't have to explicitly register with the SCA domain, especially
for the pull mode.
Encountered problems with some suggestions to try resolving some of them:
Issue 1. Component connections: there is no API provided to the user
to connect components. Connections are done by the runtime from
assembly descriptions. So there is no direct way for the user to
connect dynamically ports (references/services). For our
requirements, I adopted a solution to define a service with
connect/disconnect operations on a user side port (reference) rather
than define a reference port. Thanks to such methods I can pass a
service reference to the user component, which in reality realizes a
connection. The principle is similar to what we can find in other
component models like CCM.
I assume you are talking about "wiring" when you say "connection". The whole
composite model is open to use, you can simply create the deployable
composite programmatically.
Issue 2. Deployment/placement for distributed execution: Components
within a node and nodes are statically specified. The concept of node,
like it is realized, requires a whole application assembly to be
divided through node descriptions and to know execution resources in
advance. That also means that the hierarchy of an assembly should be
broken by the user when for example sub-components are to be deployed
on different machines. That can be tedious to do for the user and a
strong dependency between assembly and deployment is created. It can
be fine if an assembly is kept unchanged for different execution on
different resources. In this direction, if there is a way to create
"empty" nodes on which it is possible to add/remove components, part
of the issues can be resolved to avoid for example splitting an
assembly through nodes. I saw the Node implementation and there is no
API allowing that.
Again, the node is modeled as a SCA composite so you can create it
programmatically too. Just look at the the node composite files in our
store-tutorial.
Issue 3. Behavior when a service is requested: The domain is aware
about the services provided by components. These services are known
thanks to nodes registration. However, it seems that the registration
is not sufficient to find a service. The knowledge of node placement
(host on which it is launched) is also required. That is why a host is
specified in a node XML descriptor. In addition to the problems cited
in Issue 2, that represents an issue for dynamic deployment. Why nodes
registration is not sufficient to be able to find a service? If a node
can pass its placement information to a domain when it registers
itself, it should be possible to avoid the need of static description
of node placement. Isn't it the case? And if the concept of empty
nodes (see Issue 2) is considered, are XML descriptors of nodes still
necessary? Is the proposal feasible by light extensions or
modifications of the SCA Tuscany Java implementation?
Issue 4. Dynamic addition of nodes: Is it possible to add dynamically
a node definition in the domain? I'm revisiting the SCA
specification and in which there is a notion of Domain-level
composite. It seems to allow adding/removing nodes in this way, but
I'm not sure. Can that be a solution? if yes, is it supported in
SCA Tuscany? Otherwise, is the support of dynamic addition/removal of
nodes can be easily feasible?
Node is not a concept in the SCA spec. The domain-level composite has
"include" for each deployable composite added to the SCA domain.
Are you aware of the node2-api, node2-impl and node2-launcher modules in the
code base? It provides a way to create node and launch it.
Any help/suggestion is welcome. Thank you.
Hinde
