The document summarizes the OSGi 4.2 Enterprise Specification, which includes specifications for component models, distributed services, database access, web applications, and other supporting technologies. Key aspects include Blueprint for easier OSGi development, Remote Services for exposing and consuming services over the network, JPA and JDBC for database access, and integration with Java EE technologies like JNDI, JTA, and JMX. Examples of using these specifications include the Apache Aries Trader application and isolated examples from implementing projects. Future work may include specifications for subsystems, applications, package management, and asynchronous messaging.

1. What's new in the OSGi 4.2 Enterprise Specification
David Bosschaert, 2010

2. History
● EEG formed early 2007
● Work areas identified and work started
● Work areas:
● Distributed Services
● Developer Support / Spring DM
● JEE – related specifications
● Remote Services & Blueprint specs part of 4.2
core/compendium release summer 2009
● Culmination of the work done in
4.2 Enterprise Release, Q1 2010

3. 4.2 Enterprise
Specification
Component Models Naming, Management
● Blueprint ● JNDI
● Declarative Services ● JMX
Distributed Services Database Access
● Remote Services ● JDBC
● Remote Services Admin ● JPA
● SCA Configuration Type ● JTA
Web Applications Supporting Technologies
● Http Service Spec ● Events, Config Admin, User
● Web Container Spec Admin, Trackers, ...

4. Blueprint
Blueprint makes developing for OSGi easier.
● Create Blueprint Components
● Based on ideas from Spring Dynamic Modules
● Blueprint Component ≈ Spring DM Bean
● Inversion of Control
● Dependency on other components or OSGi Services
● Register components as Services

5. Blueprint
example Bundle
component.xml MyComponent.java
<blueprint xmlns="..."> package org.example.test;
<reference id="logSvc"
interface="org.osgi.service.log.LogService"/> import org.osgi.service.log.LogService;
<bean id="myComponent" public class MyComponent implements MyInterface
class="org.example.test.MyComponent" {
init-method="started"> private LogService logService;
<property name="dbURL" private String dbURL;
value="jdbc:foo://bar"/>
<property name="logService" public String getDbURL() {
ref="logSvc"/> return dbURL;
</bean> }
<service ref="myComponent" public void setDbURL(String url) {
interface="org.example.test.MyInterface"/> dbURL = url;
</blueprint> }
public void setLogService(LogService log) {
logService = log;
Blueprint manifest header: }
Bundle-Blueprint: OSGI-INF/blueprint/*.xml public void started() {
logService.log(LogService.LOG_INFO,
"MyComponent started. DB URL: " + dbURL);
}
}

6. Distributed OSGi
Distributed OSGi (RFC 119) split up into three specs:
● Remote Services spec released in 4.2 Compendium
Summer 2009
API to expose and consume remote OSGi Services (service properties)
● Remote Services Admin spec new in the Enterprise
Release
Standardizes the APIs of internal Remote Services components,
allowing mix & match of sub-components (like Discovery)
● SCA Configuration spec
If you want to use SCA metadata for configuration

7. Remote Services
(in brief)
Export a service remotely: Import a remote service:
● Add an extra service property ● With Discovery
public class Activator
implements BundleActivator {
private ServiceRegistration reg;
automatic
public void start(BundleContext bc) {
Dictionary props = new Hashtable();
● With static
props.put("service.exported.interfaces",
"*"); <endpoint-description> files
// optionally, configure some details
// for example
props.put("service.exported.configs",
● All client-side proxies
"org.apache.cxf.ws");
props.put("org.apache.cxf.ws.address", services have
"http://localhost:9090/greeter");
service.imported
reg = bc.registerService(
GreeterService.class.getName(),
new GreeterServiceImpl(), props); property set.
// Greeter Service now accessible
// over network
}
…

8. Remote Service
Admin
Standardizes the API of components under the hood
● Distribution Provider, Topology Manager, Discovery
VM1
creates remote
invocation
Distribution Topology remote Discovery
Distribution Topology service
Discovery network
Provider
Provider instructs Manager
Manager metadata Component
Component
X listens
D
D T
T DP
DP creates X'
X'
a service
by some listens
bundle
Service
Service
Client
Client
Bundle
Bundle
VM2

9. Web Applications
Deploy your webapps straight into an OSGi Framework
Supports .WAR and .WAB files
● Deploy them just like any other bundle
● .WAB primary deployment format
– Is a proper bundle, with BSN, package Imports & Exports, etc...
– Required Manifest header:
Web-ContextPath: /myServlet
● .WARs are turned into a .WAB via a URL handler, e.g.
webbundle:file:///mywebapp.war?Web-ContextPath=/myServlet

10. Web Applications (2)
Support for interaction with OSGi Framework
● Access to Bundle Context from within a Servlet
BundleContext bc = (BundleContext)
servletContext.getAttribute("osgi-bundlecontext");
● Servlet Context registered in OSGi Service Registry
– For every successfully started Web Application

11. JPA
Proper database persistence for OSGi
● Don't use static Persistence class to create an
EntityManager
● Look up EntityManagerFactory or
EntityManagerFactoryBuilder in the Service Registry
● A bundle defining Persistence Units declares this using
the OSGi/JPA header:
Meta-Persistence: OSGI-INF/people-persistence.xml
● Look up Filter
filter: (osgi.unit.name=People)
interface: javax.persistence.EntityManagerFactory

12. JPA (2)
Small example:
EntityManagerFactory emf = … // from OSGi Service Registry
// From here everything is familiar
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
Person person = new Person();
person.setName("David");
em.persist(person);
em.getTransaction().commit();
…

13. JNDI
Access to OSGi from JNDI clients
● Look up OSGi Services and BundleContext through JNDI osgi:
scheme
osgi:service/javax.sql.DataSource
osgi:service/my_service (if service sets the osgi.jndi.service.name property)
osgi:servicelist/javax.sql.DataSource
osgi:framework/bundleContext
Access to JNDI for OSGi Bundles
● Look up JNDI in OSGi Service Registry
– JNDIContextManager Service provides access JNDI Initial Context
– Service registry preferred over calling new InitialContext()

14. JTA
Provides OSGi services in the registry:
● javax.transaction.UserTransaction
● javax.transaction.TransactionManager
● javax.transaction.TransactionSynchronizationRegistry
Supports XA Resources.

15. JDBC
Database Drivers registered in the OSGi Service Registry
as DataSourceFactory objects
● With APIs to create
– javax.sql.DataSource
– javax.sql.ConnectionPoolDataSource
– javax.sql.XADataSource
– java.sql.Driver

16. JMX
● JMX access to the OSGi Framework
● Framework Control (Bundle lifecycle)
● Bundle information
● Service information
● Services supported
● Package Admin
● Configuration Admin
● Permission Admin
● Initial Provisioning
● User Admin

17. Examples?
● Apache Aries Trader
● Leverages
– Blueprint
– Web
– JPA / JDBC
– JTA
– JNDI
http://incubator.apache.org/aries/ariestrader.html
● Besides that lots of more isolated examples can be
found in the various implementing projects.

18. Future EEG work
Besides refinements to current specs...
● Subsystems & Applications
● OBR
● Async communications
● JMS
● Message Driven Components
● Asynchronous Services
● ...

19. Questions?