A new white paper positioning the IBM J2EE Middleware Platform vs. the Microsoft .NET Platform is now available.

While it will be useful to many, its primary target is CEOs, CFOs, and other high-level decision makers at Independent Software Vendor (ISV) companies who are focused on the mid-market and looking to make a platform/partnering choice in the next 12 months. The outcome of the J2EE vs. .NET decision by ISVs is critical to IBM's ongoing success and relevance in the midmarket arena, traditionally a Microsoft stronghold.

View the white paper: IBM J2EE Middleware Platform vs. the Microsoft .NET Platform

In related news: Microsoft's Developer Network site has launched a "Resources for Java Developers" DevCenter, aimed at giving Java developers who need to write code for the .NET platform a quick transition to C#. Co-sponsored by the J# and C# Program Managers, it provides both interoperability and learn-by-comparison resources.

The Java Resources site is located at http://msdn.microsoft.com/vstudio/java

All's fair in love and marketing ..

An interesting paper, particularly the parts that show IBM solutions costing less than the comparable Microsoft solutions. I'm sure this will help keep IBM customers buying IBM, but I wonder how it will help outside that group.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

IMO there is nothing new added by the paper published by IBM. Almost all the stuff is pretty generic and already existing. The vendor lock-in issue has been beaten to death to fill in all 18 pages.

- Roger Rustin

IBM is about making sales, the rest of you can get stuffed.

"You have your way. I have my way. As for
the right way, the correct way, and the only
way, it does not exist."

Friedrich Nietzsche

Three Short Poems

"The underground roads
Are, as the dead prefer them,
Always tortuous."

"When he looked the cave in the eye,
Hercules
Had a moment of doubt."

"Leaning out over
The dreadful precipice,
One contemptuous tree."

W.H. Auden

Although I am J2EE guy,
when forced to choose between all IBM J2$$ solution and all M$ .NET solution I would choose all M$ .NET solution !!!

MC

Although I am J2EE guy,when forced to choose between all IBM J2$$ solution and all M$ .NET solution I would choose all M$ .NET solution !!!MC

I would say that for all trivial applications and those of medium difficult (web sites that are under a couple thousand hits per day, don't need transactional support, etc.) .NET is just easier to use. While I love Eclipse, drag and drop forms, call backs, etc. just make development pretty simple.

However, if I had to build something important, I would do it in Java/J2EE. Of course, I still like Entity beans, so I probably have just killed my own credibilty.

However, if I had to build something important, I would do it in Java/J2EE.

Sure, but not vendor-locking all IBM J2$$ solution!

However, if I had to build something important, I would do it in Java/J2EE.

Sure, but not vendor-locking all IBM J2$$ solution!

And how do you that? I though we talking Java/J2EE?

However, if I had to build something important, I would do it in Java/J2EE.

Sure, but not vendor-locking all IBM J2$$ solution!

And how do you that? I though we talking Java/J2EE?

1. Write code that directly uses IBM implementations of specifications.
2. Write code that uses IBM extensions (i.e. Stored Procs). this really wouldn't be J2EE then.

Other than that, using an all IBM stack doesn't necessitate a "vendor-locking" solution. In fact, that is the beauty of Java.

1. Write code that directly uses IBM implementations of specifications.
2. Write code that uses IBM extensions (i.e. Stored Procs). this really wouldn't be J2EE then.
Other than that, using an all IBM stack doesn't necessitate a "vendor-locking" solution. In fact, that is the beauty of Java.

If only that were true. The fact is that while Java solutions are massively more portable than .NET, it is still very difficult to avoid lock-in on large, complex projects. There is always some detail in the deployment or integration process that has the effect of making it difficult to switch vendor.

Anyway, the benefit of platform independence is not in avoiding vendor lock-in once a vendor decision has been made, but in providing choice and competition before the decision is made. When doing a Java project you can choose at the start from several competing products, each with their own foibles, strengths and weaknesses. Once that choice is made you are best advised to squeeze all the performance and productivity you can get out of your chosen platform and accept the lock-in consequences.

YMMV, IMHO, etc.
Brian.

That worked for our project, which is nothing trivial. Luckly we stayed away from Websphere specific stuff such as the object caching and spawning threads within an ejb method call (which is pretty nice by the way)

The fact is that while Java solutions are massively more portable than .NET, it is still very difficult to avoid lock-in on large, complex projects. There is always some detail in the deployment or integration process that has the effect of making it difficult to switch vendor.

Maybe some vendor lockin. But not complete or irreversable. I sure there is at least one example. But how many projects really are that big and that complex? I don't think it is always true. I think it is due (not 100%) more to lack of knowledge of what is available and what techniques are available.

Anyway, the benefit of platform independence is not in avoiding vendor lock-in once a vendor decision has been made, but in providing choice and competition before the decision is made.

When doing a Java project you can choose at the start from several competing products, each with their own foibles, strengths and weaknesses. Once that choice is made you are best advised to squeeze all the performance and productivity you can get out of your chosen platform and accept the lock-in consequences.YMMV, IMHO, etc.Brian.

Projects change over time. Even when they are being developed.

I don't see why you have to lock yourself in after choosing vendors. Very seldom have I had to or seen the need to make the Java Application not be cross Vendor. You should only do it when necessary and then wall off all that code and put up big red flags so everyone else knows what that code is there, that it will need be handled if you change vendors and that noone should use that code as an example of good practices.

Maybe some vendor lockin. But not complete or irreversable. I sure there is at least one example. But how many projects really are that big and that complex? I don't think it is always true. I think it is due (not 100%) more to lack of knowledge of what is available and what techniques are available.

No not complete or irreversible, but non-trivial. The ability to take an EAR for a large project from one vendor's server to another without effort is still more an aspiration than a reality. I think it is worth continuing to strive in that direction. If nothing else it will force the vendors to be more innovative when competing for business.

Projects change over time. Even when they are being developed.
I don't see why you have to lock yourself in after choosing vendors. Very seldom have I had to or seen the need to make the Java Application not be cross Vendor. You should only do it when necessary and then wall off all that code and put up big red flags so everyone else knows what that code is there, that it will need be handled if you change vendors and that noone should use that code as an example of good practices.

I'd ask a different question. You ask why lock yourself in after choosing vendors. I ask why not make use of all the productivity and performance improvements you can after choosing vendors.

The answer in both cases comes down to cost / risk. What is the cost of not using productivity or performance enhancements? What is the cost of switching vendor? What is the risk of using vendor-specific functions?

In my experience the risk of using vendor-specific functions is low, and the cost of not using them is high (think reduced productivity).

So I go back to my original point that the real value of portability is in forcing the vendors to compete.

Again: YMMV, IMHO, etc.
Brian.

I'd ask a different question. You ask why lock yourself in after choosing vendors. I ask why not make use of all the productivity and performance improvements you can after choosing vendors.

Wonder why some people pay $$$$ for a J2$$ server and then try very "hard" not to use those special hooks for the sake of portability. Hibernate/ J2SE rocks.

I'd ask a different question. You ask why lock yourself in after choosing vendors. I ask why not make use of all the productivity and performance improvements you can after choosing vendors.

Wonder why some people pay $$$$ for a J2$$ server and then try very "hard" not to use those special hooks for the sake of portability. Hibernate/ J2SE rocks.

Not sure why most anyone one pays big bucks for a J2ee server. Most pay for the "service" the vendor supplies. (yes, there are exceptions)

Not sure why most anyone one pays big bucks for a J2ee server. Most pay for the "service" the vendor supplies. (yes, there are exceptions)

Totally agree. If cost were the only option free servers would dominate the market right now. In additon to service I would also add "value".

Not sure why most anyone one pays big bucks for a J2ee server. Most pay for the "service" the vendor supplies. (yes, there are exceptions)

Totally agree. If cost were the only option free servers would dominate the market right now. In additon to service I would also add "value".

In reality, I've yet to see the "service" and "value" be worth the $$$. Those are my experiences. In some cases I'm sure they are and believe that they are. Just not the majority.

Also note that 'IBM J2$$' solution has more $ then 'M$ .NET' solution, :)

Also note that 'IBM J2$$' solution has more $ then 'M$ .NET' solution, :)

I think any vendor based J2EE solution would have more $, unless you opt for open-source J2EE stack. Unless you getting your math from somewheer else.

I think any vendor based J2EE solution would have more $, unless you opt for open-source J2EE stack. Unless you getting your math from somewheer else.

Wonder if anyone worries about TCO these days? :-)

Cheers,
Ramesh

Wonder if anyone worries about TCO these days? :-)Cheers,Ramesh

The people who care about it worry a lot :-) These are still, hopefully, the people that control the purse-strings and are making the ``buy'' decision.

Although I am J2EE guy,when forced to choose between all IBM J2$$ solution and all M$ .NET solution I would choose all M$ .NET solution !!!MC

Well at least, that moment, you can stop calling your-self a "J2EE guy" ;)

I don't get this all one vendor approach. Why in the world would I want to go all IBM or all Microsoft. Both have strengths and weaknesses. I much rather be practical and choose the best tool for the job. If I'm working in a all MS shop, the cost of retraining a bunch of VB guys is prohibitly expensive. The technology itself saves time, but you have to have people skilled in it. I have to work with .NET and so far, most of the enterprise level tools in J2EE that are mature do not have an equivalent in .NET. But that's my biased perspective. The biggest factor in the decision is the staff and training cost. There's nothing worse than throwing a bunch of programmers at a totall new development environment and praying it produces good results instantly.

I'm finding client after client that the choice of hardware/os server ends up being more important than the software platform you put on top. The software platforms tend to be pretty flexible.

When it comes down to it, your best insurance in software engineering is leaving yourself room for going down another path; workarounds.

No matter what the platform, sooner or later you run into an issue and you need to be able to work around it with minimal pain. The problem with going all MS is that for OS and development your workarounds get close to zero.

Real world example, at my current client we are using J2EE webservices to talk to a microsoft application. The microsoft side kept choking and dropping connections and the only way to get them back was to reboot the server. MS was brought in and basically said that a piece of their stack having to do with ssh encryption just doesn't scale and there was nothing to do about it. So the workaround was buying a few $5000 specialized hardware boxes to do it.

If the other side was java or some other development platform with a large 3rd party developer base, my guess is that there would have been many cheaper options available.

Until .NET works on any OS I can't in good conscience recommend it to clients because it locks you into the entire MS stack. Nobody does the entire stack perfect for every situation so this is basically a recipe for disaster.

I wish MS would get off trying to lock everyone in to make their money and just compete by putting out a superior platform choice.

I totally agree with that(MS stack).

-sithu

The link for the white paper is not working.

No one like to be locked in any environment except guys that are weak and need another ones care :)
But by j2ee you will never be locked in BEA , ORACLE , Sun , IBM , .. as long as you are working on standard j2ee. Changing platform probably is time consuming and expensive but it's still possible.
I cannot image myself locked by MS or any one else and it's why I work by j2ee.
And by j2ee you got a big thing and a great technology so please stop crying about price as long as you got your free developing tools from vendors.

Best Regards.

One very important thing that IBM never mentioned in this paper is the developers experties. I mean no body in the right mind can ever justify developing any thing on a proprietry OS unless you have a team of developers who only knows how to use the MS technology. This factor alone is the biggest factor for any company, manager or tech lead to choose one technology over other. The rest of the factors are negligible and have no significance in my personal opinion. Besides that I think developing database driven GUI applications are much easier in .NET than the Java/J2EE, but again enterprise applications are a totally different beast and J2EE is definitly a winner in this area...

Besides that I think developing database driven GUI applications are much easier in .NET than the Java/J2EE

If you pick the right IDE there isn't much difference. The problem with this thinking is that (to paraphrase a saying) these days no program (ninety some percent) is an island. It happens quite often that a company(etc) wants to take their "webapp" and put it in a portal or hook it up to something else. What are your choices with .Net? There went cheap. And easy. Been there, done that.

Besides that I think developing database driven GUI applications are much easier in .NET than the Java/J2EE, but again enterprise applications are a totally different beast and J2EE is definitly a winner in this area...

Have you tried the latest open source ORM tools like hibernate? It seems alot easier to use hibernate than to pound out a bunch of DAOs in .NET. There are many other open source libraries avaliable for Java developers that are either not available in .NET or are halfway ported.

<!-- Have you tried the latest open source ORM tools like hibernate? It seems alot easier to use hibernate than to pound out a bunch of DAOs in .NET. -->

Timothy your argument is valid but in case of enterprise applications where you care about the domain model. But you can not beat .NET (WebForms/WindowsForm + ADO.NET)if you are developing your application on 2-tier model (presentation tier + data base tier). As a matter of fact MS already started thinking in terms of O/R mapping tool and if I am not wrong the next realese of .NET/Yukon(SqlServer 2005) will include some thing called ObejctSpaces that will be apple to apple comparable with hibernate/toplink etc. Besides that there are many vendors in market who provides you O/R mapping tool for .NET. As a matter of fact there is a .NET version of Hibernate named NHerbinate is already in the process of development.

<!-- Have you tried the latest open source ORM tools like hibernate? It seems alot easier to use hibernate than to pound out a bunch of DAOs in .NET. -->

Timothy your argument is valid but in case of enterprise applications where you care about the domain model. But you can not beat .NET (WebForms/WindowsForm + ADO.NET)if you are developing your application on 2-tier model (presentation tier + data base tier). As a matter of fact MS already started thinking in terms of O/R mapping tool and if I am not wrong the next realese of .NET/Yukon(SqlServer 2005) will include some thing called ObejctSpaces that will be apple to apple comparable with hibernate/toplink etc. Besides that there are many vendors in market who provides you O/R mapping tool for .NET. As a matter of fact there is a .NET version of Hibernate named NHerbinate is already in the process of development.

<!-- Have you tried the latest open source ORM tools like hibernate? It seems alot easier to use hibernate than to pound out a bunch of DAOs in .NET. -->Timothy your argument is valid but in case of enterprise applications where you care about the domain model. But you can not beat .NET (WebForms/WindowsForm + ADO.NET)if you are developing your application on 2-tier model (presentation tier + data base tier). As a matter of fact MS already started thinking in terms of O/R mapping tool and if I am not wrong the next realese of .NET/Yukon(SqlServer 2005) will include some thing called ObejctSpaces that will be apple to apple comparable with hibernate/toplink etc. Besides that there are many vendors in market who provides you O/R mapping tool for .NET. As a matter of fact there is a .NET version of Hibernate named NHerbinate is already in the process of development.

Isn't it nice how MS makes it so easy to do it wrong? Everytime I've done the 2 tier thing, I've come to regret it. With just a little more effort I could have done it n-tier and made my life much easier.


Also, isn't nice how MS is going to make MS.Net "programs" not portable to other .Net implementations? :)



As for NHibernate - it was dead for quite a while (at least no releases). I think that they had run into a problem because a big diff between Java(platform) and .Net. Seems they have wacked all old releases and some new alphas have come out. I've been looking for a good .Net O/R mapping tool. There really aren't that many (not compared to java) and nothing open source that is production ready and is comparable to Hibernate. (if you of one, please share)

http://www.artima.com/forums/flat.jsp?forum=106&thread=51769

I'm wondering about what you mean by "wrong".

I am forced to agree that if you want to crank out a small scale 1 or 2 tier solution it's hard to beat the .NET tools. In about an hour I can crank out a modestly complex data driven app by simply drawing a few forms (web or native), mapping database queries to recordsets and then bind the recordsets to the form controls. The resulting architecture is much different than if I had generated a J2EE solution, but I wouldn't consider it "wrong".

A tool is most helpful if you use it for what it was meant for. The bad thing is MS tries to sell everything as the silver bullet answer to all problems. If you try using a hammer to unscrew something you're wasting your time and you're going to be unhappy.

The biggest mistake I made when I first tried a .NET solution was to apply my J2EE know how to the .NET tools. You have to understand that when you choose .NET you have also chosen to use MS mandated architecture. If you try to force a J2EE solution you are begging for disaster because the tools aren't meant to work that way.

That of course trails off into the old vendor locking arguments and everything else but since everybody has already beaten that to death...

The biggest mistake I made when I first tried a .NET solution was to apply my J2EE know how to the .NET tools. You have to understand that when you choose .NET you have also chosen to use MS mandated architecture. If you try to force a J2EE solution you are begging for disaster because the tools aren't meant to work that way.

Intrested to know what exactly you tired to apply and what you mean by "MS mandated architecture".

I'm wondering about what you mean by "wrong".I am forced to agree that if you want to crank out a small scale 1 or 2 tier solution it's hard to beat the .NET tools. In about an hour I can crank out a modestly complex data driven app by simply drawing a few forms (web or native), mapping database queries to recordsets and then bind the recordsets to the form controls. The resulting architecture is much different than if I had generated a J2EE solution, but I wouldn't consider it "wrong".A tool is most helpful if you use it for what it was meant for. The bad thing is MS tries to sell everything as the silver bullet answer to all problems. If you try using a hammer to unscrew something you're wasting your time and you're going to be unhappy.The biggest mistake I made when I first tried a .NET solution was to apply my J2EE know how to the .NET tools. You have to understand that when you choose .NET you have also chosen to use MS mandated architecture. If you try to force a J2EE solution you are begging for disaster because the tools aren't meant to work that way.That of course trails off into the old vendor locking arguments and everything else but since everybody has already beaten that to death...

Different isn't wrong. By wrong I mean not having and using domain objects and separating out layers (and concerns). I'm not comparing it to a J2EE solution. Just a basic J2SE solution. Sometimes things are just "data" but then one is just reporting and the domain objects have been "expanded" into just pure attributes.

I've done VB since '95 and have found databound controls, etc. to be "bad" for many reasons. So I know the typical MS "architecture".

I'm using VS.Net more daily and I miss my Java IDE each time I use it. Cause most programs are more than click and drag (speaking of that, anyone know of an AOP implementation for C#? I'll be glad when they day comes that the MS desktop strangle hold is broken).

For more info, see the link I posted earlier.

<!--There really aren't that many (not compared to java) and nothing open source that is production ready and is comparable to Hibernate. (if you of one, please share) -->

Mark try the link below you will find many O/R tools and libraries,hope you will find some thing that is open source too but I am not sure about that.

http://weblogs.asp.net/yreynhout/archive/2003/10/07/30798.aspx

<!--There really aren't that many (not compared to java) and nothing open source that is production ready and is comparable to Hibernate. (if you of one, please share) -->Mark try the link below you will find many O/R tools and libraries,hope you will find some thing that is open source too but I am not sure about that.http://weblogs.asp.net/yreynhout/archive/2003/10/07/30798.aspx

Thanks. I'll look through the list. I've look at some before. Looks like some links are broken and other projects are dead. But some are promising. So we will see. I do wonder what Microsoft's ObjectSpaces will do to the O/R mapping market in the .Net arena whenever it does come available (whatever life that will be). Probably what usually happens (bye-bye little guy). So, to be honest, I am going to only look at OSS.

This article is more about IBM and Microsoft rather than J2EE and .NET.

This isn’t meant to start a huge debate or flame but I look at the lock-in issue from a different perspective. If I’m a mid to upper level manger or architect responsible for recommending a standard tool, vendor, technology etc., for my enterprise then I would certainly like to think I’m going to expend the effort to perform due diligence on each of my choices and go with the vendor that offers the best approach and solution to my wide ranging problems. Now, if I spend millions of dollars or more on an enterprise solution, well, I’m thinking there’s going to be a little lock-in, especially mid term, as I don’t have the funds to keep changing my mind. I can also think that I would be highly dismayed if developers didn’t take full advantage of all the hooks, APIs etc. that made best use of the technology that I just purchased. Does portability go out the window? Well, yes, of course, but again if I’ve standardized on the solution across the enterprise with a long-term vision that probably isn’t as important. I’m curious, has anyone ever ported a large-scale enterprise solution several times between vendors and technologies? This isn’t a rhetorical question, I would really like to know.

I have seen a situation with a previous employer where a product was redeployed in different environments.

The company offered a 'buy and build' solution, where the bulk of the product was written in advance as an EJB-based app, and the remainder was developed bespoke and integrated with existing systems of record.

In that scenario there was obviously a great need to be as vendor-independent as possible, as we had to deploy onto whatever the customer preferred.
That company went to great lengths to isolate those pieces of code that were likely to be affected by different deployment environments as well as using only the standard APIs.

In practice this was only moderately effective. There were always issues in the integration and deployment that required some work.

Despite that experience I agree with you that once a decision is made an investment is made in a particular vendor, and that investment should be milked for all it is worth. The developers should use all the productivity and performance enhancements possible.

(Note: In case I come across as a PHB: I have worked for near ten years in the trenches writing code and leading development teams. I understand the technology and the value of independence, loose coupling, standard APIs and etc.)

Brian.

Note: In case I come across as a PHB: I have worked for near ten years in the trenches writing code and leading development teams. I understand the technology and the value of independence, loose coupling, standard APIs and etc.)Brian.

I wouldn't worry about that too much. As much as the pointy hair people receive a bad rap I've come across my share that know more about the business and overall IT landscape than a lot of developers, as much as I hate to admit it ;-)

Note: In case I come across as a PHB: I have worked for near ten years in the trenches writing code and leading development teams. I understand the technology and the value of independence, loose coupling, standard APIs and etc.)Brian.

I wouldn't worry about that too much. As much as the pointy hair people receive a bad rap I've come across my share that know more about the business and overall IT landscape than a lot of developers, as much as I hate to admit it ;-)

I would say you've been lucky. I can count the tech savy ones on one finger. But unfortunately, most developers aren't either. They might have their area of expertise, but that is it.

people, people,,, come down here,,,the article was written by ibm,, who has a dog in the fight...so don't give it much weight..

Instead, believe this white paper, written by an unbiased, very intelligent technology agnostic (me).

http://www.bijonline.com/PDF/EnterpriseWarsLykins.pdf

Don Lykins
Cincinnati

This paper is a bit dated. It was written over 2 years ago. Some of the assertions regarding J2EE limitations are no longer true. J2EE 1.4 includes first class support for Web Services.

This paper is a bit dated. It was written over 2 years ago. Some of the assertions regarding J2EE limitations are no longer true. J2EE 1.4 includes first class support for Web Services.

I just realized my comment is unclear. I am referring to the Lykins white paper, not the new paper that is the original subject of this thread.

There are two things that you should bear in mind when looking at the J2EE vs. .NET debate, especially as it relates to IBM vs. Microsoft.

1. IBM can send battalions of consultants from their 250,000 man army and tell managers to "sign the check and we'll make your problems go away". That's a very compelling offer if you're a business exec. Microsoft, on the other hand, does not have much of services wing. They're primarily a software company. Not a hardware company like Sun, IBM or Apple. Not a services company. So, they need .NET as a platform to make sure they can use Java-grade languages for building future versions of their flagship products, and also so they can get ISVs on the smaller end of the market to buy their development platform for building software.

2. The IBM/J2EE white paper focuses on the role the two companies play with regards to ISVs, but that's too general. The difference is that in the Java world, ISVs are building things like CRM suites and development tools, whereas in the Microsoft world they're using Microsoft's CRM suites and development tools to build things like video games and small business portal apps. And when they *do* build their own development tools, they're usually plugging extensions into the Microsoft platform.

The point is, and I definitely got this impression when I was at TechEd this year, despite all the hullaballoo, Microsoft and IBM haven't really been competing for middle market share--at least not the way they're going to be in the next five years. So far the J2EE crowd has been racing against Oracle and SAP tribes up in the mountains and the Microsoft guys have been farming the lowlands. But it seems Microsoft's been looking up and all the different companies in the J2EE space have been looking down. The push for SOA is only going to accelerate that. I think the middle ground is going to be hotly contested in the next few years. You're going to see the BizTalk vs. Websphere & BizTalk vs. Weblogic articles rolling out as each side tries to build up developer loyalty and make their products more appealing to mid-market officers. I would point out BEA's new dev2dev site as exhibit A.

One interesting question is how SAP and Oracle are going to respond to this. Is IBM going to be fighting a software war on two fronts? If you're an ISV it doesn't really matter--more competition in the low-to-middle portion of the market means better tools from Microsoft, and more open standards and better prices from the JCP crowd. Hopefully the big J2EE companies will keep their heads stuck in the clowds and Microsoft will keep its feet stuck in the mud long enough for the middle market to diversify and flourish for a little while. It'd be nice to get an infusion of new leaders and players from the low end of the market.

Besides, you know what more mid-sized vendors means--more swag at conferences ;)

My $.02
--
N. Alex Rupp