I am planning to use osgi in a typical client-server (with swing gui) application. Hot deploying bundles to the server is made easy with fileinstall but now I am looking for something similar on the GUI.
The GUI is started with webstart but I want to update bundles without asking the user to close and restart.
I was planning to have a server side bundle which monitors a directory containing bundles, exposes the bundles over http and notifies the clients when something has changed. A client side bundle would listen for the notifications and do the bundle installs/updates using the methods on BundleContext and Bundle.
(Note: I already have an RMI like link between the server and clients which can be used for the notifications)
Is there anything which already does this or similar?
I would at least like to reuse fileinstall for the filesystem watching part but I don't want the GUI bundles started on the server.
P2 is a great provisioning system for OSGi based applications. Eclipse uses it, and there are a lot of uses even for non-OSGi applications. You should definitely have a look at it before you start building you own update system. You can also check Apache Ace.
The Fractal example for the Paremus Service Fabric may be instructive here ( https://docs.paremus.com/display/SF16/Demonstration ). In this example both Server and Client side OSGi bundles may be dynamically installed. RMI is also supported.
Regards
Richard
Related
Our application are built on Spring boot, the app will be packaged to a war file and ran with java -jar xx.war -Dspring.profile=xxx. Generally the latest war package will served by a static web server like nginx.
Now we want to know if we can add auto-update for the application.
I have googled, and people suggested to use the Application server which support hot deployment, however we use spring boot as shown above.
I have thought to start a new thread once my application started, then check update and download the latest package. But I have to terminate the current application to start the new one since they use the same port, and if close the current app, the update thread will be terminated too.
So how to you handle this problem?
In my opinion that should be managed by some higher order dev-ops level orchestration system not by either the app nor its container. The decision to replace an app should not be at the dev-ops level and not the app level
One major advantage of spring-boot is the inversion of the traditional application-web-container to web-app model. As such the web container is usually (and best practice with Spring boot) built within the app itself. Hence it is fully self contained and crucially immutable. It therefore should not be the role of the app-web-container/web-app to replace either part-of or all-of itself.
Of course you can do whatever you like but you might find that the solution is not easy because it is not convention to do it in this way.
I am considering writing a new set of applications using OSGi, but they will need to interact heavily with existing non-OSGi applications.
To clarify, the new applications will need to call into existing non-OSGi code bases maintained by other teams (usually propriety services of varying protocols), and new non-OSGi applications will need to call the new OSGi services.
I am not seeing much documentation for how to do this.
Can someone please point me to the correct steps
It sounds like you want to embed OSGi into a larger application. A good starting point for this is a blog post I wrote some time ago: http://njbartlett.name/2011/07/03/embedding-osgi.html
The trick to creating visibility between OSGi bundles and the objects "outside" OSGi is to publish and/or consume services using the system bundle's BundleContext. The embedding code must be aware of the objects from the outer application that you want to make visible into OSGi, and it should publish them as services. Be aware that you need to export the service interface packages via the system bundle exports -- how to do this is described in the blog post.
OSGi services are only for communications inside the same JVM process. So I guess you want to communicate between processes. In this case you have all the usual remoting protocols like SOAP, Rest, RMI. On the OSGi side you can bridge from OSGi services to offering SOAP or REST endpoints using Distributed OSGi (DOSGi).
My organisation is moving away from traditional EAR/WAR based applications and moving towards OSGi for building our business applications. The WSO2 platform provides a lot of support services (esb, governance, identity, etc) that we would want to leverage in our applications.
Is it possible to deploy our OSGi components directly to the WSO2 application server, or does it make more sense to deploy just to WSO2 carbon? Are there any issues that we should be considering with this approach?
WSO2 Carbon is the Core server for WSO2 platform which includes all common features used as the base for WSO2 products. Application Server is Carbon Server + Service Hosting features and few others which is used for service hosting aspect. You can use Carbon Server directly to deploy OSGi bundles. You can install any of the features you need through configure-->features
by just adding a P2 repository. if you do not need Service hosting features just start from Carbon server and add any features you need to fulfill your need. (feature is a collection of OSGi bundles which cater one aspect). You can build your p2 repository and install your features directly to Carbon Server as it is normally done. There are several methods to drop your OSGi bundle into WSO2 Carbon based servers.
Following link will help you to understand How OSGi is used inside Carbon Server.
WSO2 A.S. is based on a Carbon platform, like every other WSO2 instances, so it should not make much difference, but makes sense to use the Application Server.
I have not tried to deploy OSGI components but I know it is possible. Sorry I can't help more.
We have to support at least 2 versions of functionality at the same time. It can be in the web side or services, meaning we'll have different layout for different users in the web or service implementation will be different for different users. We should be able to route the users based on their login to the right version of the web application / bundle.
We thought of something like this (please see bigger picture here http://i.stack.imgur.com/6NxhF.png).
Also is it possible to have multiple web applications / bundles deployed as one EBA? If yes, is it possible to share the session between these web apps / bundles? As we are new to OSGi, looking forward to any suggestion on the design we have chosen. Appreciate any help / suggestions on this.
Thanks,
Bab.
OSGi could be right for you. In my last project we had something equivalent to your approach. We've developed a backend system with OSGi where we had a backend connector as a starting point for different other bundles who wants to use functionalities of the backend. In your case the backend is your shared bundle context. We then had a SOAP webservice, several servlets and webpages (which should be OSGi based as well) which sends requests to the backend connector. Of course you can send request directly to internal bundles like your manager, but I would propose a layered architecture. In case of shared sessions: The question is which component is responsible for handling sessions? If you want to have not only web applications in your environment, you can manage sessions via a database or an inmemory approach. A 'SessionManager' bundle in your shared context is then responsible for creating user sessions (sessionid for identification), relating sessionid and temp data, getting data for sessionid and deleting temp data for sessionid. With this approach each client request should send the sessionid, which will be validate somewhere in your shared context. Then you dont need the web sessions. The created sessionid could be stored in a specific HTTP header entry of Request/Response for the communication. But thats only one approach.
Hopefully, all above makes sence to you. If not send me an email and we can discuss it more in depth. :) Sometimes pictures say more as a lot of sentences and I could draw some if you want. ;)
Greetings.
Christian
Yes, OSGi can help you a lot with this.
The architecture you have chosen looks fine, I would suggest perhaps also adding a 'SessionManager' as suggested by Christian.
Regarding the OSGi specifics you will need for this:
If you have two different versions of the "Services" bundle, which are packaged in the same Java packages, you should definitely define package versions when exporting them in the manifests:
In Services V1:
Export-Package: com.acme.foo;version="1.24"
and in Services V2
Export-Package: com.acme.foo;version="2.3"
You can then control which package is imported in the Web bundles by defining restrictions, e.g. like this for whole intervals:
Import-Package: com.acme.foo;version="[1.23, 2)"
The beauty of this is that due to the modularity of OSGi and the separate classloaders of the bundles both versions of com.acme.foo can be installed and used in the same system. You cannot achieve this in the "usual" Java setup, because there there is only one classloader and one version of the package will shadow the other.
You can see OSGi demos and examples for example here
This was about the packages and libraries.
Now about the actual service objects:
You could also have two versions of the same service published in the OSGi Service Registry. The easiest way to differentiate between the two is to use service properties when registering the service:
Hashtable properties = new Hashtable();
properties.put( "service_flavour",
"advanced" );
context.registerService(
SomeService.class.getName(),
this, properties );
You can then use the props to lookup the correct service in the Web bundles:
ServiceTracker someServiceTracker = new ServiceTracker(bc, "(&(objectclass="+SomeService.class.getName()+")(service_flavour=advanced))", null);
someServiceTracker.open();
Regarding your question about EBA - I am not sure what you mean. You can install as many bundles as you want in any OSGi framework, and they can all register under different aliases in the OSGi HTTP service. As long as the aliases don't have a conflict with each other it is ok. You can also have one main servlet if you want, and distribute the handling of the different pages to other bundles without registering them as servlets too - your main web servlet could look them up in the OSGi service registry for example, and distribute the work. It all depends whether you expect more application logic/calculations etc, or is it more about formatting and representation of some existing data.
Hope this helps.
We are developing a open source trading platform based on Springframework and Hibernate http://code.google.com/p/algo-trader/ and http://www.algotrader.ch. The application consists of a trading framework and several strategies that can be started independently. So far, these different parts have been running in separate JVM's communicating through RMI and JMS.
To avoid unnecessary serialization and network overhead we would like to run the entire application within some sort of container (potentially an application server). We do however have the requirement, that the individual parts of the application can be deployed, started and stopped independently.
We have looked into OSGi, but a lot of the libraries that we use are not OSGi ready yet, so this is not currently an option. Also please note, there is no web-GUI in our application.
Any suggestions on this?
Thanks
Andy
If OSGI is not an option then functionality can be broken into smaller units and then deploy them as utility jar, if deployed as utility jar they can be managed independently.
For application server I feel either glassfish or Jboss will be a good option considering they are open source and free.
Though at a later point in time you can check with Weblogic (Dev free).
So in your case you would like to break the static data configuration(Counterparty, Currencies), Dealing(Pricing, Quoting, Booking) as two separate feature.
For your choose of an application server i advise you Jboss and specially in his version 7.1 which is faster and more stable!