Implementing Microsoft's .NET PetShop using Sun's J2EE

Discussions

News: Implementing Microsoft's .NET PetShop using Sun's J2EE

  1. Trifork inc. has made a J2EE reimplementation of the .NET PetStore, which mimics the .NET code closely, reuses the database layer, and employs Struts as the view layer framework.

    Trifork does not make any claims on performance, and instead tells you to do your own benchmark, so you can decide for yourself.

    There is a comparison of the lines of code needed for each implementation. One nice thing about the comparison is that it details the "type" of code (Model code, view code, XML config, etc).

    editors note: Comparing lines of code is a tricky thing. People tend to assume that this is a judge of productivity, but this isn't the case. A better judge of productivity would be to give teams of developers a project, and compare the time that it took them to complete the requirements (including performance requirements).

    See the full article at Trifork's Website

    Threaded Messages (16)

  2. Performance Test[ Go to top ]

    Might be nice to performance test this thing in the same way that the .NET v J2EE comparison was made.
  3. TSS performance[ Go to top ]

    as long as TSS recuses themselves from any perfomance test it might be worth a look otherwise no..
  4. .net petstore port to struts[ Go to top ]

    When you look at the number of lines of code- especially at the number of lines in the view part of the app- I become more convinced that the Struts framework, and others like it(webmacro)- are superior from an architecture standpoint. Who doesn't hate code in the view? Microsoft itself put together that .net petstore App- so you're looking at a pretty well coded application from .net standpoint.
  5. TSS has never done a performance test[ Go to top ]

    Again, TSS never did a performance test. TMC did one. This isn't the same thing.

    TSS itself will not be taking part in any performance test.
    All we do is report on J2EE news.
  6. Ahhhhhhhhhhhhhh[ Go to top ]

    Good point Dion.

    But I am always curious why TSS yanks out messages that criticize TMC.
  7. At this point anybody who's creating yet another Java PetShop needs to be very aware of the performance comparisons. While ultimately we all want to have an objective view of Java performance vs .Net performance it is the responsibility of the auother of the Java version to test their implementation for performance and make sure it is comparable to .Net version. Otherwise it will do nothing but disservice to Java community.

    Buttom line, before you post something as a "good thing" look at all the aspects of your application including the performance. And prove it with data.
  8. Alex,

    The J2EE implementation was never meant as a "good thing", but merely as a demonstration that you can make a Java implementation using the same design patterns as those used in the .NET version and get approx. the same results in terms of code lines.

    I completely agree that a serious performance comparison of the .NET and J2EE versions would be great to have, and we would have loved to have the time and lab setup required to undertake such a task. Yet, since the application wasn't tuned for any specific environment and no performance claims were made, I fail to see how this is in any way damaging to the Java community.

    Regards,

    /Kaare
  9. How Long?[ Go to top ]

    Hi Kaare,

    Great work! This is a very interesting way to approach the comparison.

    I have a question regarding this comment:

    >isn't the case. A better judge of productivity would be to
    >give teams of developers a project, and compare the time
    >that it took them to complete the requirements

    How many developers where involved? How long did it take?

    Also, why did you choose to reimplement the 1.x version of the .Net Pet Shop, rather than 2.x?

    Best regards,

    Clinton Begin
    http://www.ibatis.com
    Home of JPetStore and the iBATIS Database Layer
  10. Re: How Long?[ Go to top ]

    Hi Clinton,

    What makes you think I was involved ;-).

    Seriously, though, we wrote the J2EE PetStore late last year before the 2.0 version of the .NET PetStore was released as an internal project and only decided to release it later.

    The project took 4 man weeks, which included reading up on .NET and the new release of Struts. Code clean and writing of the article took another couple of days.

    Best regards,

    /Kaare
  11. Half the Time[ Go to top ]

    Excellent Kaare!

    So it should be noted that you were able to write it in half the time it took Microsoft (actually Vertigo software --8 man weeks plus 2 weeks of tuning).

    Although you reused the stored procs (right?), I'm sure it wouldn't have taken more than a week to write them yourself.

    Cheers,

    Clinton
  12. Re: Half the Time[ Go to top ]

    Right, but as you point out we did reuse all database related code including schemas and seed data. On top of that, we didn't have to design the UI, but could simply reuse the HTML from the .NET petstore.

    Cheers,

    /Kaare
  13. If we are talking about LOC, cpetstore
    http://sourceforge.net/projects/cpetstore
    has almost 0 LOC in persistent layer
    most of entity beans are generated by middlegen.
    (LOC should not be counted in this case, IMHO)
    Developers only have write EJB-QL finders.
    (roughly one line for each finder).

    Regards

    Qiming He
  14. Generated code[ Go to top ]

    Your cpetstore example is another excellent example of the architectural options available to Java developers. Good job!

    Although I have a comment regarding this statement:

    >> most of entity beans are generated by middlegen.
    >> (LOC should not be counted in this case, IMHO)

    The only problem with not counting LOC that are generated is that Microsoft did not use (or need) code generators. And where they did (VS.Net), they counted the code. In their analysis they counted all lines of code (compiled and configured) that were required to run the application in production.

    So by these rules, we should count the generated code. This is one area where I actually agree with them.

    Just my opinion.

    Cheers,

    Clinton
    www.ibatis.com
  15. Whats an J2EE Application?[ Go to top ]

    Can anybody explain me whats the difference between a simple java-web-application (e.g. deployable in a standard servlet-container) and an j2ee-application?

    To my mind this Petshop is just a very simple Java-Web-Application. No transactions, no SessionBeans nor EntityBeans or any kind of messaging.

    Why is there the J2EE label on it? Just because J2EE is a buzzword?

    Also I dont think it's serious to compare an application developed on a 3rd-party framework and libraries (struts and many jakarta-commons-libs) with another application using only its built-in capabilities.

    Sorry for this critism. I love java. But this comparison is really ridiculous. Of course it demonstrates one fact: there are more open-source libraries available for java. But this is just a matter of time.

    Just my $0.02
  16. Whats an J2EE Application?[ Go to top ]

    <quote>
    Can anybody explain me whats the difference between a simple java-web-application (e.g. deployable in a standard servlet-container) and an j2ee-application?
    (...)
    Why is there the J2EE label on it? Just because J2EE is a buzzword?
    </quote>

    First of all, J2EE is not a "take it" vs "leave it" kind of thing. It's an umbrella specification for a pool of technologies that you can choose from. You simply pick whatever is appropriate for the projects at hand. That may not be a view that the major J2EE server vendors officially share, but it is nevertheless a fact.

    The term "Java web application" resp." "J2EE web application" (I'd like to omit the word "simple", as such apps can actually grow very complex) is not well-defined, as there's no clear distinction from a "J2EE enterprise application". The same applies to the underlying application server: "J2EE web application server" vs "J2EE enterprise application server".

    There are of course quite clear rules of thumb. A J2EE web application server has to support HTTP, Servlets, JSPs, and JNDI resources like JDBC datasources - in terms of deployment: WAR files. Furthermore, it may support JTA transactions. A J2EE enterprise application server, i.e. a fully certified J2EE server, has to support the whole menu: Servlets, JSPs, JDBC datasources via JNDI, a JMS provider, and most notably an EJB container - deployment: EAR files.

    According to this definition, Tomcat and Resin are J2EE web application servers (even with basic JTA support), whereas Jetty is "just" a J2EE web container because it does not feature out-of-the-box support for JNDI resources. JBoss, Orion, WebLogic, WebSphere etc are "full" J2EE enterprise application servers because they add EJB and JMS support.

    Both categories deserve the label "J2EE". J2EE web application servers support a significant and coherent subset of the J2EE umbrella specification. Of course, there's no respective web umbrella certification and associated branding. I think there should be: "J2EE web application server" should be an officially supported term, maybe even "J2WE" (Java2 Web Edition).

    Note that J2EE web application servers tend to be significantly less complex in terms of configuration and handling, compared to "full" J2EE servers. I like to call them "lightweight", compared to "heavyweight".

    <quote>
    Also I dont think it's serious to compare an application developed on a 3rd-party framework and libraries (struts and many jakarta-commons-libs) with another application using only its built-in capabilities.
    </quote>

    I've got a different view. Just because those third party frameworks are not included in the base platform doesn't mean that using them in such a comparison is unfair. .NET enforces certain approaches via tight programming models in the base platform, while J2EE only specifies generic technologies and leaves the rest to application frameworks. Both are valid approaches but differ quite heavily. IMHO it would be unfair to ignore anything beyond the base platform in face of such different approaches. Especially if the actual third party toolkits are open source.

    J2EE does not only offer a number of specification implementations but also various programming models on top. You can choose whatever suits your needs and your taste. Web frameworks and persistence toolkits are probably the prime examples. Concretely, Struts' architecture is far from perfect - I appreciate that it is just an optional framework, not an official base technology. And there are some flawed specifications too, but that doesn't really matter because there are alternatives in every respect.

    Regards,
    Juergen
  17. Whats an J2EE Application?[ Go to top ]

    Juergen,

    Sometimes I think that you are the only reasonable
    person left in the universe.

    Regards
    Rolf Tollerud