EJB design: Domain Object and Service oriented pattern

  1. Domain Object and Service oriented pattern (1 messages)

    We have J2EE based application with following components, we are facing some issues with existing system.

    Current System : We have J2EE based application. The following is the flow.
    Client Layer [including JSP, Struts ] action classes  Delegates  Session façade [Session bean]  DAO EJBDAO  EJB. We use CMP, xDoclets , JBOSS.

    1. Our Domain objects are heavy. I know they are suppose to be coarse objects but they take more time in loading. Also, we noticed one thing that lot of methods are called during Domain Object creation process and it takes lot of time in loading. Actually, we dont really know what is happening as we are using CMPs.

    Question :
    - Any input on what can be done to avoid Domain object excessive loading time.
    - Anyone can share there experiences with Domain objects. Are you facing issues related with performance.
    - We dont use DTO, we pass domain objects between. Do you see any problem in doing that.

    2. Currently, our system was used by one single front end or lets say we have only one client but soon we will have more clients using it.
    Question :
    - What should be our design approach. How can we make our system more like service oriented. If the two clients demand different business logic then how it will be handled. Business logic common to all the clients will be handled by which layer and business logic specific to client will be handles by which layer.
    - Please suggest based on our existing infrastructure. We don’t want to use SOAP or cannot make drastic changes to our flow.

    We have domain and services in the same package and we are doing the refactoring of code, your inputs will be valuable.
  2. 1. My guess is that the domain objects that are getting used are very large objects with lots and lots of nested objects inside them. Are you trying to load these objects to show them as a list to the user? If so, recommend use of JDBC reader pattern to directly load from the database and show it on the screen. That speeds up things a whole lot.
    2. The other approach that we can use is the CustomDTO or DTOHashMap patterns that are listed in the EJB patterns book. These custom dtos can lookup only the info required for that operation as opposed to the whole of the info. For eg, if we have a huge Person domain object and if we want to do something with his name, there is no point loading a ton of objects that describe the courses he has enrolled in - his spouse info - his address info and all that!
    3. Try constructing the domain objects outside of the container - and see how much time it takes.
    4. All else fails - use a profiler like performasure or something.

    Custom logic for each client - can be done using a base class (abstract) that defines the operations that need to be accomplished and we can have a factory object that constructs the right implementation based on some criteria - like say client type? The custom implementations should be subclasses of this abstract class and the factory creates the subclass instance using reflection. Generally all these solutions are hard to maintain - it may be better off maintaining different business logic objects and statically link them to the right place.

    Just some ideas! All the best!