• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NX: More 2-tier verse 3-tier

 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
See this thread:
https://coderanch.com/t/201877/Performance/java/memory-less-GC-Soft-ref
though it is not directly related to this posting, it may be relevant.
I am not here to argue either way (though I will post my conclusion at the end).
I am curious about this only because I would be interested in knowing what
Sun really had in mind.
So, let's look at this important, architectural must condition, and this is the only
part of the instructions being considered in this posting:

Major Components
The main architecture of the application must be a traditional client-server system. There are three key parts:� the server-side data management system, the client-side GUI, and the network connection between the two.

The instructions above, a must condition, should, in and of itself, be sufficient to unambiguously
define the major architecture of the system. If it fails to unambiguously define it, then the assignment is ambiguous. --this may not actually be true for your assignment! But, for this
posting, that is how it is structured; for if your assignment says make Data's methods available
to the client, well, that's pretty explicit.
What is a "traditional client-server system"?
Does this definition change from the 1980's, 1990's, 2000's?
Is it hardware?
Is it software?
Is it both?
Does a "traditional client-server" system define what components go where:
1. business methods: book(), goes on client or server?
2. Implementation methods: lock, update, unlock: exposed to client from server?
3. Database: got this part! Goes on server in network mode.
4. Client GUI: easy: client side.
So, there are two basic choices?

and, variants:


I'm not asking these questions to provoke argument unnecessarily. But, just wondering
if Sun's must condition is unambiguous.
Aside: Probably our best proof of what Sun might have really meant is the newest assignments,
which one discussion in this posting board said that the methods of Data must be callable
by the client, or some such wording; but, this would only become apparent if we learned about
this not from one sample new exam, but from many more samples of new exams.
Of note, I did a google search on "traditional client-side"
and while I don't intend to read over every hit for this, here is one link, which seems
to definitely focus on hardware:
http://www.ietf.org/proceedings/98aug/slides/ipfc-fabric-slides-98aug/sld003.htm
That is, every client gets at most one server which is shared, and sitting "behind" the server
is the database;
but, it is unclear that this physical set up dictates what software components go where
with respect to Sun's given must condition given at the top of this post. My personal
conclusion, based upon this one quote only from the instructions, is that whether the
client is thin or fat, is not specified. And, as long as your solution has only one server
coded (and not two or more), you are following the directions.
If you do or don't expose Data's methods to the client-side, the only difference is the
level of abstraction that is exposed to the client-side. Not being an expert, obviously,
I suspect that this level of abstraction exposed to the client is not in and of itself a
definition of a traditional server-client architecture.
[Though, in the real
world, you can't only look at one instruction, which is the focus of this article, you need
to look at the instructions in their entirity; but, this posting focused only on this one
must condition, and the title of this posting actually should be renamed.]

---------------------------------------------------------------

Ammendment:
Here is a later response to another post posted by Andrew Monkhouse:
from
Topic: NX (Contractors v2.1.1) : Database access from GUI
https://coderanch.com/t/185219/java-developer-SCJD/certification/NX-Contractors-Database-access-GUI

...
The exact instructions I had in my assignment were:
"you should create a client program [which] should include a class that
implements the same public methods as the suncertify.db.Data class".
Most of the NX assignments seem to allow a more more flexible interpretation.
Take a look at ... [this] thread:
Topic: Should lock methods be callable by the client:
https://coderanch.com/t/184224/java-developer-SCJD/certification/Should-lock-methods-callable-client
...
The important thing is that you must justify your decision in
your design decisions document.
Regards, Andrew

The above snippets from Andrew's post suggest that Sun quite a while ago had
the capability to unambiguously state whether Data's methods would be exposed
to the client. It doesn't prove what Sun's intentions are at any given time. But,
I think that the conservative ones certainly cannot go wrong exposing Data to the
client, simply because some exams explicitly state this as a requirement, such
as Andrew's version of an assignment, which was before mine, and such as a later
assignment question posted by one individual where similar wording and requirements
were stated.
It's quite possible that if you are not told explicitly whether or not to expose Data
to the client that you have to justify your design decision, and, quite frankly, there
are quite a lot of points to cover.
Here is a later post by me when I finally made my final decision on this issue:
Topic: Data as Context Independent Concept
https://coderanch.com/t/185216/java-developer-SCJD/certification/Data-as-Context-Independent-Concept
---------------------------------------------------------------
Thanks,
Javini Javono
[ February 20, 2004: Message edited by: Javini Javono ]
[ February 29, 2004: Message edited by: Javini Javono ]
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Javini,

My personal conclusion, based upon this one quote only from the instructions, is that whether the
client is thin or fat, is not specified. And, as long as your solution has only one server coded (and not two or more), you are following the directions.


That was the generally accepted conclusion (while we still disagreed on the best choice to me made ) of the huge thread we had in the past on the topic. And later, we could notice that - whatever the personal choice (thin or fat client) - both architectures could lead to perfect scores.
Martin Fowler, in his excellent book Patterns of Enterprise Application Architecture, makes a clear distinction between tiers (often understood as "physical") and layers (logical).
If we accept that "tiers" refer to physical separation, it's clear that we are developing a 2-tiers system which the words "traditional client-server" imply BTW. But we have 3 layers anyway: presentation, domain logic (business) and data.
And you're right that our instructions don't specify where the business layer must go.
Regards,
Phil.
[ February 20, 2004: Message edited by: Philippe Maquet ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic