You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2007/01/03 19:03:43 UTC
Deployment, was: Java kernel release
I started work on a version of this with the definition of two
interfaces in host-api:
ContributionService is an API that handles the contribution of
artifacts to a SCA domain (for now, the domain corresponds to a
single runtime, in the future it will be multiple federated ones).
The main method is:
contribute(URI source, InputStream contribution, String contentType)
which allows the content of any resource to be added to the domain.
The contentType is used to direct the stream to a processor that is
responsible for handling the stream's content and adding the
definitions it provides to the domain. For example, if the Content-
Type was "application/zip" it would be dispatched to a processor
handling zip archives (which might be able to handle other zip-style
archives such as jars). Once a contribution has been processed, the
definitions it provided can be referenced from the Assembly.
The other interface, AssemblyService, handles changes to the logical
Assembly for the domain (which is the instance of the Assembly model
that describes the services provided by the domain and how they are
wired together). The Assembly starts off empty (when the domain
boots) and is built up with a series of changes made through this
API. Typical changes would be things like creating a component,
removing a component, adding a wire between two components and so forth.
The Assembly only references logical definitions such as the
"com.acme.Foo" class name from Jim's example. The runtime is
responsible for mapping that reference into a physical
implementation. So, if that class was contributed in a OSGi bundle,
then the runtime would want to instantiate it in an OSGi-compliant
manner (for example, by loading it into an OSGi framework).
I'm still actively working on this and there is a lot still to do.
--
Jeremy
On Jan 3, 2007, at 9:08 AM, Jim Marino wrote:
>
> On Jan 3, 2007, at 7:54 AM, Francesco Furfari wrote:
>
>> Hi Jim,
>>
>> as you know my vision about Tuscany architecture is still limited,
>> but I was wondering whether one of the JMX implementation at the
>> Felix project could help you. Take a look at http://
>> cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html
>>
>> This solution is tied to adopt an OSGi container. I thought that
>> assemblies could be deployed as bundles, and the SCA system
>> controlled using an OSGi-based JMX console.
>>
> Hi Francesco,
>
> Meeraj has been leading the JMX integration so I'll let him talk
> about what his plans are for it...
>
> In terms of deploying assemblies as bundles, yes, we want to be
> able to support that but we also have plans to do more. The SCA
> collaboration is currently working on deployment (it is one of the
> big missing pieces prior to releasing the specs as "1.0" versions).
> It is still very much a work in progress but the idea behind SCA
> deployment is that we want to support a variety of "packaging"
> formats as well as the ability to contribute resources (e.g. Java
> classes, XSDs, WSDL port types, etc.) that an assembly may
> reference. They key thing we want to do is decouple how resources
> are referenced in an assembly and how they are physically
> contributed to the SCA "domain". Another key thing is we want the
> end-user experience to be very simple.
>
> Some specific examples may help to explain this further. Say I have
> the following component definition:
>
> <component name="FooService">
> <implemenation.java class="com.acme.Foo">
> </component>
>
> How the com.acme.Foo service is contributed to the SCA runtime
> should not be evident from the assembly SCDL, as shown above. It
> could have been contributed through any of the following means:
>
> 1. The class file was placed in a directory
> 2. A jar containing the class file was contributed to a
> "deployment" service
> 3. An OSGi bundle containing the class file was contributed to a
> "deployment" service
>
> ..etc..
>
> Similarly, the same mechanism could be used for WSDLs, XSDs, etc.
>
> More specifically, two steps take place in this process. The first
> is the resource is contributed to the SCA domain. The second step
> is the assembly is mutated, for example, a component is
> instantiated using the SCDL above. This allows for reuse. Sometimes
> these steps may be combined from an end-user perspective. For
> example, I should be able to drop a Java class in a directory and
> have the runtime introspect and deploy it as a component. The
> runtime should also be smart enough to be able to figure out how to
> provision components to various nodes in the service network. For
> example, if I have a component that requires high availability, it
> may deploy to a J2EE host environment running Tuscany. Or, it may
> provision it to an OSGi container running Tuscany. Ditto for the
> Standalone server.
>
> By the time we are done defining the deployment API, I suspect we
> will have something similar to Subversion.
>
> If you are interested in getting involved in helping implement some
> of this or other parts of Tuscany, let us know and I am sure people
> will be able to give you pointers to help get you started. Also,
> we're always interested in hearing about your requirements,
> particularly since it sounds as if you have several projects that
> may be able to make use of these capabilities.
>
> Jim
>
>
>> Is this approach feasible for you or you prefer to add JMX support
>> directly to the kernel?
>>
>> francesco
>>
>
>
> ---------------------------------------------------------------------
> 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: Deployment, was: Java kernel release
Posted by Francesco Furfari <fr...@isti.cnr.it>.
thank you all for the details :-)
I need more time to absorb them, but here some comments following up to
the thread about the Standalone server.
> 1. How the management mechanism is implemented
> 2. How the management interface is extracted from managed components
I would like to discuss about the third level
1. (Agent level) How the management mechanism is implemented
2. (Probe level) How the management interface is extracted from managed
components
3. (console) How client applications effectively manage components
thinking to hundreds of components to be controlled I'm not sure that
standard consoles can manage all them easily.
for example, can the containment hierarchy of the composite pattern be
reproduced using
> ${userDomain} : type = SCAComponent, composite = "${compositeURI}" , name = ${componentName}
I suspect that a standard console (i.e. JConsole) would show a flat
structure, and custom client applications should be developed in order
to integrate *dynamic* systems !! not so exciting.
From this point of view the approach used in Felix mosgi console is
quite interesting in my opinion. For every instrumented component the
developer could point another "controller" component (Plugin) for
rendering purpose (console side). The pattern could be extended also to
composite or modules in order to improve the management of a complex system.
for instance:
@ManagedResource(description="a sample management interface",
controller="componentURI")
In such a way you could also maintain compatibility with the MOSGi
implementation, in fact the URI could point to a non-SCA component (i.e
pure bundle) as well.
> I think one key question is would these annotations be specific to tuscany, or would they be pushed into the core SCA spec some time.
I don't know whether pushing annotations to the SCA spec would be
limited to extend the componentType only, but I'm wondering if it makes
sense to declare instrumented component even in the scdl schema.
Would be nice to have a top level view of the system understanding which
part of the system are manageable. Actually instrumented component
define implicit service entries.
well I've still a lot of questions, but I will post them next.
regards
francesco
Jeremy Boynes wrote:
> I started work on a version of this with the definition of two
> interfaces in host-api:
>
> ContributionService is an API that handles the contribution of artifacts
> to a SCA domain (for now, the domain corresponds to a single runtime, in
> the future it will be multiple federated ones). The main method is:
> contribute(URI source, InputStream contribution, String contentType)
>
> which allows the content of any resource to be added to the domain. The
> contentType is used to direct the stream to a processor that is
> responsible for handling the stream's content and adding the definitions
> it provides to the domain. For example, if the Content-Type was
> "application/zip" it would be dispatched to a processor handling zip
> archives (which might be able to handle other zip-style archives such as
> jars). Once a contribution has been processed, the definitions it
> provided can be referenced from the Assembly.
>
> The other interface, AssemblyService, handles changes to the logical
> Assembly for the domain (which is the instance of the Assembly model
> that describes the services provided by the domain and how they are
> wired together). The Assembly starts off empty (when the domain boots)
> and is built up with a series of changes made through this API. Typical
> changes would be things like creating a component, removing a component,
> adding a wire between two components and so forth.
>
> The Assembly only references logical definitions such as the
> "com.acme.Foo" class name from Jim's example. The runtime is responsible
> for mapping that reference into a physical implementation. So, if that
> class was contributed in a OSGi bundle, then the runtime would want to
> instantiate it in an OSGi-compliant manner (for example, by loading it
> into an OSGi framework).
>
> I'm still actively working on this and there is a lot still to do.
> --
> Jeremy
>
> On Jan 3, 2007, at 9:08 AM, Jim Marino wrote:
>
>>
>> On Jan 3, 2007, at 7:54 AM, Francesco Furfari wrote:
>>
>>> Hi Jim,
>>>
>>> as you know my vision about Tuscany architecture is still limited,
>>> but I was wondering whether one of the JMX implementation at the
>>> Felix project could help you. Take a look at
>>> http://cwiki.apache.org/FELIX/mosgi-managed-osgi-framework.html
>>>
>>> This solution is tied to adopt an OSGi container. I thought that
>>> assemblies could be deployed as bundles, and the SCA system
>>> controlled using an OSGi-based JMX console.
>>>
>> Hi Francesco,
>>
>> Meeraj has been leading the JMX integration so I'll let him talk about
>> what his plans are for it...
>>
>> In terms of deploying assemblies as bundles, yes, we want to be able
>> to support that but we also have plans to do more. The SCA
>> collaboration is currently working on deployment (it is one of the big
>> missing pieces prior to releasing the specs as "1.0" versions). It is
>> still very much a work in progress but the idea behind SCA deployment
>> is that we want to support a variety of "packaging" formats as well as
>> the ability to contribute resources (e.g. Java classes, XSDs, WSDL
>> port types, etc.) that an assembly may reference. They key thing we
>> want to do is decouple how resources are referenced in an assembly and
>> how they are physically contributed to the SCA "domain". Another key
>> thing is we want the end-user experience to be very simple.
>>
>> Some specific examples may help to explain this further. Say I have
>> the following component definition:
>>
>> <component name="FooService">
>> <implemenation.java class="com.acme.Foo">
>> </component>
>>
>> How the com.acme.Foo service is contributed to the SCA runtime should
>> not be evident from the assembly SCDL, as shown above. It could have
>> been contributed through any of the following means:
>>
>> 1. The class file was placed in a directory
>> 2. A jar containing the class file was contributed to a "deployment"
>> service
>> 3. An OSGi bundle containing the class file was contributed to a
>> "deployment" service
>>
>> ..etc..
>>
>> Similarly, the same mechanism could be used for WSDLs, XSDs, etc.
>>
>> More specifically, two steps take place in this process. The first is
>> the resource is contributed to the SCA domain. The second step is the
>> assembly is mutated, for example, a component is instantiated using
>> the SCDL above. This allows for reuse. Sometimes these steps may be
>> combined from an end-user perspective. For example, I should be able
>> to drop a Java class in a directory and have the runtime introspect
>> and deploy it as a component. The runtime should also be smart enough
>> to be able to figure out how to provision components to various nodes
>> in the service network. For example, if I have a component that
>> requires high availability, it may deploy to a J2EE host environment
>> running Tuscany. Or, it may provision it to an OSGi container running
>> Tuscany. Ditto for the Standalone server.
>>
>> By the time we are done defining the deployment API, I suspect we will
>> have something similar to Subversion.
>>
>> If you are interested in getting involved in helping implement some of
>> this or other parts of Tuscany, let us know and I am sure people will
>> be able to give you pointers to help get you started. Also, we're
>> always interested in hearing about your requirements, particularly
>> since it sounds as if you have several projects that may be able to
>> make use of these capabilities.
>>
>> Jim
>>
>>
>>> Is this approach feasible for you or you prefer to add JMX support
>>> directly to the kernel?
>>>
>>> francesco
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org