Francesco, Most of the discussions on management and JMX are available on the recent thread titled Standalone Server.
Here is a brief overview of what we have .. Tuscany provides a standalone server in which one or more tuscany runtimes can be started. The server itself used JMX for management. The managed ops include stating/shutting down named runtimes and shutting down the server itself. However, the individual runtimes may choose to any management mechanism (JMX, WSDM, SNMP etc) to enable management. If a runtime decides to use JMX for management, the server will make sure the same mbean server that hosts the server is available for the runtime for registering the managed components within the runtime. This is, however, transparent through the management service abstraction. The abstraction is defined in ManagementService Tuscany SPI. However, the only implementation we have in core is based on JMX. When components are registered, they make them available for management through the management service. Currently, we support read-only view to the component properties. We are discussing about how to enable management of other aspects like poperty mutations, wire management etc. However, they do have other implications around durability of mutations, thread-safety around instances and scopes etc. Ta Meeraj -----Original Message----- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 5:08 PM To: [email protected] Subject: Re: Java kernel release 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] This message has been checked for all email viruses by MessageLabs. ***************************************************** You can find us at www.voca.com ***************************************************** This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
