The Middleware Company is pleased to present a new whitepaper, which teaches you the best practices that will help you get the most reliability and scalability out of your J2EE based application and the most productivity out of your developers. It covers all elements of the software development cycle, from design through deployment.

Download The Middleware Company's 'J2EE Best Practices' whitepaper

are they the same practices TMC used to refactor PetStore application?

This is an excellent collection of J2EE best practices.

I do have some issues with some of them, however:

#2 - Design for change with a Dynamic Domain Model

While the content of this Best Practice is very valid and I agree with it, the title of it is, IMO, dangerous and inaccurate.

The real best practice discussed in #2 is "Capitalize on Proven Code to Decrease Testing and Increase Robustness".

I have seen time and time again, some "architect" try to come up with some uber-framework, using some special sauce, that allegedly handles ANY change to the domain model without changing a line of code. This behavoir must be stopped at all costs. I would not consider the usage of CMP or Toplink to be creating a "Dynamic Domain Model". Rather, it is a specific instance of using tested, proven code, which any architect should be doing.

I also take issue with the following quote from "#18 - Do not restrict deployment options at design time":

"Whenever possible, you should maintain as much flexibility as possible as you build the system. That way, if your deployment needs change, you'll be ready to adapt."

That's a fine soundbite, but I have seen time and time again, an architect or tech lead favor flexibility over simplicity and waste countless cycles building for situations that may not ever happen, wasting not only precious resources, but time and money. Take a hint from the XP camp: "You're not gonna need it." Build to your requirements. You'll have enough to keep you busy without adding new ones.

I think the message that should be sent WRT to deployment is to consider deployment in a distributed environment, IF THAT IS A REQUIREMENT.

#19 just rehashs other best practices, except that it buries one of the most important as a bullet point. The important one is to use a version control system. And you dont' need a store-bought one to reap the benefits. CVS is proven and free, so there's no excuse to not use one.

Right on Dave, solve the problem at hand cleanly and efficiently, then when you have a clean working system, grow it to handle the next problem that comes along.

I really hate the "do everything now so we can bill tons of hours" approach taken by every every blood sucking consulting firm in town.

Outstanding comments.

#2: Good point.

#18 Another good point. I'm an XP advocate as well. The point is that deploy-time flexibility is important and too often ignored. Best practices are not hard-and-fast rules.

Page 10. Cache Implementation.
You don't need to synchronize addObject as Hashtable is already synchronized (same is the case of expire) :-)

Cache best practices example does not provide any expiration policy (probably to have something to talk about in memory leaks chapter).

Acme DAO implementaion does demonstrate best JDBC practices:

Class.forName("oracle.jdbc.driver.OracleDriver");
con = DriverManager.getConnection(
AcmeProperties.getProperty("database.CONNECTION_NAME"),
AcmeProperties.getProperty("database.USER_NAME"),
AcmeProperties.getProperty("database.USER_PASSWORD"));
...

and doesn't use Acme Service Locator from the next page

etc.

--
Dimitri

Keep in mind that in the example that you indicated, we had not introduced the service locator pattern yet.

Alse, getInstance() methods in Object Pool and Cache examples should be static

Dejan

UML
Great, lets all draw pictures, grunt and point rather then talking with each other and clearly commenting code. Great advice.

Object Pool
Even sun recommends developers not use object pools as it undermines the gc.

Value Objects
By making a value object mutable, it is no longer a "value" is it? it is a variable, so these are often termed "Data Objects" or data beans. The term value object is misleading, let alone slow and hard to maintain in comparison to local interfaces.

This is a hodge podge of random quotes and sloppy advice all grouped under the "patterns" or "best practices" umbrella. Pick a topic and add something important rather then cutting and pasting from the last shitty rfp the tmc might have spit out.

"UML
Great, lets all draw pictures, grunt and point rather then talking with each other and clearly commenting code. Great advice. "

How do you model relationships with code comments? Commenting code is next to useless. The comments quickly become out of date.

"Even sun recommends developers not use object pools as it undermines the gc. "

Garbage collection causes as many problems that is supposedly fixes. Just like many other 'features' of Java.

"Value Objects
By making a value object mutable, it is no longer a "value" is it? it is a variable, so these are often termed "Data Objects" or data beans. The term value object is misleading, let alone slow and hard to maintain in comparison to local interfaces. "

I follow you up to the point where you mention interfaces. Can you elaborate?

Sartoris Snopes Writes:
"How do you model relationships with code comments? Commenting code is next to useless. The comments quickly become out of date."

Knuth and many others have advocated a very close integration between code and documentation, commenting code is far from the literate programming that they envisioned but it is far better then what rational and together soft is pushing. UML is incomplete and a very difficult medium to communicate with. They are not a replacement for CLEAN READABLE CODE. Anyone who thinks that a uml diagram is better then clean readable commented code is a fucken moron. Clean code is first and for most a communication mechanism for humans, not machines. Please see "Code Complete" for a more complete discussion of how code is the most common and important communication mechanism. Code is NEVER out of date by definition, only a few hard to understand overtly complex and uml diagrams can be generated from code. The key to creating a good UML diagram is not showing very much and including it into a clear text document as a small side image to make the document look less imposing and technical to idiots.

 
"Garbage collection causes as many problems that is supposedly fixes. Just like many other 'features' of Java. "

I don't follow your arguments here.. garbage collection has been proved to be faster then manual memory management. GC is also a feature of almost every modern language for good reason.

" follow you up to the point where you mention interfaces. Can you elaborate"

I am referring to local interfaces in the new ejb2 standard. Arguments are passed by reference not be value, yet the ejb is still remotable when necessary. All to often people use this "value object" pattern because they might, someday, maybe, when the moon turns red move the object to a remote server.

The project is canceled and the shitty dot com has already gone out of business before they every "take advantage" of the "flexibility" inherent in the j2ee standards, and "best practices" the overpriced consultants pushed it on unsuspecting clients.

"Code is NEVER out of date by definition..."

I agree with you 100% on that. I also agree that UML diagrams should be simplea and provide a snapshot of a particular subsection (or partition) of a system.

But having to look at code to tell you that class A implements class B and class A contains many class Cs is not nearly as easy as looking at a class diagram which models these relationships with 3 boxes and two lines.

"I don't follow your arguments here.. garbage collection has been proved to be faster then manual memory management. GC is also a feature of almost every modern language for good reason."

I'd like to see a proof of this. How can that be? How can say 'delete myObject' be slower than 'determine if myObject can be deleted, then delete myObject'?

"The project is canceled and the shitty dot com has already gone out of business before they every "take advantage" of the "flexibility" inherent in the j2ee standards, and "best practices" the overpriced consultants pushed it on unsuspecting clients."

Ha, ha. A cynic just like me. There are so many things out there that are complete hacks or near worthless or totally overhyped...local interfaces being one, GC being another. As for J2EE and standards, what good are they when they change all the time? It's getting kind of silly.

"But having to look at code to tell you that class A implements class B and class A contains many class Cs is not nearly as easy as looking at a class diagram which models these relationships with 3 boxes and two lines."

The boxes and arrows don't provide any more information then the code, in fact they provide much less. How is the containment performed? are instance of class c created in A? are they assigened by an instance of class D after a user event is fired? ALL of this information is avialable in the code, and I can determine it based on where I choose to look.

Sure, a strucutral diagram like you descirbe is usefull, like I said, at an "idiot level". They are primarly used to take the edge off a text document so that the business analyst can feel secure in knowing a small part of the system. It provides you with NOTHING when you need to understand how things work, and how to make changes to the application. They are like a shot of vodka, easy to take, empty calories, and provide a false sense of confidence.

"How can say 'delete myObject' be slower than 'determine if myObject can be deleted, then delete myObject'?"

By grouping deallocations in batch, fewer calls are made to free, or whatever machanism is used to free memory. The mangare is also able move and allocate like objects in the same portion of memory, which has been proven to increase memory caches.

"But having to look at code to tell you that class A implements class B and class A contains many class Cs is not nearly as easy as looking at a class diagram which models these relationships with 3 boxes and two lines."

I agree here. UML has its place for communicating high-level information. And sometimes you don't want to look at the code. Sometimes a person will be asked by a co-worker to describe how a particular system is designed. Sometimes a quick UML sketch containing a handful of classes on the white board is much easier than going through actual code. And sometimes the code is not crystal clear at first, especially if there is a significant amount of indirection. In these cases, it can take a few minutes to "get your bearings" in new code.

I think the point of addressing UML in the white paper was to say everybody needs a *common* modeling laguage. This way, when somebody draws a diagram describing an aggregate relationship, everybody understands.

"I'd like to see a proof of this. How can that be? How can say 'delete myObject' be slower than 'determine if myObject can be deleted, then delete myObject'?"

Perhaps some of the time saving is in development. That is, when not having to manage your own memory in a GC environment, it is one less thing to code. Also, the development "costs" of manual memory management do not scale like the run time "costs" of GC. As GC technolgies and hardware improve, the costs go down. The development costs of manual memory management will always remain.

Ryan

Models are one way of communicating and comprehending code. Often a very good way. However, it's a common fallacy to assume that UML models are the _only_ valid way to form and communicate understanding. I use forward engineering when it helps me understand and communicate a design. On other occasions, plain Java code does just fine. For example, I've just had to hand over a moderately complex application to a co-worker. We went through the code, he understood it very quickly, and he felt more comfortable with a code-oriented explanation than with working with a model (although he has an excellent understanding of UML).

Rod

This is refreshing to see that TMC is learning Java and J2EE development.

I wish they would had read these from other sources like we as developers have been using and put in using. I dont think TMC should have done the PetStore app since their knowledge of Java was so shallow prior to this.

I guess it is never to late for TMC to learning Java as .Not is a total failure.

Quite amusing : the day TMC announces a whitepaper "that will help you get the most reliability and scalability out of your J2EE based application", theserverside crashes again and again with the message "An Unknown error has occured, please try again later" ;-)

Jean-Baptiste,

  If you would email me (floyd@theserverside) with the details of these crashes you mentioned, I would appreciate it. We are always looking for and fixing bugs/probs. The trials and tribulations of running a production site.

Floyd

This is a good summary of conventional wisdom on J2EE design. However, there is increasing recognition, based on hard experience, that conventional wisdom on J2EE design is not always so wise. See, for example, the new "Bitter EJB" book and my own recent book, Expert One-on-One J2EE Design and Development for discussion of some of the problems with some of the recommendations.

A case in point: p 7 discusses the benefits of a domain model implemented via entity beans or similar.

"In the event that the database schema changes, which it inevitably will, the programmer will have significantly fewer lines of code to change then if the entire persistence layer was written from scratch."

This is highly debatable. What entity beans give you (in 90% of the applications I've seen that use them) is a fake object model that is really a relational model, heavily tied to the underlying RDBMS schema, with a 1:1 relationship between "objects" and tables. If the schema changes, the entity bean model becomes unworkable, and the verbose entity access code in session beans will need reworking.

The sections on building, deployment etc. are excellent, and it's good to see this covered, as it's often missed in books. It's also good to see testing covered as an integral part of the process.

Some other comments: The JDBC example on p 46 should use an abstraction layer to simplify use of JDBC (such as I present in Chapter 9). JDBC rapidly becomes unmanageable if everywhere we do a JDBC operation, we need to do the whole try/catch/finally, as in the example. This is also a rich source of errors. (Also, this code should really get a connection from a container-managed DataSource, not load the JDBC driver itself, which will prevent it benefiting from connection pooling and global transaction management.) Throwing an Exception is also a bit primitive: Chapter 9 discusses a much more expressive, data acess strategy-independent hierarchy of data access exceptions for use by DAOs.

Likewise, object pooling and caching should really be achieved using third-party solutions, rather than hand-rolled code.

These issues aside, there's a lot of good stuff here and TMC deserve praise for doing the community a service by releasing the paper free.

Rod Johnson

I like your point about EJB alternatives. Part of what we were trying to do in the paper was to help our customers get the most out of what's in J2EE and EJB. There are some outstanding persistence alternatives that bear serious consideration, including several good commercial versions of JDO and some good proprietary relational mappers, including TopLink (especially if you're using Oracle stuff.)

This should be called: Best Practice with EJB, since it presumes EJB.
Since EJB proved to be not scalable in production and it is complex to develop, only small and simple applications that need CORBA should be built with it. The Conventional wisdom is never to use EJB for persistence as we know, boys and girls.
See your figure 27 for a working alternative.

The first slide shows nice waterfall process... minus the requirements. If there is no requirements, there is no success. Oh wait, you have EJB, requirements are not needed.
(What I do for a living, the way I pay my rent, food, etc. is doing project recovery! Keep my web site handy towards the end of the project when you need to deliver so you can contact me, see baseBeans.com)

Risk is best defined by PMI.org. Your solution to risk does not compute. When solving a bus. problem, you should only consider proven technologies that you can lean on in a production environment.

Dynamic "data" model? In case it changes? I see.
Let me say this is well known: " The slowest part of J2EE is data access ".
And from SQL P&T (performance and tuning ): "At least 90% of achievable performance is in the data model." There is no Dynamic data model.

UML? A type of flow chart is important?
Not all developers or business users think it UML terms. Your picture 27 is not UML, but developers and bus. users know understand it. If you are a programmer, you can read source code, or maybe even write it.

Resource usage as a best practice? Most developers use the containers pool or Commons Pooling or Poolman.
Very rare that someone writes their own pool, when there are many good jars where you can just use it, including one in JCP, at jakarta.apache.org/turbine/jcs

Design patterns, or Algorithms at those with a degree in CS call it. I say use OO: "is a/ has a" more than Algorithms. OO saves costs.

Ant is a good practice, especially for building a WAR, but so is Maven.
You can also put your build path to web-inf/classes and Tomcat or Resin or Orion will auto reload the changed class and save a session so you can keep debugging without restarting the container.
In server.xml set reload=true.
Auto reloading class during development is a good practice.


Test. Finally. This saves costs.
When you have requirements and a test case, now we have something.
Presumable find the optimal, lest risk solution as next step.
How you test is not important, just do QA, IMO.

Manage memory? In C, yes. Not in Java.

Figure 25 is a joy for a sales man to see. Web machines, Presentation machines, Business machines, and a database cluster?
Did anyone ever see a database cluster in production?
I did, and got rid of it to make it faster.
Did anyone ever see a cluster of EJB machines in production? I did. The client went to .NET.
Anyway, you just maybe need more application servers, and none of these other machines. And
only if you have more than 2000 concurrent users (say on Tomcat), since a J2EE app. server can support more than 2,000 concurrent users
(if you do not use EJB for persistence, but use DAO, such as Ibatis, rowset, basicPortal.com or Commons-SQL).
But note that most apps are very small and have 50 concurrent users.
So lets say you have 10,000 concurrent users, you need 5 app. servers, a cisco up front with a sticky, and 1 fast IO db server. Spend your money on people, not HW.
Anyway, if you do not know J2EE, you can save money with .NET, since this drawing does not work.
(Are you guys new or something?)

Figure 27 I like, a non UML flow chart, showing how to get to data. See how you gave an option to by pass the VO and EJB and caching and facade? Keeps it fast and simple.
Good. You should put that up front.

Listing 32. ?? Writing your own security all over the place?
Ok, that is violently stupid. If this is a J2EE paper, I expect you to know Servelet 2.2 and Web.xml.
If you have a Sun Certified Java Web Developer on staff you would know this, which you could afford if you did not spend all this money on HW.
You SHOULD know that there is a getUserPrincipal, and is user in role servlet api.
You should know that Struts action mapping uses it. Ok, maybe you do not know Struts action mapping, but you do know web.xml where you set up container security.
http://edocs.bea.com/wls/docs61/webapp/web_xml.html
A good practice is to always start with J2EE built in security, declarative and container manager.

J2EE is more than EJB, you should also know Servlets, and Standard tags and container pool, and reuse of jars.
Session facade is for EJB only, as is VO, for EJB only.
DAO is good!

You mentioned iterative process and never explained it, I guess you are not sure what that is.
Have a Project manager and experienced architect review this before hand next time. It's closer to newbie guide to known pitfalls.

Good practice summary:
Struts! That is a best practice, makes it hard to fail. Use with Java Sandard Tag Library and DAO.
Pay attention to requirements.
Write good SQL. Spend money on your people do not hardware. Done!

Vic Cekvenich
Project Recovery
baseBeans.com

You can read up more about action mapping, including security role (from servlet/web.xml) on page 593 of "Struts in Action".

<sameless promo text=" baseBeans.com won best training as voted by Java Developers Journal for their "Fast Track to Struts". A new version of the class public is out.
You learn a lot in the class.
baseBeans specialty is project recovery "/>

.V

Vic,

"Since EJB proved to be not scalable in production and it is complex to develop..."

Can you back this with a survey ? You may be right but I find it a bit easy to assert things like this without a proof. Scalability seems to be a problem with entity beans (in my experience) but I never had problems with neither SLSB nor MDB: they're basically transactional pooled instances with extra standardised functionality. And so much for 'conventional wisdom'... Where did you get that concept from ?

"What I do for a living, the way I pay my rent, food, etc. is doing project recovery!"

And you wonder why you have bad feelings about EJBs ? If they only send you to failed projects, when will you have an opportunity to see EJBs at work ? :)

Vic, I agree with most of the things you say in your post (excepted that I don't see Struts as the ultimate in MVC applied to the web - check out Rod Johnson's book, it contains a very interesting approach), don't get me wrong. But you don't need to sound like an angry young man. You don't have to diss basically everything there is in the paper. I've read the paper too and I think that if architects/designers and developers apply the concepts it contains, the rate of project failures has a chance to diminish. You can always reach a 'better' level. Most people can live with 'good'. All that people want is that requirements are met (included performance) and many are happy to spend an order of magnitude more than they should in hardware and software licenses. You have to accept that not everyone is skilled as you are and be a bit tolerant. Objectively, I think this paper is good even though I don't agree with everything.

"You mentioned iterative process and never explained it, I guess you are not sure what that is."

You should not be so arrogant. That does not bring anything of interest. Just my opinion. I have not read your book, I'm not sure I'd really want to with such an attitude of yours, anyway, but if I go to amazon.com, do I see 2 stars out of 5 in 15 reviews, ranked 211,291 ? That does not sound like you did any better than the TMC paper, excepted that your book is not free.

It all holds in one unique word: humility.

                Yann

I do not take this work to serious, I was just having fun.
My book is FREE at basicPortal.sf.net, click download, click doc, it's there. It was the first Struts book, first on any framework AFAIK.

I did not come out humble, but I agree with every point you made; if I have to judge a programmer in first few minutes, I do it only on humility, if they are humble they tend to be smart. (Hence I must not be that good? OK.)

I did work on EJBs, and found they need a room full of machines, and that those clients went to .NET to save money and get more performance.
Tell me this, how do you do a multi row updateable master detail “EJB”?
Multi row and EJB! With Master Detail. Most forms are complex like insurance forms.
EJB makes it hard.
DAO makes it easy to do a nested beans, that are updateable in multi row.
And no need for VO and façade and caching. Less objects = less work = faster in practice.

I think my point is J2EE != EJB.
We have servlets, jsp, tags, DAO, etc.

And I do mostly go sent to bad projects. One thing I learned is that technology is mostly ok, but failed projects tend not have real requirements, (Ex: Our requirements is that we will use EJB")


I wish I was young. 40! Maybe foolish, or funny?

.V

<vic>I think my point is J2EE != EJB. </vic>
Yes. EJB has its place, but it shouldn't be used automatically. The value proposition must be carefully examined on a case-by-case basis.

<vic>
One thing I learned is that technology is mostly ok, but failed projects tend not have real requirements, (Ex: Our requirements is that we will use EJB")
</vic>
Yes. One of the points I make in my book is that the requirements should drive the technology choice, not the reverse. J2EE rode the dotcom wave of technology-driven euphoria: 2-3 years ago few questions were asked about ROI. Most of the technologies are fine in themselves, but they're tools to an end.

Rod

Vic:

Also keep in mind EJB != BMP entity beans! Don't bash EJB as a whole when you intend to imply certain flavor of EJB's is not as fast as it is desired to be! SLSB and MDB have proven to be scalable and performant as well. The scenario you proposed can be done easily using SLSB + JDBC (via DAO helper classes).

Vic,

"Tell me this, how do you do a multi row updateable master detail “EJB”? Multi row and EJB! With Master Detail. Most forms are complex like insurance forms.
EJB makes it hard."

I agree with you. EJB entity bean is a standard that was written for the record-level, hence its inefficiencies when it comes to handle more than one row. As far as I can see, on the projects in my neighbourhood, CMPs are only used for writing one record at a time: this is probably the only case where there do not hinder performance. This restriction completely defeats the purpose of using CMPs at all. Some application servers will commonly solve your problem doing batch updates but that's not enough to justify the complexity of writing CMPs and the subsequent application servers high price in general. Ok. This is not the right thread to talk about this so I'll stop there.

"I think my point is J2EE != EJB."

I'll add EJB != {CMP,BMP,SFSB}.

"One thing I learned is that technology is mostly ok, but failed projects tend not have real requirements, (Ex: Our requirements is that we will use EJB)"

I agree. I also see that often, but I think it's changing. Things like this TMC report are useful because they stress on performance and unit testing for instance and how to specify those. If one of the requirements of your project is "We will use EJBs", then you follow TMC's advice and run your benchmark and then identify a bottleneck at CMP level, then you must follow another path. This is exactly what happened recently to a project in my working environment. We have to accept that it takes time before technologies are really understood by a community.

The first part of the white paper is excellent. I found the second part "J2EE in action" less interesting because it isolates those 'patterns' and throw them too much into relief. That's the part you really did not like... :) And even though I'm not a big Struts fan, I have to admit that it is much better than any model-1 anytime and that it can be considered a good practice.

                Yann

I too like TSS and am glad they have a forum where I and other particapate to air out ideas, end product beeing better J2EE.

.V

Vic,

You know - I appreciate your circumspect reaction to Yann's post. So often, people react very violently and entire threads become flame wars that really reduces TSS's appeal. Thanks!

IMHO, (emphasis on 'M'), I think TMC has been given enough flak for whatever happened with the benchmark. Probably a case of misaligned priorities. (I find it difficult to view TMC and TSS as distinct entities). I think its best avoiding flame baits (TMC-related or otherwise). TSS is probably one of the best forums for J2EE discussions. The quality of any forum averages out pretty fast with flame wars.

The thing is - if large projects merely use SLSBs and sooner or later, the community at large re-defines
EJB == SLSBs (more or less), then do we perhaps need a revised spec that really simplifies EJB development and deployment practices. You know - may be an EJB-Lite version of the spec that focusses around SLSBs (and perhaps MDBs too - MDBs are fun)?

It would also be interesting if the O/R software vendor community could collaborate on defining some sort of standard for O/R mapping. This could be as simple as defining a standard XML schema for O/R mapping plus defining connectivity and EJB-compatible transaction semantics (so that integration with SLSBs work without hacks). Sun seems to not like JDO, so if O/R mapping is here to stay to replace custom-SQL-based persistence, then we might as well standardize it.

That's a far-fetched concept now. Also, some amount of co-ordination with the metadata spec would be good as well in that case. One persistence option could be to use beans enchanced with standardized AOP-ish "persistence-hint" attributes. (I don't think this really hinders portability. I also really don't want people necessarily poking around my XML O/R mapping files if I am shipping a commercial product.)

Sandeep

Sandeep,

I also appreciated Vic's reaction to my first post as I tend to agree with many things he said (excepted the tone he used to say it). I'm glad to know that he was not too serious. :)

I'm not a fan of flame wars either.

"It would also be interesting if the O/R software vendor community could collaborate on defining some sort of standard for O/R mapping."

Apparently, JDO 2.0 (the next one after 1.0.1, a maintenance release) will define an O/R mapping standard. It's the only thing that is disclosed about it so far.

                Yann

Sheesh what a rant!

>> Design patterns, or Algorithms at those with a degree
>> in CS call it. I say use OO: "is a/ has a" more than
>> Algorithms. OO saves costs.

Algorithms are not patterns. Patterns are OO and OO is a lot more than "is a", "has a". But you might need a bit more than a degree in CS to understand these things...

<quote>Since EJB proved to be not scalable in production and it is complex to develop, only small and simple applications that need CORBA should be built with it. The Conventional wisdom is never to use EJB for persistence as we know, boys and girls. </quote>

Can anyone throw some explanation around this ? Does this mean no entity beans ? no CMP ? no BMP ? What is small and simple?

I'm not trying to start a flame war here, I just want to understand - in more than subjective terms - what you mean by "never use EJB for persistence".

Sure I know some of the problems that Entity beans have, but based on my own experience and from what I have heard from others, entity beans do work .... and in large numbers.

What I would like is some detailed numbers & explanation on this.

There is a lot on EJB in TSS and even Google.
I like light weigh DAO, such as
Commons-SQL on Jakrata in Commons, or
http://developer.java.sun.com/developer/technicalArticles/javaserverpages/cachedrowset/
or
basicPortal.com
or
ibatis.com/common


More on EJB do and don't(including VO and facade and caching):

http://www.softwarereality.com/programming/ejb/EJB_101Damnations.pdf

http://radio.weblogs.com/0107789/stories/2002/05/24/isEjbAlwaysNecessary.html

http://www.tallsoftware.com/dotnet/Java%20to%20J2EE%20to%20oblivion.pdf

http://www.tallsoftware.com/dotnet/Java%20to%20J2EE%20to%20oblivion.pdf

http://www.mail-archive.com/general%40jakarta.apache.org/msg03376.html

So that picture 27 they have says a lot, chose DAO or chose EJB.

I also do not like JDO, or any XML defined variation, since like another poster in this thread said, O/R tends to mirror R, and gets in the way.

Example is multi row updates, or master detail or any moderately complex page. Try it with O/R. Then try it with just DAO.

Everyone, please try a multi row update of a JSP via RowSet above, you will convert! Nesting beans works great for master detail. And now I have large sites with high load, low cost, high performance, simple to develop.

Hey everyone, sorry about the tone.
And thanks TSS for this forum, hope you use the ideas.

hth,
.V

Vic,

I know enough about J2EE, EJB and entity beans. And I definitely know how to google. Have already read all those links a long time ago. What I was asking about has to do with your original post.

So getting back to your original post ..... (I am inserting a copy of my previous post here):

<quote>Since EJB proved to be not scalable in production and it is complex to develop, only small and simple applications that need CORBA should be built with it. The Conventional wisdom is never to use EJB for persistence as we know, boys and girls. </quote>

Can youthrow some explanation around this ? Does this mean no entity beans ? no CMP ? no BMP ? What is "small and simple"?

I'm not trying to start a flame war here, I just want to understand - in more than subjective terms - what you mean by "never use EJB for persistence".

Sure I know some of the problems that Entity beans have, but based on my own experience and from what I have heard from others, entity beans do work .... and in large numbers.

What I would like is some detailed numbers & explanation on the original statement.

Wow, I really like the organization of this guide, as well as the comments that have been posted on this forum.

I'm wondering, does anyone know of any other best practice guides that one could point developers at for standardization as well as architecture and performance concerns? I'd like to publish a similar guide for my developers, but have found little relative material out there.

The Sun Blueprints guide is nice, but hard to get people to retain 440 pages of text. This guide is nice and concise, contains few errors, and is easy to read.

Any others out there?

We did not try to rewrite any of the outstanding articles already on TSS on choosing whether to use EJB. Instead, we tried to help J2EE developers use the tools and frameworks at their disposal. Undoubtedly, we made some mistakes, but the paper as a whole contains a free, and useful, consolidation of J2EE best practices.

You make some interesting points.


"The first slide shows nice waterfall process... minus the requirements."

You can view it as a waterfall, or as we intended: the cycles in an iteration. As to your development process, it depends on your development method, no? We lumped requirements into the design step, since they do not have a significant impact on the types of issues that we discuss in the paper.

"Your solution to risk does not compute. When solving a bus. problem, you should only consider proven technologies that you can lean on in a production environment."

So no one under any circumstances should try anything new? I disagree. We applied Servlets after an early proof-of-concept when the technology was young, and shaved nearly four months off of our total development cycle. The key to risk is understanding your requirements and tolerence, and plan accordingly to minimize risk. In general, you should be more aggressive earlier in the cycle, and more conservative at the end.

"Manage memory? In C, yes. Not in Java."

Actually, Java does minimize your memory management, but absolutely does not eliminate it. In C, you must explicity free every node in the tree that you want to free, and update each remaining object that references the object in the tree. In Java, you need to make sure that no object in the tree is reachable, especially where a long lifecycle meets a short one.

Thanks for the interesting comments. Tone it down a little, and I'd love to chat with you about them.

Dear Bruce

"You make some interesting points. "
Thanks.


"Thanks for the interesting comments. Tone it down a little, and I'd love to chat with you about them."
Yes, I wish I knew how to tone it down, will try next time. It tends to lower the impact of my message with the tone.
Same here, if you want to chat, even voice.
vc at basebeans.com is the "real" e-mail.

Yes memory in Java, like session should be managed.

I do think that for a bus. production application, one should not do anything new. That is for systems and technologies, but not for bus. applications.

Re: cycles. I must say I mostly read it light. I just wanted to sort of say, in my own way, that #1 should allways be requirments. Then we can talk arcitecture, etc.

Vic

"In C, you must explicity free every node in the tree that you want to free...."

Every heap-based node.

Page 41-42

And what is wrong in the basic login module provided by the server? And isUserInRole() calls later to check rights?

Marina
Coldbeans &#8211; Java server side components

Okay I'm a stickler for proper terminology. In this otherwise good document, sticky HTTP sessions are described using the term "sticky bit". The only sticky bit I know of lives in the Unix filesystem, and has nothing to do with J2EE or even the Web. What the document describes is called "sticky sessions" and uses a lot more than one "sticky bit".

Sticky bit refers to a Cisco setting that works with mutiple app servers.

TSS had this drawing of lots of computers, and I said you do not need all those type of computers.
Just mutiple app server in case of more than 2000 concurent users, with a CISCO set to sticky, so it allways sends same session to same box.

hth, .V

I liked this whitepaper. Ther are a lot of interesting advices but there are few very bad examples:

page 41. listing 32
- What is UserFacade class? If it is session bean it should locate HomeObject first. It seems that getUser() is static..
- If it is BusinessDelegate object why you haven't mentioned that pattern, too?

page 46. listing 38
- Connection is not pooled, no DataSource used.
- Driver name is hard-coded. It is strange since username, password and connection are not hardcoded but accessed using AcmeProperties class. BTW, you have _properties class variable which is not used in code!
- I would suggest using abstract DAO class which would define all methods common to all DAO objects - getting connection, releasing resources. Other DAO classes should extend it.


I would also suggest adding servlet filters or using abstract Action class that should be extended by other Action classes. It would simplify maintenance and adding common functionality. There are also other useful J2EE patterns that you haven't mentioned.

Don't get me wrong, but this is not J2ee tutorial or getting started document - it is Best Practices. So examples should ilustrate best not bad practice!

Dejan

Other than jdbc connection pools, what are some examples of when you would pool objects and would those be pooled inside of the ejb container or by the client application

I found a decent critique of this paper at:

http://www.neward.net/ted/weblog/index.jsp?date=20030210#1044877160285

I tried posting this as a separate news item but TSS has declined it for some reason.

--Dilip

hi,

This request came might be too late. I would like to know where can download the sample code. I'm following the instruction stated in the article which is get the code from http://otn.oracle.com/sample_code/tech/java/oc4j/content.html. But unfortunately, I couldn't find it over there. This is an excellent and complete guides for J2EE system development. I'm really looking forward to look at the sample code. I will very appreciate if someone can help.

Best regard,
ICKO

Search the Oracle Application Server forum (using keyword of ACME), you will find it there (I found this by chance, and I cannot remember the links)

You can see how some (unthoughtful) references are so hopeless and cost people time like you and I.

Cheers!
huy

The Pool class sample seems to be flawed - the checkOut() method doesnt update the locked Hashtable if there are items ready for use in the unlocked table - effectively, this means a client can checkOut() as many instances as they want without ever having to do a checkIn(), defeating the purpose of having a capacity at all.