Something I like to do to keep my understanding of technologies up-to-date is to identify a technology on the cusp of widespread acceptance, and to figure it out. This is why I decided to start working on Karaf and OSGi a year ago, and it has served me very well.
The current wave is the cloud and virtualization. Like OSGi, its been around for a while, and is being widely accepted. Many organizations are familiar with "virtual machines", not Java VM's, but the ability to start up an instance of an operating system within another operating system.
Anyhow, as a newcomer to cloud computing, my first small chore was to create a virtual appliance containing Karaf and Celler. Karaf is a small, lightweight OSGi container that allows you to do enterprise stuff. :-) To accomplish this, I used an older Toshiba Satellite computer system as my server, and a newer Dell laptop as my client. The client is planned to be used for development of the virtual appliance.
VMWare: VMWare has a great web-centric application called "Go" that small-to-medium businesses can use to download thier Hypervisor version of software. Using this, businesses can get access to thousands of virtual appliances, and leverage them (for a cost) to handle their business needs. However, there are some drawbacks. Specifically, my laptop needed a gigabit controller. Because my slow computer only had a little ol' nic-card, the driver couldn't be found and I was unable to install Hypervision to test it. Also, remember that installing this app successfully on your system will completely wipe out the previously installed operating system.
Susestudio: SuseStudio has an awesome web-based interface for creating virtual applications. The only drawback I saw to that was the fact that .rpm's needed to be created for any applications I wanted to install into my VApp. I'm still looking to see if this is the standard. In any case, this was a show-stopper for me.
XenServer: This, like VMWare, was a download that wiped out my hard-drive. They were nice-enough to let me know that during installation. The good thing is that this is the first cloud system I've been able to install on my test-system, so this is the server I'll use to buildand install my virtual appliance!
Next time: How to find the XenServer UI!!
Wednesday, September 21, 2011
Monday, September 19, 2011
Why OSGi?
Recently I answered a question on stackoverflow.com about the difference between component-based and modular architectures. However, what it really does is show one of larger benefits of OSGi, fixing the classpath.
Here is the question and my answer:
Q: OSGi is a modular architecture, JavaBeans is a component architecture. What's the diff?
A: The primary difference between OSGi and Java Beans is in how the classloader works. In a standard .jar file or EJB, the rt.jar file or EJB equivalent maintains the classpath. Additionally, if you are using a container to deploy your application into, you may have multiple classpath maintanance mechanisms which cause problems. As a result, when you make a .war file, for example, you usually create a lib directory with all of your .war's .jar dependencies inside of the .war. If you only have one war or .jar in your application, this isn't so bad. But imagine a large enteprise deployment with 100 EJB's all containing apache-commons! You end up with 100 instances of apache-commons all running inside the same container sucking up resources.
In OSGi, you deploy each .jar file (we'll call them bundles cuz this is OSGi now) into the OSGi container. Each .jar file exposes (exports) the packages it wants other packages to use, and also identifies the version of the bundle. Additionally, each bundle also expressly states (imports) the packages it needs from other bundles to work. The OSGi container will then manage all of these exports and match them up to the appropriate imports. Now you have apache-commons available to each of the EJB's you want to make available. You've done away with your /lib directory and now your application takes up less resources.
In your question you asked the difference between a component architecture and a modular architectures. Modularity refers to this process of making each bundle its own deployment unit and allowing it to talk to other bundles instead of balling them all up into one massive .jar file.
Here is the question and my answer:
Q: OSGi is a modular architecture, JavaBeans is a component architecture. What's the diff?
A: The primary difference between OSGi and Java Beans is in how the classloader works. In a standard .jar file or EJB, the rt.jar file or EJB equivalent maintains the classpath. Additionally, if you are using a container to deploy your application into, you may have multiple classpath maintanance mechanisms which cause problems. As a result, when you make a .war file, for example, you usually create a lib directory with all of your .war's .jar dependencies inside of the .war. If you only have one war or .jar in your application, this isn't so bad. But imagine a large enteprise deployment with 100 EJB's all containing apache-commons! You end up with 100 instances of apache-commons all running inside the same container sucking up resources.
In OSGi, you deploy each .jar file (we'll call them bundles cuz this is OSGi now) into the OSGi container. Each .jar file exposes (exports) the packages it wants other packages to use, and also identifies the version of the bundle. Additionally, each bundle also expressly states (imports) the packages it needs from other bundles to work. The OSGi container will then manage all of these exports and match them up to the appropriate imports. Now you have apache-commons available to each of the EJB's you want to make available. You've done away with your /lib directory and now your application takes up less resources.
In your question you asked the difference between a component architecture and a modular architectures. Modularity refers to this process of making each bundle its own deployment unit and allowing it to talk to other bundles instead of balling them all up into one massive .jar file.
Subscribe to:
Posts (Atom)