wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: Exposing different interface to client (than the one provided) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: Exposing different interface to client (than the one provided)" Watch "NX: Exposing different interface to client (than the one provided)" New topic
Author

NX: Exposing different interface to client (than the one provided)

Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
Dear Developers,
I am wondering if it is acceptable to have client maintains a reference to some other interface or class than "DBAccess" and "Data". For example in the case of Network Client (i.e. Networked Mode), can I have client call methods: "find(criteria)" and "book(record)" of, say, "Booking" interface which delegates calls to "Data" class which is only on the server?
(Of course in Standalone Mode, DBAccess and Data will also be present on client but they will never be referenced directly by client. If, for example, there was only Networked Mode then client would never know about "DBAccess" and "Data" as they would only reside on server and be callable by a custom client class.)
Please share your ideas! Thank you very much!
+Seid
[ December 06, 2003: Message edited by: Seid Myadiyev ]

Seid Myadiyev<br />SCJP, SCWCD, SCBCD, SCEA-Part 1
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
Seid,
Not only is it acceptable, I believe it is a much better solution than any 2-tier approach that potentially allows bad client code to cause problems. When creating a real world server, it's best to decouple any client code and NEVER EVER allow the server to become dependent on it. Somebody may come along later and write incorrect client code. Clients should know what a server can do via its interface and as little as possible about how it does it (implementation). This is fundamental to good O-O design.
Those who say that a strict interpretation of the specification says that you must allow the client to call your DB interface and cannot use an adaptor are just plain wrong.
When you say that in standalone mode, the DB access classes and methods are in the client, ti just means that the classes have been loaded in the same JVM. In the real world, you might put the client code in its own separate jar, unlike what's called for in the assignment. In that case, you would not need to include the server's DB classes at all if you design it correctly. It then just becomes a packaging issue.


kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
Hello Ken,
I am very grateful to you for your clarification!
Now I am clrear of these doubts. Thank you very much again!
+Seid
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11405
    
  81

Hi Ken,
Those who say that a strict interpretation of the specification says that you must allow the client to call your DB interface and cannot use an adaptor are just plain wrong.

Oooh - them's fightin words!
In a normal project we would (hopefully) have the oportunity to talk to the project manager and/or the client and explain why we believe that an alternate way of handling things is better. But even then the project manager or the client may simply tell us that we cannot do it our way: we must do it their way. (yes, this unforunately happens in real life).
In the case of the SCJD assignment, we cannot make suggestions to the client and get their approval. So what you are suggesting is that you deviate from the requirements, and hope that the client accepts your explanation in the design decisions document.
Some people may choose not to gamble like that - their playing it safe does not make them "just plain wrong".
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11405
    
  81

Hi Seid,
You may want to look at "Should lock methods be callable by the client". In that topic there's a lot of discussion as to how the instructions can be interpreted and what interfaces we should present to the client application.
Regards, Andrew
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
Hi Andrew,
I was in a feisty mood when I posted having just watched my good and noble Green Bay Packers defeat the evil Chicago Bears .
IMO, it is not a gamble at all to go 3 tiers as the specification does not say that the client must specifically call the methods in the DB interface. I actually think that 2 tiers is more of a gamble as it can easily be less clear and more difficult to score. BTW, I got my results back in less than 2 days after taking the essay exam. I think that some of this has to be because of the lucidity and testability of the design which is in part due to the 3-tier aspect.
I must also once again point out the international character of the exam and Sun's obvious awareness of the fact that it would be pointless and even detrimental to their interests to hold people accountable for subtle nuances (real or imagined) of the English language. The nature of those interpretations can still be somewhat subjective. The instructions are very clear about the use of the word "must" in the assignment.
I think that the people who have built this exam have done a superb job of writing the instructions in such a way as to give people enough wiggle room to use different approachs to get the job done.
My point about "just plain wrong" goes only to those who have said that the client MUST call the DB interface directly.
Cheers
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
Hello Andrew and Ken,
My "instructions.html" states the following:
" -- 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. "
Does it mean that I cannot architect my application the 3-tier way?
Could you please clarify this requirement again!?
Thank you!
Seid
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Seid,

Does it mean that I cannot architect my application the 3-tier way?
Could you please clarify this requirement again!?

Like Andrew suggested, have a look at the thread he has pointed, there are a lot of pros and cons concerning both the 2-tier and 3-tier-solutions.
I have to admit that Andrew's arguments conviced me there and by my first reading of the instructions I had also the feeling that DBAccess is the interface which should be exposed to the client. So I decided to implement a 2-tier. But generally I think it's up to you to take your choice, but document it.
Greetings
Ulrich
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
Hello Ulrich,
Thanks for replying. I did read important posts on Andrew's thread and arrived at a conclusion that I want to architect my application the 3-tier way.
My only concern is the word "must" in this line in my instructions document:
"...must be a traditional client-server system..."
I hope that it does NOT mean that I definitely must design my application the 2-tier way where client uses DB interface. And so I want to confirm that with the given requirement (below) I still can have a 3-tier architecture. Of course, I hope to successfully justify my choice; I just need to know that I am NOT violating the given requirement in first place.
Please advise! Thank you!
Here is the instruction again:
" -- 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. "
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Seid,
I don't think that your approach violates the requirements.
If you implement the business logic at the server-side or the client-side you're not violating the client-server architecture. I would even say that to implement the business logic at the server side refers more to the traditional client-server system.
And you're not the only one to choose the 3-tier approach, I think Ken has acquired a great result with it.
Greetings
Urlcih
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
Ulrich, thank you. In this case my application will be designed as a 3-tier architecture (as much as possible)!
Ken, Andrew, what do you think?
Thank you all!
Seid
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi everybody,
I am a bit surprised that this question (2-tiers/3-tiers) is still debated the way it is, given the huge thread mentioned above.
The initial question was "Should lock methods be callable by the client ?", but everybody agreed (including Andrew) that it'd better rephrased as "Should the Data interface exposed to clients ?".
And this was finally - and practically - translated in the "2-tiers vs 3-tiers" question.
In that thread, we quickly saw two camps : the 2-tierers (Andrew, Jim and a few others) and the 3-tierers (myself, Ken, Michael and a few more others ).
At the start of the discussion, 2-tierers main arguments turned around the "no-allowability" of the 3-tiers design, while 3-tierers mainly defend their position with "quality" arguments, like "more efficient", "easier to maintain", "reuse of the business logic" (important as they intend to move to the web), etc.
For any reader of that huge post, it's clear that 3-tierers won the discussion around the middle of it (as Andrew recognized himself in the middle of the thread BTW ).
Now why did the 2-tierers finally give in ?
Because it was obvious finally that while a 2-tiers design was *mandatory* with the *old* FBN assignment (Andrew could repost here the exact words), for *new* assignments the candidate *may choose*, the candidate has a (main) design choice to be made.
I don't think that any poster in that huge discussion doesn't agree with that middle conclusion.
Given that, the opposite question ("Why did the 3-tierers finally win the discussion ?" (as far as a dicsussion can be "won" ?!)) becomes obvious too :
If you have the choice (and we have it in the new assignments), it's obvious to choose the better one, right ?, and the 3-tierers arguments (accepted by the 2-tierers BTW) fully demonstrate IMO that the 3-tiers design brings much more pros than cons in comparison with the 2-tiers one. As a recall, here are the main two pros :
*performance* : have a look at your read() and find() method signatures. find() returns recNos (instead of records), meaning that if your design is 2-tiers, you have to make as many remote requests on read() as you get recNos from find().
*business logic code reuse* : our customer intends to move to the web. With a "business-oriented" server, a future client servlet will be able to reuse the business logic (book, search), instead of having to reimplement it.
In that thread, 3-tierers were only waiting for the first one of them who would pass with his 3-tiers design. We badly named them "guinea pigs" . Well, in the meantime, the first 3-tiers-guinea-pigs passed, and passed with a high score (look here).
Just a few more words about the terminology used (2-tiers vs 3-tiers). It's a bit misleading, because *4* tiers exist in both designs, the only difference being *where* (in which JVM) the business tier fits in :
2-tiers :
*******


3-tiers :
*******

3-tiers "extended" :
******************

My conclusion is that with the new assignments, you may do whatever you want, as far as you justify it. And that's far much easier to justify a 3-tiers design.
Best,
Phil.
[ December 08, 2003: Message edited by: Philippe Maquet ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Now why did the 2-tierers finally give in ?
Please don't misrepresent the discussion Phil. Some of us just got tired of repeating the same arguments for every new person who came along - it's all been said. Many times.


"I'm not back." - Bill Harding, Twister
Philippe Maquet
Bartender

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

Phil:
Now why did the 2-tierers finally give in ?
Jim:
Please don't misrepresent the discussion Phil. Some of us just got tired of repeating the same arguments for every new person who came along - it's all been said. Many times.

Sorry Jim, but what I just tried above was to *summarize* that huge thread. I made my best to keep objective while doing (OK it's hard ! ), giving both camps's most arguments.
There were two main camps in that discussion, and it's clear that Andrew gived up on October 14, 2003 02:55 AM (on page 3 of the thread), anyway that's how I understood his post.
But I didn't know that the 2-tiers camp still had a few guerilleros who never surrendered ...
All best,
Phil.
[ December 08, 2003: Message edited by: Philippe Maquet ]
Matt R. Hansen
Ranch Hand

Joined: Sep 05, 2001
Posts: 71
If we are doing statistics again( ), count Me for the 3-Tier solution. I am submitting in less than 2 weeks and I am gambling with the 3-Tier route.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Thanks Matt, but for making updated statistics I surrender !
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
I would like to apologize for asking questions on topics which have been already discussed in previous threads at length (possibly even many times). I always make an effort to read other posts first before asking a question and starting a new thread. However, I still feel more comfortable sometimes asking a question again rather than remaining doubtful regarding certain issues. There was a time, for example, when I had misunderstood a certain requirement and participated in one of the current threads. But not until I started a new thread and restated my question was I able to find satisfying answer. At the same time, I understand forum moderators who are tired of answering the same type of questions as new developers join the discussion!
So please accept my apology for the inconvenience I may have caused.
Thank you very much for this great forum!
Seid
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Phil]: and it's clear that Andrew gived up on October 14, 2003 02:55 AM (on page 3 of the thread), anyway that's how I understood his post.
That's a fairly creative interpretation of the post I think. The first part of Andrew's post seems to acknowledge that there now seem to be more 3-tier than 2-tier supporters. Big deal; statistics on this subject are irrelevant and tiresome. The second part acknowledges that there's at least one specific case where a 3-tier solution did not lose any points for being 3-tier. Which is good, but if you were paying attention Andrew and I acknowledged long ago and many times that in terms of grading, either 2 or 3 tiers was probably fine, as long as it works correctly. To have this point eventually confimed is hardly cause for "surrender". But apparently the 3-tier camp is experienced in reading things to say what they [iwant[/i] them to say, instead of what they actually do say.
My conclusion is that with the new assignments, you may do whatever you want, as far as you justify it.
Agreed long ago.
And that's far much easier to justify a 3-tiers design.
It's remarkably easy to justify 2-tiers based on the fact it's what the client asked for. Yeah, it's not a completely clear and absolute requirement, and especially with all the English-as-second-language folk here it would be unfair of Sun to enforce this requirement strictly, so I'm glad that evidently, they don't. (As far as we can tell.) But it remains pretty clear to me what they asked for, even if in the real world I'd prefer to replace it with a better design. I think that the whole idea of requiring cookies for locking is a bad idea really; I don't see any benefit. But it's what the client wants, and it's possible to deliver this, and it's not difficult, so why not do it? The various arguments about why 3-tier is better really don't matter to me - I agreed with most of them long ago. The fact that Sun evidently allows 3-tier is nice, but I still advocate doing what they asked for, not what they allow. If you genuinely interpret the instuctions differently, that's fine, we can agree to disagree. But given the way I read the instructions, I see no need to go against their apparent intent. 2-tiers may not be the best possible design, but it's simple and it works.
[Seid]: I would like to apologize for asking questions on topics which have been already discussed in previous threads at length
No problem, Seid; there will always be new people coming in, and it's hard to wade through all the existing discussions. I'm just arguing with Phil's erroneous summary.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11405
    
  81

Hi Seid,
My "instructions.html" states the following:
" -- 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. "
Does it mean that I cannot architect my application the 3-tier way?
Could you please clarify this requirement again!?

I think that you have been answered already, but just to clarify...
One of the big problems with that big thread was the discussion of "two tier" vs "three tier". In reality both solutions have only two components, and that is why some of us prefer calling it a "fat client" vs a "thin client" solution.
If you think of it in terms of "fat client" vs "thin client" you will hopefully see that both solutions fit the "client - server" requirement. Whether both meet your other requirements is something you have to decide .
And please don't think that I agree with the thin client solution - as Jim says, I just gave up rehashing my arguments. I still believe the fat client is the best fit for the requirements, but I accept that others may interpret the instructions differently.
Regards, Andrew
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
Jim,
but I still advocate doing what they asked for, not what they allow

I guess we're going to have to agree to disagree about what it is that they asked for in the newer versions of the assignment. I've never seen the older one so i can't comment on that.
I STRONGLY disagree with the point of view that 3-tier implementors are somehow getting away with something that is incorrect at least in my assignment.
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
Jim, Andrew, Ken - thank you very much for your input.
I sincerely appreciate everybody's assistance!
Thank you all again!
Seid
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Jim,
That's a fairly creative interpretation of the post I think (...)
Which is good, but if you were paying attention Andrew and I acknowledged long ago and many times that in terms of grading, either 2 or 3 tiers was probably fine, as long as it works correctly.

In my mind, and from memory, it was the main question. It's now clear (from recent results) that people pass equally well with both designs, and that's the most important point IMO. If I had known that then, I'd even not have argued at all in that thread. "October 14" was just a date I knew from memory, because that thread is too long and boring to be read again ! I actually ignored that you have still a different opinion. Same for Andrew, and it surprises me a bit more. But I have no issue with that. I just regret that most people who read that thread are more confused than helped with it. "Tiers" : looks like a word I could get allergic to !
Best,
Phil.
 
wood burning stoves
 
subject: NX: Exposing different interface to client (than the one provided)
 
Similar Threads
URLyBird 1.2.1 - MUST not use the network server code
Network Server Code...please clarify
Locking in local mode - URLyBird 1.1.2
Could somebody suggest me about locking in standalone mode,please?
LocalAdapter and Remote Adapter