At least with respect to the Equinox Servletbridge the use of a WAR file is a
means to an end. The Servletbridge uses a WAR file just to provide the
integration with existing Java EE application servers and in particular it is
an attempt to allow server applications get away from a monolithic deployment
strategy. The Servletbridge approach is a recognition of the current world that
many of us operate in and is trying to provide a way forward without
necessarily paving the daisies. As OSGi matures inside of application servers
we're sure to see better approaches.
If what you're seeing is "constant references to WARs" then I'm just as
concerned as you are as this is just integration glue. I agree with you in that
the message we want to give is to think in terms of web components instead of
web applications. I'd be very interested if you have any ideas on how we could
better deliver this message.
One problematic approach I frequently see done with the Servletbridge is the
packaging of all the various bundles in the WAR file. This is typically done to
simplify deployment but obviously lacks some of the interesting dynamic
characteristics we'd like to have. It doesn't have to be this way and
subsequently I'm very interested in partnering up the various provisioning
technologies to create a more complete solution. My feeling is that this is the
required next step.
-Simon
----- Original Message -----
From: Kirk Knoernschild
To: OSGi Developer Mail List
Sent: Tuesday, October 16, 2007 8:48 AM
Subject: [osgi-dev] war, jar, and Equinox
If this isn't appropriate for this list, I apologize. If not, and you can
point me to the correct list, I thank you.
I seem to have grown confused regarding the deployment model related to
server-side OSGi, and how I continue to constantly see references to .war
files. I've been doing some work with Server-Side Equinox, and all of the
documentation I find repeatedly talks about deployment of .war files. But it
seems that a significant benefit of OSGi is that we no longer need to continue
thinking in terms of web applications, but instead think in terms of web
components that are individually deployed as OSGi bundles.
In the ideal world, it would seem sensible that we no longer work with .war
files at all. Instead, when it came time to develop for the web, we think more
in terms of features, use cases, business functions, or technological layers.
But regardless, we would deploy individual bundles within an OSGi framework
that was an inherent part of the application server. At this point, the
separation between what we traditionally view as webapps becomes nothing more
than how URL's are registered within a BundleActivator instead of thinking of a
webapp as an individual deployable unit.
Then, given the current OSGi specification, if we desired to run different
components in a separate VM, we would either embed another OSGi framework
within the application server or setup another application server instance
altogether.
So my question...is the constant reference to .war files a stop-gap solution
until more application servers have built-in support for OSGi? Do I continue to
hear .war file as the unit of deployment simply because the Equinox
ServerBridge is required to embed OSGi in a Servlet Container, and the only way
to currently do this is to deploy the ServletBridge within a webapp (.war). Or
is .war deployment still the long-term solution?
If .war is still the long-term solution, possibly someone can clarify a few
things for me. I do understand that we would still possess the ability to
dynamically load bundles within that webapp. But the greater problem of
determining the behavior of one webapp versus another still stands, and this is
a prevalent problem in the world of enterprise software development where a
software system is really a system of systems. Take away the notion of .war and
begin thinking in terms of componentization, and it would offer significant
architectural and design benefits. Continue to use .war files for deployment,
and there are definitely system administration benefits (dynamic loading,
etc.), but there could be so much more that OSGi brings to the table from and
architectural and design (ie. modularity) perspective.
Or...am I missing the boat?
Kirk Knoernschild
------------------------------------------------------------------------------
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
