These are big generalities, so it's hard to call them true or false in an absolute sense. a) This isn't necessarily true. If most client requests require processing on both back tiers, it doesn't scale any better. Typical going from 2->3 tiers just lets you seprate the data storage from the business logic. It only scales better if one of those two processes has different usage patterns (frequency of requests and service time per request) than the other, and you can use those differences to scale better. b) Certainly code reuse comes from good design. Code either can or can't be used based on how flexible it is, not where it is. Maybe there's some idea of tier reuse, but I don't know of any. c) How thin is thin? Clients range from web pages to applets, to GUI renders to full blown applications. The terms thin client and ultra-thin client can be pretty relative. d) CORBA, RMI, DCOM facilite making the service distributed across a network. Multiple clients don't require this, although in some cases it makes it easier. CORBA is generally only used on the back end, and not for client (as in user client) connectivity to the server. Servlets are more of a turnkey build a server solution, and is used often for http-based connections. I wouldn't really lump them in with the other technologies.
a) two tire architecture do not scale as well as tree and more tier arch. (connection pooling, load balancing). IMHO true. b) you can reuse your code easier while using n-tier arch. separation of processing space for particular layers leads to lower coupling. that's why this one is false. c)could go either way on this one, (see Mark) d) that is a true statement, this technologies do allow multiple clients to work with the same server based business objects, although Servlets do not really fit in here. CORBA, RMI, DCOM in general allow cross process calls (CORBA is really powerfull tool while RMI is just a toy, DCOM i've never used ), while servlets are rather tide to the specific kind of client.
This is a single select question. My opinion is that it's either c or d. "a" doesn't seem right to me because it says two tier software architectures do not scale to as many clients as three+ tier architectures. Well, two-tier application doesn't scale as well as three tier because it's inability to separate business logic from the view, that doesn't necessary mean it can't have as many users as three-tier applications.
Hi, I would lean towards A. A is correct. Scalability means application can deal with more and more users by changing the hardware configuration rather than the application itself.Typically, this means that it's partitioned into pieces that can run on seperate servers.Most 2-tier applications have database and business logic coupled in one tier.Since they are based on different usage patterns (and require different server requirements), they can be treated as independent pieces, only by going from 2-tier to 3-tier.This ensures better scalability.Similarly, you can identify more such pieces which can run seperately; this leads to 3-tier+ architecture. Hence, Two tier software architectures do not scale to as many clients as three+ tier architectures. B is incorrect. Two-tier architecture would mean higher coupling between 2 diferent processes - say Business logic and the data in the DB itself.Three-tier+ architecture is based on low coupling.You reduce the interaction between different software layers of your framework.This ensures more lower coupling and more reuse. Hence Three+ tier architectures lead to more reuse than two tier architectures. C is incorrect. The Enterprise Java Technologies (EJB's) is aimed to take the bulk of processing on itself.This means EJB are coarse-grained or thick server-side components.This also ensures fine-grained or thin clients.The thin clients could be a GUI application like a Swing Applet or Application.It may also be a Servlet or a JSP, which renders HTML back to the client.JSP/Servlets are "server-side" thin clients to "coarse-grained" EJB's. Hence Thin clients are not restricted to GUI parts D is incorrect. If you consider any of the technologies mentioned, the Container is responsible for handling the access to the business object to the client. In the case of EJB, the client may do a lookup on the HomeObject in this manner:
A lookup done many number of times gives the same HomeObject reference(Probably because it is based on Singleton Pattern).But this is not a business object.The Business Object in EJB is EJBObject, which may not be same, if the create() method on the HomeObject is invoked many number of times.
Hence Technologies such as CORBA, RMI, DCOM, and Servlets may not allow multiple clients to work with the same server-based business objects. Hope this helps, -- Sandeep [This message has been edited by Desai Sandeep (edited May 16, 2001).]
Originally posted by Desai Sandeep: D is incorrect. If you consider any of the technologies mentioned, the Container is responsible for handling the access to the business object to the client.
Thank you very much for your explanation! I can see now C is incorrect. As to D, it's really vague what the question means by "the same server-based object". I definitly see your point of multiple instances of the acturl EJBObject being created. If that's what the question means, then D is incorrect either.