As per my understanding when developing with CQ5, service layer will be located on the OSGI bundle. Does that mean for every service classes that I will create it will be equivalent to one OSGI Bundle? For example if I have 3 services for my CQ5 application namely: Login Service, UserManagement Service, Registration Service does it mean that there will be also 3 OSGI bundles to be deployed? and how does this bundles will communicate with each other?
Not really. Bundles are more like modules. So you can split your services into bundles basing on their functionality or if you would like to reuse them in other projects. For example you can have next structure:
projectname-core: there you can have services, which can be used by other project as well. Like some content feed generators for external services, Log-in service (if it will be useful in other project as well:
projectname-ui-beans: there you can have beans, which you will be injecting on your jsp pages;
projectname-services: general services, which are specific for this project, like search or registration;
projectname-taglib: there you have your own jsp tags implementation;
projectname-it-test: bundle with integration tests;
projectname-some-specific-stuff: there can be some services which are not dependent on any other bundle, like one-time content manipulation;
Refer this topic for basic structure and Maven archetype for creating it.
Upd1: Communication between bundles can be done in two ways:
you can have one of your bundles as a dependency for another bundle. Then, you could just use #Reference to get services from other bundle
also you can use events to do communication, see this for details.
Having small, focused bundles is good in my opinion, but it doesn't necessarily mean one bundle per service. In your case, login, user management and registration look sufficiently different to warrant their own bundles. But user management for example might be implemented by several services, all provided by the same bundle.
A good rule of thumb is to design your bundles so that removing one of them disables a consistent unit of functionality. Removing your "user management" bundle for example would disable all user management features, ideally without affecting login or registration.
As for communication, think in services. Using Declarative Services, OSGi components simply declare which services they require (usually using #Reference annotations) and the framework takes care of only starting a component once all the services that it requires are available.
Related
For an application written using OSGi specifications
A service is a java object that represents a feature, recording a voice call for example
Every service has a number of packages associated with it, for example, service interface, service implementation, and slick.
I can't get the relation between the above and OSGi bundles, as bundles contain services does that mean they contain the service packages or something else
An OSGi service is a mechanism for bundles to communicate over a well defined Java interface known to all parties. OSGi acts as a broker where one party can register a service under the interface name, and other parties can get it under this interface name. I.e. the actual implementation class is decoupled from the users of the service. This allows the use of different implementation classes while the user of the service is unaware. I.e. for example, if you want to set up a voice call, there could be an PhoneExchange service that would provide you with the functions to setup the call and maybe record it. You can then write your code against the PhoneExchange interface. In runtime, you might be coupled to an Ericsson PBX or a Nokia one.
This decoupling is also present with Java factories. However, Java factories have many disadvantages, and tend to be very static. The OSGi broker is a dynamic broker. A service can be registered but also unregistered. The dynamism in OSGi is seen by many as hard to handle but the Declarative Services makes that more or less trivial. When you really get the dynamism of OSGi services you will find out that many complex dynamic scenarios, like for example communication channels, map extremely well.
The bundle is the module in OSGi. It contains all the Java code and resources. A bundle will export and import Java packages. In a well designed system, these are only the Java packages that hold the service interfaces. It is a bad pattern to export implementation packages. At startup, bundles are wired. This means that exporters get bound to importers. OSGi is unique in that it can handle the same package in multiple versions.
Bundles have their own life cycle. They get started and stopped. In both cases, they can run their own private code.
The aforementioned Declarative Services provide yet another layer. When a Java class declares it is a component with an annotation, it can also declare on what services it depends. When these services are registered, they are injected and the component is activated. Declarative Services allow you to eat your cake and have it to. You get the incredibly powerful dynamics without the associated complexity.
Currently using JBoss 5.2 + Java 8 (Upgrading JBoss is soon to come). We have the opportunity to revitalize the application with a strong core for multi-tenancy support, so assume this can be started from scratch.
Our Java+Spring application is a simple web app:
Exposes various REST services to be utilized by our client implementations (mobile native + browser).
Connects various systems to complete a 'tenant' implementation.
We build out our tenant implementation utilizing our standardized client/server patterns with customization on each side. On the service side, this involves connecting to various external services including the specific tenant's back-end system for querying or end-product submission.
It's a domain driven design, treating the various services as pluggable utilities based on an interface. The services basically act as a translation and request/response handler to and from our standardized domain objects. Currently the various service interfaces, common services, and tenant-specific modules are broken off into separate projects and maven'd together via POM in JAR format. Also note we currently have a single controller layer since the client/server interfaces are standardized for our solution.
My question is: How can we support releases of various tenants without bringing down the JVM?
The current thought was to be able to dynamically swap the tenant JAR dependencies. Right now the tenant-specific services are designated by spring bean injection - tenant config determined by the URL requests are made with (secured by a session token).
Consider the following scenario of 3 tenants:
Tenant A releases monthly # 3am on a Saturday
Tenant B wants agile/security releases every 2 weeks # 9am Saturday
Tenant C wants planned development releases every quarter # 8pm on a Wednesday
Definitely need to ensure security of the application, so don't want to break the class loading to do anything shady.
Any help/direction would be appreciated and will update with what we end up with.
Thanks in advance!
So what I've come up with so far is a single JVM hosting multiple WARs.
Components separated into their own projects:
'core' - Controllers, web service factories, etc..
Service interfaces
Domain Objects
Tenant Implementations (each their own)
This split of projects allows them to be built individually and take advantage of Maven's versioning system (snapshots).
Each implementation(tenant) now has an 'app' project that mavens the various components and services together. This is a different project than the Tenant Implementations - allows that one to be reused by other projects that would utilize the same domain objects. These 'app' projects would provide all configurations for the app and sub components, being built into their own WAR.
Deployment process is as said - a single JVM that doesn't get cycled while starting/stopping WARs. We currently run an older version of JBoss, so messing with the class loader has been the main issue, but not bad. Looking to upgrade or separate WARs into their own server areas under JBoss.
Going to look into a custom class loader via database storage for JARs or into moving to a Docker setup.
I have some little silly doubts in an OSGI concepts but they need to be clarified to have better understanding of concepts. Can anybody tell me what is the difference between OSGI Service and Component. What i know is that Service is like an interface file in java that can be used either by a different service or by a component. While component is like a particular implementation of the service.
Please let me know if i am wrong or suggest some link from where i can get the things nicely.
The OSGi Core specification defines the service model which is a key part of the OSGi concept. A service is an object (instance) which implements a declared type (normally an interface). The OSGi framework provides the service layer which is a broker between service providers and service consumers.
DS introduced the concept of Service Components which are classes in a bundle which that are managed by the DS runtime (SCR). The components are described by XML in the bundle which is read by SCR. These components, once instantiated and if declared to be services, can be registered as services by SCR.
So components can be services (but they do not have to be) and they can use services.
OSGi evolved the concept of services, so that bundles could reduce their coupling with other bundles - ie. achieve loose coupling. The 'loosest' coupling comes from using dynamic services, where bundles that produce services are started dynamically as consumers register to consume those services. The dynamic services model went through several evolutions with OSGi, through service registration and event listening, Service Tracker, and finally Declarative Services.
With all but the last (Declarative Services), the service registration code is put in the bundle's Activator. With Declarative Services, the bundle that exposes a service is called a component and it's declared in a component.xml file that the framework understands - no need for activators. In the Eclipse IDE, you can use Declarative Services by right-clicking on a bundle and adding a 'Component Definition'. There's a really good book on the subject that takes you through the technology with tutorials:
OSGi and Equinox
So I created a new maven pom based webapp using intelliJ 11.
Now I want to separate out my various layers of the application, so I currently I have:
/myproj
/myproj-common (maven module)
/myproj-services (maven module)
/src/main/webapp (spring mvc application)
So I am using the following:
spring mvc
hibernate
So I will create Dao for each entity, and then a service layer that will use the Dao's and wrap other business logic etc.
How should I setup my maven modules properly without making it too complicated?
Should I create a separate interface module that my other modules will use?
Looking for some practical advice.
I'm using maven to build this also.
I tried this before and moving things into separate modules can't be a little tricky, so looking for some guidance on how to do this.
Update
Should I have a separate module for my entities also?
The simplest way is use only one maven module and do separation on package level.
If you need more I can recomend this setup:
myproj-services - entity classes, service interfaces
myproj-services-impl - implementation dao and services
myproj-ui - your spring mvc classes
Ui depends only on services and services-impl depends only on services.
To reply to your update: IMO yes.
To follow the DDD you should have a model module that contains your entities and DAO's and a service module for for your services.
One step further is splitting up the service module into a service-api module (service interfaces) and and service-lib module (implementations). This also entails then that you don't pass entities from your service module to your web modules by TO's (or views if you prefer).
Another related tip: if you're afraid your service classes will get too big (hence difficult to read/maintain/test) consider splitting them up into Business Objects. So, instead of having a UserService containing all the code you have a UserServiceFacade which delegates to MakeUserBO, FindUserBO, ... . These BO's are responsible for one (or more if related) tasks and can easily be reused by other services or other BO's. BO's are short, to the point and therefore easily to read/maintain. It is also easier to mock specific BO's while you're testing other.
I've been looking into OSGi recently and think it looks like a really good idea for modular Java apps.
However, I was wondering how OSGi would work in a web application, where you don't just have code to worry about - also HTML, images, CSS, that sort of thing.
At work we're building an application which has multiple 'tabs', each tab being one part of the app. I think this could really benefit from taking an OSGi approach - however I'm really not sure what would be the best way to handle all the usual web app resources.
I'm not sure whether it makes any difference, but we're using JSF and IceFaces (which adds another layer of problems because you have navigation rules and you have to specify all faces config files in your web.xml... doh!)
Edit: according to this thread, faces-config.xml files can be loaded up from JAR files - so it is actually possible to have multiple faces-config.xml files included without modifying web.xml, provided you split up into JAR files.
Any suggestions would be greatly appreciated :-)
You are very right in thinking there are synergies here, we have a modular web app where the app itself is assembled automatically from independent components (OSGi bundles) where each bundle contributes its own pages, resources, css and optionally javascript.
We don't use JSF (Spring MVC here) so I can't comment on the added complexity of that framework in an OSGi context.
Most frameworks or approaches out there still adhere to the "old" way of thinking: one WAR file representing your webapp and then many OSGi bundles and services but almost none concern themselves with the modularisation of the GUI itself.
Prerequisites for a Design
With OSGi the first question to solve is: what is your deployment scenario and who is the primary container? What I mean is that you can deploy your application on an OSGi runtime and use its infrastructure for everything. Alternatively, you can embed an OSGi runtime in a traditional app server and then you will need to re-use some infrastructure, specifically you want to use the AppServer's servlet engine.
Our design is currently based on OSGi as the container and we use the HTTPService offered by OSGi as our servlet container. We are looking into providing some sort of transparent bridge between an external servlet container and the OSGi HTTPService but that work is ongoing.
Architectural Sketch of a Spring MVC + OSGi modular webapp
So the goal is not to just serve a web application over OSGi but to also apply OSGi's component model to the web UI itself, to make it composable, re-usable, dynamic.
These are the components in the system:
1 central bundle that takes care of bridging Spring MVC with OSGi, specifically it uses code by Bernd Kolb to allow you to register the Spring DispatcherServlet with OSGi as a servlet.
1 custom URL Mapper that is injected into the DispatcherServlet and that provides the mapping of incoming HTTP requests to the correct controller.
1 central Sitemesh based decorator JSP that defines the global layout of the site, as well as the central CSS and Javascript libraries that we want to offer as defaults.
Each bundle that wants to contribute pages to our web UI has to publish 1 or more Controllers as OSGi Services and make sure to register its own servlet and its own resources (CSS, JSP, images, etc) with the OSGi HTTPService. The registering is done with the HTTPService and the key methods are:
httpService.registerResources()
and
httpService.registerServlet()
When a web ui contributing bundle activates and publishes its controllers, they are automatically picked up by our central web ui bundle and the aforementioned custom URL Mapper gathers these Controller services and keeps an up to date map of URLs to Controller instances.
Then when an HTTP request comes in for a certain URL, it finds the associated controller and dispatches the request there.
The Controller does its business and then returns any data that should be rendered and the name of the view (a JSP in our case). This JSP is located in the Controller's bundle and can be accessed and rendered by the central web ui bundle exactly because we went and registered the resource location with the HTTPService. Our central view resolver then merges this JSP with our central Sitemesh decorator and spits out the resulting HTML to the client.
In know this is rather high level but without providing the complete implementation it's hard to fully explain.
Our key learning point for this was to look at what Bernd Kolb did with his example JPetstore conversion to OSGi and to use that information to design our own architecture.
IMHO there is currently way too much hype and focus on getting OSGi somehow embedded in traditional Java EE based apps and very little thought being put into actually making use of OSGi idioms and its excellent component model to really allow the design of componentized web applications.
Check out SpringSource dm Server - an application server built entirely in terms of OSGi and supporting modular web applications. It is available in free, open source, and commercial versions.
You can start by deploying a standard WAR file and then gradually break your application into OSGi modules, or 'bundles' in OSGi-speak. As you might expect of SpringSource, the server has excellent support for the Spring framework and related Spring portfolio products.
Disclaimer: I work on this product.
Be aware of the Spring DM server licensing.
We've been using Restlet with OSGi to good effect with an embedded Http service (under the covers it's actually Jetty, but tomcat is available too).
Restlet has zero to minimal XML configuration needs, and any configuration we do is in the BundleActivator (registering new services).
When building up the page, we just process the relevant service implementations to generate the output, decorator style. New bundles getting plugged in will add new page decorations/widgets the next time its rendered.
REST gives us nice clean and meaningful URLs, multiple representations of the same data, and seems an extensible metaphor (few verbs, many nouns).
A bonus feature for us was the extensive support for caching, specifically the ETag.
SpringSource seems to be working on an interesting modular web framework built on top of OSGi called SpringSource Slices. More information can be found in the following blog posts:
Modular Web Applications with SpringSource Slices
Pluggable styling with SpringSource Slices
Slices Menu Bar Screencast
Have a look at RAP! http://www.eclipse.org/rap/
Take a look at http://www.ztemplates.org which is simple and easy to learn. This one allows you to put all related templates, javascript and css into one jar and use it transparently. Means you even have not to care about declaring the needed javascript in your page when using a provided component, as the framework does it for you.
Interesting set of posts. I have a web application which is customized on a per customer basis. Each customer gets a core set of components and additional components depending on what they have signed up for. For each release we have to 'assemble' the correct set of services and apply the correct menu config (we use struts menu) based on the customer, which is tedious to say the least. Basically its the same code base but we simply customize navigation to expose or hide certain pages. This is obviously not ideal and we would like to leverage OSGi to componentize services. While I can see how this is done for service APIs and sort of understand how resources like CSS and java script and controllers (we use Spring MVC) could also be bundled, how would you go about dealing with 'cross cutting' concerns like page navigation and general work flow especially in the scenario where you want to dynamically deploy a new service and need to add navigation to that service. There may also be other 'cross cutting' concerns like services that span other of other services.
Thanks,
Declan.