Hi,
I have more questions below.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, January 29, 2007 6:50 PM
Subject: Re: Federated Deployment (was SCDL Location in Composite
Implementation)
On Jan 29, 2007, at 5:20 PM, Raymond Feng wrote:
Hi,
I think it's better to discuss the design in the context of a simple
scenario so that we can see the whole picture. I'm giving a try to
capture what I understand. Please forgive me if there's anything dumb
and help me complete/fix it.
I think this is a good idea - some expansion inline.
1) For the purpose of illustration, let's assume that we have a SCA
domain (D1) with two active runtimes: R1 and R2. R1 is running on
machine M1 and R2 on machine M2.
There is a logic composite (Composite0) representing the SCA domain D1.
The domain has a name which I believe is a hierarchical URI. Let's use
http://www.example.com/D1
There is a conceptual component at the root of the domain implemented by
Composite0. The conceptual URI of this component can be that of the
domain: http://www.example.com/D1
2) An SCA application is developed and packaged as a jar file. The jar
file contains a SCDL to represent a compoiste Composite1 with two
components: Component1 and Component2. The SCDL file references a global
element or type in a.xsd by QName for property definitions.
MyApp.jar:
sample.Component1Impl
sample.Component2Impl
META-INF/sca/default.scdl
xsd/a.xsd
The jar file is contributed to the SCA domain. Some services will be
responsible for scanning/loading artifacts in the contribution. Is
"ContributionProcessor" or "ContributionService" for this purpose?
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)?
Is artifact resolving going to happen during this phase?
I think it can. We can introspect the artifact once during contribution
and save the results in a platform neutral format for consumption by any
runtime. This is an optimization - we may need to invalidate that cache
on lease expiration or if the artifact is modified.
3) A service (AssemblyService?) will add Composite1 to the logical
composite representing the SCA domain.
The implementation behind AssemblyService anyway. Logically this is
applyChange(add <include> of Composite1).
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?
4) We decide to deploy Composite1 distributedly: Compnent1 to runtime R1
and Component2 to runtime R2.
R1: Composite1.Component1
R2: Composite1.Component2
So a subset of Composite1 (physical model?) will be sent to R1 and the
other to R2 using some sort of XML messages. Component1 is activated at
R1 and Component2 is activated at R2. They are now running.
I don't think that what is sent is a strict subset of the SCDL supplied
by the user. For example, if we just sent:
<component name='Component1'>
<implementation.java class='sample.Component1Impl'/>
<reference name='r1' target='Component2'/>
<property name='p1'>${cp1}/foo</property>
</component>
then there is insufficient information there to define what transport is
used to connect Component1 to Component2 over r1 and what the actual
value is for p1.
Instead, I think the data sent should define the configuration data
needed by the JavaComponentBuilder, something like:
<java:component xmlns:java="http://tuscany.apache.org/xmlns/java/ 1.0"
uri="http://www.example.com/D1/Component1";
scope="Composite"
eagerInit='true'>
<implementation class="sample.Component1Impl" classLoader="MyApp"/>
<constructor>
<param class="sample.Component2">
<rmi:binding xmlns:rmi="http://tuscany.apache.org/xmlns/
rmi/1.0" uri="http://m2:1099/D1/Component2"/>
</param>
</constructor>
<injection>
<method name="setP1" type="java.lang.String">
<java:simpleTypeFactory>fooValue</java:simpleTypeFactory>
</method>
</injection>
</java:component>
The XML is meant to be illustrative. It's also meant to be internal to
the runtime and not editable by users :-)
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 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).
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.
--
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]
