dev@jsr311.java.net

Re: JSR311: Support for OSGi Service Platform

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 12 Aug 2008 16:30:11 -0400

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