A long awaited feature has finally been completed in Felix: Fragments!
I'm really happy to hear this because in the past it has been a pretty big gap in the support provided by Felix.
Here's the message from Richard Hall: http://www.nabble.com/Re%3A-Status-of-Fragments-in-Felix--p25663384.html
Tuesday, September 29, 2009
Monday, September 28, 2009
Aries: an Apache project for Enterprise OSGi
Some of you may have noticed the Aries incubator project at Apache: http://incubator.apache.org/aries.
Aries is about building a community specifically around enterprise OSGi components and an enterprise OSGi application programming model. It provides a home for bundles and larger chunks of enterprise OSGi technology independent of the OSGi container, so anything found in Aries should work in a compliant OSGi runtime such as Felix or Equinox.
Part of the proposal focuses on the development of an OSGi Application model for assembling multiple bundles into a larger parts which you can think of as an application.
An application model is one of the things that the OSGi Enterprise Expert Group (EEG) is currently defining and working ahead on an implementation will help making this standard better as experience is always better gained by doing.
Initially the project will provide an implementation of the OSGi 4.2 Blueprint specification (RFC 124), an implementation of JPA support for OSGi and JNDI integration for OSGi.
Like with any Apache project, anyone interested in joining the fun is more than welcome to contribute! Many individuals and people working for a large variety of companies have already joined during the proposal stage and I would expect even more people to join once the project is under way.
Exciting stuff!
Aries is about building a community specifically around enterprise OSGi components and an enterprise OSGi application programming model. It provides a home for bundles and larger chunks of enterprise OSGi technology independent of the OSGi container, so anything found in Aries should work in a compliant OSGi runtime such as Felix or Equinox.
Part of the proposal focuses on the development of an OSGi Application model for assembling multiple bundles into a larger parts which you can think of as an application.
An application model is one of the things that the OSGi Enterprise Expert Group (EEG) is currently defining and working ahead on an implementation will help making this standard better as experience is always better gained by doing.
Initially the project will provide an implementation of the OSGi 4.2 Blueprint specification (RFC 124), an implementation of JPA support for OSGi and JNDI integration for OSGi.
Like with any Apache project, anyone interested in joining the fun is more than welcome to contribute! Many individuals and people working for a large variety of companies have already joined during the proposal stage and I would expect even more people to join once the project is under way.
Exciting stuff!
Thursday, September 17, 2009
OSGi 4.2 Core and Compendium Specs Available
The new OSGi 4.2 Core and Compendium Specifications are now publicly available.
The big new items are:
Remote Services - The Remote Services Specification (Chapter 13 in the Compendium Spec) defines how you can use the OSGi Services Programming model to distribute your services across machines. It brings Distributed Computing to OSGi in a very natural way. The Reference Implementation is provided by Apache CXF.
Blueprint Container - This standardizes the Spring Dynamic Modules development model and allows you to expose simple POJO's as OSGi Services. Additionally, OSGi Service References can be injected into your own POJO through simple setter calls. In a way it is similar to OSGi Declarative Services (and other OSGi Component Frameworks), the difference is that this one works very similar to the way Spring works. The good thing is that all OSGi Component Frameworks works seamlessly with each other. E.g. a Service created with DS can be consumed by Blueprint without any problems, and vice versa. The Blueprint Reference Implementation is worked on at the Spring-DM project.
Service Registry Hooks - This enhancement to the OSGi Core was initially triggered by the Remote Services (Distributed OSGi) work as it needs to know what Services active Bundles are looking for. This information allows the Remote Service implementation to look specifically for the requested service in any of its registries to see if there is a remote one available. Later it turned out that there are many more applications of Service Registry Hooks. They allow you to figure out what services are being looked for, but they also add the possibility to hide certain services for certain bundles making it a building block for Service Proxification. The Hooks (Chapter 12 in the Core Spec) are implemented by both Equinox 3.5 and Felix 1.8.0.
Additionally, many small updates have been made to other specs. You can find the specifications here: http://www.osgi.org/Specifications/HomePage
Meanwhile, the Enterprise Expert Group is working at full speed on the OSGi 4.2 Enterprise Release which contains many additional new Enterprise related specifications.
The big new items are:
Remote Services - The Remote Services Specification (Chapter 13 in the Compendium Spec) defines how you can use the OSGi Services Programming model to distribute your services across machines. It brings Distributed Computing to OSGi in a very natural way. The Reference Implementation is provided by Apache CXF.
Blueprint Container - This standardizes the Spring Dynamic Modules development model and allows you to expose simple POJO's as OSGi Services. Additionally, OSGi Service References can be injected into your own POJO through simple setter calls. In a way it is similar to OSGi Declarative Services (and other OSGi Component Frameworks), the difference is that this one works very similar to the way Spring works. The good thing is that all OSGi Component Frameworks works seamlessly with each other. E.g. a Service created with DS can be consumed by Blueprint without any problems, and vice versa. The Blueprint Reference Implementation is worked on at the Spring-DM project.
Service Registry Hooks - This enhancement to the OSGi Core was initially triggered by the Remote Services (Distributed OSGi) work as it needs to know what Services active Bundles are looking for. This information allows the Remote Service implementation to look specifically for the requested service in any of its registries to see if there is a remote one available. Later it turned out that there are many more applications of Service Registry Hooks. They allow you to figure out what services are being looked for, but they also add the possibility to hide certain services for certain bundles making it a building block for Service Proxification. The Hooks (Chapter 12 in the Core Spec) are implemented by both Equinox 3.5 and Felix 1.8.0.
Additionally, many small updates have been made to other specs. You can find the specifications here: http://www.osgi.org/Specifications/HomePage
Meanwhile, the Enterprise Expert Group is working at full speed on the OSGi 4.2 Enterprise Release which contains many additional new Enterprise related specifications.
Subscribe to:
Posts (Atom)
