This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Andrew & others - 2/3 tier issue Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Andrew & others - 2/3 tier issue" Watch "Andrew & others - 2/3 tier issue" New topic
Author

Andrew & others - 2/3 tier issue

mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Having read alot of the archives around Sept '03 I noticed there was a big issue regarding new assignments and how visible (to the client) to make the supplied interface. ie whether to go 2 or 3 tier.

my UyB 1.1.1 has this text:

'Server - The data server and its network connection'
'network server funtionality for the database system'

So what is the considered opinion now after the dust has settled?
Have people passed using both approaches, are there any gotchas that have materialised when taking one particular path?

Also what is the take on the 'minimum disruptiuon to users' in relation to this?

And why is this talk of 2/3 tier surely all these options are still 2 tier?

Personally I think the whole point of the supplied interface is to make our apps plugable into a sun test program.

TIA


SCJP 1.4, SCJD
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Mike,

My real name is "Others", but how did you know that?

Have people passed using both approaches?


Both designs lead to similar results, that's a fact, and for a while now. So just choose the one you prefer, without forgetting to justify your choices. But I think the "big" thread you didn't miss for sure shows enough arguments in favor of both solutions to make such a justification easy to write...

Regards,

Phil.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Mike,

Originally posted by mike acre:
So what is the considered opinion now after the dust has settled?


As Phil said, you may go with whichever option you feel you can justify.

Originally posted by mike acre:
Have people passed using both approaches, are there any gotchas that have materialised when taking one particular path?


Again, as Phil said, scores are very similar using either approach.

Originally posted by mike acre:
Also what is the take on the 'minimum disruptiuon to users' in relation to this?


You can argue that either way. From memory I made the argument that having all the business logic on the server meant that any additional business logic would disrupt all users. The counter argument is that having the business logic on the clients means that every client needs to be updated individually.

Originally posted by mike acre:
And why is this talk of 2/3 tier surely all these options are still 2 tier?


Hopefully you noticed that part way through the discussion we changed to "fat client" / "thin client" instead of 2/3 tier.

Either option will still result in a "2 tier" architecture, however the "thin client" resembles a 3 tier solution in that those advocating it were talking about the server consisting of "the database" and "the business logic handler".

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Thankyou Andrew and Others

Since Thin/Thick client is undoubtably the most major design decision by far - I just want to make sure my design is broadly correct.

It seems to me if you opt for thin client where the supplied interface is not visible to the client. Then you might as well go the whole hog and wrap up each record in a Record object with all the details you could possibly want along with it.

I started out with a lightweight approach of String[] for the record but now I find I need the recNo client side too for booking. It seems a bit daft to have to maintain recNos and records independently in the thin client.

The only real reason I'm unsure of this (well the whole thin client approach) is that Sun have deliberately made life awkward and tried to introduce a real world awkward customer element. And then it seems to me if the thin client approach is valid (as per requirements) that I can neatly side step a whole wodge of this awkwardness. Why does anyone ever opt for a fat client?

Obviously I still have the supplied interface and ALL data does go through it.
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Originally posted by mike acre:
Thankyou Andrew and Others

Since Thin/Thick client is undoubtably the most major design decision by far - I just want to make sure my design is broadly correct.

It seems to me if you opt for thin client where the supplied interface is not visible to the client. Then you might as well go the whole hog and wrap up each record in a Record object with all the details you could possibly want along with it.

I started out with a lightweight approach of String[] for the record but now I find I need the recNo client side too for booking. It seems a bit daft to have to maintain recNos and records independently in the thin client.

The only real reason I'm unsure of this (well the whole thin client approach) is that Sun have deliberately made life awkward and tried to introduce a real world awkward customer element. And then it seems to me if the thin client approach is valid (as per requirements) that I can neatly side step a whole wodge of this awkwardness. Why does anyone ever opt for a fat client?

Obviously I still have the supplied interface and ALL data does go through it.


I have a dilemma. They supplied to me an interface, but I find I have to implement a parallel interface with less methods. I'd much have preferred tp have this second interface be the parent of this first interface. The second interface is the one for DataAdapter class.

I will have to provide it to ClientController class as well, by the way.


Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
So if you have business layer on server, are people having some sort of Record class with a method like isBookable() to implement the 48hr rule?
I figure this makes for neat design and further business logic can be added easily. If this is the way to go I don't think it is necessary to revalidate the rule serverside after booking. My idea is to check if it is bookable at time client requests via find(), flag it as so with isBookable(). Theoretically the client could have waited for days between find() and book() but is it necessary to guard against this?

On the pros/cons of thin v fat client from a disruption to users perspective there is no real difference at the end of the day.

I suppose if it was real trivial business logic then thin client may win.
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
have a dilemma. They supplied to me an interface, but I find I have to implement a parallel interface with less methods. I'd much have preferred tp have this second interface be the parent of this first interface. The second interface is the one for DataAdapter class.


Why?

I assume your adapter defines business functions, this is a separate tier from the data tier that implements the supplied interface. Separate tiers should be completely decoupled therefore different interfaces.


I will have to provide it to ClientController class as well, by the way.


Thin client approach to then yes?
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Andrew & others - 2/3 tier issue
 
Similar Threads
3-tier architecture -- poor Manageability?
Architecture of FBN
[URLyBirdHotel 1.3.3] Can I add more interfaces on Data.java?
URLYBird1.3.3 must use 2 tier ?
B&S: Exception handling in book method in adapter