Architecture advice involving multiple projects/spring context files?

[constv]

Fatefree,
just the fact that you are so carefully considering all these things tells me that you will do the right thing -- whatever it may be for your particular case. Thoughtful approach based on a carefully designed strategy is the essence of any good architecture and successful project. Thoughtless mimicking someone else's patterns - just "because everybody does it" - is a recipe for failure.

Consider the following approach that should allow you to reuse your context-specific configuration between multiple applications without duplicating it in each application - while still keeping your business modules architecturally pure.

1. Package your business modules as I described above in this thread - without any configuration, to make them truly reusable and self-contained.
2. If you want multiple applications to be able to use the same context configuration (same service implementations, same data source, same data access implementations/hbm configuration, etc.) - without duplicating the config files - wrap each of these "pure" business components into a module that depends on the relevant business components (as jars) and adds configuration - in the resource folder. Obviously, such module would also be a perfect place to keep your specific implementations of services, daos, etc. that are meant to be reused by all those applications that reuse the same deployment context configuration. (The service/domain API should be, of course, defined in your "pure" business modules.)
3. Include the latter (modules with configuration) into your applications as dependencies - not the "pure" modules. (Similar to what you would do with objects when you extract generic functionality into a class and create a "wrapper" class that includes the generic functionality by composition.)

This way, you will have your business components available for potential reuse in any contexts, as well as more context-specific modules that are composed of the "pure" business modules plus context-specific configuration.

HTH,
Constantine

[Fatefree]

Thanks Constantine,

That was exactly in line with what I was thinking of in my second post, about the context project (minus all projects referring to it - the other way around now). Back then, which seems like a long time ago, I couldn't grasp the value of it without understanding the bigger picture.

But its clear to me now, and thats the approach I will take. As a bonus my web project will only have to concern itself with any web tests rather than integration tests, which sits much better with me. And thanks again, I appreciate all of your advice.

[pzoio]

Fatefree,

This is a good discussion because it highlights many of the problems that come up when you try to break up a substantial real world Spring application into reusable chunks.

Something you might like to take a look at is Impala, which provides a lot of support for addressing the types of issues you and Constantine are raising, as well as some simple to use techniques for making parts of a larger application easier to mix and match in different environments and configurations.

Cheers,

Phil Zoio
Impala - modular productivity for Spring applications
http://www.impalaframework.org/
http://impalablog.blogspot.com/

[ivat]

Hi,

Interesting thread. I must accept that I face the same concerns regarding the design of a new spring based application. For the moment, I use a layered architecture (Web / Service / DAO / Model) because, first of all, as ConstV said, it’s a commune practice.
I would really want to understand where to use a layered and when to use a functional decomposition.
I take your example and I create 5 independent maven projects
- common-prj
- user-prj
- bookings-prj
- awards-prj
- web-prj
- pom.xml
In my user-prj I will create com.app.user.model.User (+ service, DAO to handle the User). Let’s say that a User can have a List<Award>. To avoid some horizontal dependency I must create the Award in com.app.common.model ? (You’ve said: “common : entities (entities reusable by all)”). Isn’t this a very permissive architecture? The fact that two functional modules can reference an entity, can be enough to qualify it as a commune entity?

“I don't recommend putting any Spring config files into your business modules.”
Adding AOP your business module implies the writing of some Spring configuration files. Aspects can change (or add functionality to) your business logic, so they have their place (in my opinion) in the same project. I will put the Spring beans configuration in the same project, too. Simply because that, when I define a bean, I need to put the full class name, class which is declared in the same project, and if I rename this class I will see a validation error in my src/main/resource/my-sub-prj-config.xml (the bean initialisation can change, too, imagine that you have to make some attribute as Required).

Please don’t get me wrong, I really want to understand when, why and how to configure a Spring – Maven multi module (multi projects) based application using "Package-By-Feature" approach.

Thanks,
Ivat

[Fatefree]

Well just to answer quickly, for your example I would (and have done, for many similar things) keep User in the common project, and create a new project that depends on common to hold your Awards logic.

Then instead of having a List<Awards> in your User object, I would instead attach a User reference to an Award object. Then you can simply query Awards where User = some user id, and get a list of awards for a particular user. This way the actual user object doesn't need to know anything about awards, but your award service can still provide a list of awards for any user. And of course this could apply for any object that needs ownership by a user.

[ivat]

Hi,

Thank you for your answer.
My problem is that I must design a bottom-up application (based on an existing relational database). Maybe this entity example is a little bit exaggerated.
Yes, I would use the “Package-By-Feature” decomposition, for the applications where the functional business modules doesn’t have a very strong dependency.
If I take a site like Amazon for example, probably I will create:
-Commun-Prj (some utility classes, constant classes, DaoBase or EntityBase classes)
-Products-project (Service / DAO/ model for CRUD operations with all the Products, Categories and so.)
-Orders-Project (having some services to processAnOrder(List<Long> productsIds) ).
-Web-Project

In this case, my Products-project and Orders-Project don’t have anything in common, not even an entity. Every project will have their own unit tests, their own XML config files referenced in the web-application-config.xml (Web-Project) something like that:

<import resource="classpath*: /products-config.xml"/>
<import resource="classpath*: /orders-config.xml"/>

I’ve read something about the decomposition in the “Sun Certified Enterprise Architect for Java EE Study Guide” but some practical example will be much useful.

Thanks again,
Ivat

[sincereheart]

I have been following this thread. I am trying to understand the following message by constv:

>>>>>>Consider the following approach that should allow you to reuse your context-specific configuration between multiple applications without duplicating it in each application - while still keeping your business modules architecturally pure.

1. Package your business modules as I described above in this thread - without any configuration, to make them truly reusable and self-contained.<<<<<<

Understood so far....
In our case we are using: jsp, spring mvc, spring jdbc and mySql with ANT.

We are not using MAVEN or HIBERNATE.....

================================================== ==
================================================== ==

In our case here are some of our functionalities / Business Modules:

1. Transactions (e.g. New Transactions etc).
2. Orders
3. Fees.
4. Shipping.
5. Admin:
>>>> a. Roles
>>>> b. Users
>>>> c. License.
>>>> d. Action.
>>>> e. Bonus.
>>>> f. Commissions.
6. Reports (I guess these can be a separate module.... The reason is that each role will be allowed to view part of a report e.g. certain rows or columns based on their authorizations)......
7. "maintenance-utilities" module: All un-related Stuff. Dummy Test Data CRUD operations etc etc.

=======================================

Apart from the "common" module which will be a directory we will have other directories pertaining to each functionality.

Under Each such directory (per functionality) I am hoping to see following sub directories:

>>>>a. entities / model
>>>>b. persistence or dbms or you may like to call these: dao
>>>>c. services (I am guessing this will contain the business logic).
>>>>d. exceptions
>>>>e. utilities
>>>>f. unitTests (The only tests that belong with a module are unit tests).

So each of these a/m directories will contain the interfaces and implementations.
So for example under "Services" directory we may have its interface and its implementations. (These may be sub - divided into sub directories).
Similarly under persistence we may have its interface and its implementations (These may be sub - divided into sub directories) and so on.

=============================================

webapp
-css
-js
-WEB-INF
- config/...
-config/app-context
>>>> (Consolidate your app configuration, e.g. under the webapp/WEB-INF/config/app-context directory. I prefer to split configuration into multiple files - also based on the functionality and functional domains).
- views (Here we will have sub directories for each functionality. So jsp will be divided into those sub directories accordingly. After we put them into sub-directories as per the functionality, we may also use some pre-fix for the names of jsp as well. But putting these jsp into sub-directories is important).
web.xml

==============================================

INTEGRATION TESTING:

I am trying to understand the following......... in our case we are using ANT instead of MAVEN...... so how will this work in our case....

>>>>>>for integration tests, you could create a special module - that would mock your actual app but without the UI, etc. and have all the required dependencies on your business modules. You could add such maintenance classes/methods to such mock client, run the DB setup before running your integration tests, and then run the cleanup methods.<<<<<<<

>>>>> Just put your test Spring config files into the Resources folder under the test tree, not main. I am assuming you are using the Maven standard directory structure with two distinct source trees: main and test. If not, use it. It will solve your problem. Put any config files you want under the test tree, in "resources". They will be invisible to your "main" source code.
<<<<<<<<<<

================================================== ==
================================================== ==

>>>>>>
2. If you want multiple applications to be able to use the same context configuration (same service implementations, same data source, same data access implementations/hbm configuration, etc.) - without duplicating the config files - wrap each of these "pure" business components into a module that depends on the relevant business components (as jars) and adds configuration - in the resource folder. <<<<<<<

I am sorry for not understanding this...... How to wrap....... into a module..... I will appreciate if some one may post some examples of this wraping......and concept of module..... my knowledge of java is little rusty..... I thought java does not have any thing known as "module".... instead in java they use "package"..... I am little lost here....

======================================

>>>>>
Obviously, such module would also be a perfect place to keep your specific implementations of services, daos, etc. that are meant to be reused by all those applications that reuse the same deployment context configuration. (The service/domain API should be, of course, defined in your "pure" business modules.)
<<<<<<<<<<<

How to do the above.... any example / explanation for easy understanding please....

========================================


>>>>>>>>>>>>3. Include the latter (modules with configuration) into your applications as dependencies - not the "pure" modules. (Similar to what you would do with objects when you extract generic functionality into a class and create a "wrapper" class that includes the generic functionality by composition.)

This way, you will have your business components available for potential reuse in any contexts, as well as more context-specific modules that are composed of the "pure" business modules plus context-specific configuration.

HTH,
Constantine <<<<<<<<<<<

Again... some examples will help in understanding this better.

===========================================

One thing I am still not sure about is the Admin / CRUD operations for each "Functionality"..... The main / primary user of the CRUD operations will be the site admin / assistant admins.....

Whereas the main users of each of the "FEATURE / FUNCTIONALITY" will be standard users..... So will I still be putting all the admin related stuff pertaining to the CRUD operations of each such module / feature / functionality under it (rather than have a completely separate Admin Module which spans across all the other modules.....)...

So if this be the case then under each FEATURE / FUNCTIONALITY I will also have a sub directory with the name == "Admin".

Please confirm my understanding on this....

or else Please advise. Thanks.

Sincerely,
Ahmad

[constv]

"Modules" in this discussion do not relate to java packaging. It is more of a dev project organization/distribution/deployment related concept. For example, a module may represent an archive (after it is built - jar, war, etc.) or an aggregation of other modules. Maven operates on a Project Object Model (POM). Within this concept, a "module" essentially defines the content (Java sources, resource files, tests, etc.), dependency libraries (potentially, other modules that will be packaged as jars), build strategies, etc. It does not matter whether you use Maven, Ivy, or Ant to build your projects. You need to organize the projects as "neat" building blocks with uni-directional dependencies, where each such building block/module is built the way you want it, and other modules that need its functionality are able to use it as a dependency. Getting familiar with Maven may be very helpful - if only to better understand the general concept of dev project organization and currently accepted standards. (Unlike Ant, Maven is a powerful development project management tool, not just a build tool.)

I hope understanding the issues of project organization (perhaps, using Maven strategies and concepts as a good example) will help...

(I'm planning to put together some notes that describe the issues in detail - with examples, but, unfortunately, I just don't have time right now. When I do, I will post it and provide a link.)

[sincereheart]

Hi Constantine,

Thanks for the kind reply.

Here is my understanding on ADMIN module:

ADMIN MODULE:
Earlier I was not sure how do we go about the admin module thing....
As I have read more, in the light of keeping less dependencies, each of the functional module will have its own CRUD operations under its own "ADMIN" sub directory. Another name for this may be: "Manage"..... Which ever one may like to call it.

So once again:
Each of the Functional Module will have a sub directory called either "ADMIN" or "MANAGE". This will have its own CRUD operations.

So the fact as to who is "AUTHORIZED" to do those CRUD operations will be controlled via SPRING ACEGI Security.

Additionally we are going to have a matrix GUI that will be managed by the ADMIN to control all such "AUTHORIZATIONS".

I am guessing that code which handles these authorizations / spring security will be under the "COMMON" module.

================================================== =====

COMMON MODULE:

I guess those things that are common to the whole application will go in the COMMON module. This will also have its own ADMIN or MANAGE sub directory to handle its own CRUD operations.

So the next question is what all will go under this "COMMON" module.

a. Spring Security and Creation of ROLES, USERS and their authentication.
b. Spring security of the above and their "Authorizations".
c. Any ideas on what else....

Ahmad

[constv]

Ahmad,
I think understanding the principle of module organization by domain (aka by feature) - rather than by tier - should alleviate much of your confusion. Try to reread the thread carefully. The common module should simply contain any interfaces, classes, utilities, etc. that do not fall into any particular business domain/feature category but rather should be shared between all or many domains. It also may define the library dependencies that you'd want all of your other modules to "inherit" when they define the dependency on the common module. It may or may not be a good idea to include Spring Security, or Spring, into the Common module - depending on whether all your other modules use Spring. Often, business modules consist only of POJOs without any Spring dependencies - unless they use Spring annotations or some Spring tools/API. For example, all your business services may need to use Spring's @Transactional and @Secure annotations, etc., and in that case, it would make sense to include the appropriate Spring/Spring Security dependencies into the Common module. Your Application Administration functionality seems to be a well-defined functional domain in its own right - if I understand it correctly. If you have custom security implementation (some authentication service/handlers, etc.) you can have a dedicated module for that. That module would depend on Spring Security libraries. Other business modules that use security would use that security module as one of their dependencies. Analyzing and working out the optimal dependency graph for your application is, actually, one of the most essential parts of the application architecture design - something that is often overlooked and under-appreciated. If you get that right, everything falls into places, and the application starts writing itself.

Your CRUD operations belong in the data access tier of each functional domain that uses data access. So, you are generally on the right track placing that functionality inside each domain. However, I wouldn't view that as some kind of "admin" or "management" functionality. Instead, data access is just an implementation detail of your business functionality. So, if you have an Orders business domain module, your orders-related CRUD implementation should live inside the Orders service/dao layer. You've mentioned that you are using Spring JDBC. In that case, your data access will live in you Spring JDBC DAO implementations that are probably injected into your business services. Correct? (Use a service API to expose your business use cases, and the DAOs within the service implementations to implement the data access functionality.) In terms of packages - assuming you use services and dais, it may look like this:
com.yourcompany.orders.service.dataaccess...

I am awfully busy these days, and I may not be able to answer every question you have. Just try to carefully analyze the functional areas in your system and draw a dependency graph. Don't be afraid to invest some time and effort in this task. You may find that some concepts need to move from one conceptual module to another so they could be reused, so that circular dependencies are eliminated, etc. It takes more than a few iterations, usually, to get it right. Don't rush into coding. Have a clear architectural concept of your system first. Don't be afraid to refractor it later. Refactoring is good. It's an essential part of a healthy development process. I think you are on the right track. Good luck.

-Constantine