- JVM 1:
- Enterprise Application
- Utility and third-party jars
- Persistence unit
- Web Application
- Enterprise Application
- JVM 2:
- Content Repository
- JVM 3:
- containing external applications like mail handling
News: TSS Asks: OSGi-related development practices
One of the prototype architectures for an enterprise application uses OSGi to contain services for everything: the web application is a service, the content repository is a service, the chat application is a service, and so on. How do TSS readers approach developing this kind of architecture? Traditionally, you might have a layout something like this:
- Posted by: Joseph Ottinger
- Posted on: March 03 2008 09:53 EST
- Re: TSS Asks: OSGi-related development practices by Christopher Brind on March 03 2008 13:39 EST
- Re: TSS Asks: OSGi-related development practices by Konstantin Ignatyev on March 03 2008 14:55 EST
- What do you deploy in? by greg matthews on March 03 2008 17:40 EST
- Component Market... by Michael Murphree on March 03 2008 18:37 EST
- OSGi-related development practices by Cameron Purdy on March 03 2008 18:47 EST
- OSGi Webapps? by Eric Jain on March 04 2008 01:22 EST
- OSGi DevCon by Wayne Beaton on March 04 2008 09:08 EST
- Re: TSS Asks: OSGi-related development practices by Martijn van Berkum on March 04 2008 10:45 EST
- GWT and OSGi? by Lubos Pochman on March 04 2008 14:16 EST
I still think a component oriented architecture is very appropriate, EJB is/was just a good example of how not to do it, though in recent years it has certainly improved especially with EJB3. OSGi has the added benefit of being service oriented as well, so it is a true component and service oriented architecture. The company I work for, Arum Systems, are actively working with an OSGi based architecture. The product I am working on is based on a platform that we have developed in-house called "Solstice" and which is due to be released as a fully open source alpha any day now. Solstice is a platform for modular Flex development, but is essentially a an OSGi platform. It is a web application containing BlazeDS and Equinox (with Servlet Bridge), as well a couple of bundles from the Felix project. As such it has to be deployed as a WAR under an application server and we're currently using JBoss 4.2.2. I would have preferred a pure OSGi stack, but BlazeDS has some dependancy on a more recent servlet spec than is supported by standard OSGi frameworks. Once I get my hands on the source for BlazeDS I will migrate to a pure OSGi stack probably based on the Equinox platform. People who want to feel the enterprise comfort factor could use ProSyst's OSGi platform (which is also based on Equinox), it would be their choice but the transition would be easy because the bundles won't have any dependancy on the OSGi platform. For development we use Eclipse because we're all used to it and it's plugin development environment is excellent. Each component is a bundle, apart from the "Solstice Web Application" and the "SolsticeSupport" project which creates a Flex library. As a result we use osgijc and osgibb in our build Ant scripts, as opposed to bnd; mainly because osgijc and osgibb understand Eclipse based osgi bundle projects and don't require any additional meta files in order to build the bundles. Think of them as lightweight PDE ant tasks. For me, staying with component and service oriented architectures makes perfect sense, our flagship product based on the Solstice platform will be completely future proof thanks to working with OSGi, which means our customers will benefit from every penny out of their initial investment without fear of a big outlay later when they want to upgrade their systems. Regards, Chris
I welcome the attention the OSGI getting or any other technology that promotes building application in logic oriented way rather then try shoehorning any application into a fixed number of layers architecture. The multi year, multi billion push for 3-tier architecture did a lot of harm and many developers just gave bewildered look when you talk to them about more tiers, or less tiers, or different layers than prescribed by J2EE spec.
I would generally agree with Konstantin. However, 3-tier architecture (web tier, server side and database) still covers surprisingly large (majority) of web-based systems and there’s nothing inherently wrong with this setup when used correctly. EJB2 was definitely a disaster but the technology recovered rather quickly with frameworks like Spring and ultimately EJB3. I still view OSGi as more of intra-VM technology but that could be my ignorance. Regards, Nikita Ivanov. GridGain - Grid Computing Made Simple
.. 3-tier architecture (web tier, server side and database) still covers surprisingly large (majority) of web-based systems and there’s nothing inherently wrong with this setup when used correctly...While it is largely true I prefer slightly different mental and implementation model of OSGI: my application needs a HTTP connector so I use it, rather than J2EE's notion that my application lives inside of HTTP container.
We're evaluating OSGi and the Spring OSGi wrapper at the moment. I think we understand it but not sure what to deploy in. - WebSphere 6.1 seems to support OSGi - JBoss is being made OSGi ready. - JONAS, I think, supports OSGi. - Equinox and Knopflerfish are OSGi containers, but is anyone deploying web apps in them?. Is there a Tomcat OSGi bundle, into which my other application bundles can register servlets? If not, and based on my current limited understanding of deployment options, I think that's the missing link before mass take up. i.e. OSGi is nice, but the necessary bits aren't there to deploy into.
As I understand it, WebSphere is actually built on top of Equinox, so it's not so much a matter of "support" but of the fact that WebSphere is a system of OSGi bundles all the way down. For web stuff, you're really looking for an implementation of OSGi's HttpService. In the case of Equinox, you get Jetty embedded and configured as the implementation. The design of Tomcat doesn't lend itself well to implementing org.osgi.services.http.HttpService. I actually did this for one of our internal projects and it was a major pain in the rump. We did it, however because at the time we had an ISAPI redirection requirement that Jetty had no answer for. If you can, stick with Jetty. JBoss is writing their own OSGi runtime (http://labs.jboss.com/community/interviews/ales_osgi.html ). I buy the argument that they want more control, but I'm not sure I buy the argument about it being the same amount of work as using / working on an existing one like Felix. As for what you should use? If you're not interested in taming Equinox for the server-side (it'll take you a few weeks if you're familiar with OSGi), you may want to have a look at a product that already does this. I don't mean WebSphere or WebLogic / AquaLogic, but rather a container meant to be an OSGi runtime. Have a look at ProSyst: http://www.prosyst.com . They have a commercial offering and a community offering: http://www.prosyst.com/products/osgi_se_equi_ed.html . They are also contributers to Equinox itself, and they've contributed some of the work they've done for their commercial server back into Equinox (you'll see some of it in the Ganymede release). I hope this helps. Regards, Michael
JBoss is writing their own OSGi runtime (http://labs.jboss.com/community/interviews/ales_osgi.html ). I buy the argument that they want more control, but I'm not sure I buy the argument about it being the same amount of work as using / working on an existing one like Felix.Rather than the same, it would be a lot more work trying to implement what we want to do with OSGi starting from another framework (even if we ignored backwards compatibility). I exclude the "compendium" part which we will "borrow" and contribute back to where appropriate. Probably from Felix? In the long run, it's more than just deploying OSGi bundles. That's probably the easy bit? I can say that because I'm not doing it. :-) Our road map includes many other things. e.g. somebody asked about deploying a webapp as/from a bundle. That's "trivial" in our architecture although it does require a piece a "nonspec defined metadata" to say where the content is structured in the bundle. So is scanning a bundle for jpa/ejbs and deploying it, etc. With dependency injection onto services, activators, ... and vice versa into our "native" services, ejbs, ... It is "vapourware" at the moment. ;-) But it's not that we don't have the technology or architecture we just need to map it to the OSGi spec api. Which means things like the correct events, permissions, callbacks, error types to be compliant. Once it is done, the other parts mentioned above are "low hanging fruit" for us. Why throw that advantage away and start from "just" an OSGi framework?
I haven't seen WebLogic Event Server mentioned, so I thought I would throw it out there as a possibility. (I'm a member of the development team.) Here is a link with more information: http://dev2dev.bea.com/blog/swhite/archive/2007/08/weblogic_event_1.html Event Server applications are packaged and deployed as OSGi bundles. The Event Server embeds Jetty and supports the OSGi HTTP Service. It supports Spring DM, as well. Seth
OSGi is more and more used on the "server side", and the OSGi alliance has recently formed the OSGi Enterprise Expert Group, looking to extend the OSGi specification to support the needs of Enterprise Java actors. JOnAS 5, the OW2 open source application server, adopts a pure native OSGi based services architecture. The core of the application server is an OSGi gateway (currently Felix) and technical services are packaged into OSGi bundles. This enables the server and its services to be dynamically adapted and extended depending on users/applications needs and on the environment constraints. This brings modularity, dynamic (re)configurability, on demand incremental services delivery, easy access to OSGi world (RFID, probes...) from java EE applications, and in a near future will allow to target embedded app servers needs. Compared to JOnAS, I think WebSphere 6.1 is very tight to Eclipse and does not use the OSGi services. JBoss core architecture is based on their micro-container, and it seems they just intend to provide an OSGi personality. See http://jonas.ow2.org for more info about JOnAS 5. and http://http://wiki.jonas.objectweb.org/xwiki/bin/view/Main.Demos/JOnAS5 for a demo of Java EE / OSGi interaction.
- WebSphere 6.1 seems to support OSGi
- JBoss is being made OSGi ready.
- JONAS, I think, supports OSGi.
Component market? Isn't that already here (http://www.eclipseplugincentral.com/ )? I know... Those are plugins, not OSGi services. But in order to be a plugin, you must also be an OSGi bundle. This means that there's an awful lot of bundles to pick up and use (http://www.eclipse.org/orbit/ ). Let's have no fantasies of picking up that OSGi GL component, or OSGi customer module. That might make sense in the context of a higher-order system of composition ( http://www.osoa.org/display/Main/Service+Component+Architecture+Home ), but not in something finer-grained like OSGi services. I will say this (having worked with and on OSGi-related stuff for the last year and change), that thinking "service architecture" is exactly right. OSGi gives you the right mix of publish-find-bind with interface-based decoupling to make service decomposition a very natural way to design things. Best IDE: Eclipse RCP distribution ( http://www.eclipse.org/downloads/ ), you can take advantage of the PDE Build system that works with all the project materials Eclipse already creates for an OSGi-savvy headless build. Best practices: When you design a service, create one bundle for the service interface, and at least one other bundle for service implementation. The reason for this is that you may actually want to provide additional implementations of the same service interface. If the interface is in the same bundle as the implementation, a replacement implementation (a newer one, perhaps) would also require the old implementation to work. Ick. When you consume a service, you must assume you don't know what implementation provided it. Unless, that is, you've queried by vendor and version when looking the service up. Use declarative services where you can. Better, use Spring OSGi Extensions. Floss. Don't export the package containing your Activator, unless there's good reason to. Don't export internal classes either, and keep them in packages whose names end with "internal" just to remind yourself. Always set a version number on your export declaration. Favor package imports over Require-Bundle statements. Don't forget the sunscreen. Regards, Michael
OSGi changes things by deploying all of these components as peer services with interdependencies.It's just a JAR with a lifecycle.
how do you build your OSGi modules?ZIP ;-)
Should OSGi developers consider a component market after the lack of success seen by EJB in this area?EJBs weren't proper components. OSGi is more a linker model than a component model. Frankly, Java still doesn't have components.
Is the deployment model illustrated above even correct?No. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
Frankly, Java still doesn't have components.Would you mind elaborating on this?
It's just a JAR with a lifecycle... and explicit dependencies, module-level information hiding, versioning, and a graph-based classloader architecture that replaces Java's broken "global classpath" model.
That's possible, certainly, and good as a learning exercise. This is the approach I took in my OSGi Tutorial at EclipseZone, for example (http://neilbartlett.name/blog/osgi-articles). However for serious OSGi development you should look at using tools to manage the metadata and help you analyse dependencies. Amongst IDEs, Eclipse has the most obvious support for building OSGi bundles, but it is by no means necessary to use Eclipse, and one problem with the OSGi tooling in Eclipse (known as PDE, Plug-in Development Environment) is it requires your whole team to use Eclipse. If you prefer a more heterogeneous IDE environment you can use tools like "bnd" (http://www.aqute.biz/Code/Bnd) which integrates well with ANT and Maven, and works with all of the major Java IDEs. You could also look at the Maven-based tools under the PAX project (http://wiki.ops4j.org/confluence/display/ops4j/Pax).
how do you build your OSGi modules?
OSGi is more a linker model than a component model.Cam, did you read only the modules layer chapter of the specification and skip the services layer? OSGi does have a component model, although it is really the low-level framework for wiring together components dynamically. For ease of use it needs a higher-level abstraction built on top, and this abstraction is still being defined by a number of people. Spring-DM provides one such abstraction; Declarative Services or iPOJO are other examples. So you're right, Java still doesn't have components, but we're getting really close.
Peace,Pax, Neil Bartlett
I'm currently puzzling over how to build an OSGi-based web application that can be extended with OSGi bundles. There are some examples that show how to either run an embedded web server on an OSGi platform or deploy OSGi bundles on a web application server. But where things get tricky is when you want to create bundles that provide part of the UI (e.g. additional Struts Actions or Spring Controllers, and JSPs that make use of shared templates). Anyone "been there done that", or is this unchartered, "here be dragons" territory?
I'm currently puzzling over how to build an OSGi-based web application that can be extended with OSGi bundles.I won't claim it is production-ready or anything, but I've been working on an OSGi plugin for Struts 2 on and off for a while. Basically, it allows you to create bundles containing Struts 2 Actions, configuration, and Velocity/FreeMarker templates and deploy them dynamically. It embeds an OSGi container (Felix) so that you can deploy the plugin on any application server or even existing Struts 2 application. I've found it certainly does require framework support for all the right hooks, which works out as I'm a Struts 2 committer, but it can be done. The core integration idea came from the Atlassian plugin system, which is in dire need of an OSGi-based overhaul, IMO. I wrote an article about it a while ago, but the majority of the content still applies.
We have been working at the web application framework built on top of OSGi (Equinox) and Spring-OSGi. Among other things we have created the solution for the dynamic UI parts providing. Being based on an "extension point" approach, the UI fragments along with backend code can be published in any bundle. It is now possible to add, replace or remove such bundles on runtime; all these changes are synchronously reflected on the UI rendering. For now, the framework provides out-of-the-box integration bundles for such libraries as Hibernate (we are using it as JPA provider), JSF, QuipuKit, Facelets and Spring Security... Practically every library can be integrated into the framework, that's just a matter of time. The applications built using the framework are now launched on bundled Jetty server. Currently we are adopting the applications to be run inside of Tomcat and other application servers/servlet containers. We are going to release the framework as an open-source product later this year. Expected Early Access Program (EAP) start is June 2008. Check updates on www.teamdev.com Sincerely, Alexei Tymchenko
If you want to learn more about OSGi and meet some of the big brains in the space, consider attending OSGi DevCon  which is being held in parallel with EclipseCon , the week of March 17 in Santa Clara, California. Wayne  http://www2.osgi.org/Conference/HomePage  http://www.eclipsecon.org/2008/index.php?page=home/
Our company wanted some kind of an addon system for our WCM system, and we decided in 2006 to use OSGi for that. In april 2007 we have released GX WebManager 9.0. From an architectural viewpoint, we use Apache Jackrabbit as repository storage based on Java Content Repository, Spring MVC as controller and Apache Felix as the OSGi implementation. The (old) plugin architecture is maintained, so we have all enterprise features from older WebManager releases. The whole application is running in one JEE container, but is clusterable of course, for high traffic websites (this is not as easy as it sounds, especially with Jackrabbit still a little bit immature at that time). As we have our own user interface for editors, we use OSGi bundles (we call them WebManager Component Bundles, WCBs) to make it easy to add functionality to our CMS, without restarting the whole JEE container. We provide several ways to create consistent user interfaces. This architecture makes for very small turnaround times. Our product is used at several very high profile websites in the Netherlands, as we are one of the marketleaders here. Most of our customers are migrating to version 9 of our product, so we are now building up a marketplace of components you can add to GX WebManager, with eventually the server downloading the component online directly from the component directory. Components like wiki's, polls, FAQs, questionaires, RSS integration but also headless services are no problem. Although the user interface part is of course different with every application, we really think that from an architectural level this is where the JEE market should be (and is) heading, just as the rest of Java: more dynamic, less static, more runtime and less compiletime, and think more in components. The JCR is actually a great addition to such an architecture, as the JCR promotes fast changing data models. BTW, we will be releasing a community edition and a public developer website for our product in a few weeks, so if you want to play with it, contact me or visit our website if you want more information. Martijn van Berkum CTO GX (www.gxwebmanager.com)
Is there an example code, article or any other information about how to develop OSGi based web application with GWT?