Announcement Announcement Module
Collapse
No announcement yet.
Architecture advice involving multiple projects/spring context files? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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

    Comment


    • #17
      Directory Layout - Spring Application with Multiple Functionality / Features /Modules

      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
      Last edited by sincereheart; Oct 20th, 2010, 10:42 PM. Reason: Minor Clarification....

      Comment


      • #18
        "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.)

        Comment


        • #19
          How to organize &quot;ADMIN&quot; / &quot;MANAGE&quot; Module - CRUD Operations

          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

          Comment


          • #20
            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

            Comment


            • #21
              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!

              Comment


              • #22
                It seems good ,thank you! I’ll try!



                To see more, check here:
                http://www.softpedia.com/get/Office-...peg-Free.shtml

                Comment


                • #23
                  Any opinion?

                  Comment

                  Working...
                  X