Hi guys! Doing J2EE for years I'm a potential 3-tier man For me that means having remote and local access to a database service and a business service. To hide the RemoteExceptions in local mode, I'm planning to use business delegate layers between database and business service and business service and (thin) client. I consider this as the cleanest design. Locking would be done solely in the database service. What worries me is that this approach might not be readily understood by a junior programmer at the first and maybe at the second look. I think it'll be too much interfaces and factories/service locators for this "simple" assignment, which is meant as a kind of proof-of-concept anyway (-- The IT director does not anticipate much reuse of the first Java technology system...) So what you 2-tier/3-tier guys think? PS: The business service would be really thin and maybe not worth the trouble
Joined: Jun 02, 2003
Hi Horst, As you can read in this thread, the 2-tiers camp just convinced me. But if I stop kidding (it's very tough BTW) to reply to your own post, I would say the the 3-tiers design is easier to be understood by a junior programmer : Or that guy needs to dig in your client code, and (except the pure swing part) he will find two main methods (book() and search()), methods which make perfect sense in the CSRs job context. He will find it very clean and easy to understand, anyway much easier to understand than the mess brought by the low-level db access he would have to deal with in a fat client. Or that guy needs to dig in your server business code. As you noticed yourself, the business service will be really thin, "thin" being a quality in that context. Or he will need to dig in your db code. It will be as it is, but with the big advantage for the junior programmer to be in only one place. Your first sentence was "Doing J2EE for years I'm a potential 3-tier man". If it happens that your junior programmer is doing J2EE for months, he should be 3-tier minded. Best, Phil. [ October 17, 2003: Message edited by: Philippe Maquet ]
Joined: Oct 08, 2003
Hi Horst, I know what the XP crowd would say. But, if you 1. make sure your database service locator/factory returns to the business delegate layer one of two service providers to access the database itself (1 which uses DMI for local mode and the other which uses RMI/Sockets for networked mode) and 2. your presentation layer communicates with the business service layer only via DMI (no network protocols) then I think you have a great 2-tier design. Now if your GUI also uses RMI/Sockets to communicate to your business service provider instance, you really would have a 3-tier system. I think of each tier as being able to sit on a different machine, or able to communicate to the next tier via a networked protocol. (Protocols - that's all these J2EE guys understand ) By the way, I personally think the database service should expose all the methods in the DB interface, including lock and unlock. Is this what you mean by "in the database service" or do you mean you will hide it from a user of the service? Deep [ October 17, 2003: Message edited by: Amardeep Cheema ]
Joined: Mar 29, 2002
Hi Phil, hi Amardeep! Thanx a lot for your input! First of all I think that a clear design also has to be quite easy to understand (Phils reasoning). Even if there are some more interfaces/classes a rookie would have dismissed. Second: I won't write crappy software on purpose if some IT manager states "Sooner or later we kick it anyway!" So I'd say I'm looking for the hard way Eventually it all comes down when you're justifing your approach (and list the alternatives). What counts: For my first shot I AM a 3-tier supporter: Database service and business service will go to the RMI registry (or local), lock/unlock will be hidden from the business layer (sorry Amardeep). I don't want to run into threading issues. As I understand the specs, RMI does not guarantee handling two or more calls of one client with the same thread. How could that go anyway, if a thread has to wait. I'm going to use a mutex implementation of an abstract semaphore interface. The mutex enforces real strict locking: Only the owner (thread) of a mutex can unlock it. Think cookies won't be really necessary in that case. Maybe I change the locking in favor of cookies. Considering that I even might change to a 2-tier architecture O.k. it time to code If I run into trouble you will know, when everything's going fine, I let you know, too. Thank you very much again for your input. Horst. PS: The mere asking and considering in this forum with all you guys, gets my thoughts sorted out.