I have passed the first step of SCEA and I have received my assignment for the second step. The assignment is to prepare a new system for FlyByNight Inc - you probably know this assignment very well (I think so because there are many threads about this assignment in the forum).
After reading the requirements, use-cases and domain model I noticed that Customers and Travel Agents can use exactly the same set of functionalities of the new system - there is no special functionality that is used only by Customers, and there is no special functionality that is used only by Travel Agents. On UC diagaram actors Customer and Travel Agent are connected to the same use-cases, and in the use-case descriptions it very often happens that only "Customer" actor is mentioned. From all this observations I deduct that form the functional requirements point of view actor Customer is equal to actor Travel Agent.
In many threads in this forum the following opinion occurs: there should be web-browser/servlet&JSP based client/presentation layer for the Customers and Swing based client/presentation layer for the Travel Agents. Both layers should access common EJB based service layer. But I believe that there should be only one web-browser/servlet&jsp based client/presentation layer used by both Customers and Travel Agents. In my opinion this design choice is justified by two facts: 1. Customers can do the same things as Travel Agents (as I described above), so there is no point in creating two distinct client/presentation layer implementations. 2. The Customers have to access the application by web-browsers, and Travel Agents do not care about the way of access. That is why the web-browser/servlet&jsp client/presentation layer should be choosen and implemented.
What do you think about that? Do you agree with my observation about the functional requirements similarity of Customers and Travel Agents? Do you think that the solution with single web based client/presentation layer would be accepted by people that would check my assignment?
I am aware that my English is not perfect, so do not hesitate if you need more clarification/explanation. I would very appreciate your comments.
I do agree with you that from a usage perspective it makes sense to provide a common interface (Web UI) for both customers and the travel agents. However, IMO, what the SCEA requirement/design is looking for is support for multiple clients (both Web and stand alone). Any comments from the already "SCEAs" ?
Originally posted by Jibu Thomas: SCEA looks for a design that supports both web and application clients. BTB, AA, Please give your name Jibu SCEA
And in the real world, i do expect thick client to act faster than the web client and travel agents do need that speed differences. In addition, thick client allows local system/hardware pheripirals integration.
Implementing the user interface for a Java client usually requires more effort to implement than a browser interface, but the benefits are substantial. First, Java client interfaces offer a richer user experience; with programmable GUI components, you can create more natural interfaces for the task at hand. Second, and perhaps more importantly, full programmability makes Java clients much more responsive than browser interfaces.
When a Java client and a browser client request the same data, the Java client consumes less bandwidth. For example, when a browser requests a list of orders and a Java client requests the same list, the response is larger for the browser because it includes presentation logic. The Java client, on the other hand, gets the data and nothing more.
Furthermore, Java clients can be programmed to make fewer connections than a browser to a server. For example, in the Java Pet Store sample application, an administrator may view orders in a table and sort them by date, order identifier, and so on. He or she may also see order data presented in a pie chart or a bar chart,
Because the administrator client uses the JFC/Swing API, it can provide all of these views from the same data set; once it retrieves the data, it does not have to reconnect to the server (unless it wants to refresh its data). In contrast, an administrator client implemented using a browser must connect to the server each time the view changes. Even though the data does not change, the browser has to download a new view because the data and the view are intertwined.