dev@jsr311.java.net

Re: JSR311: Support for OSGi Service Platform

From: Tobias Hofer <tobias.hofer_at_basis06.com>
Date: Wed, 13 Aug 2008 09:41:04 +0000

Well, I agree that OSGi is not a user-friendly framework in the sense
that most
popular libraries and frameworks do not work on it. But I do not agree
that there
are tons of component models because all of them you listed do not
fulfill the
criteria for what a software component shall be.

Some of the criteria that Clemens Szyperski and David Messerschmitt give
for
what a component in a component model must fulfill are
 - Encapsulated
 - A unit of independent deployment and versioning
 - etc.
There exist three more criteria, but that two are the most interesting
for now.

Unfortunately does IMHO the JAX-RS API not fullfill the criteria to work
in a
component model because of the RuntimeDelegate class. It would be nice to
see a growing number of libraries and frameworks that can be used without
pain in a real component model. Would JAX-RS be one of them?

Now, I don't wont that this discussion will end up in a dispute about
what a
component model is. There exist a common usage of that term that does not
match the point of view mentioned. But I think that component
encapsulation
and independent deployment and versioning of components really are
desirable because that makes it easier to produce stronger applications.

Tobias Hofer


On 8/12/2008, "Bill Burke" <bburke_at_redhat.com> wrote:
>I hope you don't mind arguing about this... I'm not trying to be a
>jerk, but rather to make sure that my assumptions are correct.
>
>Tobias Hofer wrote:
>>>> I'm involved in realizing a JAX-RS implementation for the OSGi Service
>>>> Platform. But there are some barriers in the current JAX-RS
>>>> Specification that hinders a seamless integration.
>>>>
>>> The problem is OSGi isn't mature enough to work with modern
>>> user-friendly component models. Keying everything off of an interface
>>> is just a poor model that only works with a small subset of applications.
>> Most existing applications and libraries rely on a static and monolithic
>> deployment and therefore cause problems in a more dynamic environment.
>> So do most component framework behave. They ignore that a component can
>> have its own development and deployment life cycle.
>>
>
>
>
>
>
>> The original focus of OSGi was on service gateways but the applicability
>> is much wider. IMHO the OSGi Framework is mature and very modern even if
>> it's origin can be dated back to 2k.
>>
>
>mature that it solves life cycle for its own component model.
>Unfortunately, there's tons of popular non-OSGi component models.
>
>> I'm not sure what you declare as a modern user-friendly component
>> model...
>
>Seam, Web Beans, EJB 3, Spring, Guice, GBeans (Geronimo), JBoss Beans
>(AS 5), and even JMX Service Beans (JBoss AS 4 and earlier). All could
>have cross bundle dependencies.
>
>>
>>
>>>> One of them is the lack of a root resource service interface. I suggest
>>>> to introduce an empty interface named 'javax.ws.rs.RootResource' or
>>>> alike. This interface would allow an OSGi bundle to expose its resources
>>>> using the OSGi service registry using interface that is part of the
>>>> official API.
>>>>
>>> I don't think an OSGi bundled JAX-RS application *needs* to export any
>>> classes. I also don't think an OSGI service registry is appropriate for
>>> JAX-RS components.
>> Exactly right. There's no need to export any classes. But the bundle
>> must provide information about the services it provides. That
>> information is used by the framework to wire bundles and their
>> components together.
>>
>
>The problem is, again, there are different popular component
>architectures out there. The main ones being Spring, EJB 3, Seam, and
>maybe even Guice.
>
>Most users would be writing a component that is registered with the
>JAX-RS runtime. In other words, you would be using Spring, EJB 3, Seam,
>Web Beans, or Guice to define your JAX-RS resources. You wouldn't be
>using the default JAX-RS component model.
>
>
>>
>>> Instead, exposing only javax.ws.rs.core.Application classes would be a
>>> better approach. As it is the JAX-RS implementation still needs to set
>>> classloader boundaries with every incoming invocation, as AFAIK, this is
>>> not something OSGi handles.
>> That's true, javax.ws.rs.core.Application allows to return instances and
>> not only classes as its predecessor did. It is very important to be able
>> to return instances in order let the framework handle the component's
>> life cycle.
>>
>> But the javax.ws.rs.core.Application is not very user-friendly to
>> implement. That requires every bundle to implement an additional class.
>>
>
>Application is as user friendly you are going to get considering the
>number of popular component models out there.
>
>> I know, that my proposal of an empty interface is not the best solution
>> (redundancy, etc) but it would allow a more user-friendly way in
>> exposing a JAX-RS component than the Application class does.
>>
>
>User friendly for OSGi, not user-friendly in general. I know one of the
>things we're solving in JBoss's new kernel is the ability to
>automatically manage dependencies and lifecycle that could be
>cross-bundle, cross-component, and even cross-component model. And to
>do it transparently without additional metadata. I know we couldn't do
>this with the current state of OSGi which is why we're trying to work
>with the specification.
>
>> I do understand your opposition against that additional interface. In
>> fact it is possible to use the java.lang.Object as service type, but
>> that's not really a service contract. I'll have to live with that.
>>
>>
>>>> A global class path scanning in OSGi is possible, but accessing
>>>> instances of classes in bundles that do not explicitly expose them as a
>>>> service would break the managed life cycle of bundle components.
>>>>
>>> Yeah, i haven't been very impressed with OSGi beyond its fine-grain
>>> classloading.
>> I like the life cycle handling of components in OSGi.
>>
>>
>>>> I'm sure that JAX-RS and OSGi is a powerful combination with an existing
>>>> market.
>>> IMO, OSGi is overhyped as I think it should be marketed more as a
>>> framework developer consumable API rather than an application developer
>>> consumable API.
>> I agree, OSGi is overhyped. But that does not derogate the specification
>> nor its usage. And yes, there is first the need of frameworks that will
>> work on OSGi, but I don't think that they need to encapsulate and hide
>> OSGi in order to get application developer ready.
>>
>
>I disagree. IMO, we need a common kernel, but OSGi isn't complete
>enough to get to the level of user-friendliness we should aspire to.
>
>--
>Bill Burke
>JBoss, a division of Red Hat
>http://bill.burkecentral.com
>