Discussions

News: Five reasons against migrating EJB applications to .NET

Bookmark and Share Get thread feed

  1. Five reasons against migrating EJB applications to .NET (119 messages)

    If your manager is silly enough to be thinking of dishing out the cost of migrating your system to .NET, an article on builder.com gives some obvious reasons agaist that, including that the CLR does not support Java, IIS does not support JSP, Server controls require redesigns, .NET doesn't support CMP and has a very different session handling implementation.

    Read Five reasons against migrating Java EJB applications to .NET.

    The whole idea of the article is some what ridiculous, but it I got a good laugh reading it. Probably the most important point that wasn't mentioned was: Cost!
    Reply to this

    Threaded Messages (119)

  2. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Also, one important factor is if your EJB app is running on a platform other than Windows, then you have to port the OS.

    Also, how about any of the other declaritive issues in J2EE. I don't know .NET too well, but do they support Declaritive transactions and security. If not, I would imagine that new transactional and security code is another big task.

    Integration I would imagine is another big point. If you are going to a Mainframe using JCA or JMS, big coding changes would have to be made. How would re-code a Connector?
    Reply to this Reply to original

  3. Five reasons against migrating EJB applications to .NET[ Go to top ]

    The whole point is kind of "irrelevant". The battle is not for old applications, but for new ones. Web UI and VS.NET allow to write simple application very fast and IDE-integrated JSF is (unfortunately) at least 2 years behind. Of course, for stable big complex application speed to write GUI part is proportionally smaller, so J2EE is a (current) winner here as more mature framework.

    I did asked once this question with no answer, here it is again: What is the 3 year cost for .NET stack vs Java stack ??? My VERY aproximate guess is
    -- linux, Eclipse, XDoclet, JBoss, MySql - O$
    -- linux, WSAD, WS -- 50K
    -- solaris, JBuilder, WL -- 100K
    -- XP, VS.NET, IIS...... $$$???
    -- .NET server, VS.NET......$$$???

    Thanks for any information or links.

    AlexV.
    Reply to this Reply to original

  4. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Alex,
    how did you come to the result 0$ cost for 3 years? Is it also 0$ for 4 years? Then why did you select 3 years?
    The software license cost, alone, doesn't mean much.

    What matters in real world is the total cost which includes hardware, software license , development, operation, maintenance etc.
    Reply to this Reply to original

  5. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Ozgur,
    Floyd Marinescu had noted "COST" as a factor. I just curious what he is talking about. I suggest, for example calculate total cost for some small and one complex project - creation and maintainance for 3 year:

    small one:

    Java
    several PC-10K, Linux-Eclipse-Tomcat-JBoss-MySQL(InnoDB)-0$, Creation - 1 man-year = 80k, Maintainance 6 m-y - 400K, 3y-licence == 0$ total = ~500K

    .NET
    several PC-10K, XP(pro?)=0.5K, VS.NET=???, .NET framework==???, SQL Server=???. Creaion 0.5 m-y == 40K, Maintainance 6 m-y == 400K. 3-y licence==????
    Total 450 plus purchase and licemce of software ??????

    Can somebody suggest realistic price scenarion for big project ?

    AlexV.
    Reply to this Reply to original

  6. Five reasons against migrating EJB applications to .NET[ Go to top ]

    "Floyd Marinescu had noted "COST" as a factor. I just curious what he is talking about."

    What I meant was it would be ridiculous to port an existing and working J2EE system to .NET because it would cost way to much money to perform the port. J2EE is not legacy technology, why the heck would someone spend so much money porting it?
    Reply to this Reply to original

  7. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Thanks Floyd, now it is clear.

    Still, price for .NET stack and/or individual components is a mistery... :-)

    AlexV.
    Reply to this Reply to original

  8. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <Floyd>
    What I meant was it would be ridiculous to port an existing and working J2EE system to .NET because it would cost way to much money to perform the port. J2EE is not legacy technology, why the heck would someone spend so much money porting it?
    </Floyd>

    Why would anyone replace a working and tested application let alone a J2EE based one? :)

    Extend and enrich! :) EAI & WebServices!

    (Sorry had to spread the propaganda. My head is spinning from David's post still!)

    Greg
    Reply to this Reply to original

  9. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Thanks Floyd, now it is clear.

    Still, price for .NET stack and/or individual components is a mistery... :-)

    AlexV.
    Reply to this Reply to original

  10. Five reasons against migrating EJB applications to .NET[ Go to top ]

    PC and operating systems costs are a wash.

    VS.Net Enterprise is about $2400 for a site license and eliminates the need for JBuilder, Er & UML modeling, and test automation tools.

    The .Net Framework like the JVM is free and from what I hear will be shipped with the operating system in the future.

    IIS comes with Win2k Server, Win2K Prof and WinXP Prof.

    Creation time should be the same or less as VS automates much of the front end work. Back end work should be about the same.

    Mike P.
    Reply to this Reply to original

  11. Five reasons against migrating EJB applications to .NET[ Go to top ]

    PC and operating systems costs are a wash.


    They are? Tell that to all the people paying for Windows licenses, upgrades, maintenance, upgrade protection and time lost to ensuring compliance and compliance inspections and fighting viruses and bugs and updating all the software to ensure protection.

    The only washing occuring is after people wake up and wash their hands of Windows.

    <Q>VS.Net Enterprise is about $2400 for a site license and eliminates the need for JBuilder, Er & UML modeling, and test automation tools.
    </Q>
    It does? Cool. No more testing! Or modeling! Yeah!

    <Q>
    IIS comes with Win2k Server, Win2K Prof and WinXP Prof.
    </Q>
    And we turn it off. ASAP.


    <Q>
    The .Net Framework like the JVM is free and from what I hear will be shipped with the operating system in the future.
    </Q>
    Free from MS. Hmmm. Sounds anything like "go ahead, this one's on me. It won't hurt you."

    <Q>
    Creation time should be the same or less as VS automates much of the front end work. Back end work should be about the same.
    </Q>
    Heck. I can whip out the same stuff in Java. Of course it will be an unmaintainable, unreusable pile of pooh too.


    Reply to this Reply to original

  12. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Alex,
    Your $0 price is definitely very attractive, but:
    How much will be the cost of lost business due to down time caused by non-enterprise-grade, limited functionality, low quality, un-supported products?

    And, how much will be re-architecting and replacing the infrastructure once your customers are fed up, and you need to move to real world, mission critical solutions?

    Obviously, there is a plain programmer's point of view, and then there is real business.

    My 0.02,

    George
    Reply to this Reply to original

  13. Five reasons against migrating EJB applications to .NET[ Go to top ]

    George,

    Yes, I am a programmer, so I am asking if somebody can explain bigger price picture. About features, can you provide price scenario for some, let say, medium project (where .NET and J2EE may have similar functional solutions)?

    AlexV
    Reply to this Reply to original

  14. Five reasons against migrating EJB applications to .NET[ Go to top ]

    George - LOL.

    You really need to wake up.

    Apart from oracle which we pay for, we are running an on the "$0" stack.

    Yes, Linux, jboss, apache etc.

    And you know what? It rocks.

    24 x 7 uptime, and we're talking 100s of $1000000 revenue.

    ALL taken from this one system that runs the site and runs our company.

    If that's not "business sense" I don't know is.

    But, if you'd feel happier shelling out 100's of K$, well.... good luck to you.
    Reply to this Reply to original

  15. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Everyone:

    Before we get into the "We use open source" comments... Please make sure you let everyone know where you work. It is hard to tell the difference between "Joe Closet Company" and Fortune 500.

    Not to be negative but, if you’re proud of what you have done... Why not say who you have done it for? It is frustrating for me (and possibly others) to read comments about how everyone uses Open Source yet never wants to say where what product name and the real results.

    This is not a challenge. This is just a basic request that anyone who wants to boast about how great his or her system is at least tell us what it is and who is running it. (Company name at least!)

    Tim your success story sounds great! I would love more details about the company, the software project, and some insight into the team who helped deploy it.

    Greg Peres
    Rogers Communication Inc


    Reply to this Reply to original

  16. Five reasons against migrating EJB applications to .NET[ Go to top ]

    You don't think this '$0' stack doesn't cut it?

    I've been working on a project for Cingular Wireless.

    An internal app was built for National Application Availability.

    This system is rock solid and out performs many of the other solutions that they've been using from other '$$' stacks.
    Reply to this Reply to original

  17. Five reasons against migrating EJB applications to .NET[ Go to top ]

    "Apart from oracle which we pay for, we are running an on the "$0" stack. "

    <falls off chair>

    So apart from the (several thousand dollar database), which is 80% of your scalability bottleneck, you're $0? Never, ever, ever, go into accounting, Tim.

    "24 x 7 uptime, and we're talking 100s of $1000000 revenue. "

    Really? So it's been up 24x7 for how long? And hundreds of millions directly from this implementation? Must be a popular business.
    Reply to this Reply to original

  18. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Stu,
      You need to read what he wrote including the ""'s. He said he is only paying for the db. And if I have to pay for something - that is what I would pay for. Unless you get an enterprise edition - dbs can be gotten for less than a few K.

    That is the beauty of Java and the tools surrounding it. You can build a system that uses "$0" parts (see the quotes?) and replace pieces with expensive stuff if you or the client feels comfortable forking over money to a big vendor. I would rather have the client give me a little more and keep a little for themselves.
    Reply to this Reply to original

  19. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Hi Stu-

    <quote>
    "Apart from oracle which we pay for, we are running an on the "$0" stack. "

    <falls off chair>

    </quote>

    I hope you didn't hurt yourself. Yes it's real.

    <quote>
    So apart from the (several thousand dollar database), which is 80% of your scalability bottleneck, you're $0? Never, ever, ever, go into accounting, Tim.
    </quote>

    It's interesting you have this magical ability to determine the performance bottlenecks in our system without knowing anyting about it.
    Do you use tarot as a debugging tool? If so it sounds very interesting.
    Thanks for that, next time we have a scaleability problem we will be sure to consult you.


    <quote>
    "24 x 7 uptime, and we're talking 100s of $1000000 revenue. "

    Really? So it's been up 24x7 for how long? And hundreds of millions directly from this implementation? Must be a popular business.
    </quote>

    Yes, it's a popular business. In fact, it's the UK's largest internet wholesaler.
    We've just released a new phase of the project, (JBoss 3) (prevously 2.4.3)
    How long is it up for.
    Well, with hot deploy we don't have to restart jboss, let alone reboot the linux servers.
    Doing a quick "uptime" on the servers gives me:

    [hidden_forsecurity@hidden_forsecurity hidden_forsecurity]$ uptime
      7:20pm up 221 days, 2:33, 1 user, load average: 1.01, 1.00, 1.00

    I hope that answers your question.

    Now I suggest you get back off your chair, and get back on your seat.
    Reply to this Reply to original

  20. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <quote>
    ...Now I suggest you get back off your chair, and get back on your seat.
    </quote>

    Burn (!)
    Reply to this Reply to original

  21. Five reasons against migrating EJB applications to .NET[ Go to top ]

    In response to Tim,

    "It's interesting you have this magical ability to determine the performance bottlenecks in our system without knowing anyting about it. "

    I know your system is an e-commerce site. E-Commerce sites exhibit pseudo-random reads and writes, and are read-mostly. Typically are concurrent I/O bound, and hence have bottlenecks in the database. Tuning the application server certainly can help performance, but the database is usually the prime determinant.

    Hence why I'm suggesting that you don't have a "$0 stack". You have a $40,000+ stack because Oracle is doing most of the work.

    "Doing a quick "uptime" on the servers gives me: [hidden_forsecurity@hidden_forsecurity hidden_forsecurity]$ uptime
      7:20pm up 221 days, 2:33, 1 user, load average: 1.01, 1.00, 1.00

    I hope that answers your question. "

    The uptime of your operating system says nothing about the uptime of JBoss.
    Reply to this Reply to original

  22. Five reasons against migrating EJB applications to .NET[ Go to top ]

    I have found management often do not like the 0$ option becuase it takes away the ability to shout and assign blame to vendors.

    Take away the vendor who you are paying money to and when there are problems you may have to take responsibilty and fix them.

    ;-)







    Reply to this Reply to original

  23. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <quote>
    Take away the vendor who you are paying money to and when there are problems you may have to take responsibilty and fix them.
    <quote>

    In my experience management does not like "$0 option" because they believe the old truism of "you get what you pay for" (yes, I know there are exceptions). $0 option often entails inferior or absent management and productivity tools, less documentation, no support, etc.

    As an application developer, I would rather deal with problems in my work and let my infrastructure vendor "take responsibility and fix them" in theirs. Why would such division of labor be a bad thing?

    Boris
    Reply to this Reply to original

  24. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Such a division of labor is actually a good thing. The bad thing is that products are bought for the right reasons but do the wrong job.

    Just look at some so called "Content Management Systems" or "E Business Applications" that - in my experience - often take very long to learn and offer only limited benefit.

    On the other hand, I find it almost laughable that a lot of so called software developers end up considering very primitive open source frameworks the silver bullet of software development by some.

    In the end I want the tools that I can be most productive with. You're absolutely right. But more often than not with tens-of-thousands-of-euros tools, the most productive tasks are in calling the support that - unfortunately - can not help.
    Reply to this Reply to original

  25. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <Q>
    Why would such division of labor be a bad thing?
    </Q>

    It is the implementation that is bad. What if the vendor can't, won't, or doesn't have time to fix it? (This happens way to often). What if the vendor is disappears? (Happens way to often) Choose your open source tools carefully. OS supporters seem to be more responsive to fixing things and adding functionality. And if they can't get to it and you need it - do it yourself. Sounds like a Win-Win to me. Plus, even though it is the 'vendors' problem - it still makes you look bad. And if chose closed tools - you can't fix it.
    Reply to this Reply to original

  26. Five reasons against migrating EJB applications to .NET[ Go to top ]

    What is premise this article is based on.

    How is .Net more advanced than J2EE. Why would someone want to migrate from J2EE to .Net. I am totally lost here. I understand that .Net is much more advanced with respect to Web Services but J2EE is catching up. But Web Services has not taken up as much as expected except for the hype in the last couple of years. Could someone point to me the need that anyone would consider moving from J2EE to .net especially they already have a multi-tier distributed application laid out in J2EE
    Reply to this Reply to original

  27. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Does anybody think of SUN new offering?

    Sun one 7.0 App server – free (need to buy support I think that is fine with lot of companies).
    MY SQL server (fully supported by SUN)
    Forte for Java (free if you buy the App server support).

    I think, This is good offer and we are in a serious evaluation phase to select SUN ONE solutions for our next project. We don’t have to pay ton load of money to IBM/BEA to get their software even for development. I think the SUN ONE plan will definitely change the high prize J2EE App market!!!!

    Hay SUN even has planned to offer LINUX based corporate desktop to stop paying tax to M$.
    Reply to this Reply to original

  28. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Tim, I am well awake.

    And what I am talking about are stock exchanges, banks, airlines, telcos, large manufacturing and other high-volume, mission-critical customers.

    You can probably run J2EE reference implementation and be happy, until you need to provide uninterruptable service with failover and session persistence across a cluster.

    Or, when you need to interoperate with COM, MQ Series, CORBA, Tuxedo, COM+, or anything else out-of-the-box.

    Or, when you need to scale.

    Or, when you need a two phase commit over serveral resource managers like DB2, MQ, Tux, and something else that I can't even type with this font.

    Or, when you need a highly reliable clustered JMS with distributed fault-tolerant destinations, durable subscribers, message persistence, and other non-J2EE options.

    Or, Web Services - I am not talking about just supporting SOAP and WSDL, but the whole infrastructure with JAX-RPC, custom data types, asynchronous message-style Web Services (not just basic RPC), interoperability with .Net, and so on

    Or, when you want to use open management interface to the application server so you could control it from your other applications programmatically...

    Want more? Here you are...

    The recent ECperf has shown that the price of application server in the whole real world application is small... The most of it is hardware, database, networking, support (don't tell me that your $0 stack comes with free support as well - that's BS. You either paying to your internal people, or to a vendor).

    Hope it makes it clearer,

    George
    Reply to this Reply to original

  29. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Sigh.. another FUDmeister troll... Ok, where do we start...

    <quote>
    And what I am talking about are stock exchanges, banks, airlines, telcos, large manufacturing and other high-volume, mission-critical customers.
    </quote>

    Yes, plenty of these use the $0K stack in production. If in doubt, please ask jboss for some references.

    <quote>
    You can probably run J2EE reference implementation and be happy, until you need to provide uninterruptable service with failover and session persistence across a cluster.
    </quote>

    Who says I'm running the sun ri implementation? Don't be silly now.
    Yes, I have failover, clustering etc. etc. out of the box. Next question?

    <quote>
    Or, when you need to interoperate with COM, MQ Series, CORBA, Tuxedo, COM+, or anything else out-of-the-box.
    </quote>

    Sigh... yes I can interoperate with most of the above straight out of the box (jboss). Any more FUD George?

    <quote>
    Or, when you need to scale.
    </quote>

    My system scales very nicely thanks.

    <quote>
    Or, when you need a two phase commit over serveral resource managers like DB2, MQ, Tux, and something else that I can't even type with this font.
    </quote>

    Oh dear George, you should really check your facts before you post. I have full support for XA transactions. What's your point?

    <quote>
    Or, when you need a highly reliable clustered JMS with distributed fault-tolerant destinations, durable subscribers, message persistence, and other non-J2EE options.
    </quote>

    We use JMS at the core of our system. (JBoss implementation). Yes it has durable subscribers, message persistence etc. etc. and yes it's free. George, this is getting tiresome.

    <quote>
    Or, Web Services - I am not talking about just supporting SOAP and WSDL, but the whole infrastructure with JAX-RPC, custom data types, asynchronous message-style Web Services (not just basic RPC), interoperability with .Net, and so on
    </quote>

    When I find a reason for using web services I'm sure I will use them. When that time comes they will be ready for me to use.

    <quote>
    Or, when you want to use open management interface to the application server so you could control it from your other applications programmatically...
    </quote>

    Sorry to disappointment you George, but I've got one of those too. JBoss is ENTIRELY built on a JMX skeleton.
    If you don't know what JMX is I suggest you look it up on java.sun.com

    <quote>
    Want more? Here you are...

    The recent ECperf has shown that the price of application server in the whole real world application is small... The most of it is hardware, database, networking, support (don't tell me that your $0 stack comes with free support as well - that's BS. You either paying to your internal people, or to a vendor).
    </quote>

    Not for us George:
    Hardware costs: 3-4K per webserver. 4-5K per db server. all raid 0/1. (This is peanuts)

    Networking - this comes under our contract with our hosting provide, who also provide the (very) fat pipe we require. A few 10s of K per month.

    Support goes something like this:
    1. RTFM (Solves 70% of problems)
    2. Search through the forums and bug lists (solves 80% of problems)
    3. Check out the source code (solves 90% of problems)
    4. Post message on forum. Get it answered by one of the people who actually wrote the software. (Aside - can you imagine phoning the weblogic tech support call centre, and the lead developer answering the phone? LOL! But, hell you pay for your support, so you'd prefer to be speaking to Joe Schmo high school dropout.) - (Solves 99% of problems)
    5. Fix code yourself, since it's a known problem but isn't going to be released in time. ( Solves 99.99% of problems)
    6. Too stupid to fix code yourself (are you surprised?), so phone up JBoss who supply member of core team to fix problem in exchange for some dollars (not that many though). (Solves 100% of problems)
    BTW we have never ever had to do 6).


    <quote>
    Hope it makes it clearer,
    </quote>

    As a muddy pool George, as a muddy pool.
    Reply to this Reply to original

  30. Five reasons against migrating EJB applications to .NET[ Go to top ]

    why are you talking about the price for software...
    for example you paid for the license of WebLogic 10 000$ and also you paid to administrator ~ 80000$ each year, actually more because of 1 admin is not enough in most cases, so the price for software it's just 10% or less of expense.

    Thx.
    Reply to this Reply to original

  31. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Profit is not calculated on some "Total Cost of Ownership" number. Profit is calculated in the margins. A really good profit margin in most industries is 20%. A more typical one is between 5% and 10%. So, if you save 10% on production costs, you double your profits! That's huge on the final balance sheet.
    Reply to this Reply to original

  32. Five reasons against migrating EJB applications to .NET[ Go to top ]

    http://www.tpc.org/
    Reply to this Reply to original

  33. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Database Architecture: Federated vs. Clustered

    -- Igor
    Reply to this Reply to original

  34. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Thanks, Jayesh,

    resume from brief scan of results/prices:

    MS products are rather unexpensive
    2000 server (IIS include ?) == 2-3K purchase and part
    of server license (6K in 3Y)
    Linux70pro == 180 purchase and
    5K - 3y maintainance (!!!!)
    WebSphere 30K
    SQL Server 6-15K
    Oracle EE 50-100K for 16 CPU (5Y)
    DB2 - 16-17K per CPU

    performance/price for 100G databace dominated
    by MSSQL+Win2000, above 1000G _only_ Oracle and DB2.

    In general, MS packages are leaders in low-end
    tasks (low - relatively speaking). In high-end
    there are more Oracle, IBM, Sun.

    There are only MS based results in
    TCP-W (web, e-comerce). Looks like j2ee
    does not like TCP at all.

    AlexV.

    Reply to this Reply to original

  35. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Hi Alex!

    > SQL Server 6-15K
    > Oracle EE 50-100K for 16 CPU (5Y)

    Hmm... Why are you comparing MSSQL with Oracle running on 16 CPUs? I wonder how you can run MSSQL on 16 CPUs at all? I did not know Intel based platform + Windows supported that many CPUs. And, by the way, one of the major advantages of Oracle is the ability to efficiently utilize multiple processors when running a sigle SQL query.

    Sergey.
    Reply to this Reply to original

  36. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Hmm... Why are you comparing MSSQL with Oracle running on 16 CPUs? I wonder how you can run MSSQL on 16 CPUs at all?


    Hi Sergey,

    SQL Server runs great not only at 16 but also on 32 processor machines... A recent TPC-C result: a single NEC machine with 32 Itanium 2 got very close to the top TPC-C result for non-clustered benchmarks. A quote from CNET below:

    "A $4.6 million NEC server using Microsoft Windows has grabbed high marks in a closely watched performance ranking traditionally dominated by machines running the Unix operating system.

    The fifth-place ranking on the Transaction Performance Council's TPC-C speed test is an important step in Microsoft's years-long struggle to have its software used not only on PCs and low-end networked "server" computers, but also on high-end machines. Such servers often handle vital corporate computing tasks, such as tracking inventory or managing bank accounts.

    Expensive, high-end servers typically come with higher profit margins and often include sales of services and software. But these servers, sold by companies such as Sun Microsystems, IBM and Hewlett-Packard, usually run the Unix operating system, not Windows.

    NEC dented that Unix dominance with its $4.6 million TX7/i9510 system using 32 of Intel's new Itanium 2 processors. While the price tag might sound steep, it's a bargain compared with the top-ranked Fujitsu PrimePower 2000 server. This gargantuan Unix server comes with 128 processors and a $12 million price tag--and a 50 percent better score than the NEC machine"

    http://news.com.com/2100-1001-957226.html?tag=fd_top

    http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=102090902

    Thanks, Adi
    Software Design Engineer, Microsoft Corporation

    P.S. My views here are not necessarily Microsoft's official position.
    Reply to this Reply to original

  37. Five+ reasons against migrating EJB applications to .NET[ Go to top ]

    <quote>
    The fifth-place ranking on the Transaction Performance Council's TPC-C speed test is an important step in Microsoft's years-long struggle to have its software used not only on PCs and low-end networked "server" computers, but also on high-end machines.
    </quote>

    Adi,

    A $4.6 mil NEC server using Microsoft Windows at 308,621 tpmC. Good result indeed.

    Oracle beats it easily though with 423,414 tpmC and total cost of the system at $6.6 mil on HP hardware. I’d be interested to see Oracle’s figures with Intel chips on Linux, Oracle may beat its own record. One also has to consider that SQL Server runs only on Windows and for many IT managers this is not an acceptable deployment platform, especially for mission-critical applications.

    -- Igor
    Reply to this Reply to original

  38. Five reasons against migrating EJB applications to .NET[ Go to top ]

    I've had it. It sickens me to see Microsoft turn this J2EE discussion board into an advertisment for their products. Microsoft, PLEASE GO FIND SOME OTHER SITE TO TERRORIZE, and leave us alone. I don't care about your products, even if they are 'better' than J2EE. I would not use them even if they were.

    To this site, can we get rid of the J2EE vs. .NET threads? This is really pointless and only presents Microsoft yet another opportunity to spread it's disinformation.

    It is CLEAR that Microsoft will stop at NOTHING to crush Java/J2EE. Lets not make it easier for them to do so.

    Mike
    Reply to this Reply to original

  39. Five reasons against migrating EJB applications to .NET[ Go to top ]


    Great idea. thats what Javalobby did, and its now a completely uninteresting place with very low activity. I had learned many things in the discussions on TSS and I do really hope that it will continue to exist in its current form.

    MS people pop up now and then in various lists but how is it that the never are anybody from Sun who participate in any debate? You can be sure that they are not afraid to do so..The reason is spelled "arrogance".

    Regards
    Rolf Tollerud
     
    Reply to this Reply to original

  40. Five reasons against migrating EJB applications to .NET[ Go to top ]

    It might have cost Microsoft $4.6M, but I can't buy one for any price
    Reply to this Reply to original

  41. It is Microsoft who keeps the prices down[ Go to top ]


    Hi Alex, some more info for you.
     
    Comparison 1

    1 x 8-CPU Application Servers to Host Web Services running Windows 2000 Advanced Server with .NET Framework @ $3999.00 per server + 1 Internet Connector License @ $1,999 per server:
    $5,998

    1 x 8-CPU Application Servers to Host Web Services running IBM WebSphere 4.0 Advanced Single Server Edition (on Solaris, W2k Or AIX) @ $8,000 per CPU:
    $64,000

    **********************************************

    Comparison 2

    4 x 8-CPU Application Servers to Host Web Services running Windows 2000 Advanced Server with .NET Framework @ $3999.00 per server + 4 Internet Connector Licenses @ $1,999 per server:
    $23,992
     
    4 x 8-CPU Application Servers to Host Web Services running IBM WebSphere 4.0 Advanced Edition (on Solaris, W2k or AIX) @ $12,000 per CPU:
    $384,000

    www.gotdotnet.com/team/compare/webservicecompare.aspx
    www.gotdotnet.com/team/compare/ibmrespond.aspx

    Regards
    Rolf Tollerud
     
    Reply to this Reply to original

  42. It is Microsoft who keeps the prices down[ Go to top ]

    Comparison 1 ...

    The problem with these comparisons is that Websphere provides much more functionality than does the MS implementation. WAS AE is overkill for what you can only do in the MS implentation. You will need to go down to the cheaper WAS version or something like Tomcat.


    Now run the comparison on Linux - Oh, you can't.
    Reply to this Reply to original

  43. It is Microsoft who keeps the prices down[ Go to top ]


    Mark,

    "You will need to go down to the cheaper WAS version or something like Tomcat"

    So? Don't forget with .NET you also get:
    8 times faster performance, 4 times less code base, and 2 times more productivity..
    Can Tomcat give you that?

    (Assuming IBM WebSphere 4.0 Advanced Edition with EJB/CPM)

    Regards
    Rolf Tollerud
     
    Reply to this Reply to original

  44. It is Microsoft who keeps the prices down...right[ Go to top ]

    Rolf:

    "8 times faster performance, 4 times less code base, and 2 times more productivity.. "

    Prove it.

    And don't try to use that old .Net Petstore crap. If I move everything into stored procs (maintenance nightmare, tied to a DB vendor) and don't use proper exception handling, I can probably have 4 times less code and 8 time faster performace in a J2EE app. Off course being able to make bad code 2 times as fast as proper code is of dubious value anyway....

    BTW, can it run on *nix system [i]PRODUCTION READY[/i]?

    And don't say "Mono" and those kinds of projects...they might be able to compile themselves, but even if they ever get to production quality (which they are not close to), they will not support the ENTIRE .Net runtime...that's only on Windows.

    Just so you know, using JBoss/Apache/Tomcat with DB of your chioce, is very production ready, cross-platform (even on Windows!) and much cheaper than .Net...


    Enough with the FUD.


    Reply to this Reply to original

  45. It is Microsoft who keeps the prices down...right[ Go to top ]


    Mike,

    "Prove it"

    Sorry, it have already been proved. And if you think that Mono is not going to finish you will be very much mistaken. .NET is an open ECMA standard with an Open Source implementation - more than you can say about Java.


    Regards
    Rolf Tollerud
     
    Reply to this Reply to original

  46. It is Microsoft who keeps the prices down...right[ Go to top ]

    Rolf
      Here are 3 questions ?

      The current comparison between the petstores were :

      .net petstore used stored procedures.
      java petstore used java data layer.

    #1)
    If someone rewrote the java pet store to use stored procedures do you think this we more or less correct than the original performance comparison ?

    #2)
    Better yet if someone ported the .net petstore to java, and used equiavlent technologies do you think that would be a more or less accurate performance comparison than the original ?

    bonus question ?
      Do you want a true head to head technology comparison ???
      I know I do!

      JSP vs ASP. Storeprocedure vs storedprocedure.
      Remoting Vs EJB
      C# language feature Vs Java Language features
      CLR vs JVM


    From my perspective, when microsoft puts out these apples to oranges comparisons, it denegrades the product they have produced. It also forces me to 'read the fine print' on everything they produce. And now, I have to sit down, and actually do my own BASIC bechmarks becuase the one's MS produces are virtually useless. Work I should NOT have to do ! Very frustrating.





      


    Reply to this Reply to original

  47. It is Microsoft who keeps the prices down...right[ Go to top ]

    A Pet Store from the Open Source Community

    -- Igor
    Reply to this Reply to original

  48. It is Microsoft who keeps the prices down...right[ Go to top ]


    Robert,

    Thank you for arguing without degrading to Slashdot level.

    Your observations and arguments are correct, if someone rewrote the java pet store to use stored procedures the performance would probably approximate something similar to MS .NET Petshop. IMO.

    But unless others, I think that the Java Petshop example was programmed correctly, assuming 2000-5000 simultaneous users. Utilizing EJB makes the performance initially to take a hit, but after it scales much better.

    The fact that the .NET Framework can handle 2000-5000 simultaneous users without any special treatment like serviced components or other tricks makes everything a lot easier. How it is done or why it is so I can not explain. It just works as everyone can verify by downloading and testing on their own computers.

    So it is not practical to program Java in the same way as .NET in this important middle segment of the market.

    To compete with .NET Java has to come up with some simple and practical replacement for EJB.

    Regards
    Rolf Tollerud
     
    Reply to this Reply to original

  49. It is Microsoft who keeps the prices down...right[ Go to top ]

    <q>
    The fact that the .NET Framework can handle 2000-5000 simultaneous users without any special treatment like serviced components or other tricks makes everything a lot easier. How it is done or why it is so I can not explain. It just works as everyone can verify by downloading and testing on their own computers.
    </q>
    Now that's the type of explanation I like - easy to understand, no confusing technical details, and correctly pitched at the average forum reader's intellectual level. Indeed the plentiful amount of free time that we all have is also correctly predicted so that the inquisitive among us can did deeper if they wish.

    Quality!
    Reply to this Reply to original

  50. It is Microsoft who keeps the prices down...right[ Go to top ]

    Hi, Julian Coombes,

    MS will be sarcazmitized (sic-?) here if they
    do provide details and if they does not.
    Just imagine yourself responce in some ms-
    oriented group to some detailed ejb
    explanation (for example why the same field
    can not be simultaneously in CMR and CMP)

    Rolf Tollerud,
    BTW, "2000-5000 simultaneous users" -
    what is this? requests per second?
    simultaneous threads?

    <quote autor="Sergey Tavanets">
    Hmm... Why are you comparing MSSQL with Oracle running on 16 CPUs? I wonder how you can run MSSQL on 16 CPUs at all?
    </quote>

    I do not, just discovered (for myself) big
    picture of server economics. Apart from separate
    stability/security issues, MS stacks are
    looking not bad in relatively low-end
    areas.

    AlexV.
    Reply to this Reply to original

  51. It is Microsoft who keeps the prices down...right[ Go to top ]

    <quote>
    if someone rewrote the java pet store to use stored procedures the performance would probably approximate something similar to MS .NET Petshop
    </quote>
    I assume the same order of magnitude.

    <quote>
    I think that the Java Petshop example was programmed correctly, assuming 2000-5000 simultaneous users. Utilizing EJB makes the performance initially to take a hit, but after it scales much better
    </quote>
    I don't think so: Given enough physical memory (to avoid the need for activation/passivation of sessions), a non-EJB application should scale nicely.

    <quote>
    The fact that the .NET Framework can handle 2000-5000 simultaneous users without any special treatment like serviced components or other tricks makes everything a lot easier (...) To compete with .NET Java has to come up with some simple and practical replacement for EJB.
    </quote>
    Here you are, a replacement for Session Beans: Components not serviced by the container, without method interception for transaction and/or security control, and without activation/passivation: plain Java objects, stateless (used as singletons or via static methods) or stateful (used in HttpSessions, wisely programmed to keep as little state as possible).

    Juergen
    Reply to this Reply to original

  52. EJB & COM+ performance[ Go to top ]


    Jonathan,

    Remember that C# is just Java under another name. In practice, Java has been forked. There is only ca 5% of C# which is not Java, mostly things that JCP was planning anyway. But the library is completely different..

    The reason that Java was forked is the same as when other project that was forked, mismanagement - in this case by Sun.

    I don't know which framework that will prevail, J2EE or .NET but even if the .NET "wins" it is still with the original ideas and visions from Java..

    *************

    Juergen,

    "I don't think so: Given enough physical memory (to avoid the need for activation/passivation of sessions), a non-EJB application should scale nicely."

    If you say so. When I look at the test results from Nile (http://www.gotdotnet.com/team/compare/nileperf.aspx), it seems to confirm your statement. There is very little difference with or without EJB. I always have been under the impression that EJB is necessary for large scale apps.

    Likewise, another strange thing is that Microsoft did not show any test results with .NET Serviced Components. Could it be that neither EJB nor COM+ adds anything to performance?

    Regards
    Rolf Tollerud
    Reply to this Reply to original

  53. EJB & COM+ performance[ Go to top ]

    <q>
    If you say so. When I look at the test results from Nile (http://www.gotdotnet.com/team/compare/nileperf.aspx), it seems to confirm your statement. There is very little difference with or without EJB. I always have been under the impression that EJB is necessary for large scale apps.

    Likewise, another strange thing is that Microsoft did not show any test results with .NET Serviced Components. Could it be that neither EJB nor COM+ adds anything to performance?
    </q>

    There is of course another funny thing. The sources for the .NET version can be downloaded, but the javasources cannot.
    Reply to this Reply to original

  54. It is Microsoft who keeps the prices down...right[ Go to top ]

    <q>
    Your observations and arguments are correct, if someone rewrote the java pet store to use stored procedures the performance would probably approximate something similar to MS .NET Petshop. IMO.
    </q>

    As you can see earlier in this thread, has been done, but without the stored procedures.

    <q>
    take a hit, but after it scales much better.
    </q>
    Isn´t that the whole purpose of higly available, highly scalable platforms ??

    <q>
    So it is not practical to program Java in the same way as .NET in this important middle segment of the market.
    </q>
    Why ?? Don´t middle segment companies want to grow without having to rewrite everything ??

    <q>
    To compete with .NET Java has to come up with some simple and practical replacement for EJB.
    </q>
    I can´t think of anything more simple than CMP/CMR entitybeans. Hardly any coding required.
    Reply to this Reply to original

  55. It is Microsoft who keeps the prices down...right[ Go to top ]

    <Q>
    .NET is an open ECMA standard with an Open Source implementation
    </Q>

    .NET is an ECMA Standard? I'm aware that C# is an ECMA Standard, but .NET, MS' technology line?
    Reply to this Reply to original

  56. It is Microsoft who keeps the prices down...right[ Go to top ]

    ".NET is an open ECMA standard ..."

    Well, this is not true. Only a (relatively small) part of .NET is an ECMA standard. Major APIs are NOT standardized at all:

     - Windows Forms
     - ADO.NET
     - ASP.NET
     - Web Services
     - Serviced Components
    Reply to this Reply to original

  57. It is Microsoft who keeps the prices down...right[ Go to top ]

    Rolf,

    you're being very naive!

    Do you really believe that .NET is an open ECMA standard and that the Java platform is less open??


    I did a little research on ECMA website and guess what:
    -Indeed C# is submitted a as standard:
     http://www.ecma.ch/ecma1/STAND/ecma-334.htm

    -The CLI is also submitted as a standard:
     http://www.ecma.ch/ecma1/STAND/ecma-335.htm

    What it states is that C# and all its semantics are standard. The virtual machine (CLI) and merely a set of BASIC class libraries are also standard.

    The above does not cover .NET at all!!

    In reality, a virtual machine and a programming language do not change often (eg. look at Java, JVM) because it would break compatibilty. But the libraries and API's undergo many changes overtime.

    API's are the most important tools a developer has to get its work done. A language and a VM with just a basic sets of support classes enable you to do ZIP!

    Now let's look at .NET and Java.

    Who developes, maintaines the .NET API's (except for the ECMA stuff)? Microsoft
    Who creates the development tools, IDE,...? Microsoft
    Who developed the deployment environment in which your enterprise stuff will "live"? Microsoft

    Is there made a clean separation between key components which enable other parties to reimplement them? No
    Has every key .NET component/infrastructure a public specification? No

    Other people could probably add more points to list.

    When I look at java every API is developed through the Java Community Process resulting in SPECIFICATIONS that EVERYONE can implement and where everyone can participate in.

    So don't tell me that .NET is an open standard!

    Regards,
    Ivan Melotte


    Reply to this Reply to original

  58. It is Microsoft who keeps the prices down...right[ Go to top ]

    Rolf

    <quote>
    So? Don't forget with .NET you also get:
    8 times faster performance, 4 times less code base, and 2 times more productivity..
    </quote>

    Sorry old son, it hasn't been proven as you have said. In any way, shape or form. Show me a real head-to-head enterprise application where that is the case. You can't. All you do is quote microsoft fluff which may work with microsoft devotees but not for most on this list.

    Cheers
    Ray
    Reply to this Reply to original

  59. It is Microsoft who keeps the prices down...right[ Go to top ]

    <Q>
    <quote>
    So? Don't forget with .NET you also get:
    8 times faster performance, 4 times less code base, and 2 times more productivity..
    </quote>

    Sorry old son, it hasn't been proven as you have said. In any way, shape or form. Show me a real head-to-head enterprise application where that is the case. You can't. All you do is quote microsoft fluff which may work with microsoft devotees but not for most on this list.
    </Q>

    Now if they would throw in a Color TV (Flat panel) I'm sold![not]

    Reply to this Reply to original

  60. It is Microsoft who keeps the prices down...right[ Go to top ]

    <quote>
    "Prove it"

    Sorry, it have already been proved. And if you think that Mono is not going to finish you will be very much mistaken. .NET is an open ECMA standard with an Open Source implementation - more than you can say about Java.
    </quote>

    Proved where ?? Petstore ?? Get serious. Petstore is a blueprint app to show what can be done in J2EE. It´s probably not even scalable, and does thins even SUN indicates is BAD such as:

    String a = "";
    a += ".";
    a += "NOT";

     
    Reply to this Reply to original

  61. It is Microsoft who keeps the prices down[ Go to top ]

    <quote>
    Don't forget with .NET you also get:
    8 times faster performance, 4 times less code base, and 2 times more productivity..
    </quote>

    ...and 10 times the stored procedures....
    Reply to this Reply to original

  62. It is Microsoft who keeps the prices down[ Go to top ]

    <quote>
    So? Don't forget with .NET you also get:
    8 times faster performance, 4 times less code base, and 2 times more productivity..
    Can Tomcat give you that?
    </quote>

    You´ve got any proof of that besides the petstore thing ?? I really want to see .NOT performing 8 times faster.
    Reply to this Reply to original

  63. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Not only that, in addition to the points all of you guys mentioned.
     Some time internal IT team have to spend 24/7 in front of server and send code to back to seattle. In my last two years I am at my third client place where IT head said "Good Bye " to Microsoft cuz of its ugly style when it come to enterprise applications. Guys if you wanna write application to host your home website may be IIS and ASP will be good. Don't even waste your time and money into that crap!!!.
      
    Reply to this Reply to original

  64. Five reasons against migrating EJB applications to .NET[ Go to top ]

    It is always amazing to me that people choose to talk about .net and they have absolutely no knowledge of .net. you should be embarrased.
    Reply to this Reply to original

  65. Five reasons against migrating EJB applications to .NET[ Go to top ]

    At last some sensible even-handed contribution.

    I too have worked with both as an architect and found very little reason to get worked up about either option. The Java/Oracle vs Msft/SQL Server vs WSphere/DB2 costs are in the same ball park. In both environments a bad developer can cost the company far more than the difference in server licences. The Msft studio tools are easier to get started with and cheaper than Borland Java (enterprise) but once you have the basic framework built, the development costs converge. A great developer will more than compensate for any differences in productivity of tools.

    Long may both option thrive.

    Another...

    Jonathan
    Reply to this Reply to original

  66. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <Q>
    It is always amazing to me that people choose to talk about .net and they have absolutely no knowledge of .net. you should be embarrased.
    </Q>

    For those who this is true - it is true. But who are you talking about?

    The same could be said for those who talk about Java and have not clue.

    And even worse those who really no nothing about Java or .Net.
    Reply to this Reply to original

  67. Five reasons against migrating EJB application .. (corrections)[ Go to top ]

    [Sorry - mind is faster than fingers.]
    ... have not a clue.

    ... really know nothing ...
    Reply to this Reply to original

  68. Five reasons against migrating EJB application .. (corrections)[ Go to top ]

    Hi All,

    I dont care about EJB, since our web applications really doesnt need EJB

    and our clients are not ready to buy App Servers. (Even Gartner Report

    says 60-70% of the so called J2EE Applications developed till now all

    over the world use only JSP. Rest of the 30-40% only are in EJB).

    Without EJB we developed nearly 5-6 Web Products full of JSP only without

    any framework. Now weve seen ASP.NET and developed few Mobile

    Applications and Web Applications in ASP.NET.

    1. Our Mobile Application developed in ASP.NET and deoployed in IIS 6

    with Mobile Tool Kit can be viewed in more than All Handsets

    (Keep in mind no mobile application will be like c/server ERP app's)

    How long will it take for Sun and others to give such a Framework or

    something (Mobile Tool Kit) and a Free Server (like IIS). Another 5 Years

    ?

    2. We are able to develop ASP.NET Web Services in no time. And we

    deployed for production also. We are able to use it in Java with AXIS.

    How long will it take for Sun to give ASMX like pages. Though AXIS is

    there, Y Sun is not using it. Even it didnt support Struts also. But come

    out with JSF with same functionality.

    3. We are able to develop ASP.NET projects as fast as ASP OR JSP or Even

    an Windows Application or Java Application using the Controls.

    JSF has no way comparable with ASPX HTML Controls. Will Sun take another

    1 year to develop such controls. Even JSF will take another year for

    release.

    4. ASP.NET Server Controls like DataGrid have minimised the development

    of web projects drastically.

    Will Sun gives such a Server Control atleast within a Year.

    5. ADO.NET gives back the table data itself as XML and the Disconnected

    DataSets will definately be useful.

    Can we think of anything in near future from Sun.

    6. Custom UI Controls can be developed in no time.

    Sun, Did u heard about anything like this.

    7. .NET is not available for Linux.

    Beware, www.mono.org will give the answer within 3 to 6 months.

    Im asking, Apache is only for Java Development. Y dont Apache get in to

    .NET and develop a C# Compiler, .NET CLR, and other libraries for Linux

    in Open Source. If they get into it, they can do the things within 3

    months time, with the help of Such a big community support. Y not Apache

    Team think about it.

    8. Support for Oracle, SQL Server, and other OLEDB based DB's are

    supported in .NET or even the DB Vendors are releasing their own Data

    Providers for .NET. Ex: Oracle Data Provider for .NET

    9. Multiple language Support. Definately in big organisations, VB

    developers, C++ developers and new to MS developement from Java guys like

    us can learn within few days C# and get in to .NET development. They

    individually can develop the libraries. But can be used, utilising the

    entire developer resources without the barrier of language.

    Sun is not able to support Java itself. They are so busy people.

    10. ASP.NET application are really faster than JSP.

    Still and even after 2 or 3 years also, Sun cannot give a JVM without

    Memory Leak.

    Its upto u to decide. Java guys dont get angry on me. Cos, Its my

    experience ive wrote here. Im not blaming others. Bye

    Thanks,
    Sankar.B
    Informatin Dynamics
    Reply to this Reply to original

  69. Five reasons against migrating EJB application .. (corrections)[ Go to top ]

    Hi Sankar,
     
    this sums up what loads of folks will experience. Under ms .Net you have a fixed set of tools. You can quote a specific example of what works, and the entire ms community will understand what you mean. And most will have used the same set of tools.

    But, the java community will have many folks who have something just as powerful or better, and it will run on any operating system, and it will be changing month on month in response to community comment.

    But there will be a huge section of the java community with no direct experience of these tools which fit your problem so well.

    The power of java from the developer point of view is choice. The weakness of java from the project point of view is finding which is the right choice.

    Or putting it another way, the Microsoft route is currently easier because there is less choice. My example would be ASP.NET v's [Struts, JSP, common tag lib, jakarta tab lib, cocoon, velocity god knows what].

    Jonathan

    Reply to this Reply to original

  70. Five reasons against migrating EJB applications to .NET[ Go to top ]

    "It is always amazing to me that people choose to talk about .net and they have absolutely no knowledge of .net. you should be embarrased. " - mccorney

    Bill is having the same problem and trying desperately to market it as the "black rocket."


    Reply to this Reply to original

  71. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Some corrections and counterpoints...

    I'd like to address several inaccuracies in Godfrey's article. But before I do, I'd like to take exception to his title. Microsoft is not keenly interested in motivating customers to take perfectly fine, working business applications in Java and move them to C# (or VB.NET, etc.). Instead, we offer a broad array of interoperation features, primarily based on Web Services. However, for those customers that want improved performance, higher productivity, and lower total costs, we offer several paths to migrate existing applications into the CLR.

    Now, on to Godfrey's inaccuracies:

    1. CLR does not support Java

    False. Microsoft offers the J# product for people that want to continue using the Java language syntax.

    Regarding interoperation, there are several alternatives, but a Java/COM bridge is not one of them. COM itself is superceded by the .NET CLR. If you are looking for wire-level interoperability, there are several third-party providers that offer RMI/.NET Remoting bridging products. Alternatively, you can consider features such as Message Queuing interop. However, in the long run, the standardized mechanism to achieve interop is through web services.

    Regarding porting Java code to C#. We offer this feature to those customers that want to port their products from Java to C#, and we will continue to improve that product over time, based upon feedback we get from our active communities and partners. Our next release will allow customers to migrate JSP pages into ASP.NET, Swing/AWT into Windows Forms, Servlets into C# classes, and EJBs into Serviced Components. Having said this, it should go without saying that ANY conversion from one platform to the next will require development resources to capitalize on the features of the new platform. While ArtinSoft may ultimately achieve 99% automated conversion, developers will still want to rewrite parts of the code to capitalize on the superior features in the CLR.

    2. IIS does not support JSP

    This is a bit of a red herring, as IIS isn't directly part of .NET, but I'll answer anyway :-)

    IIS supports JSP pages exactly the same way that Apache does. In IIS, it is supported through ISAPI extensions, in Apache, through modules. Similarly, IIS supports ASP.NET pages through a separate ISAPI extension worker process (aspnet_wp.exe, for those of you that want specifics :-).

    The core of the complaint in this bullet is that converting from JSPs to ASP.NET is challenging. While we certainly agree that there are a few challenges converting a JSP into ASP.NET, the rewards are significant: Massive performance improvements, greater development speed, and a far more logical, event-based approach that scales well. We are confident that, for customers that decide it is necessary to move JSPs into ASP.NET, the rewards will quickly outweigh the conversion investment.

    We encourage Java developers to look at the features of ASP.NET and judge for themselves. You can download our free WebMatrix tool at http://www.asp.net and see for yourself why we consider ASP.NET to be light-years ahead of JSPs.

    3. Server controls require redesign

    Godfrey again cites several potential impacts in porting JSP pages (and their backend supporting Servlets, taglibs, etc.) into ASP.NET. This is a good time to emphasize, once again, that Microsoft does not attempt to mandate conversion of these pages. Further, Godfrey states in his example that existing PL/SQL must be converted to Transact SQL to support DataGrid queries. This is not true. First, the DataGrid is disconnected from any database product whatsoever, you can use a DataGrid with any set of information that you bind to. Secondly, Oracle is natively supported in .NET through the Oracle Managed Provider, which is freely available through Microsoft. There is no need at all to sacrifice any PL/SQL stored procedures in your Oracle database. Again, our emphasis is on interoperability.

    4. No support for Container Managed Persistence

    Microsoft deliberately left out features similar to CMP in the first release of the .NET framework. We will be releasing a similar technology in the future, called ObjectSpaces, which will address these (and other) concerns. However, it's better to discuss distributed persistence in a broader context. We fully support distributed persistence through Serviced Components using COM+ (not to be confused with COM, which is not a part of .NET. My apologies for the confusion, you can blame it on our marketing people :-). COM+ allows developers to create objects that are distributed, transactional, and secure. More importantly, the mechanism works in a stateless mode, allowing more efficient use of scarce connection resources. So, while CMPs are not directly supported, the architectural functionality of CMPs is.

    5. Different session handling implementation

    Godfrey only speaks of one part of our session management approach. We provide three distinct ways to store session data for your application: in-process session state, out-of-process session state as a Windows service, and out-of-process session state in a SQL Server database. We also support session management techniques that look familiar to Java developers: Cookies, URL rewriting, and custom session state management.

    Conclusion.

    I hope my comments have helped somewhat. While we regard objective criticism in a positive manner, we want the development community to judge .NET on its own merits, not on hearsay or misinformation. I encourage each Java developer to spend some dedicated time evaluating .NET as a competitive alternative to the platform they are used to. As the old commercial goes, "Try it, you'll like it" :-)

    In closing, I'd like to say I definitely agree with Godfrey's final sentence: For companies that have performant, functional J2EE applications, please leave them right where they are. For those of you that want to extend functionality without abandoning your investment, consider using web services to integrate with legacy applications while developing in .NET. Finally, for those of you wanting significant leaps in productivity and performance... give .NET a try :-)

    David Weller
    Microsoft Java Community Evangelist

    Reply to this Reply to original

  72. Five reasons against migrating EJB applications to .NET[ Go to top ]

    David,

    I’ve always been told that the difference between a technology evangelist and a technology salesperson is that the evangelist actually believes what they are telling you. Based upon your response, I think you just blurred the distinction.

    >> False. Microsoft offers the J# product for people that want to continue using the Java language syntax.

    Really? Do you really think J# is the same as Java? Remember, we aren’t just talking about ‘Java’ the language but ‘Java’ the language, ‘Java’ the APIs and ‘Java’ the platform. I guess you carefully put the word 'syntax' in there.

    Here’s a simple test for you: try to import javax.net… Or anything in the javax space. Or maybe java.util.logging or java.nio. All of that there? Didn’t think so.

    Heck, if I want to use a very old version of Java, why not try J++? Or perhaps I can program on Mac OS 9 with JDK 1.1.8.


    >> 2. IIS does not support JSP . This is a bit of a red herring, as IIS isn't directly part of .NET, but I'll answer anyway :-)

    While I agree with your answer to this point, that IIS supports JSPs the same way other pure web servers do, the rest of your answer might as well have come straight from marketing. MASSIVE PERFORMANCE IMPROVEMENTS? Care to back that up with a benchmark? (And, please, don’t compare anything that uses stored procedures. I just want to see how well an ASP.NET page generates compared with a JSP page to show MASSIVE improvements in performance. I.e., anything to do with the Petstore has absolutely nothing to do with ASP.NET vs. JSP.)


    >>More importantly, the mechanism works in a stateless mode, allowing more efficient use of scarce connection resources. So, while CMPs are not directly supported, the architectural functionality of CMPs is.

    Stateless stateful components. Interesting trick. So, how exactly do you maintain the state across multiple pages? I thought Microsoft has abandoned in-memory database, heterogeneous stateful transactions, etc. Can you site any documentation that says otherwise?

    Besides, AFAIK, you can run EJBs in stateless mode. How are .NET components more efficient compared with J2EE components? Because you don't have the choice?

    >>Finally, for those of you wanting significant leaps in productivity and performance... give .NET a try :-)

    I understand where your paycheck comes from. And, I understand this is tongue in cheek. BUT… If you want to be an evangelist to the Java community, you should drop the significant marketing hype and talk plainly. When you compare .NET to J2EE, there are some clear advantages .NET brings. Of course, there are clear advantages the other way too. But if you want to say that .NET is higher performing because you built the J2EE Blueprints sample application to run faster in .NET… then, please, change your title to ‘Microsoft Java Community Salesperson’ -- its more fitting for the high-level, misleading reply you posted here.

    Russ
    Reply to this Reply to original

  73. Five reasons against migrating EJB applications to .NET[ Go to top ]

    anything to do with the Petstore has absolutely nothing to do with ASP.NET vs. JSP.


    Oh yeah, I remember that thing ;-)

    .NET Outperforms J2EE. In a head-to-head comparison of performance and scalability between Sun's Java Pet Store J2EE blueprint application and the ASP.NET implementation, .NET significantly outperformed J2EE. The bottom line: the ASP.NET implementation required only 1/4th as many lines of code, was 28x faster (that's 2700%), and supported 7.6x as many concurrent users as J2EE, with only 1/6th as much processor utilization. Click here to review the results, download the code, and run the .NET Pet Shop yourself

    If you like silly comparissons:
    http://www.gotdotnet.com/team/compare/webservicecompare.aspx
    Reply to this Reply to original

  74. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Hi David -
    You are talking to a more sophisticated audience than your post is meant for.

    <quote>
    However, for those customers that want improved performance, higher productivity, and lower total costs, we offer several paths to migrate existing applications into the CLR.
    </quote>

    Care to back that up? Where are your stats on improved performance, higher productivity and total costs?

    <quote>
    False. Microsoft offers the J# product for people that want to continue using the Java language syntax.
    </quote>

    Sorry - but syntax support isn't language support by any stretch. So, should we change your statement from 'False' to 'True'?

    <quote>
    While we certainly agree that there are a few challenges converting a JSP into ASP.NET, the rewards are significant: Massive performance improvements, greater development speed, and a far more logical, event-based approach that scales well.
    </quote>

    Massive performance Improvements? Please back this up with real world data.

    Greater development speed? Please back this up with real world data.

    Far more logical, event-based approach that scales well? C'mon David - what kind of statement is this? You forget your audience.

    David - why don't you try to conterpoint the article by finding 5 real-world reasons to convert J2EE projects to .NET?

    Cheers
    Ray
    Reply to this Reply to original

  75. Five reasons against migrating EJB applications to .NET[ Go to top ]

    "Hi David -
    You are talking to a more sophisticated audience than your post is meant for."

    Is it so? How about this pearl then? (from this thread):

    ".NET is mainly from MS nowadays. As long as this is the case I won't use it. Period."

    or, even better (another poster):

    "I don't care about your [Microsoft] products, even if they are 'better' than J2EE. I would not use them even if they were."

    Where are the deep technical reasons of these guys? The funny thing is that it is precisely this kind of attitude that scares business decision makers, sadly, you find it more frequently on the Java camp.
     
    "David - why don't you try to conterpoint the article by finding 5 real-world reasons to convert J2EE projects to .NET?"

    I guess the article is really silly from the premise: either the J2EE project is doing well so you just don't want to touch it or it is failing in which case you switch. End of the reasoning.
    Reply to this Reply to original

  76. Five reasons against migrating EJB applications to .NET[ Go to top ]

    You can easily find some extreme ideas of some of the pro-MS guys posting here. Let's have a look at this one, Rolf believes that open-source programmers are thieves:

    "[...]The open source people can only make software by stealing."
    Reply to this Reply to original

  77. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <q>
    Rolf believes that open-source programmers are thieves:

    "[...]The open source people can only make software by stealing."
    </q>
    Worse, in the same letter:
    "I am constantly amazed to why Open source un-American movement gain so much space"

    I guess we´re subversive. Am I glad I´m not american ...

    BTW, why is open source 'un american' ?? Is it because it´s usually 'community' work ?? Does it have something to do with communism ??

    I may be dutch AND stupid because I don´t get it. Does it have someting to do with terrorism ?? WHAT ??? WHAT ??

    Please tell me ...
    Reply to this Reply to original

  78. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <q>
    BTW, why is open source 'un american' ?? Is it because it´s usually 'community' work ?? Does it have something to do with communism ??

    I may be dutch AND stupid because I don´t get it. Does it have someting to do with terrorism ?? WHAT ??? WHAT ??

    Please tell me ...
    </Q>

    I'm 1/4 dutch. :) And American. I'm glad you are glad to be Dutch. But sad you are glad not to be American. I'm sure the Netherlands (and England, ...) has their share of morons who have learned to type and speak.

    I think it is the result of not very bright thinking (consider the source). I think Open source is very American. Maybe early American. Yes, Communism is bad, but we have lost our way and think helping our neighbor and sharing a little is bad. Somethings do belong on a community level. Some do not.
    Reply to this Reply to original

  79. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <q>
    I think it is the result of not very bright thinking (consider the source). I think Open source is very American. Maybe early American. Yes, Communism is bad, but we have lost our way and think helping our neighbor and sharing a little is bad. Somethings do belong on a community level. Some do not.
    </q>

    I agree wholeheartedly. Open Source is a lot more 'american' than anyting else. Isn´t it 'freedom for all' ??

    Anyway, I don´t think it´s 'american'. Freedom is not an american comodity. It´s something we all strive for.
    Reply to this Reply to original

  80. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <Q>
    I agree wholeheartedly. Open Source is a lot more 'american' than anyting else. Isn´t it 'freedom for all' ??
    </Q>

    With freedom comes responsibility. I guess freedom is for all. At least here in America it is suppose to be. Not so much any more. And not so much anywhere else


    <Q>
    Anyway, I don´t think it´s 'american'. Freedom is not an american comodity.
    </Q>

    No it is not. But it was something it was founded on. What countries did the European settlers seek freedom from?

    <Q>
    It´s something we all strive for.
    </Q>

    On a personal level, yes. On a country level. No.
    Reply to this Reply to original

  81. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <TF>You can easily find some extreme ideas of some of the pro-MS guys posting here. Let's have a look at this one, Rolf believes that open-source programmers are thieves:

    "[...]The open source people can only make software by stealing."
    </TF>

    That was a great link. If Rolf feels like stealing, maybe he should read the license agreements first. Maybe he wouldof found out that what he is doing is legal. Maybe he would have found that he is not making software by stealing but by uhm ... reusing.



    Reply to this Reply to original

  82. Five reasons against migrating EJB applications to .NET[ Go to top ]


    Bob,

    Stealing ideas and code is something that always has been going on in a capitalistic society. For instance in the case of Linux all they have done is to cannibalize 30 years of Unix development. But I am referring to the trying of making themselves look like the White Knight. OSS is sometimes very ugly look at the true face:
    http://smoothwall.org/community/home/articles/dickmorrell/20020322.time.html


    And then there is the hypocrisy part. Somebody idealistic and competent (but naive) gather together to create something, then their collective efforts is sized upon by some "clever" people who turn it into profit. Not only are the original developers left without any part in the company but soon their contributions are minimized, so even the credit is taken away from them. For an example of this look no further than jBoss!

    But they have the fanatism. No matter wherever it is left or right fundamentalist fanatics never excite me.

    Regards
    Rolf Tollerud
     
    Reply to this Reply to original

  83. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <Q>
    But they have the fanatism. No matter wherever it is left or right fundamentalist fanatics never excite me.
    </Q>

    The problem with fanaticism is that it really is poing of view thing. You think they are fanatics. You think you are not. They think you are and they are not. Extremism is easier to detect. If no one is on your left then you are extreme right (and applied to the other side). The thing is the 'extremist' might be right. Is a fundamentalist always a fanatic? I'm guessing (and by looking at your statements) in your book - yes. I think middle of the fence/wishy-washy is much worse than being committed to something.

    I wouldn't say JBoss is extreme or fanatical. Maybe commited, and sometimes a little over the top verbally.
    Reply to this Reply to original

  84. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <q>
    Stealing ideas and code is something that always has been going on in a capitalistic society.
    </q>

    Yes Rolf that is really true, One of the first example I can remember is your Boss (Bill) stealing CP/M and adapting it for use with ibm´s new toy. (I still have that peace of stolen software at home. It´s called DOS 1.0)
    Reply to this Reply to original

  85. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <QQ>
    <q>
    Stealing ideas and code is something that always has been going on in a capitalistic society.
    </q>

    Yes Rolf that is really true, One of the first example I can remember is your Boss (Bill) stealing CP/M and adapting it for use with ibm´s new toy. (I still have that peace of stolen software at home. It´s called DOS 1.0)
    </QQ>

    Non-capitalistic societies are no better. Usually worse. Many other places they kill you before they take it.
    Reply to this Reply to original

  86. Five reasons against migrating EJB applications to .NET[ Go to top ]

    My concern with open source is human aging. I recon most OS developers are young with loads of time, or older with very dull day jobs.

    Most peoples lives change every 3 or 4 years as they get married, have kids, get a mortgage etc. At this point they either ditch their creation or look to extract money from it. This is possibly with huge open source successes where they can do consultancy - JBoss, Linux. It's not true of most others.

    So what happens to small or mid level open source after 4 years?

    Apache, Emacs, Linux all fly in the face of this I guess. Who now manages these efforts? Is the batton being passed on to a new generation, or are the original folks still involved? I'd like to know the answer, because human aging is the one thing that can kill off a decent open source effort.

    Jonathan

    ps OS and nationality have nothing to do with each other. Time and education seem to have an effect though.
    Reply to this Reply to original

  87. Five reasons against migrating EJB applications to .NET[ Go to top ]

    David Weller,
    It is interesting to see a free asp.net development tool. I currently don't have Windows on any of my machines. My servers, and my Development laptop are all Linux based. I got tired of MS Headaches on the server side a couple years ago, and my older win98 desktop system crashed "hard" a few months ago due to a hardware problem I have not gotten around to fixing.

    I developed in ASP years ago at a previous job, but have been all PHP and J2EE recently.

    I suppose a Linux version is out of the questions, so what software do I need to have, and how much will it cost me in licensing to put together a development station capable of creating .net objects (or whatever you call them this year) and an envirnment capable of running an asp.net application? I know I of course would need a windows machine, but what version can run the server software required? Basically, what is my least expensive route to experimenting with your technology.

    (BTW - the cost of entry of a system such as I ask for is effectivly nothing in the J2EE world, with Tomcat, JBoss, NetBeans, Eclipse, etc.) I have older hardware lying around I could use, but not NT server licenses.

    -Pete
    Reply to this Reply to original

  88. Five reasons against migrating EJB applications to .NET[ Go to top ]

    David Weller,
    Another question. How cross browser compatible is the code created with Web Matrix? Looks to me from the screen shots like it can create a lot of code automagically.

    -Pete
    Reply to this Reply to original

  89. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Oh my! Is it so hard to understand:

    .NET is mainly from MS nowadays. As long as this is the case I won't use it. Period.

    The reason is that I already wasted 70% of my life-time with MS products. It is enough. I want to be _free_ again.

    There are several fine speeches by RMS about this topic:
    http://www.fsf.org/philosophy/audio/audio.html
    Reply to this Reply to original

  90. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Repeat after me:
    "J# is not Java, J# is not Java, J# is not Java"

    Therefore, the CLR does not support Java.

    End of debate.

    Reply to this Reply to original

  91. Five reasons against migrating EJB applications to .NET[ Go to top ]

    1. CLR does not support Java

    False. Microsoft offers the J# product for people that want to continue using the Java language syntax.

    **************************************

    J# is not Java it is the Java syntax as defined in JDK 1.1.4. This is the syntax from the MS JVM that got MS in trouble in the first place. It is not the Java platform, language, or even Java 2.

    **************************************

    2. IIS does not support JSP

    **************************************

    While it is true that JSP can be supported through ISAPI plugins, it is not natively supported under IIS. ASP.NET is supported directly by IIS.

    ASP.NET does have some nice items technically. However, there are many other questions. When will ASP.NET run under anything other that IIS. When will IIS be secure.

    ***************************************
    3. Server controls require redesign
    ***************************************

    Your statement is misleading. His example is misleading but his staement is mostly accurate. If you do your access through taglibs and EJB, you have almost a complete rewrite to go to ASP.NET. You my be able to save you presentation, if you coded it correctly, but the business and data logic will need to be redone.

    ***************************************
    4. No support for Container Managed Persistence
    ***************************************

    COM+ is a repackaging of COM and DCOM with some impovements.
    .Net does not suport CMP. The idea of using COM+ in .Net is disturbing. You have to do this by running your code as "unsafe".
    The smoke screen of Stateless vs. Statefull does not address this.

    CMP gives a great deal to J2EE platform.

    ***************************************
    Finally, for those of you wanting significant leaps in productivity and performance... give .NET a try :-)
    ***************************************

    There are so many problems with this statement. J2EE/J2SE is a mature, test, proven, and secure platform. With the right tools you can be very productive.
    In my experiance it twice the developers and 4 times the support when I go with a MS solution. This is the best case not worst case.

    The licencing cost and the virus cost of the MS platform makes it a bad business decision. The other problems I see are:

    1. .Net uses Web Services and XML for everything
    2. There is no standard way to protect Web Services
    3. The CLR using C#, J#, or VB.Net lets me ignore errors by not supporting checked exceptions.
    4. The track record of IIS on security is pathetic at best
    5. This is the first release of a whole new technology
    6. License cost is way to high
    .....

    I am sure other items exist.

    Reply to this Reply to original

  92. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Hi: David,

    I don't want to criticize or bash MS for no reason, but .NET environment disappoint me a lot (and every OO purist) when it comes to data tier layer. The ADO.NET and it's predecessor ADO are very procedural when you compare it to EntityBean and JDO. Executing SQL and stored procedures directly from your code is a common practice in MS world (even their "Java Pet Store" version for .NET follow this kind of model)which according to my opinion corrupts your object model a lot. Any comments from your side..

    Regards,
    Rashid.
    Reply to this Reply to original

  93. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Yes, you might support the Java language syntax with J#. However you do not support the Java platform, which gives Java what people attracts about java - platform independence.

    Apple's WebObjects had multilanguage support as well and was supporting Java as a language as well. However, it did not run on the Java platform, it was based on ObjectiveC (another language which sadly enough seems to disappear). The result: WO got run over by more Java compiant app servers like BEA etc. Also, with version 5.0 Apple finally shipped a native Java-WO, giving full platform indepence.

    As for multilanguage support: Within a project, I do not believe, there is much potential to code in different languages. I think it will be either Java or C# or Objective C or, uhm, Cobol.NET. However, when it comes to matters of reuse, if the appserver supports reusing components that are written in a language different from what is used in the current project, then multilanguage support becomes powerful. Here is where .NET has good potential.



    Reply to this Reply to original

  94. Five reasons against migrating EJB applications to .NET[ Go to top ]

    I was surprised the guy only found five.
    Steve
    Reply to this Reply to original

  95. Five reasons against migrating EJB applications to .NET[ Go to top ]

    What idiot wrote that article ?? There should not even be a link to it on this site.
    Reply to this Reply to original

  96. Five reasons against migrating EJB applications to .NET[ Go to top ]


    This discussion surely is entertaining!

    Regards
    Rolf Tollerud

    Who needs tv!
     
    Reply to this Reply to original

  97. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Another reason not to - lack of choice.

    In the large financial institution I consult for developers develop java under Windows and Linux.

    We currently deploy to Solaris and AIX.
    We've plans to deploy to Linux.
    We could deploy to Windows if we wanted.

    Basically we have lots of choice, lots of platforms lots of vendors, lots of tools - we have the ability to choose the best combination for each particular job.

    Why would we want to change that for a single vendor with a single platform and a single tool(VS.NET), with a patchy history of security, robustness and scalability, a tendency to lock people in at every opportunity and an immature untested technology.
    Reply to this Reply to original

  98. Irrelevance of EJB[ Go to top ]

    One interesting perspective I heard on what .NET does to EJB takes the general view that .NET makes the "object request broker" (ORB) model of distributed objects/components obsolete. This means that COM and CORBA-based approaches are obsolete, replacing the ORB with web servers.

    EJB is just a runtime API specification for Java-based CORBA components. It offers a runtime stack for network access, concurrency, security, state management, fault tolerance, persistence, events, etc.

    Well, HTTP and web services provide several of the above services too -- networking, concurrency. Though most of those services are still works in progress. And .NET fills in things like state management and persistence.

    I think it's actually somewhat refreshing that Microsoft turned around from a decade-long strategy of pushing COM as the be-all, end-all solution to reusable components and saying, "we were wrong". Self-describing semantic data streams (XML) and a ubiquitous network stack (HTTP, SMTP, etc.) are a more open, less divisive, and easier solution.

    It remains to be seen if we can keep people working together on this long enough for it to actually work, instead of devolving into the traditional "object wars" occured through the years -- CORBA vs. COM, COM+ vs. EJB, NeXT vs. Taligent, OS/2 SOM vs. Win32 OLE, OpenDoc vs. OLE, etc.
    Reply to this Reply to original

  99. Irrelevance of EJB[ Go to top ]

    "One interesting perspective I heard on what .NET does to EJB takes the general view that .NET makes the "object request broker" (ORB) model of distributed objects/components obsolete. "

    Is that perspective representative? I don't think it's .NET which is making any of the ORB model obsolete. Simply that Web Services which is a joint effort by the industry is intended to be a better model. But before the technology is sufficiently ready, even MS cannot throw away their COM/DCOM. MS is not doing anything different here.

    "Well, HTTP and web services provide several of the above services too -- networking, concurrency."

    But what about security and transaction? Those have to be solved before Web Services can take off.

    "And .NET fills in things like state management and persistence."

    Those are also available in J2EE.

    "I think it's actually somewhat refreshing that Microsoft turned around from a decade-long strategy of pushing COM as the be-all, end-all solution to reusable components and saying, "we were wrong"."

    I don't think it's a matter of right or wrong. Simply that Web Services is a different technology (and it's not proprietary to anybody).

    Clifford Cheng
    Reply to this Reply to original

  100. Irrelevance of EJB[ Go to top ]

    the data stream does not need to be self describing if it is defined on both ends. This eliminates a huge network overheard. And while HTTP and SMTP are great ways of exposing communication channels externally (because they're ubiquitous), they are hardly efficient themselves.

    Don't get me wrong. I'm a big fan of XML services over HTTP + SMTP, it's the simplest way to make disparate networks talk. XML transactions over HTTPS are great for making *separate* networks interoperate. But when you have 1 or more *internal* networks, streamlining protocols and standardizing data transmissions have a *huge* payoff.
    Reply to this Reply to original

  101. Make it "X reasons against migrating EJB applications to .NET"[ Go to top ]

    lets forward a bit ...in the meantime after several versions of dotnet, now they call it dotnew, it is approximately year 2007, somebody found a serious bug with dotnet and i'm using it in my super-duper business...

    and you will see headline like this: "MS decided not to fix dotnet because dotnew is newer"..... grrrrr...

    http://www.cnn.com/2002/TECH/ptech/09/13/microsoft.word.bug.ap/index.html
    Reply to this Reply to original

  102. Five reasons against migrating EJB applications to .NET[ Go to top ]

    not to mention, C# does not enforce exception handling when a method is declared to throw an exception at compile time.
    Reply to this Reply to original

  103. Five reasons against migrating EJB applications to .NET[ Go to top ]

    It seems dangerous to compare religions based on operating costs alone. I worry for Java if people focus on this too much. The battle is waged on different fronts.

    My feeling is that Microsoft has reduced development risk and operational performance risk with good tools and an optimized MSSQL/XP/IIS stack. Java has so-so tools and a confederation-oriented stack. Java is also harder to learn. All these make Java a riskier bet for departmental systems. Assume Micrsoft owns the desktop. So the highground is business critical systems. As mindshare decays this will go too. I see a trend of losing mindshare before market share. When WebLogic and IBM drop prices it will be too late. Java does have lots of price points. .Net has one.

    If I could herd cats I would suggest enhancing Eclipse to surpass WSAD in order to compete against Visual Studio. JBoss needs an opensource marketing group. Hype the service side. That ought to give opensource parity with .Net.

    $0 + $.02





    Reply to this Reply to original

  104. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <Q>
    It seems dangerous to compare religions based on operating costs alone
    </Q>

    Well how much does your religion cost to operate? Mine only desires 10%.

    <Q>
    I worry for Java if people focus on this too much.
    </Q>
    Oh, I see. You are confused. You seem to think voicing support for something makes it a religious thing.

    <Q>
    My feeling is that Microsoft has reduced development risk and operational performance risk with good tools and an optimized MSSQL/XP/IIS stack
    </Q>
    Sure it is not a religious belief? I would said the opposite about what MS has done.

    <Q>
    Java has so-so tools and a confederation-oriented stack. Java is also harder to learn.
    <Q>
    My Java tools are good. And they don't have to be confederated. ('Ours' aren't)

    <q>
     Java is also harder to learn
    </q>
    Than what? .Net? If you want to create good 'programs' it isn't. What to whip out wizard stuff? Have at it.


    <Q>
     All these make Java a riskier bet for departmental
    </q>
    If they were true. If betting the farm on one company is good. Diversification and choice is very important.

    <Q>
    Assume Micrsoft owns the desktop
    </Q>
    And look what it has gotten us. Back to choice thing.

    <Q>
    So the highground is business critical systems. As mindshare decays this will go too. I see a trend of losing mindshare before market share.
    </Q>
    Keep an eye on linux. It is growing in the server arena and will help push it into the client. MS's 'stack' won't be going there. I look into my crystal ball and see something different. When was the last time you had your crystal ball calibrated?

    <Q>
     When WebLogic and IBM drop prices it will be too late.
    </Q>
    IBM's has dropped for what compares to MS's stuff.

    <Q>
    Java does have lots of price points.
    </Q>
    Isn't choice great? Pay for what you need.

    <Q>
    .Net has one
    </Q>
    "You can have any color of car you want. As long as it is black."


    <Q>
    If I could herd cats
    </Q>
    Maybe you should consider a career change.

    <Q>
    I would suggest enhancing Eclipse to surpass WSAD
    </q>
    WSAD is an enhanced Eclipse. And WSAD is way better that VS.Net. Where is the refactoring, junit, choice... ?

    <Q>
    JBoss needs an opensource marketing group
    </Q>
    Why? Do they need more business? I'm sure they would welcome it but they don't need a marketing group. Free is hype enough.

    <Q>
    That ought to give opensource parity with .Net.
    </Q>
    If they charged for it, made it break down and made it generally less useful then it would be on parity. Oh, and made it single platform.

    <Q>
    $0 + $.02
    </Q>
    More like $0 + (-$.O2). You owe us.



    Reply to this Reply to original

  105. Five reasons against migrating EJB applications to .NET[ Go to top ]

    My few cents worth, picking up comments from others:

    Rolf: loved the price links, thanks.

    Many folks: JSP v's ASP. I believe JSP is completely rubbish. It has resulted in many OS projects that try to kill it off because it is so rubbish: struts, velocity, cocoon etc. Yes I know they don't aim to kill it off as a stated goal, but having worked with so many rubbish JSP's I will read that into them. No one should defend JSP.

    Speed: Give it up. .Net v's J2EE...who cares. Upgrade your hardware, wait 12 months and double the performance. The bottle neck is the data layer, and that has nothing to do with .Net or J2EE, it's about the database and your farm architecture/clustering etc etc.

    Cost: Developers role in at 70k to 100k a year (say) - salary, tax, space, rental, pension etc. A good size project has 6 developers, with sales, marketing, internal sponsors on top. Say the project totals 3 million all in. With maintenance costs in staffing terms at about 200k (say).
    How much does the business head care about 120k of licensing (for weblogic/oracle) as opposed to the guarantee that there is support and maintenance. And frankly the big shops have site lecenses for this stuff, so the big buys are actually perceived as 'free' to individual projects.

    I agree linux, jboss, mysql do the job. But if the project is 3 million I want a dedicated support company. If you are lucky, your co has a techie business sponsor who is happy with Linux/JBoss - but most do not.

    CLR and Java. .Net hates pure java and will always strive to kill it. I personally want java to adopt .Net as one of its operating systems - ie implement all java libs on top of .Net. Then java can say it is cross platform again, and the .net v's j2ee debate goes away, because j2ee would BE .net as well as linux etc.

    SOAP v's EJB. This really is apples and oranges. Role back of distributed, asynch soap transactions is an art in itself. Rollback of distributed, SYNCHRONOUS EJB transactions is done for you. Note they are different things.

    Vendor lock in. Can't fault anyone here, .Net is ms forever.

    Microsoft v's J2EE, this is not what it appears. People think this is microsoft v's sun, but its not. It's microsoft v's open source, and that is a serious hearts and minds, true religious debate. With the associated martyrs, burning, and shouted beliefs based on personal world views. Reasoned arguments have no effect here.

    C# exception handling raised by many as a flaw - there is a nice counter to the argument. Basically, as systems grow very large and the api's called throw more and more exceptions developers start to role all exceptions into the base class - just to avoid the hassle of declaring them all and catching them all. This is not theoretical, but is practical. I have seen it happen over and over. The solution is documentation of exceptions, with helpers in the IDE. I'd provide the URL, but I've lost it.

    Not using TSS for .net debates. I obviously disagree. I think we all need to understand the issues, know how to interoperate and have arguments to back our technology choices. This only comes from debate - where we exchange ideas and learn. I agree this removes TSS as a sales channel for java, but TSS has never been a sales channel, it's for us developers and architects to try to work arround the flaws in J2EE to actually make stuff work. It's also a great barometer of java trends.

    Transitioning from J2EE to .Net
    ===============================
    Very silly. If you do this its either because Bill gifted your co 10 million in sales revenue (it happens), or they bought you, or your techies want to retrain.

    This is also true for moving from SQLServer to Oracle, or Sybase to Oracle, or whatever. If it works don't fix it.

    Selecting J2EE v's .Net
    =======================
    That is entirely different, and not part of this thread. But from my experience the choice comes down to:

    Do you have an existing team
    If yes: do it the way they can
    If no: Does your company have a single standard
      If yes use it
      If no, then is your co. worried about vendor lock in? eg Does Unix/Linux scare you? Do you trust Microsoft servers?
      If you are happy with both Unix and Microsoft then it comes down to staff costs and then 'beliefs'. Who will be cheaper? Which system will be easier to maintain, which has the simpler architecture. At this point flip a coin (or hire a really expensive architect so he can flip the coin - backed up by lengthy documentation.) Both .Net and J2EE will work. Both have worked on large and small systems, both have developer pools. Both will integrate with legacy systems.

    If you don't know which staff are cheaper, go for java cos we love it, and it doesn't lock you into msoft licensing - you get BEA/IBM and Oracle instead, who are all cuddly, lovely lil companies (sarcasm in case you didn't spot it).

    Once you have flipped the coin hire another expensive architect to make it work. i.e. both technologies are complex, and both will do the job.

    Footnote:
    Some of you will contest my comment
    'Both have worked on large and small systems, both have developer pools.'

    Please take a look at the ms sales stuff - they give examples of large clients. For all your perceived FUD there is truth in there as well.

    Jonathan
    Reply to this Reply to original

  106. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Hey Jonathan,

    I suppose it's sad that I'm surprised of reading such a balanced message. I mean, we developers and consultants exist for serving our customers with the best tool for the scenario and in this sense we should be above market-share fights. As this thread shows, far too many Java developers (believe it or not developers in the other side are less religious about their technical merits) has lost this "best tool for the job" approach and made a religious war out of it, so kudos for your as unbiased as possible message.

    In particular I would like to refer to this point of yours:

    "CLR and Java. .Net hates pure java and will always strive to kill it. I personally want java to adopt .Net as one of its operating systems - ie implement all java libs on top of .Net. Then java can say it is cross platform again, and the .net v's j2ee debate goes away, because j2ee would BE .net as well as linux etc."

    I find this intriguing because: Sun or IBM could create a Java 2 compliant compiler for .NET (Microsoft can't, out of legal reasons), porting the Java libraries is an even easier (if rather long) job. If we get servlets, JSPs and EJB hosted in the CLR we should've done a great service to the customers at large (who for the most part doesn't understand or care about this platform wars).
    Reply to this Reply to original

  107. Five reasons against migrating EJB applications to .NET[ Go to top ]

    "Many folks: JSP v's ASP. I believe JSP is completely rubbish. It has resulted in many OS projects that try to kill it off because it is so rubbish: struts, velocity, cocoon etc. Yes I know they don't aim to kill it off as a stated goal, but having worked with so many rubbish JSP's I will read that into them. No one should defend JSP."

    JSPs are certainly not rubbish and have been used successfully by many (including myself). And I would remove Struts from your list of projects that give JSPs the shaft. If anything, Struts plays to JSPs strengths and promotes their proper use.

    <rant>
    Let's see. So EJBs are unnecessarily complex with fatal design flaws and now JSPs are rubbish (worse, they are completely rubbish). I guess that doesn't bode well for J2EE. I have even been hearing lately that Java is also rubbish compared to C#. I guess that doesn't bode well for Java either. And don't even get me started on Swing. Wow! It is a good thing that I don't spend too much time contemplating these truths. Instead, I continue to apply these technologies successfully in blissful ignorance of the conflagration that is occurring outside of my window.
    </rant>

    Would I be soundly flogged here if I said I actually liked EJBs and JSPs?

    I would prefer to hear mmore constructive, well-reasoned arguments please. Opinions are a dime a dozen. If you have done so and have been routinely ignored by the "expert groups" then I would like to hear that as well.
    Reply to this Reply to original

  108. Five reasons against migrating EJB applications to .NET[ Go to top ]

    "JSPs are certainly not rubbish and have been used successfully by many (including myself)."

    I totally agree with the fact that JSP is a good base to build web applications on. Bad programming practices and bad programmers make all the difference. You can make perfectly clean, maintainable and scalable applications with JSP.

    I will never forget when MS came out with Visual Interdev and just months later warned all the users not to use its built-in controls because they were leading to unmaintainable software and a tone of spaghetti code in the generated ASPs....

    Sell first, fix later, this is the biggest innovation MS brought to the software industry.
    Reply to this Reply to original

  109. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Hi,

    Try reading "Bitter Java" and you might find some of the reasons behind the failures you mention.

    StopAReboot
    Reply to this Reply to original

  110. Five reasons against migrating EJB applications to .NET[ Go to top ]

    My reply addresses Bill Willis's post.
    Reply to this Reply to original

  111. Five reasons against migrating EJB applications to .NET[ Go to top ]

    We have spend several years trying to find an integrated solution to solve problems in chemistry. We initially worked on IBM's package (VA, WAS Studio, WAS and DB2). We wasted a lot of time. Even websphere studio application server is not mature, costs too much and contains too much IBM stuff. Recently, we use JBuilder, Ant, Tomcat, Jboss and MySQL in Linux for developement and deployment. We really like it. So far the project is about 80% completed with less than 10K spent. We can easily migrate to the combination of JBuilder, Weblogic and Oracle or DB2 in the future if necessary. Why bother with Microsoft?.

    Jerry
    Reply to this Reply to original

  112. Five reasons against migrating EJB applications to .NET[ Go to top ]

    <Q>
    We have spend several years trying to find an integrated solution to solve problems in chemistry. We initially worked on IBM's package (VA, WAS Studio, WAS and DB2). We wasted a lot of time. Even websphere studio application server is not mature, costs too much and contains too much IBM stuff. Recently, we use JBuilder, Ant, Tomcat, Jboss and MySQL in Linux for developement and deployment. We really like it. So far the project is about 80% completed with less than 10K spent. We can easily migrate to the combination of JBuilder, Weblogic and Oracle or DB2 in the future if necessary. Why bother with Microsoft?.
    </Q>
    Excellent post. This is the beauty of the Java platform. Don't like a vendors tools - don't like how they perform - don't like the cost - pick another.
    Reply to this Reply to original

  113. Five reasons against migrating EJB applications to .NET[ Go to top ]

    Here's a quick tally, it seems those in favor of migrating EJB applications to .NET are all from microsoft's marketing department.



    Reply to this Reply to original

  114. To EJB or not to EJB[ Go to top ]


    Can anybody tell me if EJB (stateless) actually improves performance or not. I have some decent experience, 1-2 year, with Java but not with EJB. Now I have to do a new project in Java (unfortunately I can not use .NET which I prefer) and I am in doubt. Before I was under the impression that EJB improved performance for large scale apps. Is that so? For how much load? The other reasons for applying EJB (transactions etc..) is not actual here, only performance. Is it crazy to use Tomcat/Velocity/Poolman? Will it scale?

    Regards
    Rolf Tollerud
     
    Reply to this Reply to original

  115. To EJB or not to EJB[ Go to top ]

    IMHO: No, in your case Stateless Session Beans won't improve performance, compared to business logic in plain Java classes. Instance pooling of Session Beans doesn't give you any benefits if you just use them locally and don't keep resource references as instance variables in them. On the contrary, Session Beans have the overhead of method call interception that you don't benefit from if you don't use declarative transactions and/or declarative security. The rest is all plain Java logic execution, in both cases.

    I don't consider a Tomcat/Velocity combo crazy, although I wouldn't use Poolman. I suggest Tomcat 4.1.10 which features Jakarta Commons DBCP as its integrated JNDI connection pool, or Resin 2.1.4 with its own connection pool. Both are easy to configure, and JNDI DataSources are the standard way of resource access and connection pooling.

    In my experience, Resin is faster and handier than Tomcat, although Tomcat 4.1 has improved over 4.0. Both containers come with an integrated HTTP server, no need for Apache or co. Resin licences are free for development and 500 USD per server (http://www.caucho.com).

    JBoss 3.0 is also an option. But IMHO both Tomcat 4.1 and Resin 2.1 are simpler to handle and easier to configure. And both are as fast, stable and scalable as JBoss' web container (Jetty), or even faster in the case of Resin.

    A cleanly written web app running in either container will scale, provided it runs on suitable hardware (e.g. enough memory). I guess the biggest potential for performance improvement lies in database configuration, and in how your app handles state.

    Regards,
    Juergen

    P.S::
    Rolf, I am glad to see that your tone changed a lot during the last few weeks. I prefer discussing best practices. Emotional technology debates often just lead to needless accusations and semi-religious fronts.
    Reply to this Reply to original

  116. To EJB or not to EJB[ Go to top ]


    Juergen,

    Thank you for the tip. I have to earn my daily Caviar and Entrecote!
    I read through the JNDI Datasource HOW-TO and it seems straightforward, one more question only, shall I use the new BEA VM?

    By the way it seems that it is possible to use transactions with Tomcat after all, with Tyrex, which is good to know just in case.

    Regards
    Rolf Tollerud
     
    Reply to this Reply to original

  117. To EJB or not to EJB[ Go to top ]

    <q>
    I read through the JNDI Datasource HOW-TO and it seems straightforward, one more question only, shall I use the new BEA VM?
    </q>

    The new BEA VM is not new, I don´t know what BEA calls it nowadays, but it´s actually called JRockit. It´s a great VM. AFIK it´s almost the same price as Weblogic Express but should come packaged with WLS & WLS Express. If you don´t need EJB, WLS express is also a very good option. It contains all features of WLS but without EJB.
    Reply to this Reply to original

  118. To EJB or not to EJB[ Go to top ]


    Sven,

    But I though it was free?

    Stuart Lawrence wrote,
    "Yes, there is no charge to download and use JRockit (for development or deployment). The only restriction really is a pretty standard non-distribution agreement (see the verbiage in the bundled license)"

    (http://www.theserverside.com/home/thread.jsp?thread_id=15407#58895)

    Regards
    Rolf Tollerud
     
    Reply to this Reply to original

  119. To EJB or not to EJB[ Go to top ]

    To my knowledge, JRockit is free since BEA acquired it. But I've heard mixed reports about its performance vs resource usage. I guess Sun's JDK 1.4.1 or IBM's JDK 1.3 would be good choices.

    JTA via a Tomcat 4.1/Tyrex 1.0 bundle works nicely, I've already played with it. Note that you have to declare your DataSources as Tyrex resources in Tomcat and configure them in Tyrex' config file. This is more laborious than working with an integrated JTA solution like the ones that Resin 2.1 or JRun 4 provide, but it works.

    Having JTA in your toolbox is fine: Generic and/or distributed transactions can be handled in a container-independent way, even without XA-capable JDBC drivers. Both Tyrex and Resin perform two phase commits when given XADataSources and one phase commits in case of ConnectionPoolDataSources and Drivers.

    BTW you should use ConnectionPoolDataSource instead of Driver for the configuration of standard connection pools, as it provides additional status feedback to the pool. Most JDBC drivers provide an implementation, even MySQL's. Tomcat 4.1's DBCP, Tyrex 1.0, and Resin 2.1 all support ConnectionPoolDataSource implementations as "driver name".

    IMHO the dependency of (distributed) transactions on EJB is a widespread misconception in the J2EE world. You can handle them easily via explicit JTA usage. Beyond remote access, EJB gives you DECLARATIVE transactions as well as declarative security. For PROGRAMMATIC J2EE transactions, JDNI resources and JTA are all you need.

    Regards,
    Juergen
    Reply to this Reply to original

  120. To EJB or not to EJB[ Go to top ]


    OK. I buy this solution. It has the advantage of simplicity (KISS) which is fine with me because the app itself are "not trivial" and I don't want to spend to much time learning the tool.

    Thank you
    Rolf Tollerud
    Reply to this Reply to original