Discussions

News: TSS Announces Portability Re-Launch on WebLogic and Oracle9iAS

  1. TheServerSide has demonstrated J2EE portability in action by re-launching itself on a cluster of J2EE application servers, consisting of Oracle9iAS, and BEA WebLogic. The launch itself was an involved process, and we've written an article about various issues that had to be resolved when migrating TSS to a clustered environment.

    Read more about the cluster launch in our article about it:
    http://www2.theserverside.com/resources/article.jsp?l=tsscluster1.

    TheServerSide as an application now stands as a great example of J2EE portability in action. It's a production system with heavy loads (over 2 million pageviews/month) that runs with the same J2EE application binaries deployed across different vendors servers. Each server is J2EE 1.3 compliant and runs TSS in a consistent fashion.

    Participation in the cluster is open to all J2EE Server vendors. Oracle and BEA are the first vendors in the cluster for a variety of reasons. They were excited about hosting TheServerSide in production and proving their portability to the community. They compensated us for part of our hosting, porting, and maintenance costs. They were also one of the few vendors that met our requirement of having a shipping J2EE 1.3 compliant server. HP had also committed to joining the cluster, but then we all know what happened to them.

    We also used Tangosol Coherence to implement a clustered entity bean cache. More on that in the article.

    Press Release
    -------------------------
    TheServerSide.com Demonstrates J2EE Portability with Re-launch on Oracle9iAS and BEA Weblogic 7

    Austin, TX (BUSINESS WIRE) - October 8, 2002 - TheServerSide.com J2EE Community, in conjuction with BEA Systems and Oracle Corporation today concretely demonstrated the portability benefits of J2EE by re-launching TheServerSide.com across Oracle9i Application Server Release 2 and BEA Weblogic 7. The re-launch uniquely proves Java's (tm) promise that Java (tm) 2, Enterprise Edition (J2EE tm) is a portable development platform, and comes as a snub to Microsoft, a company often criticized for vendor lock-in and the lack of portability of the .NET platform.

    One of the primary benefits of J2EE over competing enterprise development platforms is portability. This has been the rallying cry for J2EE and one of its core value propositions that has allowed J2EE to grow as a lively community/industry of vendors and developers. But how far does the portability promise go?

    TheServerSide.com J2EE community is demonstrating to the world just how far J2EE portability can go. What they decided to do was demonstrate runtime portability of a J2EE application in production, by taking TheServerSide.com (itself a J2EE application) and running it in real-time/production across a cluster of different vendors servers. In todays launch, TheServerSide.com is running in a cluster consisting of BEA Weblogic 7 and Oracle9i Application Server Release 2. For the previous 2 years, TheServerSide.com ran as a single-server application on BEA Weblogic 5.1.

    Oracle and BEA were chosen to run the cluster because they have shipping J2EE 1.3 certified application servers, and showed eager willingness to work with TheServerSide to ensure that the cluster launch went smoothly.

    "As our community members browse www.theserverside.com, each web request will be served by either of the deployed application servers, and the end user will be able to visibly notice which server is hanlding the request." said Floyd Marinescu, Director of TheServerSide.com. "BEA Weblogic and Oracle9iAS are both running the same version and build of TheServerSide.com application, and are running it equally and compliantly."

    "This project conclusively demonstrates the interoperability of standards-based J2EE server technology, and we are proud that Oracle9i Application Server helped TheServerSide.com achieve this objective," said Thomas Kurian, senior vice president of Oracle9i Application Server Development. Oracle9iAS supports the latest J2EE standards and provides a fast, reliable and complete middle-tier infrastructure required to support business-critical applications such as TheServerSide.com."

    "Multiplatform computing is the reality of today and increasingly the reality of tomorrow," said Ralph Galantine, Group Marketing Manager, Java, Web Services Technologies, Sun Microsystems. "Key to success in this computing environment is a portable technology like Java. TheServerSide cluster provides a compelling demonstration of Java platform's portability which liberates enterprises from single vendor dependence and creates business opportunity."

    TheServerSide invites vendors of other J2EE application servers to prove their J2EE compliancy and join the cluster.

    ABOUT THESERVERSIDE.COM J2EE COMMUNITY
    TheServerSide.com J2EE Community is the central site for J2EE vendors and developers, with over 225,000 registered members and over 2 million page views per month. Built for developers, by developers, the community-driven site offers daily updated J2EE specific news, discussions, interviews, design patterns, product reviews, events, resources, and more. TheServerSide is written in J2EE and runs on a cluster consisting of Oracle 9iAS and BEA Weblogic application servers. TheServerSide is built and run by The Middleware Company, a training and consulting company dedicated to server side java.





    Threaded Messages (69)

  2. To all those dot-netties out there: bring it on!
  3. Way to go Dion!
  4. Bravo, guys! Keep up the good work!
  5. Great job Dion, TSS really screams now.
  6. Great Work!

    Are there plans to also port TSS on Websphere and Pramati?
    They satisfy your conditions - right?

    Rob
  7. Yup, Dion did a kick ass job taking my circa-2000 codebase and turbo charging it, handling the ports to the new appservers.

    Floyd
  8. I see your point about financial support from Application Server vendors. However I think that the portability demonstration would be incomplete without JBoss being included.
  9. IMO the only way you can run a cluster containing servers from different vendors is to have your application as stateless. Othewise you go for bespoke solutions like JMS based distributed storage and stuff like that (or you can store the state in the database :-)). Most of the challenges in a clustered environment are replicating the state. Also, I can't imagine any large enterprise running an application in a cluster of different servers. I agree, it is great from J2EE portability perspective. Apart from that, I am sorry, there is nothing great in it.

  10. 2 million page views per month is ca 46 per minute. Even if you allow for peak situations, wouldn't the uncomplicated TSS page run better, faster with "LAMP" on a Wal-Mart $2000 computer? LAMP=LINUX,APACHE,MYSQL,PHP.

    Regards
    Rolf Tollerud
     
  11. It'd have to take into account multiple submissions from users, so multiply by 2. ;-)
    Steve
  12. To really demonstrate J2EE portability, you guys should also make this cluster heterogeneous in terms of platforms: use Windows, Linux, Unix. Possibly, S/390 is IBM wants to sponsor :-)

    Good job (hopefully the duplication bug will be fixed soon)

    George
  13. Websphere has a J2EE 1.3 compatible production app server ?? Since when ?? I thought they only had a preview running on W2K.
  14. <quote>
    2 million page views per month is ca 46 per minute. Even if you allow for peak situations, wouldn't the uncomplicated TSS page run better, faster with "LAMP" on a Wal-Mart $2000 computer? LAMP=LINUX,APACHE,MYSQL,PHP.

    Regards
    Rolf Tollerud
    </quote>

    In that case, wouldn?t the microsoft site be better off running on a SunFire with 64 processors & Weblogic ??
  15. I don't know if the current site is running on this cluster but when i hit the home page (http://www2.theserverside.com/home/index.jsp), the "Apache AXIS 1.0 Released" announcement shows "8 messages in thread...". But when I refresh the page, it shows "4 messages in thread...". The thread has only 4 messages. Caching issues?
  16. Why don't we see the power of EJB2.0, interoperability cross EJB containers? It looks like, the business process is still fully executed in one vendor's product.

    Is there any technical problems with these vendors compliance with full EJB2.0?

    If we can see some EJBs deployed in vendor1's container, the other in vendor2's container. Naming Service is based on INS, Security Service based on CSIv2, communication protocol based on IIOP so transaction context can be transparently propagated...

    That will rock the foundation of M$, the real power of distributed computing cross vendors.

    BTW, I tried to post this yesterday, but it got lost! While some other people experience double posts, looks like the cluster is totally out of sync...
  17. It is certainly very impressive to see TSS deployed on two different app servers and both are running in the same cluster. The article, however, didn't give topologic layout of the servers and components. It is hard to see to what extent and what clustering features that the TSS cluster provides. Hopefully more information on cluster configuration, failure recovery, load balance, etc become available from TSS.

    Keey up with the good work!
  18. 2 million page loads/month is not exactly what I would call a heavy load. We get 3 million page loads/week on our system serving fully dynamic pages (pages are hardly ever the same so caching is basically impossible). This is accomplished with a three-tier system with three 1.2GHz intel boxes with tomcat.

    I do realize the point of this experiment wasn't the load but still...
  19. <quote>
    2 million page views per month is ca 46 per minute. Even if you allow for peak situations, wouldn't the uncomplicated TSS page run better, faster with "LAMP" on a Wal-Mart $2000 computer? LAMP=LINUX,APACHE,MYSQL,PHP.
    </quote>

    Something like vBulletin ?

    --
    Dimitri
  20. "Websphere has a J2EE 1.3 compatible production app server "

    They don't have one now, thats why we aren't running with them. They will have one in 2003 (Websphere 5).

  21. <Something like vBulletin?/>

    Yes, why not? Another example:

    "The U.S. Census Bureau's MySQL-based "QuickFacts" (quickfacts.census.gov) is an award-winning, user-friendly web site that provides state and county profiles with the latest Census statistics about people, business and geography. Visited by many students and others unaccustomed to using Census data, QuickFacts serves an average of 120,000 pages per day. It won the 2001 Census Bureau's Director's Award for Innovation in 2001. The U.S. Census Bureau's open source-developed web sites have served as models of success for this government agency. "We've had a lot more traffic to our office because of our success with MySQL," said LaPorte Taylor. "We are now helping other departments within our agency develop applications with open source software, and we have future plans for more MySQL-based applications."

    I always thought Java (or .NET) for use of *not trivial* applications. LAMP is a perfect fit for *trivial* high-volume sites.

    Regards
    Rolf Tollerud
  22. "2 million page views per month is ca 46 per minute. Even if you allow for peak situations, wouldn't the uncomplicated TSS page run better, faster with "LAMP" on a Wal-Mart $2000 computer? LAMP=LINUX,APACHE,MYSQL,PHP"

       I suppose it could run on a LAMP setup. However, TSS is a J2EE site. Back in 2000 when it was launched, it was a cool proof of concept for J2EE, as it was one of the few apps at the time running on J2EE or EJB for that matter. Being about J2EE, we're putting our money where our mouth is so to speak.

    Floyd

    ps - thanks for letting us know about these bugs, we are working on them. Not everthing comes up during testing cycles... :(
  23. We have run into some problems with some of the use-cases under load on the server and are working to solve them as we speak. I appreciate your patience.
  24. You are censoring posts or are they just vanishing ?
  25. "They don't have one now, thats why we aren't running with them. They will have one in 2003 (Websphere 5). "

    Websphere 5.0 will be released in November 2002.
  26. The "TheServerSide.com" is a good site, with good content, great community, and in general a great source of information, but as applications go "TheServerSide.com" is a huge piece of crap.
    I was just at the Petshop thread, and, ignoring the fact that is now over 1.4MB in size, its impossible to follow any thread in a non painful way.
     
    - There is no possibility to see the posts in a threaded way
    - There is no possibility (at least that I can see) to preview the posts before submission.
    - There is very limited support for HTML posts.
    - For a community oriented site there is not much features that address the community. e.g.: I can't see a way of seeing former posts from a user, I can't see a way of ignoring post from a user.
    - Maybe is because I'm in Europe but the site is as slow as molasses in January, the front page takes forever to load, when it loads at all.
    - There is no Topics for the front-page posts and no way to choose which Topics we want to see.
    - There is no possibility to revert the order of the posts, i.e., seeing the new ones first.
    - Overall the interface feels... well... dated.

    I can understand that you guys don't want to use "Slashcode" but the javalobby.org site although not perfect is light years ahead, and they also use a Java backbend.

    Like I said, I love the site and I came here several times/day, but as an application that in Floyd's words are supposed to showoff J2EE it's not doing a very good job. The usability sucks and the resources behind it are over the top.
    A cluster off Application Servers to serve 2M pages/month?... are you kidding?! There is something very wrong with this picture.
    Is the cluster used by necessity or to serve as an academic exercise?

    P.S.: Why are some non-duplicate posts disappearing?

    Best regards,
    Luis Neves
    <me ducks>
  27. I agree.
  28. "You are censoring posts or are they just vanishing ? "

    Lars, we very rarely censor posts. In this case, since we fixed the bugs in question, we did delete the bug related and duplicate posts, since they aren't adding value to the scope of this thread.
     
       thanks everyone for helping us track down these bugs.

    Floyd

  29. Luis,

    You are right on all counts. Why isn't TSS more advanced? Cause we didn't have the manpower to put into feature development over the last few years. I spent most of the time I could spend on content, and I think we've done a good job on that front.

    What are we doing to fix the problem? We have a full time person dedicated to building these features you are asking for. Dion Almaer is a kick-ass architect and will be focused on the features you mentioned.

    You can expect some big improvements over the next 6 months, hang in there guys. :)

    With regards to the questoin about did we need the cluster for academic or technical reasons? Its obviously more academic than technical. As the article says, this launch is a demonstration of J2EE portability.

    I am grateful that you guys are loyal members, and care enough to express your honest view in this thread.

    Floyd
  30. This good news to finally have a site running the same app on different vendors appservers. Maybe you can tell a bit about Floyds original "mid-2000" code/design and what was needed to make the orignal app portable. What sort of beans do you use? CMP/BMP?

    Regarding app servers ... it would be awesome if you could bring an open source app server like jboss or jonas into the cluster. Any plans on this?

    Regarding the 20000000 (how many zeros?) pages/month discussion, I don't believe this should be discusses in this thread. I think, if this ever becomes an issue for TSS, something like OSCache will fit very well.

    Nice job ... talked the talk and walked the walk.
    -thebob.
  31. Floyd, when we talk about new features, are you considering to offer a newsfeed like http://slashdot.org/slashdot.rdf? That'd be so cool.
  32. Me stupido ... there it is and I cannot see it. Too many trees, no forest.
     
  33. Despite the problems TSS is a very good site and I like it very much. I never liked javalobby because it has an absolutely awful layout (how many items can you put on one page?).
  34. WoW!! But isn't one of your favourites missing out here?

    - Pramati?

    /He! He!
  35. Floyd,

    what about making TheServerSide.com OpenSource and let the community help you build some features. You and Dion could act like a steering committee deciding which features to add to the page and which you won't include. I see some benefits for you and the community in that approach. First TheServerSide.com will propably improve. Second it would be a nice example for a running protal on different AppServers that us guys could use to build better code for our customers. This would be like a usable "PetShop" in a runnig environment...


    Mirko
    :wq
  36. Yes, We are going to be supporting RSS for TSS content in the near future.
  37. Mirko, we've thought of the open source question many times. Havn't made up our minds yet. You are right about the benefits. :)

    Floyd
  38. <quote>
     Yes, We are going to be supporting RSS for TSS content in the near future.
    </quote>

    Wow, now *that* would be cool!

    And thanks for modifying the links on the front page to include the date of the last article posted and also the article count, it makes it much easier to figure out if new articles have been posted since last time I read it.

    Go, Dion!

    --
    Cedric
    http://beust.com/weblog

  39. Hi,

    What do you guys think about Tangosol cache? Have you seen any problems until now?
  40. As I said in the article. It has been great to use.
    It is very simple to install, and programatically you get a Map to play with. How simple is that?
    To test it, we hammered the cache on both machines, and it handled everything easily.
    Basically, it works, its fast, and it is very simple to use!
  41. and programatically you get a Map to play with


    I'm wondering why they don't provide a JNDI interface to Tangosol. JNDI is also simply a Map but it's standard. Further, there are a lot of possibilities when using JNDI instead of a proprietary interface (factory to create the Map). For example, replacing the whole JNDI impl of an app server with Tangosol-JNDI and thus make it clustered out-of-the-box, configuring different caching policies per sub-context, JNDI federation, mounting other JNDI trees into Tangosol-JNDI and thus make it cluster-ready, sharing JNDI tree over different vendor's app server, <your ideas here>

    I guess if Cameron don't provide that, I will give it a try... ;-)

    -- Andreas

  42. I have some questions about the migration and its results:

    1. Did you check the overall architecture for performance? ( previous against current ).

    2. OC4J offers a cache facility of its own, did you consider it before going for teh 2k$/cpu Tangosol ?

    3. Which node (Oracle/BEA) does more transactions and how much?

    4. Which JDBC Driver do you use for the WL and the OC4J?

    Thanks,
    Yuval.

  43. Hi Andreas,

    Andreas: "I'm wondering why they don't provide a JNDI interface to Tangosol. JNDI is also simply a Map but it's standard."

    First, there's one good reason (same reason why JCACHE JSR is considering using Map as the basis for the API) and that reason is that everyone and their brother uses Hashtable for caching. When we say, "It's the same interface as Hashtable", potential customers say, "Oh, we use Hashtable right now for our caches." So I guess you could say that it is hardly an accident.

    Secondly, we could expose other APIs. Some people ask us for clustered JNDI (more on that below), some ask us for clustered JMS (I'd rather see the successful JMS vendors use Coherence ;-), some ask for clustered JavaSpaces, some ask for clustered RMI, etc. The only commitments we've made are for JCache (when there is an API), HttpSession (we already support this for WebLogic7, WebSphere4, Tomcat4 and all Servlet23 containers), JTA/XA (we already have several customers using these interfaces for doing transactional caching), J2CA to plug our JTA/XA stuff in to the app servers, and various XML APIs for handling things like distributed XQuery.

    That's a lot of TLAs (Three Letter Acronyms).

    Andreas: "Further, there are a lot of possibilities when using JNDI instead of a proprietary interface (factory to create the Map). For example, replacing the whole JNDI impl of an app server with Tangosol-JNDI and thus make it clustered out-of-the-box, configuring different caching policies per sub-context, JNDI federation, mounting other JNDI trees into Tangosol-JNDI and thus make it cluster-ready, sharing JNDI tree over different vendor's app server, <your ideas here>"

    I like your ideas, but I'm a bit worried after seeing how different app servers assume that the JNDI implementation is their own. For example, I think we'd have some real problems replacing WebLogic's JNDI implementation. OTOH, I might just be FOS since we've never actually tried.

    Andreas: "I guess if Cameron don't provide that, I will give it a try... ;-)"

    I like your attitude. Let me know how it goes ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  44. I like your attitude. Let me know how it goes ;-)


    IMO, a 3rd party clustered JNDI is a good product opportunity and a technical/architectural challenge as well. I should not think about it, otherwise I start up with a design. However, as you know, I have another baby which needs my full attention for the next decade...

    Nice weekend,
    Andreas
  45. Floyd, Dion,

    It's great to see TheServerSide.com now running as a J2EE app on several different app servers. I hope you get the chance to write additional articles on what you found with each server (I'm assuming we'll see WebSphere and iPlanet and Jetty/JBoss and ...). I was hoping to see more technical detail on the Oracle "port", including any difficulties you had with it. Likewise with each additional platform. Maybe under "about this site", you could post an article on each, current ones included, showing specific configs and descriptors. Anyway, as a J2EE portability "proof of concept", it already ranks up there with the PetStore, and for interoperability, it's probably in a league of its own ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!


  46. <Anyway, as a J2EE portability "proof of concept", it already ranks up there with the PetStore/>

    You have now proved that a Java application that could have been written in one afternoon with PHP can be ported to another appserver, and comparing it to Petstore, a program with thousands of rows of code and 700 files.

    Congratulation!

    Regards
    Rolf Tollerud
     
  47. Dion,

    The article didn't mention what load balancing product
    is being used ?

    Thanks

    Gavin
  48. Since J2EE portability is quickly dropping as a priority for companies (compared to interoperability, manageability, and developer productivity), Are you guys considering "portalizing" TSS, interoperating with portals/portlets, or even publishing a WebServices API?

    Also, Why are you guys using Open Source functionality vs. what is provided by WebLogic and Oracle? (OS must be starting to drive a lot of AD revenue for you!)

    Matt

  49. Rolf: "You have now proved that a Java application that could have been written in one afternoon with PHP can be ported to another appserver, and comparing it to Petstore, a program with thousands of rows of code and 700 files."

    Wow. You have to be one of the most negative persons I've ever met (virtually speaking) in my life.

    Let's start with the obvious: This is "TheServerSide.com Your J2EE Community", so I feel they have a right -- if not obligation -- to run their site using J2EE. I don't see any suggestions that the web site for "Joe's Car Wash" should be running on a multi-vendor clustered configuration, for example.

    Consider: Java apps work across many platforms, unlike e.g. .NET. Java apps interoperate (RMI, serialization, standard protocols, binary compatibility, etc.) across many platforms. Higher level standards, such as J2EE, are implemented by many vendors. Applications written to those standards also work across those many vendor implementations across the forementioned many platforms.

    Instead of just talking about it, TheServerSide.com did something with it. They "put their money where their mouth is", so to speak. (There's a corollary to that saying, which is "put up or shut up".) Sure, a multi-vendor cluster of J2EE app servers is not necessarily practical, but it was never meant to be practical: it is instead a public proof-of-concept and seemingly a good one at that.

    I think your acquiescence is in order until you have a similar application built out of standards-based components working in a clustered environment of both both Windows/IIS/ASP.NET and Linux/Apache/Mono with the same exact set of binaries running on both.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!

  50. Cameron,

    ?Wow. You have to be one of the most negative persons I've ever met (virtually speaking) in my life?

    Thank you. That hurt!

    I have no problem with that TSS is using J2EE to run their site. I would have done the same being in the same situation. On the contrary, I would be strange if they used any other technique and as I have said before, TSS is a great site.

    But I am just taking the opportunity to set the light on Java over-engineering in general.

    Doing any kind of complicated things in PHP or ASP results in completely un- maintainable spaghetti code. That was one of the reasons that Java is superior, maintaining MVC, separating content and code.

    All over the world there are hundreds of thousands of vertical business applications that apply only to some special kind of business, or just even a single company. Typically there is something like 30.000 ? to 90.000 rows of code. These apps would benefit greatly by being done as browser-applications, saving $millions (and earning $millions for the developers). You know as well as I do all problems with maintaining an app with 100 DLLs for 100 users. Not to speak of 1000 users or more.

    This is the right place for Java, a perfect home for J2EE (and .NET). There is just not any other way to do it.

    But instead of seeing a lot of these business apps appear I see again and again Weblogic and Websphere been used for simple sites that would have been much better of being done in PHP, ASP or CGI etc. The point is, for a -trivial application- it doesn?t matter to mix HTML and code, the designers are not idiots!

    And for the portability of programs between Java app servers, I wait until I have been convinced that it is easy and simple to port something like Petshop between servers.

    J2EE community. Stop playing and start working!

    Regards
    Rolf Tollerud
     
  51. Dude. Why are you here? I mean, I'll defend your right to be here, but why do you waste your time? It's just amusing that you spend so much time extolling the virtues of toys for toy web sites. I think what we all hope (and our employers) is that our server-side apps turn from being toys into sites that need so-called "over-engineering."

    I mean, at least Java Developers can do OOP intelligently, unlike many of your php hackers and ASP weenies. I know that's a generalization, but you're making one as well, and the implications of your generalization are:

    Java developers know how to refactor, use OOP correctly, and design a system that's maintainable.

    Major bummer 8-)
    Steve

  52. Maybe TSS could publish some WEB services like Oracle tech network did.

    Maris
  53. I also posted the following here.

    In a TSS Thread, Rolf writes:

    <<
    But I am just taking the opportunity to set the light on Java over-engineering in general.
    >>

    Russ expressed a similar concern:

    <<
    Is it just me, or is J2EE just insanely verbose?
    >>

    It is hard to deny the complexity of J2EE, but I have a slightly less pessimistic take on it. While a lot of applications out there tend to be over-engineered, I think it is just the manifestation of the fact that for the first time in the course of the information era, software might actually be getting ahead of its needs.

    Believe it or not, this amazing fact already happened for hardware. It was already hard to ask the demand to keep up with Moore's law (in short: a lot of us are using machines that are much faster and bigger than we really need), but on top of that, it looks like we are actually accelerating way past Moore's law predictions (I wish I could remember where I read this).

    So... hardware is going too fast, and it looks enterprise software is following the same way. But ask yourself this: is it a bad thing if enterprise applications get written to handle cases that have not arisen yet? What's wrong if TheServerSide can now handle an order of magnitude more requests than it is handling now? What it means, is that when this time comes, the developers will already be tackling the next problems, hence staying ahead of the curve.

    What does this say about J2EE? A lot of good things. J2EE looks very complex and intimidating, but the bottom line is that after getting past the learning curve, developers are not afraid to over-engineer their applications because they can still meet their deadlines while planning for future growth.

    I don't know about you, but this sounds very familiar to me. I went through the same kind of revelation in 1995 when I started realizing that Java was a lot more friendly to program than C++ (and I was a very ardent C++ supporter back then). I remember being very shy about adding features or refactoring code in C++, but suddenly, Java made this process less intimidating, and I started "programming ambitiously".

    I will write a separate article for this, there's a lot to tell. In the meantime, please don't be intimidated by J2EE :-)

    --
    Cedric
    http://beust.com/weblog

  54. "Java developers know how to refactor, use OOP correctly"

    Gee, I'm impressed. I am sure Donald Knuth is impressed too. Now you only need too learn that less is more..

    Regards
    Rolf Tollerud



    Regards
    Rolf Tollerud
     
  55. Rolf: "Gee, I'm impressed. I am sure Donald Knuth is impressed too. Now you only need too learn that less is more.."

    You're being negative again. You need to watch some Stewart Smiley.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  56. On the average, I would say this is true. Or at least the average is trying. If you look at the Java IDEs/Tools compared to VS.Net, you will see that the tools reflect the typical developer's concerns. Java IDEs (typically) have things like refactoring built in and are built to create OO applications. VS.Net is built to whip out apps with little concern for the future (no refactoring built in, little OO in the GUI, etc.). Good [OO] coding can be done in VS.Net [minus the cross platform issues] but it takes time just like in Java. It is just that the typical mindset of a 'Windows Programmer' is their app will run on one OS (Windows) and for one purpose (i.e. a Web App).
  57. since we fixed the bugs in question,

    >we did delete the bug related and duplicate posts,
    >since they aren't adding value to the scope of
    >this thread.

    I still see 'Unknown error' message from time to time.

    --
    Dimitri
  58. I'd like to second that. Last week I had the opportunity to talk with a few of the developers from my company's .NET group. Not understanding or having any concept of MVC, Model 2, seperation of concerns, or pull vs push I can excuse, but how can one design an OOP app w/o knowing simple design patterns like the business facade or data access object or a basic 3 tier design? All the code for their app, including sql, was in their code-behind page!

    Now, granted they are not necessarily typical of a .NET development team, but I think the parent's point is applicable here. VS.NET teaches the developer to run through wizards to develop code which the Java apps tend to use things that require some prerequisite study like struts to get something done. Of course, the VS.NET app will get up quicker, but their maintainability, flexibility, etc will be no better than a mediocre ASP app.

    As a result, getting back to my story, their app was a complete rewrite of a previous app serving the nearly the same function, as the previous app was completely unmaintainable and inflexible. With their current redesign, I'm sure the same will need to be done in another few year's time. Complexity is good if it positively contributes to the open-closed principle - open to extensions, closed to modifications.

  59. "VS.Net is built to whip out apps with little concern for the future"

    It?s your choice. The Mono web components will not be available for deployment until somewhere around second half of 2003. (although I'm sure that some early adopters will try before). So J2EE have the advantage of 6-8 months. Don't take this opportunity and you will loose this rich and profitable market to the .NET.

    It?s up to you.

    Regards
    Rolf Tollerud
     
  60. Rolf,
      You missed/ignored my '[minus the cross platform issues]' and that I said 'VS.Net' and not '.Net'. I was talking technique. The future being maintainability and multiuse 'apps'. Yes, this can be done in .Net. But how many doing .Net are doing MVC, O/R Mapping and not doing SP's? To do MVC in .Net you have to 'roll-your-own'.

    As for the cross-platform issue (which I was purposefully avoiding). No one has a crystal ball. All we have to learn from is history. "Those who don't learn from history are doomed to repeat it." History shows us that, other than simple little 'programs', Mono.Net applications will not run in MS.Net and the other way around. One will be able to take most of their knowledge (and some of their code) and code something in either platform.

    But this being said, those who code in MS.Net (VS.NEt) or Mono.Net like the 'typical' Java programmer does will have more of a chance of the majority their code running in the opposing platform (sans any shenanigans by MS) and being able to be maintained there (have you looked at all the stuff VS.Net generates?).

  61. Mark,

    In this case I agree with you and I can assure you as soon the Mono 1.0 is out, me and most other guys I know that currently is using .NET will switch to Mono, a free ISO C# standard with an Open Source implementation. If MS break the compatibility there is only more reason for doing so.

    That stands even if they have only 2/3 of the functionality of MS.NET. The advantage of cross-platform outweighs everything else.

    If the future is maintainability and multiuse 'apps' I suspect that the work will be lower level roll your own hand code and less "industry rolling band" which is fine for me. Our profession is one of the very few hand-crafts left in the world.


    Regards
    Rolf Tollerud
     
  62. Rolf

    I must agree with you. And I'm a Java guy. Design Patterns, MVC, O/R Mapping and good OOP design aren't monopoly of just Java guys. If Java could grow-up in past years, why don?t an GOOD open source and (!) plataform independent implementation of a well designed OOP language with services like garbage collection, thread managament and class loading couln't be sucessful ?

    But please remember that C# was designed when Java already was running really critical business apps... The guy that was the technical leader on C# was a venerable former Borland (Delphi VCL) enginner, a de facto "OOP oriented" standart language for many pre 3 tier, business, client server applications.

    The really big question is about the success of Ximiam?s project. When (an if) they could really deliver what they are promising, more talented guys will pay attention and port to it. And those guys could easily build fantastic frameworks as we have today in Java. I?m impressed with Cedric Beust reply. Moore?s law is being a happening for software today. It?s like a biological evolution, don?t you think ?

    Cheers,

    Rodolfo

  63. In the film Jurassic Park, based on Michael Crichton's novel and directed by Steven Spielberg, the mathematician Ian Malcolm (Jeff Goldblum) answer the theory to prevent natural reproducing by only cloning females, "Nature will not be stopped".

    Despite the efforts of Sun, JCP and Microsoft it still will exist a free implementation.
    "Nature always finds a way".
  64. <Q>In this case I agree with you and I can assure you as soon the Mono 1.0 is out, me and most other guys I know that currently is using .NET will switch to Mono, a free ISO C# standard with an Open Source implementation. If MS break the compatibility there is only more reason for doing so
    </Q>

    Just keep in mind that your code will only run where Mono does unless you only do what is specified by the specification. Anything beyond that (which you really will need) is just asking for trouble. Hopefully there will be a good IDE for it by then too. VS.Net won't do you any good.

  65. Mark,

    I do not understand exactly what you mean. MS will always be a little ahead of the Open Source, therefore you can not use everything in .NET but you can use everything from Mono which runs on both Linux and Windows (more platforms coming).

    As to VS.NET, we never use it - only text editor and compiles with NAnt. The only other thing we use is DbgCLR.exe, the free debugger. Hopefully Ximian will come up with something similar.

    But if you are into that kind of thing I think you can use Eclipse with Mono.

    Regards
    Rolf Tollerud
  66. Rolf,
      The Specification only provides a small portion of .Net. The rest Mono is guessing or trying to emulate (I can quote their site and their leader if you like). Those extra things are needed to do useful applications. So typical business apps will more than likely (who can say for sure till we can try it - put money on MS to mess things up) not run on both platforms without modifications. Once (and if) Mono is available on multiple plaforms, we can forget MS. That is if they let us. History says no.

    I am into things like Eclipse because they save me much time without getting in my way.


    BTW, MS will be way ahead of Mono for quite a while.


  67. "Once (and if) Mono is available on multiple plaforms, we can forget MS"

    Exactly.
  68. I think that this could never run on iPlanet! Who has a different opinion?
  69. Aha - sorry, I had written this comment before I've read how this cluster was done. I see it is not a "real" cluster and that it could work on iPlanet as well. We have just some experience that iPlanet has problems to call components from one its instance to another one.
  70. Tomas: "I had written this comment before I've read how this cluster was done. I see it is not a "real" cluster and that it could work on iPlanet as well. We have just some experience that iPlanet has problems to call components from one its instance to another one."

    This is the first time that Coherence has been used to cluster together different vendors' servers all in one tier, but it isn't the only case in which it has been used to cluster different application servers and/or other JVMs into a single cluster. And Coherence certainly provides a a "real" cluster that allows all those different processes to know about each other, share live data, and even coordinate processing among the servers using leasing/locking.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!