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.
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
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.
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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
