Earlier this week a new OSGi Early Access Draft was made available. A lot of new work is currently underway in both the Enterprise Expert Group (EEG) as well as the Core Platform Expert Group (CPEG) and in this document you can see where things currently are. Below you can find a short summary of each of the RFCs to get an idea what they are about.
RFC 180 - Portable Java Contracts. This RFC is about how you import technologies that originated in the JCP and specifically how these are versioned. A previous version of this RFC was included in the last EA draft and you can find more information on what RFC 180 is about in this posting:
http://osgithoughts.blogspot.com/2012/10/new-osgi-eeg-early-access-draft.html
RFC 182 - Defines a REST Management Interface for OSGi Frameworks. A number of remote management specifications already exist for OSGi, but especially in the context of Cloud Computing a REST-based management API is highly desirable. This is defined in RFC 182.
RFC 183 - Cloud Ecosystems. This RFC defines how a number of OSGi frameworks can work together in a Cloud Computing context, or other environment where multiple frameworks collaborate together. It describes how OSGi frameworks and their associated node-related meta-data can be discovered within the Ecosystem. It also covers how these frameworks can communicate across nodes to provide a fluid environment where a logical application is spread across multiple nodes and its components and services can easily be moved from one VM to another to deal with changes in machine load, available resources and other constraints.
RFC 184 - Blueprint 1.1. This RFC defines a collection of updates to the Blueprint specification that include the ability to switch off damping, change the behavior of the grace period and other changes.
RFC 185 - Data Transfer Objects. OSGi has always provided mechanisms for remotely managing its technology, but as the number of specs and the number of management technologies both grew maintaining coverage across all specs for all management technologies became a challenge. Data Transfer Objects provide a means for an OSGi specification to provide information suitable for a management agent in a technology-neutral style. The idea is that every OSGi spec defines its DTOs and that this can then be easily, possibly mechanically, mapped to most management technologies, so that they are kept up-to-date with a lot less effort than what was previously required. RFC 182 builds on top of these DTOs, other management specs (such as JMX) will most likely be updated in the future to take advantage of them too.
RFC 187 - Complex Repository Requirements. The Enterprise R5 specification defines the OSGi Repository spec. This was really the first Bundle Repository specification, although the Apache Felix project did have an OBR project before. The OSGi Repository is a simple yet powerful spec, which defines an API that allows one to find resources based on capabilities. RFC 187 adds a small enhancement to this specification which makes the querying mechanism even richer. It allows the combination of multiple capability namespaces into a single query so that you can express things like: I need a bundle that exports package org.foo and has license X. Or I need a bundle that provides the Declarative Services capability and has passed our company's internal QA process.
RFC 188 - Native Namespace. This specification adds a capability namespace for the generic OSGi Capabilities and Requirements model to represent the Bundle-NativeCode header. While other requirements in the Bundle Manifest, such as Import-Package or Fragment-Host can already be described using generic requirement namespaces, the Bundle-NativeCode did not have such a mapping yet. This RFC addresses this issue.
RFC 189 - HTTP Service Updates. The HTTP Service specification has been around for a long time and has seen many projects using it. However, it was long due an update to modernize it in relation to the Servlet Specification and the way people generally use OSGi Services. This RFC brings the HTTP Service spec up-to-date. It makes it possible to use Servlet Filters, adds the ability to use the Whiteboard pattern and provides additional configuration mechanisms.
RFC 191 - Weaving Hook Enhancements. This RFC enhances the Weaving Hooks allowing consumers to find out in what stage the weaving of a certain class is. In particular it helps the Subsystems specification to react appropriately to any imports that were added dynamically during the weaving phase.
RFC 193 - CDI Integration. This RFC focuses on how CDI beans can be deployed in OSGi and how these interact with the OSGi Service Registry. It brings annotation-based interaction with OSGi Services based on the popular CDI annotations. As with any OSGi component technology that uses the Service Registry, it will allow you to mix-and-match them. So a CDI bean can be injected by a service created in a Blueprint component. Similarly a simple Declarative Services client could obtain a service that was created in a CDI bean, and so on...
RFC 195 - Service Scopes. Up until now the OSGi Service Registry has supported two models. Either a registered service instance is shared across all consuming bundles or each distinct client bundle gets a separate instance. Recent work in the context of CDI and EJB integration (an OSGi/EJB RFC is being worked on but didn't make this draft) indicates that additional models are desirable. For example where a new service instance is returned every time the service is obtained, to fit stateful session models. This RFC describes additions to the OSGi Service Registry that support these models.
You can find the full documents in the EA draft at the following link: http://www.osgi.org/Download/File?url=/download/osgi-early-draft-2013-03.pdf
If you are interested in becoming involved in any of these RFCs, join our efforts: http://www.osgi.org/Join. If you already work for a member company, contact the EEG or CPEG chairs for more information on getting involved see http://www.osgi.org/EEG or http://www.osgi.org/CPEG.
Also note that some of these topics will be discussed at EclipseCon/OSGi DevCon Boston March 25-28. For more information see here: http://blog.osgi.org/2013/03/boston-calling.html
No comments:
Post a Comment