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.
Related
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.
I have an existing group of bundles that together create a web application (including an instance of Jetty). A new requirement is to extend this application to provide a RESTful api (using JAX-RS).
I was able to develop the majority of the RESTful API in isolation, away from the rest of the applciation. Without realising, the Apache CXF bundle I was using contained its own Jetty instance. So, in isolation, this worked fine. When I merged the two halves of the application, the two instances' addresses conflicted.
This much I know for sure.
What I do not know is how to re-configure the RESTful API part of the application (JAX-RS) to use the existing Jetty instance. This page suggests the use of CXFServlet, but I cannot find much information on this.
Could anybody shed some light or point me in the right direction?
Edit: I should also mention that, currently, my endpoints use the JAX-RS annotations in a Java interface to map between an endpoint and mapped class. I would prefer to keep this configuration method as opposed to XML or any other method.
One option, which does not use Apache CXF, is to use the web components of Amdatu, which also support JAX-RS annotations. You can find more documentation about them at http://amdatu.org/components/web.html which explains how to setup your project with a separate Jetty instance. You might also want to watch the video at http://amdatu.org/howto/createwebapp.html which deals with the same subject.
If you really want to use Apache CXF, there are two versions: an "all in one" that is pretty much self-contained (and therefore also includes Jetty) and a "modular" one that consists of many separate bundles. The latter in theory gives you the option to integrate with your own copy of Jetty, but you need to figure out what exact set of bundles you need based on their documentation at http://cxf.apache.org/docs/index.html
So, yeah, this is what I understood.
Servlet is just an intermediary responsible for finding out what the parameters in the request mean. These parameters are given to the .java file. It is a mere intermediary
.java file is the Model which does business logic
View is the JSP that will do the presentation
Did I get that right?
The Model View Controller pattern is not specific to Java or Servlet technology. There are many non-java MVC implementations, and in Java, there are non-Servlet implementations (Swing is an example).
In Java, when using Servlet-based MVC, usually an MVC framework is used. There are two main categories here: action based and component based, the difference being that action based frameworks listen each registered URL independently while component based frameworks keep a component tree and maintain server-side state.
Action based frameworks are Spring MVC, Struts 1+2, Stripes, Play etc. Component based frameworks are Wicket, JSF 1 & 2, Tapestry etc.
Your diagram gets close to the truth, but there are a few subtle misconceptions.
First, it doesn't make sense to speak of .java files. Java source files are totally irrelevant to a deployed web application, it uses compiled .class files only, and the JavaVM can be programmed in many different languages, so the application doesn't care whether the .class files were compiled from Java, Scala, Groovy, JRuby, Clojure, AspectJ or anything else as long as they comply to the Java Class File specification.
Second, while JSP has long been the default view technology in Java Servlet technology, it's far from the only one. Other technologies include Facelets, Velocity, Freemarker etc., and there's also nothing to stop you from writing data directly to a request from a controller without a dedicated view technology (although this is usually not advisable).
Basically, what MVC stands for is a system where there is separate code for business logic (the M), the view technology (V) and the Controller that ties things together. In a well-organized MVC architecture, the M part is so well encapsulated that the same business logic can also be executed through other channels (e.g. web services, direct library access etc.). Also, it should be possible to switch view technologies through configuration from the outside without editing the actual controller logic.
I would advise you to read the docs for the Spring MVC framework, it is to my knowledge the most robust (and also easy-to-use) MVC framework out there, and the tooling support is also great (in either InteliJ Idea or the Eclipse-based SpringSource Tool Suite).
When you are talking about MVC, then all three layers should be separated from each other.
In web application :
1: A controller should be responsible handling the user request then filtering & executing the appropriate actions and then forward the generated response to the client.
2: A model consist of your Business logic,beans & Pojo classes. This should deal with you logic ,perform some operation and renders the generated result to some kind of persistent object or DTO's.
3: A view is consist of your GUI, some presentation-logic , it should be separated from your back-end ,ultimately you are showing an encapsulated form of result to your client i.e. what a client actually needed.
There are two types of MVC: MVC1(Push-MVC) and MVC2(Pull-MVC)
Pull-MVC and Push-MVC are better understood with how the view layer is getting data i.e. Model to render. In case of Push-MVC the data( Model) is constructed and given to the view layer by the Controllers by putting it in the scoped variables like request or session. Typical example is Spring MVC and Struts1. Pull-MVC on the other hand puts the model data typically constructed in Controllers are kept in a common place i.e. in actions, which then gets rendered by view layer. Struts2 is a Pull-MVC based architecture, in which all data is stored in Value Stack and retrieved by view layer for rendering.
I'm creating an application that relies heavily on dynamic creation/management of various resources like jms queues, webservice endpoints, jdbc connections... I have a background in java EE and am currently working on a jboss 7 server however I'm finding it increasingly difficult to control these things programmatically. The hardest thing to control seem to be the webservices. I need to be able to generate WSDLs (and XSDs) on the fly, manage the endpoints, soap handlers etc and the system simply does not seem to be set up to do that.
Other application servers don't seem to really offer any groundbreaking solutions so I'm wondering whether perhaps java EE is not the best solution to this particular problem?
Is there an application server that allows you to do just that? Is there another technology that does? Should I just roll a custom solution that integrates all the separate modules (e.g. a jms server, a web server etc...)?
UPDATE
To clarify, most java EE stuff is accomplished through a mixture of annotations and XML configuration. This however assumes that you have a POJO and/or a jar/war/... per resource.
Suppose I have a #WebServiceProvider bean which can be reused for multiple input/output combinations (for example because it dynamically redirects the content). I need to be able to deploy a new "instance" of the provider on the fly. This means I do not want to duplicate the code and redeploy it, I just want to take that one existing bean on the classpath and deploy it multiple times with different configuration settings. This also means I need to manage the WSDL dynamically. The end result should be a webservice that works pretty much like a standard webservice on the application server with the necessary integrated security, soap handlers,...
I imagine that at some point in the application server code, there must be a class "WebserviceManager" which has a method like "createWebservice(...)" that is actually used by the deployment module whenever it discovers a webservice annotation. I want access to that method and similar methods for creating jdbc connections, jms queues,...
You can use OSGi for these kind of scenarios. It is perfect for hot deployment of varios modules.
I am writing my first portlet based application (for liferay, but the solution should be container agnostic) and I am wondering how people solve to provide links to the user that "lead" to different portlets (maybe on different "pages" in the portal).
While you can easily have different view modes inside your portlet, how can you link to another portlet and (maybe) also pass parameters along?
I am not talking about plain communication between portlets, it's the real pageflow that interests me.
Example:
You have page A with a portlet that displays a list of news items. Then you have page B that is in the way configured I'd like a single the news item to be shown (for example different portlets around it)
Is there a generic solution to link to page B and say to the news-Detail-Portlet that it should show item XYZ?
The quick and dirty solution would be to configure the target link via edit mode of the news-list-portlet. But this has several disadvantages:
- complex portlets may have several target URLs which leads to massive configuration efforts for the portal admin
- the urls may not follow a scheme that allows simple parameter injection
I have a solution in mind, but this would require massive efforts and maybe changes in the targeted portlets, which is not always possible if you use 3rd party portlets.
My solution would look like this: (draft!)
Portlets register at a central service with their portlet IDs and when a portlet wants to link to a portlet it can do a lookup based on a symbolic name. This would ease the pain for the admin, because it is possible to "auto discover" portlets. The service may also provide a UI to wire portlets based on source and target portlet.
The URL generation for portlets that can be changes may be solved via service call to the portlet that generates the URL as a whole with injected parameters and returns it.
For portlets that you can't change you have to append the parameters and hope that it works. :-/
Any suggestions? Are there simpler solutions? existing solutions?
Thanks!
Patrick
As far as I know Portlet Specification doesn't cover this. So there is no portable solution. For Liferay you can always use theirs custom tag library which aims exactly this issue. There is similar mechanism for Websphere Portal.
Something can be found here and here
Generally I would try to avoid this and use standard IPC mechanism(Public Render Parameters or Events)
For JSR 286 specification it is possible to use events for inter-portlet communication. For the older JSR 168 there isn't an endorsed way to do so. If you find a way that works for you, then use it.
There is an old book given away for free from Manning (registration required). You can find some ideas there.