Why Swing client at all?

[dieman nambawan]

There has been a lot of discussion about the architecture for the swing client. Many posters seem to presume that a application client must be a part of the architecture.

On the other hand, the requirement(as far as I can see) do not imply necessity of such a client. We are only told that travel agents will get graphic terminals, that's all. Also, need to interface the TransMaster's web interface implies availability of a TCP/IP connection at such a terminal.

Thus, we have a graphic terminal that can (apparently) run a JVM and is connected to a TCP/IP LAN. Why can't one assume that such a terminal can run a web browser and give the travel agents a web interface similar to that given to the internet users?

[kaiser eblovich]

Two points for you to think about.

1. They say "FBN would like to make the user interface more appealing for their travel agents by replacing the 3270 terminal with one that can support a graphical user interface". Graphical user interface -> GUI client -> Swing. Though one might argue (and I even would agree to) whether a browser is sort of graphic user interface as well, especially with advent of RIA and alike, but it's clearly not what they meant then back in 2001 when this certification was planned.

2. Everyone I know who passed SCEA (including myself) did use Swing client.

[Hitry Mitry]

Dieman,

I have same doubts. A web browser definitely is a sort of graphical interface, those of us who ever used a VAX terminal or the old IBM PC computers would know the difference!

I guess it's just inertia of the "Pet Store" application that many people use as an example?

Wonder whether someone has skipped the swing client and got away with it??
[ July 13, 2005: Message edited by: Hitry Mitry ]

[Mahesh Kumaraguru]

Hi,

Swing client comes under the category of thick client and an architect should be able to use thick client where appropriate. There are lots of debate on the net regarding thick-vs-thin client and we accept the advantages & disadvantages of thick client. If the travel agents are also made to use a web browser ( thin client ), then what would be the use of travel agents getting new graphics terminals ? Plus travel agents access the TransMaster's interface on a LAN and if we use Swing client, then as part of security, these clients will not be accessible outside the company's LAN whereas the browser client would be accessible anywhere on the internet.
[ July 13, 2005: Message edited by: Mahesh Kumaraguru ]

[vu lee]

guys,
The instruction requires that a travel agent must have the fastest system to meet the customer expectation. If the travel travel agent uses web browser, what he will get is equivalent to the regular customer. By bypassing the layer of web interaction, eg https protocol,servlet, etc., swing client can gain certain advantages.

[Hitry Mitry]

Originally posted by Mahesh Kumaraguru:


Hi,

Swing client comes under the category of thick client and an architect should be able to use thick client where appropriate. There are lots of debate on the net regarding thick-vs-thin client and we accept the advantages & disadvantages of thick client.


With all respect, this point has nothing to do with the FBN requirements and is purely speculative.


If the travel agents are also made to use a web browser ( thin client ), then what would be the use of travel agents getting new graphics terminals ?


Coz you can't run a web browser on a text-mode based terminal, obviously!!


Plus travel agents access the TransMaster's interface on a LAN and if we use Swing client, then as part of security, these clients will not be accessible outside the company's LAN whereas the browser client would be accessible anywhere on the internet.

This point has some validity to it, BUT! If both the the travel agents and customers over the Internet get a web interface, this does not mean that it must be THE SAME web interface! These can be two DIFFERENT web applications, each talking to it's own set of EJBs etc. But both applications can be based on the same architecture which would save the architect some effort architecting the Swing-based client.

[vu lee]

Plus travel agents access the TransMaster's interface on a LAN and if we use Swing client, then as part of security, these clients will not be accessible outside the company's LAN whereas the browser client would be accessible anywhere on the internet.

Both web client's request and swing client's request will eventually process by the app server where secure socket is established with the transmaster.

[kaiser eblovich]

They say agent's clients (GUI apps) are running on internal network (look into assignment for exact phrasing) so I'd say there's no need for secure sockets there.

[Mahesh Kumaraguru]

Question : Is there any restriction in the Assignment submission that the design must contain zero extra features ?

Originally posted by Hitry Mitry
With all respect, this point has nothing to do with the FBN requirements and is purely speculative.

This "point" is thick-vs-thin clients.

Originally posted by vu lee
The instruction requires that a travel agent must have the fastest system to meet the customer expectation.

This is just one advantage I get by using a thick client.

Originally posted by kaiser eblovich
They say agent's clients (GUI apps) are running on internal network (look into assignment for exact phrasing) so I'd say there's no need for secure sockets there.

So my statement - Plus travel agents access the TransMaster's interface on a LAN and if we use Swing client, then as part of security, these clients will not be accessible outside the company's LAN whereas the browser client would be accessible anywhere on the internet, rather browser interface is available only thru servlet. There is no Swing class which calls any servlet in my design. Rather FBN website is html with links to other JSP(s) / Servlet(s). Swing app cannot be reached thru any link on a html/jsp/servlet, they cannot be reached by typing an url address in a browser. The Swing application needs to be physically installed and configured on the client machine.

Originally posted by Mahesh Kumaraguru
An architect should be able to use thick client where appropriate.

To get the fastest response, Swing application is best.Refer above.

Also making it Swing app may give other features which would prove invaluble like :- When the Swing trader logs into his application, the server downloads some data files as mini-local db into client local temp folder and this local database used for first level of search etc. The Server keeps publishing incremental database changes. If network connection is lost, some part of functionality will work using this local db. This may not be a requirement, but having this may give me some increase in performance.

Originally posted by Mahesh Kumaraguru
If the travel agents are also made to use a web browser ( thin client ), then what would be the use of travel agents getting new graphics terminals ?

Originally posted by Hitry Mitry
Coz you can't run a web browser on a text-mode based terminal, obviously!!

OK. point taken.

A web browser does not need much client computing power and the response time of thin client is accepted. Now to increase speed if hardware capacity is increased, there would not be much gain in performance. So the only practical way to get speed is by developing swing application.

If x dollars is project cost of thin client architecture application which gives some performance y, then by spending 2x dollars ( buying more capacity client machine + more network transfer speed ) cannot get me 2y performance, somewhere around 1.5x cost, you need to switch to thick client architecture to get increase in performance ( somewhere on the net I remember seeing a graph showing comparision of the cost ( hardware/infrastructure cost + project development cost ) versus performance for a sample application using thick and thin clients, if I come accross it again, I shall post it ).
When new graphics terminals are bought, for the same final cost of project, if a swing application is developed for the booking Agent, the responsiveness of Swing application will be much higher than browser based thin clients which use servlet / JSP technology.

Lets for a minute try to look at the users.

The web client ( WC ) is a person looking for the travel information thru the internet and booking one or two trips.

The booking agent ( BA ) is mostly a full time employee of a travel services / tour company and for him/her booking response speed / search speed are the criteria, time is money for BA. BA has to try more complex queries to make business - the BA may be answering phone customer and BA cannot pause between receiving customer query and answering. These can be achived only using thick client. So in a realtime project, a Swing rich client would be prefered and it would have advantages like even if it looses network connectivity with the server, some local functionality is available. Obviously there is a development cost of the swing client, but it pays off in terms of increased speed / availability of the application and hence more productivity of the booking agent.

Parts of Workflows may be different between web client and booking agent. To take an example - web client would be required to enter a credit card / online account number, whereas booking agent would be entering a client identification number, in the event a new client calls in who does not have client identification number, redirect call to new clients service representative who creates a client id ( this is out of scope for this project, so just metion in the assignment submission ), after which the flow continues with BA using the newly created client id.

Also number of booking agents is more or less fixed, so there isnt any major changes in load expected, plus these will not be affected by changes to web user loads. Lets look at a scenario - some booking agents presently use a character based legacy interface ( dumb terminal ) to perform their activities, I go as architect and try to sell my design, if my "new booking system ( NBS )" is not as fast as their present text only legacy booking interface ( LBI ) BAs will not migrate to my new booking system.

The legacy text only interface is a thin client, browser is also a thin client. So the only way to make a value addition to the BAs is by providing a thick client.

Originally posted by Hitry Mitry
If both the the travel agents and customers over the Internet get a web interface, this does not mean that it must be THE SAME web interface! These can be two DIFFERENT web applications, each talking to it's own set of EJBs etc. But both applications can be based on the same architecture which would save the architect some effort architecting the Swing-based
client.

Should the architect be trying to save some architecting effort or trying to provide the best to the user(s) ( if these both cannot be achived together ) ? This is a "conflict of interest" question. This also brings back my question ( see above ) zero extra features - I should design an application which represents "real world" solutions. I should be able to go back to the booking agents some time after giving them the "new booking system" and hear "hey architect, the system you put in is great, we are able to do more now than what we were doing before - thanks " instead of "hey arhcitect, your system is not fast enough, so we went back to old text based interface".


[ July 21, 2005: Message edited by: Mahesh Kumaraguru ]

[victor porcar]

Let�s imagine the following scenario:

the performance of a system with thick client for travel agent is equal to the performance of a system with a thin client, then, from the architectural point of view?, what architecture is better?

I think the second one for many reasons: maintainability, extensibility, etc..

but we all know that this scenarario does not happen in the reality, but..., how far is this scenario from the reality ? i think not much, in fact, that "distance" does not justify having the worst architecture. ok, ok, you may not agree with this, but then, why not the thick client talks directly with the database??? Because we are willing to pay a price in the performance in return of a maintainable, extensible, ... , architecture, just the reasons to choose a thin client.

[victor porcar]

Let�s imagine the following scenario:

the performance of a system with thick client for travel agent is equal to the performance of a system with a thin client, then, from the architectural point of view?, what architecture is better?

I think the second one for many reasons: maintainability, extensibility, etc..

but we all know that this scenarario does not happen in the reality, but..., how far is this scenario from the reality ? i think not much, in fact, that "distance" does not justify having the worst architecture. ok, ok, you may not agree with this, but then, why not the thick client talks directly with the database??? Because we are willing to pay a price in the performance in return of a maintainable, extensible, ... , architecture, just the reasons to choose a thin client.

[Mahesh Kumaraguru]

Originally posted by victor porcar:
...why not the thick client talks directly with the database??? Because we are willing to pay a price in the performance in return of a maintainable, extensible, ... , architecture, just the reasons to choose a thin client.

In Topic : "Fast lane reader" on the Swing client thread, I understand that Swing client bypasses Entity beans and talks directly with a DAO for read only data from the database. This is part of the thin client ( with maintainability & extensibility & architectural simplicity ) versus thick client ( with much better performance ) architectural choice.