|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 48
Messages: 48
Messages: 48
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Deciding whether EJB is appropriate
An article by Ed Roman reacting to the recent Gartner Group report that companies overspent $1 billion on EJB last year, when they could have just gotten by with Servlets/JSPs. The article explores "the all-important decision: are you actually going to use EJB on this project? Or is EJB overkill."
Read Article Here
|
|
|
Message #29224
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
> The major J2EE server vendors, such as IBM, BEA, and
> Oracle, do not sell their EJB layer separately from
> their Servlet/JSP layer
I dont know about Oracle and IBM, but I do know that BEA sell weblogic express which is essentially just their servlet engine. I am not completely familiar with the the details but I do know that it is identical in build to the regular Weblogic Server, but with some features disabled by the license.
Weblogic Express
I thought the others did... but I dont know for sure.
|
|
|
Message #29234
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
I though Scalabillity and High-Availability were important issues when considering adoption of EJB components. However, these are not mentionned in the article. Sure, J2EE specifications do not mandate support for features such as clustering technology (providing transparent session fail-over and the likes). But if these features are considered important for a particular e-commerce site, won't it need to be done with EJB containers (and not simply with JSP/Servlet containers) ? I though that only clusters of EJB containers could support those scalability andc high-availability. Am I missing something ? If so, please guide me with more explanation...
Thanks
|
|
|
Message #29239
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
A cluster of Servlet engines using some load balancing scheme is also scalable. If your servlets are all essentially stateless (no data in the session, etc ...) you can use something like Cisco LocalDirector to implement load balancing.
-Dave
|
|
|
Message #29240
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
The statistic Gartner were basing their report on was that 70% of companies will buy a J2EE server, but only 60% of these projects will use EJB (i.e the rest will use the JSP/Servlet talking directly to the database).
I think Gartner have wrongly interpreted this is meaning
you only need EJB 40% of the time. It was clear that
the Gartner report didn't understand much about reuse,
maintainability etc... and all the reasons behind the
EJB design. It seems to me like a simplistic use of a statistic. So why are 60% of projects bypassing EJB? Having watched the world biggest consultancy (no names) implement a JSP to database 'architecture' I can explain how it happens.
(1) Development begins at the same time as architecture. There is therefore no time to develop an EJB layer. They want to get cracking on screens to show the client asap.
(2) EJB is unprooven. Safer to use database caching facilities for performance etc.
(3) Lack of skills. JSP is an easy migration from ASP. EJB requires a thoughtful approach eg minimising remote calls.
(4) Parallel development. Let 5 teams work on their own set of JSP pages and they can all work in parallel. Agreeing on what a shared EJB layer should look like slows everybody down.
(5) Performance testing left to end. The priority is always to show the client the screens at the end of two week cycles. Things like performance don't get thought about until the end. By then it is too late. The project is a failure and J2EE gets blamed.
Shocked? Well this was the worlds biggest consultancy working on a project at one of Europe's biggest investment banks. So the fact 60% of projects aren't bothering with EJB doesn't mean 60% shouldn't be using it. I think it is evidence of hack it out fast for the client culture that EJB is designed to mitigate. I think people will learn slowly, and one day business logic will be placed in an EJB layer and re-used across applications. However a lot of people have got to learn the importance of architectural principles first - and learn to read between the lines with Gartner reports by not awfully technical people...
For prototyping a JSP to database approach has some merits. However if you do this you are better off using PERL or ASP, unless you are seriously intending to migrate the business logic to EJB later on. Otherwise you end up with all the problems EJB is designed to solve - lack of maintainability, reinventing the wheel etc...
I was disappointed that Ed's article appeased Gartner. They
really should have been taken to task over this..
|
|
|
Message #29242
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Sylvain,
You can have clustering,load-balancing, and fail-over with just servlet/JSP (see www.rexip.com for example).
You can store session data in servlet session. The session data are replicated over multiple machine. The mechanism is similar to clustering in EJB, but not exactly the same.
|
|
|
Message #29243
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
The most interesting note i saw was the statement "Use ejb's if you want to reuse components across systems. You can't do that with Java classes because they're not remote objects, and if you wrap it around RMI you have to implement your own instnace pooling etc."
So why not go ahead and make it an EJB from the get-go and "future-proof" your app (buzz word there!) instead of possibly having to rework later, and just use local interfaces until you need the remoteness?
|
|
|
Message #29244
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Nice article by Ed.
But Ed appears to argue that the overwhelming reason for using EJB is because it is the standard for RMI usage. Not because it is a good standard, but rather because everybody is using it, and the bandwagon is behind it, it will be a safe bet for me to use it. If there are difficiencies, hopefully one day it will be fixed.
In that sense, it is not much different from Powerpoint and Words being the de facto standard for document exchange.
If one follows the logic, in the end we should probably all just be customers of GE, IBM, Microsoft, Cisco...
It is fortunate that new innovative companies continue to find their place despite overwhelming hurdles.
Tim,
Yes. Scalability is possible with JSP/servlet only. I recall the documentation of Rexip explains how they implement clustering... with heartbeat and in-memory replication much like that of Weblogic.
|
|
|
Message #29245
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
IBM, like Weblogic, also sells a pure servlet container. Priced very low (probably lower than JRun, but am not sure) but nobody bought it. Very limited features. Very bad reputation around here on its stability.
Most people who buy servlet/JSP containers are customers of JRun, Servletexec, Rexip, and Resin.
When they buy Websphere or Weblogic, they most likely buy the EJB version.
|
|
|
Message #29249
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Many of the reasons in favor of EJB put forth Ed are also reasons to use servlet.
Take hiring, it is in fact much easier to hire programmers proficient in servlet than programmers who know EJB, the barrier entry of which is substantial.
As for load balancing, instance pooling and caching, persistence, transaction handling, they can be taken care of with clustering of servlet session combined with JDO.
JDO overhead is lower than EJB.
|
|
|
Message #29250
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
I thought that stuffing everything in the servlet
session and clustering/load balancing the http session
was horrible for performance (WebLogic 5.1). The
EJB clustering technology was much more efficient and
advanced. The object clustering technology was the only
reason that my attention was attracted to the
possibilities of using an EJB layer. So it's not
as simple as just saying "cluster the http session"
Just my .02
|
|
|
Message #29258
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Big GUI to a database
"If you are just a big GUI to a database--heavy on data logic but no business logic--you could achieve a deployment easily using JSPs with tag libraries connecting to a database via JDBC"
This is the first time I've ever heard/read anyone say this. Every IT application and every website I've worked on was just a "big GUI to a database." We've used an EJB layer primarily to encapsulate the database code and take advantage of the container manager persistence.
|
|
|
Message #29260
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Ed,
We did an interesting test when building our J2EE server at Lutris to determine the absolute 'performance' delta between servlets and EJB.
For the test, we took the canonical Java Pet Store app from the J2EE programming model and ported it to a Servlet model (we maintained the 3 layers of the app - pres, bus, data, so that the app development was clean). Obviously, we lost many benefits that J2EE offers, but what resulted was an application that was 7-14x as faster than its J2EE counterpart. The same performance delta occurred between our clustered servlet runner, Lutris Enhydra 3.5 and WebLogic. We had Intel verify the Enhydra results in their labs in Folsom [see http://www.lutris.com/media/LutrisSG.pdf]. Note, the performance of Lutris Enhydra and the Enhydra.org 3.1 release are identical, so as you say, some good things in life are indeed free.
best regards,
Keith
Lutris
|
|
|
Message #29263
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
I find it hard to believe that you'd see a 7-14x performance increase when not using EJB. If you tune your system properly, EJBs can actually increase performance due to caching. This very web site is built on J2EE and its speed is a testimony to that statement.
I have a bunch of 'tuning performance tips' in a free chapter downloadable from this site called "EJB best practices and performance optimizations".
|
|
|
Message #29265
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
I wonder sometimes if EJBs aren't the most misused portion of the J2EE. As an example - I have seen a number of companies that have modeled their EJBs by looking at their ERDs - and they wonder why their performance is poor. Like any tool, EJBs shouldn't be use willy-nilly but where appropriate and in the way in which they were intended.
|
|
|
Message #29268
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Ed,
I never said that Java Pet Store was architected for optimal performance, but it is Sun's 'blueprint' app, and is held up as an example of how to write J2EE apps...
Fundamentally, regardless of EJB caching, if you're bouncing communication over RMI across multiple containers as you do in a standard J2EE Servlet/EJB architecture, and constantly re-checking if isUserInRole or method permissions for every call from the servlet to the ejb container, you'll experience a performance hit. If you counter that you're going to write to the vendor's proprietary local interfaces to overcome the intra-container RMI performance overhead, as some app servers would advise, you certainly jettison the primary value prop of J2EE, portability.
Performance is hardly the only constraint on an enterprise application, and I hardly wanted to imply that EJB/J2EE is bad. All of the other constraints for an enterprise app are where J2EE shines, including availability, reusability, security, and robustness of transactions.
As for the performance tips, I think you should give them to the Pet Store team! <smile>
keith
|
|
|
Message #29271
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
In response to most companies buy IBM's EJB version of websphere, our company has bought a number of copies of the 'Standard' (non-ejb) version, and are currently running production systems on them.
We are currently looking at jboss in our evaluation of the applicability of ejbs.
|
|
|
Message #29275
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Only one reason of six to use EJB is REAL
Ed,
I like J2EE/EJB architecture but I think only one of your six reasons to use EJB over Java classes is REAL. That is "separation web tier and application server". Others are not real.
1. "built faster and more reliably" - if don't need to desing/coding/testing EJB layer than you will build your system more faster and it will be more reliable due to easier desing, coding and testing "simple" Java classes.
2. "hiring" - it was already mentioned that it will be easier to hire a developer with Servlet/JSP skills.
And even if you shoose EJB you have to develop some kind of "your own custom framework" consisted from patterns (Facade, Delegate, Helper, DAO, etc.).
3. "the best practices" - you DO can use "the best practices" or J2EE/EJB patterns to build "a proprietary Java class framework" :)
4. "different user interfaces" - Servlet/JSP application can be remotely accessible via HTTP (web services)
5. "work with industry-standard tools" - the same tools will "help streamline" your Java classes development process :)
In my opinion "Core J2EE Patterns" better discovers motivation and mechanics when to use EJB on page 117.
|
|
|
Message #29277
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Rich,
What you say may be true when EJB has caching and you do not do caching for your Java classes used for your sessions.
With JDO, my understanding is that caching of instances is done.
|
|
|
Message #29278
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Dan,
You may have already knows this. I am with www.rexip.com
We do offer a JDO implementation on Rexip AppServer called Rexip JDO. It is one of the most complete JDO implementations around. A beta download is available from our site.
We will be posting documentation/tutorials on how to program JDO within the Rexip environment in the near future.
We plan to make Rexip JDO interwork with other major App Servers as well.
Hope this information is useful.
- Niles
www.rexip.com
|
|
|
Message #29287
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
To many people seem to assume that you can not build a fast, reliable and scaleable solution without using EJBs.
Face facts... placing business logic within EJBs is not the only way to enable MVC and gain these abilities.
The key is placing business logic in a place where it can be made visible such as database stored procedures, even CICS Cobol transactions (as we do)...
It is our job as designers and architects to produce a solution that is appropriate to requirements. Start looking at expected usage levels, exisiting skill sets and standards.
Maybe EJBs will be the correct solution to your problem... just do not assume it.
|
|
|
Message #29302
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
>> The key is placing business logic in a place where it
>> can be made visible such as database stored procedures,
>> even CICS Cobol transactions (as we do)...
I am not sure that this is a very portable place to put your business logic...
Would you advocate this on a new greenfield project?
|
|
|
Message #29318
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Funny... CICS is essentially an EJB tier. Has transaction support, scalability and so on. Can be run on Unix boxes (AIX) or the MF hosts and accessed from many different clients.
What goes arouond comes around.
|
|
|
Message #29332
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
I see many articles on e-commerce sites, etc. But what about IntraNet ? It has different aspects from Internet sites. IntraNet information systems usually have 100 ar 1000 times less users, but 10-50 times more complex systems. E.g. Amazon.com is quite simply with few possible actions/screens. However, if you take internal information system, which manages information from various sources, e.g. online and offline orders, information from banks and other institutions, when part of information requires hand-work over it due to its nature, then you have to deal with rather complex system, which could be frquently changed/enhanced. I do not see any articles on EJB suitability for such projects.
|
|
|
Message #29338
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
"Would you advocate this on a new greenfield project?"
You hit the nail on the head there!
This just adds to my argument... you take all the information into account before deciding on an appropriate solution and do not automatically take EJB to be the answer.
How many of us are lucky enough to be able to start any project from scratch, get real...
|
|
|
Message #29339
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
"CICS is essentially an EJB tier"
Funny that, I was under the impression that CICS had been around a lot longer that EJB...
Should you not be saying EJB is essentially a CICS tier?
The point is that we should be aiming to isolate business logic. There are many valid locations to place that logic. Work out what is best in your situation do not just go for the trendy option... or is that to hard a decision for you?
|
|
|
Message #29372
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
I've always used the following litmus test for deciding whether to use EJBs on the projects I've been the lead architect on. This assumes that the essential decision to be made is between a servlets-only approach or an EJB approach.
1. Do you need transactions? Will the things that you talk to--like legacy systems, homegrown systems, databases--be able to "plug in" to the transaction engine in an EJB container?
2. Do you need declarative security? Are the types of security checks you do based on roles or individuals?
3. Can you afford to take up to three network hits for a simple round trip (proxy webserver to main webserver (optional), main webserver to servlet engine, servlet engine to EJB cluster)?
4. Do you have the people on the ground who can work with the complexity of the deployment descriptor, and who are sufficiently versed in your application server's idiosyncracies to really know what they are doing?
Generally, if you answer no to, say, two or three of these questions, a servlets-only approach is often better, I've found. There's still no excuse for not separating presentation- from business-logic, however.
Cheers,
Laird
|
|
|
Message #29404
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Let me challenge your comments.
"Your system is built faster and more reliably.
...If you used regular Java classes, you'd need to write this middleware yourself over time..."
"You can have different user interfaces. You can reuse the same EJB component layer for a thick client as well as a Servlet/JSP client. With Java classes, you cannot achieve this because Java classes are not remotely accessible."
Talking about Java classes is to broad, EJBs are java classes as well.
You can use a Persistent Object Frameworks just as Apple's Enterprise Object Framework (formerly NeXT), Toplink, etc, which provide the functionality EJB Container Management Persistence layer fails to provide. Moreover these technologies are becoming EJB compliant and playing that role.
So you can buy already tested, solid frameworks that let you build the business logic layer with contracts that are even better designed than EJB.
Moreover you are comparing large grained object models just as EJB, to fine grained object models, just as EOF, JDO or your own framework (in your words : Java Classes)
"...That 'framework' is a fancy word for building your own home-grown application server."
That's not true the app server is the runtime environment for your apps, here you are just defining business logic, and you are doing that probably by building a framework, then your app should inherit or use classes defined in this framework then you deploy the app using an app server. Please use the right terms.
"The framework needs to be tested, debugged, features need to be added. This is a non-trivial task indeed."
Software engineering is a non-trivial task, always! And of course you'll have to test,debug, and add features, over and over again. What do you mean with that? Hell!
"It is easier to hire new employees. If you build your own custom framework using Java classes, then newhires need to be trained on this framework. If your framework is complex..."
2 things here:
- If you are managing big projects then you will always need to train people on your frameworks (even if you are using VB, ok no fwks here but libraries)
- So are you stating EJB is easy to learn...then you never code against it...or you do not know competing technologies such as Apple's EOF, or Toplink.
|
|
|
Message #29408
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
>> You hit the nail on the head there!
>>
>> This just adds to my argument... you take all the
>> information into account before deciding on an
>> appropriate solution and do not automatically take EJB
>> to be the answer.
>>
>> How many of us are lucky enough to be able to start any
>> project from scratch, get real...
I am not sure what nail I hit.
I think I phrased my question poorly - All I was asking was, given a choice (read: Not already locked into some vendor) would you readily commit your company to a proprietry solution?
I wasnt necessarily advocating ejb - in fact I didnt even mention it.
The fact is, if you choose open standards solutions, it is inevitable that the standards wont "fit" your problem 100%. There will be a price to pay for conforming to the standard - and it usually comes in dealing with its limitations during design. However, keep this price in perspective - 70% of a systems total cost will be the maintenance of it (these are industry stats).
The cost (or risk), however, in a proprietry solution - even if it is a good solution - is that you now are committed to that vendor and sometimes there is no turning back.
I am sure that most people are 100% satisfied with their software vendors. I, however, know that at least 2 companies I have worked were extremely unhappy with their vendor. One company was using an open standards-based solution, and they could do something about it - they changed vendor. The other company could not - and they cannot. Until the system is decomissioned, they are stuck with the vendor and they dont like that.
One tempting alternative to avoid tying yourself to a vendor is to write it yourself. While this doesnt tie you to a particular vendor, it has the potential to be even worse. At least with a vendor you have some guarantee of support. As soon as your home-grown "framework" based system moves into a support/maintenance phase, the original developers who know the "framework" (and know how to support it) will move on and the understanding of this "framework" will dilute.
Choosing a component framework like EJB does not trivialise your problem - you trade one set of problems for another. You will perhaps gain a lot on robustness of implementation (in comparison to effort) - but your design will be somewhat more difficult as you have to contend with the limitations.
However, there are some advantages. When your system becomes a "legacy" system, at least there will be a pool of old legacy ejb developers to call on (all those people who used the technology when it was the best thing since bread). At the VERY least, you will find some books on it.
Sadly, most internally developed frameworks fare worse. The core of the developers always move on. Rarely is the software documented well, rarely are there regression tests to prove the systems functionality. The result is that you have a poorly documented proprietry system that no-one knows much about and is very expensive to maintain. Moreover, it will also likely need to scale at some point - and even though the original design allowed it to scale very well, no-one will quite know how to do it.
In the end, you may not have bought it from a software vendor, but you have invariably parted with a lot of money by the end of its lifetime.
I dont think that anyone suggests that ejb is THE solution - but there are some compelling reasons to consider it very carefully. I think that Ed's article was very pragmatic in this sense.
Avoid the hype surrounding how good ejb is. Equally, ignore how fashionable it has become to bash it.
|
|
|
Message #29424
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
hai all,
actually i was also in a dillemma weather to go for ejb
or not for our project and making some studies
what my conclusion is that
1)We should not go for EJB for a FASHION ..only bcoz
we heard many peoples using it we will also
use it that approach must be moved from head
2)i found many peoples putting arguments with
ideas from project they have done.But pls do think that
it all depends on condtion existing on that particuclar
scenario.So weather we need diff type of GUI or Not
or all that transcation mangment hurdles etc must studied
before giving try to EJB.
simply putting fire over EJB is not only argument for
not using a refined tech.
3)what ever argument we put EJB will slow down a application
to level....i admit.But we usally dont switch to EJB for getting speed boosting
Manu,
Square Deal tech
|
|
|
Message #29433
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
"I think I phrased my question poorly - All I was asking was, given a choice (read: Not already locked into some vendor) would you readily commit your company to a proprietry solution?"
Yes - looks like I'm in trouble with the non-proprietry police!
There are "compelling reasons" to look at all possible solutions to a problem.
If following a full investigation of all appropriate information, a proprietry solution was deemed the most appropriate solution I would commit to a it.
If your proposed solution is to go with a specific vendor then they should be investigated themselves in order to minimise the risk of a failed relationship.
Also remember that by using a component framework (such as EJB) that is vendor neutral you are still having to "go with" the framework. If this evolves over time in a direction that you are unhappy with you may still be impacted.
As for compelling reasons to consider EJB Ed's article says:
* Your system is built faster and more reliably - Just by using EJB's? Looks like my job just got a lot easier!
* You benefit from the best practices the world is building around EJB - So I will only be able to find EJB related best practises on the internet?
* You can have different user interfaces - I have to use EJB's to have different user interfaces?
* You can separate your web tier and application server - here we go again...
Ed's article states the benefits of component based solutions not just EJB based solutions as such he should say so.
|
|
|
Message #29488
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
IMHO, there is another valid reason why usage of EJB is not as widespread as one would imagine. This is because most or many IT projects does not involve writing core (meaning manufacturing, HR, shipping etc.) functionality from scratch. These are already fulfilled by existing legacy or ERP applications (Baan, SAP etc.). For e.g. Ed Roman's example would most probably be fulfilled by an existing system in most organizations. So many of these projects are basically web enabling these existing systems (with other augmenting EAI functionality). This being the case, servlets may be percieved as being sufficient. Having said this, I think there is a lot of value in using EJBs as facades to such existing legacy systems. I think a lot of folks would find it useful to see such patterns discussed here.
Regards
Nick
|
|
|
Message #29553
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
hello,
I was expecting some strong points like when to use EJB and when to not.But it seems article is not precisely talking about this.No matter article is superb but if someone who dont know EJB then what he will be expecting from such article is the Bullet points what is to be used and when.
Am i rite??? please correct me if i am wrong.
thanks and regards,
amit
|
|
|
Message #29564
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
<i>Yes - looks like I'm in trouble with the non-proprietary police!</i>
Its not like EJB isn't proprietary. It is a proprietary specification to Sun. Not only that, but the 'guts' of each container vendor's application server implementation is completely proprietary to that vendor. Anyone who has migrated from one container to another can vouch for this.
Anyone who thinks that a complex EJB solution is WORA (Write Once, Run Anywhere) needs to get their head examined.
Regards,
Rick
|
|
|
Message #29603
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Rick,
Perhaps not 100% WORA but damn close. I've ported a medium-sized financial system between containers before without changing code. My head doesn't need examining either.
It's when you use proprietary extensions that you get into trouble, and with most systems this isn't a necessity, unless one was using TopLink (which itself has a JTA hook that allows it to interoperate with several container vendors without code change beyond the configuration project).
Fundamentally, EJB is about creating scalable distributed objects. It's about exposing services over the network, both stateless, stateful, and data-oriented.
Assuming you want to provide a "service" oriented architecture, something that has many clear benefits that have been outlined for years, one now has to make the tradeoff between the Servlet state management & thread model and the EJB state management / thread model. It's generally recommended to services as plain objects and then "wrap" them with either a suitable servlet service (i.e. Apache's SOAP router, custom in-house), or wrap them with a session or entity bean (and then perhaps another router to expose an XML-ized interface).
I believe the benefits of EJB over servlets are there: stateful session beans arguably have a better model for managing large "working sets" than HttpSession does -- though this is highly dependent on the EJB container and the means by which it stores its state. Some servers use multicast cache replication, others just ping the database on each hit.
I would also suggest that entity beans with CMP 2.0 are very promising (as are Session/Entity Beans with TopLink today, of course with Toplink being imperfect, YMMV.)
|
|
|
Message #29713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Help me to Decide ..!
Hi,
We have a (EJB = GO : NOGO ??) situation for our new project. We have a project running on iWS6.0 which uses applets,js,html for frontend and servlets,jdbc in the backend connecting to sqlserver7. Since we use applets extensively for displaying/adding multiple records and lots of popup screens, the online speed is not so high. Also the application is like a client/server sort but via online.
Now the client wants to go for enterprise version to enhance the application with features like email etc and ensure the online speed. I strongly beleive that this could be achieved by jsp/servlet/ejb(statelesssession).
For example let all the popup's(around 1200-just queries the db and shows results with one or two arguments passed to query)replaced by one or two stateless session ejb's. Other add/delete/read/update operations use -again stateless session ejb's. I am going for stateless session ejb because we can track the user thru session and much(all) of the business operations are not spanning to transactions.The traffic to our application is not going to be too high. Am I correct in selecting stateless session beans?...
PLEASE Someone clarify...as it is very critical and I need to give my architecture design in a week and i want to go with sound backing from you experts...!!
Thanks...
Ram Kumar S
|
|
|
Message #29749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
"Perhaps not 100% WORA but damn close. I've ported a medium-sized financial system between containers before without changing code. My head doesn't need examining either."
If you didn't have a change a line of code, I'd say that you should have played the lottery that day, as well. Because you'd have been a millionaire.
"Assuming you want to provide a 'service' oriented architecture, something that has many clear benefits that have been outlined for years, one now has to make the tradeoff between the Servlet state management & thread model and the EJB state management / thread model. It's generally recommended to use services as plain objects and then "wrap" them with either a suitable servlet service (i.e. Apache's SOAP router, custom in-house), or wrap them with a session or entity bean (and then perhaps another router to expose an XML-ized interface)."
No question. In most cases, I think that the servlets, combined with a good persistence framework would more than suffice. And also be scalable and robust. So would the EJB approach. But I think it adds unneeded overhead in terms of financial cost, development time, and code bloat.
"I believe the benefits of EJB over servlets are there: stateful session beans arguably have a better model for managing large "working sets" than HttpSession does -- though this is highly dependent on the EJB container and the means by which it stores its state. Some servers use multicast cache replication, others just ping the database on each hit."
I disagree. Its apples and oranges. HttpSession is very robust and scalable. It has a good event model. In decent containers, they can be persisted between containers in a cluster. There are lots of advantages to using HttpSession, as well. Its not a case of 'one is better than the other'. It is a case of 'they both have their uses and can solve a problem.
If someone wants to be track sessions on a servlet solution, I find it somewhat of a stretch to say that they should go, purchase a container, and use stateless session beans for that purpose.
As for CMP2.0 being promising, I agree. I actually think the leanest and meanest web-based solutions will be one-two combinations of servlets and JDO.
Finally, I'll say that I think EJBs really don't scale down at all. For that matter, they don't perform particularly well, either. Compared to other solutions running on lesser-equipped servers. Because of how the J2EE is written, containers have to do a bunch of things. Even if 90% of those services aren't used. This is really highly inefficient.
Ideally, I'd like to see J2EE go in the direction of modularization. Where a person can pick and choose their pieces of J2EE they want. Even from different vendors. I would love a situation were someone says, "Rick, I've got a great setup. My J2EE uses BEA's implementation of JMS, and Resin's implementation of servlets."
I think it makes much more sense.
Best regards,
Rick
|
|
|
Message #30118
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
I was told that when there are too much data to read from database frequently, such as stock-price query in stock trading, then EJB is not suitable. Is that true?
-zhang binbin
|
|
|
Message #30189
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
If u dig into what WebLogic Express is.. u will know the reality..
In our project, we needed to have just a servlet/jsp engine and hence we turned toward WebLogic Express and after talkin' to the guys for licensing, we realized that, WebLogic Express is just a name for marketin' stratergy, but it comes as a whole WebLogic App/web server, u pay the same licensing amt for what you pay to buy an app server. And when you load onto your box with limited memory etc etc, u wud have installed a whole chunk of app server.
So then u tweak your stratergy as to, if I'm payin' the same amt for an app server instead of a shortened express version, why not buy a bigger chunk :-) !!!
So in reality its not the same as what we think...
Ramesh Hosahalli
|
|
|
Message #30261
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
I am an engineer in the EJB scalability test group of Bean-test, and I agree with Ed in that tuning the application server can yield significant performance improvements/degradations. This needs to be taken seriously when benchmarking the two-tier vs. three-tier setups. Most of the Bean-test users use it to not only test the scalability of their EJB implementations but equally to tune their apps server AND evaluate their software/hardware configs. You just can't accept the default apps server vendor settings.
--------------------
Steve Kolak
skolak@empirix.com
www.empirix.com
|
|
|
Message #30395
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
Hi all.
When reading the discussions here and elsewhere a point that is often said against the EJB and J2EE is that it is a HUGE treshhold to overcome and that it is easier (better ?) to use JSP/Servlets etc.
I think that we can be missing something here.
The customer I currently work for have a few different systems running. It is NOT an Internet site, it is poperiarity systems written in different languages. Today those languages are getting old - they are old 4GL client/server languages. They also have technical equipment that talk to PC's with C++.
When managing the code they have 10 persons internaly and have to hire consultants if the workload is to high.
The idea know is to slowly and controlled move to J2EE to get one language for ALL systems and one familiar environment within 6 to 8 years.
Maintanence will be very cheap over the comming years, people can help each other with all parts of the companys systems, peoples workload will be easier to manage, consultants easier to hire (knowledge about the old languages are rare).
Even if you need to use SQL as well - what's the big deal it is just the 2:nd language for the developers and today they are together using at least 5 to keep the systems running, COBOL, HyperScript, NewEra, C++, SQL.
And they are even using ASP and VB for their Intranet so that makes it another 2 languages and one architecture.
My point is - J2EE is very well suited for large systems and the complexity is more of an advantage, it brings standard and reuse to the organisation.
So - does it mather that it so "hard" to learn Java and J2EE ?
Jan Nilsson
pro IT
|
|
|
Message #30529
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
For small scale projects or the projects which may not need future enhancements, EJB may not be a viable option. Also, if code is developed in such a way that avoids too much dependence on a specific server, u r not restricted to a single vendor. U can migrate in days or even hours to a new vendor product.
|
|
|
Message #30743
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
One of advantage EJB can provide but Servlet can not is autmatic transaction management such as commit and rollback. EJB takes cares for you nicely, but for Servlet/JDBC you have to code it yourself. It will be very hard to code/debug when transaction getting complex. I will definitely go EJB if it a project involves a lot transaction-type-of activities such as those in on-line bank and e-commerce site.
|
|
|
Message #31716
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
I like your thinking. planning is everything. Architectural is soooo important! And, for the most part Gartner sucks! I never seem to read the "why" in their reports. It's like watching CNN, just telling what is. I personally like ejb, for providing a workable middle tier.
Good luck with your work!
|
|
|
Message #32655
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
This is why I think one should use EJB:
To create an abstraction of business rules that can be accessed by more than one application. Where, an application could be a web app(servlets and jsp), java app, delphi app, vb app, C++ app etc.
A simple example would be a Customer business object (assume complex business logic is involved). I have two java web applications (e.g. CRM and Finance) needing to access the same data provided by the Customer object. Since I cannot assume that both my webapp's would be running on the same appserver, it would be required to connect to the Customer object remotely by the webapp's. Here are the choices that I have for creating my Customer object:
-RMI
-CORBA
-DCOM
-EJB
-IIS
I would choose EJB simply because of the following features (From Ed's Feature List)
-instance pooling
-transactions
-security
-container managed persistence
-container managed relationships
-data caching and many more.
The point is, I did not choose EJB based only on its features. I had a requirement where more than one independent application required to access a common object (providing business logic) remotely. I think this should be the primary criteria one should apply before one goes down the EJB route. Everything else is secondary.
|
|
|
Message #38634
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deciding whether EJB is appropriate
I think it gives more points for Using EJB and lees points for not to Use EJB,
Viswa
SLK Soft
|
|
|
Message #73213
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
True
I believe the need for EJB needs to be well-defined. In my view there are just two - remote access of beans, instance pooling. If these two are not a primary requirement for a deployement, then other options must be considered.
Also, the use of EJB, especially, Entity beans and Message beans, take away the kind of performance control that an architect would desire. I somehow feel that Session beans was a good concept, but extending them to Entity and message beans was not.
There are lot of projects that use all the latest features of EJB, but do not really evaluate which parts of EJB they need. The result is too much technology, lack of control on performance and some times reliability is also a big concern.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
