Eclipse Community Forums: Virgo » Missing part in understanding OSGI

Home » Eclipse Projects » Virgo » Missing part in understanding OSGI(Designing a rest api)

Missing part in understanding OSGI [message #1064049]

Mon, 17 June 2013 08:10

Eclipse User

Dear VIRGO experts,

I need your help to point me in the right direction understanding the osgi concepts. What i don't understand yet is how to use the basic web.xml definition made in a single web bundle (dispatcherServlet, securityFilterChain, ...) in a no web bundle.

For example if I want to design a modular rest api. Then - if I understand osig correctly - it would be possible to do it like this:

Web Bundle
web.xml with dispatcherServlet
springconfig.xml with RequestMappingHandlerMapping, JSON Converter, ...

Non Web Bundle - API parts 1
applicationcontext.xml with various osgi:reference imports form the web bundle like:
RequestMappingHandlerMapping
or other resources defined in other bundles like:
Hibernate datasource
and the bundle content:
Controllers, Services, DAO, etc...

Non Web Bundle - API parts 2
applicationcontext.xml with various osgi:reference imports form the web bundle like:
RequestMappingHandlerMapping
or other resources defined in other bundles like:
Hibernate datasource
and the bundle content:
Controllers, Services, DAO, etc...

The question is now: How to run the part 1 part 2 bundle in the corresponding context of the "central rest api web bundle".

The same question is relevant for spring security settings. Of course i can define a security filter chain in a web bundle as well as the auth manager for example in the corresponding springconfig.xml. It is also no problem to use a reference to the authManger in other bundles. But: I don't understand how to bring the non web bundles in the context of a web bundle. In this case the security filter chain.

Is this VIRGO SNAPS what I am looking for?
Or am I totally on the wrong way with my osgi understanding?

Any help would be fantastic.

Best regards, Martin

Re: Missing part in understanding OSGI [message #1064054 is a reply to message #1064049]

Mon, 17 June 2013 08:55

Eclipse User

The way I understand your description you are cutting your single web app in the wrong direction/way.

Perhaps it is possible the way you are trying to do it but we have gone a different direction and it may help you in your quest Smile

:

We have one Persistence API bundle.

We have one bundle for persisting entities which offers itself as a service (via declarative service).

We have one API bundle for the business layer.

We have one bundle which implements the business API and gets a reference to the persistence service injected via declarative service.

We have one web app bundle (WAB) which contains the REST services. This bundle has a bundle activator which contains a service tracker for the business service. (this could probably also be injected somehow)

Hope this helps.

Mihael

Re: Missing part in understanding OSGI [message #1064270 is a reply to message #1064054]

Tue, 18 June 2013 09:55

Eclipse User

Hi Mihael!

Thanks for your response!

Let me think about your pattern...

A: We have one Persistence API bundle.
This is clear.

B: We have one bundle for persisting entities which offers itself as a service...
Also clear. Do you have multiple bundles here for special parts?

C: We have one API bundle for the business layer.
All your services and so on...
Don't you need access to your Bundles B here?

D: We have one bundle which implements the business API...
What are you doing here?

E: We have one web app bundle (WAB) which contains the REST services...
OK. This is interesting. Does the service tracker in this case mean that you dynamically scan your Business API for available services and than provide the Rest automatically?

So far so good Smile

What happens now if you need to implement new services in your system? You need to write an new Bundle B as well as a bundle C. Am I right?

Thanks for your time.

Re: Missing part in understanding OSGI [message #1064282 is a reply to message #1064270]

Tue, 18 June 2013 10:26

Eclipse User

Quote:

We have one API bundle for the business layer.
All your services and so on...
Don't you need access to your Bundles B here?

Yes. As said before: The persistence bundle offers service(s). These services can be injected into the business services (one way by declaring a reference in the component definition xml file, see OSGi declarative services).

D: Business API bundle containes the interfaces to the business layer. We use these interfaces in the web bundle to get a service from the OSGi container for the passed interface.

We use interfaces to register services in the OSGi container.

ServiceA implements BusinessInterfaceA

Now we register ServiceA at the OSGi container and say that it implements BusinessInterfaceA (which it does).

Any other object with access to the BundleContext can retrieve ServiceA via the OSGi service registry and ask for a service which implements BusinessInterfaceA.

Exchanging the backend is no problem at all as long as the API stays the same. You would just write new implementations of the interfaces and exchange the bundles. You can just exchange the persistence bundle or the business bundle or both. As we are always using APIs when talking to other bundles exchanging things is easy.

That's one of the good thing about OSGi.

Mihael

Re: Missing part in understanding OSGI [message #1064289 is a reply to message #1064282]

Tue, 18 June 2013 10:48

Eclipse User

Ok. Thanks for your detailed answer. Your way is definitely the common osgi way but I am not sure if it fits me needs... We work on a SOA backend with a high amount of flexible growth.
We want to be able to split everything in modules depending to the function.
For example:
Part "Customers"
Part "Dates"
Part "..." and so on...
Each Part should of course use one single bundle which holds a reference to the auth Manger or the data source... but works completely independent...
You are right: This is maybe not a proper way but we want to be able to load complete modules in the system on the fly.
I'll need to think about it. Smile

Best regards from Nuremberg.

Re: Missing part in understanding OSGI [message #1064337 is a reply to message #1064289]

Tue, 18 June 2013 15:24

Eclipse User

Nothing wrong with splitting things up if you need it in smaller pieces/bundles.

You can also put jpa and "ejb"/business stuff together and split it the other way like having a bundle

crm.customer

and

crm.salesprospects

or you can even further split it into

crm.customer.jpa
crm.customer.ejb
crm.customer.api
crm.customer.rs

For the JPA stuff you probably want shared persistence so that every jpa bundle of yours has the same cache (only from my exp with hybrid apps on glassfish, don't know Gemini JPA yet).

Hope this is of any help.

Mihael

Re: Missing part in understanding OSGI [message #1064434 is a reply to message #1064337]

Wed, 19 June 2013 05:06

Eclipse User

And here comes the part which I don't understand Smile

How to bring these non web bundles - each containing:
-Controller
-Service, Service Impl
-DAO, DAP Impl
into one web bundle context?

For example:
Each single "function bundle" provides the rest api via the controller:
@RequestMapping("api/customer")

The web bundle than provides the the dispatcherServlet in the web context: /rest/

The question is now how to run the single non web bundles in the main web bundle in order to reach the
rest api like this: ...localhost:8080.../rest/api/customer

I understand how to share services ore config beans made in the spring-config xml. But I do not understand how to share the dispatcher Servlet definded in the web.xml.

Previous Topic:	Using bundles with Wars
Next Topic:	What is the correct location for defining "filterChainProxy"?

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 11:11:24 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter