Hi,
For the sake of similicity can we assume that allocation of components to
runtimes are explicitly specified in the SCDL, when it is made available to
the assembly service? Then the assembly service can matreilize the physical
component model for individual target slave runtimes, serialize it to XML
and send it through the discovery service. On the receiving end, the
discovery service will route the message to an approriate listener based on
the QName of the message. I have already added a federated deployer as a
listener. The deployer will use the current loader framework to load the
component definition from the XML and pass it to the builder registry to
build and deploy the component. Based on this, I would assume we need to
build the following components,
1. Define the physical model in Java.
2. Map the physical model to XML infoset sent from the master to the slave.
3. Extend the loader framework to support serialization of physical model to
XML. Kind of mirror image of what it does now for deserialization.
4. Write new loaders capable of interpreting the XML snippets representing
the physical model and materialize the component definition on the slave. I
would assume once the component definitions are built we can use the
existing buildres.
Ta
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: Federated Deployment (was SCDL Location in Composite
Implementation)
Date: Tue, 30 Jan 2007 12:13:28 -0800
On Jan 30, 2007, at 11:40 AM, Raymond Feng wrote:
Yes. The JAR is a packaging format understood by a ContributionService
in the domain. Based on the media type (application/zip or
application/x.tuscany.jar) this is processed by the appropriate
ContributionProcessor implementation and the definitions it contained
registered with the domain.
The content type works well with archives that can be streamed. How do we
handle the case that the contribution is from a directory on the file
system (for example, an SCA application installed at folder
/tuscany/applications/MyApp)?
You can stream off the filesystem too aka FileInputStream or the
InputStream from a file: URL.
Many platforms provide a way to get media type from a file (e.g. Windows
has a registry based on extension). On some, that is supported
automatically for file: URLs, on others it isn't. The ContributionService
API allows you to pass in a content type if there is some way to figure it
out, if not there's always application/x- octet-stream and we can have a
processor try and figure out the content type from the stream itself.
Then the SCA domain will be:
Composite0:
include Composite1:
Component1
Component2
The resulting component hierarchy will be:
http://www.example.com/D1
http://www.example.com/D1/Component1
http://www.example.com/D1/Component2
So the composite1 is not in hierarchy due to "include". Does this scheme
require that all components in the top level composites have unique
names?
Yes - it is a requirement from the spec that they do.
This is basically the expanded component definition needed by the
builder. The only reference is to the classLoader and I think that
would be created by another part of the message.
I'm not very sure why ClassLoader is in the message. Shouldn't the target
runtime decide which ClassLoader when the component is activated?
The message would contain information on which classloader to use. The
runtime may need to reuse an existing one or create a new one (e.g. for
multiple components with a local connection). It will need to be told by
the master what to do related to class sharing.
The XPath evaluation for the property value and the decision to use RMI
for the transport would be done by the implementation behind the
AssemblyService API based on information provided by the logical model,
by the runtimes (including what extensions they can support),
administration policies and user-supplied metadata.
The generation of this configuration would be done by an
<implementation.java> processor on a node with access to the assembly
model (for logical context), the resolved artifact information, and a
Java runtime. This may not be the actual node where the component ends
up running.
It seems to me that we need to pass the fully-configured component
definition, i.e., all the model objects referenced by the component.
That's required by the JavaComponentBuilder to create runtime metadata to
start the component.
<component name='Component1'>
<implementation.java class='sample.Component1Impl'/>
<reference name='r1' target='Component2'>
<binding.xxx ...>
...
</binding.xxx>
<property name='p1'>ABC</property> <!-- resolved XML value for
${cp1}/foo -->
</component>
Some of data can be passed by value (for example, the XML value for a
property and the ServiceContract), but some of them will need to be
re-resolved in the target runtime (Java class name --> Java class).
Sounds to me like we're saying the same thing - the message needs to
contain the fully-configured component definition, fully configured as per
the builder's requirements. That will be a lot more information than
defined in SCDL snippets. Some things will need to be resolved on the
target runtime e.g. a Java class name/classloader pair needed to load the
defined Class.
When a contribution is added to the SCA domain, can we assume that all
the resources from the contribution will be available to all runtimes in
the domain? For example, if we deploy Component1 (a java component) to
R1, R1 needs to be able to load the implementation class of Component1.
"Deploy" is such a loaded word here.
Specifically, if R1 is going to be used to run Component1 then it needs to
be able to load its implementation. However, if Component1 is only going
to run on R1 then no other runtime need have access to that implementation
although others could depending on their role in the federation. For
example, yet another node might need access to the implementation in order
to introspect it (even though it will never actually be run there).
Part of federated allocation is to ensure that components are only run on
nodes that have the resources to run them; another part is to distribute
those resources around the domain as needed to run the assembly, subject
to the constraints imposed by federation policies.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.
http://www.msn.txt4content.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
