OSGi Enterprise Spec 4.2 released

Posted by Alex Blewitt on Mar 23, 2010

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

Modularity ,

Web Frameworks ,

SaaS ,

Java ,

Network Programming ,

Web Services

Today, the OSGi announced the release (pdf) of the Enterprise OSGi 4.2 specification, along with the corresponding JavaDoc.

The Enterprise OSGi spec covers features that are useful to many developers (like Remote Services and JDBC) as well as more enterprise-level services (like JNDI, JTA and JPA).

To understand how these OSGi services fit in – and avoid the “OSGi is too complex” rant – it's useful to take a look at how the specs work. Each OSGi service is provided by a package (or packages) with a specific version number, which is independent of the OSGi release number. For example, OSGi 4.2 contains the OSGi org.osgi.framework version 1.5, whilst OSGi 4.1 contained the OSGi org.osgi.framework version 1.4. Packages are versioned using the OSGi versioning scheme, which uses a major number to signify backward compatible breaks, minor numbers to signify forward compatible enhancements, and micro numbers which add no new functionality other than bug fixes etc.

At its core, OSGi is only 27 Java types, including 14 interfaces and 7 security permissions. Everything else is optional. Furthermore, each optional dependency is represented as its own package (with its own independent version numbering scheme) with the result that some, like Declarative Services, are only on version 1.1 and others, like org.osgi.service.url are still on 1.0. Services are also occasionally described as their chapter number in the OSGi specs; anything in the Enterprise or Companion specifications tend to start from 100 onwards.

As a result, the OSGi Enterprise Spec is a set of additional packages that can be used (independently of others) in any application, whether or not it's an Enterprise application. There's even some overlap; for example, the Remote Services (chapter 13) is the same in both the Enterprise spec and also the OSGi 4.2 compendium; they can be identified as the same since they describe the same package/version combination. So, with the preamble out of the way, what does the OSGi Enterprise spec provide?

Remote Services Admin

Although Remote Services (13) was defined in the OSGi 4.2 compendium, it's also included in the OSGi Enterprise spec since it is referred to by the Remote Services Admin. (As a side-note, it's been given the relatively low chapter number of 13 so that it can be integrated in with the OSGi core services specification at a later date.)

Remote Services Admin (122) provides standard hooks to listen for remote services coming and going, as well as to register them with a specific set of properties. This permits the development of topology managers which can be used to control what happens in an endpoint failover, or when services come and go in a distributed environment. For example, ECF provides a number of different discovery providers (such as ZooKeeper and ZeroConf) that can be used to announce the presence of services on a network; there is a defined endpoint schema which can be used to identify where the endpoint resides (and using which service). It's very likely that OSGi-provided enterprise servers (like Eclipse Virgo or Gemini) will provide such administrative functionality, and value-add providers who sell commercial tools on top of Equinox (like Paremus Service Fabric) will provide their own user interfaces on top of the basic admin service.

Web Applications Spec

The Web Applications Spec provides a way of running ordinary WAR-like applications inside an OSGi environment. The difference is that these are Web Application Bundles (or WABs), combined with dependency management from OSGi's bundle resolution mechanism.

Version 1.0 of the WebApp Spec declares a dependency on Servlet 2.5 and JSP 2.1. When a bundle is deployed into an OSGi Web Container, the Servlets are registered with a hard-coded Web-ContextPath, defined in the manifest. This means that it's not possible to associate the same bundle with multiple URL paths, or change them without modifying the installed bundle. (It also implicitly prevents multiple WABs with the same bundle but different version numbers being installed in the same runtime, without the path being modified.)

Lessons learned during the use of the Web Application Bundle type will no doubt be addressed in a future OSGi specification. Fortunately, since such services are versioned, it will be possible to evolve these after the fact.

JDBC, JNDI, JTA and JPA services

JDBC services are often defined externally to an application, through the use of properties or some other global singleton definition. This is not acceptable in a dynamic environment where things can come and go at runtime; in addition, JDBC services are often discovered through JNDI, which is an ugly global singleton factory for accessing (static) configuration information in a non-class dynamic way.

The OSGi JNDI Service (126) provides a mechanism for client code to access a JNDI context, without having to declare a static InitialContext ahead of time. This permits OSGi to provide a backing OSGi initial naming context, which can be swapped out at runtime when required. Note that this is not a type of InitialContext, but rather, a type that implements Context. To acquire the OSGi service, a org.osgi.service.jndi.JNDIContextManager must be obtained (e.g. injection through declarative services, acquisition via Blueprint service or a specific service lookup), from which a context can be acquired using the appropriate factory messages. As a result, it will be possible to write code which works either inside an OSGi runtime or outside, by doing:

// Injected with DS or @Inject
private Object jndiService = null;
...
Context ctx = null;
if( jndiService != null )
  ctx = (JNDIContextManager)jndiService.newInitialContext();
else
  ctx = new InitialContext();

JNDI can be used to discover a JDBC service (125), in a similar way to accessing DataSource objects at the moment. Alternatively, specific database connections/drivers can be requested using the DataSourceFactory.

The JTA (123) and JPA (124) services both provide mechanisms for using transactions and persisting data to a database. Unlike Hibernate, with its fixed set of classes, JPA is able to handle classes loaded from multiple bundles and auto-wire the dependencies in the bundle that provides those data structures. This will permit two bundles, each with different versions, to be loaded simultaneously and persisted to different databases. In addition, both the JTA and JPA services can make use of the JDBC service to acquire a connection to a database.

OSGi DevCon London, covered previously, gave a good description of what to expect with the JPA release; and the fact that the EclipseLink is the reference implementation for non-OSGi JPA as well as being the foundation for the OSGi JPA aware implementation (along with backwardly compatible factory methods) means that this approach will give seamless results either inside or outside an OSGi environment. There was a talk at EclipseCon on JPA and OSGi usage.

JMX interface

JMX has become a de-facto standard for remote management of any Java application. The JMX service in OSGi permits the OSGi services to be represented as JMX MBeans(FrameworkMBean, BundleStateMBean, UserAdminMBean etc.). This will provide a standard interface for remote management of OSGi consoles – such as Scott Lewis' Amazon in the Cloud OSGi runtime image – to be introspected remotely.

SCA Configuration Type

The SCA spec (129) provides a means to describe components and how they can be arranged/wired. These permit files, deployed in OSGI-INF/sca-config/*.xml to define how services should be wired up. A service could choose to be wired over different transports (RMI, WebServices) as well as different configuration parameters (for example, ensuring that a transport ensures confidential or integral intents). Future tooling will help with the creation of the SCA documents; the important definitions are all defined within the specification (and delegated to the Oasis SCA specification).

Other services

The enterprise specification also includes a number of other services, which are taken from the OSGi 4.2 Compendium document. They are included within the Enterprise Spec as a selection of service which may be implemented in an application server, such that the server can claim complete (or partial) implementation of those specifications. Here is a list of the services included but that have not changed since the OSGi 4.2 compendium:

• Log Service (101), version 1.3
• Http Service (102), version 1.2
• Configuration Admin Service (104), version 1.3
• Metatype Service (105), version 1.1
• User Admin Service (107), version 1.1
• Initial Provisioning (110), version 1.2
• Declarative Services Specification (112), version 1.1
• Event Admin (113), version 1.2
• Blueprint Container Specification (121), version 1.0
• Tracker Specification (701), version 1.4
• XML Parser Service (702), version 1.0

1. Back to top

   My interest in OSGI was peaked by the title

   by Levi Strope

   But you lost me by the 3rd paragraph.

   Reply

2. Back to top

   Why OSGi URL Scheme

   by Tuomas Kiviaho

   I skimmed through to the JNDI section and wondered why a special OSGi scheme is created instead of using existing LDAP scheme.

   Reply

3. Back to top

   OSGI

   by Luís Carlos Moreira da Costa

   My interest in OSGI is developer one container to server web services!
   Excellent article Alex!

   Reply

• Older >