Tuesday, June 30, 2015

New RFPs under discussion at OSGi

While the Enterprise R6 release is currently in the process of being released, new topics are being worked on in the OSGi Alliance. These topics are currently discussed in RFP documents, which hold the requirements. The plan is to finalize these RFPs by the end of the summer, then we can start on the RFCs, the technical design that will ultimately be the basis for future spec texts.

Below you can find a brief 'elevator pitch' of the currently active RFPs, as discussed in the Expert Groups. For details click on the links that will bring you to the actual text. All documents are available publicly in GitHub here: https://github.com/osgi/design/tree/master/rfps.

The following RFPs are discussed in the context of the Core Platform and Enterprise Expert Groups:
  • RFP 163 Log Service Update - This RFP is about modernizing the OSGi Log Service and making is easier to use. 
  • RFP 164 Authentication and RFP 165 Authorization - Are about providing APIs to integrate various security providers and mechanisms into OSGi for authentication and authorization.
  • RFP 166 Scheduling - Provide a cron-like persistent scheduling API.
  • RFP 167 Manifest Annotations - Adds annotations to generate OSGi Manifest Headers. In particular this will make generating Provide-Capability and Require-Capability headers easier.
  • RFP 168 Configurer - This RFP is about providing a standard way to store OSGi Configuration Admin configuration inside a bundle.
  • RFP 169 Object Conversion - The converter that converts anything into everything. This can be especially useful when working with configuration data or service properties.
  • RFP 170 Managed JPA - Adds Managed JPA to the OSGi JPA integration.
  • RFP 171 Web Resources - This RFP talks about a standard way to provide resource for the web. In particular it's about providing JavaScript libraries and CSS files such as Angular, Bootstrap, D3 etc from an OSGi bundle.
  • RFP 172 Protocols - Create a REST service using OSGi annotations and conventions.
  • RFP 173 JAX-RS - Integration with JAX-RS.

The following RFP relates to the Internet of Things:

Have any thoughts or feedback on these requirements documents? Anyone can post feedback as described at https://github.com/osgi/design#feedback.

Want more direct involvement? If you are interested in participating in shaping these specifications, or writing an entirely new RFP, then become a member. Details on joining can be found here: http://www.osgi.org/Join

Wednesday, June 3, 2015

OSGi Enterprise R6 specifications proposed final draft

The OSGi Enterprise R6 specs are now available as proposed final drafts: http://www.osgi.org/Specifications/Drafts
OSGi members are currently voting on these and once that is done the same text will be released as 'final' specification. Let's dive in to see what's new!

New specifications

  • Promises - Promises are a popular asynchronous programming paradigm regularly used in the JavaScript world. The Promises specification brings a similar asynchronous programming model to Java. It allows you to define a chain of operations that are executed asynchronously, every next step being started once the previous one has completed. For example, let's say you have some code that needs to prepare a download, then find the appropriate mirror and then start downloading, all time consuming operations. This can nicely be modeled asynchronously using promises:
      Promise<InputStream> masterURL =
        prepareDownload().then(p -> getMirror(p.getValue()).

        then(p -> p.getValue().openStream());
    Promises integrate very well with Java 8 lambdas and support monadic programming. They can be used both inside as well as outside of an OSGi Framework.
  • Asynchronous Services - This specification can turn any regular OSGi service into an asynchronous service. It leverages the Promises API as described above and supports turning ordinary services into async ones. It also provides support for developing new services that are specifically implemented to be asynchronous. 
  • REST Management Service - This specification adds remote framework management via REST over HTTP, either using XML or JSON. This is particularly useful in cloud settings where traditional Java remote management via JMX does not work very well. The REST management service can either be invoked directly, or via the Java and JavaScript clients that are defined in the specification. The JavaScript client allows you to use the REST Management service directly from your JavaScript code in the browser. 
  • HTTP Whiteboard Service - OSGi has provided a simple mechanism to register servlets for a long time via the HTTP Service specification. This specification, although widely used, has aged a little. The new HTTP Whiteboard specification supports Servlets, Filters, static resources and Http/Servlet listeners based off the Servlet 3.1 specification. It leverages the OSGi Whiteboard pattern (www.osgi.org/wiki/uploads/Links/whiteboard.pdf) to register them, which effectively means that if you register a Servlet or a Filter as a service, it will be made available by the whiteboard runtime. This specification also includes a wide range of DTOs to allow runtime introspection. 

Updated specifications

  • Declarative Services - This specification has undergone extensive changes bringing several exciting enhancements: new annotations for field injection, a strong-typed mechanism based on annotations for providing configuration and DTOs for introspection. Declarative Services now also support Prototype Service Factories which were introduced in the Core R6 release. Numerous other small improvements were also made to DS. 
  • Remote Service Admin - This specification has had minor updates which allow remote endpoints to be updated. In the past the only way to do this was to remove/re-add the endpoint but in practise this caused unnecessary volatility in the system, especially for discovery providers. With the update facility this volatility is now avoided.
  • Repository - The OSGi Repository service now supports composite queries that span multiple namespaces. With this you can ask the repository questions like 'Is there a bundle that exports javax.mail and has the ASL license?' As this information is expressed in different capability namespaces, it's an example of a composite query. A requirement builder utility has also been added to by this specification to make the developer's life easier. 
  • Subsystems - This specification has been updated to allow providing a Deployment Manifest at deploy time. No longer does it need to be embedded in the subsystem archive. Deployment manifests freeze the dependencies that a subsystem has to particular versions; for example the versions validated during a QA phase. With this release these manifests can be provided separately, without the need to modify the subsystem archive (.esa file). The subsystems specification also received a number of other updates. 
A number of smaller changes were made to other specifications. Look for the Changes sections at the back of each chapter for details.

Capability Namespaces

The Enterprise R5 specification provided a number of capability namespaces for general use: osgi.extender, osgi.service and osgi.contract. The Enterprise R6 specification adds the osgi.implementation capability. This capability is useful to ensure that a given technology is present. For example, if you want to ensure that the HTTP Whiteboard implementation is present in a given framework, just add a requirement of the osgi.implementation capability:
  Require-Capability: osgi.implementation;
  filter:="(&(osgi.implementation=osgi.http)(version:Version>=1)(!(version:Version>=2)))"


Note that if the implementation is an extender, then osgi.extender is used instead of osgi.implementation.
Specifications that have been updated in this round have these standard capabilities added, where this made sense.
In addition, Portable Java Contracts have been defined using the osgi.contract namespace to achieve portable bundles for JSR-based java packages that don't follow semantic versioning. This allows for portable consumer bundles of these packages. See here: http://blog.osgi.org/2014/09/portable-java-contracts-for-javax.html and http://www.osgi.org/Specifications/ReferenceContract.

Enjoy, take a look at all this good stuff. The PFD spec is available here: http://www.osgi.org/Specifications/Drafts. A number of (near) finished implementation are available, you can find them listed on the OSGi Specification Implementation wikipedia page: http://en.wikipedia.org/wiki/OSGi_Specification_Implementations

David Bosschaert
Raymond Augé

OSGi Enterprise Expert Group co-chairs

Blog Archive