Discussions

News: Where are all the vendors official ECperf benchmark results?

  1. Given the fact that the majority of the leading application server vendors have already been into Sun's testing facilities and run the ECperf benchmark with their own products and now have an official number to compare their results to, there can only be one conclusion as to why they have not posted a result.

    "Giga believes that the lack of ECperf results clearly indicates that the leading vendors products did not perform as well as their previous benchmarks had indicated and definitely not well enough to beat Borland's official benchmark."

    Read Giga's IdeaByte: Borland Posts First J2EE ECperf Result: Still King of the Hill 30 Days Later.

    My personal view is that Sun should make publishing ECperf results a condition of J2EE certification compliance otherwise they will not publish if the results are not good. And we will get more of the Pet Store 'benchmark' nonsense!

    But its nice to see GIGA research calling the vendors on not publishing their ECperf results when they have them.

    Threaded Messages (122)

  2. Greetings,

    Since Sun has some of the ECperf test results of other vendors, is there URL to look at these results even if they not official yet?

    Thanks in advance,

    Taras
  3. Giga believes that the lack of ECperf results clearly indicates that the leading vendors products did not perform as well as their previous benchmarks had indicated and definitely not well enough to beat Borland's official benchmark


    Very natural conclusion...

    >>My personal view is that Sun should make publishing ECperf results a condition of J2EE certification compliance otherwise they will not publish if the results are not good. And we will get more of the Pet Store 'benchmark' nonsense!

    Ok, but on what kind of machines?
  4. Greetings,

    I agree that Hardware must be somehow specified for the ECperf benchmarks. It is very complicated task - different vendors, different combinations lead to different benchmark results.

    I believe that it is still possible for a customer to see overall difference between App Servers because:

    1) Since we are talking about J2EE (application based on specifications) each App Server should also release ECperf Deployment Kit (as Borland did), so anybody could re-create benchmark tests on any desired hardware configuration. Of course results will be different, but as long as customer can recreate test from the different App Server vendor on the same hardware, he/she/them will see which App Server performs faster in their desired configuration.

    2) One of the good things of the ECperf that results provided in Price per Resource/Work format, so in theory same App Server should run with the same results (at least almost the same) on different hardware. Example: on smaller hardware App Server will show worse results (less operation performed, more recourses are needed) but price of that hardware configuration will be also small so it will keep benchmark test results in certain range close to the official ECperf results.

    P.S. Unfortunately it is only theory - there are much more variables in the formula and also for now only Borland posted their results so there are nothing to compare to.

    Best regards,

    Taras
  5. I agree that Hardware must be somehow specified for the ECperf benchmarks. It is very complicated task - different vendors, different combinations lead to different benchmark results


    The specification mandates a full disclosure of hard- and software, so that's not the problem.

    I'm only suggesting that the ECperf price/performance metric ($/performance) may be more valuable than its pure performance metric (business transactions/minute)
  6. Then again, Java is suppose to run anywhere? choosing a platform could give an advantage to a vendor.
  7. Has anyone ever thought that some of the vendors may be so swamped in a race to be the first or second in line for the J2EE 1.3 certification that ECperf has taken a back seat in the queue? Outside of theserverside.com at customer/potential customer sites, I still see people more interested in J2EE 1.3 certification than ECperf results.

    However, ECperf is closing in.

    --
    The comments made are personal opinions
  8. You know who is the first J2EE 1.3 vendor (Not certified of course, this will take some time)?
    Surprise - Its Borland! The ones who managed to get ECPerf results online!
    Okay, in fact, Sybase provided the first J2EE 1.3 server/EJB2 container, but they only seem to "map" EJB2 to EJB 1.1 (it creates separate beans for relationships).
    So in fact Borland is first. Not only this, but they are the first to provide a full-fledged EJB2 development tool!
    All the vendors who cannot come up with J2EE 1.3 containers and ECPerf results because of lack of resources - I like this, as it seems they invested many resources in marketing campaigns and useless benchmarks, add-on-functionality without sense (well, some add-ons are cool - but before using add ons I'd like to have a stable and up-to-date J2EE platform) and so on. Hopefully they'll see what it was worth.

    kind regards,

    Messi
  9. <quote>
    You know who is the first J2EE 1.3 vendor (Not certified of course, this will take some time)?
    </quote>

    Interesting. Would you share the source of this information with us?

    --
    Cedric
  10. Of course:
    http://www.flashline.com/components/appservermatrix.jsp
    is one source, you can easily see there are only two vendors who claim full EJB2 compatibility, Sybase and Borland.
    Then see
    http://www.borland.com/bes/appserver/
    "It fully implements the latest industry standards: J2EE 1.3, EJB 2.0 ..."
    and
    http://www.sybase.com/detail/1,6904,1016238,00.html
    "Leveraging its new support for the Java™ 2 Platform–Enterprise Edition (J2EE)™ 1.3 specification, Sybase EAServer 4.0 ..."

    You can see there are two vendors claiming this, I didn't find anyone else who claims this; I admit I didn't test each and every appserver whether it supports J2EE 1.3 though the vendor doesn't claim to support it but it is "by accident", but I think that's ok.
    Additionally I have no reason to think the two (Sybase & Borland) are lying because after some tests both seem to work e.g. with EJBs V2, Sybase quite clumsy, but both seem to work.

    I hope you didn't mean I should clarify "Certification will take some time" (?)

    Hope this helps & kind regards,

    Messi
  11. My team is using EJB 2.0 (CMP 2.0 and CMR 2.0) with BEA WLS 6.1 for almost 6 months now.
    ECPerf is very good indication - speed only. Would you rather use the fastest app server which forces you to reboot it 5 times a day? I would not. Speed is very important but maturity and stability of an App server is a must. That's why people in serious mission critical applications still rely on BEA.

  12. We should ask Cisco why they choose Borland to run a 20 bilion business. I think that this is mission critical enough, don't you?
  13. You said: "We should ask Cisco why they choose Borland to run a 20 bilion business. I think that this is mission critical enough, don't you?"

    First, I doubt that the entire Cisco business runs on the Borland app server, and I would bet that there are other app servers used there.

    Second, the reason why they chose Borland shouldn't be a big surprise -- Borland has some pretty impressive products, and they work pretty well. There is no reason to be defensive about Borland -- the problem isn't their products, it's their market share.

    Peace,

    Cameron.
  14. And that is exactly why BEA is losing market share to IBM... because it is not as stable as they claim it to be.
    Normally, if everything runs well, everything is fine with BEA, it is stable, ok.
    The difference occurs when the application has a bug... this began with WLS 5.1 ("server stopped to service requests" aha?) and went through to 6.0 (I didn't try 6.1 extensively).
    On the other hand IBM is always behind and the server was a nightmare to maintain until V4.
    So my position is still: If BEA does nothing about ECPerf, deployment tools etc. they will lose market share to Borland (not all, but a bit; and the next bit with the next release and so on)... there are always customers who are in need of the technically best solution, as they used "large vendors" products and lost (you know Microsoft?)...
    I'm not really a Borland AppServer fan overally, you know... The license is too expensive, I cannot get an eval in Europe (of 5.0; at the moment), support is not very good and so on. But I do understand that their server is "definitely" (I don't know all vendors) the best J2EE implementation (not talking about the add-ons!).
    And the Borland guy here is right... why doesn't BEA publish WebLogic 6.1 results? These are interesting, as many things are running on it, many customers will purchase it in the near future. Why wait for the next release? Borland didn't seem to find it necessary to wait for BES 5.0.
    So basically, yes, BEA and IBM are the market leaders, Borland is the technical leader and whatever BEA tells me (marketing blah blah), I want to see the ECPerf results.

    Same way, if Borland told you they were the market leader you'd ask them for sales numbers, wouldn't you?

    regards

    Messi
  15. [The license is too expensive]
    Do you want to say it's more expensive than WL?!

    [I cannot get an eval in Europe (of 5.0; at the moment)...]
    Try it now at http://shop.borland.com/Category/0,1257,3-15-1180,00.html

    [So basically, yes, BEA and IBM are the market leaders, Borland is the technical leader...]
    META ranks BAS 4.5 (note, not BES 5.0) at position 2 - http://www.business2.com/articles/mag/0,1640,35691|3,FF.html

    [Same way, if Borland told you they were the market leader you'd ask them for sales numbers, wouldn't you? ]
    Sales numbers of what? Till BES Borland had another product line than BEA and IBM did. Borland had VisiBroker and BAS, but BEA and IBM had WebSphere/WL _Editions_. Thus it's not correct to compare sales numbers of AppServers since BAS is equal only to WS/WL Enterprise editions. We should compare market shares in a year or so to see real picture.
  16. Do you want to say it's more expensive than WL?!

    It is. In my previous job we considered using Borland Assuming its cheaper than WLS. The Numbers given by Borland sales are higher than that of WLS (Considering the discounts BEA Offered). BTW We did tell the sales guy we were looking at alternative to reduce the cost of deployments.

    Kumar.
  17. Was it Servlet/JSP project only or EJB project?
    If it was a combination of Web/EJB I can suppose BAS was more expensive because it had only Enterprise edition. With BES this configuration is quite cheaper.
  18. [The license is too expensive]
    {Do you want to say it's more expensive than WL?!}
    Yes, BAS 4.5 list price is US$ 12K/CPU while BEA 6.0/6.1 is US$ 10K/CPU. Don't tell me about discounts etc., I know I can get them, but I can only compare list prices here (in fact, for one project we did, BEA offered less expensive than Borland).

    [I cannot get an eval in Europe (of 5.0; at the moment)...]
    {Try it now at http://shop.borland.com/Category/0,1257,3-15-1180,00.html}
    Still, I can only ship to an US Address. Borland also told me so. Shame on them!

    [So basically, yes, BEA and IBM are the market leaders, Borland is the technical leader...]
    {META ranks BAS 4.5 (note, not BES 5.0) at position 2 - http://www.business2.com/articles/mag/0,1640,35691|3,FF.html}
    Couldn't "really" find it ranked on pos. 2, I mean they are there but nothing explained etc. Gartner does not (rank them 2nd), and neither would I. Just a guess, but I'd say they are third.

    For the last one:
    No, BAS does _not_ compare to WL Enterprise but to WL Server, same with IBM (different with V4 though).
    Still, I like the BES model more, just don't have "serious" price quotes at the moment.
    You are however right, someone counting market numbers should include Borland VisiBroker, at least to some degree... I think the outcome will still be 1)BEA 2)IBM 3)Borland(?)
    Pure speculation, but as you said: Yes, lets compare again in one year, as I said... BES is technically superior, a bit of marketing and it'll probably fly ;-)
    Sadly Borland doesn't treat their partners as well as IBM or HP; something that will cost them dear...

    regards

    Messi
  19. <quote>
    http://www.flashline.com/components/appservermatrix.jsp
    is one source, you can easily see there are only two vendors who claim full EJB2
    </quote>

    Oh we are looking at vendors who "claim" they support EJB 2.0?

    <quote>
    Additionally I have no reason to think the two (Sybase & Borland) are lying
    </quote>

    Of course not. Especially on their own Web sites.

    --
    Cedric

  20. <quote>
    Oh we are looking at vendors who "claim" they support EJB 2.0?
    </quote>

    Come on Cedric, you're being unfair here.

    Your company has been the only one (AFAIK) to claim to be EJB2.0 compatible for months, long long before the final spec, and even before the latest draft was out. Borland and the rest of the crowd didn't want to claim this, since it was not correct in their opinion. Now they have worked hard to make their AppServer really EJB2.0 compliant, and at the same time implementing and releasing the ECPerf kit and results to the public.

    Your company, on the other hand, is late (still trying to have a decent ORB, perhaps?) and it seems that your only strategy is to FUD.
    So stop posting and fudding. Back to work! Show us BEA is really the best as you claim. Post your damn ECPerf results.

    JB.
  21. Thankfully none of us has to rely on the PR, evangelist, and marketing staffs of these companies to know whether they are compliant. It doesn't matter whether you've read it on Borland, Sybase, BEA, IBM, or foo vendor's web site, if they haven't passed the 1.3 certification tests they are not yet compliant, bottom line. I'm not saying those tests are so great that they would define an entire product, but they do answer the question of performance. The articles you mention are nothing but marketing people mouthing off.

    No one has passed yet. No one has announced they have passed and Sun has not confirmed that anyone has. I'm sure all the vendors are scrambling to get through this suite to meet whatever deadline Sun imposes on it. These tests should be open not only for the open source folks who claim that they are just as compliant even though they've never seen these tests and these issues, but also because the tests are probably bug-riddled cause we see great specs from Sun but poor implementations and the tests could probably use some good-old brutal open source peer review.

    I'm not asking for flames about this or ECPerf but I am curious about that perf test. It sounds good but most transactional tests focus on the tp and rdbms and not containers and rmi, so has anyone actually looked at the tests to see if it's even a good benchmark for ejb? It may be great but I don't assume it's the standard perf test just because Sun wants it to be.

    McG
  22. <snip>
    so has anyone actually looked at the tests to see if it's even a good benchmark for ejb?
    </snip>
    It is a very much an EJB benchmark. A carefully chosen workload to ensure that the load is more EJB (business logic processing) centric rather than DB or TP centric.

    <snip>
    It may be great but I don't assume it's the standard perf test just because Sun wants it to be.
    </snip>
    It is not a benchmark from SUN per se. It is a benchmark from the Java community. All of the leading App Server vendors are involved in this benchamrk specification.

    - Ramesh

  23. I'm not asking for flames about this or ECPerf but I am >> curious about that perf test. It sounds good but most >> >> transactional tests focus on the tp and rdbms and not >> >> containers and rmi, so has anyone actually looked at the >> tests to see if it's even a good benchmark for ejb? It >> may be great but I don't assume it's the standard perf >> test just because Sun wants it to be.


    ECPerf spec is developed by most of the major J2EE vendors (including BEA, IBM & Oracle), so it should be as good as other JCP specs.

    Mileta

  24. <quote>
    So stop posting and fudding. Back to work! Show us BEA is really the best as you claim.
    </quote>

    Where did I ever say that? (you are the one touting that BAS is the best, by the way)

    I was just pointing out that saying that "company x is the leader" just because company x says so on their Web site is very naive.

    --
    Cedric
  25. I see microsoft has done a fabulous job at dividing and conquering you morons.

  26. "I see microsoft has done a fabulous job at dividing and conquering you morons."

    The irony is that Microsoft doesn't have to do a thing. The J2EE vendors are responsible for their own infighting and will hand Microsoft the market on a platter.
  27. "Microsoft.. conquering.."?

    Am missing the logic here? The 'infighting' here is about which vendor is better and which of compliance-cert &/or ecperf is better. Now, whether all vendors are 'united' or not, is not going to make any diff to which of J2EE & .NET is better? Nor to a purchasing decision. Noone is going to go and get the servers from more than one vendor!

    So guess MSft is not given anything on the platter. This is plain commerce at work.. within the J2EE pie ;-)

    - Ramesh
  28.  "Microsoft.. conquering.."?

    Am missing the logic here? The 'infighting' here is about which vendor is better and which of compliance-cert &/or ecperf is better. Now, whether all vendors are 'united' or not, is not going to make any diff to which of J2EE & .NET is better? Nor to a purchasing decision. Noone is going to go and get the servers from more than one vendor! - ramesh


    First things first:

    1. All J2EE vendors should unite and challenge the .NET benchmarks, It not about Microsoft vs. Oracle and IBM. The headlines are .NET vs. J2EE.

    2. I've seen many high growth customers purchase more than one app server and complain about compatibility amongst them. It's time to stop being short-sighted and cooperate on deployment standards also.
    3. With no cooperation amongst the J2EE vendors, don't be surprised 5 years from now all you got in your pockets are lint and .net to infight about. It's happened before, multiple times because of this exact same reason: No cooperation.

  29. <snip>
    With no cooperation amongst the J2EE vendors, don't be surprised 5 years from now all you got in your pockets are lint and .net to infight about. It's happened before, multiple times because of this exact same reason: No cooperation.
    </snip>

    I think there is a very high level of cooperation among the vendors. The JCP is the best thing that has happened to vendor neutral computing environments. ALL the J2EE vendors are fully behind the process (including ServerManagement & Deployment). And the number of (full) J2EE 1.3 implementations you will see in the mkt in the coming months will be a true indication of this. And J2EE1.3 addresses several inadequacies in J2EE1.2 & EJB1.1 and has a very high level of emphasis on interoperability (A vendor's perspective)

    - Ramesh
  30. 1. All J2EE vendors should unite and challenge the .NET >benchmarks, It not about Microsoft vs. Oracle and IBM. The >headlines are .NET vs. J2EE.


    There are several problems here.

    I do not see how should vendors unite over this. All they can do is publish their own benchmarks, which will then be comparable to each other and not only to .net. I'm pretty positive that there are pure JSP/Servlet/JDBC Pet Shops out there, but obviously no single vendor wants to publish the results. Which leads to the second problem:

    Vendors cannot come out and say "We are not 20x slower then .net. Only 2x." _That_ would be digging the grave.

    What vendors _can_ do is say ok, we put our PS and .net PS on two servers, and in 6 months we see who had more down time. If nimdas, hackers, and other internet wild-life does what they do normally... Well, it could be positive.
  31. Good point Dejan, I was thinking about what a wonderful base of tools and vendors we have to choose from in J2EE. We must exercise our choice in this best of breed approachs against microsoft. I have couple of suggestions:

    1. Use TowerJ on the backend.
    2. Use Oracle's database.
    3. Mix and match different app servers for the best results.
    4. Use a caching module.

    I am certain with this combination, .Net can be pummeled.

    The problem is, we have a good deal of lazy aces lingering about in here infighting; Meanwhile, Greg Leake is in here with his legs up on the coffee table asking for a challenge. The sad fact is: there is more passion towards infighting than competing with .net. If J2EE vendors are intimidated, lazy, or just busy playing the game of semantics, someone fund me and I will do it in two weeks.

     






  32. I see microsoft has done a fabulous job at dividing and conquering you morons.


    No, it's more like

    Microsoft camp:
     user #1: Microsoft is king!
     user #2: Microsoft is king!
     user #3: I love Outlook, it is sooo powerful!
     user #4: M$ is my hero!

    Java camp:
     user #1: BEA kicks ass, and I have the market numbers to prove it!
     user #2: Borland is technically superior, and I have ECPerf to prove it!
     user #3: Well, I haven't decided which vendor to use, so I'll check out both!

    I'll stay a HAPPY java camper, thank you!

    Gene


  33. Comon Cedric, don't be jealous !
    And don't worry too much.
    It's not because Borland has a faster app Server they will grab your market shares.

    Most of the time, the buy decision is not taken by a technical guy but by a manager who has no idea of what ECPerf is.
    What they are looking for is a well known vendor, to prevent themselves from being fired if they've made a wrong decision.
    If only the "best" App Servers were used, I guess some leading vendors would close the shop. (no, no, I won't give any names !!).

  34. Cedric,

    Jean is absolutely correct.
    I didn't know you work for BEA...
    In fact what you say leads me to something... probably it is common at BEA to say "we are fully compliant" though they are not, but it doesn't seem so with other vendors.
    In fact, seldom often is it the case that someone reports compliance to a standard and isn't even close to it... especially in the Java world.
    And again, Borland has a good reputation, especially with this kind of things. You know, BEA has not, though better than many others, I wouldn't rely as much on something said by someone from BEA as I would on something said by Borland (and still, I of course take what they say with a grain of salt ;-)
    I however also stated that I tried both servers with a small EJB2 application, and both worked (more or less), however, Sybase's implementation seems to be clumsy, but BES does the work well.
    In fact we shall see who is certified first...

    regards

    Messi
  35. While both J2EE1.3 and Ecperf are quite important, one point to note is that Ecperf is EJB1.1 benchmark. Will not give any info on how the server does for EJB2.0. Further it gives no info at all on the web container performance. So other data along with Ecperf must be considered when comparing J2EE1.3 performance.

    Ramesh

  36. "Ok, but on what kind of machines? "

    I see no reason to specify machines or DBMS. Naturally both HW and app server vendors will publish results for combinations that perform well and hardware vendors will ally themselves with app server vendors that perform well on their machines.

    One more step towards breaking the integrated stack that the HW and integrated software vendors have a vested interest in maintaining. If WebSphere is the best price performance on IBM HW then good luck to them.

    Although I found it interesting that the first ECperf result was Borland app server on Sun HW and Oracle DBMS.
  37. Hehe, I completely agree with what Giga says...
    Just wanted to say that it is nice seeing that "we" were right. You know, someone else who worked for Borland earlier (don't know his name) and me always stated Borland AppServer was faster than the others, and we always got flamed for it, something I really didn't like, especially by Oracle, BEA and IBM people.
    Hmm, I don't really want to offend anyone (well, probably a bit ;-) but where are "your" vendor's benchmarks now? Where is the great WebSphere? Where is BEA with its great "market leading server"?
    Very interesting someone pointed to a whitepaper from IBM in one of the latest threads where they say something like "they kick the other vendor's butts" and "they are easily beating Sybase, Borland, Oracle, ...". They also stated that "ECPerf results will be available in Oct on theserverside".
    So again, I don't really want to offend anyone but the vendors: The arrogant and almighty BEA and the "we are the best, no matter what others say" IBM, not to forget Oracle with their stupid benchmarks. Please explain, salesman!
    I just think its sad that we'll never see a result from jBoss, but maybe someone could get a result on a similar hardware configuration (V880 or some IBM RS6K) and publish it on jboss.org (?) Would be inofficial, yes, but BEA and IBM will feel even more pressure then (which is something really good I think).

    kind regards,

    Messi
  38. Greetings,

    I am totally with you on this. Of course Borland the best. One thing that was missing until a few weeks ago is Web Container. EJB Container was (and still is) the best but Servlets, JSPs and static pages were not so fast in Java Web Server provided as part of original IAS 4.X. Web Edition of the Borland Enterprise Server (Apache + Tomcat)should take care of that problem now. Hopefully Web Edition of BES will be available soon for download so we can try it.

    Best regards,

    Taras
  39. Hi Messi,

    I hope that I can answer some of your questions.

    First: "Where is the great WebSphere?"

    In about 30% of the accounts that Borland would like to be in.

    Second: "Where is BEA with its great "market leading server"?"

    In about 60% of the other accounts that Borland would like to be in.

    No one doubts that Borland is a reasonably good server. That's why a lot of people use it when they are first learning J2EE.

    This may bother you, but your definition of "best" doesn't always win. For whatever reasons, people (at least those that make decisions in the industry) can agree on Websphere and WebLogic. Obviously, they continue to select those products without ecPerf results and -- surprisingly -- without your blessing.

    Borland could fully support J2EE 1.4 right now and be twice as fast as BEA (we won't bother even mentioning Websphere ;-) and it would not make a difference. Sorry. That is nothing bad about Borland ... it is just the way things work.

    Peace,

    Cameron.
  40. Cameron,

    I'm fully aware of this fact. And still, the servers are chosen because it is "BEA" or "IBM" (especially with IBM).
    This however doesn't mean it cannot change. In fact, quality products can, especially in this very expensive sector where people like facts at least a bit more than, say the client side.
    And after demonstrating BES to some customers they indeed switched and didn't choose BEA or IBM. And in fact, they are lucky with it.
    Again, it makes no difference for me whether I seel my app on top of WebSphere or WebLogic or BES, but if my customer wants consulting, I will tell him that, while BEA and IBM are market leaders and have some nice add ons, and they are a safe choice, ... BES is, technically speaking, far superior.
    And you know, performance _does_ matter in this area, as the old BAS 4.5 performed more than twice as fast as e.g. WebSphere 3.5. This means half the hardware and half the AppServer licenses. It means money ;-)
    We even had customers who were very unsatisfied with WebLogic or WebSphere and searched for a better solution. They chose BAS after evaluating some servers.
    You see, I'm not a BEA or IBM foe, they really know how to sell things, and their products are not bad (at least since WebLogic 6 and WebSphere 4), but after experiencing difficulties some customers begin to ask whether there is a better solution. And indeed, there is (for some applications, I don't say "Borland is always the right choice).
    I also admit that there are difficulties with BAS, but I think its technically better and recommend it to everyone who wants a good solution, not necessarily from the market leader.
    And that is everything I wanted to say... where is the "best appserver in the world"... I define "best" as "technically best" here, you are right, the question was not "Where is the appserver sold most often?". YOu get my point I hope ;-)

    kind regards,

    Messi
  41. I think these tests are a big waste of time.
    Certain applications perform better in one app server while others perform poor and vise versa. It's all as good as the architecture.
     
    The App Server vendors put out tests tuned for their own App Servers, and in reality, when building the application on the server of choice, we would apply these optimizations and best practices.
    Making an independent benchmark really independent means putting together an application and platform that is not a reality in most situations.

    Compliance is another cushion people use to make a customer beleive that their product is better than the next. Although compliance is somewhat important, it isn't everything. Eventually every piece of the enterprise will be based on some standards at the sacrifice of performance. Vendors sell compliance to customers as if it is vital when in essence it's not. A customer will work on a project with this added worry that by the time the system is in production they are not compliant anymore anyway. Then the vendor convinces customers to up the system to the latest standard. If customers allow it, vendors will drive them crazy. If compliance was so important, Microsoft would be no where.

    Just look for the best solution for your product. If you are a Mainframe shop with MQSeries, WebSphere is the best choice. If you are a Tuxedo shop, WebLogic is the best, etc.... If you were a Visigenic CORBA shop, Borland may be the best.

    I look for a product that can solve all my problems. Let's face it, I know alot of people here on this site are not WebSphere fans, but know other vendor offers a full range of products like they do, from development to production, the best messaging in the business, one of the top App Servers in the industry, Great development tools, great legacy integration, And compliant with production ready versions of the standard.

    No one can convince me otherwise.



  42. I think these tests are a big waste of time

    And I think you're just too lazy or too rusty to think about it.

    >>The App Server vendors put out tests tuned for their own
    >>App Servers, and in reality, when building
    >>the application on the server of choice, we would apply
    >>these optimizations and best practices
    Oh, so let's have a look at the Pet Store cat fight... I think most people agree that vendors are not trying to build a robust application. They're simply trying to make an application that does the same as the Pet Store and allow it to be a hell for maintenance.
    I do not understand you claim that you apply the same "best practices" in a realistic application than those vendors do in their benchmarks!

    >>Just look for the best solution for your product.
    >>If you are a Mainframe shop with MQSeries, WebSphere is the best choice.
    >>If you are a Tuxedo shop, WebLogic is the best, etc....
    >>If you were a Visigenic CORBA shop, Borland may be the best.
    And use JBoss if??? Never thought about it? Not cool/expensive enough?
    However, you've got a very good point at stating that every application may lead to a small subset of all available J2EE application servers. Nevertheless, I believe that the claims that all server vendors make, nead to be validated using an independant benchmark, such as ECperf.

    >>I look for a product that can solve all my problems.
    I totally agree with you

    >>No one can convince me otherwise.
    That's where you're wrong: you're too rusty!
  43. I look for a product that can solve all my problems.

    >I totally agree with you

    Oh, I'd like a magic wand too. Right now I settle for a screwdriver that fits the screw.

    My concern is that ECPerf is going to be too diversified over hardware platforms to be usable. Bang/buck benchmarks add more value, but up to the limit, because there _is_ a minimal buck for given hardware platform, and lots of companies around are out of it's range.

    As it is, ECPerf is on a good way to become one of the "mine is bigger then yours" marketing hype headliners-for-a-day.
  44. My concern is that ECPerf is going to be too diversified

    >>over hardware platforms to be usable. Bang/buck
    >>benchmarks add more value, but up to the limit, because
    >>there _is_ a minimal buck for given hardware platform,
    >>and lots of companies around are out of it's range.
    >>
    >>As it is, ECPerf is on a good way to become one of
    >>the "mine is bigger then yours" marketing hype headliners
    >>for-a-day.
    I disagree. The benchmark is designed to produce reproducable results. I suggest reproducing the benchmark runs on your own hardware. Borland puts a good example by publishing a bundle for this purpose.
    So what you get isn't a "mine is bigger then yours marketing hype", what you get is: "that one is faster than the other on my hardware"
  45. I disagree. The benchmark is designed to produce >reproducable results. I suggest reproducing the benchmark >runs on your own hardware. Borland puts a good example by >publishing a bundle for this purpose.

    >So what you get isn't a "mine is bigger then yours >marketing hype", what you get is: "that one is faster than >the other on my hardware"

    Sure, one can run it's own benchmarks. But, personally, I've never worked for a company for which this is an option. There are not enough man hours, equipment nor knowledge available for getting, setting up, running, clustering, tweaking, etc. WL, Websphere, BAS, JBOSS, EAS and others. And even if you manage it (somehow), that was only the start... Where are the stability, known issues, web conteiner performance? How do you weight "WL gives 0.3 bangs/$ more then WS, but freezes once a week while WS freezes once a month" in overall results?
  46. Sure, one can run it's own benchmarks.

    >>But, personally, I've never worked for a company for
    >>which this is an option. There are not enough man hours,
    >>equipment nor knowledge available for getting, setting
    >>up, running, clustering, tweaking, etc. WL, Websphere,
    >>BAS, JBOSS, EAS and others. And even if you manage it
    >>(somehow), that was only the start... Where are the
    >>stability, known issues, web conteiner performance? How do
    >>you weight "WL gives 0.3 bangs/$ more then WS, but
    >>freezes once a week while WS freezes once a month" in
    >>overall results?
    I understand the problem you're pointing at; I'm running the ECperf benchmark on JBoss now and I AM TRYING to get in running on BEA WebLogic, so I know how much time/effort is required only for the performance results...
    As for the stability: ECperf may not be able to address this issue, but can you point out a cost-effective alternative?
    Regarding Web container performance: I've just visited the TPC-W results site. Why aren't there any results for J2EE products? Do you know other independant benchmarks for the web tier? (SPECweb99 is for static web resources... what about the web container then?)
  47. I understand the problem you're pointing at; I'm running >the ECperf benchmark on JBoss now and I AM TRYING to get >in running on BEA WebLogic, so I know how much time/effort >is required only for the performance results...


    Exactly. And once you are done, then try changing OS, number of CPUs, clustering, VM... Personally, I'd never wish that kind of a nightmare to anybody.

    >As for the stability: ECperf may not be able to address >this issue, but can you point out a cost-effective >alternative?

    No. :) I just wanted to say that ECperf is only a part of overall server usability. For some shops pure EJB performance can be crucial point, for some not, but in my experience ejb performance is anyway going to be drowned in scalability, stability, networking and db performance issues.

    Anyway, whatever you are building today, you are building for next several years. Soon your average hardware/j2ee server/VM platform is probably going to be double as fast as now, for less $. (Just try changing that 750 MHz AMD CPU from a year ago to 1.x GHz on your linux box, and see your apps getting wings) So, in my opinion, it's more important to make it _work_ then to make it blazing fast.
  48. And I think you're just too lazy or too rusty to think about it.


    You are you and do you know me, do you know what application servers I have used and in what situation.

    >> I think most people agree that vendors are not trying to >> build a robust application. They're simply trying to
    >> make an application that does the same as the Pet Store >> and allow it to be a hell for maintenance.

    What people, everyone has different results for the same app, something is being done different.

    >> And use JBoss if??? Never thought about it? Not
    >> cool/expensive enough?
    Use JBOSS when I can't afford anything else. I personally would never think about using it except for education. And I don't think it is cool enough.

    >> That's where you're wrong: you're too rusty!
    If name calling is all you can do, don't respond to me. How can you call me wrong for my own opinion. Again, you don't know who I am or what I have done, nor should I justify it for someone with teenage remarks.



  49. You are you and do you know me, do you know what

    >application servers I have used and in what situation.
    I'm sorry, I did not want to insult you, I just wanted to wake you up.

    But first you were saying:
    >>>I think these tests are a big waste of time
    So you are stating that an independant benchmark like ECperf is not an option.

    Then you say:
    >>>The App Server vendors put out tests tuned for their own
    >>>App Servers, and in reality, when building
    >>>the application on the server of choice, we would apply
    >>>these optimizations and best practices
    I could not understand why you were happier with the results from benchmarks published by vendors. (I still can't) I'm sorry if I prejudged you, but can you explain me the logic behind this?

    Because you weren't even giving the ECperf benchmark a try, I said:
    >> That's where you're wrong: you're too rusty!

    I guess I came over wrong. However, in my opinion, it is not the right attitude to join a discussion when you think from the start that nobody can teach you something.

    >How can you call me wrong for my own opinion. Again, you
    >don't know who I am or what I have done, nor should I
    >justify it for someone with teenage remarks.
    I have no problems with your opinion.

    >>>No one can convince me otherwise.
    You came in and said: "hey, this is what I think, and everything else is bullshit". That's why I reacted "with teenage remarks"
  50. I could not understand why you were happier with the

    >> results from benchmarks published by vendors. (I still >>can't) I'm sorry if I prejudged you, but can you explain >>me the logic behind this?

    I never mentioned here that these choices made me happy, as a matter of fact, I think that these bench marks are not relevant in choosing an app server. I stated that the choice should fit the problem. The above statement only says that after choosing the app servers, we would apply the same techniques in making it optimal.

    >> I guess I came over wrong. However, in my opinion, it is >> not the right attitude to join a discussion when you
    >> think from the start that nobody can teach you
    >> something.

    If I felt I could learn nothing, I would not even look at this web site. I don't think that by stating I feel that one vendor offers the most choices says I have nothing to learn. No where do I state one app server is better than the other. My original comments actually state that ones App Server choice should fit the easiest migration path. It is rare these days to build a product from scratch.

    Anyway, I don't mean to come accross as snotty, but if you feel my comments be-littled anyone, I'm sorry. I gave a couple of scenerios and did not include JBoss(I didn't think I had to list every single choice to get my point accross).



  51. Given the heated discussion, we (BEA) wanted to provide the community with our official position on ECPerf:

    BEA is actively involved with the ECPerf initiative and will be announcing our results in the near future. The ECPerf process is involved because we will be releasing numbers on a variety of hardware / databases and this requires partnering with multiple vendors. We have a team of engineers focusing on this effort and working with the ECPerf community to finalize this work over the next few months. Additionally, BEA is in the final stages of engineering on a major new version of WebLogic Server, so we have had some delay in releasing our numbers so that we could migrate to the newer server version.

    Thanks.

    Tyler Jewell
    Director, Technology Evangelism
    BEA Systems, Inc.
  52. Tyler,

    Given the issues with ecPerf as a closed "J2EE-only" benchmark, I am curious if BEA will also be releasing any TPC-W numbers so that your technology can be compared to non-J2EE products, or participating in any publication-based shootouts for the same purpose?

    Thanks for the info,

    Greg Leake
    Group Product Manager
    Microsoft Corp.
  53. Given the issues with ecPerf as a closed "J2EE-only"

    >benchmark, I am curious if BEA will also be releasing any
    >TPC-W numbers so that your technology can be compared to
    >non-J2EE products, or participating in any publication-
    >based shootouts for the same purpose?

    Can somebody explain me why the only server listed in the
    TPC-W results is Microsoft Internet Information Server 5.0?

    I'd be very happy to see some J2EE products in that list.
  54. Greg,

    I would refrain from saying J2EE-only, because there is nothing that is 'only' with J2EE. I'd say that 'only' fits better with .NET.

    The J2EE-specification is 100% open, the ecPerf is 100% open. More or less everyone is behind J2EE, except MS. The ecPerf-testing is trying to provide a better tool for customers to chose their vendor for their Enterprise Business Framework.

    I'm sad that you (MS) didn't provide your own J2EE-implementation, then you wouldn't have to bad-mouth the ecPerf-tests.

    Why don't you tell us why you prefer a closed environment, when there is an open alternative?
  55. BG Gullburg,

    There is nothing open about ecPERF. I suggest you read the spec and license agreement. If ecPERF is so open, let me ask you this: Can PHP on LINUX enter? Answer: no. Can PERL on Solaris enter? answer: no. Don't be so blind. ecPERF is clearly an effort by Sun and other J2EE app servers to hide from well-established benchmarks where any technology can compete, such as TPC-W. I still have heard no good explanation as to why Sun, BEA, IBM et al don't simply use the TPC-W? As for bad mouthing the ecPERF, it does not look like I am the only one asking questions. Lots of Java developers seem to wonder where all the ecPERF results are, and also wonder why J2EE needs its own closed benchmark and cannot compete in open benchmarks with other technologies. What is Sun afraid of?

    Greg Leake
    Group Product Manager
    Microsoft Corporation
  56. Hi Greg,

    You said, "There is nothing open about ecPERF."

    http://www.dictionary.com/cgi-bin/dict.pl?term=disingenuous

    When will ecPerf run on .NET? If you want to ante on the "open" term, you need to at least stay at the table.

    Peace,

    Cameron.
  57. Cameron,

    Sticking to the point...your response is evasive. ecPERF is a closed benchmark, pure and simple. The question isn't when .NET and other non-J2EE technologies can "run" ecPERF, the question is when will Sun open up the benchmark and let non-J2EE implementations enter. The ecPERF benchmark should really be renamed "j2eePERF".

    You still have not answered my question (rather you have changed the topic): Why do you think Sun and J2EE vendors, instead of working with TPC-W, have created a benchmark where non-J2EE products cannot compete? What do you think Sun and these vendors are afraid of, especially since these very same companies such as Sun, BEA and IBM have a long history of working with the TPC on benchmarks such as TPC-C using their non-J2EE based products.

    -Greg
  58. You still have not answered my question (rather you have

    > changed the topic): Why do you think Sun and J2EE
    > vendors, instead of working with TPC-W, have created a
    > benchmark where non-J2EE products cannot compete?

    TPC-W is (mainly) a DBMS benchmark. The vendors (I presume) are interested in showing how fast the application servers are, which are totally different beasts than the TP Montiors you describe (MTS, TxSeries, Tuxedo). That's why there's the specific benchmark for application servers that support the standard (J2EE).

    The question to ask is not 'why does ecPerf focus on J2EE?' But, why don't proprietary technology vendors support the J2EE standard?
  59. No, TPC-C is a RDBMS benchmark, TPC-W is a Web-based ecommerce benchmark by the same TPC Group.

    -Greg
  60. Hi Greg,

    Thanks for responding ... I was starting to think you were just here to post flame bait. ;-)

    "Sticking to the point...your response is evasive."

    I'll take your word for it. I don't remember what I wrote and I'm to lazy to go back and read it.

    "ecPERF is a closed benchmark, pure and simple."

    Greg, I don't expect you to officially agree with me on the meaning of the terms "open" and "closed". That doesn't mean that I won't question what I see as excessive silliness in your use of the terms. Kind of like England and the US, two nations separated only by a common language.

    "The question isn't when .NET and other non-J2EE technologies can "run" ecPERF, the question is when will Sun open up the benchmark and let non-J2EE implementations enter."

    I went to http://ecperf.theserverside.com/ecperf/ and read the title: "ECperf is a benchmark and implementation for measuring performance and scalability of J2EE servers". Apparently you can get more information on its origin from http://jcp.org/jsr/detail/004.jsp (that's the "community process" by which Java continues to evolve).

    I think it is fair to say that .NET would have to support big parts of the J2EE API in order for ecPerf to run on it. It would appears that you don't like that, but it is a J2EE benchmark, so I'm not sure why you would expect to be able to change it so you could post numbers from .NET that were based on a different implementation. Unless I'm misunderstanding your intent, that would be as misleading as re-writing the Petstore application for performance ;-)

    "The ecPERF benchmark should really be renamed "j2eePERF"."

    I'll agree with you there, except in the spirit of things I'll capitalize it as J2EEperf.

    "You still have not answered my question (rather you have changed the topic):"

    That reminds me ...

    "Why do you think Sun and J2EE vendors, instead of working with TPC-W, have created a benchmark where non-J2EE products cannot compete?"

    I would suggest two reasons:

    1) They want a way to compare J2EE performance
    2) They felt that TPC-W did not show their products in a favourable light

    Regarding the second, I assume that they didn't like comparing against more vanilla "W" offerings and they wanted a benchmark that would compare the Java application servers hosting multi-tiered logic and doing all sorts of buzzword compliant and complex things.

    I don't see that as bad ... since there are a beaucoup of Java applications servers all more or less J2EE-ish or -ized, it is nice to have some way of comparing performance on the things that people are actually buying them for.

    As to the issue of TPC-W submissions, it is unfortunate that vendors or third parties don't publish those numbers ... personally it doesn't bother me that various app servers don't perform the basic tasks as efficiently because I can put the right type of software to play there. We even use this IIS product sometimes to sit in front of an application server like Weblogic, and it works pretty well with the HTTPS protocol on commodity hardware. (Unfortunately we're always having to patch it because of these massive strings of executable code that get thrown at it, but that's a different topic again.)

    "What do you think Sun and these vendors are afraid of, especially since these very same companies such as Sun, BEA and IBM have a long history of working with the TPC on benchmarks such as TPC-C using their non-J2EE based products."

    Frankly, I don't think that they feel a lot of pressure to do TCP-W benchmarks, otherwise you know that Oracle would somehow have the highest TCP-W numbers by a couple orders of magnitude ;-). What businesses are looking for today are good solid scalable implementations of the J2EE spec, and these companies are delivering pretty well in that arena. It's too bad that your company decided yet again to go it alone, but at least with the web services support that you've been forced to do, your customers will be able to interoperate to some extent and even migrate if they have to.

    So Greg, do you think that .NET/IIS will support J2EE APIs before too long?

    Peace,

    Cameron.
  61. Cameron,

    At least I got you to agree that J2EE vendors do not work with TPC-W becuase it will likely "not show their products in a favourable light." As for other statements in your post, such as Microsoft "being forced to support Web Services," well, I think you should understand that Microsoft has been one of the key supporters of Web Services from the beginning, even helping, along with IBM and others, to author the specification for SOAP/UDDI, etc. in the standards body. Any objective industry observer would conclude that with respect to Web Services and interop via XML, Microsoft has been in the forefront (along with some other vendors)....while Sun has been dragging its feet and only begrudgingly supporting late in the game.


    Greg Leake
    Group Product Manager
    Microsoft Corporation
  62. Greg,
      I believe there are valid reasons for J2EE Vendors not going with TPC-W and having ECperf. Performance is Just One goal for J2EE. J2EE Goals include "Providing a simplified way for application development using standardized, modular components, by providing a complete set of services to those components, and by handling many details of application behavior automatically, without complex programming".
     J2EE Server may not be the best server as far as performance is considered. But J2EE is THE BEST way to develop applications today. An application developed using J2EE is scalable, extensible by design.
     Coming to TPC-W, it doesn't talk whether application developed need to extensible, maintainable by design, scalable by design and is only worried about the numbers. Applications developed using J2EE has these factors as primary goals.
     J2EE applications might not have THE BEST performance as it has other goals too. Microsoft might come up with NUT STORE Examples (A poor design of Pet Store) a get Marketing HYPE about numbers but that not what We Developers want.
     BTW Here is what I heard recently regarding .NET (and obviously I believe it too): .NET exist not because there exists a business problem that needs to be solved but Microsoft has a problem and that is "to make money".
     Well we are not interested in making money for you as we have a perfect way of designing and developing our applications.
     I do not work for any J2EE Vendor or Sun but just a Happy developer who love J2EE.

    Kumar.
  63. Hi Kumar,

    >>> I believe there are valid reasons for J2EE Vendors not going with TPC-W and having ECperf. Performance is Just One goal for J2EE.

    You seem to imply that ECPerf was not designed to compare performance results of J2EE solutions :-). Let’s just say this contradicts with the definition of the ECPerf benchmark. The section 8.4 of the ECperf spec mentions that the purpose of benchmark results publication is simply to allow vendors to publicize the performance of their products. This make sense, since a vendor-independent benchmark process is the ONLY way to measure scalability of a certain solution in relation with various metrics (database size, workload, number of connections, etc.).

    >>> J2EE Goals include "Providing a simplified way for application development using standardized, modular components, by providing a complete set of services to those components, and by handling many details of application behavior automatically, without complex programming".

    I guess the goals above will apply exactly to .NET also. Do you think the goals above points to something not to be found in .NET in a similar form?

    >>> Coming to TPC-W, it doesn't talk whether application developed need to extensible, maintainable by design, scalable by design and is only worried about the numbers. Applications developed using J2EE has these factors as primary goals.

    If you take a detalied look to TPC-W in the light of the services provided by J2EE you will agree that it may be a very representative benchmark for J2EE performance and scalability (let’s mention only the fact that TPC-W exercise much more the middle tier than the database tier). Personally, I don’t see a single reason why a TPC-W solution cannot be implemented using J2EE – besides it will be a good test of anecdotical affirmations like “An application developed using J2EE is scalable, extensible by design”.

    >>> BTW Here is what I heard recently regarding .NET (and obviously I believe it too): .NET exist not because there exists a business problem that needs to be solved but Microsoft has a problem and that is "to make money". Well we are not interested in making money for you as we have a perfect way of designing and developing our applications.

    Fact is that the reality looks pretty different than what you’ve just mentioned. Right now, by far the most expensive Application Servers today are J2EE ones (check the prices for IBM and BEA J2EE products). I think this definitely is a “business problem”, isn’t it? BTW, the .NET Framework SDK can be freely downloaded from the following address: http://msdn.microsoft.com/net/framework

    Thanks, Adi

    P.S. These posts are purely personal opinions, that may or may not represent the official position of my company (Microsoft Corporation).
  64. Adi,

     Its nice to know that Microsoft Employees are reading ECperf spec :-)

    >>> You seem to imply that ECPerf was not designed to compare performance results of J2EE solutions :-).

     I was quoting Goals of J2EE and not ECperf. Please do read my post again. ECperf is EJB Benchmark. TPC-W allows any poor frameworks letting them get better numbers loosing other important aspects of design.


    >>>I guess the goals above will apply exactly to .NET also. Do you think the goals above points to something not to be found in .NET in a similar form?

    Really?? Then why would any one comeup with Nut Store Version 1 which has SQL Server Data Readers in ASP.NET Pages.

    >>> Right now, by far the most expensive Application Servers today are J2EE ones.
    And by far the Most Cheapest ones are J2EE Ones too. JBoss Costs you 0$. You might want to download it from www.jboss.org.

     As always is the case with Microsoft we got buy Visual Studio to develop application using .NET right? But you can download Netbeans from http://www.netbeans.org for free.


    Kumar.
  65. Hi Kumar, some replies again:

    >>> [adi] You seem to imply that ECPerf was not designed to compare performance results of J2EE solutions :-).
    >>> [Kumar] I was quoting Goals of J2EE and not ECperf. Please do read my post again. ECperf is EJB Benchmark. TPC-W allows any poor frameworks letting them get better numbers loosing other important aspects of design.

    [adi] My point was that the way you quoted the J2EE goals put in question the whole point of doing benchmarks: i.e. sacrificing performance/scalability by treating it as an optional, second-rate goal. Again, I guess we all agree that the only way to measure the scalability of a certain solution is to measure its performance in relation with various metrics – and this is exactly the reason why Ecperf benchmarks were invented. In most cases you DO care about performance, since it DOES matter how much perf you can squeeze from a hardware box. And these concerns will usually drive business decisions when you want to acquire new hardware equipment, or choose the right platform and software suite, or even choosing a new App Server/ Container, etc.

    And again: why do you think that a good J2EE app design will NOT have a comparable perf results compared with other non-J2EE, TPC-W entries? If this is true then, sorry, there are some overhyped expectations with respect to J2EE scalability.

    >>> [adi] I guess the goals above will apply exactly to .NET also. Do you think the goals above points to something not to be found in .NET in a similar form?
    >>> [Kumar] Really?? Then why would any one comeup with Nut Store Version 1 which has SQL Server Data Readers in ASP.NET Pages.

    [adi] I didn’t found any usage of SqlDataReader in the ASP.NET pages, in the latest version of the .NET PetStore.

    BTW, the data access in this sample uses the ADO.NET data provider for SQL Server but the code can be easily converted to another data provider or even to the OleDb .NET data provider, etc. The interface differences are minimal between these approaches given the fact that ADO.NET model is pretty much independent from the particular data source. BTW, you did not address my original question concerning .NET.

    >>> [Kumar] And by far the Most Cheapest ones are J2EE Ones too. JBoss Costs you 0$. You might want to download it from www.jboss.org. As always is the case with Microsoft we got buy Visual Studio to develop application using .NET right? But you can download Netbeans from http://www.netbeans.org for free.

    I was talking about some App Servers (from IBM or BEA for example) which have a huge price compared with the .NET solution.

    Anyway, the software price of the .Net solution (and also the price of a “free” app server) is usually small compared with other costs: First you must tke into account development/maintenance costs in either case – and Microsoft addresses them by creating a good integrated IDE – Visual Studio.NET – not sure about NetBeans. There are also integration costs that MS solution addresses by increased interoperability - web services or bridging software like the MSMQ/MQSeries bridge, and integration software, like Host Integration Server or Biztalk, etc.

    There are other problems that are addressed by .NET Framework and not by J2EE, like integration between existing programming languages (so you don’t have to rewrite everything in Java), OS integration, a simpler deployment process, etc.

    Adi
  66. And again: why do you think that a good J2EE app design will NOT have a comparable perf results compared with other non-J2EE, TPC-W entries?


    Because as in case with Nut Store a poorly designed app can manipulate results.


    >>>I didn&#8217;t found any usage of SqlDataReader in the ASP.NET pages, in the latest version of the .NET PetStore.
    Its part of Version 1 not 1.5.


    >>>There are other problems that are addressed by .NET Framework and not by J2EE, like integration between existing programming languages (so you don&#8217;t have to rewrite everything in Java), OS integration, a simpler deployment process, etc.

    As one of My friend pointed out imagine 5 different developers in a project developing application in 5 different languages.

    >>>so you don&#8217;t have to rewrite everything in Java
    Yep but you encourage to rewrite in C# right?

    BTW If some can write .NET Applications using any language why did microsoft invent C#?

    Kumar.


  67. [adi] And again: why do you think that a good J2EE app design will NOT have a comparable perf results compared with other non-J2EE, TPC-W entries?

    >>> [Kumar] Because as in case with Nut Store a poorly designed app can manipulate results.

    [adi] First, you have yet to define why .NET Pet Shop is a poorly designed app. I can just assume that your definition of a “poor design” is “a non-J2EE” design :-) Besides, I really don’t see any results manipulation. You can download the .NET Pet Shop and Java Pet Store apps and repeat the tests yourself on your specific hardware configuration...

    Concerning TPC-W (as well as any other TPC benchmark): TPC-W was designed (among other things) specifically to avoid manipulation of results – so I’m not sure what is your argument. TPC is a vendor-independent organization and every participating vendor has all interest to prevent these kinds of things. For example any TPC participant can vote against a benchmark result if it finds a “benchmark special” i.e. a specific manipulation of tests results using uncommon design practices. You can download the TPC-W spec from www.tpc.org.

    >>> [Kumar] As one of My friend pointed out imagine 5 different developers in a project developing application in 5 different languages.

    I’m not sure what the programming language has to do with a certain project. If you have good integration between those languages then why it shouldn’t work? Let me put the question in this way: do you really care about the languages used to implement a certain OS? I don’t think so.

    And, even in OOP world, language independence was promoted from a long time ago by Component-based infrastructures (CORBA, COM). The language is (almost) irrelevant as long as you stick on classical design techniques as modularity, encapsulation, rigorous interface design, enforcing contracts, etc.

    >>> [adi] so you don&#8217;t have to rewrite everything in Java
    [Kumar] Yep but you encourage to rewrite in C# right?

    Well, that’s the point – you don’t have to <b>rewrite</b> anything in C#. You can stick with your existing language: C++, VB, etc (as long this is not an exotic language not supported yet by .NET). However, if you want to start a new project, then you may want to consider C#.

    >>> [Kumar] BTW If some can write .NET Applications using any language why did microsoft invent C#?

    C# is nothing more than a language-related incarnation of all features offered by .NET (for example garbage collection, attributes, properties, value types, boxing, the .NET common type system, etc.). However, to be noted that programming .NET apps in C# doesn’t give you any essential advantages over other languages like C++/VB/J# etc. – since .NET runtime is designed to be language independent and <b>not</b> specific to C# only.

    Thanks,
    Adi
  68. BTW If some can write .NET Applications using any

    > language why did microsoft invent C#?

    Because C# is a quite decent language compared to C and VB?

    /F
  69. Kumar,

    To echo a point made by Adi, the .NET Pet Shop is not a poor design compared to the Java Pet Store. You should look at the latest version (1.5). This includes data classes wrapping all data access. So you will not find data readers in ASPX pages as you suggest...You will find a fully factored 3-tier design that we think is easier to maintain than the the Java Pet Store, and has a much smaller code base. And as Adi points out, it can be used against Oracle, DB/2, etc. with a trivial amount of changes in the ADO.NET data access classes. The bottom line is that we stand behind the design of the .NET Pet Shop as a better design than the Java Pet Store in terms of productivity, ongoing maintenance and performance/scalability.

    In terms of software license costs, .NET is a much less expensive solution than the Java solution if you are deploying Java on the most widely used enterprise J2EE app servers such as Websphere or BEA. If you compare the software costs to deploy the .NET solution vs. deploying the Java Pet Store on IBM Websphere, BEA WebLogic, Oracle app server, Borland, etc. you will find that the cost is much, much lower no matter the hardware you deploy Java on or the OS in use. Keep in mind the .NET is free, and can be freely redistributed by any customer. So to deploy .NET requires only a licensed copy of W2K Server (around $4,000 for W2K Advanced Server on up to 8CPUs)...to deploy on Websphere or BEA you will be paying upwards of $10,000 per CPU, plus the cost of the OS (at least $80,000 on an 8-CPU server). So there is a huge difference, more than an order of magnitude and this cost is very significant.

    So in short, I think the .NET Pet Shop provides a more elegant design, achieved in 1/4 the amount of code, offers huge performance gains over Java Pet Store, and the cost to deploy is a fraction of the cost of the most widely used "enterprise" J2EE app servers on the market, including Websphere and BEA (not to mention Oracle, Borland, etc.). The great thing is that customers have access to all the code to both versions, so they can do their own analysis and even perform their own benchmarks. This may be especially important since the J2EE vendors are not participating in open benchmarks such as the TPC-W.

    Greg Leake
    Group Product Manager
    Microsoft Corporation
  70. Greg>>So in short, I think the .NET Pet Shop provides a more elegant design, achieved in 1/4 the amount of code, offers huge performance gains over Java Pet Store, and the cost to deploy is a fraction of the cost of the most widely used "enterprise"

    That what Microsoft said before inventing .NET about DCOM and every other technology in that line. Remember Roger Sessions debate about COM+ vs EJB?

    Greg>>>If you compare the software costs to deploy the .NET solution vs. deploying the Java Pet Store on IBM Websphere, BEA WebLogic, Oracle app server, Borland.

    No smart J2EE customer would use the above mentioned server for PetStore application. You might want to look at Tomcat and JBoss.

    The Major Advantage with J2EE is that we have a choice (to choose App servers and IDE) based on cost and many other factors. Thats what .NET wouldn't let their customers do.


    Kumar.
  71. Greg,

    You know you are really completely wrong here...
    Hosting J2EE applications on an 8 CPU server is... guess... free!
    -) The server has to be bought, yes (no difference)
    -) The OS is - surprise - free! No matter whether you buy a SPARC server or an IBM Power, the OS is, be it Solaris or AIX, free. And you know Solaris and AIX have magnitudes lesser downtimes than Windows? Even if someone would have the (IMO strange) idea to buy an 8 CPU x86 server, Linux could be deployed... still more stable than MS WinXY, still cheaper ;-)
    -) Application server could be jBoss for - guess - nothing! or SAP's InQMy server - for 800 Euro per Server or CPU (don't know exactly)? Orion for US$ 1500/Server is also an alternative.

    Concluding we can say that for less money we'll get a more stable system with Unix/J2EE than Win/.NET, right?
    But you see, this is not the point. The point is _freedom of choice_. If jBoss has a bug and doesn't work, I can use something else... this doesn't work with .NET.

    Greg, tell me: Why has MS ported .NET to FreeBSD? Why not to Linux? (This would really be easy) Why may it not be used for commercial applications? When will we see it on Solaris and AIX? on zOS?

    And, regarding your other posts, you cannot simply discuss Microsoft's "embrace and extend" methods away... Microsoft hasn't been taken to the court for nothing... the Java lobby dislikes MS for a good reason, and so do other vendors.
    You cannot simply do away with all of this by simply crying ".NET is multi-platform" and "We work the standards way now!", ".NET petshop is faster" and expect people to believe you, especially without proving it. Port .NET to Linux, Solaris and AIX (not _that_ difficult after you have a FreeBSD port) and make them available for commercial use. And you'll see, people will believe you.

    I know this is partly no exact reply to your posts, but the basic tenor of your posts is always the same - and I dislike this you know.

    kind regards,

    Messi
  72. Hi Messi,

    My sentiments exactly. We use jBoss to prototype , develop and test and then BEA for our UAT , production environment.
    I can deploy and test jBoss on Linux , NT or Solaris. BEA runs on an E10000 with Solaris as we have a wack load of transactions and need an encredibly stable system.

    What I'm trying to say is that we as a development team have choice - J2EE servers, OS's and hardware - where does Microsoft and .NET give you this much choice ?.

    IMO Microsoft sucks and always will.

    Luigi
  73. Tyler,

    I am also aware of the french magazine ECperf runs I would like to hear a response on this in line with your current open and honest policy. Could you tell me what are the main drivers behind the fortcoming release of WebLogic without giving it all away, ;-).

    Could performance be up there at the top? I did notice that at the begining of the year BEA had advertised for engineers to work mainly in the ECperf area.

    I wonder if it was not for ECperf would some of the performance strives made by appserver vendors in the last year and probably into the next year really have been initiated and made. I think its good to have competition at the technical level as well as the commercial level. I weclome .Net and of course Gregs presence and contributions on the serverside.com.

    <aside>
    I do not know the exact details of why Borland and IBM did not allow the publication of their results considering that they did pass.

    Was Sysbase not involved in this ECperf showdown.
    </aside>

    William
  74. Hi Greg,

    Greg: "At least I got you to agree that J2EE vendors do not work with TPC-W becuase it will likely "not show their products in a favourable light.""

    You're pretty funny ;-)

    Greg: "As for other statements in your post, such as Microsoft "being forced to support Web Services," well, I think you should understand that Microsoft has been one of the key supporters of Web Services from the beginning"

    If Microsoft could have made the Blackbird project work in the market, you would have gotten rid of support for all public spec'd protocols, and if you don't know that, then you've only worked at Microsoft long enough to find out that the soft drinks are free. ;-)

    (If you cannot remember all the code-words, Blackbird was the project from Microsoft that bragged that it would replace the "web" and the Internet as we know it. Too bad the world didn't stop and wait for that one either.)

    Basically, since Microsoft lost every round in which it tried to supplant standards, it decided to "out-standard the standards", but that doesn't make Microsoft's offerings any more palatable when those solutions still include Microsoft Lock-In(tm) as a core component.

    Don't misunderstand me -- .NET and C# are very Cool(tm), but that lock-in is unacceptable. Anyone who buys into .NET better be choosing it because they -want- to be locked into Microsoft's products 100%. Some companies do, and that's their choice. The vast majority of us have already tried a little of that koolaid, and we decided it wasn't safe.

    Some of the steps that Microsoft is taking such as standardization through ECMA would be more encouraging if it were also providing full source and licensing full ports (not tiny meaningless subsets) to real vendors that take real stands in the industry for supporting standards -and- interoperability. Right now, all the talk about standards is just a gimmick by Microsoft. "Oh, granny, what large eyes you have!"

    Greg: "..while Sun has been dragging its feet"

    Yes, I honestly can't figure that one out. Lead, follow or get the h*ll out of the way. I can't tell if they are dragging their feet or just slow on the uptake. At any rate, they gave you a chance to get back into the game, so I'm sure you don't mind all that much ;-)

    Peace,

    Cameron.
  75. Cameron,

    It's funny how Blackbird has come up on this thread...possibly becuase of n n's earlier post.
    You have an overactive conspiricy-theory driven mind here, although I understand where your perceptions come from (and I also understand you wanting to change the topic here). But to answer your question, I do know quite a bit about Blackbird, the original authoring tool that was being created for MSN. The real history is that the original version of MSN was started long before the Internet came to be. Like Compuserve and AOL, it was originally based on a proprietary back end since HTML, HTTP etc. were not widely used standards back in the early 90's when MSN was first conceived. Hence, the authoring tool created for MSN was not standards based either, although it was based on an SGML markup language similar to HTML. So to say that MS had a huge conspiricy to hijaack the Internet with Blackbird is just silly... companies doing commercial online services in the early 90s were not doing them based on Internet standards....becuase these standards were just coming to the fore.

    At any rate, along the way the Internet exploded onto the scene, and MS at the time was not focussed on the Internet or Internet standards. That changed however, very radically based on direction from Bill Gates in December 1995, known as Internet D-Day at MS. Basically, at this time the entire direction of MS was changed to focus on the Internet across every product group. Since that time 6 years ago, MS has had a very strong history of contributing in very positive and major ways to Internet standards such as HTML, HTTP, DHTML, XML, ECMA Script (aka JavaScript/Jscript) Web Services and many, many others. To say otherwise is simply to show a lack of any understanding of the standards process and the work over the last 6 years that has gone on at the W3C, ECMA and other organizations. And by the way, based on the decision to focus MS on the Internet 6 years ago, Blackbird was abandoned as a proprietary SGML tool in 1995 (it never shipped commercially, even) and the team refocussed on Visual InterDev, an early Internet development tool solidly based on standards including HTML, HTTP and delivering content to any range of browsers on any range of platforms.

    Anyway, this is probably boring most observers on this thread, but I thought I should add some context to your post, becuase I think a lot of Java developers wrongfully see conspiricy whenever they think about Microsoft.

    Greg Leake
    Group Product Manager
    Microsoft Corporation
  76. The debate we are having in this thread is about cost of performance. I'd like to point out that the licensing information for BEA / IBM isn't quite right.

    With BEA, you can get an 8CPU license of WebLogic Server for somewhere between 4000-5600. I can't remember if the license is $500 or $700 / CPU. This minimal version of WebLogic gives you all of the capabilities necessary to run the PetStore. This version provides JSPs, servlets, taglibraries, JDBC, basic JCA, and EJB client capability.

    The more expensive versions of the BEA license add on a number of features that are not available elsewhere: in-memory replication, complete JCA support, JMS load balancing, and a number of other things.

    I think when consumers look at it this way, the .NET / J2EE cost comparison isn't so wide. Of course, this cost structuring will change over time and both companies will continue to drive down the cost of more features.

    Tyler Jewell
    Director, Technical Evangelism
    BEA Systems, Inc.
  77. Tyler,

    I do not see such a version listed on the BEA Web site. I see a BEA WebLogic Express, WebLogic Advanced Edition, and WebLogic Premium Edition. Prices are not listed on BEA site that I can see, but eWeek pegs the prices in a recent review as:

    WebLogic Express - $3,000 per CPU
    WebLogic Advanced - $10,000 per CPU
    WebLogic Premium - $17,000 per CPU

    The review is at: http://www.zdnet.com.au/developer/xml/story/0,2000010388,20260997-1,00.htm

    The Express edition, without the support for EJBs, would not be capable of running Java Pet Store. So that leaves enterprise customers with the Advanced Edition at $10,000 per CPU, or $80,000 on a 8-CPU system, plus the cost of the OS. Am I missing something (I do not want to misrepresent pricing)...if so where is this information located on the BEA site?

    Greg Leake
    Group Product Manager
    Microsoft Corporation
  78. Greg-

    That's a really good question, apparently we don't list the pricing on our external web site. It's not listed anywhere. I was able to go onto our internal site and get the pricing / CPU and the numbers quoted at $3000 / CPU aren't right. Unfortunately, I can't list the actual numbers here.

    Wish I could, *sigh* to demonstrate that the two solutions are mostly on par in terms of cost effectiveness. We can take this offline if you want, Greg.

    BTW, I think there are incredible opportunities for complementary collaboration between .NET and the WebLogic Platform. More so than viewed as direct competitors, which most people see them as. Greg, what area are you the manager for at MSFT?

    Tyler Jewell
    tyler@bea.com
  79. Hi Greg,

    Greg: "It's funny how Blackbird has come up on this thread...possibly becuase of n n's earlier post."

    Sorry, didn't see that one. I just think it is a good example of how Microsoft "goes it alone".

    As for my proximity at the time ... uh 156th and 39th (Redmond) if I remember correctly.

    Blackbird was not just an authoring project. It also included network protocols for content transfer and a replacement for HTTP service.

    Greg: "You have an overactive conspiricy-theory driven mind here"

    No, a conspiracy is what you accuse the J2EE vendors of doing with ECPerf. ;-)

    A conspiracy from Microsoft would be a welcome change, because it would mean that Microsoft is working with at least one other party! <BWG>

    Peace,

    Cameron.
  80. Cameron,

    Very funny!

    -Greg
  81. "companies doing commercial online services in the early 90s were not doing them based on Internet standards....becuase these standards were just coming to the fore." -Greg Leake

    Ringling Bros and Barnum & Bailey can use your talent for hot air production Greak Leake.The online service Pipeline had support for ftp, irc, html browsing, ntalk, etc - Not to mention the huge support of internet standards from freeware and shareware tools in the early 90s. Where was Microsoft ? Back in the early 90s and still today RFC means Refine Further Confusion for Microsoft; ie, blocking of people with non-MS browsers from using its MSN.com site.
     

    Berners-Lee said about Microsoft: "Obviously this was a blatant attempt to use the leverage of some content to produce domination at the software layer. I have fought since the beginning of the Web for its openness: that anyone can read Web pages with any software running on any hardware. This is what makes the Web itself. This is the environment into which so many people have invested so much energy and creativity. When I see any Web site claim to be only readable using particular hardware or software, I cringe - they are pining for the bad old days when each piece of information needed a different program to access it."

    It is blatantly obvious Microsoft has intentions of polluting XML just as it attemped with Java(remember that?). It hasn't happend yet because it is too early in the game. Microsoft's XML will end up resembling a Word binary.


  82. Greg, you have made some good postings, but your tone is getting a little cynical. I believe there is a well-founded answer to many of the statements / suggestions you have made.

    You said:
    "Don't be so blind. ecPERF is clearly an effort by Sun and other J2EE app servers to hide from well-established benchmarks where any technology can compete, such as TPC-W. I still have heard no good explanation as to why Sun, BEA, IBM et al don't simply use the TPC-W?"

    Sun created ECPerf and then got other vendors to support it. It is Sun's creation and if it deserves scrutiny, the scrutiny should go to sun and not the vendors. Now, the reason that BEA, IBM, Borland, etc. are participating in ECPerf solely has to do with industry demand. Honestly, our customer base is much more interested in seeing ECPerf benchmarks rather than TPC-W benchmarks.

    I really don't see this is as a competition between the two benchmarks because they test completely different things. It's not a matter of open benchmark vs. closed benchmark. ECPerf was created because there are many companies leveraging J2EE purely that are interested in benchmarks designed to test J2EE specifics such as EJB containers, Adapter containers, and web containers. TPC-W isn't designed to test for these aspects, yet there are many that want them benchmarked. That is why vendors support ECPerf.

    Now, if the industry shifts, and I believe it is doing so right now, the ECPerf benchmark will become less important moving forward because of the focus on interoperability. As the number of companies that have heterogeneous enterprises increases, they will begin to demand a benchmark that adequately tests *equivalent* portions of .NET with non-.NET technologies such as J2EE.

    Honestly, the industry hasn't gotten to that point yet. Yes, I'm interested in those benchmarks and so are you, but are the .NET early adopters and loyal MSFT customers asking for it? Are the loyal J2EE enterprises asking for it? Probably not in large quantities. The people asking for TPC-W on a broad scale are the companies seriously evaluating both technologies. It's likely that these companies are in the minority right now.

    I guarantee you that as the number of companies begin to do .NET vs. J2EE comparisons, this type of benchmark will rise in importance, but for an existing J2EE vendor, we have a larger potential customer base that is *more* interested in ECPerf right now.

    You are a program manager for MSFT implying that you have to make hard choices *every* day. If you were in our position and you only had the resources to do one benchmark, which one would you choose? The benchmark that could drive the most revenues over the next two years or the one that's completely open, but will likely not drive any revenues? It's even more difficult to make this type of decision given the tighter economy.

    Tyler Jewell
    Director, Technical Evangelism
    BEA Systems
  83. Tyler,

    I appreciate your candor, and thank you for your honest answer. I guess I would say in response that from a customer perspective, the demand I hear is not demand to compare strictly one J2EE product to another...rather I hear a very strong demand from customers to compare a wider variety of technologies to eachother so customers can truly get a complete picture in terms of price and performance tradeoffs between products available on the market. I also firmly believe that TPC-W would work just fine to allow customers to also compare J2EE products to eachother, and so could easily serve your purpose as well, but Sun opted for a different path. I do agree with you that most of the scrutiny on this decision belongs with Sun, since they control and lead the Java technology. However, I have to imagine that the J2EE app server vendors could have voiced their opinion to Sun and influenced the decision, instead of simply just following Sun down this path. CReating and choosing ecPERF however, instead choosing TPC-W, is very convenient for the J2EE app server vendors as has been discussed here. But I honestly do not think the invention of ecPERF was in the best interest of customers--it was in the best interest of Sun and the J2EE app server vendors.

    Anyway, it has again been a healthy debate.

    Greg Leake
    Group Product Manager
    Microsoft Corporation
  84. Greg-

    We don't have any plans to run WebLogic on TPC-W right this second. Our efforts are consumed with ECPerf and availability of resources is an issue. If I'm not mistaken, our Tuxedo line has TPC-W numbers for it. WebLogic will have them eventually, but we don't have a definite timeline.
  85. I apologize. I meant that our Tuxedo line has TPC-C results, not TPC-W results. That was a typo. BEA is committed to this organization and the standards they promote. These efforts all require resources, however, and that is our #1 friction from us completing more of these.
  86. Greg,

    One more point I want to make. You said, "Given the issues with ecPerf as a closed "J2EE-only" benchmark, I am curious if BEA will also be releasing any TPC-W numbers so that your technology can be compared to non-J2EE products, or participating in any publication-based shootouts for the same purpose?"

    This is a reasonable question to ask, but the TPC-W isn't our #1 concern right now. Our #1 concern is to focus on interoperability, standards support, and usability. We have a number of engineers dedicated to web services and protocol interoperability and as new resources have freed themselves up, they are more likely to be assigned to these efforts, rather than performance testing. We have interoperability testing at the web services level with .NET Beta 2, SOAP Toolkit, Apache, and one more I believe.

    So, even though performance is important, it isn't as high on the priority list as standards compliance, availability & reliability (as opposed to raw throughput), interoperability, and usability.

    So, from our perspective, we aren't hiding or shying away from any performance efforts, we are just prioritizing to the best of our ability.

    Tyler Jewell
    Director, Technical Evangelism
    BEA Systems
  87. Tyler,

    You mention "near future" and "next few months" and a "major new version". Typical marketing stuff - which I will skip around :)

    Why do you need a major new version to run ECperf on? Haven't you been able to get ECperf running on the 6.x version of WebLogic? (I believe your 6.x is certified compliant as is our (Borland) 4.5.x version)

    -krish
  88. Hi Krish,

    You said to Tyler: "You mention "near future" and "next few months" and a "major new version". Typical marketing stuff - which I will skip around :)"

    Hopefully that means they found some performance problems that will be fixed and some areas that needed to be improved for the next release! (I guess that means the ecPerf is working ;-)

    Peace,

    Cameron.
  89. Krishnan-

    Yes, we have ECPerf running on WebLogic 6.1. The decision to port to the new version was two-fold: we needed to have all engineering resources focused on the next version of weblogic and there are some features in the new version that would benefit our performance.

    Even though we had ECPerf running on WebLogic 6.1, we are dependent upon some efforts from partners in the DB and hardware space. So, it's mostly a timing issue and getting everyone on the same page for us.

    Tyler
  90. I have a close aquaintance who works for one of the J2EE compliant application server vendors. I have been reading all of the hype from the analysts, most of which, is said without being informed. An independent ECperf benchmark was sponsored by an unamed faction in Paris back in September. This was to be the first public ECperf "bakeoff". Many vendors ran their tests for 1 week - BEA actually had multiple opportunities, but could not successfully pass the tests. IBM and Borland were the only 2 vendors to succeed, but both decided not to publish because of various issues. The analysts should be investigating the results of this testing rather than relying on their own assumptions.
  91. n n,

    Get a grip on reality. First off, no one should listen to someone who hides behind a fake name, refuses to reveal their identity and company they work for. You manage to turn civil discussions into one-way spitting matches at every turn, no wonder you hide. The fact is, the Internet may have *existed* in early 90s, but it was not a consumer phenon until a few years later. Lots of companies struggled to determine how and when to endorse and incorporate Internet standards into their mainstream products. There is nothing wrong with this, decisions like these are a natural part of doing business. But its a moot point anyway, Microsoft bet on the Internet in a big way in 1995, and has been a major positive contributing force in the standards bodies to evolving internet standards while working with other companies, and arguably has done as much or more to incorporate internet standards into its products than any company out there.

    Greg Leake
    Group Product Manager
    Microsoft Corporation
  92. Kumar,

    There is a lot of topic evasion going on in this debate, I think its better to stay focussed to the topic at hand.
    Customers should download the code and compare for themselves. You can't draw conclusions without doing some due diligence.

    As for customers being stupid to use Websphere or BEA or Oracle for Pet Store vs. JBoss or Tomcat....the point of the Java Pet Store is to show an enterprise architecture and enterprise coding using a simplified sample application scenario. So the debate is about enterprise applications, and in the enterprise, customers today are choosing BEA and Websphere, these are the recognized market leaders in this space. I am not drawing conclusions as to whether they are better...but they are the leaders today in the enterprise, and the comparison of .NET costs to IBM Websphere and BEA costs is very relevant to the majority of enterprise customers.

    But we do just fine on the cost comparison to free app servers as well, since the .NET framework (everything you need to build and deploy full-featured .NET apps) is a free download and can be freely redistributed.

    Greg Leake
    Group Product Manager
    Microsoft Corporation
  93. Greg,

    While I think you've contributed to a healthy debate and have elicited some interesting and entertaining responses from members of this board, I have to say I do view your posts with more than a little suspicion.

    You've challenged the J2EE Vendors to submit their application servers to TPC-W, the E-Commerce performance benchmark from TPC. I'm not surprised the J2EE Vendors don't want to take you up on it because and I quote from the TPC-W Whitepaper: "TPC-W does not require that an Ecommerce package be used to implement the Web Server Application. Most TPC-W solutions are custom coded applications written as close to the Web Server Internet layer as possible. The benchmark provides a great test of Web Server Hardware, operating system and basic Internet software capability but does not provide any information on the higher-level Ecommerce packages."

    So TCP-W is a great way to compare Microsoft Windows 2000 and Microsoft Internet Information Server vs. TUX2 on Linux. It's not a great way to compare J2EE to .NET.

    Your comments regarding ECPerf are misleading. ECPerf is a J2EE benchmark. It was always meant to be a J2EE benchmark. ECPerf is closed to .NET in the same sense that TCP-C is closed to Image Manipulation programs.
  94. Jamie,

    Thanks for the positive feedback and for not flaming me out of the gate for being here. As for your comments on TPC-W and ecPERF...I'll have to disagree. TPC-W is a fine benchmark for J2EE products to enter. Any custom-coded J2EE solution, running on any app server, could enter the TPC-W. And as for your analogy equating .NET to an image manipulation program...I don't agree. .NET and a host of other non-J2EE technologies could easily implement the functionality of ecPERF, providing 100% functional equivalence to the J2EE solution. I don't think the same could be said for an image manipulation program attempting to implement the functional requirements of the TPC-W.

    -Greg

  95. Greg,

    1) I notice that you selectively reply to messages and ignore those which intelligently refute your arguments. For example Bernhard Messerer posted an excellent comment above and of course ... silence.

    2) I don't use EJB's, as a lot of J2EE developers I know who aren't dealing with "large enterprise apps" don't. I personally prefer the Resin app server and using JSP/Servlets/JDO.

    When you compare prices/performance in this non EJB range with .NET then it is a different story altogether. You have free servers (Tomcat) and cost effective ones (Resin - http://www.caucho.com/sales/index.xtp). You can use free databases (PostgreSQL, MySQL etc) and free operating systems (Linux, *BSD etc). Transferring applications between servers, OS, databases is almost trivial with non-EJB applications you know?

    Performance can also be made spectacular (see http://www.aceshardware.com/read.jsp?id=45000240)

    In the non-EJB range, I don't see any reason why you would choose .NET, unless you are already a MS shop and want to be locked into MS products indefinitely.

    So now then, compared with "large enterprise apps" in J2EE which use EJB, maybe you win on cost/performance versus some of the big players (mind you, there are definitely cheaper alternatives like Orion which you choose to ignore). However, most large companies can afford the money on BEA/IBM/Borland/Oracle products (servers, DBs etc), they don't have performance as a number one goal and _definitely_ don't want to be tied 100% into Microsoft products. This is of course just MHO but is backed up from a lot of things I have read (and I read a LOT, trust me).

    3) I've downloaded .NET framework beta 2 to compare Pet Shop implementations to "see for myself" as you and other MS guys have suggested. I have an open mind and will evaluate any new technology.

    To be honest, I have had endless troubles. I cannot get the basic tutorials working properly with .NET let alone the famous Pet Shop. I am sick of wasting my time! (and yes I have spent a lot of time reading docs, forums etc).

    I recently graduated from University (Computer Engineering / Computer Science) in the top 5% so I am not stupid either, I think ;-)

    JBoss (free) took me roughly 30 minutes to get Pet Shop working (after never using it before). I have spent over 40 hours on .NET so far and still no luck. True, .NET is still in beta but the way you have been talking about it I expected to almost seamless. Much, much better than what I have found out anyway.

    While using .NET beta 2, I have been taken aback at the amount of Microsoft products required for things to work properly, basically I have to throw out all my previous knowledge of things non Microsoft and learn specific Microsoft products instead.

    More specifically:

    a) .NET beta 2 forces you to use IIS as the web server (ASP.NET etc). The number of holes in this web server are well documented. I do not feel safe running this on my computer (I stop IIS every time I connect to the internet :) ). I am familiar with apache not IIS. Guess I'm out of luck right?

    b) Due to a) and many other aspects of .NET you really need to be running Win2K (or WinXP I guess) for everything to "just work" out of the box or work without huge hassles. I use this for my main development machine so no problems here but again - no choice right?

    c) ADO.NET may work with any database _theoretically_. However 99% of tutorials and documentation (offline and online) I have been through so far cover SQL Server or Access only. I am not familiar with either and have had no luck getting it working with my more familiar (and free)PostgreSQL or MySQL.

    From http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguidnf/html/cpconusingadonetproviderstoaccessdata.asp

    "ADO.NET includes two .NET data providers, that being
    1) SQL Server .NET Data Provider - For Microsoft SQL Server 7.0 or later
    2) OLE DB .NET Data Provider - For data sources exposed via OLE DB"

    Looks like I need to buy SQL Server or use Access to make things easy for me right?

    Even when using the "dummy" SQL Server component installed with the .NET framework, the quickstart tutorials involving DB's (namely intro8.aspx and intro9.aspx) just will not work (I won't go into the reasons here). I've spent a lot of time on it and am about to give up.

    4) Be honest here - are C# platform libraries really going to be cross platform? I doubt it since a large number of them aren't in the ECMA standard so even if it is ported to the other platforms like linux etc, thinks like ASP.NET, ADO.NET and web services probably won't be there right? So cross platform means BOTH Win2K and WinXP I guess eh :)

    I could go on and on but to me it is now quite clear. The .NET strategy is all about making you buy and use 100% Microsoft products and not enabling you to have any vendor choice at all. Of course this is no surprise. All big companies do this. IBM and BEA probably want the same vendor lock in too, but at least with J2EE I can vote with my feet. At least with J2EE I have choices.

    Two final points regarding University students that I would like to add:

    - My university, as with the vast majority, taught Java as it's primary language. Companies will have much less hassle finding Java developers than .NET - in the not too distant future at least. I can't see MS countering this.

    - Student's will have a hard (if not impossible) time learning all of .NET properly due to number of Microsoft products you need to buy/obtain for it to work or at least work without huge hassles.

    With J2EE I can use entirely open and free servers/databases, e.g. JBoss, Tomcat, MySQL and implement applications implementing the entire J2EE framework. With .NET I would need to buy a huge array of software to implement/evaluate all aspects of the framework. How is MS going to address this? Force students to buy .NET server licenses? Yeah, right.

    In case anyone is in doubt, here is the list of .NET servers you would need to implement all things .NET (taken from http://www.microsoft.com/net/whatis_server.html):

    Microsoft Windows .NET Server to build, deploy, manage, and run XML-based Web services.
    Microsoft Application Center 2000 to deploy and manage highly available and scalable Web applications.
    Microsoft BizTalk™ Server 2000 to build XML-based business processes across applications and organizations.
    Microsoft Commerce Server 2000 for quickly building scalable e-commerce solutions.
    Microsoft Content Management Server 2001 to manage content for dynamic e-business Web sites.
    Microsoft Exchange Server 2000 to enable messaging and collaboration anytime, anywhere.
    Microsoft Host Integration Server 2000 for bridging to data and applications on legacy systems.
    Microsoft Internet Security and Acceleration Server 2000 for secure, fast Internet connectivity.
    Microsoft Mobile Information 2001 Server to enable application support by mobile devices like cell phones.
    Microsoft SharePoint™ Portal Server 2001 to find, share, and publish business information.
    Microsoft SQL Server™ 2000 to store, retrieve, and analyze structured XML data.

    That's all you need, simple and non-confusing eh :)

    If you are trying to win over developers like me to the .NET framework (which along with C# I quite like BTW, I just don't like the approach you MS guys take and the 100% lock in to MS products) then I can assure you you have a long way to go.

    Regards,

    Ben
     
  96. Ben,

    You may well have had genuine problems with installing the .Net framework but please, don't use that as a basis for misrepresenting it so completely. The only Microsoft product you need to buy to use the framework is a version of Windows. As you appear to have that already, you're all set. ASP.Net does not require IIS, but as it's a free part of nearly every Windows release, it's the natural choice. As for databases, both ODBC and OLE-DB providers are freely available (the latter is part of the base install) which work with the databases you mention.

    Your exhaustive list of Microsoft's enterprise application range is spurious and irrelevant. None of them are required by the framework.

    Jim
  97. Jim,

    > You may well have had genuine problems with installing
    > the .Net framework but please, don't use that as a basis
    > for misrepresenting it so completely

    Misrepresenting? I told it _exactly_ as it happened - I'm sure others were interested to know that .NET is not as seamless as you make out. I've had another fellow developer try installing it and exactly the same problems arose so maybe we're just plain unlucky right? Thanks for saying "please, don't" though, very polite ;-)

    I genuinally tried to evaluate the .NET beta 2 release (I'm still using it so you don't have to give up on me yet :) ). Sure you would like me to have said "I installed .NET, everything worked first time as expected, .NET is so good it can make my coffee in the morning!" but that wasn't the case. You can't stop people like me telling it like it is.

    As I mentioned I actually like .NET and C#, especially the windows forms and server controls. I've managed to do some reasonably cool stuff with it in the time I've used it, it's the 100% tie in to MS (and don't think you can fool me on this Jim) that I disagree with.

    > The only Microsoft product you need to buy to use the
    > framework is a version of Windows

    LOL! Do you really believe that yourself Jim do you? If so I would like to sell you some of my offshore shares. A key goal of .NET is to make big bikkies out of your .NET servers which you will need to do _anything_ serious with .NET. Why do you think Greg is so active here eh? Because that's what MS is hoping for, to dominate the server space like they have the desktop. You may well be able to develop .NET apps using only a desktop Windows OS (+ IIS + ...) but you sure can't deploy them with just the OS.

    > ASP.Net does not require IIS, but as it's a free part of
    > nearly every Windows release, it's the natural choice.

    What???? Then why did the .NET documentation tell me that ASP.Net will not work properly without installing IIS? An outright lie there was it? Care to give me any links to running ASP.NET on any different web server to IIS? Then I might believe you. Maybe you will say it is _theoretically_ possible but in practice it just won't happen - you know that as well as I do.

    BTW, saying "IIS" and "it's the natural choice" in the same sentence was a true gem, I liked that. I always love that marketing speak.

    > As for databases, both ODBC and OLE-DB providers are
    > freely available (the latter is part of the base install)
    > which work with the databases you mention.

    I quite aware of the OLE-DB provider as part of the base install. Ever tried getting it to work with MySQL or PostgreSQL? I sure couldn't and it wasn't from lack of trying.

    > Your exhaustive list of Microsoft's enterprise
    > application range is spurious and irrelevant. None
    > of them are required by the framework.

    Spurious and irrelevant eh. You MS marketing guys really are pure genious - much more funny then the J2EE ones. You forgot to say "please, don't mention them" though >:-)

    Yes, none of the .NET servers are *absolutely required* by the framework to develop applications, if we are getting down to petty arguments. They are preferable of course right :) However come deploy time then guess what - .NET server's for everything under the sun.

    Have a merry Christmas Jim, Adi and Greg, nothing personal, but you are blinded by your devotion to Microsoft. I'm not devoted to anyone, J2EE or .NET (... but maybe Jini *grin*), I'll use, recommend and talk about whatever I feel is the best solution to a given problem.

    Regards,

    Ben
  98. Ben,

    Made me laugh that you think I work for Microsoft :-)

    Look, all I'm asking you is to have some perspective. I take issue with 2 things you did in your previous post:

    1) You used your bad experience with the .Net SDK as the basis for an argument against Microsoft's entire .Net strategy. That's (ahem) a fallacy of composition. If you'd said "the SDK's install didn't work for me, here's why..." then fine, but you effectively said "the SDK's install sucks, therefore .Net sucks, and anyone who tells you otherwise is a Microsoft goon".

    2) You used the fact that Microsoft sell a whole range of products under their ".Net" banner to spread FUD about deployment requirements for .Net applications. I appreciate there may be confusion about what exactly .Net encompasses, but for the purpose of this thread, I'm assuming it's the runtime and SDK, not just anything with .Net slapped on the end of it. I couldn't care less about MS Application Center, MS SharePoint Server, MS blah blah. Again: why are they relevant? It's like saying you need DB2 to run WebSphere, because it's an IBM product. Sure, IBM would like you to use DB2, but it's their job to sell you things.

    As for your other points:

    Download the ODBC.Net provider from www.microsoft.com/data - it works with MySQL (certainly) and PostGre(not sure, but probably). AFAIK, there is no OLE-DB driver for either of those DB's.

    ASP.Net can be hosted very easily. There's an example here:

    http://www.123aspx.com/resdetail.aspx?res=547

    Merry Christmas to you to :-)

    Jim

  99. "ASP.Net can be hosted very easily. There's an example here:
     http://www.123aspx.com/resdetail.aspx?res=547 "

    - Jim Arnold

    Jim,

      Please, let's stick to professional solutions.This implementation has a number of faults: It lacks performance, reliability, scalibility, etc. It might work great for demonstrating to your next door neighbor but try multiplying the load by 100s.

     


  100. n n,

    "Please, let's stick to professional solutions.This implementation has a number of faults: It lacks performance, reliability, scalibility, etc. "

    Er, Ben said ASP.Net couldn't be run without IIS. That example proves it can. It also shows how trivial it would be to write a wrapper for it fed by any number of existing web servers. I'm sure if there's demand for an Apache host, one will appear.
  101. Jim,

      I wouldn't call reading from a flat file support for non IIS servers.

    ;^)
  102. Jim,

    I've been enjoying Christmas and the new year and didn't see your reply.

    > Made me laugh that you think I work for Microsoft :-)

    Then I'd suggest applying for a position immediately Jim! I'd recommend marketing or evangelism, I'll even be one of your references if you like :)

    > Look, all I'm asking you is to have some perspective

    And I ask the same from you and Greg.

    > you effectively said "the SDK's install sucks,

    Yes, the SDK install is very poor in my opinion. Why should I have to install:

    - MS Frontpage extensions
    - MS Internet Explorer 6 (don't tell me because of MSXML)
    - MS IIS
    - An SQL server component (SDK, SQL Server 7, 2000)

    just to get things the basic tutorials working! That reeks of MS tie-in to me. Have you actually tried to install the framework yourself? Were you happy with it?

    I'll admit that after getting everything working (days after instlling the framework mind you) the development process was quite nice.

    > therefore .Net sucks, and anyone who tells you otherwise
    > is a Microsoft goon

    I did not say .Net sucks, I already said that I like .NET and C# (read my last post) so who's jumping to wild conclusions here?

    > I couldn't care less about MS Application Center, MS
    > SharePoint Server, MS blah blah. Again: why are they
    > relevant?

    Do I have to explain it again? To deploy anything beyond the basic web application with .NET, MS will require the use of their .NET servers, e.g. Passport (I've read the MS documentation carefully Jim :)). Even Mono (the .NET implementataion by Ximian) will still need to go through at least one MS .NET server as it currently stands.

    To deploy basic web applications you will not need any of these fancy .NET servers, you are correct.

    But then again you won't need anything fancy with J2EE either for basic applications - JSP/Servlets work beautifully here for example (forget EJB for small apps IMO)and many Servlet engines are cheap or free (e.g. Resin, Tomcat) and can run on *ALL* robust server OS's (linux, *BSD, Win2K, Solaris). And as I mentioned before, JSP/Servlet applications are almost trivial to port across different Servlet engines.

    > Download the ODBC.Net provider from
    > www.microsoft.com/data - it works with MySQL (certainly)
    > and PostGre(not sure, but probably). AFAIK, there is no
    > OLE-DB driver for either of those DB's.

    Yeah, I meant ODBC.Net not OLE-DB before. I've now got ODBC.NET to work with MySQL somewhat, PostgreSQL not at all. Still, 99% of documentation/tutorials on .NET relate to SQL Server or MS Access so it makes it very difficult for a developer to work with non MS databases doesn't it?

    > ASP.Net can be hosted very easily. There's an example
    > here:
    > http://www.123aspx.com/resdetail.aspx?res=547

    Come on Jim, that's not an effective solution and you know it. I stand by my word - to effectively host ASP.Net you will need IIS.

    I apologise for my negative tone in my first post, I was sick of being told that I had to use 100% MS products to develop with .NET when scouring and posting information to .NET related sites.

    Bottom line is that I like .NET and I like J2EE, I believe that a developer cannot eliminate either framework from their repotoire in today's climate. It's the .NET tactics I disagree with (more than J2EE) and I am free to share that information here on theserverside.

    Regards,

    Ben
  103. Ben,

    Look, I know you're on a real anti-Microsoft trip, so I'll try and keep this a technology discussion:

    >Yes, the SDK install is very poor in my opinion. Why >should I have to install:

    >- MS Frontpage extensions
    >- MS Internet Explorer 6 (don't tell me because of MSXML)
    >- MS IIS
    >- An SQL server component (SDK, SQL Server 7, 2000)

    I can't think of any part of the SDK which requires FrontPage extensions or IE 6. IIS is a standard Windows component, and MSDE is a freely available component distributed with the SDK. I really don't think these are extreme requirements for the install (and only needed to run the tutorials).


    >To deploy anything beyond the basic web application >with .NET, MS will require the use of their .NET servers, >e.g. Passport

    Passport is not a .Net server, it's a user-authentication service. The only relationship it has to the .Net framework is that it's an option for ASP.Net security (and MS provide a managed wrapper for it). It's as much a requirement as SQL Server is (ie not at all). Can you cite some other Microsoft products that are required for deployment of a "beyond the basic" web application?

    >Come on Jim, that's not an effective solution and you know >it. I stand by my word - to effectively host ASP.Net you >will need IIS.

    Hey, you said ASP.Net required IIS, I said it didn't and provided proof. I'm not going to advocate that everyone ditches IIS for a hand-rolled web server, but the point is that it *can* be hosted anywhere. It's still in beta ferchristsake, you can't expect alternative containers to be immediately available!

    >It's the .NET tactics I disagree with

    What, that Microsoft are using it to generate revenue? Yeah, that really bites. Thank god for Sun.

    Jim (who has no affiliation to Microsoft or any other software company).
  104. Jim,

    I am not on an anti-MS trip and I am not anti-Sun - I don't like big business practices full stop, is that a bad thing? Just because I don't like MS tactics doesn't mean I automatically like Suns ... or IBMs or whoever - it's not black and white like that.

    <Jim>
    I can't think of any part of the SDK which requires FrontPage extensions or IE 6
    </Jim>

    Don't ask me why you need them either, however, when you install the .NET framework beta 2 it requires you to install Frontpage extensions and have IE 6 installed (as well as IIS etc).

    See the link given by someone else above http://www.byte.com/documents/s=1816/byt20011214s0001/1217_udell.html which is written in .NETs favour and says the same thing as I did.

    <Jim>
    Passport is not a .Net server, it's a user-authentication service. The only relationship it has to the .Net framework is that it's an option for ASP.Net security (and MS provide a managed wrapper for it). It's as much a requirement as SQL Server is (ie not at all).
    </Jim>

    I am quite aware of what Passport is - trusting MS with your personal data no less. Passport is not a .NET server, I never said it was, but it sure as anything is hosted by a whole bunch of MS servers - and the majority of these have been branded or re-branded (in SQL servers case for example) to .NET servers.

    <Jim>
    Can you cite some other Microsoft products that are required for deployment of a "beyond the basic" web application?
    </Jim>

    Sure! (Mind you I've already said that *all* the .NET servers aren't 100% necessary but that's a separate argument).

    Since you like to ignore my terminology, let's use some of MS's own then:

    http://www.microsoft.com/servers/evaluation/overview/net.asp:

    "Market opportunities, competitive threats, and cost containment pressures require agile businesses to build, deploy, and manage solutions that quickly Web-enable their enterprises. Microsoft .NET Enterprise Servers offers all of the tools necessary for responsive IT departments to take action—today.

    ...

    Microsoft .NET Enterprise Servers are the fastest way to integrate, manage, and Web-enable the enterprise.
    "

    Gee, sounds like I am really going to need these .NET Enterprise Servers eh?

    How about http://www.microsoft.com/windows.NETserver/evaluation/choosing/default.asp:

    "The Microsoft Windows .NET Server product family includes four versions:

    Windows .NET Web Server ...
    Windows .NET Standard Server ...
    Windows .NET Enterprise Server ...
    Windows .NET Datacenter Server ..."

    The matrix there says it all.

    Need the basics? Then sure the standard Web Server might be enough. What if I need Security Services like say an Internet Connection Firewall (shock horror)? Whoops, up to Standard Server we go. What if we now need some scalability? Enterprise/Datacenter Server here we come.

    It's all there in plain english. I'm not saying MS or Sun or IBM or whatever don't promote similar marketing tactics (I don't work for any of them) but with MS you are tied to a particular vendor indefinitely. For some shops this may be entirely acceptable I agree, for many it won't be.

    <Jim>
    Hey, you said ASP.Net required IIS, I said it didn't and provided proof. I'm not going to advocate that everyone ditches IIS for a hand-rolled web server, but the point is that it *can* be hosted anywhere. It's still in beta ferchristsake, you can't expect alternative containers to be immediately available!
    </Jim>

    You didn't provide proof. Your link to a solution was unworkable and amateur at best. I agree .NET is still in beta but again I repeat - 99% of documentation and tutorials are related to IIS and MS sees apache as a direct rival and would do anything it can to make sure it can't work with ASP.NET.

    So I repeat like a broken record - to run ASP.NET effectively you will need to run IIS. I hope I am proven wrong but I doubt it.

    <Jim>
    What, that Microsoft are using it to generate revenue? Yeah, that really bites. Thank god for Sun.
    </Jim>

    Ahhhhh. So you finally admit you are really an anti-Sun bigot. Thanks for clearing that up. And I never mentioned Sun anywhere in my posts. I'd rather not have any large monopolies (MS or Sun) thank you.

    <Jim>
    Jim (who has no affiliation to Microsoft or any other software company).
    </Jim>

    I know. You work for Furturestep (futurestep.com). Except that you regular answer questions for DevelopMentor-dotNET (see http://aspn.activestate.com/ASPN/Mail/Message/DevelopMentor-dotNET/919634) for example, so it is clear where your preferences lie.

    Regards,

    Ben
    (who also has no affliation to MS, Sun, IBM or any other software company)
  105. Ben,

    This is getting really tired now. I'm fed up of semantic nitpicking (and you're bordering on the personal), so I'll iterate the current technical points of contention (in case anyone's still interested):

    1) That the .Net Framework B2 install requires FrontPage extentions and IE6.

    My response: It doesn't. I have neither on my machine (and never have). Beta 2 installed fine without them. The article you linked to refers to the Visual Studio.Net installation, which is what I assume you're confusing it with.

    2) That ASP.Net requires IIS

    My response: It doesn't. We both agree that the example I referred you to is not an effective solution, but that's really not the point (not my point anyway). ASP.Net is NOT tied to any web server, and your claim that MS will block others from hosting it by any technical means is pure speculation.

    As for the other points, I really couldn't care less anymore. Yes, MS and Sun are big greedy companies that spout a lot of drivel, but if that allows them to create better and better technologies (and effectively give them away to us poor developers), I'm happy. Let's argue about the technology.

    Jim (who does indeed work for Futurestep and post to the DOTNET list, but fails to see the relevance).
  106. Jim,

    I agree this is getting tired so I am afraid we are going to just have to agree to disagree :) And please don't use the semantic nitpicking line because you've used that tactic much more than I.

    With respect to 1), yes I *definitely* needed to install Frontpate Extensions from my MS Office 2000 Premium CD when installing the .NET *framework* beta2, maybe you did not, maybe you already had them installed, I don't know. I have installed the .NET framework quite a few times so I am not making it up.

    With respect to 2), yes I still believe that ASP.NET is and will be directly tied to IIS. I'm glad you are optimistic that it will not be, let's hope that comes to fruition eh?

    And I'm glad you couldn't care a less about MS and Sun, if the J2EE vs .NET competition creates better/cost-effective products and technologies for developers it can only be a good thing, that we agree on.

    I am more than happy for "pure" technology debates. I've got a few that can get us started:

    vi or emacs?
    C# or Java?
    Gnome or KDE?
    .NET petstore or J2EE petstore?
    Windows or Unix?

    *grin*

    Regards,

    Ben

    p.s. I only mentioned the dotNet thing because you were trying to come across as totally impartial which is not true. I have a slight preference for using J2EE (if I had to make a choice) though I quite like .NET and the opposite applies for you I'd say, it's not a big issue really. Peace.
  107. Ben,

    What's your evidence to show that ASP.Net is specifically tied to IIS?

    Jim

    PS. No way I'm touching any of your suggested debates in here :-)
  108. Ben,

      I've had my own experiences with .net along with other peers, since the install my OS is flaky. And this is my seventh clean install. Did you encounter this problem also Ben ?

  109. n n,

    > I've had my own experiences with .net along with other
    > peers, since the install my OS is flaky. And this is my
    > seventh clean install. Did you encounter this problem
    > also Ben ?

    Yes and no.

    The .NET framework install did not make me comfortable, let's put it that way. My OS did not become obviously flakey but I did get more crashes than usual in some applications after installing, though I'm not sure if its directly related, I wouldn't be surprised.

    I did do a clean re-install of Win2K on my main machine after installing .NET though and I now develop with it on a separate machine.
  110. Greg,

    I believe we're going to have to agree to disagree on the TCP-W benchmark then. You are right that "Any custom-coded J2EE solution, running on any app server, could enter the TPC-W", however that seems to be a deliberately misleading statement. The question should be: is TCP-W an appropriate benchmark for J2EE servers and I'll use the same quote from the benchmark again:

    "The benchmark provides a great test of Web Server Hardware, operating system and basic Internet software capability but does not provide any information on the higher-level Ecommerce packages".

    I'd say that your statement that "TPC-W is a fine benchmark for J2EE products to enter" runs completely contrary to the explicit design of the TCP-W benchmark. Your tiger style may be strong, but our dragon style will defeat you.

    As regards comparing .NET to an image manipulation program, that might have been a little unfair ;) but for the longest time, what exactly .NET was was anybody's guess (i had money on it being a self balancing scooter myself).

  111. Jamie,

    The phrase you quote from TPC-W equally applies to ecPERF. ecPERF is meant to be implemented on a vendor's choice of hardware, OS and server-side software....Its the exact same stack being tested. If you look at TPC-W, its a very interesting and relevant test for J2EE since the app tested includes

    -middle tier business logic
    -scripting/component database interaction
    -dynamic generation of HTML pages on the server
    -state management
    -transactions
    etc.

    But regardless of the relevance of TPC-W to J2EE app servers, ecPERF does not allow J2EE app server price/performance to be compared to anything non-J2EE. This is the main point I am arguing. Customers want the complete picture, and ecPERF does not provide it. What would you recommend to solve this problem?

    -Greg
  112. Hi Greg,

    Are you going to reply to Ben's insightful (inciteful?) comments?

    I think there is a lot to learn from those comments ... I'm kind of dismayed that he did so much good "homework" for you ;-)

    Peace,

    Cameron.
  113. Greg is busy with damage control on a severe Window XP security flaw discovered today. I'm sure he will respond promptly when his firewalk is completed.


    Greg, give my condolences to bill and steve.
     
  114. Tom,

    This does not surprise me. I agree with your point about most analysts relying on assumptions vs. any real technical analysis. For example, I have seen on the Oracle site a quote from Gartner that states they "believe Oracle and BEA are faster than Websphere" becuase "Websphere has hundreds of lines of complex code in it." They would do well to actually test the products before drawing conclusions that have no basis in fact.


    Greg Leake
    Group Product Manager
    Microsoft Corporation
  115. Greg,
    I have to agree with you on that point. There should be a public challenge issued to all the app. server vendors running the ECperf benchmark on the same configuration. There should also be a clause that says, "if the vendor wishes to participate, the vendor gives up the right to deny the publication of results". Half would drop out and half (the straight shooters)would participate. This would put an end to all of the speculation of who the true leader is.
  116. Don't you guys work. I just realized that I wasted last two hours reading this thread at my work!!!
  117. While on the topic of .NET vs. Java (which thread turns into):

    Having developed in Java for couple of years and now developing in .NET for last three years, I have to say that VS.NET (and C# and class libraries) are great. I never found cleanly integrated development environment while doing Java development. We tried Visual Cafe, JBuilder and later Visual Age, and every one of these had some problem while working with WebLogic for EJB, Servlet/JSP development/debugging. And they were all enterprise editions, which costs thousands. In the end, we used CodeWright and emacs editors for writing our Java code; and many of our visual cafe boxes were not even opened.

    Don't get me wrong; I was not a big fan of MS before either. I was forced into .NET pilot group from Java group; and well, I am not that religous about Java vs .NET, that I would try to find another job (especially in this economy). I have say though, that they are doing it right, finally. I just hope that mono project succeeds (www.go-mono.org), because competition is good for everyone.

    For unbiased folks, see this article from John Udell:
    http://www.byte.com/documents/s=1816/byt20011214s0001/1217_udell.html
  118. Only two years of java experience and using CodeWright and emacs editors for n tier dev ? What were you trying to accomplish that you had to resort to codewright and emacs ?

    My first inclination is to believe there was lack of supervision because I don't know of one project manager that would introduce this much risk to a project.



      
  119. Let me try again for the article link:
    .NET Development, Java Deployment
  120. In answer to the original question asked:

    "Where are all the vendors official ECperf benchmark results?"

    they can be found at http://ecperf.theserverside.com/ecperf/index.jsp?page=results/top_ten_performance, at least for those vendors who chose to participate, completed the benchmark, and allowed their numbers to be publically released.

    Kevin Zemanek
  121. Yes, take a look at that URL if you haven't lately. :)

    Randy Schnier
    View are my own and not necessarily IBM's
  122. Hi Randy,

    Randy: "Yes, take a look at that URL if you haven't lately ... View are my own and not necessarily IBM's"

    WebSphere at the top of the list, eh? Does this mean I have to take back all of the nasty things that I said about WebSphere? ;-) Congrats! (Now that IBM posted the numbers, I guess we'll see the rest of the submissions start coming.)

    Peace,

    Cameron.
  123. Thanks Cameron! I agree it will be cool to see other numbers become available. I think it's safe to say that the WS development and related teams are pleased with these results. (But of course it's a moving target.) For any folks that hadn't already seen, Floyd Marinescu started another thread today on the main page to discuss the IBM results.

    Randy
    Views are my own and not necessarily IBMs