Hi, Jeremy.
Thank you for the explanation.
One more thing to clarify:
Assuming I have a folder structure on the file system to host my
contribution:
/tuscany/apps/MyApp/
/tuscany/apps/MyApp/META-INF/sca/default.scdl
/tuscany/apps/MyApp/xsd/a.xsd
/tuscany/apps/MyApp/sample/Component1Impl.class
What's the input to the ContributionProcessor? The root folder or each file
under the structure?
When I asked the question for the file system case, I thought the
ContributionProcessor takes the whole archive as the input. For a directory,
we cannot open the InputStream.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Tuesday, January 30, 2007 12:13 PM
Subject: Re: Federated Deployment (was SCDL Location in Composite
Implementation)
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]