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