This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes modeling JSF managed beans on component diagram Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "modeling JSF managed beans on component diagram" Watch "modeling JSF managed beans on component diagram" New topic
Author

modeling JSF managed beans on component diagram

Ronald Wouters
Ranch Hand

Joined: Apr 28, 2005
Posts: 190
Hi all,

in my component diagram I want to model JSF managed beans.
I have the following questions on this:

in the deliverables section for the component diagram, the assignment mentions some example components like jsp pages, servlets, ejb. I was just wondering if a JSF managed bean can be considered to be of the same "level of abstraction" as "servlet" or "jsp page" and therefor a component of the "same size" if you will? Should a jsf managed bean even appear on a component diagram at all ?

If you put a jsf managed bean as a seperate component on a diagram there is another modeling matter that I am a bit confused about. As I understand it, and also after reading this article, components on a component diagram show provided/required interfaces often modeled using the socket and lollipop notation. However, jsf managed beans, don't really seem to have clearly defined provided and/or required interfaces. After all, jsf managed beans or just pojo's with some configuration data (faces-config xml) which are accessed in jsp pages by using jsf expression language tags. The jsf runtime implementation uses JavaBeans conventions and probably a lot of the reflection api to invoke action methods and bean property setters/getters. So as I said, jsf managed beans do not expose provided/required interfaces in the normal sense. The obvious question then is of course, how to model this ? Do you show a lollipop (provided interace) and label it "reflection api" or "JavaBean" or maybe even "EL" (jsf expression language) ?
Any insight on this would be appreciated.

Regards


Sun Certified Developer for the Java 2 Platform
Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5
Juee Doo
Ranch Hand

Joined: Sep 26, 2008
Posts: 232
Good questions. I also want to know
Ashu Sharma
Ranch Hand

Joined: Apr 03, 2001
Posts: 53
Hi Juee/Ronald,
Did you get any answers/insight into this.

Thanks
Ashu
Janis Kazakovs
Ranch Hand

Joined: Aug 13, 2009
Posts: 33
Hello,

From my understanding, you would want to display on your component diagram only these components that are relevant to your application. Since, managed bean is a part of your application I would put it on a component diagram, even though it is just an extension of JSF framework. If you put managed bean component on your component diagram, it, probably, doesn't make sense to show provided interfaces of your managed bean component, since, as you already mentioned, there are many implementation specific details that are not interesting for a reader. However, your managed bean component may rely on a functionality defined in another component, such as business delegate or session facade (depending on your architecture), which specify a provided interface. In this case, a reader might want to know how your components are interrelated and it makes sense to specify a required interface on your managed bean component, which references to a provided interface of another component.

If you want to show relationship between components, but you don't want to specify through which interfaces these components are related, you can simply use dependency relationship. In this case you don't use provided/required interface notation.

Regards,
Janis


SCEA 5.0, SCBCD 5.0, SCWCD 1.4, SCJP 5.0
OMG-Certified UML Professional, Intermediate; OMG-Certified UML Professional, Fundamental
Janis Kazakovs
Ranch Hand

Joined: Aug 13, 2009
Posts: 33
Hello,

From my understanding, you would want to display on your component diagram only these components that are relevant to your application. Since, managed bean is a part of your application I would put it on a component diagram, even though it is just an extension of JSF framework. If you put managed bean component on your component diagram, it, probably, doesn't make sense to show provided interfaces of your managed bean component, since, as you already mentioned, there are many implementation specific details that are not interesting for a reader. However, your managed bean component may rely on a functionality defined in another component, such as business delegate or session facade (depending on your architecture), which specify a provided interface. In this case, a reader might want to know how your components are interrelated and it makes sense to specify a required interface on your managed bean component, which references to a provided interface of another component.

If you want to show relationship between components, but you don't want to specify through which interfaces these components are related, you can simply use dependency relationship. In this case you don't use provided/required interface notation.

Regards,
Janis
Ronald Wouters
Ranch Hand

Joined: Apr 28, 2005
Posts: 190
From my understanding, you would want to display on your component diagram only these components that are relevant to your application.

That was indeed the case for me. The managed beans were "relevant" because, to give just one reason, they made the "connection" with the EJB part of my solution. The "managed" is there for a reason. I felt that, certainly from an architectural point of view, it therefor made sense to show the JSF managed beans in the component diagram.


Regards,
Ronald Wouters
Ashu Sharma
Ranch Hand

Joined: Apr 03, 2001
Posts: 53
Thanks for your input Ronald and Janis.

My Solution is also similar to that of Ronald's. My Solution comprise of following

JSP--->Backing Beans--->ServiceLocator---->SessionBeans----->DAO--->Entities


In class diagram i am planning to show the Session Bean layer and onwards(Boundaries,Controls and Entities only).

Q. Should i include the backing beans also in the class diagram.

In component diagram i am showing All the layers starting from JSP to DAO(and entities)

I am little confused about Sequence Diagram also.

Q. Should it show the JSF controller servlet

user--->controllerservlet--->backing bean---> and so on

or i should ignore the controllerservlet since it is assumed to be there as a part of framework.


Thanks
Ashu

Jason Marston
Greenhorn

Joined: Aug 03, 2009
Posts: 11
Ashu Sharma wrote:Thanks for your input Ronald and Janis.

My Solution is also similar to that of Ronald's. My Solution comprise of following

JSP--->Backing Beans--->ServiceLocator---->SessionBeans----->DAO--->Entities


In class diagram i am planning to show the Session Bean layer and onwards(Boundaries,Controls and Entities only).

Q. Should i include the backing beans also in the class diagram.

In component diagram i am showing All the layers starting from JSP to DAO(and entities)

I am little confused about Sequence Diagram also.

Q. Should it show the JSF controller servlet

user--->controllerservlet--->backing bean---> and so on

or i should ignore the controllerservlet since it is assumed to be there as a part of framework.


Thanks
Ashu



My take on this is:
  • If you use injection you don't need the service locator. (Injection can be shown in a simple annotation)
  • In the class diagram, you show classes that directly relate to or are derived from the problem domain (plus a few orchistrating classes. xxxControler, xxxManager etc). Technology belongs in the Component diagrams
  • In the Component diagram you show all the components, JSP, Session, etc.
  • In the sequence daigrams, you show every class in your design (you may split the sequence diagrams of course to keep the ones representing the use cases simple SSDs)


  • Of course some of the above is different in real life, it seems to me that SUN want the class diagram to be a Technology Independent Design. The Component diagram to reflect the technology design descisions. The sequence diagram to show how all the classes collaborate to get the job done.

    Your language suggests you are using the Rational approach, whilst a good approach, consider if it shows what SUN are asking for on this assignment.

    I don't show on any of my diagrams classes that are a part of the underlying platform or framework I am using. (I show the JSF and the ManagedBean. the FacesServlet is provided and not something you are designing. A simple annotation mentioning the FacesServlet in my opinion should suffice)

    To use your notation I would show

    Actor ---> JSF Page --> ManagedBean --> SessionBean --> DAO --> Entity

    Remember a JSF Page is compiled into a Servlet if it is JSP based. Facelet based JSFs are of course different (and not a core part of JavaEE)

    A final reason I would show the JSF Pages is that the Case Study in the Cade book shows JSPs
    Ashu Sharma
    Ranch Hand

    Joined: Apr 03, 2001
    Posts: 53
    Hi Jason,
    Thanks a lot.
    You have explained everything with immaculate clarity.


    Thanks
    Ashu
    A Amit Ranjan
    Greenhorn

    Joined: Sep 25, 2010
    Posts: 10
    Hi All,
    I got the dreamcar assignment and after looking at the requirements - All of these objects and the relationships between them should be addressed in your design and implementation. I am confused what kind of relationship will be between suspension and request? Break disks has many-to-many with request. If we have to design a generic extensible solution then ideally request could be raised against any item (base class) and subclass being suspension, Breakdisks, Break pads.

    Is it possible to have multiple PO against one request?
    Is it possible to have a supplier that bids for partial items?

    Thanks Amit
    Chiraunji Lal
    Greenhorn

    Joined: Dec 27, 2009
    Posts: 7
    In my opinion these things can be covered in your assumptions section and the design should be done accordingly.

    For example: One can make an assumption that there will be only one PO per request and request will have item of only one kind. Based on this assumption you can design your system.

    Other assumption can be system doesn't allow bid for partial items.

    Any comments???

    A Amit Ranjan
    Greenhorn

    Joined: Sep 25, 2010
    Posts: 10
    Relationship between the domain models should be addressed in your design and implementation- this is written in the assignment. And the model shows some multiplicity. Can I change that?
    Chiraunji Lal
    Greenhorn

    Joined: Dec 27, 2009
    Posts: 7
    I am also working on the same assignment and initially I also had the same confusion regarding the one to many mapping between bid request and purchase order. But going through different threads on the forum I think we can make some assumptions. One which I am planning is to have one to one mapping between bid request and purchase order.

    Any inputs from any experts on the forum?
    jack klein
    Greenhorn

    Joined: Mar 23, 2009
    Posts: 5
    Jason Marston wrote:
    My take on this is:
  • If you use injection you don't need the service locator. (Injection can be shown in a simple annotation)



  • You said that it's not necessary service locator if you use injection. But how do you inject the DAOs in the SessionBeans? I think that you can only inject server resources in Java EE (EJB, DataSource, etc). If I'm right, I think it's better to use ServiceLocator to inject the DAO in the SessionBeans and the SessionBeans in the ManagedBean, because you're resolving the dependies in the same way.

    What do you think?
    A Amit Ranjan
    Greenhorn

    Joined: Sep 25, 2010
    Posts: 10
    Can anybody who has been successful in the exam comment on my question
    prasune john
    Greenhorn

    Joined: Oct 29, 2010
    Posts: 4
    Jason Marston wrote:
    Ashu Sharma wrote:Thanks for your input Ronald and Janis.

    My Solution is also similar to that of Ronald's. My Solution comprise of following

    JSP--->Backing Beans--->ServiceLocator---->SessionBeans----->DAO--->Entities


    In class diagram i am planning to show the Session Bean layer and onwards(Boundaries,Controls and Entities only).

    Q. Should i include the backing beans also in the class diagram.

    In component diagram i am showing All the layers starting from JSP to DAO(and entities)

    I am little confused about Sequence Diagram also.

    Q. Should it show the JSF controller servlet

    user--->controllerservlet--->backing bean---> and so on

    or i should ignore the controllerservlet since it is assumed to be there as a part of framework.


    Thanks
    Ashu



    My take on this is:
  • If you use injection you don't need the service locator. (Injection can be shown in a simple annotation)
  • In the class diagram, you show classes that directly relate to or are derived from the problem domain (plus a few orchistrating classes. xxxControler, xxxManager etc). Technology belongs in the Component diagrams
  • In the Component diagram you show all the components, JSP, Session, etc.
  • In the sequence daigrams, you show every class in your design (you may split the sequence diagrams of course to keep the ones representing the use cases simple SSDs)


  • Of course some of the above is different in real life, it seems to me that SUN want the class diagram to be a Technology Independent Design. The Component diagram to reflect the technology design descisions. The sequence diagram to show how all the classes collaborate to get the job done.

    Your language suggests you are using the Rational approach, whilst a good approach, consider if it shows what SUN are asking for on this assignment.

    I don't show on any of my diagrams classes that are a part of the underlying platform or framework I am using. (I show the JSF and the ManagedBean. the FacesServlet is provided and not something you are designing. A simple annotation mentioning the FacesServlet in my opinion should suffice)

    To use your notation I would show

    Actor ---> JSF Page --> ManagedBean --> SessionBean --> DAO --> Entity

    Remember a JSF Page is compiled into a Servlet if it is JSP based. Facelet based JSFs are of course different (and not a core part of JavaEE)

    A final reason I would show the JSF Pages is that the Case Study in the Cade book shows JSPs



    Hi Jason and Ashu,
    I can see that you guys have used SessionBean and JPA entity in the project.
    In my project (Dream car) it is mentioned that API response time 5 secs or less for 95% of time which means use of an ORM framework like JPA is not recommended.
    Coz it is for developer performance and not application performance. In my design I am using plain JDBC implementation.
    Also, is there a requirement for using session bean? Scalability is not mentioned to be an issue and with the type of application we have, the only bulk operation expected is bidding and rest of the operations will not be happening in much volume.
    So do we require these components (Session bean and JPA entity)?
    my design - Actor--> JSF Page --> ManagedBean --> Service Delegator ---> JDBC_DAO --> Transfer Object representing Entity
    Please let me know your comments....

     
    GeeCON Prague 2014
     
    subject: modeling JSF managed beans on component diagram