Saturday, March 28, 2009

Enterprise OSGi - "Not List"

I spend a lot of time talking about what enterprise OSGi is, but I always get a lot of questions, particularly about distributed OSGi. I thought it might help to put out a list of what enterprise OSGi is not.

Enterprise OSGi is not:
  • Java EE - but EE components are being mapped to OSGi
  • A new distributed computing stack - but it defines how to use existing ones
  • Spring - but it has a "Spring-inspired" Blueprint service that does something similar
  • Something a bunch of vendors dreamed up and decided to standardize - it's a grass roots effort started because people were already using OSGi for enterprise applications and needed help
  • Done - the release of the specification is scheduled for June/July (part 1) and December (Part 2)
  • Simply a deployment standard - the real power and ultimate benefits of OSGi are in its service programming model
  • Untested - the OSGi Framework has been successfully used in enterprise scale deployments
Many of you who have been following the OSGi specification for a while are familiar with its trajectory - starting with its adoption as the platform for Eclipse, the OSGi Framework is used underneath most enterprise products based on Java, including market leading application servers, development tools, portals, and ESBs.

The question that stirs the most debate is not this aspect of OSGi but whether enterprise Java application developers will embrace it in addition to, or in place of, Java EE APIs. Those of us working on the enterprise OSGi release do understand that it is currently too hard to use, and that it's best to develop OSGi bundles and services using the Spring Framework/Blueprint service or another programming abstraction technology such as iPOJO or Peaberry. But we fully expect the benefits OSGi provides for improved modularity and dynamic deployment and update are benefits enterprise developers need.
Posted by at
Labels: ,

2 comments:

  1. Dominique De VitoMarch 31, 2009 at 6:10 AM

    Then, it looks like Enterprise OSGi is all about mapping (or integrating better) existing services into OSGi (world) and providing a OSGi bundle for deployment, isn't it ?

    This being said, it looks like too Enterprise OSGi is going to make easier to implement Jini-like technology on top of OSGi. Is that true and one of the goals for Enterprise OSGi ? Thanks.

    For example, if correctly read, Enterprise OSGi aims to map a transaction service as a OSGi service, then put into OSGi world a Jini similar service about transaction too.

    How do you see Enterprise OSGi/Jini-like technology relationships in the future ?
    Thanks

    ReplyDelete
  2. Eric NewcomerMarch 31, 2009 at 9:39 AM

    Hi Dominique,

    Jini is definitely one of the technologies we anticipate someone mapping into enterprise OSGi, but we don't explicitly define the relationship. We want to be sure we don't do anything to prevent it, but we are not standardizing on it either.

    Last time I read the description of Jini transactions it was basically an interface over JTA or something similar. Jini did not define a transaction manager of its own. We don't either. We are also defining a mapping of JTA into OSGi. The design for this is available in the early release drafts published last week.

    We are definitely thinking out work will make it easier for someone to map Jini and other types of distributed computing software into OSGi - so yes, that is one of the goals. But we are not doing anything specific to Jini or any other type of distributed computing software. The choice is open.

    Thanks,

    Eric

    ReplyDelete

Subscribe to: Post Comments (Atom)