Jeremy,
Pls see questions below.
Thanks
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: Federated Deployment (was SCDL Location in Composite
Implementation)
Date: Mon, 29 Jan 2007 18:50:36 -0800
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.
How do you see this xml being consumed, if the intended target runtime is
implemented in C++?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
