modeling JSF managed beans on component diagram

[Ronald Wouters]

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

[Juee Doo]

Good questions. I also want to know

[Ashu Sharma]

Hi Juee/Ronald,
Did you get any answers/insight into this.

Thanks
Ashu

[Janis Kazakovs]

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

[Janis Kazakovs]

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]

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]

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]

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]

Hi Jason,
Thanks a lot.
You have explained everything with immaculate clarity.


Thanks
Ashu

[A Amit Ranjan]

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]

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]

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]

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]

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]

Can anybody who has been successful in the exam comment on my question

[prasune john]

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....