dev@jax-ws.java.net

Re: Integrating JAX-WS RI with OSGi

From: Potociar Marek <Marek.Potociar_at_Sun.COM>
Date: Wed, 07 Jan 2009 20:39:35 +0100

Hello Valery,
as you may know, the JAX-WS RI is part of Metro web services stack
together with WSIT[1]. WSIT is basically an interoperability extension
built on top of JAX-WS RI and implements various WS-* technologies. I
would like to ask if you would be also interested in working with us
(the WSIT team) on a proper integration of WSIT with OSGi. Please, let
me know.

Best regards,
Marek Potociar

[1] http://wsit.dev.java.net

On 29.12.2008, at 17:17, Valery Abu-Eid wrote:

> Hello,
>
> My name is Valery Abu-Eid (a longtime happy JAX-WS RI user), I
> maintain DynamicJava.org a website which provides open source
> projects and articles that leverage the use of OSGi, I developed the
> project Dynamic-WS which allows the dynamic use of JAX-WS RI in the
> OSGi Environment and I've did a research on the subject of
> developing highly dynamic Web Services on top of OSGi, the research
> used Dynamic-WS with JAX-WS RI run on top of OSGi to prove the
> efficiency of the proposed approach.
>
> Since JAX-WS RI jars are OSGi-incompliant, I used some techniques
> which need further advancement to be run simply in any OSGi
> Environment, which in turn limits the use of JAX-WS RI for OSGi
> Applications. I think that it's more appropriate to make core JAX-WS
> RI modules compatible with OSGi instead of finding workarounds for
> every separate case.
>
> So far I've migrated/integrated with OSGi more than 10 open source
> projects some of them are JSR APIs like JAXB, StAX and JPA. Usually
> I consider three OSGi-adoption levels when migrating/integrating a
> project with OSGi:
> 1- OSGi-Compliant: Project jars contain needed OSGi Metadata (OSGi
> related manifest headers) as such they can be installed and started
> in the OSGi Environment without package wiring problems (package
> sharing and class visibility problems).
> 2- OSGi-Compatible: The project functions properly in the OSGi
> Environment, its behavior is similar as when run in plain Java
> environment.
> 3- OSGi Powered: The project uses OSGi capabilities to provide
> additional features like dynamic behavior and versioning.
>
> How OSGi-Migration can benefit JAX-WS RI?
> 1- Developers who develop Web Services for OSGi Applications will be
> able to use JAX-WS RI.
> 2- Until the moment JAX-WS RI doesn't support Web Services Hot
> Deployment, migrating it to OSGi would allow developers deploy Web
> Services and other application modules in bundles which can be
> easily installed and removed at runtime, the approach which is even
> more efficient that the Web Service Hot Deployment.
>
> Before carrying on I would like to highlight three facts:
> 1- Making JAX-WS RI jars OSGi-compliant requires only adding the
> correct values of the OSGi headers to manifest files of JAX-WS-RI
> jars and such effort doesn't conflict with the work done so far.
> 2- An 80% probability that making JAX-WS RI OSGi-compatible would
> require no changes to the already written code, rather adding a
> single class to 2-4 libraries (the Bundle Activator) and adding a
> new jar file.
> 3- Glassfish v3 will be running on top of OSGi, an OSGi-compatible
> JAX-WS RI will run smoothly with Glassfish v3.
>
> Since I've already worked on integrating JAX-WS RI with OSGi and
> developed a project that allows running JAX-WS RI Web Services
> dynamically on top of OSGi which is already used in production by
> other developers, I think it would be relatively easy for me to
> apply the same experience to migrate JAX-WS RI to OSGi in my free
> time. So basically what I offer you is to get me involved in the
> development of JAX-WS RI to migrate it to OSGi. While it might seem
> not too complicated to involve new people with a project, past
> experience shows that first OSGi-migration efforts usually overlook
> many important details that cause incompatibility problems and bad
> OSGi design choices.
>
> What I will be doing if I get involved?
> 1- Adding needed headers to manifest files.
> 2- Adding Bundle Activator class (a class which will be invoked by
> the OSGi Framework when the Bundle is run in the environment) to
> some jar files, the Bundle Activator will not be referenced by other
> classes in the jar file, as such no modification to exiting code
> will be required.
> 3- Adding a new module (or a set of modules) that would allow
> installing Web Services in bundles in the OSGi Environment.
> 4- Developing a Tests project that will validate the implemented
> features.
>
> What will be the end result?
> 1- The base modules of JAX-WS RI will be OSGi-compatible, as a
> result JAX-WS RI will be runnable in the OSGi Environment.
> 2- Installing JAX-WS RI base modules alongside other module(s) will
> allow developers to install and remove Web Services dynamically in
> the OSGi Environment.
> 3- JAX-WS RI will be compatible with the OSGi Frameworks: Eclipse
> Equinox, Apache Felix and Knopflerfish and Java Environments JRE and
> JDK 1.5 and 1.6.
> 4- A Tests project which validates the claims above.
> (The OSGi migration will not affect the behavior of JAX-WS RI in non-
> osgi Environments in a single way)
>
> Waiting to hear your thoughts on the ideas above.
>
> Best Regards,
> Valery
>