WAF or JSF in SCEA 5 Part 2

[Denis Meleshko]

Hi everybody!

I've got an Assignment (SCEA 5 Part 2) recently. It is web application. A simple web shop. Can I use WAF instead of JSF in my design?
I'm asking because almost everybody here used JSF in their assignements.
May be Sun expects JSF or it doesn't matter ?

May be somebody successefully passed Assignment without using JSF ?

Thank you, ranchers, in advance !

[J J Wright]

It shouldn't be a matter of what everyone else is doing. JSF is part of J2EE so you're free to do what you like with it. The real issue is what are the pros and cons of each approach with regards to your design and it's on going maintenance. Make a decision based on that then document it in your assumptions.

[Ronald Wouters]

My assignment says

The architecture must be based on the Java™ Platform, Enterprise Edition (Java EE) platform.

If your assignment has that phrase too, then I suggest you *only* use official JEE technology. Better to be safe than sorry ...

Regards

[Hong Anderson]

How do you know that almost everybody here used JSF in their assignements? That is new to me, and surprised me.

And I don't understand that from architecture and design artifacts how do we tell that this architecture and design use which web MVC framework? You will write a comment states that you use JSF or something?

[Ronald Wouters]

You will write a comment states that you use JSF or something?

No, not a comment. However, on my component diagram I have a component with stereotype "JSF Managed Bean". Also the FacesServlet appears on my component diagram.
Both things clearly indicate that the JSF framework is being used.

[J J Wright]

And I don't understand that from architecture and design how do we tell that this architecture and design use which web MVC framework? You write comment "I use JSF" or something?

In my opinion the written assumptions are just as important, perhaps even more so, than the diagrams. Of course, if you're using JSF you're going to state than in your assumptions, use of design patterns, etc. The component diagram would also be a bit of a give-away if you've got a faces servlet, data and controller backing beans etc. Your activity diagrams would also reference the JSF lifecycle phases, perhaps including listeners, converters, validators etc.

If your assignment has that phrase too, then I suggest you *only* use official JEE technology. Better to be safe than sorry ...

Since when was JSF not part of the J2EE spec? http://java.sun.com/javaee/technologies/

I think the relevant word here is "based". As an example, I don't think there'd be anything wrong with using a framework like Facelets. Facelets is clearly based on APIs contained in the J2EE spec. If you justify all you're decisions and explain why you think they conform to requirements I don't see how they could argue against it. After all, if their intention was to prohibit the use of any framework or third-party Java APIs they'd have said something along the lines of "your solution must use only those APIs contained in the J2EE spec". That's the kind of language they use in SCJD assigment requirements. They're giving us the leeway to come up with a practical solution, not putting a straight jacket on us.

Anyway, that's just my opion!

[Denis Meleshko]

Ronald Wouters wrote:

You will write a comment states that you use JSF or something?

No, not a comment. However, on my component diagram I have a component with stereotype "JSF Managed Bean". Also the FacesServlet appears on my component diagram.
Both things clearly indicate that the JSF framework is being used.

Yes, you are absolutely right. If I choose JSF, I'll mention it on my componet diagram.

[Denis Meleshko]

Ok, thank you guys!
I think I'll make a good choice!

[Hong Anderson]

Ronald Wouters wrote:

You will write a comment states that you use JSF or something?

No, not a comment. However, on my component diagram I have a component with stereotype "JSF Managed Bean". Also the FacesServlet appears on my component diagram.
Both things clearly indicate that the JSF framework is being used.

Right, that is a way to indicate you use JSF. But I don't sure that if what you think to design is too detailed.

[Ronald Wouters]

But I don't sure that if what you think to design is too detailed

Regarding the component diagram my assignment states :

... Examples of components are Enterprise JavaBean™ (EJB™), servlets, JavaServer™ Pages (JSP™), major Plain Old Java Objects POJOs), and important Managers / Controllers / Design Pattern implementations

I admit, it doesn't mention anything about jsf managed beans or jsf at all for that matter.
However if you look at this blueprints article on using JSF : https://blueprints.dev.java.net/bpcatalog/ee5/persistence/ejbfacade.html#using_jsf you will see that jsf managed beans play the same "role" if you will, like servlets do in a non-jsf application, in connecting web/presentation-tier components with business-tier components like ejbs. Also, in the latest version of the petstore application you will notice that jsf managed beans are often used as "Controllers" which is mentioned in the assignment. When you look at these aspects I don't see how you could decide not to show a jsf managed bean on the component diagram when you're designing an application that uses jsf, considering also that you probably will not have (m)any servlets to show on your diagram (well maybe except for the FacesServlet frontcontroller that is).

Regards

[Hong Anderson]

Actually, components in UML 2 can be almost anything.

I don't have much knowledge about JSF, is it a very unique framework?

I mean when I design I'll specify only that I use component-based or request/response-based web MVC framework.
I don't focus about web MVC part much, because I don't design a web MVC framework.

But if JSF is very unique, using JSF will impact architecture and design in other tiers/layers, I agree that we should specify that we use JSF.

But if using JSF (or Struts, Spring MVC, Tapestry, WebWork, etc) or not doesn't impact other parts of architecture and design, I can see no reason to specify that we use which framework.

[Ronald Wouters]

The whole purpose of setting up an architecture and making a design is to guide/set guidelines for the development team(s). They should be able to look at the architecture and design diagrams and have that "ahah" moment of realizing "hey, ok so that is what we are supposed to implement, piece of cake"
If your architecture and design documents/artifacts/diagrams don't mention the actual technology being used by the system like Struts or JSF or whatever, then in essence you are leaving it up to the developer teams to pick and choose a technology as they see fit. This kind of decision, in my opinion, is a decision to be made by and is the responsibility of the architect of a system and he or she has to be almost an evangelist when it comes to defend that decision.

[J J Wright]

But if using JSF (or Struts, Spring MVC, Tapestry, WebWork, etc) or not doesn't impact other parts of architecture and design

It's good to hear someone else is looking at using third-party MVC frameworks. What I've found incredibly frustrating the past few days is the lack of real information, i.e. performance metrics, re JSF. I'm being asked to create an application where the number one NFR is performance; so that kind of info would be pretty handy! Why don't Sun publish this kind of stuff for their reference implementation? It's also virtually impossible to find information about the caching of JSF dynamically generated content. If you search the JSF spec the words 'cache' or 'caching' don't even get a mention! I'd like to be able to make an informed decision but it's pretty hard. In the end I'll end up opting for JSP + existing MVC2 framework because I know it works and I know it can be easily cached. I've also read a couple of horror stories about memory usage and poor data table performance for some JSF implementations - Not good!

[Ronald Wouters]

Jonathan Aotearoa wrote:In the end I'll end up opting for JSP + existing MVC2 framework because I know it works ...

Can you explain what you mean by "In the end" ? Do you mean that the technology you choose is something you "just mention" in your assumptions list ? Do your diagrams show no technology specific components ?
Surely, given that a design is something to be "given to" development teams to be implemented, it should mention the technology being used (in the diagrams) and not be an afterthought mentioned in the assumtions and/or risk list.
Did I misunderstand you perhaps ?

[J J Wright]

Can you explain what you mean by "In the end" ? Do you mean that the technology you choose is something you "just mention" in your assumptions list ? Do your diagrams show no technology specific components ?

The technology you use will obviously have huge implications for how you architect a solution. "In the end" was just a statement born out of frustration at having found so little information of substance on issues like caching and performance with regard to JSF. After a little reflection I've decided to invest time in investigating what some people have called the JSF/JSP mismatch. This article also talks about the mismatch between how JSP processes a page and how JSF creates a component tree.

I also intend on investigating the implications of not being able to wrap a custom tag around flushed content. This has big implications for how you structure your pages. As I see it you basically have two options when it comes to caching dynamically generated content: a custom body tag which caches it's body or a servlet filter which caches the entire page. However, I've read some forum postings in which people have found JSF tag implementations with a hard-coded flush attribute value of true.

I may be getting bogged down in detail / going on a slight tangent, but I'm trying to use SCEA as more of a learning experience than a means to end, i.e. not just getting a piece of paper saying I'm SCEA. In my view having a real and grounded understanding of caching issues is critical so I don't see time spent investigating this as wasted. Plus it will all go into to my justifications for using, or not using, a particular technology.

So to answer your question I will be making it very clear both in my diagrams and in my assumptions which technologies / frameworks I'm using. I'll also be listing any critical issues and/or constraints that that may impose on developers.

[Lann Lu]

I very much agree with Jonathan!!!

Btw,
1. I personally will use JSF + Facelet (or JSF 2.0)
2. What is WAF?

Thanks,

[Denis Meleshko]

WAF stands for Web Application Framework