aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Local Adapter Issue Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Local Adapter Issue" Watch "Local Adapter Issue" New topic
Author

Local Adapter Issue

Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Hi, I had a question about a local adapter issue. I already made a remote adapter for networking, but I am having trouble with my local adapter. Since my local adapter does not use any sort of locking, I can't decide whether I should implement the DB interface or not. I could implement the DB interface and not implement the lock methods or I had another idea. I could use a HAS-A instance and have a Data object that calls all of the methods except the ones that need locking. Then I could just write a new method for update. My problem is, if I took this approach, I need access to things such as the Data class's variables. Is there any way to do this besides make an inner class?
[ December 20, 2004: Message edited by: Daniel Simpson ]

SCJP 1.4<br />SCJD 1.4
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Daniel Simpson:
Hi, I had a question about a local adapter issue. I already made a remote adapter for networking, but I am having trouble with my local adapter. Since my local adapter does not use any sort of locking, I can't decide whether I should implement the DB interface or not. I could implement the DB interface and not implement the lock methods or I had another idea. I could use a HAS-A instance and have a Data object that calls all of the methods except the ones that need locking. Then I could just write a new method for update. My problem is, if I took this approach, I need access to things such as the Data class's variables. Is there any way to do this besides make an inner class?

[ December 20, 2004: Message edited by: Daniel Simpson ]


Why not use the DB interface as is and use a null Lock Manager that simply does nothing but return a cookie for lock, true for checkCookie and nothing at all for unlock.

Or just use the standard locking methods, they will run very quickly if they only have the local client.
Paula Decker
Ranch Hand

Joined: Dec 17, 2004
Posts: 36
I agree with Peter. I thought too about making the local interface contain different methods than the remote (DB interface), but wouldn't the UI then have to change its code when using local vs. remote? Even if the lock/unlock methods do nothing in the local implementation, I think its worth it to expose the same interface locally and remotely.

Am I right in thinking that there is no need to lock the db in local mode? The only case I can think of is if the UI is multithreaded. I'm planning on a single-threaded UI.
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
This is from my doc:
You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

So if I took the advice of using the exact same interface, would I be violating anything above? Although it does not explicitly say must, I wonder if this is some sort of implicit must. I am not using a Lock Manager in my application. But if I were to use the same interface as networking, then I would just pass in null or zero values where needed? Am I on the right track?
Andy Zhu
Ranch Hand

Joined: May 26, 2004
Posts: 145
In my instruction, it says I can assume one and only one program access the physical file. It also REQUIRES the local client will have the same db server codes as networking one. It means except the rmi/socket codes, you don't view your clients differently. Furthermore, the assumption ensures little penalty for using locking in the local mode. We only consider one thread in standalone. In networking, the multithreads are created thru your socket code/RMI server.

So in my DBConnection, I have two static methods: getRemote and getLocal, both return DBClient, an interface of business logic wraps around data access layer. I don't know if this concurs with Max' book. Anyway, I think Max book should have a topic covering it.


--------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
Matt Sheehan.
Ranch Hand

Joined: Oct 08, 2004
Posts: 63
You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

My doc says the same thing, but I did what Andy did and passed without being penalized for it.

Matt
Paula Decker
Ranch Hand

Joined: Dec 17, 2004
Posts: 36

In my instruction, it says I can assume one and only one program access the physical file. It also REQUIRES the local client will have the same db server codes as networking one. It means except the rmi/socket codes, ...


I was headed in the same direction as Andy, but I reread the specifications for B&S:


Non-Networked Mode
...
Architecturally, this mode must use the database and GUI from the networked form, but must not use the network server code at all.


I think I can still use the same interface (so the UI doesn't change from local to remote), but the implementation will be different. I think this satisfies the requirement that the local application
must not use the network server code at all


Does this seem correct?
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
So if I understand you correctly, Andy, I have a DBAdapter which HAS-A Data object. My Data object implements the given DB interface. Am I correct in doing this? Here is my next question, though, my code for the book method roughly looks like this:

My question is, is this correct for networked mode? Shouldn't the server be calling these things and not the client via the book method? It's pretty late so I might not be thinking straight. Thanks for the help!
Andy Zhu
Ranch Hand

Joined: May 26, 2004
Posts: 145
Hey, Mat and Paula: thanks for your encouraging reply. At least I know there are precedences that Sun Ok's the method. I wish I could done with documentation sooner. I am counting on the incoming holidays.

Daniel:
First I don't mix business logic with networking/connection. What I called the adapter is the business logic layer which handles high-level operations on database using the methods in access layer. This layer has nothing to do with any networking/location connection.

In the connection layer which I placed in rmi package, it has an object of DBClient which the adapter mentioned above implements. In this class, it provides two public methods one for networking connection, the other for local mode, both return DBClient interface type. So in the connection layer, I never touch the access layer directly. I think you'd better study Max's book and his sample project. It really helps. I agree someone said it needs updated. But the existing methodologies still apply.
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Daniel Simpson:
So if I understand you correctly, Andy, I have a DBAdapter which HAS-A Data object. My Data object implements the given DB interface. Am I correct in doing this? Here is my next question, though, my code for the book method roughly looks like this:

My question is, is this correct for networked mode? Shouldn't the server be calling these things and not the client via the book method? It's pretty late so I might not be thinking straight. Thanks for the help!


The server could call those things, there has been a lot of discussion of this, do a search for "thin client". Some of us believe that this is a violation of the specification, but people have passed doing it. I use the "rich" or "fat" client model where this occurs on the client and the DBAccess interface is available to the client.

Here's an overview of the classes I use:
Andy Zhu
Ranch Hand

Joined: May 26, 2004
Posts: 145
Hey, Peter: like your post. so you use fat client? I used thin client and didn't notice this is at the edge of infringing instruction. But I think in this project, the thin-client vs thick-client just has several lines difference (I think Anton has mentioned this in one of his posts). However, from the view of the real world project design, what do you think of the strategy? I still lean on thin client.
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Andy Zhu:
Hey, Peter: like your post. so you use fat client? I used thin client and didn't notice this is at the edge of infringing instruction. But I think in this project, the thin-client vs thick-client just has several lines difference (I think Anton has mentioned this in one of his posts). However, from the view of the real world project design, what do you think of the strategy? I still lean on thin client.


I did my first iteration on this project using the thin client. Its a lot simpler than the fat client. Most of the locking issues are far easier to code and you expose far less across the network. In URLyBird, all you need to provide to the network client is book and search commands, and there is no need to adapt the DBAccess interface to allow RemoteException. It could be done with a few lines of code if you already have implemented the fat client, but you end up with a huge pile of redundant code.

Here's the statements in the spec that I (and other, including Andrew, if he hasn't changed his mind on this) use to justify the fat client:

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.


- A traditional client-server is a two tier architecture.
- the server is described as a data management system, not a business tier or an application server.


Server

Required Interface


The provided interface is titled as the server's required interface, I interpret this as meaning that this interface must be provided to the client.


Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.

The thin client does not do this. Any enhancement to the capabilities of the client would require modifications be made to the server and possibly all existing clients. With the fat client approach the server has all the functionality required to provide access to the data and thus an enhanced client can run concurrently with the older version of the client. I actually have several client programs that can access the same server. The maintenance and testing client allows all database actions, inuding locking a records and leaving it locked.

The "thin client" isn't really that thin, its more like less fat. A true thin client would know nothing of the server's business capabilities and would use a protocol such as HTTP to access the server. This is explicitly forbidden.
Nikolay Petrov
Greenhorn

Joined: Jan 07, 2005
Posts: 9

quote:
--------------------------------------------------------------------------------

Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.

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

The thin client does not do this. Any enhancement to the capabilities of the client would require modifications be made to the server and possibly all existing clients.

The requirement does state this but for GUI. As I understand it this part SUN are talking about GUI functional enhancements. The guys from URLyBird will need to hire a programmer in order to do these. So he could also do the modifications in GUI's facade.

With the fat client approach the server has all the functionality required to provide access to the data and thus an enhanced client can run concurrently with the older version of the client. I actually have several client programs that can access the same server. The maintenance and testing client allows all database actions, inuding locking a records and leaving it locked.

With this I'm totally agree on the other hand


SCJP 1.2 Done<br />SCJD 1.4 (URLyBird 1.2.1) (In Progress)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Local Adapter Issue