I'm working on a layered business application written in Java that should be packaged as an EAR file and deployed to a JBoss application server. There's a web-application layer, a service layer, a domain layer but no persistence layer. At least on paper.
What is the best practice for deploying the different layers? In our team we have a little religious war going on between:
Packaging each layer in its own JAR file (e.g. in its own Maven module), and adding each module to the EAR file, OR
Bundling everything together in a single JAR file, with each layer mapped to a package naming convention.
Are there other possibilities I'm missing? What are the best practices in this area? Are there any online or offline resources I could consult about this?
In my company, we bundle each layer into its own JAR. Then we include it in a WAR.
If you don't have any EJBs that need managed, there's no real advantage to using an EAR over a WAR for deployment.
Whichever approach you choose, make sure you actually gain value out of it. In other words, don't serve the architectural principle (package/jar) let the architecture principle serve you.
You need to balance separation of concerns with efficiency. The more projects you have the more cumbersome things become, but if you have one project, that can also be cumbersome.
Look at your requirements, context and size of your application and decide which approach is going to serve you best.
Related
I am developing a standalone java application which is later packaged as a jar and will be deployed into an Enterprise application(EAR).
I am accessing database several times in my application using JDBC, in this application can I use any of the data access design patterns like Abstract DAO? or should I not consider including data access layer or any such layers in a stand alone java application?
Of-course you can do whatever you can do with a web application. Moreover, the abstract DAO pattern is not specific to a particular set of applications.
There are couple of ways of doing this.
You can create the DAO code as a jar and include it in the class path of other proejcts which are deployed as EAR.
Yes having a data access layer to consolidate your JDBC code instead of having it scattered throughout the application is beneficial. Also should consider using a db connection pool. An example is Apache DBCP. Just because it is a stand-alone app does not negate the benefit IMO.
If I were to it, I would :
Create a dedicated library dao.jar (packaged as a jar) that would contain the DAO code
Create a standalone (runable) application app.jar (runnable jar) that relies on this library
Make my ear app.ear use the dedicated library (dao.jar) NOT the application
If there is some business logic, you can create an additional library that contains it business.jar that relies on dao.jar and make app.jar and app.ear rely on it too.
One jar should have only one major responsability or layer.
dao.jar can use any useful design principle or design pattern to access its data.
I have a start up web application using Spring and Hibernate which currently has 3 layers. View, Service and DAO. It also the domain objects are segregated separately.
To this I want to add webservice and scheduler . Now which layers should I add these classes? Or shall I create new packages for these? What are the best practices on n-tier web applications?
Please share your thoughts and experiences.
To web and scheduler packages?
There's no "right" answer to this question, and without any idea regarding your package layout beyond what's shown, it's difficult to be more specific.
As long as it makes sense in context, and it's consistent, it really doesn't matter a whole lot anyway. And you may find that your existing structure changes after you identify and refactor functionality across the original and new functionality.
A few thoughts:
A package is not a tier. A tier (or layer) is a logical abstraction for a collection of related functionality, a package is a physical grouping tool for compilation units. It may be the case that all the classes used to implement a logical tier reside in the same source package, but there is no requirement that this is the case.
It seems like webservice would fit nicely in the service package, or maybe a subpackge within service called web.
For the scheduler, it may also belong somewhere in the service package (particularly if other components are meant to interface with the scheduler via a service API). If not, then the next most appropriate thing would be to give it its own package called scheduler.
As for best practices, just do what 1) works and 2) makes sense. "n-tier web applications" is a topic so broad that there aren't really any specific answers that apply in all possible cases.
I'm working on a 10-year-old Java webapp, and I would like to introduce some new technology into the project. One of the things I would like to start doing is dependency injection. I know the Spring Framework has the capability to do dependency injection, but I am having a hard time integrating the framework into the old project.
Could someone provide an example of what I would have to change in my web.xml, other files I would have to add, and other changes I would need to make? I want the smallest Spring footprint while still being bale to do dependency injection.
There are a lot of examples online about starting a new project using Spring, but I can't find any about integrating Spring into an old project.
Thanks.
You'll have to start by adding a context loader listener into your web.xml, along with the locations of the Spring configuration XML files.
You should configure the Spring DispatcherServlet to accept all URLs that you wish for it to handle.
You should write Controllers to bind and validate HTTP requests, call services, add data to ModelAndView for rendering, and map JSPs to success/failure views as needed.
You should put interfaces in front of your service and persistence tiers. Move implementations into implementation classes that Spring can inject.
Leverage Spring AOP for security and transactions and logging as needed.
Throwing new technology at a project wont make it faster\better, unless you introduce the new technology to all parts of the project. The idea behind DI is to lose dependencies between objects. The project probably is tightly coupled, so you'd have to rewrite at least parts of the thing. Depending on the size, this can be a monster to beat - ask yourself if this is worth it, if it has any positive effect on the project other than introducing new technology.
The reason why there are little to none tutorials about integrating DI container into an old project is quite simple: it usually doesn't make any sense. Either you use the pattern in all places, or none at all. The bastard child that would be creating by mixing both would be a horror to maintain. I'd really advise you think about why you want to introduce a DI container into that 10 year project. Unless there is a real good reason for doing it (and you are happy with rewriting a lot of code) don't do it.
I'm working on a project that have several webapps (WARs) built with Maven and deployed in a Java EE.
These WARs share several common business JARS (like one containing domain objects which are loaded from hibernate) and other framework JARs like Spring and Hibernate.
They use Spring MVC, and the Application Context loads Hibernate. As each WAR has its own Classpath in the servlet container, the Hibernate cache (EHcache) is not shared.
What I'd like is to share the cache and also the hibernate session factory bean (as well as other common beans) betweeen the different WARs. I think this is possible by repackaging those WARs inside an EAR and then I'd have to make a spring configuration XML using those commons beans and in the WAR's Spring XML use something like SingletonBeanFactoryLocator from what I've read.
What I'm asking here is if there is a simple way to do this, minimizing changes to the WARs' POMs
Note: I'm familiar with WARs, tomcat and servlets, but not so much with EARs.
Thanks in advance.
Hmmm... Most Java EE containers use isolated classloaders for WARs, even in an EAR (even if the Java EE spec does not mandate class loading isolation among modules of a single EAR) so I wouldn't expect to much from an EAR packaging, especially if you want your application to remain portable (i.e. if you don't want to rely on any app server specific behavior).
Now, if really it makes sense to share your session factory and your 2nd level cache between several applications, maybe consider merging them in a single WAR. That would be the easiest way IMO. But I'd be tempted to ask why are they separate then? When applications are separate, they have most of time separate governance and I don't know if deploying them together would be a good idea in such case.
And if merging the WARs is not an option, please tell us which container you are using.
Have you considered making use of a coherent clustered L2 cache? If you're using multiple app servers you might see more benefit then as they would all be sharing the same coherent cache
Using a shared parent application context in a multi-war spring application
http://blog.springsource.org/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/
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.