I suppose it's a combination of a few things. Any of the useful
examples I've found illustrating OSGi and web application development
are always done using Eclipse and Equinox. I haven't found any useful
documentation that illustrates how to embed Felix, etc. in a servlet
container. There are a lot of really good examples on the Server-Side
Equinox site (http://www.eclipse.org/equinox/server/), but most of
them assume you're using Eclipse as the IDE (for good reason, I
suppose). While Eclipse is a wonderful IDE, for those new to OSGi,
it's strength also serves as a weakness in that it shields the
developer from so much of the underlying technology that you don't
experience the value that OSGi provides. On top of that, most of the
detailed examples assume you're embedding a servlet container (jetty)
in Equinox, which I don't feel is the enterprise use case, as it's
more likely that OSGi will be embedded within the application server.
When embedding Equinox in a Servlet container like Tomcat, all of the
examples use the ServletBridge, and a bridge.war is even provided
that serves as a template project. Now, with the recent release of
Eclipse RAP, the documentation is also centered around deploying
a .war file (http://help.eclipse.org/help33/index.jsp?topic=/
org.eclipse.rap.help/help/html/intro.html), and there's an explicit
section labeled "WAR deployment".
I can see where it would be easy to embed all the bundles directly in
the WAR file when using the ServletBridge. After experimenting for a
while, I dropped the bridge.war in the Tomcat webapps directly and
then installed my bundles from the OSGi console. This was a real eye
opener, especially after I got Jasper up and running and could
include JSP pages within WAR files. It was a "WOW" moment, because it
was characteristic of enterprise development. Since I did all this
outside Eclipse, I really saw exactly what was happening.
When you add it all up, I don't think the supporting documentation
comes right out and says "...this is really going to change how you
develop enterprise software systems. You'll no longer deploy
individual web applications, but instead systems will be an assembly
of bundles that come and go as necessary. In other words, WAR files
are dead and JAR files are hip." Or something like that, but probably
a bit more eloquent. Either way, I believe that the more
documentation that continues to reference .war files as the
deployment model, the more confusion that's going to exist. Maybe
that's just where we're at right now, and we're not sure what the
future exactly holds, so it's difficult to explain it any other way.
Right now, I wanted to make sure I wasn't too confused, and
misunderstanding something significant, as I continue to explore how
OSGi fits into the world of enterprise development.
Kirk Knoernschild
http://www.kirkk.com
http://techdistrict.kirkk.com
http://planet.kirkk.com
On Oct 16, 2007, at Oct 16, 9:23 AM, Simon Kaegi wrote:
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
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
