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]