RFP and RFC Status

ACTIVE

RFC 236 - OSGi Interworking Service for oneM2M Networks

Defines the OSGi interworking service for oneM2M networks that enabling OSGi-based devices to interoperate with oneM2M devices

RFC 235 - Abstraction Layer with oneM2M Smart Device Template

This document describes the need of using the oneM2M device abstraction layer in an OSGi platform, a comparison with the current OSGi Device Abstraction Layer, the major requirements for the integration of oneM2M standard concepts and a technical solution for an implementation on OSGi technology.

RFC 234 - Framework Tracing

Currently there is no API to define how the framework should do tracing; code launching a framework needs to know implementation details when it wants to configure this with the launching API. This RFC proposes a framework implementation independent way to be used by the framework for tracing.

RFC 233 GPU capabilities

More and more GPU hardware is used to accelerate computations in applications compared to running on a CPU. In order to know whether or not an OSGi framework has access to GPU hardware and a GPU accelerated bundle can be deployed, this RFC provides a namespace with capabilities and requirements.

RFC 229MQTT Protocol Adapter

In the IoT domain there is a widespread of communication protocols available for letting devices interact with eachother. A popular publish-subscribe protocol for communicating with IoT devices is MQTT. This RFC focuses on ways to integrate the MQTT protocol with OSGi. The goal to bridge MQTT to the existing OSGi EventAdmin.

RFC 193 CDI Integration

While OSGi services are very powerful, some still find it challenging to use them effectively. This RFC looks at how CDI can be used to interact with the OSGi service layer. The intent is to bring the popular CDI programming model to OSGi as a way to interact with OSGi services. It will provide the convenience of CDI and allows developers familiar with the CDI technology to reuse their skills in an OSGi context.

DESIGN COMPLETE

RFC-232: JPA Service Enhancements

The OSGi JPA Service provides a modular mechanism for using JPA within an OSGi framework. Version 1.0 of the JPA Service was introduced in the OSGi Enterprise Specification Release 4.2. Since this time there have been new versions of the JPA Specification, and new related OSGi specifications such as the Transaction Control Service. This RFP gathers updated requirements to ensure the continued usefulness of the JPA service.

RFC 231: Remote Service Intents

OSGi Remote Services are a powerful, flexible way to expose OSGi services from one framework into another. The model allows great flexibility in the serialization, transport and wire formats that are used by the Remote Services implementation, meaning that Remote Services can be used across many sorts of distributed system. Unfortunately this flexibility offers few guarantees about the types of object that may be safely used in the Remote Service API. This RFC aims to provide some basic remote service intents that can be relied upon to provide support for simple synchronous and asynchronous remote services.

RFC 230 Promise Update

Updates to the Promise specification.

RFC-227 Configuration Admin Updates

Updates to Configuration Admin for R7.

RFC 224: Resolver Service Updates

Updates to the Resolver Service for Release 7.

RFC 223: Http Whiteboard Updates

Updates to Http Whiteboard for Release 7

RFC 222: Declarative Services Updates

Updates to Declarative Services for Release 7.

RFC 221 Transaction Control

The OSGi Alliance Enterprise Expert Group has developed adaptations of the JDBC, JTA, and JPA Java EE specifications. These resulted in a disparate set of services, that is they provide factory services (DataSourceFactory and EntityManagerFactoryBuilder) and a JTA Transaction service. However, the native OSGi model is to be able to use configured instance services so they can directly be injected through DS and used together. This RFC proposes a client transaction management specification that fully leverages the OSGi service model and Java 8, whilst also making it easy to use resources as part of the transaction.

RFC 220 Bundle Annotations

In the light of the enRoute project bnd pioneered the use of build time annotations to generate manifest headers. The use of annotations makes it easier to manage manifest headers per component, significantly minimizes errors, and leverages the Java type system to provide content assist in IDEs.

RFC 219 LogService Update

Logging is a crucial component to discover software bugs in a software system. The OSGi Log Service was the first compendium service and the Java eco-system gained over time many different log solutions: Log4j 2, Logback, Java Util Logging, etc. Since the OSGi Log Service was not further developed, the API does not take advantages of any of the new features in Java and looks very simplistic in comparison to mainstream Java. This document seeks to improve the Log Service API and add additional roles to upgrade it to Java 8.

RFC-218 Configurator

OSGi Configuration Admin is a slightly pedantic but highly effective flexible standardized model to configure applications. This RFC seeks a solution to carry configuration information in a bundle.

RFC-217 JAX-RS Services

The RESTful service model has existed for several years as a simple means of providing CRUD (Create, Read, Update, Delete) style services using existing HTTP standards, request types, and parameter passing. As REST services grew in popularity they were adopted into Java EE as the JAX-RS standard. This standard was designed to be standalone, with minimal dependencies on other Java EE specifications, and to provide a simple way to expose HTTP REST services producing JSON, XML, plain text or other response types, without resorting to a servlet container model. This RFP aims to enable JAX-RS components and applications as first-class OSGi citizens, making it easy to write RESTful services in a familiar way, whilst simultaneously having access to the benefits of the modular, service-based OSGi runtime.

RFC 216: Push Streams

The OSGi specifications have described how to distribute OSGi services across VM boundaries now for a number of years. However many OSGi services are synchronous in their nature. Many of today's business applications require asynchronous distributed communication mechanisms. While the OSGi Event Admin specification describes an asynchronous eventing model inside the Java VM this does not address event distribution to other Vms. In addition, while the OSGi Asynchronous Services specification defines mechanisms for asynchronously invoking services, it does not address some concerns specific to eventing. This RFP aims to address the issue of Distributed Events in an OSGi context.

RFC 215 - Object Conversion

Java is a type safe language that can be used to create applications that are easy to navigate in an IDE and that significantly reduce time to write tests. However, there is a tendency in Java to bypass the type system because it is often deemed easier to use strings instead of proper types: logging, JAX-RS, configuration, records, etc. This RFP investigates the issues that surrounding the use of type safe interfaces and DTOs where traditionally properties and other string based solutions are used.

RFC 213 - Serial Device Service

This document defines the Java API to communicate with Serial devices on the OSGi platform.

RFC 212 - Field Injection for Declarative Services

The component model defined by Declarative Services is using a method based approach for injecting referenced services into the component. Compared to other component models this requires the developer to write the same boiler plate code for each and every reference. This RFC aims to provide a technical design to add field injection to Declarative Services. This RFC focuses on field injection for Declarative Services.

RFC 211 – Event Admin Update

That RFC document covers some new Event Admin enhancements.

RFC 210 - Device Abstraction Layer Functions

Defines a core set of functions to RFC-0196 Device Abstraction Layer. They provide an interoperability between the different specific domains.

RFC 209 – Network Interface Information Service

This document defines the Java API that provides the information of network interfaces in an OSGi environment. The bundles can get not only information of network interfaces but notification when the configuration of network interfaces to be changed to use this API.

RFC 208 Metatype Annotations

This RFC introduces annotations for the Metatype specification which can be use to annotate Java types so that tools can generate Meta Type Resources from the type declaration.

RFC 206 - Asynchronous Services

The OSGi service registry is used by bundles to collaborate using loosely coupled services, registered with one or more public interfaces that can be called. OSGi services are, like most Java objects, normally designed to be called synchronously. There are, however, often significant advantages that can be

realized by clients when they execute one or more parts of their operation asynchronously. This RFC provides a generic mechanism that allows existing OSGi services with a synchronous API to be invoked asynchronously without requiring them to be modified.

RFC 204 - Framework Extension Activators

The OSGi Core specification version 4 introduced framework extension bundles as a way to deliver optional parts of the Framework implementation. The OSGi Core specification version 4.2 and 4.3 introduced various framework hooks that allowed bundles on top of the framework to augment certain behaviors of the framework. For example, the service, bundle and resolver hooks together may be used to implement a scoping model for isolating groups of bundles with in the same framework. In many scenarios it is desired to have these hooks be available (registered) as early as possible to guarantee consistent behavior for the complete lifecycle of the framework. Currently there is no standard to ensure the hook implementations are available when a framework is initialized because hook implementations are registered as services by normal bundles which can only be activated after a framework has been initialized. This RFC specifies extension bundle activators which can be used by a framework extension to hook into the initialization process of the framework, including the ability to register framework hook services.

RFC 203 – Remote Service Admin 1.1

The Remote Service Admin specification is lacking a mechanism to notify consumers of changes to an endpoint. The EndpointListener interface defines endpointAdded and endpointRemoved callbacks, but no mechanism to convey that an endpoint has been modified, for example because the service properties of the backing service have changed. This RFC addresses this issue.

RFC 202 USB Device Category

This document defines the device category for USB devices information in OSGi.

RFC 201 Subsystems Update

This RFC proposes various updates to the Subsystem Service Specification.

RFC 200 Resource Monitoring

OSGi applications need hardware and software resources to perform their features. As these resources are limited, they have to be fairly shared between applications in order to preserve the global quality of service. Up to now, OSGi platforms delegate the resource monitoring features to the Java Virtual Machines themselves or took advantage of some external Java Resource Monitoring solution like JVM TI or JMX. Unfortunately, all of these resource monitoring solutions provide features at the Object or Class level. This granularity is too low level to easily monitor resources consumed by OSGi applications.

This specification proposes a Resource Monitoring solution fitting with OSGi model and constraints. Resources (CPU, memory, disk storage space, I/O) are monitored per bundle and can be enabled and disabled at runtime. When a bundle consumes too many resources, the Resource Monitoring solution notifies interested applications and limits resource allocations.

RFC 199 EnOcean Device Service

This specification defines the Java API to discover and control EnOcean devices on the OSGi platform and according to OSGi service design patterns. This API maps the representation model of EnOcean entities defined by EnOcean Equipment Profiles standard into Java classes. OSGi service design patterns are used on the one hand for dynamic discovery, control and eventing of local and networked devices and on the other hand for dynamic network advertising and control of local OSGi services.

RFC 198 System Bundle Framework Hooks

The OSGi Core specification version 4.2 introduced service hooks and version 4.3 introduced bundle, resolver and weaving hooks. The service, bundle and resolver hooks together may be used to implement a scoping model for isolating groups of bundles with in the same framework. These framework hooks can control the visibility of services, bundles and generic capabilities for the system. The current specification is silent on the ability to isolate or hide services, bundles and capabilities from the system bundle. This implies that framework hooks are able to hide services, bundles and capabilities from the system bundle. This RFC specifies the behavior of framework hooks when acting upon the system bundle.

RFC 197 OSGi Package Type Annotations

OSGi may soon move to full Java 5 language support include annotations. Some standard OSGi annotations, such as package version, type role, etc., need to be defined. This RFC proposes an initial set of standard OSGi package and type annotations.

RFC 196 Device Abstraction Layer

Defines a new device abstraction API in OSGi platform. It provides a simple access to the devices and their functionality.

RFC 195 Service Scopes

Add prototype service scope to OSGi Service Layer

RFC 192 ZigBee Device Service

This specification defines the Java API to discover, control and implement ZigBee devices on the OSGi platform and according to OSGi service design patterns. This API maps the representation of ZigBee entities defined by ZigBee Cluster Library into Java classes. OSGi service design patterns are used on the one hand for dynamic discovery, control and eventing of local and networked devices and on the other hand for dynamic network advertising and control of local OSGi services implementing this API.

RFC 191 Weaving Hook Enhancements

Addresses various enhancements to the Weaving Hook Service specification.

RFC 190 Declarative Service Enhancements

Declarative Services provide functionality to implement Dependency Injection programming in OSGi based applications. This RFC proposes describes adding an additional management API, better support of property handling through annotation interfaces, new features introduced in Configuration Admin 1.4 and 1.5, service scopes, and defines an extender namespace.

RFC 189 HTTP Service Updates

The current Http Service specification is based on Servlet API 2.1. As such it misses newer functionality such as Servlet Filters or event listeners. In addition use of the service does not support the recent whiteboard pattern approach. This RFC lists requirement to create a new Http Whiteboard Service specification.

RFC 188 Native Namespace

The generic capabilities and requirements model in OSGi provides a common way to express most dependencies specified by the OSGi Core specification. Namespaces have been defined for most all of the standard OSGi dependencies. For example, osgi.wiring.package, osgi.wiring.bundle, and osgi.wiring.host. For the OSGi Core R5 specification we also introduced the osgi.ee namespace to handle the Bundle-RequiredExecutionEnvironment dependency. The only standard dependency from the Core specification that is missing a generic namespace is for native code as defined by the Bundle-NativeCode header. This RFC provides a new standard namespace for defining bundle native code dependencies

RFC 187 Complex Repository Requirements

The generic capabilities and requirements model in OSGi provides a powerful constraints-based resource selection model, however the API for this is limited to constraints within a single namespace essentially limiting queries to a single type of information. This RFC aims to provide a technical design for the relevant requirements as stated in RFP 148. This RFC focuses on generic Requirements in the context of the Repository Service API

RFC 185 Data Transfer Objects

Define a set of data-only objects to represent runtime objects. The types will have limited behavior to support easy serialization and use by management agents to communicate with external systems

RFC 183 Cluster Information

The Computing Cloud often provides a highly dynamic environment where the load of a system might change, the topology of the cloud nodes might change or the requirements on the application may change at runtime. This document describes an OSGi cloud environment where nodes and capabilities can be discovered dynamically through OSGi Services and the deployment topology can be changed at runtime to react in changes in the observed characteristics, topology or requirements. An OSGi cloud can also be repurposed which can save network bandwidth as VM images only need to be sent to cloud nodes once.

RFC 182 REST Interface

This RFC describes a REST interface for managing OSGi framework instances, e.g., in cloud computing setups

RFC 180 Portable Java Contracts

One of the promises of OSGi is the ability of a bundle to know that the runtime provides the capabilities it needs. At one level this is based on the code package required, however this is insufficient. Packages evolve over time with new methods, interfaces and classes being added. The provider of a package can express the version of the package so client can select the minimum version it needs. Making use of semantic versioning also allows the provider to make breaking API changes without affecting client bundles. This is the promise, however the Java platform itself does not version its packages. This RFC defines how bundles using Java packages can express dependencies on particular versions of Java packages.

INACTIVE

RFC 226 – Scheduling

This RFC defines a time service that can provide time aspects like delays, timeouts, and periodic scheduling with the option to have cron like scheduling using the whiteboard pattern. The solution takes advantage of the OSGi Promise API and the date-time API introduced in Java 8.

RFC 225 - Web Resources

Web Applications require more and more access to web resources like Javascript files. These web resources can be served from content delivery network over the Internet but this has implications for HTTP/HTTPS access, security and availability (especially in the future). Therefore, applications serve these web resources from their own server. The OSGi environment is a perfect environment to handle these web resources. This RFC defines how to package Web Resources in an OSGi system.

RFC 214: Distributed Eventing

The OSGi specifications have described how to distribute OSGi services across VM boundaries now for a number of years. However many OSGi services are synchronous in their nature. Many of today's business applications require asynchronous distributed communication mechanisms. While the OSGi Event Admin specification describes an asynchronous eventing model inside the Java VM this does not address event distribution to other Vms. In addition, while the OSGi Asynchronous Services specification defines mechanisms for asynchronously invoking services, it does not address some concerns specific to eventing. This RFP aims to address the issue of Distributed Events in an OSGi context.

RFC0207 - Native OSGi

No abstract

RFC 184 Blueprint 1.1

Update Blueprint Container to 1.1 with some features requested via bug reports or directly from users.

RFC 166 Blueprint Bean Interceptors

This RFC describes the requirements and solution for Blueprint Bean Interceptors as an extension of the Blueprint container specification.

RFC 164 Blueprint Transactions

Blueprint declarative transaction provides container managed transaction for blueprint beans which enables application developers to focus on the application logic and provides better separation of application and infrastructure code

RFC 156 Blueprint Configuration Admin support

This RFC extends the Blueprint service to support Configuration Admin.

RFC 155 Blueprint Namespaces

This RFC extends the Blueprint service to support user defined namespaces in Blueprint configuration files

WITHDRAWN

RFC 228 Bulk Configuration Updates

When several configurations have related updates, processing all the updates at once can considerably reduce churn. This behavior can be implemented by a Coordination. The configuration management agent that updates the configuration starts a Coordination, and the consumer of the updates such as DS registers as a participant in the Coordination and tracks the configuration events received during the Coordination. After completion the consumer can process all the updates in a suitable order. Labeling the Coordination with a well known name enables consumers to detect that the Coordination is actually involved in configuration. ManagedService and ManagedServiceFactory can be registered with a similar (or identical) well known name so config admin itself can implement this behavior on their behalf.

RFC 205 - Versions as Scalar types

No abstract

RFC 194 EJB Integration

The Enterprise JavaBeans architecture (EJB), part of JEE technology, is a managed server-side component architecture for the construction of enterprise applications[4]. While OSGi moves towards enterprise, it has long been interest in integrating EJB into OSGi. This RFP describes the requirements for integrating EJB into the OSGi framework with the intention that the current EJB developers should be able to reuse their current skills and assets to develop and deploy EJBs that run in and exploit the OSGi framework.