management (RE: Announcing SOAP service with Glue impl)

[Leo Simons <ma...@leosimons.com>]

> On Thu, 30 Aug 2001 17:29, Paul Hammant wrote:
> > I have coded a cornerstone service that publishes a service (though it
> > could be any object/api) as SOAP api.
> >
> > The service is generic and has ..
> >     void publish(Object obj, String publicationName)
> >     void unpublish(String publicationName)
> > .. as methods.
>
> Excellent!!!! This has remarkable similarities with the JMX stuff ...

Definately cool.

Both SOAP and JMX are promoted as the universal way for apps to talk
together (i.e. "the simpler, better version of CORBA). Unfortunately,
both are in their first use cycle and thus have many deficiencies/
missing features.

As I see it, some kind of GlobalComponentManager which supports
both JMX (by composing an ApacheMBeanServerImpl of some kind) and
SOAP (by composing a SOAP publication service) is what would make
Avalon a lot more useful, especially if it were stored in JNDI
and have a remote interface exported over RMI-IIOP for CORBA
compatability.

For this, we need (thinking out loud):

a) high-level abstraction for the common ground shared by CORBA/SOAP/JMX
b) CORBAService, SOAPService and JMXService implementing their respective
   managers (ORB, SOAP repository (what's it called), MBeanServer) as well
   as CORBADecoratorFactoryService, SOAPDecoratorFactoryService and
   a JMXDecoratorFactory which add manageability to any Object/Component/
   Block/Service (what level should be manageable?)
c) A Manager which can receive a ComponentManager providing the
   above Services, can export itself using RMI, RMI-IIOP, JNDI and the
   provided services based on a supplied Configuration
d) An extension of the block info format / sar descriptor / whatever to
   indicate whether the chosen manageable unit should be manageable
e) An pluggable extension for Phoenix that creates a DefaultManager which
   is asked to export as per d.
f) people to program all this.

here's a draft:

/** Phoenix Facility to expose objects for management */
public interface Manager extends Composable, Facility {
	/** export object for management */
	public void register(Object key, Object value) throws ManagementException;
	/** disable management of object */
	public void unregister(Object key, Object value) throws
ManagementException;
	/** get reference to managed object */
	public Manageable getManageable() throws ManageableNotFoundException;
}
/** marker interface Services/Blocks/Components should implement to be
managed */
public interface Manageable {
}

/** root interface for a Service wrapping a management protocol */
public interface ManagementService extends Service, Composable {
	/** needs ManageableDecoratorFactory */
	public void compose(ComponentManager);
	/** export object for management */
	public void register(Object key, Object value) throws
RegistrationException;
	/** disable management of object */
	public void deregister(Object key) throws RegistrationException;
	/** get reference to managed object */
	public Manageable getManageable() throws ManageableNotFoundException;
}
public interface MBeanManagementService extends ManagementService {
}
public interface RemoteManagementService extends ManagementService {
}
public interface SOAPObjectManagementService extends ManagementService {
}

/** root interface for a Factory that decorates an object to make it
 *  Manageable */
public interface ManageableDecoratorFactory {
	public static Manageable getManageableFor(Object object);
}
public interface MBeanDecoratorFactory extends ManageableDecoratorFactory {
	public static ManageableMBean getManageableFor(Object object);
}
public interface RemoteDecoratorFactory extends ManageableDecoratorFactory {
	public static ManageableRemote getManageableFor(Object object);
}
public interface SOAPObjectDecoratorFactory extends
ManageableDecoratorFactory {
	public static ManageableSOAPObject getManageableFor(Object object);
}

public class DefaultManager implements Manager {
	ManagerService[] m_managers = null;
	compose(ComponentManager cm) {
		// get ManagerServices
	}
	initialize() {
		// export this to all ManagerServices
	}
	register(Object key, Object value) {
		// register object with all ManagerServices
	}
	deregister(Object key, Object value) {
		// deregister object with all ManagerServices
	}
	public Manageable getManageable(Object key) throws
ManageableNotFoundException {
		// try to find the object within all active ManagerServices
	}
}

// inside PhoenixEmbeddor:
	Manager m_manager = new DefaultManager();
	m_manager.compose(m_managerContainingAllManagementServices);
	m_manager.initalize();
	m_manager.register(this);
	m_manager.register(m_phoenix);
	if(m_EXPORT_ALL_VIA_JNDI)
		jndiExport("org.apache.avalon.atlantis.Manager", m_manager);

// anywhere within management app:
	Manager m_manager = getFromJNDI("org.apache.avalon.atlantis.Manager");
	Manageable phoenixInstance = m_manager.getManageable("keyToGetPhoenix");
	phoenixInstance.shutdown();

// or:
	MBean phoenixInstance = getFromJMX("keyToGetPhoenix");
	phoenixInstance.shutdown();

// or:
	SOAPObject phoenixInstance = getFromSOAP("keyToGetPhoenix");
	phoenixInstance.shutdown();

// ...

I've been thinking about this for some time, but have no time
at all to build this, so I'm just tossing in the idea. This is
a first draft and it could probably be a lot better. It's the
concept that matters.

Note that the idea of JMX is that it is also possible to adapt
other management protocols to JMX, however I think JMX has
proven to be too difficult/complicated to actually adapt.

> > Shall I book this in, or is it a bad idea?
>
> +1

+1 to the good idea. I think it is time for serious refactoring
of the entire management concept =)

cheers,

- Leo


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

RE: management (RE: Announcing SOAP service with Glue impl)

[Leo Simons <ma...@leosimons.com>]

> >	public void register(Object key, Object value) throws
> >RegistrationException;
> >
> >	public void deregister(Object key) throws RegistrationException;
> >
> Object keys are better yes.  Note that the actual soapification api
> changed to allow a list of interfaces to expose (via DynamicProxy).
>  Lets say that one (arguably poorly written) block implemented 10
> interfaces, but only a couple were to be exposed for internet presence
> of the object, then you'd want to specify the subset n'est pas?

both the MBean generator and soapification service provide this:

soapification:
	// relevant part of interface:
    void publish(Object obj, String publicationName, Class[]
interfacesToExpose)
	throws SOAPificationException;
    void publish(Object obj, String publicationName, Class
interfaceToExpose)
	throws SOAPificationException;
    void publish(Object obj, String publicationName)
	throws SOAPificationException;

	// somewhere:
	SOAPification soapifier =
getService("org.apache.avalon.cornerstone.services.soapification.SOAPificati
on");
	soapifier.publish(obj1, "key1");
	soapifier.publish(obj2, "key2");

mbean:
	// relevant part of interface:
    public static DynamicMBean create( Object obj )
	throws NotCompliantMBeanException;
    public static DynamicMBean create( Object obj, MBeanInfo mBeanInfo )
        throws IllegalArgumentException, NotCompliantMBeanException;
    public static DynamicMBean create( Object obj, Class[] interfaces )
        throws IllegalArgumentException, NotCompliantMBeanException;

	// somewhere:
	MBeanServer mbeanserver = getMBeanServer();
	MBean bean1 = DynamicMBeanFactory.create( obj1 );
	MBean bean2 = DynamicMBeanFactory.create( obj2 );
	mbeanserver.registerMBean( "key1", bean1 );
	mbeanserver.registerMBean( "key2", bean2 );

as you can see, the process is remarkably similar.
We have 3 options as I see it:

a) make the options mostly identical and provide 'universal management'
   at the 'avalon level';
b) make an MBeanServerImpl wrapping SOAPification and adapt SOAPification
   to provide all the functionality required by the JMX spec and provide
   'universal management' at the 'JMX level';
c) not care about the difference.

option a would make the functionality avalon-specific. Option b warrants
a separate project ("Apache JMX") providing a JMX implementation that
also supports SOAP. Option c is not cool.
I think option b is best; unfortunately, it is also the most work. So I
suggest we try (a) first.

- Leo


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

Re: management (RE: Announcing SOAP service with Glue impl)

[Paul Hammant <Pa...@yahoo.com>]

>
>
>
>	public void register(Object key, Object value) throws
>RegistrationException;
>
>	public void deregister(Object key) throws RegistrationException;
>
Object keys are better yes.  Note that the actual soapification api 
changed to allow a list of interfaces to expose (via DynamicProxy). 
 Lets say that one (arguably poorly written) block implemented 10 
interfaces, but only a couple were to be exposed for internet presence 
of the object, then you'd want to specify the subset n'est pas?
  
 http://cvs.apache.org/viewcvs/jakarta-avalon-cornerstone/src/java/org/apache/avalon/cornerstone/services/soapification/SOAPification.java?rev=1.1&content-type=text/vnd.viewcvs-markup

Regards,

- Paul H


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org