You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Meeraj Kunnumpurath <m....@hotmail.co.uk> on 2007/01/30 00:47:41 UTC
Federated Deployment (was SCDL Location in Composite Implementation)
Based on the third option, I think we need to come up with the following,
1. Classes that represent the physical model that represents the artifacts
sent to target slave runtimes for deployment.
2. A component that is responsible on the master runtime responsible for
assembling the physical model from a logical assembly and interacting with
the discovery service to transport them to remote slave runtimes.
3. An inter-operable serialiation protocol that is used to represent the
physical model on the wire.
4. A framework for handling the serialization/de-serialization between
physical model objects and their wire-level representation.
5. A component that is responsible on the slave runtime to deploy the
deserialized model objects.
One key question is how much of this do we need to build from scratch and
how much we can leverage on the existing assets. Can the physical model
leverage on the existing model classes? Also can the current
deployer/loader/builder framework be used for deserializing the physical
model objects and applying the changeset on the target runtime?
Ta
Meeraj
>From: Jeremy Boynes <jb...@apache.org>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Re: SCDL Location in Composite Implementation
>Date: Mon, 29 Jan 2007 15:24:56 -0800
>
>The normative reference here is the name of the composite being used -
>scdlLocation and scdlResource are things we've added to allow that name to
>be resolved in a Java runtime as, to date, there is no spec- defined
>mechanism for doing that. This is related to the artifact resolution
>thread Raymond and I are having.
>
>In the federated case, I don't think that we can use the user- supplied
>SCDL to define what needs to be deployed. This is because the logical
>model supplied by the user can be mapped to different physical
>environments - for example, a single composite could be decomposed to
>multiple physical runtimes resulting in components from it being
>physically deployed separately. If that happens, what is physically
>running is not the user-supplied model but some subset of it.
>
>I think we can handle this in a couple of ways. One is to synthesize
>composites to represent the physical deployments; this has the advantage
>of reusing the existing model but the disadvantage that it conflates the
>logical and physical models. Another is to add extensions to the logical
>model to reflect physical characteristics and then have each runtime just
>deploy the bits that are relevant to it; again this conflates the logical
>and physical models. A third is to separate logical and physical models
>entirely, passing to the runtimes just the information needed to build the
>runtime objects (basically a physical model); I think this is our better
>option as it separates the logical and physical concerns which is in line
>with our existing separation between config model and runtime objects.
>
>Coming back to the original subject, this would mean that things like
>scdlLocation or any other artifact resolution metadata would only apply
>where the logical model was being processed. When it comes to the physical
>representation, these would have already been resolved and converted to
>their physical representation which would be passed to the target runtime
>/by-value./ All references would have been converted and the component
>builders on the target runtime would have a complete definition to work
>from.
>
>I think we have to do this. If we pass references down to the targets then
>we run the risk that different targets will process the references
>differently leading to inconsistent deployment across the federation.
>
>--
>Jeremy
>
>
>On Jan 29, 2007, at 2:30 PM, Meeraj Kunnumpurath wrote:
>
>>Hi,
>>
>>Currently SCDL location is modelled as a URL in CompositeImplementation
>>class. This works ok as long as the SCDL is loaded from a URL. However,
>>with the stuff I am working on with federated assembly, an SCDL may be
>>transported into the runtime through the discovery mechanism and thw SCDL
>>contents may be materialized fully in memory. I was wondering whether we
>>need a higher-level abstraction than URL or stick with URL and write
>>custom protocol handlers were the source for the URL is not a standard
>>one (an in-memory byte array for example).
>>
>>To give a bit of context, I have been thinking of using the existing
>>deployer/loader/builder framwork that is used for local deployment in the
>>federated scenario as well.
>>
>>Thanks
>>Meeraj
>>
>>_________________________________________________________________
>>MSN Hotmail is evolving check out the new Windows Live Mail
>>http://ideas.live.com
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 30, 2007, at 1:32 PM, Raymond Feng wrote:
> 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?
Either depending on whether you are looking to contribute a directory
or individual files. Let's assume the directory as that's
interesting :-)
>
> 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.
>
A directory or other collection-type location has a URL ending in "/"
such as
file:///tuscany/apps/MyApp/
The trailing "/" is significant and indicates that this is a location
containing other things. Depending on the URL scheme there are
different ways in which the content of these resources can be
enumerated - directory listing for file:, WebDAV PROPFIND for http,
LIST for imap, etc.
A suitable processor can walk these trees (if appropriate) and add
their contents.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Raymond Feng <en...@gmail.com>.
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" <jb...@apache.org>
To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Hi,
For the sake of similicity can we assume that allocation of components to
runtimes are explicitly specified in the SCDL, when it is made available to
the assembly service? Then the assembly service can matreilize the physical
component model for individual target slave runtimes, serialize it to XML
and send it through the discovery service. On the receiving end, the
discovery service will route the message to an approriate listener based on
the QName of the message. I have already added a federated deployer as a
listener. The deployer will use the current loader framework to load the
component definition from the XML and pass it to the builder registry to
build and deploy the component. Based on this, I would assume we need to
build the following components,
1. Define the physical model in Java.
2. Map the physical model to XML infoset sent from the master to the slave.
3. Extend the loader framework to support serialization of physical model to
XML. Kind of mirror image of what it does now for deserialization.
4. Write new loaders capable of interpreting the XML snippets representing
the physical model and materialize the component definition on the slave. I
would assume once the component definitions are built we can use the
existing buildres.
Ta
Meeraj
>From: Jeremy Boynes <jb...@apache.org>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Re: Federated Deployment (was SCDL Location in Composite
>Implementation)
>Date: Tue, 30 Jan 2007 12:13:28 -0800
>
>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: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.
http://www.msn.txt4content.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Jeremy Boynes <jb...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I have more questions below.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Jim Marino <jm...@myromatours.com>.
> The basic change here would be to define an InstanceFactory that
> returns a fully initialized instance for the target component:
> class InstanceFactory<T> {
> InstanceWrapper<T> createInstance();
> }
>
> The implementation of this can be provided by the user (which
> allows codegen at development time), generated during contribution,
> or generated during logical->physical mapping. The resulting
> physical component definition would be:
>
Sounds good. I'll be making some changes incorporating the
ComponentManager in which will require a refactor of the existing
builders. We can then tie those into the work on the builders you
describe above.
Jim
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 3, 2007, at 1:01 PM, Meeraj Kunnumpurath wrote:
> Jeremy,
>
> I have been working on the marshallers for the physical model, so
> that they can be transported from master to slave runtimes in a
> federated model. I think what you suggested is closely related to
> what I am working on. If I understand you right,
>
> 1. The assembly service on the master will create the physical
> model from the logical model
> 2. The Java physical model could be as simple as having the runtime
> generated byte code for the instance factory, with your second option
> 3. The marshaller framework will marshal the physical model and
> send it to the target slave through the discovery service
> 4. On the slave, the federated deployer will unmarshall the
> physical component model and use the builder to create the live
> component
> 5. This would require changes to the current builder framework and
> I can see this should simplify the current builders quite a bit.
> 6. What I would suggest is to start a new builder framework in
> parallel and deprecate the old one. The current deployer can
> continue to use the old builder framework and the federted one will
> use the new one. Once we have the builders for all the current
> component types, we can get rid of the old ones.
> 7. The builder will use the instance factory to create the
> component and wire all the properties and references.
> 8. I don't know whether this fits in with the component manager
> stuff Jim is working on, I would assume the federated deployer will
> have to call the component manager to register the component.
This should fit in quite well since the component manager will
support a federated component tree (parents and children are
referenced through URI, not directly). The new deployer can register
directly with the CM. The latter will be used by the connector to
wire source to target. This will allow us to remove the distinction
between composite/atomic components. It will also allow us to move
autowire into the resolve phase so the Connector and
CompositeComponent implementations will not need to traverse the
component tree; in fact, direct references to parents and children
will not be held and will instead be managed through the CM's URI
approach. After that, we can get rid of SCAObject.isSystem since that
can be accommodated by the URI scheme to give us a compact wiring
engine. As we progress, we will also want to allow for wire-path
optimizations, probably by the master. I think we can do some very
interesting things with federated autowire and path-analysis.
I'm in the process of doing the refactors to core to incorporate the
CM. This may take a little while but I will try and stage it as best
I can.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 3, 2007, at 1:01 PM, Meeraj Kunnumpurath wrote:
> 6. What I would suggest is to start a new builder framework in
> parallel and deprecate the old one. The current deployer can
> continue to use the old builder framework and the federted one will
> use the new one. Once we have the builders for all the current
> component types, we can get rid of the old ones.
That sounds radical but I tend to agree it's easiest way. It's about
splitting the current builder (which goes directly from logical model
to runtime component) into two parts: the logical->physical mapper
which we want to be able to run on the master, and the physical-
>runtime component builder which runs on the target runtime.
We could try to do that in place but I don't think would be very
incremental given we use the builders to bootstrap the system. I
agree it will be easier to have frameworks for the two parts and then
move the function from the current builder into them.
>
> I have already started on the physical model. Since, this fits in
> closely with the physical model and federated deployment, I can
> include the new builder framwork in the work I am doing currently.
Cool :-) I'm happy to get stuck into the InstanceFactory stuff. I
think we'll need a common interface for these builders that they
implement and the FD calls. As a strawman, how about:
interface PhysicalComponentBuilder {
Component build(PhysicalComponentDefinition defn)
}
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Jeremy,
I have been working on the marshallers for the physical model, so that they
can be transported from master to slave runtimes in a federated model. I
think what you suggested is closely related to what I am working on. If I
understand you right,
1. The assembly service on the master will create the physical model from
the logical model
2. The Java physical model could be as simple as having the runtime
generated byte code for the instance factory, with your second option
3. The marshaller framework will marshal the physical model and send it to
the target slave through the discovery service
4. On the slave, the federated deployer will unmarshall the physical
component model and use the builder to create the live component
5. This would require changes to the current builder framework and I can see
this should simplify the current builders quite a bit.
6. What I would suggest is to start a new builder framework in parallel and
deprecate the old one. The current deployer can continue to use the old
builder framework and the federted one will use the new one. Once we have
the builders for all the current component types, we can get rid of the old
ones.
7. The builder will use the instance factory to create the component and
wire all the properties and references.
8. I don't know whether this fits in with the component manager stuff Jim is
working on, I would assume the federated deployer will have to call the
component manager to register the component.
I have already started on the physical model. Since, this fits in closely
with the physical model and federated deployment, I can include the new
builder framwork in the work I am doing currently.
Ta
Meeraj
>From: Jeremy Boynes <jb...@apache.org>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Re: Federated Deployment (was SCDL Location in Composite
>Implementation)
>Date: Sat, 3 Feb 2007 12:38:38 -0800
>
>On Jan 29, 2007, at 6:50 PM, Jeremy Boynes wrote:
>>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 :-)
>
>I was thinking about this and about the number of XML entities needed to
>define the input for the builder. We don't need all the flexibility here
>as the generator and the builder are very closely coupled (down to the
>version level). In light of that, we can simplify the generator and
>builder implementation simply by hard wiring this to bytecode. This has
>other advantages as well in terms of runtime simplicity and performance,
>it would also allow users willing to dig into the Tuscany SPIs to provide
>their own factory.
>
>The basic change here would be to define an InstanceFactory that returns a
>fully initialized instance for the target component:
>class InstanceFactory<T> {
> InstanceWrapper<T> createInstance();
>}
>
>The implementation of this can be provided by the user (which allows
>codegen at development time), generated during contribution, or generated
>during logical->physical mapping. The resulting physical component
>definition would be:
>
> <java:component xmlns:java="http://tuscany.apache.org/xmlns/java/ 1.0"
> uri="http://www.example.com/D1/Component1"
> scope="Composite"
> eagerInit='true'>
> <instanceFactory classLoader="MyApp"
>class="sample.Component1Factory"/>
> </java:component>
>
>or
>
> <java:component xmlns:java="http://tuscany.apache.org/xmlns/java/ 1.0"
> uri="http://www.example.com/D1/Component1"
> scope="Composite"
> eagerInit='true'>
> <instanceFactory classLoader="MyApp">$
>{base64EncodedBytecodeForTheFactory}</instanceFactory>
> </java:component>
>
>depending on where the generation was done (i.e. is the factory already in
>the MyApp classloader or not).
>
>All property and physical binding configuration can be handled by the
>implementation of this factory. The builder though would still need to be
>involved to ensure all the local wires in and out of the component were
>connected. It could pass the outbound reference factories to the
>InstanceFactory implementation during construction.
>
>--
>Jeremy
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.
http://www.msn.txt4content.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 29, 2007, at 6:50 PM, Jeremy Boynes wrote:
> 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 :-)
I was thinking about this and about the number of XML entities needed
to define the input for the builder. We don't need all the
flexibility here as the generator and the builder are very closely
coupled (down to the version level). In light of that, we can
simplify the generator and builder implementation simply by hard
wiring this to bytecode. This has other advantages as well in terms
of runtime simplicity and performance, it would also allow users
willing to dig into the Tuscany SPIs to provide their own factory.
The basic change here would be to define an InstanceFactory that
returns a fully initialized instance for the target component:
class InstanceFactory<T> {
InstanceWrapper<T> createInstance();
}
The implementation of this can be provided by the user (which allows
codegen at development time), generated during contribution, or
generated during logical->physical mapping. The resulting physical
component definition would be:
<java:component xmlns:java="http://tuscany.apache.org/xmlns/java/
1.0"
uri="http://www.example.com/D1/Component1"
scope="Composite"
eagerInit='true'>
<instanceFactory classLoader="MyApp"
class="sample.Component1Factory"/>
</java:component>
or
<java:component xmlns:java="http://tuscany.apache.org/xmlns/java/
1.0"
uri="http://www.example.com/D1/Component1"
scope="Composite"
eagerInit='true'>
<instanceFactory classLoader="MyApp">$
{base64EncodedBytecodeForTheFactory}</instanceFactory>
</java:component>
depending on where the generation was done (i.e. is the factory
already in the MyApp classloader or not).
All property and physical binding configuration can be handled by the
implementation of this factory. The builder though would still need
to be involved to ensure all the local wires in and out of the
component were connected. It could pass the outbound reference
factories to the InstanceFactory implementation during construction.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Jeremy,
Pls see questions below.
Thanks
Meeraj
>From: Jeremy Boynes <jb...@apache.org>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>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: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
MSN Hotmail is evolving check out the new Windows Live Mail
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Jeremy Boynes <jb...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Raymond Feng <en...@gmail.com>.
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.
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.
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?
Is artifact resolving going to happen during this phase?
3) A service (AssemblyService?) will add Composite1 to the logical composite
representing the SCA domain.
Then the SCA domain will be:
Composite0:
include Composite1:
Component1
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.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, January 29, 2007 4:17 PM
Subject: Re: Federated Deployment (was SCDL Location in Composite
Implementation)
> On Jan 29, 2007, at 3:47 PM, Meeraj Kunnumpurath wrote:
>
>> Based on the third option, I think we need to come up with the
>> following,
>>
>> 1. Classes that represent the physical model that represents the
>> artifacts sent to target slave runtimes for deployment.
>> 2. A component that is responsible on the master runtime responsible for
>> assembling the physical model from a logical assembly and interacting
>> with the discovery service to transport them to remote slave runtimes.
>> 3. An inter-operable serialiation protocol that is used to represent the
>> physical model on the wire.
>> 4. A framework for handling the serialization/de-serialization between
>> physical model objects and their wire-level representation.
>> 5. A component that is responsible on the slave runtime to deploy the
>> deserialized model objects.
>>
>
> Agreed.
> For 3, I think we should use XML for that as there is no guarantee that
> the source and target runtimes will be implemented using the same
> technology. The content would be the XML types defined in by 1) and that
> must be extensible and versioned. Serialization between wire- format
> messages (XML) and in-memory mode should be selectable by each runtime
> implementation - the Java kernel uses custom loaders for this, I believe
> the C++/Native kernel uses SDO.
>
> For 5), I think the component/message processor would be fairly
> lightweight - most of the work should be in the builders (with which
> builder to use selected by QName of the config object).
>
>> One key question is how much of this do we need to build from scratch
>> and how much we can leverage on the existing assets. Can the physical
>> model leverage on the existing model classes?
>
> I used to think so but recently I've been thinking we should separate
> logical from physical. The logical model objects would represent SCDL
> concepts, the physical ones would be lower level targeted as input for
> the builders. For example, to build a Java component, the builder for it
> should be passed a definition for the implementation, injection sites,
> value factories, inbound and outbound wires with interceptor chains and
> binding definitions.
>
> Time permitting, I'll try and post a snippet for this tonight.
>
>
>> Also can the current deployer/loader/builder framework be used for
>> deserializing the physical model objects and applying the changeset on
>> the target runtime?
>
> Framework wise, yes I think so although from above I think we need more
> information in the handoff to the builder.
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
>From: Jeremy Boynes <jb...@apache.org>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Re: Federated Deployment (was SCDL Location in Composite
>Implementation)
>Date: Mon, 29 Jan 2007 16:17:21 -0800
>
>On Jan 29, 2007, at 3:47 PM, Meeraj Kunnumpurath wrote:
>
>>Based on the third option, I think we need to come up with the following,
>>
>>1. Classes that represent the physical model that represents the
>>artifacts sent to target slave runtimes for deployment.
>>2. A component that is responsible on the master runtime responsible for
>>assembling the physical model from a logical assembly and interacting
>>with the discovery service to transport them to remote slave runtimes.
>>3. An inter-operable serialiation protocol that is used to represent the
>>physical model on the wire.
>>4. A framework for handling the serialization/de-serialization between
>>physical model objects and their wire-level representation.
>>5. A component that is responsible on the slave runtime to deploy the
>>deserialized model objects.
>>
>
>Agreed.
>For 3, I think we should use XML for that as there is no guarantee that
>the source and target runtimes will be implemented using the same
>technology. The content would be the XML types defined in by 1) and that
>must be extensible and versioned. Serialization between wire- format
>messages (XML) and in-memory mode should be selectable by each runtime
>implementation - the Java kernel uses custom loaders for this, I believe
>the C++/Native kernel uses SDO.
I think, regardless of the serialization mechanism that used to represent
the wire-level representation of the transported physical model, the
collaborating runtimes will have to agree on the same discovery protocol.
For example, if a Java runtime chooses to use JXTA as the protocol for
distributing physical model artifacts, the target C++ runtime will have to
agree on the same protocol.
>
>For 5), I think the component/message processor would be fairly
>lightweight - most of the work should be in the builders (with which
>builder to use selected by QName of the config object).
Yeah, a message listener will be selected based on the QName of the payload
and the builder will have injected depenedncies of whatever components that
are required to perform any downstream processing like reconstituting the
physical model in memory, calling the builder, deployer etc.
>
>>One key question is how much of this do we need to build from scratch and
>>how much we can leverage on the existing assets. Can the physical model
>>leverage on the existing model classes?
>
>I used to think so but recently I've been thinking we should separate
>logical from physical. The logical model objects would represent SCDL
>concepts, the physical ones would be lower level targeted as input for the
>builders. For example, to build a Java component, the builder for it
>should be passed a definition for the implementation, injection sites,
>value factories, inbound and outbound wires with interceptor chains and
>binding definitions.
>
>Time permitting, I'll try and post a snippet for this tonight.
>
In addition to the physical model, there will also be control commands like
start/stop component etc. I think it will be useful to have a definitive
list of infoset exchanged between the master and slave runtimes. Both in XML
and the equivalent Java model classes.
>
>>Also can the current deployer/loader/builder framework be used for
>>deserializing the physical model objects and applying the changeset on
>>the target runtime?
>
>Framework wise, yes I think so although from above I think we need more
>information in the handoff to the builder.
The current builder abstraction accepts the parent component, component
definition and deployment context to build the component. Would any
additional information you envisage in building a component in the federated
model be included in the component definition?
>--
>Jeremy
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.
http://www.msn.txt4content.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Federated Deployment (was SCDL Location in Composite Implementation)
Posted by Jeremy Boynes <jb...@apache.org>.
On Jan 29, 2007, at 3:47 PM, Meeraj Kunnumpurath wrote:
> Based on the third option, I think we need to come up with the
> following,
>
> 1. Classes that represent the physical model that represents the
> artifacts sent to target slave runtimes for deployment.
> 2. A component that is responsible on the master runtime
> responsible for assembling the physical model from a logical
> assembly and interacting with the discovery service to transport
> them to remote slave runtimes.
> 3. An inter-operable serialiation protocol that is used to
> represent the physical model on the wire.
> 4. A framework for handling the serialization/de-serialization
> between physical model objects and their wire-level representation.
> 5. A component that is responsible on the slave runtime to deploy
> the deserialized model objects.
>
Agreed.
For 3, I think we should use XML for that as there is no guarantee
that the source and target runtimes will be implemented using the
same technology. The content would be the XML types defined in by 1)
and that must be extensible and versioned. Serialization between wire-
format messages (XML) and in-memory mode should be selectable by each
runtime implementation - the Java kernel uses custom loaders for
this, I believe the C++/Native kernel uses SDO.
For 5), I think the component/message processor would be fairly
lightweight - most of the work should be in the builders (with which
builder to use selected by QName of the config object).
> One key question is how much of this do we need to build from
> scratch and how much we can leverage on the existing assets. Can
> the physical model leverage on the existing model classes?
I used to think so but recently I've been thinking we should separate
logical from physical. The logical model objects would represent SCDL
concepts, the physical ones would be lower level targeted as input
for the builders. For example, to build a Java component, the builder
for it should be passed a definition for the implementation,
injection sites, value factories, inbound and outbound wires with
interceptor chains and binding definitions.
Time permitting, I'll try and post a snippet for this tonight.
> Also can the current deployer/loader/builder framework be used for
> deserializing the physical model objects and applying the changeset
> on the target runtime?
Framework wise, yes I think so although from above I think we need
more information in the handoff to the builder.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org