CODEWITHSUNDEEP
osgi
Bab
Bab

Reputation: 85

Is OSGi the right approach for us?

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 https://i.sstatic.net/6NxhF.png).

enter image description here

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.

Upvotes: 1

Views: 752

Answers (2)

pooh
pooh

Reputation: 662

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.

Upvotes: 1

christian.vogel
christian.vogel

Reputation: 2137

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

Upvotes: 2

Related Questions