aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes design for java application 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 "design for java application" Watch "design for java application" New topic
Author

design for java application

Peter Bergoff
Ranch Hand

Joined: Apr 07, 2004
Posts: 103
Hi everyone,

Regarding how to design for java applications (e.g. swing client). Does anyone know of a book or web url with a good example of how to show this in J2EE design? There's lots of stuff on designing for a web client (e.g. Front Controller, Dispatcher, Service Worker etc . . ) but what about the java app?

Thanks.
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Desinging Enterprise applications with the J2EE platform second edition.
.-The java blueprints should be good enough .
HTH
Dhiren
Peter Bergoff
Ranch Hand

Joined: Apr 07, 2004
Posts: 103
Hi Dhiren,

Thanks for responding!

Is there a particular part of the blueprints which addresses this question? All I see is some really general java app stuff which can't be represented in the assignment diagrams.
[ July 11, 2004: Message edited by: PETER BERGOFF ]
Peter Bergoff
Ranch Hand

Joined: Apr 07, 2004
Posts: 103
Does a java app going directly to the business tier (i.e. ejbs) use classes such as front controllers and business delegates?? In the J2EE patterns these are considered servlets - which won't be available if the client isn't using the web tier.
Darryl A. J. Staflund
Ranch Hand

Joined: Oct 06, 2002
Posts: 303
Hi Peter,

If you read Cade's example at the end of his book, you will see that he distinguishes the client tier from the presentation tier. The client tier consumes business models returned by the presentation tier in a manner specific to the display technology that it works with (ex: HTML, JSP, AWT, Swing, etc.) The presentation tier on the other hand, manages presentation logic common to all client tiers. All client tiers access the presentation tier, but only the presentation tier accesses the business tier.

To clarify this in terms of Java technology currently on the market:

1. JSP, JSF, AWT, Swing, and SWT would be client-tier technologies.
2. Struts action classes, action forward classes, struts-config.xml files
would belong to the presentation tier.
3. J2EE session and entity beans would belong to the business tier.

Hope this helps.

Darryl
Peter Bergoff
Ranch Hand

Joined: Apr 07, 2004
Posts: 103
Hi Darryl,

I agree with you if both the travel agents and customers will be using the web container. But what if the java app is going straight to the ejb container to save netowrk time?
Darryl A. J. Staflund
Ranch Hand

Joined: Oct 06, 2002
Posts: 303
Hi Peter,

I think as long as you are able to justify your decisions from an architectural point of view you will be fine. For myself, I found I had to distinguish client from presentation tiers in order to maximize code re-use and create readable sequence diagrams that didn't have alternative flows for the Java and JSP client.

Darryl
Peter Bergoff
Ranch Hand

Joined: Apr 07, 2004
Posts: 103
So you just showed the "customer" sequence diagrams? I've read of that in here before so I think it could work. What do others think about this approach?
Darryl A. J. Staflund
Ranch Hand

Joined: Oct 06, 2002
Posts: 303
Hi there,

I showed use cases for the JSP client tier but not for the Java GUI client application because I didn't feel that the GUI had been specified to the point where I knew how it should be designed. I know that the JSP and GUI clients share common presentation logic, but I was not told what sort of GUI technology I was to use to draft the application (apart from it being Java).

In general, I took the approach that if requirements were specified or were ambiguous, I would not elaborate on them -- choosing instead to note that requirements needed to be gathered from the client later on. This means that in my case, exceptions weren't handled (since the business logic eneded to resolve them weren't specified), Java GUI design wasn't specified (except to show that it shared presentation logic with the JSP client), etc.

Darryl
Peter Bergoff
Ranch Hand

Joined: Apr 07, 2004
Posts: 103
In a component diagram would you have a front controller and business delegate being used with a java application if the java application is going to the business tier directly?
Darryl A. J. Staflund
Ranch Hand

Joined: Oct 06, 2002
Posts: 303
Hi Peter,

Because I like the idea of distinguishing Client and Presentation tier, I wouldn't have the Java GUI application communicating directly with the Business tier. Rather, I would design the JSP and Java GUI client applications to communicate with the Presentation tier and let this tier make contact with the Business tier.

As a result of this, the JSP and Java GUI client tiers would both use Delegates to communicate with the Presentation tier, but only the JSP client applciation would use a Front Controller. Java GUI clients are usually event driven so they would use a different form of MVC.

Darryl
[ July 19, 2004: Message edited by: Darryl A. J. Staflund ]
Peter Bergoff
Ranch Hand

Joined: Apr 07, 2004
Posts: 103
Is it okay to use a Front Controller with a java application? My java applicationis going directly to the business tier. I honestly don't know that much about java applications and am having trouble finding decent documentation on how to design for them.
[ July 20, 2004: Message edited by: PETER BERGOFF ]
Darryl A. J. Staflund
Ranch Hand

Joined: Oct 06, 2002
Posts: 303
> Is it okay to use a Front Controller with a java application? My java
> applicationis going directly to the business tier. I honestly don't know
> that much about them and am having trouble finding decent documentation.

Hi Peter, I really don't think you have to go through the labor of designing a Java GUI application. It's hard work and is based on an event-driven MVC pattern quite different than Front Controller-based MVC patterns. Take the SCJD certification if you haven't already to see what I mean.

I don't think you need to design a Java GUI application because the requirements don't provide you with nearly enough information to get you started.

I honestly believe that your goal in the SCEA assignment is to design a common J2EE application architecture that will support both a servlet-based client application and a Java GUI-based client application. But you don't have to go so far as to design a Java GUI client to achieve this. You just jave to make sure your architecture can support one when it is developed (after the requirements for the Java GUI have been elicited from the customer.)

Just my two cents.

Darryl
Darryl A. J. Staflund
Ranch Hand

Joined: Oct 06, 2002
Posts: 303
Hi again,

Here's how I tend to view the architecture of a J2EE application that supports multiple client technologies:

a. I'd distinguish the Client tier from the Presentation tier. Client tier applications are responsible for rendering business data according to some rendering technology (HTML, XML, etc.) Presentation tier code is responsible for managing presentation logic common to all client-tier applications of a given project and also for maintaining session state, security, etc. Users interact with client tier applications, client tier applications in turn interact with presentation tier code, and presentation tier code interacts with business tier code.

b. Java GUI client applications will probably use a Page Controller to manage flow because of their event-driven nature.

c. Servlet-based client applications could use a Page Controller (ex: ASP.NET, maybe JSF) or a Front Controller (ex: Struts) to manage flow.

d. Presentation-tier code will probably use an Application Controller to manage flow.

I hope I am not confusing things :-)

Darryl
[ July 20, 2004: Message edited by: Darryl A. J. Staflund ]
Parag Doshi
Ranch Hand

Joined: Jun 29, 2004
Posts: 317
Originally posted by Darryl A. J. Staflund:
Hi again,

Here's how I tend to view the architecture of a J2EE application that supports multiple client technologies:

a. I'd distinguish the Client tier from the Presentation tier. Client tier applications are responsible for rendering business data according to some rendering technology (HTML, XML, etc.) Presentation tier code is responsible for managing presentation logic common to all client-tier applications of a given project and also for maintaining session state, security, etc. Users interact with client tier applications, client tier applications in turn interact with presentation tier code, and presentation tier code interacts with business tier code.

b. Java GUI client applications will probably use a Page Controller to manage flow because of their event-driven nature.

c. Servlet-based client applications could use a Page Controller (ex: ASP.NET, maybe JSF) or a Front Controller (ex: Struts) to manage flow.

d. Presentation-tier code will probably use an Application Controller to manage flow.

I hope I am not confusing things :-)

Darryl

[ July 20, 2004: Message edited by: Darryl A. J. Staflund ]


Darryl,
Did you show these kinda classes (PageController, BusinessDelegates etc) in your class diagram? My concern is : where do I draw the line between showing the core classes and implementation specific classes (Service classes, DAOs, Delegates, Controllers,VOs etc). If I added these later classes, then my class diagram easily spans 30 classes.
Any input would be appreciated.

Thanks,
Parag
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Parag,

After reading some success stories here in the forum I would suggest that only core classes should be shown in a class diagram. Cade is showing also stateless session beans (in his book) so that should be ok. But I definitely would not model J2EE pattern classes/components in a class diagram, component diagram is for that.

Somebody correct me quickly if I'm wrong...

Tomi
[ July 20, 2004: Message edited by: Tomi Tuomainen ]
Darryl A. J. Staflund
Ranch Hand

Joined: Oct 06, 2002
Posts: 303
> Darryl,
> Did you show these kinda classes (PageController, BusinessDelegates etc)
> in your class diagram? My concern is : where do I draw the line between
> showing the core classes and implementation specific classes (Service
> classes, DAOs, Delegates, Controllers,VOs etc). If I added these later
> classes, then my class diagram easily spans 30 classes.
> Any input would be appreciated.

Hi there,

In writing my last post, I only wanted to suggest that there are different types of controllers and that each has their place in a given architecture -- depending on where they are situated and the role they are meant to perform. I was thinking of Peter's question of using a Front Controller when I was writing my response and didn't intend to suggest that such controllers be included in your SCEA component diagrams.

Nevertheless, I did include them in my diagram (well, Front Controller and Application Controller anyway) because I chose to emphasize design patterns in my diagrams moreso than J2EE objects such as Session Beans, etc. Since Front Controller, Application Controller, Page Controller, etc. are the names of roles that classes play in a given design pattern, it was natural for me to include them. I am not advocating that everyone do this, though. It was just the approach that felt most natural to me.

Darryl
[ July 20, 2004: Message edited by: Darryl A. J. Staflund ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: design for java application