A new article in this month's Computer World makes a case for Microsoft to be the leader in delivering web services. The author goes through and makes several comparisons to J2EE strengths and .NET strengths and comes up with a matrix that just edges out J2EE.
You can read the full article here
Computer world also has their own discussion board
that has some interesting points.
Add your comments here or to the Computer World discussion board and let the author know if he is right on the money?
Could it be that Microsoft really is becoming more open as the author suggests?
The author, Don Lykins is the CTO for PortalSoft
The only product Portalsoft has to offer is "Sales & Project Tracking for Microsoft Outlook and Exchange." Where did he get his J2EE experience for him to write this article? LMAO
It obvious this individual is oblivious about the J2EE web services arena.
Hi n n,
Just to let you know - there is a big difference between PortalSoft Tecnologies Inc. (www.portalsoft.com) and Portalsoft Inc. (www.portalsoftinc.com)
To quote from the original article:
Don Lykins is chief technology officer of Portalsoft Inc., a Cincinnati-based Web application development and professional services consultancy. For a more detailed analysis of J2EE and .Net, see the J2EE vs. .Net white paper (download PDF). You can reach Lykins at dlykins at portalsoftinc dot com.
It's a little hard to critique the article. There really wasn't any information there. The author felt that MS had a better security offering due to PassPort. On one hand, I have to agree -- they have the whole security enchillada as part of their .Net plans, and one could even argue that they made a good choice for their customer-developers to provide such a feature. On the other hand, one could easily argue that having to use PassPort is as bad as having to deploy on IIS (both products have their good points, but that doesn't mean I want to be without choices!). Also, with Microsoft's security record (including PassPort already getting hacked) I can't see publishing an article with a straight face that shows them "ahead" in that category. As long as Microsoft is Microsoft, they will be a magnet for the best crackers out there, and their technologies and sites and servers and services will get hacked.
Microsoft does offer a much more complete "web services" product though ... the OOTB experience for a developer bought into "all Microsoft all the time" will be better than that of the Java developer. OTOH, not having to integrate with anything other than one's own products does simplify the problem domain quite a bit (one dev tool, one OS/hardware platform, one web server, etc.). Note that many of the necessary pieces to the Microsoft .Net platform are still beta, so it is a bit odd to compare to the Java software that has been shipping and stable and in actual enterprise use for the past several years.
Spot on!! You've hit the nail on the head. .NET may be really well thought out, well integrated with web services etc. But it means going 100% with MS despite what Jim, Greg and Adi like you to believe. That alone is a showstopper for me.
If .NET would mean 100% lock-in then the whole notion of Web Services wouldn't make too much sense. When all you want is tightly integrated apps based on a MS platform, then COM/DCOM is just enough. Why then open protocols like SOAP/WSDL?
I think, on the contrary, the whole idea of Web Services is going in a different direction than the WORA goals promoted by Java. Web Services were invented to solve the interoperability/integration problem - a story that, ironically, is less important for applications based on Java - that's because you already have standard communication protocols, like RMI over IIOP.
.NET is not trying to force you to rewriting everything in, say, C#, but to keep your legacy app and integrate it using a Web Service.
Let's pick a clear scenario: for example you have an enterprise app in COBOL with, say, 2 million lines of code. Suppose you must integrate this application with some other systems, let's say a new Java app.
If is reasonable to run this app on a Microsoft platform, then with .NET you can just recompile the app using COBOL.NET and expose it as a Web service. If this is not reasonable, you can still choose to use some non-MS SOAP libraries (supposing there are any) and still expose the app as a Web service. But that may be a harder exercise - since .NET has native support for Web Services, down to metadata/IL level - therefore independent of the programmign language.
On the opposite, the J2EE alternative is to rewrite those 2 million lines of code in Java, correct?
The conclusion is that .NET (Framework) is intended to solve a different business problem than Java/J2EE. That may not be apparent if you treat .NET just as a Java competitor. Well, that's explainable to some level - when you have a hammer in you hand then everything looks like a nail.
P.S. These are my personal opinions and may or may not represent the position of my company (Microsoft Corporation)
Ahh com'on. Just recompiling 2 million lines of codes with Cobol.NET just doesn't hold out in my opinion. What about all platform specific services such a cobol program would be depending on? And how well does,an obviously object oriented version of Cobol, support the old version?
It's a sweat idea with porting legacy apps this way, but I trouly don't believe any serious company would want to do it like that. Say you have large system running in your corporation (ie. an insurance company), I hardly think they would be willing to exchange their stable and solid mainframe platform for a web-service enabled version running on a less stable PC platform using Microsoft Windows (or Linux for that matter). There would be other and smarter ways to do it, while still keeping the old platform.
On the question about how easy it is to make a method webenabled on .NET compared to on Java, have a look at what The Mind Electric is doing with GLUE(http://www.themindelectric.com
). They're take a different path than .NET (no stubs, no skeletons and no WSDL generators) and it seems almost as easy to me as the WebMethod attribute. I admit this is not native to J2EE, but it's still available for the platform and the standard version is free for most commercial uses (but lacks in support for most J2EE specific needs). If anyone has experience with GLUE, I would love to hear about it.
Just my 2 cents.
What about all platform specific services such a cobol program would be depending on? And how well does,an obviously object oriented version of Cobol, support the old version?
It's a sweat idea with porting legacy apps this way, but I trouly don't believe any serious company would want to do it like that.
Again, COBOL was just an example - I could pick FORTRAN or C++ instead. Anyway, you'll be surprised that actually there are serious companies considering that - you might want to check the site of Fujitsu COBOL for their integration/migration path to .NET. See http://www.adtools.com
. or http://www.adtools.com/info/whitepaper/msdotnet12_01_whitepaper.htm
for more details.
The J2EE-alternative would not be to rewrite the 2 million Cobol-program in Java. It would be to use a JCA connector implemented by the same guys that did the actual transaction-manager for Cobol (ie. IBM). This would integrate into the ejb-container with full support for security-propagation and 2-phase XA-commits. I wouldn't even start thinking about using SOAP etc. for this. For example XA has been around since long before Java but the SOAP-alternative for distributed transactions is barely conceived.
There has been integration between Java and mainframe systems for years now. We're starting to get the hang of it, sorting out all the issues and actually getting some stability and performance. Redoing it all again with .NET is simply not an alternative in an enterprise-level scenario.
Uh, yeah, .NET could probably be used for the zip-code validation-service mentioned in the article. :-)
If is reasonable to run this app on a Microsoft platform, >>then with .NET you can just recompile the app using >>COBOL.NET and expose it as a Web service. If this is not >>reasonable, you can still choose to use some non-MS SOAP >>libraries (supposing there are any) and still expose the >>app as a Web service. But that may be a harder exercise - >>since .NET has native support for Web Services, down to >>metadata/IL level - therefore independent of the >>programmign language.
>>On the opposite, the J2EE alternative is to rewrite those >> 2 million lines of code in Java, correct?
I'm sure a customer will take there legacy Mainframe programs and run it on Windows. Since Mainframe programs have no other dependencies like IMS databases, CICS transactions, or VSAM files.
This is clearly an unrealistic solution. I really don't think most serious companies will run their thousand transactions a second CICs program on windows. I don't think a J2EE developer or architect would do the same.
A J2EE architect will leave that investment alone and utilize an array of different technologies like JMS over MQSeries, CORBA client, or Java 2 Connectors. A J2EE application could even be a web services client(although, except for the lack of XML, isn't a web service almost like a COBOL copybook anyway). Cobol has had function calls encoded in data for a very long time.
Web services is a good technology, however, i'd hate to see poeple using solutions for the wrong problem. The web application should call the legacy system. The web service wraps the web application business objects.
I'm sure a customer will take there legacy Mainframe programs and run it on Windows. Since Mainframe programs have no other dependencies like IMS databases, CICS transactions, or VSAM files. This is clearly an unrealistic solution. I really don't think most serious companies will run their thousand transactions a second CICs program on windows. I don't think a J2EE developer or architect would do the same.
Note that I wasn't talking about mainframes (I didn't even mentioned them). My scenario was about reaching seamless interoperability between two apps written in different languages. I could choose choose Fortran and C++ as well. My point is: using Java makes sense only if you can (re)write in Java - regardless of the size of your code. And there is and there will be large amounts of non-Java code.
>>> A J2EE architect will leave that investment alone and utilize an array of different technologies like JMS over MQSeries, CORBA client, or Java 2 Connectors.
Integration solutions are also well addressed (at least in theory) by web services. All vendors that supported CORBA in the past (IBM, Iona, BEA, etc.) are now big supporters of SOAP-based protocols.
That being said, I recognize that it is too early to draw a definitive conclusion since the web services market is still in early stages.
>>> Web services is a good technology, however, i'd hate to see poeple using solutions for the wrong problem. The web application should call the legacy system. The web service wraps the web application business objects.
Web services don't require web applications at all - they are all about server-to-server communication using SOAP over HTTP or even over TCP/IP. The last option doesn't even require a web server/client.
When you mention a language like COBOL, you have to mention the mainframe. I don't think there are too many COBOL implementations on the PC. Taking an old language and compiling everything into a new runtime is nice in theory. But in practice it is probably impossible to find an application where you woundn't need to rewrite code. I feel that Integration solutions produced by people like IBM are more than theory. Real world integration implementations already exist. You may be able to take C++, but I would imagine that would only be Visual C++. I can't imagine taking a C++ application in UNIX and compiling it to .NET and running it on the PC without any re-write.
Thankyou for the correction Adi but the basis of my concern is still the same. It's good to see he has knowledge about Microsoft products(Wrote the book “Building Enterprise Applications with Visual Studio 6”) but where is his J2EE experiences ?
There was serveral instances in his article where I see J2EE exceeding .net but it seems he is not aware of such
products.The number of J2EE geared products on the market is astonishing.
Could it be that Microsoft really is becoming more open
> as the author suggests?
No, no, no. Don't fall for this trap. Just because MS promote SOAP/UDDI/W*DL et al. does not make them more open. It is true that .NET developed web services will be able to talk to J2EE developed web services which can talk to a web service developed in Perl, Python etc -- this is good and necessary (otherwise who'd want web services??). You really only need a language with a XML parser to use web services remember. At the basic level, web services are still good ol' RPC via XML over HTTP.
However the company which uses .NET to develop a web service will find themselves 100% tied to MS products from there on -- changing vendors will be "just too hard". They will need to purchase .NET servers (at least one) and/or talk to MS .NET servers (e.g. Passport). Of course MS will then begin to charge for each time you use a .NET service (e.g. Passport) and before you know it you are tied into using MS products indefinitely and paying MS each time you use one of their services. Just as companies are now tied into MS OS's on the desktop they will be tied into MS products on the server side - then it will be MS everywhere and Bill will finally be happy. Clever plan eh?
Don't listen to marketing talk, read for yourself, make decisions based on your own intelligence, not SDTimes articles or whatever else.
Great point here. Thanks, Ben.
I don't believe in this article at all. Whatever comparison chart says, I always believe Open Source/platform wins. Why I say this is, whatever .NET has, people still have to depend on Micrsoft for its Webservices products. Whereas, on the J2EE side, customers have lot of products to choose from. And, because of this competition to offer the best, one can get really a good product as compared to .NET. And, if J2EE is not so robust(as the author thinks so), it'll be as so many minds play with it to shape it well rather than .NET has all the inputs have to come through only one channel.
To be honest (again :)), at the moment, using .NET to develop web services really is easier than J2EE. For example , you can use the [WebMethod] attribute in C# (in combination with ASP.NET) to specify that a method should be available as a web service automatically. .NET does the rest for you (see http://www.25hoursaday.com/CsharpVsJava.html#attributes
for a web service example in .NET).
So I think J2EE, or should I say J2EE tools, have a way to go to match .NET for ease of use.
Then again I think web services also have a way to go before they succeed (if ever) so it is not that big of an issue to me.
<Ben Reid on January 6, 2002>
To be honest (again :)), at the moment, using .NET to develop web services really is easier than J2EE. For example , you can use the [WebMethod] attribute in C# (in combination with ASP.NET) to specify that a method should be available as a web service automatically. .NET does the rest for you (see http://www.25hoursaday.com/
CsharpVsJava.html#attributes and http://
www.codeproject.com/webservices/ myservice.asp for a web service example in .NET).
</Ben Reid on January 6, 2002/>
You can do exactly the same thing with XDoclet in java (sf.net/projects/xdoclet). Just put a @soap:method in method's comment and it becomes a soap callable method. XDoclet supports a long list of these kind of @tags (ejb, web, app-server specific, castor, soap, etc) and you can create @tags of your own very easily. It's sad ppl don't know about xdoclet a lot, it's really cool, opens new opportunities for you to automate many things.
<Ara Abrahamian on January 7, 2002>
You can do exactly the same thing with XDoclet in java (sf.net/projects/xdoclet). Just put a @soap:method in method's comment and it becomes a soap callable method. XDoclet supports a long list of these kind of @tags (ejb, web, app-server specific, castor, soap, etc) and you can create @tags of your own very easily. It's sad ppl don't know about xdoclet a lot, it's really cool, opens new opportunities for you to automate many things
</Ara Abrahamian on January 7, 2002>
Great! Thanks for that information Ara. I was hoping someone would correct me and tell me J2EE tools are getting just as easy as .NET - I knew it was only a matter of time. I'm off to download xdoclet and try it out now ... :)
MS puts a LOT of time into making nice tools for developers and it's important that J2EE tools become comparable -- because then the other benefits of J2EE can really shine.
The author speaks as if security concerns with soap is less reliable on j2ee, far from the truth. Please read:
ok let me set this straight. what are web services ??
its just about exposing ur applications/services as XML-RPC calls. and that can be accomplished using standards like SOAP, UDDI, WSDL. theres nothin rocket science about it. period.
the underlying technologies used to accomplish this are :
- TCP/IP - HTTP, SMTP etc
- Your Application (J2EE/.Net)
so whats the fuss about.
i think it will be a much healthy debate if we talk about J2EE vs .Net. and we all know which is a better and open technology out of the two, for now. Gotta be JAVA/J2EE.
so this talk bout which is better web services platform is all farse.
As someone mentioned above, its all about tools. How fast can we enable our applications as web services. Using a product like CapeClear, in no time, u can web service enable ur existing J2EE app.
WebService is just an extension/application of the existing technology(TCP-IP/HTTP/XML).
I also think webs services has been really over blown. i guess we all know why. M$ is using this hype to bring out .Net.
web service is great for interoperability, B2B etc., but the fact is that its not the answer to all ur problems. its been made out to be just that, by M$.
Kapil is absolutely right on the money here -- a healthy debate will come from discussing the merits of J2EE vs. .Net -- not focusing on Web Services as the end-all be-all.
For those of you who are Java developers, I think you'll
find that GLUE is even easier than .NET for creating,
deploying and consuming web services. GLUE makes any
Java object (not just EJBs) auto-magically into a web
service at runtime, with no stub generators or WSDL
generators required. The standard edition is free for
most commercial uses.
You can download GLUE from
Developer quotes are at
The article author states:
".Net has a slight edge due to the use of Microsoft's Passport, which supports the Kerberos v5.0 standard"
and yet J2SE 1.4 changes have:
"The Java GSS-API can be used for securely exchanging messages between communicating applications using the Kerberos V5 mechanism"
Am I missing something? Or is the author claiming something for .Net that will very shortly be part of standard Java?
Enterprise Wars -- J2EE vs .NET (the original article http://www.portalsoftinc.com/resources/j2eevsnet.pdf
which the PC World article is based on) tells a different story.
Most significantly, the mindless red dots per less-than-objective merit table puts J2EE overall at 56% and .NET at 51% "J2EE has a slight edge over .Net, mainly due to multi-platform supt"
I'm tired of wasting my time reading all this MS propaganda. I hope this good site ( until now ) doesn't follow the same way of javalobby.org . That I have to leave because the poor leadership blocking this kind of missinformation. I hope the serverside staff do something about it.
Healthy debate is a Good Thing (tm).
A lot of Java developers are interested in other server side initiatives in the dev arena. If you do not like to hear about .NET then:
- right now: just don't read the thread!
- soon: you will not have the keyword ".net" checked in your preferences, when Rickard and crew get to work ;)
I go off on a completely different tack on this because I was on the architecture team for E-Speak. I don't think .Net currently is showing the best approach for Web Services (WS). The reason is that the registry architecture is based on replication. When I want to discover a web service so that I can invoke its method, I present a schema/ref to the UDDI registry to lookup the service. If the schema is not in the registry then I get nothing.
Our architecture was such that you would connect to a "core" - which can be thought of in the same context as the registry, look a service up using the schema (we called it vocabulary) and invoke methods, etc. The cores were networked via an "advertising" service so when you registered a service you could make a call to advertise it as well if you wanted to. The lookup could then match any schema out on this internet of cores regardless of which node got the lookup call. If you think about this in terms of the fuzzy capabilities it can become very interesting. I hope that the current standards will evolve to support these models. AFAIK they currently fall short.
hahaha .NET security beating out Java my A$$
and they used Passport of all things as the reason? Wasn't a security hole discovered just a couple of months ago? Oh yeah. It was:
well, now that it's a new year, hopefully Microsoft made some New Year's Resolutions about security. Even though they fixed Passport and the .NET framework is still beta, they're working on security, right? Oops, guess not. Being the concept that it is, it's funny that there's already a 'conceptual' virus for .NET =p
i'm just being facetious, by the way. but still, stories like this just means more setbacks for Microsoft's .NET
Personally, I think it's good that there's a competing platform for web services. Having .NET on the market just makes J2EE seem even better =p