-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
Am Mittwoch, 5. Februar 2003 20:54 schrieb Steve Loughran: > > > > You can plug-and-play different XML parsers and XSL transformers in .NET? > > They ship with XML parsers that work *out the box*. And good pull model > ones too, if that is what you want. Yeah, I know that XML parser, it's even not possible to validate XHTML 1.1 or XHTML Basic with it because it still (as far as I know - is it already fixed?) has a well known bug regarding resolving URLs of entities, they are resolved form the referencing document instead of the declaring document. And we all know MS's "good support" of XSLT, haha. First they put on their gloriole by implementing a draft in IE, but the devil showed his face when the recommendation was published. Where was MS when XSLT became a standard? Yeah, we all know what "good support" and "out of the box" mean in MS context, especially regarding XML. That was one of the reasons for me to migrate even the last of my work systems from Windows to some UNIX and Java. For me, Windows is only good for computer games, and even there Linux is slowly catching up. Am Mittwoch, 5. Februar 2003 18:39 schrieb Nau, Michael: > We are looking into shifting our component-based development environment > from java & j2ee to c# & .NET. Am Mittwoch, 5. Februar 2003 19:14 schrieb Armenio Pinto: > Outch! It burns! Ack. Okay, seriously, I can't see a single argument for moving a serious business application from J2EE to .NET. Here's why: 1. It's easily possible to redeploy J2EE components during runtime, even in most of the simpliest (pseudo) appservers like the J2EE reference implementation. It's not so easy to do so with .NET. 2. J2EE application servers can easily be clustered. Especially, no recompilation of the components is neccessary. In .NET, the number of CPUs / Servers is a compilation flag. 3. In good J2EE servers, even session data is stored on persistent storage, just in case one of the servers handling sessions fails, then another server can take the load without the loss of the session data. 4. J2EE in general clusters very well. As soon as your machine gets too slow, you get a second one or a faster one, *without* limit. In .NET the limit is set by the very low level of maximum hardware available for Windows. Of course there are also Windows NT clusters. But try comparing a Windows NT cluster with an IBM or SUN mainframe... And again, .NET needs recompilation... 5. J2EE has a very good component design. Using Remote instead of Local interfaces enables easy clustering. Correct usage session and entity beans is an easy maintainable design that comes quite close to what's required. In .NET, Microsoft recommend that you neither use Remote nor seperate the presentation from the process from the data layer because it impacts performance. As soon as you try to achieve the same design goals you'd do with J2EE, performance of .NET is worse than that of J2EE, especially when using Remote for clustering. Microsoft recommends especially not to use that. 6. 365/7/24. Consider all arguments above: It's impossible to realize 95% or more availability with .NET. But it's quite usual to achieve this with J2EE. 7. Performance. It's always told .NET would be faster than J2EE. Okay, try .NET in a distributed environment with objects representing business data, objects representing business projects and objects responsible for the visualization. Seperate these layers and make a .NET cluster with that. *Then* compare the performance, and see the results. But don't compare a flat .NET design with an even internally multi-tier J2EE app server. If it's just some ASP's, it's unfair to compare that with J2EE EJB design, a comparision with JSP is appropriate. The so called "performance statistics", like that of IDC, are usually comparing apples and oranges. Of course, if all this doesn't count, then .NET might be a choice. Am Mittwoch, 5. Februar 2003 19:04 schrieb [EMAIL PROTECTED]: > HAHAHAHA Am Mittwoch, 5. Februar 2003 19:16 schrieb David McTavish: > Maybe such immature comments are better left untyped, or at best, posted to > a different newsgroup. By the way, I don't agree with Michael's laughter. I find it quite thought-provoking that someone drops J2EE in favour of .NET. And I find it quite provoking that such a person even requests help and tipps from the Ant User mailing list. Considering Microsoft's intolerance (especially about Java) that really strains my personal tolerance. I don't think Michael's laughter is immature. So I admire he's able to laugh so loud about that. Am Mittwoch, 5. Februar 2003 19:16 schrieb David McTavish: > You should, at the least, acknowledge the fact that > they are still contemplating the use of ant, which, in my mind, is a HUGE > compliment to the tool. Do you all really think Ant will become the favourite build tool for .NET? As soon as Ant will be somewhat successful for .NET, Microsoft will clone it and release a rival, and what do you think the .Netters will use? But don't dream of MS support for Ant. They're gonna forget Ant quite soon and be very happy to live with a tool that doesn't require a modern JVM. My 2 cents Bye - -- ITCQIS GmbH Christian Wolfgang Hujer Gesch�ftsf�hrender Gesellschafter Telefon: +49 (0)89 27 37 04 37 Telefax: +49 (0)89 27 37 04 39 E-Mail: [EMAIL PROTECTED] WWW: http://www.itcqis.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+QXjjzu6h7O/MKZkRAklWAJsF5Jz/GWTzvvbejKOqqMXT6yzGAwCgzaZy zuJnRvHJj1n9G/ExNedoLWg= =by7J -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
