Discussions

J2EE patterns: A Component Identification Pattern

  1. A Component Identification Pattern (16 messages)

    Pattern Description

    The proposed pattern involves the following steps:
    1. Write the use cases and group related use cases into "apps".
    2. Write event flows for the use cases and identify the "sevices" that each app needs to fulfill its goals.
    3. Group the "services" into "components" using separation of concerns.

    Here is a simple example for using the pattern:

    Consider a simple example of a website that requires its users to register before accessing its resources.

    The first step is to write the use cases:

    1. user -> ( register )
    2. member -> ( access resource ) <3. member -> ( update profile ) <4. member -> ( retrieve lost password )

    We can group the use cases (based on related goals) into the following "apps"

       RegistrationApp (1)
       ResourceApp (2)
       ProfileApp(3,4)

    The second step is to write the event flows.
    The event flow for the first use case can be written as:

    user submits registration form
    system generates a password
    system emails the password to the user
    system creates a member record
    system displays a confirmation page to the user.

    The above event flow suggests that we need the following "services" for
    the RegistrationApp:
       
    - generatePassword()
    - emailPassword()
    - createMember()

    The event flow for the second use case can be written as:

    member requests resource
    system verifies member session
    < system displays resource
    < system displays login form
    member submits login form
    system authenticates the member
    system stores member session
    system displays resource

    The above event flow suggests that we need the following "services" for
    the ResourceApp:

    - verifySession()
    - validateLogin()
    - createSession()
    - getResource()

    The event flow for the third and fourth use cases can be written as:

    member requests profile update form
    system displays login form
    member submits login form
    system authenticates member
    system stores user session
    system displays profile data
    member submits updated profile data
    system verifies user session
    system updates profile
    system displays confirmation page

    member requests lost password
    system retrieves member password
    system emails member password
    system displays confirmation page

    The above event flows suggest that we need the following "services" for
    the ProfileApp:

    - validateLogin()
    - getProfile()
    - createSession()
    - verifySession()
    - updateProfile()
    - getMemberPassword()
    - emailPassword()

    The last step of the proposed pattern is to group the "services" into "components".

    We can now group the above identified "services" into "components" (based on separation of concerns) as follows:

    LoginMgr
    - validateLogin()
    - getMemberPassword()

    ProfileMgr
    - createMember()
    - getProfile()
    - updateProfile()

    ResourceMgr
    - getResource()

    EmailMgr
    - emailPassword()

    SessionMgr
    - verifySession()
    - createSession()

    PasswordMgr
    - generatePassword()

    We now see that the RegistrationApp uses the services of the components PasswordMgr, ProfileMgr and EmailMgr, the ResourceApp uses the services of LoginMgr, SessionMgr and ResourceMgr and the ProfileApp uses the services of LoginMgr, ProfileMgr, SessionMgr and EmailMgr.

    An interesting side-benefit of the above approach is that once the components are identified, it is fairly straightforward to identify the database tables that each component interacts with. Since typically each component interacts with a handful of database tables the domain model can be discovered in small steps.

    Threaded Messages (16)

  2. Missing header[ Go to top ]

    Here is the missing intro to the above posting:

    In J2EE projects it is often required to identify sub-systems and components.

    The BluePrint's Pet Store demo and the Adventure Builder demo provide interesting insights into designing J2EE applications. Inspired by some of the design ideas from these two examples, I have derived here a pattern for resolving a set of use cases into "apps" (sub-systems) and "components".
  3. Well Organized Analysis![ Go to top ]

    I really like seeing an analysis (yours) that is so very well thought out. I'm in the middle of my very first large scale development project. I have been sorting out the architectural requirements in a way similar to yours. I have been grouping business logic into session EJBs, and building a command delegation layer above them to communicate with the web front end presentation logic. The delegation layer is where I control business process workflow, while the EJB session facade is where I place the more finely granular business operations.

    Your pattern has given me a tool to make more refined design judgements.

    Thanks!
    Glen D Lewis
    glen.d.lewis@boeing.com
  4. Data Analysis Approach[ Go to top ]

    A key comment in your approach may be:

    "An interesting side-benefit of the above approach is that once the components are identified, it is fairly straightforward to identify the database tables that each component interacts with. Since typically each component interacts with a handful of database tables the domain model can be discovered in small steps."

    Having worked in the area of large systems development using components for many years, I find that sub-systems/components mostly operate on data with high affinity. So a different approach to identifying possible components is to perform affinity analysis on your business entity model. This will most likely yied the same result.

    Keith Matthews
    Caro System Inc.
    www.carosys.com
  5. This is similar to what Craig Larman writes about in "Applying UML and Patterns". As part of the use case analysis, sequence diagrams depict how the actors interact with the system (ie, to a "System" object). This results in identifying the behavior the system must provide.

    From there, interfaces can be defined by collecting semantically related behaviors. The next logical step is to define the components that realize the interfaces.
  6. <quote by="David Borean">This is similar to what Craig Larman writes about in "Applying UML and Patterns". As part of the use case analysis, sequence diagrams depict how the actors interact with the system (ie, to a "System" object). This results in identifying the behavior the system must provide.

    From there, interfaces can be defined by collecting semantically related behaviors. The next logical step is to define the components that realize the interfaces.
    </quote>

    I am glad to know that the ideas presented here are in agreement with those of a renowned author. I have also found that these ideas are also in good agreement with the "Business Interfaces" and "System Interfaces" concept mentioned in a presentation (http://www.syntropy.co.uk/umlcomponents/elm-sa.pdf) by John Daniels (co-author of the book "UML Components").

    Regards,
    Nalla
  7. Grouping services[ Go to top ]

    The following questions come to my mind.
    a) Are there guidelines as to how to group the services togther? Because while looking at the given example, if there is a service called "Change password" where would it fit? In the "LoginMgr" component or "PasswordMgr" component?
    b) Is it possible to have Componet/sub-component division possible in this design pattern? For example, can "PasswordMgr" component be a sub-component of "LoginMgr" component?
  8. Re: Grouping services[ Go to top ]

    a)The services are grouped based on the "separation of concerns" principle. The "change password" is encapsulated in the updateProfile service and therefore it fits with ProfileMgr component.

    b)Since components are identified based on separation of concerns, the possibility that one component being derived from another would be unlikely.
  9. I have the following comments to make about this approach:
    In my mind, the the last steps of identifying components and "services" they offer would be iterative, and not sequential as portrayed.

    For example: With such an iterative approach, I would refactor the design to make it more cohesive and coarse-grained (Session Facade pattern). Example: validateLogin() and createSession() need not be separate methods, as there is very little point in doing one but not the other. Also we can club their corresponding Manager classes together (except for getMemberPwd()).

    What is your opinion on this?
  10. I agree. When session tracking is implemented using HttpSession object then probably there is no need for a separate component like SessionMgr.

    Nalla
  11. In the example considered for the pattern we discovered components by identifying the services that the apps "need". However, we also need to discover the services that the apps "provide". Interestingly, these services can be discovered quite easily directly from the use cases that the corresponding app is derived from.

    1. user -> ( register )

    RegistrationApp
    - registerAction()

    2. member -> ( access resource ) << include >> ( login )

    ResourceApp
    - getResourceAction()
    - validateLoginAction()

    3. member -> ( update profile ) << include >> ( login ), ( view profile )
    4. member -> ( retrieve lost password )

    ProfileApp
    - getProfileAction()
    - updateProfileAction()
    - validateLoginAction()
    - retrieveLostPasswordAction()

    Please note that I have attached an "Action" postfix for these "exposed services" to distinguish from the "internal services" needed by the apps.

    REFERENCES:
    An interesting discussion on subsystems:
    http://www.therationaledge.com/content/jun_03/t_subsystem_ff.jsp

    An interesting discussion on subsystems and components:
    http://www.arsanjani.org/business-modeling/Using%20Grammar-oriented%20Object%20Design%20(GOOD.pdf
  12. Here is another example, auction web application:
    http://www.mycgiserver.com/~nsenthil/articles/auctiondbdesign.html
    This example also includes identification of database tables.
  13. Please use the following URL if the mycgiserver URL does not work:
    http://www6.brinkster.com/nsenthil/articles/auctiondbdesign.html

    Nalla
  14. Being new to J2EE this pattern is very helpfull. It allows someone to slowly design their application in a structured and logical manner. My question is how do I identify the servlets, session EJB's with the is approach? Do the apps map to servlets, and the components to session EJB's? Someone please explain. Thanks.
  15. Being new to J2EE this pattern is very helpfull. It allows someone to slowly design their application in a structured and logical manner. My question is how do I identify the servlets, session EJB's with the is approach? Do the apps map to servlets, and the components to session EJB's? Someone please explain. Thanks.
    All the components identified by this analysis belong to the business layer (sandwiched between the web and data layers). If you attach a struts based web front end to the "apps" then you would have a set of action classes for each user action. Each one of those action classes then in turn invokes one of the appropriate "apps" identified to accomplish its goal.

    If you want to use EJBs then convert "apps" into session beans and "comps" into entity beans.

    Nalla
  16. But, why we think this as a pattern, and what if we think it as a new architecture or to be more specific as a Service-Oriented Architecture?


    Marduk
  17. But, why we think this as a pattern, and what if we think it as a new architecture or to be more specific as a Service-Oriented Architecture?Marduk
    You are probably right. The thoughts expressed in this note agree well with those of Service-Oriented Architecures. See, for example, Fig. 15 of this article on SOA:
    http://www-106.ibm.com/developerworks/rational/library/content/03July/2000/2169/2169.pdf

    Regards,
    Nalla