Best Practice for application re-use?

[stutchbury]

Hi

I've been learning a great deal lately about best practices in design and implementation of business requirements and code (thanks Rod, but I'm struggling to do the same at the 'sysadmin' level.

Using Spring, I havea couple of client applications under development, which may (or may not) be interdependent, but both (and others) will rely on one foundation: the core stuff - authentication, authorization, menus, user/organization admin/structures. Having created this core stuff as a seperate application, I am a looking for advice as to how best to keep it from being 'consumed' by each application built atop it. i.e. I'd like to keep the context, servlet and hibernate definition files independently maintained (as well as the code base).

As I'm fairly new to Spring/JSP/Tomcat, I'm struggling to think of any solution except a fairly complex Ant build file to 'merge' the required files from the seperate applications into one war file for deployment - which is not really what I was trying to achieve. (Although I can't release the client apps, I would like to release the core stuff).

My apologies if this is not all entirely 'on topic' for Spring, but any guidance would be appreciated.

Many thanks

Philip

[Dan Washusen]

Hi Philip,
We have a common project (several actually) that our other projects depend on. The common project generates a jar file and using Maven's dependency management; we include the jar file in our other projects. If your not to keen on Maven for some reason, I believe Savant offers something similar for Ant.

Another alternative could be to include the source from your common project into the current project. This can simplify refactoring between the two projects, but it's really easy to dig yourself a very big hole once several project start using the common project.

Hope that helps.

Cheers,
Dan

[stutchbury]

Hi Dan

Thanks for the response. I'll take a look at Maven. I'm fairly comfortable with the inclusion of common jar files, but not quite so sure how to handle the config files (application/servlet context, hibernate etc) and jsp's, so they are included/merged with the derived app.

I think I should keep my core stuff as a seperate servlet (i.e. merge menu options from derived apps to point at the core 'application' to do user maintenance etc) - perhaps creating taglibs for common stuff?

Philip

[Ben Alex]

We use Maven - it's worth the effort to learn.

For some applications you might find separate WARs a reasonable solution. For example:

security.war: holds a CAS server, and user management tools.
welcome.war: holds an entry page with links to other parts of the application.
gl.war: holds general ledger functions.
invoice.war: holds invoice functions.

You'd use the CAS single sign on solution so the user authenticates once and can move from one webapp to the other transparently. The only issue is each webapp would hold a distinct user session, so you'd need to consider this (session timeout, data that might need to be shared between more than one webapp etc).

[lanala]

We use Maven - it's worth the effort to learn.

For some applications you might find separate WARs a reasonable solution. For example:

security.war: holds a CAS server, and user management tools.
welcome.war: holds an entry page with links to other parts of the application.
gl.war: holds general ledger functions.
invoice.war: holds invoice functions.

You'd use the CAS single sign on solution so the user authenticates once and can move from one webapp to the other transparently. The only issue is each webapp would hold a distinct user session, so you'd need to consider this (session timeout, data that might need to be shared between more than one webapp etc).

Hello Ben,

I know that this post is very old, but today I made a post that is related with your comment. Can you give me your opinion?

Thank you!

Hi,

My company started with a small web application and along the years, new modules appeared and were separated in multiple webapps and multiple tomcat instances. The reason for this is the mature of the modules. The main module is now very stable and we are avoiding to add extra code that could have bugs and affect the performance of the main module.

Now, we are having some problems with remote calls and transaction control along these calls because sometimes we need to call transactional methods that are in other jvm and we use spring remoting to that and we can't have transaction propagation along multiple jvms.

Another problem, resides in authentication. We tried to use single sign-on to take care of the authentication process of some applications (main module + other modules) and we are in troubles because there isn't a simple solution to do that.

Anyone can you talk about this and give me your opinion?

What we can do to solve the architecture problems and what is the best architecture to applications that grows very fast and are critical and so we need to protect the core modules that are stable now.

Thanks in advance!

[dmfrey]

Philip,

I have found that using Spring's Ant-style replacement works great for configuring included components.

I have a jar file that defines it's own spring context. I call this hibernateContext.xml, since it is strictly for setting up hibernate as my integration layer. I also have a default properties file called hibernate.properties that defines common the hibernate properties that I may replace at any given time, ie. dialect, url, username, password, etc.

I can load and run junit tests against this jar file, no problem.

Once I have my jar file, all I do is drop it into my /WEB-INF/lib directory. In my web.xml file I set a context param, contextConfigLocation, that lists all spring context's to load, including "classpath:hibernateContext.xml". In my applicationContext.xml, i define a bean:

<bean id="config" class="org.springframework.context.support.Propert yPlaceholderConfigurer">
<property name="location">
<value>/WEB-INF/hibernate.properties</value>
</property>
</bean>

then when setting up hibernate, the values get replaced by what is in the properties file.
<property name="dialect"><value>${hibernate.dialect}</value></property>

By using this method, I create a new properties file for each application. The backend jar does not change, but each implementation can setup access to its own datasource by just changing the properties file.

The other nice thing about this is once you move from, say, dev to qa to pre-prod, the only thing that changes is that properties file, ie. you could create one for each evironment and change what the applicationContext.xml file loads in each environment.

I hope this helps.
Dan

[stutchbury]

Hi Dan

Many thanks, this is really useful - think I now have a way forward that I feel is maintainable...

Philip

[Dan Washusen]

No probs Philip, I'm glad I could help.

Enjoy, and I hope your re-use is going well

[themlalee]

Many of my modules need to reuse much of the same code that is less features such as database calls or reuse of common views. Here are some ideas I have to help achieve this goal, I wonder what is the best, best practices, your guys opinions, etc.

- The Ground controller, other controllers inherit from this

- A basic model to other models inherit

- Some models require other models

- But the inspectors have little to other models

- Have multiple controllers in a single module

- Having the libraries to make database calls