Hi Craig,
Craig Phillips wrote:
Hi,
I've never liked JMX in that I had to open up my firewall;
I would like a pluggable transport architecture built in to declarative services... For example, you would simply have a new keyword: "exposed"... In your OSGI-INF/dot.xml file or in your dot.bnd file for the Service-Component, in addition to words like "optional", you could have "exposed"... For the "provides" entry, you are telling the framework that your service is available across transport; For the "reference", you are telling "distributed declarative services" that you would like to get the service across the transport;
FWIW, the new OSGi 4.2 remote services specification (chapter 13 in
compendium) complies with your desires pretty closely, I think. The
specification defines several service properties, that when present upon
service registration the service is distributed over a network.
Further, there is the concept of a 'configuration type', which with
ECF's implementation allows the desired transport/distribution system to
be selected/used/configured.
So the end result is that via these OSGi-specified service properties
the transport/distribution system can be told, in essence: 'export
this/these interfaces' ( 'service.exported.interfaces' standard property
name) and 'use this/these transports' ('service.exported.configs'
standard property name).
Since declarative services fundamentally uses the OSGi service registry,
all of the remote services can/does work automatically with declarative
services. For example, we now have example code that uses declarative
services to define both the service host and the consumer [1]. There
have also been people that have already used the ECF remote services
impl along with declarative services and blogged about it [2].
I'm looking to auto-generate "stubs" (anyone who knows corba or rmi gets what I mean by the word "stub"); There are a number of ways to do this; This should ride a pluggable transport;
In ECF's implementation this is exactly what we do...the stub/proxy is
created at runtime/service import time...and it does use/ride on a
pluggable transport.
Same with "remote management" -- A better way would be to have an "mxbean like" management api, that would ride "distributed declarative services" which would ride the pluggable transport;
One day we might have a java that really works, a la OSGi and some "dreaming on top", like 'deployable source bundles', that is lightweight, value add (I'd like to see the system bundle decoratable, particularly at the point of "installBundle()" ), and works in the enterprise or the desktop, with a virtual and seamless development environment (and ditch this maven nightmare -- back to deployable source bundles), as opposed to this mount Everest J2EE nonsense...
For more information about the transport independence/pluggable
transport aspect please see [3].
Thanks,
Scott
[1] http://wiki.eclipse.org/OSGi_4.2_Remote_Services_and_ECF
[2]
http://bryanhunt.wordpress.com/2009/06/20/remote-declarative-osgi-services/
[3]
http://eclipseecf.blogspot.com/2010/01/osgi-remote-services-from-ecf.html
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
