Some questions regarding part II

[Antoni Mysliborski]

Hello!
I am slowly finishing my project (I want to send it on Thursday), and I have some questions for which I couldn't find a specific answer for in forum. I know that no one can give me definite answers, but at least please try to write what do you think - especially those of you who did similar and passed.

Class diagram
1). Inclusion of backing beans (JSF)
I did my class diagram similar to Cade's example, with JSP pages and one big Controller box. But as I can see, most of the people are including backing beans in their solution. Therefore my question is, how do you do it? Do you provide one backing bean for each JSP page? What with related pages (like "list.jsp" and "details.jsp" used in one UC and using one EJB bean)? What happens with "Controller" block in such case? Do you show the connection between each backing bean to appropriate EJB or do you use this Controller anyhow? What with "framework agnosticism" in such case?

2). Business interfaces
Do you show each BI for each EJB on diagram? How? Often for interface you are using the class symbol with a "interface" stereotype, although I don't like this idea, as it will just clutter my class diagram without providing any additional information (as there will be only one realization for each interface). In StarUML there is a circle for Interface with name, is it enough? Or maybe it is enough to mention in notes to class diagram that each bean has corresponding BI and it is injected by it?

Component diagram
I would like to follow Cade's example and provide quite high level view of the system (for example component will be "Bill view"which comprises of list of bills page, details page and corresponding backing beans etc) . But in the requirements they mention as examples of components individual JSP pages or EJB beans. Also many people on the forum have listed everything there. I believe that this way Component Diagram will be very similar to Class Diagram. Do you think that this level of details I've mentioned will be ok?

Thanks in advance for your insight.

[Arnold Reuser]

Related to the following question :

Do you provide one backing bean for each JSP page?

While implementing the mvc pattern on page level. You will recognize there is a problem related to a single backing bean per page.
This because both model and controller elements are combined in one backing bean. Therefore using a model - and controller backing bean per page
will improve your separation of concerns.

What with related pages (like "list.jsp" and "details.jsp" used in one UC and using one EJB bean)?
What happens with "Controller" block in such case? Do you show the connection between each backing bean
to appropriate EJB or do you use this Controller anyhow? What with "framework agnosticism" in such case?

You could resolve this by using the following approach :
backing bean -> business delegate -> service locator -> session facade -> application service.
All backing beans use the same delegate.If your session facade is sufficiently coarse grained it will cover multiple use cases.
This is a pattern oriented - and framework agnostic - approach.

[Antoni Mysliborski]

Ok, for model I have entities, I will use JPA, and both web and logic layer will be deployed on the same machine, so there should be no problem with this.

But I don't get how this will help me to keep the diagram web-framework agnostic (if I would put backing beans on it).

About proposed patterns, most of them are obsolete in JEE5 and I believe that using pattern just for the sake of using patterns is a serious mistake.

But my question is if someone has sent the solution without mentioning individual backing beans, or if you did mention, did you keep the general Controller (which is present in JSF, but is a part of the framework), or just backing beans communicating directly with EJBs (for sure I don't want to introduce BD and SL patterns, I think that DI with Business Interfaces provides much better separation of concerns and in much smarter way).

[Arnold Reuser]

About proposed patterns, most of them are obsolete in JEE5 and I believe that using pattern just for the sake of using patterns is a serious mistake.

Before stating something like this. Be sure that your facts are correct. Especially because I've spend some time on trying to help you out.

[Antoni Mysliborski]

Ok, sorry, I didn't mean to sound offensive, I just referred to the reasoning that this way I will have pattern oriented approach. Though indeed I could have chosen more polite wording.

Though I still believe that those patterns in JEE5 are not necessary. Even SessionFacade doesn't seem to be useful, as I don't have any common processing (I will use JAAS and manual checking of access rights to particular entities).

Anyhow, thanks for your insights. Discussion is always valuable, even if it's outcome is just self-confirmation

[naresh kumar nand]

But if JSF is used FacesServlet will act as controller and all the requests are directed to FacesServlet. Based on the request backing bean per page can be invoked and in turn it invokes SLSB. SLSB uses JPA entity from that is copied to data class is again given back to the backing bean.

Even in DukesBank example it is mentioned similar manner.

In case of list.jsp and details.jsp. If there is A1-*B
list.jsp
while displaying all A's fetch of entity A along with B will have FetchType.LAZY.

details.jsp
using id fetch entity A and along with B

Does anyone see any problem in this?

[K Zhang]

1. I also came across similar issues when I was working on the JSF design part. (I'm still working on it now)
My solution was to mention that JSF implicitly uses Controller. But I didn't add the FacesServlet to any of my diagrams.
EJBs are injected into backing beans directly in my design. One backing bean is used for each JSP page.
I believe this is one of the correct ways to do it.

2. I didn't show the interface for EJB in the diagram. Instead, I mentioned it in the design.

3. Component diagram from the book seems not detailed enough. I still need to work on my assignment to find out which level of details is proper. In my opinion, you need to understand what information people need to get from your diagram. If there's some important information missing in the component diagram, then you should elaborate it further. Otherwise, it's also Ok to adopt the diagram from the book.