IDC资讯中心
alternative approaches
so, if you are really uneasy about going down the ejb route, what alternatives exist? well, assuming you want to stay with java or employ another mainstream technology, then the answer is — not many. ive listed below the main alternatives.
avoid ejb completely, yet still employ a java solution
dont use ejb; simply write straight java classes. this solution means you must explicitly handle (or ignore) issues such as multithreading, scalability, and transaction management yourself. now if these issues dont affect your scenario, then there is no value in using ejb (or any comparable technology), so writing straight java makes sense.
if, however, you must address those issues, and you still decide to forgo ejb, then you must write systems-level code as solutions. such systems code usually starts out as a couple of base classes with utility methods like getconnection() and closeconnection(), plus a couple of xxxmanagers, then quickly mushrooms into your own custom version of a stripped-down container that must be maintained in-house — not a good solution.
adopt an ejb-friendly design
as another alternative, you can plump for a solution that makes it easy to adopt ejb at a later stage. a number of widely available design patterns make this choice feasible; in fact "designing enterprise applications with the j2ee platform" uses many such patterns. more often than not, the adopted solution is usually a model 2 architecture, with good separation between presentation (jsps) and business logic (servlets), in preparation for a more robust and scalable middle tier in the future.
move to a completely different technology
if you wonder whether java technology is right for you, then take a look at corba or .net. other options exist, but these two represent by far the main competitors to ejb/j2ee.
dont think about going to corba if you think ejb/j2ee is overkill for your needs, as corba is at least as comprehensive. in any event, the j2ee platform has supplanted corba as the premier open standards-based, cross-platform enterprise computing solution. all vendors who previously sold corba implementations now offer j2ee implementations.
meanwhile, microsoft has been pushing .net heavily. .net is language independent and platform dependent (ejb is language dependent and platform independent). by and large, the design and feature-sets of .net and j2ee map very closely. at present, in my opinion .net provides no competition to j2ee. it simply hasnt been around long enough, and the architectures key features — particularly the common language runtime (clr) and c# — are new and untested in production-class systems. however, make no mistake, .net will be a strong competitor; microsoft led the way with dcom (distributed component object model) and asp (active server page) and will continue to add good ideas and technology to the enterprise computing space.
think out of the box!
if none of the preceding options float your boat, then you may consider other candidate technologies such as jini/javaspaces or sandstorm, which are not widely used:
- the jini/javaspaces pairing has failed to attract any significant market share since its release, and is often found in an academic setting rather than in a commercial deployment. however, its simple model is easy to grasp, and it possesses the basic constructs required to build complex enterprise applications. i added jini/javaspaces to this list because i am currently using it in an academic setting myself and appreciate its elegance. but i wouldnt use it in a commercial deployment as the backbone of my system just yet; i dont feel it has enough industry momentum or support. your mileage may vary.
- the exciting sandstorm technology addresses the issue of scalability exclusively, but does not handle security or transaction management. however, it might fit some business scenarios. i would love to see an application server use sandstorm under the hood!
the rule book
at this stage, i list a set of rules to guide you in deciding whether or not to use ejb. thats basically what the ejb/no ejb decision boils down to: looking at your own unique project and applying these rules.
rules for choosing ejb
- choose ejb when you know your application will need to scale beyond initial low usage levels and support multiple, concurrent users.
- choose ejb if you need transaction management. for online catalogues or read-only systems with low user numbers, you probably dont need ejb. for financial systems or any system where you must preserve the acid (atomicity, consistency, isolation, and durability) properties, ejbs are a must.
- choose ejb if you need a comprehensive security model.
rules for not choosing ejb
- do not use ejb when you find no need for scalability, transaction management, or security and anticipate low numbers of read-only users.
- dont choose ejb if you dont need platform independence and dont mind being locked into one particular vendor. this rule isnt designed to be sarcastic; intranet applications serve as a good example where i would like to see as little complication as possible. indeed, a solution like .net could prove highly successful in such situations, even in a beta release.
- do not choose ejb if your team possesses no ejb experience (and you dont plan on ramping up or importing such experience).
- do not use ejb just because your company got a free set of licenses from vendor x.
|
|
