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