Java BluePrints Adventure Builder 1.0 Early Access Release


News: Java BluePrints Adventure Builder 1.0 Early Access Release

  1. The Sun Java Blueprints team have a released a new example application called the Adventure Builder. The Adventure Builder illustrates the typical design decisions and tradeoffs a developer makes when building a J2EE 1.4 app. Unlike the Petstore, this time they decided that the application requirements do not justify the use of EJB. The also use web services and modern design patterns.

    Check out the adventure builder (early access) here:

    Threaded Messages (54)

  2. What is the difference between this Adventure and the existing Pet Store? Do they still keep Pet Store or they have just renamed Pet Store to Adventure Builder with new stuff?
  3. Geez, why don't you take the time and effort like I did,
    download the EA and find out?
  4. hey, man, if u do not know the answers, shut up!!! do not post your stupid stuff
  5. This is what Inderjeet said:

    > Inderjeet ,
    > Thanks. Will there be a PetStore sample application demo the usage of
    > J2ee1.4?

    No. Petstore remains the demo application for J2EE 1.2 and 1.3.

    > If not, why there is there new Java Adventure Builder sample application
    > instead of continuing using the Pet Store sample application. I think
    > PetStore sample application was the demo application for both j2ee 1.2
    > and j2ee 1.3.

    We thought that Adventure Builder covers the Web service scenarios a
    better. So, we will be able to show good practices better through it.

    thanks for your interest

    > Please correct me if I am wrong.
    > Thank you
    > -----Original Message-----
    > From: Inderjeet Singh [mailto:inderjeet dot singh at sun dot com]
    > Sent: Monday, December 09, 2002 8:59 PM
    > Subject: ANN: A new sample application from Java BluePrints: Java
    > Adventure Builder Demo
    > Hi Everyone,
    > Available for download from the Java BluePrints Program, the Java
    > Adventure Builder Sample Application v1.0 is the first release of the
    > new Java BluePrints application. This early access release is a native
    > J2EE 1.4 application that runs on the J2EE 1.4 Beta SDK. It showcases
    > Servlet 2.4, JSP 2.0, JSTL, and web services. This release is designed
    > to be easy to understand and includes a new mini J2EE application.
    > Download it from
    > Read the documentation at
    > thanks
    > inder
    > ---
    > ===========================================================================
    > To unsubscribe, send email to listserv at java dot sun dot com and include in the body
    > of the message "signoff J2EEBLUEPRINTS-INTEREST". For general help, send
    > email to
    > listserv at java dot sun dot com and include in the body of the message "help".

  6. Congrats to Sun. In the few minutes I've spent so far reading through the design docs, it looks pretty solid. Hopefully the code will stand up to the test as well.
  7. Does anyone else see this blueprint as an attempt to regain some credibility?

    The omission of EJBs is an interesting decision (part of a trend?)

    On another note, I'm don't understand the need for the complexity of the build / source structure.. (all the nested build files etc).. can anyone enlighten me as to which benefits this complexity overhead brings?
  8. Regarding the nested build scripts... If you have the possibility to divide a 2000-line Ant script into, say, 5x500 lines, it may still be worth it because it becomes easier to "follow" the tasks related to a specific target/part/component.
  9. Actually there is one ejb in the application, it is the Web Service end point for the app. The decision to use an ejb for this seems odd since everything else in the application would only require a Web Container to run. With the addition of this single EJB, a full blown J2EE Server would be required. Of course, this application is supposed to demonstrate the J2EE 1.4 platform so I am not trying to be overly critical.

    The other thing I thought was odd is that the PoEndpointEJB does not follow the Naming Conventions for Enterprise Applications Sun recently published. Though I have to admit that I much prefer the EJB suffix used here over the Bean suffix in the conventions doc.
  10. All SQL queries in JSP ?!

    No update logic implemented jet ?
  11. From my understanding, the EJB used is just to implement the simple order processing backend, this is not anything related to the adventure web application - hence the use of the XML RPC - but required for the application to run therefore the application can run inside a single Web Container.
  12. How is it that Sun lost credibility? The only people that lost credibility were those that used the spec incorrectly. These blueprints spell it out more clearly for those who don't understand when it is appropriate to a certain J2EE technology.

    If everyone made an effort to understand J2EE, materials like this would not be necessary. That being said, this is a very nice example... GOOD JOB SUN! keep up the good work!
  13. <Does anyone else see this blueprint as an attempt to regain some credibility? >

    Sun never lost credibility, only those that bought into the .not and m$ sponsored studies think that it was Sun's credibility to reestablish. The sponsors of the outright incomplete and wrong work and this site have all the credibility to regain. Shame on TheServerSide for being so careless!! Shame on the liars and instigators that do not know the first thing about software development and systems reliability.
  14. It's funny watching the amount of emotions clouding the picture here.

    Personally I've been using ejb since 1.0, and so certainly am not an soul-less m$ user :) However I'm continously experienced non ejb j2ee applications being delivered with less hassles and better long term performance.

    My perspective (was)as follows:

    use EJB if:
    1. complex transactional requirements
    2. remote access requirements
    3. high concurrent work-load, reduce object creation

    I now question these points however;
    1. complex transactional requirements - experience with several declarative ejb transaction projects leads to believe that ejb declarative transactions _increases_ the complexity of a solution, rather then decreasing it.

    (I was very happy to see the BPAB advocating JTA instead)

    2. remote access requirements
    At first using rmi/iiop with ejb declarative security seams like a great way to go.. however in truth it's not a great model (how do you tell if a client is connected for example?). Given a sufficiently low volume requirement, I would consider some other solution for remote distribution.

    3. high concurrent work-load, reduce object creation
    I've seen non ejb j2ee solutions out-perform (concurrent/throughput/latency) ejb solutions over and over again.

    ... guess I'll just sit back and wait for all those emotive responses ...
  15. A few comments:

    - EJB is *not* the answer to all problems. My new book discusses how to choose when to use EJB: see the sample chapter.
    - Many web applications are better off without EJB. EJB solves some problems well, but introduces complexity and can reduce performance.
    - It's good that Sun may have finally realized that trying to push EJB for all purposes is hurting J2EE. J2EE is much more than EJB.
    - I think code generation has a place, but I prefer to reduce the complexity of the application than rely on code generation to manage that complexity.
    - CMP entity beans are definitely *not* usable in many situations. I've seen many projects face intractable performance problems using entity beans. I used to be enthusiastic about them too when EJB 2.0 came out, but I've seen a lot of projects using them since and I've changed my views.

    I haven't yet had a chance to take a close look at the new sample application, but I hope it's an improvement on the Pet Store. And I hope they did some benchmarks.

  16. "I would much rather deal with CMP EJBs that write crappy SQL myself!"

    Someone on the team, such as the team lead, must know SQL well in order to have a scalable application.

  17. Rod:

    I have read your book once and am reading certian chapters for the 2nd time. However, I am still not convinced that EJB 2.0 CMP entity beans are that "not usable". We use WebLogic's ReadOnly entity beans with CMR for reference data caching (much like displaying catalogs, which are ubiquitous in e-commerce), and so far they have worked well for us. Can you give specific examples under what circumstances CMP is not usable? Also, can you demonstarte an alternative, e.g., JDO can solves the entity bean problem(s)? There is the saying "once bitten twice shy" - many people who used EJB 1.0 or 1.1 BMP entity beans and were hurt by the poor performance are sitting on the fence, so we need scientific evidence from J2EE industry experts to help them make up their minds one way or the other.

  18. Eric,

    I didn't say that CMP entity beans are "not usable" at all, but that they are not usable to meet the needs of many applications. If you've developed a successful solution using them I wouldn't try to convince you to change technologies.

    Some of the problems EJB 2.0 hasn't fixed. Whether or not these mean they aren't "usable" will depend on each application's requirements:
    - no support for aggregate functions in standard EJB QL 2.0
    - other standard EJB QL limitations (no ORDER BY etc)
    - no support for polymorphism (a finder can't return different classes). JDO doesn't have this problem.
    - persistence tied to an EJB container with an adequate CMP implementation. JDO works anywhere.
    - Impossible to persist objects without them implementing EJB interfaces. JDO allows persistence of plain Java objects.
    - Because of the container dependence, testing is made much harder
    - Absurdly complex DD syntax, spread across multiple files (standard and proprietary). Sure, we can use IDEs or XDoclet or EJBGen, but it doesn't justify the complexity.
    - No support for set-based RDBMS operations (although in fairness any O/R mapping solution will have problems with this)
    - Cumbersome syntax for looking up homes in JNDI etc. JDO makes this a lot nicer. Session bean code using entity beans tends to end up being drowned in JNDI and exception handling. (Sure, they can be separated out, but too many developers fail to realise the importance of this.)

    Chapter 8 of my book and the EJB alternatives chapter from the forthcoming Bitter EJB book go through the arguments in more detail.

    There have been several benchmarks comparing entity bean performance vs alternatives (usually session beans with JDBC). I don't have the URLs to hand, but UrbanCode did one (around 6 months ago I think) and Rice University did one (posted here a couple of months ago). All the benchmarks I've seen show entity beans to perform very badly.

  19. I think we agree CMP entity beans as an O/R mapping framework lacks many of the flexibilities of JDO. However, I see entity beans are still evolving rapidly, as EJB 2.1 spec starts to address some of the EJB QL issues and hopefully future version will add support for inheritance etc. Also, the fact that WebLogic and JBoss already have some of these features in their CMP implementations indicates to me there is nothing fundamemtally flawed in the spec. Maybe EJB and JDO will merge into one in the not too distant future. Who knows? I am just not very comfortable with JDO as yet because the lack of support from industry heavy-weights as well as the entire opensource community.

    As for SLSB+JDBC vs. entity beans, yes the former will probably always offer better performance if data has to be read from the database upon each and every EJB invocation. However, for data caching purposes (none transactional use of entity beans, which I know deviates from the original intention of the EJB architects) entity beans offer a big advantage. Granted the ReadOnly persistence strategy is a vendor-added feature, but this is similar to any RDBMS vendor proprietary functionality - you use them based on their merits, rather than shying away because they are not part of the spec.

    Just some thoughts.
  20. Please go through this link and probably you
    will find the answer for your surprises:

    Snippet from Adventure Application Architecture details

    There are three main reasons that this application uses only a Web tier:

    The application has simple transactional needs.

    The application did not need to use Java Message Service (JMS)

    The application's security model is very simple, using only self registration.

    Essentially, this application is a good example of Web-centric design. Because the application makes such light use of transactions, database access, and security, these operations can be performed programmatically. With this type of simple application, it may be easier to program these operations directly in the application code and not to use enterprise beans, thus foregoing the EJB container's security, concurrency, and transaction features. Since this application is fairly simple, it can not really leverage the features of the EJB container. If the complexity of the application increases in the future, the declarative security and declarative transactional facilities would be more useful
  21. Or are the reasons not to use EJB's now just a place holder to say that "the work we did for the last couple of years is not a waste" .

    Basically , Having just a Web Container works for most of the applications.
  22. Most of your applications maybe. EJB (2.X) is a great technology and not a waste! I would much rather deal with CMP EJBs that write crappy SQL myself!
  23. I agree with you, Rob. I do not understand why people are so interested in writing their own DAO layer, using SQL code that needs to be debugged and tweaked for every database. Wouldn't it make sense to save time and money by using CMP2.0? Especially now that most IDEs make it so easy...
  24. <Chris>
    "...using SQL code that needs to be debugged and tweaked for every database."

    Whenever I write SQL code I write it for the database that my company is using, not EVERY database. You CMP proponents assume that companies change database platforms every week. The use of CMP involves learning and maintaining another API. And CMP has limitations. Most projects I'm on have poor database models that make the use of CMP unrealistic.
  25. Entity beans have their place place but too many people treat it like a golden hammer. Sorry, CMP or any other container driven persistence will never reach the performance of raw SQL. Use what works where it needs to; Don't just use it because it's there.

    <CMP pseudo code>
    lookup -> find -> iterate -> set -> store
    </CMP pseudo code>

    will never reach the performance of

    <Sql pseudo code>
     connect -> prepare(chached) -> execute("update table set column = value")
    </Sql pseudo code>

    Only experience, and not a book or example application, or certification will dictate the best use of a tehchology.

    Knowing what, how, and when always seperates the also ran from the can do developer/architect

  26. CMP Entity beans work in just about every situation. I'm sure part it is personal preference, CMP is tops as far as I am concerned. I would much rather deal with Java objects than write SQL. In most cases the pros out weigh the cons. After spending a bit of time with EJB I have notice that my productivity has gone way up as well!

    I find EJB relationships to be particularly elegant.

    I'm not ashamed to admit it! I LOVE EJBs!!!!!!

    I am officially "out of the closet"
  27. Using EJB's for inserts and updates seems ok to me. But for reads and finding an ejb reference(primary key)- CMP isn't good. I stay away from both too fine grained and too coarse grained levels of data for EJBs- its got to be somewhere in the middle- or I just use JDBC. Using raw JDBC to do finds and queries(with DTOs) and CMP for updates and inserts. Like you guys have been saying- use it where its appropriate.
  28. I was hoping that these blueprints would use JDO. would'nt that be the alternate architecture for not using EJB's.

    I mean
    Web Tier --over XML(JAXB)--> Domain Model --JDO with JAXB--> DB.

    Comments please....
  29. I agree with you, Rob. I do not understand why people are so interested in writing their own DAO layer, using SQL code that needs to be debugged and tweaked for every database. Wouldn't it make sense to save time and money by using CMP2.0? Especially now that most IDEs make it so easy...

    "Tuning SQL" - does it sound familiar to you? If it doesn't then, I envy you. You don't have to write high performance applications :)
  30. Rob, then you'll never get ultra-fast system. Though it's a topic for another discussion...
  31. Interesting they didn't use loads of EJBs like in the Petstore. I wonder if sun will release another app that ACTUALLY justifies the use of EJB? ;-)

    Any thoughts people?

    Cheers Smythe
  32. Reading the architecture document it seems clear to me that they have divided the application to a web front end and an ejb backend ("a stub in the early access release"). These are connected via a web service interface.

    I think this is an nice and sound approach and shows and exemplary loose coupling between tiers. This way the backend will be easy to use from other kind of applications moderately easily.

  33. Decoupling leads to code reuse....But then you get collosal business teir objects supporting multiple requirements and data collations. So the business tier explodes, requires complex maintenance, signoff and release in case you damage one of the x number of dependant web/client tiers.

    Or, decoupling leads to solid design decisions, but should in no way encourage reuse in multiple projects, because monolithic business objects are a maintenance nightmare.

    Don't go the way of windows, keep your applications seperate, and avoid interdependancies, that way you can deinstall, reinstall and upgrade without getting seriously burnt.

    As for web services, these are just asynch rpc, and asynch rpc is OK for some things, but synch is better for more. Even with assured delivery. eg you say to the user their booking worked, and the message q holds the message for 5 mins cos the network is screwed, meanwhile the plane fills up, the request then goes through and gets denied... You now need an entire infrastructure to inform the user that they have NOT got the booking after all. And with asynch collaborating web service chains the complexity goes mad - asynch rollback......

  34. Haven't read the design doc yet so can't say too much here. Howvever, using a web services layer between the Web and EJB tiers sounds like another performance hog.
  35. You'll never be happy. It makes perfect sense when you think about it. Like all parts of J2EE you the developer/architect have to use it properly.

    All of the webservice protocols are bloated and slow to begin with, so they should only be used when absolutly required! This is just as true of .Net or any other SOAP based Web Services tool as it is of J2EE.
  36. Rob Abbe - good points made there. Some people have knee-jerk reactions when web services are mentioned, launching into tired rants about performance. Yes, the performance is lousy. But there are plenty of integration problems that don't require high performance and can best be solved via web services. All you may need to do is send a couple hundred messages a day between two disparate systems (e.g. a .NET system and a J2EE system). Sometimes CORBA may be an option as well, but it may be too difficult or expensive to find skilled people to implement it. Because of industry support, there are a number of products out there that make standing up web services on top of disparate systems a snap, and thus a very effective solution in the right situation.

    I haven't looked at this AB implementation, but I imagine web services may have been included primarily for the sake of including them. I find it curious that Sun produces these reference implementations because they rely only on what is provided by the base J2EE specs. Much of the beauty of using J2EE is the ability to choose from a variety of frameworks (e.g. all the webapp frameworks) that layer on top of J2EE. I think the Sun ref impl's should serve as a nice example of how to use the base J2EE specs, and that's it.

  37. <
    Unless you work for someone like Amazon, I doubt your site processes enough orders to make this a real issue.
  38. That a good idea, but I think that they should have start from the PetStore application. I don't see why create a new app which does the same thing as PetStore do. I think that it would have been more instructive to have an EJB PetStore against a 'lightweight' PetStore and explain all design choices.
    Its very interesting also that Sun made this move, bc they seems to aknowledge that EJB shouldn't be use EVERY where as they used to say couple of years ago. This is probably a consequence of the .NET campaign to show how EJB are inneficient (Thanks to the TMC).
    Now, what is going to happen next, do sun is going to push for JDO (since this new app recommend to use only value-objects with DAO), or they are going to wait for Microsoft ObjectSpace in order to reposition their technology again.
  39. Fundamental Flaw...[ Go to top ]

    It seems to me that even this new approach (Adventure Builder) - no EJBs, etc) has a fundamental flaw: The definition of the application is still tightly coupled to its implementation. Furthermore, they wrote a bunch of code by hand. Although there are exceptions, normally an application's definition - what's in it, and what it does - has little or nothing to do with how it's implemented. The Adventure Builder could be implemented using just servlets, for example. It could also be done with EJBs or Struts or JDO.

    The problem is that most software I've seen doesn't make that distinction clear. The result is that you wind up with technology dependencies because your functionality is mixed with the code that makes use of a particular technology. For example, AB has SQL embedded in some of the JSPs. What if you need to switch to another UI technology? You can't just drop a new front end onto your app, because some of your app's logic is embedded in the JSP. The same goes for the backend. Sun did slightly better here, in that they've encapsulated DB access inside DAO objects. Theoretically you could provide different DAO implementations for each object, but that would be a real pain to code up.

    That brings up another point - everything is handcoded. Why not let the computer do it for you? By providing definitions of the objects in your app, you can use generators to generate things like bean classes, JDBC code, and XML serialization code. Each business object in an app generally has at least 2 different representations, and sometimes as many as 40 or 50 in a big application. Keeping all of these in sync is a royal nightmare; if each representation is generated off a common definition, that maintenance problem suddenly disappears.

    Not only does pervasive use of generators cut down on maintenance costs, it allows you to make widespread changes with little work. Want to try a different database? Drop in a different generator, and all of your SQL/EJB/JDO/etc code gets written automatically. Find a more efficient pattern for something in your code? Change the generator to use the new pattern, and all of your objects can take advantage of it. This approach can save - literally - dozens of man-years of development time.

    By defining your app and then generating the technology implementations, you can keep your application's logic in one place while the technology changes around it. Imagine not having to rewrite your app if you want to switch from EJB to JDO. It's possible.

    Now the shameless plug: the Structs and Nodes Development methodology allows you to build applications this way; read more at There's an open-source implementation that runs on JBoss over at
  40. Fundamental Flaw...[ Go to top ]

    Man are you talking about building Enterprise Application or trying to build stuff so that it can be replaces for the fun of it.

    You can only define n number of things that can change in your project. IF everything is going to change and you prepare yourself for it then I would say that a better guess is that your whole business is going to change.

    What are you protecting agaist....
  41. Fundamental Flaw...[ Go to top ]

    I'm talking about real enterprise apps. Everything in SAND about comes from direct experience building enterprise apps. Businesses themselves do change - it's happened to me several times, and it's happened to others, too. Technology changes, too. 5 years ago EJB was brand new (1.0 was released in March '97). 10 years ago, Java didn't exist. When new tech comes along, you shouldn't have to rewrite your app to take advantage of the technology (assuming your requirements are the same).

    One of the things that SAND is best at, however, is insulating engineering from marketing. Requirements change all the damn time, and each requirements change requires work. By using generators, SAND minimizes the amount of work needed to add/remove/modify business objects, and you're guaranteed that the changes will "just work." There's no need to hand-code any of the boilerplate that's so prevalent in software today. It sounds like overkill for small projects, but as we all know even small projects usually start to grow and get out of hand.

    SAND lets you concentrate on *what* your application does, freeing you from concerns about *how* it's implemented.
  42. Fundamental Flaw...[ Go to top ]

    "SAND lets you concentrate on *what* your application does, freeing you from concerns about *how* it's implemented." -- Steve

    While not an executable model for lack of action semantics, the SAND whitepaper well sketches a methodology for significant code generation from platform-independent models. If SAND can do it, then surely there could instead be a comparable UML profile for OMG's MDA. It bugs me that the Java community isn't pursuing a (perhaps de-facto) standard for this. SAND, Ace, etc; everyone wants to invent their own incompatible modeling framework, but no one wants to embrace standard interchange, ala XMI.
  43. OK, after 3 years' of trial and error and debates and religious wars we finally decided to use the Windows DNA approach to build web applications. Hardly an advancement in distributed computing and does make the MSFT guys look like smart visionaries.
  44. ha ha ha ha
  45. Eric,

    Tell me; what you consider is the J2EE greatest contribution to serverside programming,

    1) EJB
    2) Cashing or
    3) O/R mapping?

    Rolf Tollerud
  46. 2) and 3), none of which is offered by Windows DNA (pre dot net MSFT technology). EJB is the most current implementation for achieving caching and O/R mapping, and JDO can be a strong alternative when it picks up full-fledged support from main stream J2EE vendors.
  47. Eric,

    Well, cashing is started to be doubted - questioned, you can not share the database and there is corruption problems. An Oracle or SQL server database on the other hand is very power full and have more than 20 years experience of delivering data fast. EJB is already also out if you believe in the majority, to be used only in Corba scenarios and even then replaced by Web Services.

    So that leaves O/R mapping, useful only for the simplest of applications in my opinion..

    <Q>In PHP or Perl, people tend to prototype web applications quickly and get something crappy up over the weekend and firm it up into something usable in two weeks. People doing Java projects get very concerned about architecture and spend about two months detemining the scope of the project, another two doing a design, then about six months developing a framework. Often at this point the framework turns out to be unworkable and the project is abandoned</Q>

    Is it not sad that the reality will not adapt itself willingly!

    Rolf Tollerud
  48. Rolf - your examples are wildly different. On one hand, you talk about building a PHP/Perl app in a couple weeks, on the other hand you talk about Java developers taking 10 months to design and develop a framework. Do you really think that Java developers insist on doing that for a webapp that could be hacked up in JSP just like it was hacked up in PHP or Perl?

    I built a public website in PHP last summer. Most of my PHP pages were like a lot of PHP pages I've seen - tons of code in them, intermingled with some HTML. Couldn't find a better way to do it in PHP after searching on the web. After 6 months of use, I needed to make a lot of improvements. Because of the hacked-up nature and bad design, it was of course nearly impossible to do. I'm now rebuilding it in Java using Struts for the web tier (and I have the option of considering plenty of other webapp frameworks), plain Java interfaces for the business tier, and Hibernate for the data tier. It took about a week to design it, and it will be far more flexible and maintainable.

    The ASP's I've seen and written in the past (haven't used ASP.NET yet) were similarly hacked up - tons of code with HTML. They were nearly impossible to change and very difficult for anyone to comprehend. I don't think it takes 10 months - or even 1 month - to do the design to avoid this problem.

  49. Rob,

    You may be right; it was deliberately a little provoking.
    But I still think some "middle of the road" approach could be used though.

    Rolf Tollerud
  50. Verify Target[ Go to top ]

    Anyone know what the "verify" ant target is supposed to do? I have not yet found its implementation. If someone has figured it out, please point it out to me.
  51. This it not a Java - .NET issue[ Go to top ]

    You could divide web contractor community in 4 camps.

    1) Those that put together their Java systems preferring to choose among small modules from a smorgasbord from Open Source or commercial vendors.

    "J2EE is not just J2EE-certified application servers. J2EE is a bag of technologies, enriched by lots of open source toolkits. Choose whatever suits your needs and your taste!"

    2) Then we have a pretty large community of PHP/Perl/Phyton etc camp.

    "In PHP or Perl, people tend to prototype web applications quickly and get something crappy up over the weekend and firm it up into something usable in two weeks."

    3) Then we have those which prefer using the big Java app servers with entity EJB beans, Cashing, XML descriptors O/R mapping and the whole enchilada.

    4) And then there is of course the.NET community.

    I think it is important to nail down that this it not really only a Java - .NET issue. The situation is that it is really 3 against 1!

    And, for the record, I really prefer 1). The reason? The cross platform ability is difficult to beat. In reality I am working with one such project right now.

    But what is really pissing me off is the big Java app server’s camp. The big J2EE App servers is in a terrible mess IMO.

    Bill Roth, former Product Line Manager for J2EE at Sun:
    "EJB were written for (and by) the systems software architects at the roughly 80 companies in the world that build enterprise-class transactional software."

    And some of this solutions can be easier done with Web Services, dimishing that number even further. But always when you try to criticize the big J2EE App servers then comes some expert from one of the 80 afore-mentioned companies telling "how good use they have had from their EJBs.."

    But the reality is that there are 10 000 or more vertical business programs in the world whose complexity many times are by a power of degree grater than the J2EE. Applications that could benefit greatly by emigrating to a browser environment. Solutions with 10-20-30-40 or more man years behind them, but without any need of full J2EE functionality. The thing is that business problems can be quite complicated too..

    The practice of using the same hammer to solve all problems strikes me as odd; to say they the least.

    If only they would admit all the problems with EJB and the surrounding techniques – no great matter – we are all imperfect and we all make mistakes. You have only to admit your mistake and come up with something better.

    But far from admitting any mistakes they are pushing the idea that they (the EJB programmers) are more advance programmers and you – you are too stupid to learn

    Irritating isn’t it?

    Rolf Tollerud
  52. This it not a Java - .NET issue[ Go to top ]

    No offense, but your personal vendetta against EJBs and app server developers who use them along with how wrong you think we all are is getting quite tiresome. Since you neither like nor understand EJBs, I would suggest that you don't use them. Simple as that. It sounds like in your line of work, you don't need them. If you don't like the rest of J2EE, don't use those components either. If you don't like the big vendors and their pushy sales people always trying to sell you on EJBs, don't use those products. See how easy it all is? I, for one, have no interest in trying to make you use anything at all.

    EJB programmers don't think they are better programmers than you, Rolf - they might feel more qualified to talk about them than you, but that's different. For instance, I'm no good at developing those rich web apps you're always going on about. I'm not going to say word one about how you should develop those because I'm not experienced enough to do so.
  53. This it not a Java - .NET issue[ Go to top ]

    OK Ray, I promise I will say not a word more about EJB for one year.
    I'm tired of myself too, you know - the future will see.
    Anyhow I know you are one of the 80 (or whatever the correct number is).

    Rolf Tollerud
  54. Blueprint? Nice code...

    if (context.getAttribute(AdventureKeys.CATALOG_FACADE) != null) {
                catalogFacade = (CatalogFacade)context.getAttribute(AdventureKeys.CATALOG_FACADE);

    p.s. i'm eager to see this implemented in .NET and benchmarked against this J2EE impl. (flame?)
  55. I'm noticing that the rest of the Java community is picking up on a trend that's been building for 2 years

    1. Respect for (Entity) Beans are diminishing with practical experience. For a complete summary of why Entity Beans don't cut it read ...

    2. There has been an up swing in interest in and component/domain oriented languages

    This is all part of the process of language maturity.