|
5.4.2 Eclipse 3.1.2 and OSGI/Equinox RuntimeWebSphere Application Server uses the Eclipse 3.1.2 version of the Eclipse/OSGI environment for its runtime infrastructure to manage the loading of its main infrastructure components. Although this adds complexity, it allows IBM to provide extensions to the core WebSphere Application Server product (such as through the new feature packs) without affecting the core code. IBM, as well as vendors, have stated that many of their infrastructure packages (including some Tivoli products, the IBM Systems Console, and so on) will in the future be Eclipse/OSGI-based. Figure 5-13 illustrates Eclipse and OSG/Equinox in the WebSphere Application Server runtime infrastructure.
Figure 5-13 Eclipse and OSGI/Equinox in the WebSphere Application Server runtime infrastructure To understand how this works, look at the "configuration" directory for the WebSphere Application Server installation and examine the config.ini file that lists what base components of Eclipse are required to get the internal WebSphere Application Server extension registry up and running from the Eclipse 3.1.2 runtime. Then examine the startup scripts for WebSphere Application Server to see the Eclipse runtime JAR files being accessed. Finally, copy the com.ibm.ws.runtime_6.1.0.jar file from a WebSphere Application Server installation and open its plugin.xml file to see the component configurations used to create the underlying WebSphere Application Server product. With the later Eclipse environments, the similar OSGI (formerly the Open Service Gateway Initiative) platform R4 services and bundles are also supported, using a framework implementation called Equinox. Eclipse allows plug-ins to provide runtime extensions based on what they find around them, and OSGI adds the dynamic-aware behavior to control runtime addition and removal of bundles. All of this functionality allows applications based on it to be extended and modified without a restart. OSGI started out as a consortium working on embedded and mobile initiatives, and then defined the dynamic platform and how the applications would group Java code, native code, and other resources to form the deployable bundles. A manifest file (MANIFEST.MF) describes the bundle contents, what its dependencies are, what packages it exports, and if it is to be initialized before the first class it contains is accessed. In earlier, non-Equinox Eclipse environments, the extensions and extension points are all covered in the plugin.xml file. The current WebSphere Application Server 6.1 runtime is based on the hybrid Eclipse 3.1.2 implementation, so both mechanisms are used by different parts of the environment. In OSGI, bundles detect being started and stopped to perform initialization and shutdown in a bundle activator, and register services in a service registry. A service is simply a Java class that usually exposes a well-known interface that is made available for others to bind to and use. The current OSGI Release 4 standard also defines other features of the platform for use on the server side, such as a lightweight HTTP listener. The current Eclipse implementation of OSGI is Equinox, which is used by WebSphere Application Server. However, there are other implementations of the standard such, as Apache Felix. For more details, visit: http://www.osgi.org The dynamic extensions and services mechanisms allow the WebSphere Application Server environment that runs on top of Eclipse to be dynamically extensible without changing the core WebSphere Application Server code. Code, including that from standard J2EE applications with the appropriate additional code to support the Eclipse registry and extension mechanism, uses the registry to find what it wants to extend and then adds its own code. IBM is now providing feature packs to add new features to WebSphere Application Server 6.1 without changing the base code, and this mechanism is key to this type of extension. Platform-specific features are also being added, which will allow new AIX features to be taken advantage of. This is best seen with the startup of the WebSphere Application Server containers. WebSphere Application Server effectively has an internal Eclipse registry, and one that is accessed using Java Naming and Directory Interface (JNDI). The internal one is core to the Eclipse platform itself, with some low level WebSphere Application Server Eclipse plug-in code.
According to the "Official Eclipse 3.0 FAQs", the simplest Eclipse application (as opposed to an OSGI bundle or plug-in), consists of the following elements:
The startup for this base platform is controlled by a config.ini file that is found in the /configuration directory under the WebSphere Application Server installation directory structure. Here, you can examine the startup scripts, the documentation, the logs, and drill down into the JAR file contents. Remember, a JAR file is just a special type of zip file, and you can view the contents of zip files using Windows Explorer or other similar browsing tools. You can refer to the Eclipse startup and registry documentation for more information about this subject: http://www.eclipse.org Understanding this task can help in diagnosing startup problems. You can refer to WebSphere Application Server documentation to some extent, with much of the rest available as Open Source code. WebSphere Application Server uses the same Eclipse 3.1.2 runtime for AIX/Motif, which can be downloaded in binary or source form: http://www.eclipse.org In order to allow application vendors to provide their own extensions and plug-ins, a public version of the Eclipse registry is accessible via JNDI, which exposes the components available for public use and extension. |
