J2EE Blueprints is a developer program from Sun Javasoft. This program provides architectural recommendations and design guidelines that help J2EE developers effectively use the J2EE platform and its various technologies. A new article on onJava.com explains the who, what, where, why and how about the J2EE Blueprints.
Read about the blueprints on onJava.com
Quote from article:
"J2EE Blueprints' primary goal is supporting the J2EE application development community. It is an available resource -- with free sample code -- to understanding, architecting and building better J2EE platform based applications. Since the future of J2EE Blueprints program is driven by the needs of the J2EE application developer community, its success depends on the value it provides to that community."
This another example of "not invented here" anti pattern.
Java community generally takes care of itself, with regards to understanding, architecting, designing and things like that.
The best example here is theserverside.com where many design issues are addressed from different perspectives using input from several point of views.
We don't really need to be fostered by architecture guidelines, like we don't generally know what we are doing and we'd better stick with Sun's precious advice.
Please note that Blueprints are addressed to intermediate to advanced developers.
When Floyd adressed the invitation to Sun's "architects" to join here for various discussions he got no answer, so they are reluctant to come and promote their ideas in a real forum.
There's one notable exception, Craig Russell (the JDO lead) who is to be commented for taking time to contribute here.
And the -- free sample code -- they provide is in reality VERY EXPENSIVE, it contains a lot of bugs, and not minor bugs from oversight, but things that reflect their misunderstanding of technologies and real life development issues.
I don't think any one person can speak on behalf of the Java Community. I think that a lot of people can benefit from the J2EE Blueprints, particularly newbies. The maturity of the industry as a whole can be measured by the 'prevalence' of well documented best practices. Something we are entirely lacking today, which luckily is currently supplied by the J2EE Blueprints.
I for one applaud them, the Blue Prints was a bold initiative, the very first set of architectural guidelines and the first non-trivial application the J2EE industry had access to. Back in 99, no one was using MVC for their servlet architecture, after the Blue Prints came out in early 2000 MVC became mainstream.
>>This another example of "not invented here" anti pattern.
Sun was nice enough to spend time and money on a whole team of authors and developers to sit down and provide us with the Blueprints and Petstore, back when J2EE was in its infancy. This was a very commendable and responsible act on their part. Before the Blueprints, there was only the Specs, which were designed more for J2EE vendors than for end-developers.
It is always easy to identify and criticize small details about their implementation, particularly now in 2001, now that the industry has had time to absorb and improve upon the J2EE Blueprints. Overall the Blue Prints are probably still the single best way for a beginner to learn J2EE development. There is still no other educational resource that illustrates their concepts with a non-trivial example (find me one book!).
>Please note that Blueprints are addressed to intermediate
>to advanced developers.
On the contrary, this quote comes from the BluePrints architectural Overview:
"Knowledge of the Java language is assumed, as is some understanding of basic issues in enterprise data systems. The target audiences for this document are developers, software architects, and technically-oriented managers who are interested in using the Java Pet Store sample application to understand how to use the J2EE platform."
I think this objective is met by the Blueprints.
>We don't really need to be fostered by architecture
>guidelines, like we don't generally know what we are doing
>and we'd better stick with Sun's precious advice.
Costin, based on your posts here, you are a very knowledgeable J2EE expert, who obviously has outgrown the Blueprints and doesn't need them. However, I can tell you that a large majority of J2EE folks are still beginners, and they need architectural guidlines more than anything. The last thing they need is API documentation, what they need is architectural guidlines so that they can stop hacking and start building better systems.
ps - I never issueds an 'invitation' to Sun architects to come and play here on TSS, and there has infact been a lot more involvement from Sun on TSS outside of that JDO thread.
" the very first set of architectural guidelines and the first non-trivial application the J2EE industry had access to"
Nice from you to defend them, and it is indeed commendable that Sun invested resources in making blueprints and sample application, providing they did a quality work.
Apparently they didn't.
Otherwise each in the Java industry had access to our own applications and our own thinking, and you don't have to be a "J2EE expert" to do your own thinking.
But when I looked at the sample application I was scared.
Youd don't give such an application as an example because there will be people who will literally repeat the bugs.
And those present in Java Petstore are not normal bugs that can happen to anyone , including me and you.
There are bugs reflecting the fact that those who wrote the application don't understand issues.
"Overall the Blue Prints are probably still the single best way for a beginner to learn J2EE development"
Well, I'm not so sure it is a good way.
It is a way , but it may have undesired results.
And I quoted from the article which was written by somebody from Sun, so you can hardly argue that the BluePrints are intended for beginners.
"you are a very knowledgeable J2EE expert"
Floyd, you can do better than flatter me.
I'm NO J2EE expert, I have some experience in writing server application, and I don't want to be a J2EE expert.
Until J2EE matures, I can hardly think theres' anyone who can be proclained J2EE expert.
I have studied the Pet Store Demo code in some detail and learnt a lot from it. Especially about how to implement MVC.
I'd like to know what bugs are in it so I don't repeat them.
Can someone shed some light?
Peoples concerns (including bugs) with the blueprints have been addressed in this thread:
I have to agree with Floyd. I'm pretty new to J2EE and I think that the blueprints are and have been invaluable in my efforts to grasp the fundamentals of J2EE. The complexity of the example is in my opinion very appropriate. It is non-trivial in technical sense for beginners.
At the same time, as you point out (Costin), it is very bad if there are severe bugs or architectural flaws. But instead of criticizing the blueprints as a whole, I would rather see a constructive discussion of the blueprints. This would benefit us all, wouldn't it?
So, instead of postulating things, why don't you share your expertise, Costin.
Follow the link posted by Floyd, and you'll see to obvious bugs that I discovered at a summary look.
The problem is that I never studied the whole application, and I wouldn't discuss it here.
It would be also very difficult for me to do that considering the enormous amount of classes and lines of code in there.
If you make an analysis from a software engineering perspective and try to get the ratio between the problem complexity and the amount of classes and lines of code generated, than I think Pet Store application is not an example by any measure.
I was turned down when I saw how complicated things need to be and how a large amount of repetitive code clutters the whole thing.
You just can't study the whole application as a hobby, unless you have a special interest, so I wanted to follow a simple use case to see what specific code is executed in just one branch, and I discovered some terrible bugs.
The problem is that I really want to contribute here and share my expertise with anyone who considers me of some help, but I really cannot do that on the margin of Pet store application, because I don't want to sacrifice a large amount of time studying the whole thing.
It might be possible that the focus of the app writers might have been to illustrate phylosophical issues about architecture and design patterns.
So it might be good for that purpose.
But I am a practical guy and for me all ends up in the quality of code.
Following the principle of XP, "the design is in the code", it turns out that even the design isn't shining.
Thanx for your response. I didn't mean that you should do a full analysis of the blueprints. Nor did I mean that you where responsible for one. However, when you totally discard the blueprints, which I believe you do, one starts to wonder. Especially for me, who still has lot of bridges to cross, even if I think I walked on some of them.
Speaking metaphorical, what I mean is, that you throw in a bone without any meat on. For example:
>Paged List is an anti-pattern the way they put it.
In what way?
>BiModal data access is an anti-pattern the way they >describe it.
>Not using PreparedStatement the way it should be is an >anti-pattern
Agree, but do you have the same understanding as I do?
>If you make an analysis from a software engineering >perspective and try to get the ratio between the problem >complexity and the amount of classes and lines of code >generated, than I think Pet Store application is not an >example by any measure.
How do you measure problem complexity? (You don't have to anwser that). But I'm interested in your opinion of what this relates to, J2EE or the example? (maybe both).
Anyway, I think, as somebody said before, that this points to a new example (if possible). Floyd, are you going to use an common example throughout your book?
Ps: I do not wan't to throw in a flame, but is it not a bit odd to discard the whole blueprints if you only have skimed through a branch in the Java Pet Store?
Let me detail more.
I analyzed a couple of branches and mistakes are repeated of course.
The most glaring is the one with the PreparedStatement, and nomatter how novice you are, even if you only study the Java Tutorial (that's a really good beginner's book) you should know that that is what PreparedStatement is for.
A mistake like "SELECT seq.nextval FROM Orders" is not a simle mistake.
First of all it shows that whoever wrote this doesn't understand the principles of SQL (no the syntax, the syntax is very easy).
Second, it brings a production database to a halt.
How about complexity ?
Well, the single objective approach is the function point analysis, which of course I only estimated, but you can judge by the number of screens and input fields that it's not a very complex application.
However because of this highly phylsophical, pattern driven approach, the code bloat is impressive indeed.
You can pick up an simple entity in the system (pick one at random such as order, customer,product, whatever) and try to count how many classes and how many lines of code.
And tell me if you are willing to do the same in a real life problem.
Why do I discard the blueprints ?
Well I don't discard the blueprints necessarily, but you have to consider that the PetStore applicationis is a direct result of the blueprints architecture.
And not only the blueprints, but also the J2EE patterns catalog has the same problems, they are overly complex and they make J2EE programming look like "rocket science".
You have to create tons of classes,interfaces, separate layers, decouple objects from data and so on, so forth ...
It's just not happening like this in real life development, unless you want to program for your own esthetic criteria and not for the end-user result.
Server Side programming is extremely simple providing that you follow basic principles and not the latest hype.
In real life the basic principles are:
"Keep It Simple", "You ain't gonna need it".
For more principles you can go at www.extremeprogramming.org
I appreciate the responses that you have given back to this discussion but I still don't see or understand the errors that you elude to.
Yes, I see that Blueprints is a lot of code and a lot of classes but I personally see that as "they're trying show a 'correct and full featured' J2EE implementation if the devlopment team had all the time they needed". Ex. They implement a lot of Interfaces and extra classes that I believe would be 'best' design and practices. I would love to have the time to Interface all my variables across all the project code and make a Interface for any potential extensions I envision in the future.
Perhaps we are looking at this the wrong way and our expectations are different. I am a practical guy also. For example, Windows DNA has their own example of their architecture (FM Stocks) and they're code can be quickly used and digested but PetStore is something that can't just be quickly used and digested (I personally believe that XP will not work with this app. Since it was designed probably using RUP, we need to think the app in that way).
Once again, thanks for your thoughts!
Ok I'll spell the errors on their name now,
When thhey try to generate primary key for Oracle using sequences they use
"INSERT INTO ORDERS(PK, ...)
which performs correctly but you don't get the pk just inserted,
and followed by
"SELECT seq.currval FROM ORDERS"
which is terrible because it will not only retrieve the current value but n-times the current value where n equals the number of rows in the ORDER table, also placing readlocks on the table.
Now go figure out what that means in a production database.
Then, when you say something like
"INSERT INTO USERS (..., LAST_NAME, ...)"+
"VALUES (..., '"+user.getLastName()+"', ...)"
Note that string values in SQL is delimited by '', then it is sufficient for the last name to be something like O'Neal
and you can't get the great Shaq as your customer.
In general you DON'T WANT to put your values in the SQL string, you want to mark parameters position whith as in INSERT INTO A (X,Y,...)
Use PreparedStatement ps= connection.prepareStatement(stringwihtquestionmarks)
And then use ps.setXXX(position,value) to bind values.
This approach is natural and it saves from escape problems, value conversion problems (for dates, float and double types and other), and is performing better.
Ok, so you say "PetStore is something that can't just be quickly used and digested ".
This is not a virtue , it is fatal flaw.
We're talking about a handfull of tables/entities here, we're not talking about how to design a new language and implement the compiler !!
Let's get serious, over-architecting is one of the major cause why projects go wild.
But I go on and say in the actual state PetStore just won't work in a real life situation, and it looks like it has never been properly tested or code reviewed.
And even if you're ok with the "if the devlopment team had all the time they needed", I will say that any development team should use the time for quality code on the current features not whatever may come up in unforseeble future.
Even so I could demonstrate that there are tons of unnecessary repeatitive code in there (against best OO practice), but it would be a shame really, because there are guys who are paid to do that thing right and you could contact them on their mailing-list.
And if you cannot implement these " 'best' design and practices" (you say you'd only love to) in the real life that clearly means anti-pattern.
Patterns are for solving real-life work, real-life problems.
Thank you very much for your comments. As manager of the J2EE Blueprints, I would like to assure you that the entire Blueprints team works very diligently on examining and reexamining the design decisions made in the Java Pet Store.
Just the same, I am always glad to hear ways for making J2EE Blueprints even better. :-)
I take your major point to be that there needs to be an easier to way to get up to speed with J2EE. I would be very interested in your opinion about the mailer mini-application that comes with Java Pet Store 1.1.2. Does this address your concern? Check out mailerapp.ear.
You mentioned that the J2EE Blueprints team is inaccessible. This is actually not the case. This forum is a great way to send feedback to the J2EE Blueprints team. There is also a mailing list dedicated to J2EE Blueprints and Java Pet Store. You can find it by visiting the J2EE Blueprints site at http://java.sun.com/j2ee/blueprints
. It is an excellent way to ask questions and provide feedback directly to the J2EE Blueprints team. You can check the archives to see the answers to the questions that we get at:
I look forward to future discussions on these topics.
Manager, J2EE Blueprints
I'm sorry if I mentioned that the blueprints team was inaccessible. If I did that was an error on my part.
I do have some concerns about accessibility at Sun because one of my past experience, but of course I never tried to comntact blueprints, and this is only because unfortunately I don't have enough time to commit to a conversation/collaboration with the Blueprints team.
Anyway since you proved the blueprints team is accessible and oversees the feedback of the community I'll take the opportunity to make some comments:
1. Blueprints in general and PetStore application in special should be open-source. This thing must be obvious from outside, I don't know exactly how is it viewed from inside.
Yes, it is tougher to make design decision in open-source, much tougher to make architectural guidelines, but you have absolutely no point in stayoing closed-source.
If it was open-source I can assure you you wouldn't have had obvious bugs.
I recommend you to recommend to key decision maker to donate the BluePrints to apache.org which is a neutral organization.
Tomcat progress is really a marvel as direct result of this approach.
And guys who want to learn from blueprints would have much faster access to work in progress, apache mailing lists are much livelier than Sun's mailing list because people trust apache more than Sun, and there's a greater sense of community.
Not to mention that evrybody will see how design decision are taken.
2. Specifically about mailing app, I can hardly see why I need to send email through an Session Beans when I can have a couple of high quality smtp classes from open-source that solve the problems.
3. Sun's mailing lists are nice,but there's a fundamental problem with them.
Let's take me as example, I am subscribed to five mailing lists (3 at apache.org) and I wouldn't subscribe to more unless my life depens on it.
It would be much more efficient if your interactions with users would be through a site such as this one.
You can easily see by browsing Sun's mailing lists (blueprints, patterns, and almost all Sun's mailing lists) that they lag behind other forums by a huge margins (let's compare with theserverside.com, slashdot.org and so on). Traffic is less and the level of discussions is not very high. If you really want a community with Java developers to whom your work is addressed you have to embrace the open-source mode.
4. Technically the application lacks a generator for loading tons of random data in the database. you can see that even installation from sites like BEA, Sun, Inprise only illustrate that PetStore only works in the particular app server. In reality there are only some tens of rows in the database.
5. It would be usefull indeed if Java PetStore would follow and be compatible with TPC-W specifications. It can extend the spec where it needs to be more complex but it should be totally compatible and a TPC-W run should be able to be produced with the PetStore.
The two are very similar, and combined with a facility to generate load data, it can be very helpful to users and it can also be very helpful to you in the sense that you could measure exactly the quality of your work by mathematical facts (peformance figures).
So maybe it is not much but this is my input.
I'm very curious how do you see this.
>1. Blueprints in general and PetStore application in >special should be open-source. This thing must be obvious >from outside, I don't know exactly how is it viewed from >inside.
I think that this is a very interesting idea. The Blueprints team has discussed this before. We are currently meeting with some of the TomCat people to find out about their experience and determine if this is right for Java Pet Store.
>2. Specifically about mailing app, I can hardly see why I >need to send email through an Session Beans when I can >have a couple of high quality smtp classes from open->source that solve the problems.
The purpose of this sample is to help people understand how to program with EJBs in a much simpler application. As far as whether it is better to use this approach versus open smtp classes, that will depend largely on the context of use. EJBs should not be used lightly. I don't know if you have reviewed the J2EE Blueprints recommendations regarding EJBs at http://java.sun.com/j2ee/blueprints/ejb_tier/index.html
>3. Sun's mailing lists are nice,but there's a fundamental >problem with them.
> Let's take me as example, I am subscribed to five >mailing lists (3 at apache.org) and I wouldn't subscribe >to more unless my life depens on it.
I understand what you mean. So many mailing lists, so little time. :-) I agree with you that it is good to have interactions in forums such as TheServerSide.com. I also believe that the J2EE Blueprints mailing list is very useful for people who are especially interested in finding out more about J2EE Blueprints and Java Pet Store.
>4. Technically the application lacks a generator for >loading tons of random data in the database. you can see >that even installation from sites like BEA, Sun, Inprise >only illustrate that PetStore only works in the particular >app server. In reality there are only some tens of rows in >the database.
I agree with you that are many interesting ways to improve Java Pet Store and make it commercial grade. At present, our focus is on helping people understand the latest features of J2EE. It is more of a learning tool than an industrial strength implementation.
>5. It would be usefull indeed if Java PetStore would >follow and be compatible with TPC-W specifications. It can >extend the spec where it needs to be more complex but it >should be totally compatible and a TPC-W run should be >able to be produced with the PetStore.
Thanks for this suggestion. I will bring this up with the team.
I'd like to raise an open question to this community. Should I use "BluePrints patterns" defined on "Pet Store" as starting point to build my new site.
It will be an online brokerage service with over 20,000 session per day (over 600 simultaneous visitants)
Do you recommend me another ways?
Thanks in advance.
I'm sure that everyone is going to have their own opinions about the PetStore. For myself, I would like to applaud Sun for making the PetStore available to developers and architects and I think it's a great asset to the Java community. I really like the way you designed your app and your use of technology and trying to address some of the problems we have in production envirnment.
If anyone would like to discuss about the Petstore design or implementation, I'd really like to talk to you. First and formost, I'd like to talk to people who have a open mind.
Some thoughts to ponder:
Given that JSP is almost the same as ASP, why would someone implement MVC which requires more code and maintence. I do see the benfit in the Front Component pattern which is really hard to implement in ASP. I guess my question is that there are some parts in JSP/Servlet which I believe you should use a procedural coding approach (ASP) and some parts you should do OO. What are other ppl thoughts?