aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Thin Client/Fat Client? 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 "Thin Client/Fat Client?" Watch "Thin Client/Fat Client?" New topic
Author

Thin Client/Fat Client?

Philip Pomario
Ranch Hand

Joined: Oct 03, 2003
Posts: 113
Guys, the system requirements states that response time should be very fast and that a "graphical user interface" must be available to a special type of user.

The main question is: What is your understanding of a "graphical user interface"? Is it obligatory to be a standalone fat client (such as Java Swing apps)? Or could it be a webapp running on a very small container (such as Jetty)?

Your comments are much appreciated.
Ricardo Ferreira
Ranch Hand

Joined: Feb 13, 2006
Posts: 156
Originally posted by Philip Pomario:
Guys, the system requirements states that response time should be very fast and that a "graphical user interface" must be available to a special type of user.

The main question is: What is your understanding of a "graphical user interface"? Is it obligatory to be a standalone fat client (such as Java Swing apps)? Or could it be a webapp running on a very small container (such as Jetty)?

Your comments are much appreciated.


Philip Pomario,

The key of the assignment is judgement tought about the architecture. You should take your good sense about what must be done based in your interpretation. It is just a tip ok, in the next few lines, i'm going to answer your question.

IMHO, when someone tell me about a "graphical user interface", i see two kinds of applications: web interfaces and desktop interfaces. The fact the some application is graphical based, does not means that it should be swing based nor other client of desktop applications (non web interfaces).

It is true that you can provide a graphical user interface using web clients, because even the runtime is a browser, but it is a graphical user interface. A non graphical user interface could be the mainframe green screens, or cobol based applications.

Now, when someone says that the applications must have a very short response time, this is a tip about what kind of application must be created. If you think about it, using a web application running in the same application server that runs the logic code (EJB Layer) must provide more performance rather than a remote desktop application based on swing, that would make use of network bandwith and complex protocol transformations (RMI/IIOP, SOAP, XML-RPC).

So, I would create a web application for that, since provide more performance rather than a desktop application. If this application would be used only at the network, a load balancer could have some logic that won't use DNS or Firewalls, using instead, direct IP address, provinding shortest response time.

Based on that, use your architect judgement

Regards


Ricardo Ferreira,<br /> <br />Sun Certified Enterprise Architect<br />IBM Certified SOA Solution Designer<br />IBM Certified RUP v7.0 Solution Designer<br />IBM Certified Specialist for RUP v2003
Ben Two
Ranch Hand

Joined: Jul 06, 2007
Posts: 35
Hi Philip Pomario

In a Fat Client, like a Swing application, the dataset can be cached in client JVM, that means most of the time it does not need a communication to server, only load the initial data when the application starts and then periodly refresh the data, and finally connect to server when transaction commit.In this case the response time will be much more faster than a web application like JSP or Servlet, because theoretically we only need twice connection to the server, start up and commit.
Ricardo Ferreira
Ranch Hand

Joined: Feb 13, 2006
Posts: 156
Originally posted by Ben Two:
Hi Philip Pomario

In a Fat Client, like a Swing application, the dataset can be cached in client JVM, that means most of the time it does not need a communication to server, only load the initial data when the application starts and then periodly refresh the data, and finally connect to server when transaction commit.In this case the response time will be much more faster than a web application like JSP or Servlet, because theoretically we only need twice connection to the server, start up and commit.


Ben,

I disagree with your point of view about thin or fat clients. IMHO, there is no fat client concept when you are using three tier approach. The three tier approach says that the client MUST be thin because the whole processing, management and EIS access are concentrated at the middle tier, which means that the j2ee application server handle the heavy stuff.

And there are some architectural considerations about cache data at the client tier. This is not prohibited, but should be used with some constraints. If you cache business data at the client tier, you could potentially compromise the reliability feature of your solution, since a crash ocurred at the client tier could loose the whole data.

This is the reason for SFSF usage, when user access data must be cached to improve performance and reduce the network calls. So, I would recomend you that pay some attemption about data caching, because client caching are not a robust solution, as the application server provide for you.

And, IMHO, i believe that a web application running at the same application server that the ejb components reside are so much more faster, because you could use features like local calls instead remote calls that are expensive for the application server, since protocol transformation are required.

Regards,
Ben Two
Ranch Hand

Joined: Jul 06, 2007
Posts: 35
Hi Ricardo

I'm not going to talk too much about using a FAT client in a 3-tier architecture while your opinion is we MUST use THIN client. Because this is not an absolute question. But in my experience we did use FAT client in a 3-tier by a MDA, RAD, MVC approach and it's a mature architecture.

Let's focus on the original question, I understood that we'd better comment on whether a Swing application client or a web client should be used for the GUI requirement. IMHO, definitely we'd better use the Swing client. Put web tier and ejb tier in the same machine can improve the performance, but this is not a good idea for a distributed, well scaled system. The biggest advantage for a Swing client is, only business layer data is transmitted, while much more data should be downloaded by the web client.

Actually, the anwser is quite obvious for the assignment, otherwise there is no agent or customer, only users.

kind regards
Ben
Gabriel Marussi
Greenhorn

Joined: Jun 17, 2006
Posts: 1
Frase descrita no documento Instructions do SCEA 2:

" Your architecture and design will be graded on how well it supports both web clients and appication clients, as well as, supporting all of the requirements"

L�gico que voc� vai preferir utilizar o protocolo de comunica��o http para prover acesso os dois ou mais tipos de clientes. Prepare a sua arquitetura com Servlets e descreva os JSPs utilizados, eles pedem no exame.

"what EJBs, Servlets, and/or JSPs migth be needed"

Gabriel Moreira Marussi
Philip Pomario
Ranch Hand

Joined: Oct 03, 2003
Posts: 113
I really appreciated hearing all of your opinions! Now I can make more educated decisions on my project's solution, thanks!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thin Client/Fat Client?