I'm new whith OSGi, but it is interesting.
Is it possible to interact between osgi bundles and java application? If it is possible, how?
thanks!
The context is that I have a big Java SE application(author is another programmer) with many dependencies. First my goal is to add new functionality and second - change architecture. I'll try to use OSGi, but I don't want to write code twice, for that reason I want to write new code now as bundles. But use this new functionality from the old application.
Yes! Yes! and Yes! This is a perfect way to start taking advantage of OSGi and evolving towards a service based application.
It is trivial to create a framework with the 4.2 launcher API without even knowing which framework implementation you use. You get a Framework object then that is actually an OSGi Bundle and can provide you with a BundleContext. This you can use to install bundles. This all is described in the spec but you can find a lot concrete and excellent examples in Felix: http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html. Felix has been explicitly promoting embedded in apps since day one.
The hard part of this approach will be getting used to modularity and its restrictions. To be useful, you will have to share classes between OSGi bundles and your application; this requires explicit exporting of these shared packages from your application using the org.osgi.framework.systempackages.extra property. This property is the Export-Package header for your application.
Importing packages from bundles in the framework is not possible due to the class loading model in Java. This means your application code can only use services from the framework where the packages for those services are on the apps classpath.
The result of this is that new functionality tend to drift to bundles where there is full visibility: both the exported app packages as well as any bundles. However, this is probably exactly what you want.
So be aware of this potential pitfall. Embed, and then over time migrate all your code to bundles so that your application becomes only an OSGi launcher. However, be very aware of your the packages shared between the two environments.
Good luck and let us know how this goes.
I see OSGi as a structuring technology. You can use it to define the component structure of your application. So all of your app is effectively a collection of OSGi bundles. Hence interaction is not a problem, just different bits of your app interating in the normal way.
[Edited following comment clarification.]
You have a fundamental decision: is your OSGi code going to execute in the same process as the original or in a seperate process?
Separation implies freedom to structure the new code as you wish, exploiting OSGi, but at the cost of interprocess communication complexity and performance overheads. It's pretty likely that you will end up making substantial changes to the existing app in order to support remoting in some form. I don't see this as a great approach unless your OSGi code happens to be some kind of re-usable service that perhaps other remote clients would use.
If in the same process then I'd say that you need to bite the bullet and say that this is going to be a OSGi application. The amount of effort to take an existing app and make it run in OSGi need not be excessive.
Suppose you treated the existing application as one huge OSGi bundle? There would be some work on initialisation, but would the rest "just work"? If you do this as the first step then the real re-architecting and modularisation of the existing app is deferred. You then just expose the interfaces your new modules need, and where necessary consume services provided by the new modules. Immediately you are getting OSGi benefits by structuring the dependencies.
An application build with OSGi can interact in the same way as just two normal (Java) applications. So, by loading / saving files. Or when one of them is created as an OSGi http server, then just communicate through http with that (OSGi) server. Just think of it as you used to do, without OSGi included.
Related
After looking for a long time without finding a good answer, I come to the place where good answers are found.
I'm creating en ecosystem of independent applications (modeled as a WebApp in a WAR) and service modules (plugins) that those WebApps can consume (modeled as an OSGI bundle). I'm having trouble getting my head around how to architect those elements with Apache Felix and Jetty. The way I understand it I have three possible ways of doing it, but I have no idea of the implication of each.
Create a felix container that brings up the plugins, and also brings jetty who eventually bring up the WebApps.
Create a jetty server with embedded felix to provide the plugins, and use Jetty's deployer to manage the WebApps.
Create a jetty server with a less complicated framework than OSGI to manage the plugins, and use Jetty's deployer to manage the WebApps.
Option 1 seems to be a very orthogonal solution, everything is an osgi module (assuming the wars are a module), and managing the whole thing would be just a matter of creating the felix infrastructure and bringing everything up. From my early testing, managing all these osgi modules in development is not an easy or fast task (but most likely I'm doing something wrong).
Option 2 seems that it would work (is the one that I have managed to get further from the two) and is simpler to manage my head around, since the OSGI is limited to managing only the plugin infrastructure and not the applications or the server.
Option 3 I haven't even started to explore.
I'm expecting to have several independent applications (WebApps) and many many plugins (OSGI modules) and I would like to hear from you on the pros and cons of each option, in terms of maintainability and ease of development.
One of the problems here is that 1 and 2 are both valid use cases of osgi frameworks.
I would recommend having a detailed look at JBoss Fuse, as this is a very mature implementation of option 1 (ignoring the container based, openshift stuff and focus on the on prem version). The basics of it are:
a single JVM that hosts an OSGI container based on Apache Felix. (It's really Apache Camel, repackaged from Apache Servicemix, which uses Apache Karaf, which can either use felix or the Eclipse OSGi framework. Turtles all the way down).
Applications are packaged as osgi bundles that can include a servlet engine.
The servlet engine can then also utilise osgi to run a plugin / framework system.
You will probably not be surprised at the huge amount of house of cards tooling it requires to get this stuff up and running, and then maintaining it. You wont suffer from classpath dependency clashes, but the cost is an extremely complicated toolchain for creating and deploying bundles. This also makes unit and component testing very difficult. Some of this is just due to how complex fuse is, but trying to seperate the unnecessary complexity from the necessary is a hard problem.
A hello world on Fuse, where you are digging into each part of the platform and really getting to know what's happening, would probably take a week.
Leaving fuse aside, there are plenty of issues with either option 1 or 2
you are still limited by the JVM and its threads. You need to take some care to ensure everything works together as it is very easy for a single bundle or plugin to happily consume the entire CPU and block other applications from doing work.
plugins have a lifecycle that needs to be managed - start, stop, load, reload, unload. There are a number of management issues that will bite right away - How do you force stop a plugin? When do you give up and restart the JVM?
who is writing the plugins, where are they hosted or built, how do you trust them and so on.
OSGi is pretty successful client side, but IMHO the reason there's not many really well known server side OSGi implementations is because it's really difficult to manage with lots of threads and unpredictable request flow and people just don't get the results they want - run code from different sources in varying configurations, as decided by a user - from the pain of making it work.
So are there any other mature plugin frameworks that solve these issues in a simple reliable way? Not that I'm aware of! There's plenty around on github and google, but they always end up foundering on the same rocks of coming up with a reliable way of managing the plugins and making them play nice with the other things running in the JVM.
I would much prefer to keep the independent applications independent via their own docker container and then maybe look at felix if you really need to be able to load plugins at runtime.
I want to know why OSGI framework is used when building java applications. I am searching the web for this but answers look complex to me. Can anyone please explain few points on why we need to adopt osgi.
Am sorry if the question does not suit stackoverflow
I appreciate the patience of the readers. Thanks.
OSGi provides a modular system with versioning of the modules, and further a bit of life cycle management. It manages dependencies between modules, dynamic/lazy startup/uninstall of modules, lookup/discovery and such.
Part of this will become part of the java language. It enables a lesser complexity than a spaghetti wiring of classes.
IMHO OSGI on its own requires a a lot of boiler plate code for what it does. However if you use a library like Karaf & iPOJO most of the overhead is hidden and you get most of the benefits.
The main benefit is being able to control which versions are used and proper module isolation. For example you can
have the container download the right versions from a maven repository like nexus.
use multiple version of the same library and have the modules which need those use the right ones.
stop, upgrade and start modules while the application is running.
a web console to see the state of all your modules and manage them collectively or individually.
For me the best part of OSGi is that it promotes a service-oriented view of your system, which helps decoupling, testing and teamwork.
I don't think it has to be complex, as I tried to demonstrate with my "OSGi for mere mortals" example application [1] and slides [2] (both shameless plugs ;-)
[1] https://github.com/bdelacretaz/OSGi-for-mere-mortals
[2] http://www.slideshare.net/bdelacretaz/osgi-for-mere-mortals
Go through with this tutorial thoroughly. You might get your answer.
OSGi is a fast framework because it knows that which service will be loaded into OSGi environment thanks to pre-defined xml file. It reduces runtime cost thanks to lazy state. Service instance is created when they needed. Some bundle's different version can be used by other bundle at the same time. Since each plug-in has it own class loader, any bundle can be stopped, started, installed or uninstalled without stopping Java Virtual Machine.The communication among the bundle is possible by using declarative service or service tracker in OSGi environment via interfaces. Using interface frequently pay the way for reusable code. Although OSGi framework contains quite a few class and interface, powerful projects can be created by using it. Since java runs everywhere, OSGi can also run.
From what I understand, in OSGi you can update jars at runtime without restarting the server. But jboss also has hot-deployment in which the full ear is updated and the server is still running.
So what would be the benefits of OSGi in an enterprise java project in jboss ?
I believe that the answer is the same as every OSGi use case: modularity and finer update granularity.
OSGi is far more than updating jars at runtime without restarting the server. From the perspective of your question, it is updating jars at runtime without restarting the application.
I admit I do not know the particular implementation of EAR hot deployment in JBoss AS, but in any case EAR updating cannot possibly be designed so to preserve the whole state of the application. The server is still running, but you essentially restart the application upon updating. The degree of such state loss really depends on how you design your application, but the fact remains that you are doing things monolitically.
With OSGi this is not the case: the application is made of a large set of bundles, each hopefully designed to handle a separate part of the functionality. This approach enables intra-application hot deployment, since the framework is designed to consider the effect that restarting any single jar brings to the application as a whole, and to let the other jars react appropriately. That offers the ability to preserve application state as much as possible.
Hence the benefits of an OSGi design in the Enterprise case is application liveness. No need to underline the importance of that. Truly, there are use cases where the application may be safely restarted. But OSGi in my opinion is the only really scalable and maintainable choice for Java EE nowadays. The fact that the most important application servers have moved (or are going to) to an OSGi runtime (and consequently giving OSGi application support) is proof of that.
l10i wrote: With OSGi this is not the case: the application is made of a large set of bundles, each hopefully designed to handle a separate part of the functionality. This approach enables intra-application hot deployment, since the framework is designed to consider the effect that restarting any single jar brings to the application as a whole, and to let the other jars react appropriately. That offers the ability to preserve application state as much as possible.
Just to elaborate on this a little more, the best OSGi applications are service-oriented applications which integrate through OSGi services registry. This service registry is dynamic, services can come and go at any time and OSGi service consumers react to this dynamicity appropriately.
So let's say your application is comprised of a number of bundles, including a bundle that uses a payment service (e.g. for handling credit card payments) and another bundle that provides that payment service. If you find yourself in a situation that the payment service needs to be updated (because you have a critical fix or maybe you have found a cheaper provider, etc) you can update this payment service without even taking the consumers of this service down. To achieve this, you can update the payment service bundle itself, but what I would recommend in such a case is to install the new version of the payment service bundle alongside the old version first. This is possible because OSGi allows multiple versions of the same bundle to co-exist. Then once the new bundle is up and running you can remove the old payment service bundle at which point the consumers will automatically flip to using the new ones, courtesy of the OSGi service registry.
Such an architecture as the above example is really powerful and great to ensure that your enterprise applications stay up, and it can be realized by using OSGi services combined with the ability to dynamically install, uninstall or update OSGi bundles.
BTW there is a little more detail to the above example as bundles can also be written to use all services of a particular type - what's best for you depends on your situation.
There are a number of ways to use the OSGi service registry, you can use it with the ServiceTracker API, which is fairly low-level. In most cases it's preferable to use a framework for this such as OSGi Declarative Services (DS), OSGi Blueprint or other framework. In most cases these frameworks work through injection and handle the dynamicity of the OSGi Service Registry for you. For information on DS or Blueprint see the OSGi 4.2 Enterprise Specification.
Hi
I want to design and develop a big enterprise application using just
GWT in client side.
I want to break this enterprise application into parts and I call each
of them a module (or bundle or portlet or whatever!).
These modules might have relation with each other and might call some services that
exists in other modules (in both client and server side).
The problem is, These modules must be Designed , Developed, Compiled
and Deployed Independently and Dynamically and they will be placed and
shown together in one context on the client and the dependencies
between modules should be manageable (in both client and server side).
What can I do? What kind of technologies I can use to build an enterprise application like this?
When you develop an application that is not divided into parts (In the way that i mentioned) you can easily deploy your application after building your project, but when you change just one form in your application you have to build the entire application again, and deploy the entire application.
In this application I cannot stop the server to deploy the application again, I want to change and deploy that part of application that is needed to be changed not the entire application!!!
Of course I have searched about the way that I can solve my problem!!!
I have found that I can use OSGI on server side because it provides modularity at software construction level and helps me to manage life cycle of modules and many other benefits that you know!
And I have found that I can use Gadgets on client side.
What do you think? Are they good choices?
If they are good choices, how can I start? I know that we have different kinds of implementations of OSGi, like Apache Felix, Eclipse Equinox and Knopflerfish. Which one is good for this choice?
How GWT and OSGi can be integrated? How can they interact with each other?
Unfortunately what you want to do is not fully possible with GWT.
OSGi is a modularity solution for Java, or more accurately the JVM. A GWT client application does not run on the JVM, it runs on the browser in a JavaScript environment. Therefore OSGi cannot be used to create runtime-assembled modular GWT applications.
A GWT application can be modular at the source level, but the modules must be assembled into an application at build time. The resulting runtime is monolithic.
However, it's perfectly possible to use OSGi to host the GWT servlets, and you can use the full power of OSGi runtime modularity on the server side.
As an alternative you may want to look at Vaadin. This is a web framework that uses GWT to provide widgets, but the logic of the application runs on the server. As a result, it does support full runtime modularity through OSGi bundles. There is a cost with this approach though: your web application is quite chatty, with lots more communication going between the browser and the server than in GWT or in a traditional web application. It's possible that this approach will not scale to very large numbers of users.
As for whether to use Equinox, Felix or Knopflerfish... it really doesn't matter. Stick to the specification, and you can easily switch between implementations.
I did just this two years ago: OSGi and GWT for no downtime deployments of project modules.
Verdict: Don't do it unless you really must.
In short, OSGi is a beast and retrofitting an existing application for it is far from trivial. You're no longer making .war files (.ear now) and can't use the standard jars and Maven repositories you used before. Now everything needs to be a bundle. Trouble is, a lot of stuff (GWT, Spring, tons of libs) are not bundles! And you'll need to find them in an enterprise bundle repository or, even more fun, start rebundling 3rd party sources them yourself. Better yet, telling the other devs to rewrite everything that uses their favorite lib because bundling it would be too complex.
The GWT part didn't take that much work. The way contexts for modules were handled in gwt-servlet had to be modified so each module could find it's context on the server. We also had to make a way for most of the GWT services to register/unregister on load and a discovery service so they could know who else was out there.
Now the other pain: project explosion.
Let's say you had 20 modules you wanted to deploy independently. Well, to start with they're probably more coupled than you'd like, so better spent a few weeks breaking them into independent Maven projects and pushing common parts to a lib project. But now, you've got tons of dependencies to keep track of. When someone tweaks your lib project, do you need up upgrade every project or just 7 of them? In the classic stop the world deployment, you only had one version of all your code. Now, you need to decide if that forgot password form being upgrades will require you to also upgrade your index page module. You'll have a ton of version numbers to make up and keep track of. In our case, we quickly had 55 Maven projects building all the time in our CI server. This meant some checkins could trigger 55 builds. Eek.
Finally, JSON interfaces.
We used GWT RPC. It's magical. Write an interface and everything just works. It's also serialized and gzipped over the wire too. Awesome. But, the serialization policies depend on object and string lookup tables that are built at compile time per module. So, project A cannot RPC to project B. Boo. We chose to use JSON due to the graceful degradation, that is not failing when new unrecognized properties were present on objects. This means you'll again need a way to keep all the backend service calls coherent in the versions of the JSON they are expecting and can handle. Better simulate that live upgrade beforehand too.
So, final word: possible, but why? Do you really need OSGi to hot deploy modules because you're running a 1000% uptime business critical application? Or does your boss/architect just refuse to accept that 99.999% is good enough? You probably don't need that uptime and can achieve nearly 100% uptime with a good proxy to let you take instances in/out of the balancer pool. Also, don't forget that even if you can upgrade your projects live on the fly, I hope you've got a way to upgrade your database on the fly without dropping a single transaction.
I think you are setting yourself for more headaches than it is worth.
I would go with deploying the whole thing at a pop. If not you will end up with mismatched pieces of the application that are out of sync with each other. GWT has both Client and Server components and they need to be deployed together. If you have a zero downtime policy then you probably have load balancing in place.
I would use the load balancing software to deploy the new version of the app. Turn off one side (by diverting all traffic to the other side) deploy to it, do a quick smoke test, switch all traffic to the new side and repeat with the old side.
It seems that OSGi is a hot term these days. Many benefits are invoked:
Reduced Complexity
Reuse
Easy deployment
Versioning
(etc)
I'm asking for a very specific use case - small to medium-sized web applications. What benefits would OSGi bring for those? It is actually worth it?
I would say as always "it depends".
Your environment
Consider an existing team with no OSGI experience(who proudly consider themselves as experienced developers who "get things done". There's a chance that they'll experience a major pain or a slow start.
MANY(more than you might think) developers are not familiar with build tools such as Ant or Maven, and when they are they only use limited features of those build tools.
Creating OSGI bundles is best accomplished with Eclipse, Ant tasks or Maven BND plugin VS a script or a manually written manifest for the jar archive.
Small applications
For small applications, OSGI introduces unnecessary complexity while you could use dynamic languages such as Jython, etc. or a plugin framework such as JPF or the SPI. You could also go directly with reflection and a simple custom classloader.
Big applications
Big applications might benefit from OSGI, especially when they are written from scratch. IMHO integrating OSGI in an existing application is more like introducing a patch for provide a modular architecture.
From my experience, after rewriting many applications, it's better to think about the modularity at the early days of a project.
Other concerns
Deployment :
It is the same in any applications. If you're used to deploy Java Web Start applications, deployment is not a concern. If you're used to OSGI, deployment shouldn't be a concern.
There are always problems once in a while in any application when it comes to deploying it in production, which is natural.
Versioning :
There are many ways to provide versioning in an application. But if you only use versioning as "information" vs as a tool(manage dependencies requirement), versioning is not a concern.
Reuse :
When using OSGI you tend to write your code for reuse, but any well written API is designed with code reuse in mind.
Eclipse is a number one example of a successful big application written with OSGI. There are other big/nice tools which don't use OSGI and are modular.
Conclusion
In many modular frameworks, it's difficult to handle dependencies, stop/start/uninstall/install features at runtime, without restarting the application. You play with a custom classloader, shutdown and startup hooks, etc.
OSGI gives you such flexibility at a minor cost IMHO.
I'll hazard a NO, even though I'm a big fan of OSGi. Unless you're working with other OSGi bundles or you have a specific problem that you can't easily solve without this sledgehammer.
The benefit is elegant classpath separation (IMHO). If you need different versions of the same JAR/class, say because you're upgrading certain portions of an app while it's running, or because you are combining a lot of 3rd party modules, then OSGi is great.
That's not an easy thing to achieve, and it's not made easy with OSGi. It's made clean, but at a cost of another layer in the environment stack. And a lot of work to learn and maintain.
Not to mention the documentation isn't particularly beginner-friendly.
I suggest learning about it -- building Eclipse plugins is one very good way -- but not building it in to your dev plan until you know it well.