This is an automated email from the ASF dual-hosted git repository. djencks pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 32127876e8a3db618b0969334f70715acf0fab7e Author: David Jencks <[email protected]> AuthorDate: Sun Jul 11 15:47:51 2021 -0700 remove mosgi doc (unmaintained) --- modules/ROOT/pages/documentation/subprojects.adoc | 2 +- .../subprojects/mosgi-managed-osgi-framework.adoc | 108 ------------- .../mosgi-managed-osgi-framework/probeguide.adoc | 180 --------------------- 3 files changed, 1 insertion(+), 289 deletions(-) diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc index 667865b..ce7c83c 100644 --- a/modules/ROOT/pages/documentation/subprojects.adoc +++ b/modules/ROOT/pages/documentation/subprojects.adoc @@ -124,7 +124,7 @@ The last documentation may be found in the https://github.com/apache/felix-site- * https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-obr-plugin.html[Maven OBR Plugin] * https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-osgi-plugin.html[Maven OSGi Plugin] * https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-scr-plugin.html[Maven SCR Plugin] -* xref:documentation/subprojects/mosgi-managed-osgi-framework.adoc[MOSGi Managed OSGi framework] +* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/mosgi-managed-osgi-framework.html[MOSGi Managed OSGi framework] * xref:documentation/subprojects/apache-felix-osgi-core.adoc[OSGi Core] * xref:documentation/subprojects/apache-felix-script-console-plugin.adoc[Script Console Plugin] * xref:documentation/subprojects/apache-felix-serialization-framework.adoc[Serialization Framework] diff --git a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.adoc b/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.adoc deleted file mode 100644 index 0e4b4a0..0000000 --- a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.adoc +++ /dev/null @@ -1,108 +0,0 @@ -= MOSGi Managed OSGi framework - -MOSGi enables the remote management of OSGi-compatible service gateways, using JMX. -The framework is a reference architecture for end-to-end gateway management. -It provides the following features: - -* relies on JMX management infrastructure (IP-based management), -* provides two JMX agents: the standard Java 1.5 agent and a specific Java 1.4 lightweight embedded agent (MX4J agent deviation), -* provides a way to deploy various probes on remote gateways, -* provides a management console, -* the graphical part of a probe (management console part) can be dynamically plugged in the management console and is dynamically downloaded. - -== Very fast QuickStart Guide - -Go into $FELIX_HOME/trunk/mosgi.doc and read Readme.txt. - -== General architecture - -The overall architecture is presented in the following picture : - -!MOSGiArchitecture.png! - -== How it works - -Managed OSGi gateways can install JMX probes from various repositories. -A JMX probe is a standard OSGi bundle that registers an xref:#_mbean_definition[#MBean] component in the managed gateway's JMX agent. - -The management console (running in a standard OSGi framework) is connected to each gateway through the JMX remoting protocol. -When it connects for the first time to a managed gateway, it asks for probes that are installed (i.e. -all MBeans registered in the TabUI JMX domain). -Then, for each MBean found, the management console asks for its graphical representation through a call to our standard API (component getUI() call). -This call redirects to a bundle in the GUI probe repository that is installed by the management console. -So the management console discovers at run-time the user interface it should use to supervise a specific remote gateway. - -Here is a description of different bundles that should be installed on both parts of the infrastructure (managed OSGi gateway and Management console). - -A managed OSGi gateway must host the following bundles : - -* JMX-MX4J Agent Service: provides a JMX agent. -Either through a wrapper to jdk1.5 standard agent or through using a specific lightweight inner agent1 (originate from mx4j project). -This agent service also declares a standard MBeanServer service interface.. -* JMX rmiregistry: wraps RMI registry life cycle. -It's used by the JMX remoting infrastructure to register -* JMX RMI connector: wraps a standard JMX remoting RMI connector -* Remote Logger: notifies log informations - -A JMX Console is an OSGi framework also (for simplicity) which should host two bundles : - -* JMX Console: the graphical framework that will host graphical plugins -* jmxconsole common tabs: tabs that are common to all gateways. -For the moment it only concerns a tab that shows remote notification (it works whith remote logger) - -== OSGi/JMX MBean registration - -MOSGi installs JMX-MX4J agent at the gateways level. -Any one can register an MBean to the JMX agent. -The registration can be made in two ways. -The direct code and the white board pattern. - -* In the direct code, one can register an MBean to the agent through the standard service interface : _javax.management.MBeanServer_ - -Example: - - org.osgi.framework.ServiceReference sr == context.getServiceReference(javax.management.MBeanServer.class.getName()); - javax.management.MBeanServer mbs=(javax.management.MBeanServer)context.getService(sr); - mbs.registerMBean(new MBeanImpl(), new ObjectName("Foo:FooName"); - -Exemple of such code is uses in _mosgi.managedelements.bundlesprobes_ code in felix repository - -* In the whiteboard pattern, one can register an MBean through registering its interface to the framework as a service. -If the interface name ends with MBean or if the interface is _javax.management.DynamicMBean_, the agent will automatically register the implementation as a standard MBean. -The objectName of the MBean can either be defined at registration time with the _org.apache.felix.mosgi.jmx.agent.Constants.OBJECTNAME_ property name or automatically build through introspection. - -Example: - - java.util.Properties prop=new java.util.Properties(); - prop.add( org.apache.felix.mosgi.jmx.agent.Constants.OBJECTNAME, "Foo:FooName"); - context.registerService(test.FooMBean.class.getName(), new test.Foo(), prop); - -== Management Console - -The management console is a ad-hoc jmx compatible console. -Its aim is not to be a concurrent to general purpose consoles like MX4J or JConsole but provides an ad-hoc user interface depending on the managed gateway. -The console is based on a plugin framework. -Each time the consol connects to a gateway it gets the list of available MBean. -Then for each registered MBean it asks for specific local bundles for managing it. -Each graphical bundle is integrated as a graphical tab in the management console. - -In the next screenshot, the gateway user has deployed 4 probes on the remote gateway : Remote Obr, Remote Bundle List, GNU/Linux and OSGi Plateform.!jmxconsoleGUI.png! - -In order to get these tabs, the gateway manager deploys the 4 probe bundles on the remote gateway and GUI tabs are automatically made available to the remote console. -These bundles are : - -* ObrProbe : a probe that enables interaction with obr for bundle deployment -* BundleProbe : a probe that enables the bundle life-cycle management -* GNU-Linux : a probe that gets status from running host operating system -* OSGi Platform : a probe that gets information from current running gateway - -These plugin are developed as simple examples and are available in felix repository. -A xref:documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc[ProbeGuide] that describes plugin integration is available. -Plugin are dynamically removed and reinstalled each time you change your selected gateway. - -[discrete] -==== MBean Definition - -An MBean is a Management Component for the JMX framework. -It is made of an MBean interface and an implementation of it. -The MBean interface is used to make remote management with the implementation. diff --git a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc b/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc deleted file mode 100644 index b491123..0000000 --- a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc +++ /dev/null @@ -1,180 +0,0 @@ -= Developing probes for MOSGi framework - -\{quote} - -\{quote} MOSGi is a management infrastructure for OSGi gateways remote management. -The architecture relies on JMX management infrastructure and is classically build on a three layered system: - -!ManagementLayers.png! - -* The probe layer: are low layer elements that drive the gateway. -They can either get information from the gateway (gateway status) or set information on it (install a bundle), -* The Agent layer: there is one agent per gateway and is responsible for maintaining access to a list of available probes, -* The Manager layer is the remote environment that can communicate with the agent to get information from the gateway through the probes - -There are various way to implements this architecture (CIM/Wbem, Snmp, JMX). -We have choose to use the JMX proposal because it is standardized in the java virtual machine since jdk1.5. - -== JMX management infrastructure synthesis - -Sun JMX proposal defines the following elements : - -!JMXLayers.png! - -* The agent is the registry for probes called MBeans and is accessed through connectors. -* MBeans are java objects that register themselves to the agent under some name -* Connectors are end points were external managers can communicate with. -There are currently two available connectors : an xml/http connector and a rmi based connector. -We are using the rmi connector (JSR160). - -In the JMX world probes are represented as MBeans. -They are java singleton object that declare a single interface to the agent. -This interface is registered under a unique name within the agent namespace. -The JMX namespace is structured as a domainname:mbeanname unique name. -The following html page represents an example of this kind of namespace (we use the httpconnector connector with the agent to get this information). - -!jmxmx4jhtml.png! - -These are various mbeans deployed on a specific gateway. -We can identify 4 columns : the mbean registered name (and domain), its implementation, a comment and a function to unregister it. - -Mbeans are component that declare a management interface that should have a syntactic name similar to the class they instrument. -For instance the class foo.Test should implement a management interface whose name is foo.TestMBean. -The registration mechanism associates a implementation (conform to the management interface) with an objectName (a unique identifier). -The corresponding call is something like :aMbeanServer.register(aMBeanImplementation, anObjectName);. -There are many kinds of MBeans (standard, dynamic, model and simple) but their description is out of the scope of this document. - -== MOSGi probe developpement - -Our management infrastructure proposes a framework for deploying standard mbean within OSGi gateways. -It also embeds a reference to a graphical part (manager view) directly in the Mbean itself. -Thus the management console is automatically populated with client part of the management system. - -=== Gateway probes - -These probes are developed in conformance to the following elements. - -* A probe must be registered under the domain TabUI. -It means that they will have a corresponding tab in our management console. -* A probe must implement a management interface conform to the JMX specification (ie : foo.LinuxProbe -\-> foo.LinuxProbeMBean) -* The management interface must extend TabIfc (which declares a single method : getBundleName()). -This methods returns an url were the management console should find a tab that can establish a management dialog with the probe. -* The probe is made available as a standard OSGi Mbean that will make its registration during the bundleActivator start method. - -The following picture illustrates relations between these elements. - -!MOSGiProbeClasses.png! - -For instance a Probe that declares a single management function _int getValue()_;should provide the following interface: - - package foo; - import insa.jmxconsole.gui.service.TabIfc; - public interface ProbeMBean extends TabIfc { - public int getValue(); - } - -And the following class: - ----- -package foo; -import org.osgi.framework.BundleActivator; -import org.osgi.framework.BundleContext; -import org.osgi.framework.ServiceReference; -import insa.jmxconsole.gui.service.TabIfc; -import javax.management.MBeanServer; -public class Probe implements BundleActivator,ProbeMBean{ - ////////////////////////////////////////// - // BundleActivator Interface // - ////////////////////////////////////////// - /* The probe lifecycle is linked to the bundle lifecycle */ - public void start(BundleContext bc){ - /* Here we register the Mbean within the agent */ - ServiceReference sr = context.getServiceReference(MBeanServer.class.getName()); - if (sr!=null){ - MBeanServer server = (MbeanServer)this.bc.getService(sr); - server.registerMBean(this, new ObjectName("TabUI:name=Probe"); - } - } - public void stop(BundleContext bc){...} - /////////////////////////// - // Management interface // - /////////////////////////// - public int getValue(){return 10;} - - /* A getIfc function comes from RemoteIfc interface that enable the manager (remote console) to - a bundle that can communicate whith this probe from a remote URL */ - public String getBundleName(){ - return "http://somewhere/agraphicaltab.jar"; - } -} ----- - -Once the probe is made as a bundle it can be deployed on the remote gateway. -Then a manager (management console) can ask communicate with the gateway agent to manage the probe. - -=== MOSGi JmxConsole architecture - -When a probe is deployed on a remote gateway it is manageable by standard management consoles like JConsole, MC4J... -We have developed our own management console that is able to manage probe in a more dedicated approach. - -The management console is based on a plugin mechanism. -Each plugin is represented as a tab and each tab manages a probe. -The console is launched with two bundles. -Remotegui.jar is the execution framework and remotecomponent.jar contains a sole remote logger service that gets remote notification from gateways. -The screen represented the gateway status after it has been launched.!EmptyConsole.png! -The left panel identifies connected gateways, The upper center panel is an container for tabs from managed gateways, - -The lower center panel contains the remote logger display that shows notifications from remote gateways. -When the user selects a gateway (green flag) the console will do the following actions : - -. Ask all MBeans in the TabUI domain. -. For each of these MBean, get the URL of bundle that provides the tab. -This is done through the call to getBundleName( ) method in RemoteIfc interface. -. Install the bundle on the gateway - -For instance if the user selects the green point he gets the following tabs. - -!TabbedConsole.png! - -4 probes have been deployed on the remote gateway and 4 graphical tabs have been installed. - -=== Graphical tab integration - -When developing a probe one shall provide a corresponding MOSGi tab. -It should follow these guidelines. - -* It should be a bundle in order to be remotely installed on the console -* It should implement Plugin interface with is the jmxconsole container interface specification. - -The plugin is mainly conform to the java beans specification development. -The jmxconsole acts as a bean container and each tab is a bean in this infrastructure. -This is the general architecture of a Tab class.!MOSGiConsoleTabClasses.png! - -The plugin interface has the following structure: - - package insa.jmxconsole.gui.service; - import java.awt.Component; - import java.beans.PropertyChangeListener; - public interface Plugin extends PropertyChangeListener{ - public String getName(); /* The name of the tab */ - public Component getGUI(); /* This is called by the container to get the graphical component */ - public void registerServicePlugin(); /* This is called by the framework when a new gateway is selected */ - public void unregisterServicePlugin(); - /* see before */ - public String pluginLocation(); /* This a unique identifier of the plugin */ - /* These are constants that enable communication between container and plugins. They are treated in the - propertyChange function brought by the javabean API */ - public static final String NEW_NODE_SELECTED="newNodeSelected"; - public static final String NEW_NODE_READY="newNodeReady"; - public static final String NEW_NODE_CONNECTION="newNodeConnection"; - public static final String EMPTY_NODE="emptyNode"; - public static final String PLUGIN_ADDED="pluggin_added"; - public static final String PLUGIN_REMOVED="pluggin_removed"; - } - -Implementation tabs are provided as open-source code. -You can find various implementation of this interface in felix repository in the _mosgi.managedelements.xxx.tab_ elements. - -=== Function call sequence - -The next figure presents a function call sequence when using MOSGi framework.
