Using J2EE Design Patterns Sample Application Available

Discussions

News: Using J2EE Design Patterns Sample Application Available

Bookmark and Share Get thread feed

  1. Using J2EE Design Patterns Sample Application Available (41 messages)

    The Oracle Technlology Network is hosting a complete sample application (Virtual Shopping Mall) and an article that illustrates implementations of J2EE Design Patterns in action, including Model-View-Controller, Command Facade, Session and Message Facade, Value Object and Service Locator.

    Those trying to learn J2EE and patterns might find it useful to browse the codebase and figure out how things are done.

    Check out Using J2EE Design Patterns.
    Reply to this

    Threaded Messages (41)

  2. Using J2EE Design Patterns Sample Application Available[ Go to top ]


    Nice read!
    Reply to this Reply to original

  3. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    But will it run 10x faster than the .NET petstore?

    Sorry, someone had to say it. :D

    Keep smiling,
    Greg Peres
    Reply to this Reply to original

  4. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    <quote>
    But will it run 10x faster than the .NET petstore?
    </quote>

    Try running .Nut on Linux and you will see ... ;)
    Reply to this Reply to original

  5. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Try to run Linux - You'll see :-))
    Reply to this Reply to original

  6. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    <quote>
    Try to run Linux - You'll see :-))
    </quote>

    Do that every day, runs great! Maybe you should try Linux too ...
    Reply to this Reply to original

  7. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    YES, It is very good to have Bird view of Design pattrens. it helps me a lot. Thankx for all who made it happen.

    as for Performance with respect to .Net I feel it is true may not be 10 times but better then..since there are lot of issues with .NET.

    Viswa
    Reply to this Reply to original

  8. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    <quote>
    Try running .Nut on Linux and you will see ... ;)
    </quote>

    Might be a bad thread to ask this question but it something that has been confusing me for a while.

    I find a lot of my zealous Linux friends hate Java. In fact many of them seem to be zealous supporters of C#. Boasting the standardization as the main reason.

    It just seems weird to me that many of the readers here at TSS are Linux fanatics. I think it is great that you are… But, I was wondering if one of the Linux gurus could give me some insight as to why Java seems to have such a poor acceptance in the open source community?

    What is their beef with Java?

    Thanks,
    Greg
    Reply to this Reply to original

  9. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    <Greg Peres>
    give me some insight as to why Java seems to have such a poor acceptance in the open source community
    </Greg Peres>

    I really do not see how you arrived at this conclusion, unless you are not familiar at all with Java open source projects. On the contrary, IMHO, Java achieved great acceptance in the open source community!

    I would suggest you take a look at Apache Jakarta project, Jboss, ObJectRelationalBridge ... and there are many, many others.
    Reply to this Reply to original

  10. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    <quote>
    I really do not see how you arrived at this conclusion, unless you are not familiar at all with Java open source projects. On the contrary, IMHO, Java achieved great acceptance in the open source community!
    </quote>

    Yes, all excellent examples of open source projects all supported by people well versed in Java. But there is an even larger open source community at large that dislike Java.

    In comparison to the other efforts Java seems to play a small role in the community and is not the target language for many solutions.

    Read some of the comments on Slashdot any time a Java related topic is posted. Not that I agree with any of them and Slashdot may not be the best place to look but... The reaction many in that community have about Java is very negative.

    I typically find that the Java open source community is a much smaller subset of the larger community.

    Have fun,
    Greg Peres
    Reply to this Reply to original

  11. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    <Greg Peres>
    I typically find that the Java open source community is a much smaller subset of the larger community.
    </Greg Peres>

    I personally have not conducted any studies regarding the size of Java open source community. With open source projects you cannot really tell people how they should spend their time. If someone wants to work with language other than Java, that's fine by me even though I believe that Java is a great platform that gives you a lot of flexibility and a lot of tools to build efficient, scalable, portable, low-cost solutions.
    Reply to this Reply to original

  12. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Gregory wrote: "Read some of the comments on Slashdot any time a Java related topic is posted. Not that I agree with any of them and Slashdot may not be the best place to look but... The reaction many in that community have about Java is very negative."

    That's because Java itself isn't open source. Regardless of Sun's attempts to market and portray Java as an open platform, the fact remains that Sun owns it, lock, stock and barrel. Until they release the shackles and hand the language to a standards body (which ain't happening), the open source community will always view Java with the same contempt that they do Microsoft. IMHO.

    Also, I wouldn't use Slashdot postings as a serious barometer of much of anything, except maybe the size of the flaming zealot community.
    Reply to this Reply to original

  13. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Ahh... I'm well qualified to answer the Java vs Linux community question. >5 years ago I wrote my first java app on a 486 DX2 66. At the time Java was 10x slower than C. If you know much about the Linus drama and the kernel, you'll know that Linus rejects good ideas soley for trivial performance issues. Linux is unbearably hard to understand with some code that is just broken with comments that say, "This makes gcc compile to faster code." The average Linux person doesn't realize, as did I 5 years ago, that performance is not only secondary to stability, but to portability and maintenance. Most Linux people, like I, get into things quickly after they come out, learn all about them, then form lasting opinions. At the time, it was SUN's product that was extremely slow and incredibly useless for all but annoying applets that took 2 minutes to load in a browser.

    Java is now much more free, which has been demonstrated by SUN to apache, and is much faster, only about twice as slow in most places. The improvement of Java was so great that I took another look at it back in December, and have since written my first commercially used program using the JavaMail API. It was beautifully written and much more stable than it's Perl counterpart. Most arguements that I've had with my friends have been about Java's speed. Since I wrote my java mail app that only crashed once (from a network stall in the JavaMail API... why doesn't it ever time out?) that I worked around with threads and a controller (that will be reused for other Java daemons), most have realized that Java really is usefull. I showed them arcenea (sp?), an OpenGL game written in Java using the GL4Java library, running at >60 fps on my computer(about what I get from any game), they've come to realize it isn't slow. Since SUN solved it's problems with Apache, they now don't think "SUN will someday make me pay royalties for using java!" Basically, those are the three problem I had with java, and the three reasons that I've changed. Hope it helps you better understand where they are coming from.
    Reply to this Reply to original

  14. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Sam wrote: "Since SUN solved it's problems with Apache..."

    I'll believe that when I actually SEE some tangible results, such as JBoss being J2EE certified, rather than just believe some marketing fluff announcement to make Sun look good at JavaOne.
    Reply to this Reply to original

  15. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    FREE SOFTWARE guys don't like java because its not free (Sun controls its specification, unlike Perl, for example, which is free). They are afraid of the branching of the specification in different versions (and lose their power over it, of course).

    PERFORMANCE freaks ('real programmers'? :P ) still think that everybody should stay using only C/Assembler, for performance reasons. True, java doesn't have assembler's blazing speed (and will never have), but this kind of performance is not the main requirement of all projects. Speed of development and portability may be more important sometimes. Include memory footprint problems in this, too. But the same guys use Perl, the ugliest and slower programming language I've ever seen (but cool, I admit). Who may understand this?

    OLD PROBLEMS present in early java implementations and specifications, like performance, portability and AWT :). Many of those who tested java in its first version were disapointed, and have never returned.

    LEGENDS of java only running in browsers' (yeah, some people still think that).

    Maybe someone can think of any other? In any reasonable one?

    tetsuo
    Reply to this Reply to original

  16. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    <quote>
    java doesn't have assembler's blazing speed (and will never have)
    </quote>

    ... but it may come close ;-)

    Have you taken a look at GCJ ? It can compile Java source code directly to native machine code. Another open source project, BTW.

    my $.02
    Reply to this Reply to original

  17. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    with $25000 cash, the oracle application can run 10* faster than pet store but only in california
    Reply to this Reply to original

  18. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Hello everyone.Can somebody wants to give me a sample application on J2EE that is simple and easy to understand.Thank you...
    Reply to this Reply to original

  19. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    very bad because oracle
    oc4j config are very difficulty!!!
    Reply to this Reply to original

  20. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    The application looks terrific!!! Unique One of kind wich uses J2EE design patterns to its core.

    Thanks for Robert Hall and team for the great effort
    Reply to this Reply to original

  21. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    It is perfect app, Congrats!
    I have tried with a number of similar apps.This is really great, compared to Sun's "Petstore Demo" etc. High quality design, coding and documentation. The developers of VSM have done a great work.

    Subhash SS
    Reply to this Reply to original

  22. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    cool J2EE application. Thanks for the URL
    Reply to this Reply to original

  23. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Hmmm ....
    just curious to know whether they haven't heard about EJB 2.0 yet or just ignore it.

    Cheers,
    Torsten
    Reply to this Reply to original

  24. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Very useful article, but you should know how to model Use Cases in UML in a correct way...
    Reply to this Reply to original

  25. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Interesting observation.
    They didn't include the "include" or "extends" ornaments. What else doesn't look OK to you?
    DODO
    Reply to this Reply to original

  26. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    I dont understand why the title is J2EE design pattern
    did these patterns belongs to j2ee?
    Is the MVC an oracle invention, what about the facade , the bridge and singleton .
    Reply to this Reply to original

  27. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Com'on now. Play nice. Oracle obviously put some work into this to help the community.

    It is pretty obvious they are referring to "J2EE Design Patterns" that Sun tells us all about.

    And I think most people agree that this isn't Sun trying to lay claim to design patterns, but is actually showing us implementation of existing design patterns to help us out in the J2EE world, and few other patterns that my help work aournd some problems specific to J2EE.

    I thank Oracle for their efforts and for giving the community something to look at and talk about and point to besides the Pet Store. The more examples that are out there, the more people have to learn from.

    Chris K.
    ~ and I've never even given a penny to, or gotten one from, Oracle.
    Reply to this Reply to original

  28. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Has anybody had a close look at the code? It seems to me that they are using some non-portable code in the EJB implementations
    Reply to this Reply to original

  29. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    I looked at the code for Entity beans (package oracle.otnsamples.vsm.business), and it appears that they are following the first draft of the EJB 2.0 spec :(.

    Specifically, I noticed the following problems with the Oracle sample:

    1) The Entity beans are accessed through REMOTE interfaces, which is not the recommended design pattern for EJB 2.0, as you all know.
    2) Not every domain object is an Entity bean. For example, there is an "Orders" entity bean, but the "OrderItems" domain object is a plain Java object, implemented as a dependent value for the "Orders" entity. Had they followed the final EJB 2.0 spec, it would also be an entity bean, accessed only through its local interface.

    Comments in the code indicate that it was written in january, so I guess that explains why it's so outdated.

    In conclusion, I would not recommend this sample application as a good showcase of the J2EE 1.3 APIs, nor as an appropriate example of design patterns for J2EE 1.3 web apps.
    Reply to this Reply to original

  30. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    The application may not comply with the latest spec, but it still is a great resource for J2EE developers.
    Reply to this Reply to original

  31. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    How do you qualify "great resource for J2EE developers"? While the application does demonstrate some J2EE design patterns, IMHO the application is poorly designed. Somebody new to J2EE would look a this app and be confused with the inconsistent use of session and entity beans, inconsistent naming conventions, poor application structure and packaging and inconsistent use of primary key classes (to name a few).

    It would have been nice to see some requirements/design documentation that explained their design decisions. The documentation provided is certainly not a great resource in the use of UML.
    Reply to this Reply to original

  32. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Common Tim. Don't be blindly against Oracle. They have really contributed some thing valid to the developer community. We shouldn't blindly criticize the application structuring and packaging without looking into the details of it. May be you are right that there can be some design flaws(That we can find out with apps). I have gone through the application thoroughly and it has the following advantages and disadvantages.

    1.The functionality s very clear from the usecase diagram
    2.The article is very clear and easy to understand for any novice user
    3.The design patterns they are using in the application is very clear
    4.The EIS and MVC part is very much extensible
    5.The code is very clear and well commented than Petstore. If you go through the code, you can easily make out the functionality. This is not an easy job.
    6.This is a complete application can be reused in many scenarios.
    7.The UI is very cool

    The main disadvantages are
    1.The business part of the application should be some more clear
    2.The can come up with a class diagram in the article to make it more clear
    3.It should be compliant to EJB 2.0 and J2EE 1.3 (When Petstore released it was not :))

    I really appreciate the people to come up with another J2EE application and it is really an asset for J2EE developer community.
    Mark
    Reply to this Reply to original

  33. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    C'mon Mark, my post was neither critical of Oracle or blindly critical. I agree that this app has some validity in demonstrating some J2EE design pattern implementation. However, let us not take it out of context and position this as a poster child for good J2EE design practices.

    In your "thorough" analysis, how would you position the DB design?
    Reply to this Reply to original

  34. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Tim, If you find out any design/code level issues, please share it with the rest of the people. We can have an open discussion on it and it may give value additions to the application.

    Mark
    Reply to this Reply to original

  35. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Alrighty then!

    For the domain objects implemented as EJB's they have embedded the VO's as CMP fields. Suggest a decoupling of the VO and EJB and utilize a Value Object Factory pattern to generate the VO's.

    For the non-EJB domain objects, use the DAO pattern. And if you are going to use a J2EE server then use DB pooling. The DB access via the eis package is not doing this.

    For read mostly data (e.g. Country) implement a caching mechanism such as the Value List Handler Pattern. The "CountryManager" does a DB lookup every time it is called.

    Implement the managers as session beans, and suggest a coarser use-case organization that map 1-1 with a session bean. For example, a CartManager, CatalogManager (Shop, Item, Category, etc), UserManager, OrderManager, and ReportManager seems reasonable.

    Move the JavaScript business rule processing from the client to the business tier.

    That should be enough to get the discussion rolling.

    Tim...

    Reply to this Reply to original

  36. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    We did not see any advantage of decoupling VOs from EJBs,since the persistence is handled by the container and there is no code overhead.

    If you are referring to connection pooling, the DBConnector class does that, the underlying datasource is a pooled datasource.
    Caching mostly-read-only data is a nice idea.
    We think only the managers which need transaction features can be made as session beans. For example, OrderManager is a perfect candidate for a session bean as you have stated. But Report Manager does mostly database reads and issues like dirty reads etc are not really a big problem for
    reports from a business point of view. So a plain java class would suffice, in our opinion. Javascript code does validations only, and not any business logic is coded.Indeed, these validations should be
    present in the business tier also.

    Thank you all for the comments , and for starting a discussion on the code.We will be working on it and hope to come up with a new version with your inputs, compliant with the latest J2EE spec.

    The VSM dev team,
    Reply to this Reply to original

  37. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    The decoupling advantage should become apparent when you migrate the app to EJB 2.0.

    Why maintain two connection pools? My approach is to use the Factory pattern that does a simple JNDI lookup to retrieve a connection from the container.

    Yes, the big advantage of using session beans is the transaction demarcation capabilities you inherently get. Another advantage is security. If all the apps "Managers" are realized via session beans, you have a centralized security mechanism.

    Why maintain your validation code in two places?

    I look forward to the next version.

    Tim...
    Reply to this Reply to original

  38. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Hi,
    The eis package does just that. It looks up the JNDI tree and gets a connection from the datasource.
       The client side validation is present to avoid trips to the app server.The code on server side would be helpful if javascript is disabled in the browsers. But currently, javascript should be enabled for the application to work.( mainly for the sub-menus)

    Thanks for the inputs,
    The VSM Development Team
    Reply to this Reply to original

  39. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Any chance you could use the JSP Standard Tag Library (JSTL, from JSR-52) in a future version? That would really be great.
    Reply to this Reply to original

  40. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Tim, you are right in that the document should have elaborated on the design decisions and explained the naming conventions.
    But that doesn't make the application useless. They have focused on "how the various design patterns could be implemented". And they've done a jolly good job of that.
    I just hope that they come out with a version that complies with the latest spec. That *might* result in a different implementation of the same design patterns.
    But again, this application serves as a good reference implementation and I appreciate the folks at Oracle for their time and effort.
    If you feel that the application is poorly designed, you could maybe point out the areas that need to be improved and provide an annotation which would be equally valuable to the developer community.
    But I still feel that it is a great resource to learn from.
    Reply to this Reply to original

  41. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    I do appreciate Oracle's coders effort for this simple web application . The problem is that all the j2ee1.3 shabang SUN has been trying to promote is not present is WEBSTORE apart form WebService which is not included in Petstore1.3
    .Though Sun's Petstore1.3 is a bit complicated -it is the ultimate reference( as far as I am concerned) to build a j2ee1.3 web application
    Reply to this Reply to original

  42. Using J2EE Design Patterns Sample Application Available[ Go to top ]

    Yes i agree this doesnt showcase the J2EE1.3 specifications. Had there been EJB2.0 implementaions it would have been a better application demonstrating J2EE1.3 features. Hope they have the plans for the next version :).
     I have gone throuhg the MVC architecture. Absolutely fantastic design. Its a definitly resusable and extensive model. Session abstraction makes even the controllers re-usable. Also it has few good technologies demonstrated ..

    1) Application listeners
    2) Filters
    3) Good design patterns
    4) Good document

     Guess Its a very good resource even for the medium - advanced developers too.


    Rohan
    Reply to this Reply to original