.net

[bolidecaster]

It is said in the manual that the most serious drawback of choosing .NET is that non-Microsoft platforms are not supported. How do you think of MONO(http://www.go-mono.com/) and DotGNU (http://www.dotgnu.org/)? Thanks!

[marc]

Have a look at .net .

[michi]

Originally posted by bolidecaster
It is said in the manual that the most serious drawback of choosing .NET is that non-Microsoft platforms are not supported. How do you think of MONO(http://www.go-mono.com/) and DotGNU (http://www.dotgnu.org/)? Thanks!

Not wanting to be too biased about it, but I'm skeptical too. Remember the DCOM UNIX implementation by Software AG? That was an unmitigated disaster: it never worked properly and went nowhere. I also think it is highly likely that MS would fight any moves to make .NET availabe as Open Source. My feeling is that, if you need cross-platform functionality, you had better not look to MS technology to get it.

Cheers,

Michi.

[bolidecaster]

Thanks for the reply. I am an absolute fan of Ice.

MS is always MS. Regarding the future of Mono or DotGnu, let's wait and see.

[rdilipk]

Originally posted by michi
Not wanting to be too biased about it, but I'm skeptical too. Remember the DCOM UNIX implementation by Software AG? That was an unmitigated disaster: it never worked properly and went nowhere.

I can't believe that could've been anything more than an academic exercise. If Software AG really thought they could generate some commercial benefit out of it then they were just skating on thin ice. I believe Don Box (http://www.gotdotnet.com/team/dbox) worked on that project and it isn't such a far fetched idea to assume that of all the people, _he_ would've known that such an exercise may never yield any benefits.

Originally posted by michi
I also think it is highly likely that MS would fight any moves to make .NET availabe as Open Source.
[/b]

So lets assume that MS doesn't make .NET Open Source -- so what? That doesn't make the .NET framework any less technologically competent.

Originally posted by michi
My feeling is that, if you need cross-platform functionality, you had better not look to MS technology to get it.
[/b]

Well you are famous for your views on this but I hate to break it to you again that Webservices are the current fad that will lead to cross platform interoperability. Whether we would end up with CORBA all over again is another matter altogether. Currently the movement is there and all the big boys (MS, IBM, BEA, IONA...) are putting their money behind it. So its a little presumptous to suggest that its nothing more than collective stupidity.

--Dilip

[marc]

I really don't want to start a big discussion here, but the original question was about .NET. And .NET != Web Services. .NET is one possible platform for Web services, as are many many others.

And as far as I know, the Mono project focuses on C#, the CLR, etc., but not so much on Web services.

As for Web Services (with .NET or without), I'm sure they have their place. But they can impossibly be used for what I call "technical middleware". They are way too slow for that, due to SOAP.

As for the "movement" behind Web services, I think this is pretty much a thing of the past. Nobody gets excited by mentioning Web services anymore. (But this is of course a very subjective view, other might see this differently.)

And for putting money behind Web services: There is one company among the four you mentioned that nearly ruined itself by putting all its energy behind Web services...

[rdilipk]

Originally posted by marc
I really don't want to start a big discussion here, but the original question was about .NET. And .NET != Web Services. .NET is one possible platform for Web services, as are many many others.

The original question had nothing to do with web services in the first place. I brought it up only because Michi said that you shouldn't look twds MS for cross platform interoperability. That was true a couple of years ago. If you buy into the web services mantra then this argument no longer holds but if you don't the discussion is moot anyway. We are simply arguing whether cross platform interoperability exists in the MS world -- not whether web services are technically superior or not.

I have followed Michi's posts everywhere and I have learnt so much simply by reading what he writes (and this being I have nothing to dowith CORBA) -- I respect him a LOT. 2 years ago he argued about the importance of source code portability with another famous personality in comp.object.corba. Today he has made a 180deg turn and posted that <quote>The much-lauded source code compatibility in practice does not exist</quote>. I am not challenging him (I must be an idiot to do that :-))All I am saying is people change, views change and technologies gain or lose traction depending on your experience with it.

[michi]

Originally posted by rdilipk
So lets assume that MS doesn't make .NET Open Source -- so what? That doesn't make the .NET framework any less technologically competent.

Hi Dilip,

I agree -- there are nice things in .NET. I especially like the concept of pervasive metadata. By making everything aware of the type system, I can do nice things, especially in the tool area. But that is of little consolation if I cannot use it on anything but MS platforms.

Well you are famous for your views on this but I hate to break it to you again that Webservices are the current fad that will lead to cross platform interoperability.[Whether we would end up with CORBA all over again is another matter altogether.

Dilip, I am skeptical. The whole web services thing, in my opinion, is very ill conceived. Historically, it came about not for technical reasons, but for reasons of market and mind share: in the days of the CORBA-DCOM wars, MS were about to lose the wide-area networking market. HTTP had done things no-one thought it would be able to do, and CORBA was stealing the show for heavy-duty RPC work. Around the same time, XML became the flavor of the month. MS applied a time-tried strategy to deal with this: instead of fighting a war they couldn't win, they simply left the battle field and came up with web services and SOAP, diverting attention to an entirely new area. Whether it made sense technically to use XML and HTTP to implement RPC was completely irrelevant in this decision.

Technically, I see many serious problems with SOAP, first and foremost the insane cost in bandwidth and CPU: years ago, I wrote an article in comp.object.corba that showed that SOAP costs anything between 20 and 100 times as much as IIOP in terms of bandwidth (and IIOP is not anywhere near as compact on the wire as the Ice protocol), and that SOAP costs anything between 100 and 1000 times the CPU cycles to marshal and unmarshal. That is simply ridiculous and makes it totally unsuitable for many applications. (Yes, bandwidth is cheap, but not that cheap: I get as much traffic through a modem with Ice as I get through a broadband connection with SOAP.)

Also, the security implications of SOAP are frightening. Paul Prescod has quite serious criticism about the security implications of SOAP, and Cheswick, Bellowin, and Rubin ("Firewalls and Internet Security", Addison-Wesley) also say quite a few very non-complimentary things about SOAP's non-existent security model.

Currently the movement is there and all the big boys (MS, IBM, BEA, IONA...) are putting their money behind it. So its a little presumptous to suggest that its nothing more than collective stupidity.

I don't think I ever used those words But this isn't so much a matter of collective stupidity, as one of riding the wave and following current trends. As Marc pointed out, at least one company of the four you quote nearly ruined itself trying to ride this wave. And the history of computing is full of bad ideas that never went anywhere, no matter how many large companies tried to push it. Ultimately, functionality and performance are just as important as being with the latest trend. Or, more accurately, no matter how trendy my software may be, if it doesn't perform or causes my company to loose data or get hacked, I will eventually turn to something else (most likely after having been burned first).

I seriously doubt that something as flawed as SOAP is going to be the foundation of our future wide-area commerce network, especially given the security implications, let alone the performance problems. (I may be wrong though, seeing that insecure e-mail is a large part of our commerce foundation today, and that a 16 year old with a virus construction kit can just about bring down the world's economy, thanks to Outlook -- but I digress.)

The original question had nothing to do with web services in the first place. I brought it up only because Michi said that you shouldn't look twds MS for cross platform interoperability. That was true a couple of years ago. If you buy into the web services mantra then this argument no longer holds but if you don't the discussion is moot anyway. We are simply arguing whether cross platform interoperability exists in the MS world -- not whether web services are technically superior or not.

Dilip, I'm afraid that it is impossible to leave the technical argument out of any discussion about cross-platform interoperability, especially if there are serious security and efficiency problems. Any cross-platform infrastructure (especially when used for commerce) must address these issues, otherwise the technology will fail pragmatically. Web services might be useful as a fallback position when everything else fails (like comma-separated text files for spreadsheets get used when all else fails). In that sense, web services might become a lingua franca. But web services also might end up in the same position as comma-separated text files (or Esperanto, for that matter): no-one uses them unless they have no other choice.

I have followed Michi's posts everywhere and I have learnt so much simply by reading what he writes (and this being I have nothing to dowith CORBA) -- I respect him a LOT. 2 years ago he argued about the importance of source code portability with another famous personality in comp.object.corba. Today he has made a 180deg turn and posted that The much-lauded source code compatibility in practice does not exist.

Dilip, I have spent many years working for that portability and I argue today as much as I did then that it is important. However, despite my best efforts (and those of many other people), that portability simply hasn't happened: current CORBA C++ code is, as a rule, not portable, especially when you take into account all the peripheral issues, such as configuration, build environment, etc. That is just how it is, specification efforts notwithstanding. And, even when source code is strictly portable (that is, limits itself to the specification), the price I pay for that portability is horrendous. Let's face it: the CORBA C++ mapping simply sucks and you have to be a masochist to put up with it. And, even then, it is impossible to write serious CORBA applications without stepping outside the specification, simply because the specification does not address a whole host of issues that I need to deal with in a real application. To me, that is too high a price to pay for source code portability that only exists on paper.

I'd love to have a portable middleware platform: it really could do wonders for distributed computing. But I'm afraid that neither CORBA, nor .NET, nor web services are going to provide such a portable platform because they all have problems that, pragmatically, make them unsuitable as a portable and ubiquitous solution.

I am not challenging him (I must be an idiot to do that :-))

Dilip, I'm flattered but, honestly, I screw up as much as the next guy. Just because I'm outspoken that doesn't mean I'm infallible

All I am saying is people change, views change and technologies gain or lose traction depending on your experience with it.

Right, I couldn't agree more. The problem with web services and SOAP is that there is hardly any experience with it. (I am not aware of a single heavy-duty and mission-critical system that has been built with web services to date.) Once people try to build such systems with web services (and my prediction is that they will fail), the pendulum will swing the other way and people will start yet again on something else. The joke in all this is that the core issues in distributed computing are very well understood and that we can easily build something that is better than web services or CORBA. (We do have enough experience for that, given the long history of RPC platforms, such Sun RPC, Apollo Domain, DCE, CORBA, and DCOM.)

Personally, I believe that Ice is the best general-purpose middleware platform that anyone has ever built. That's why I am putting my efforts into that instead of continuing to work on a doomed effort such as CORBA.

Cheers,

Michi.

[ganzuoni]

Hello,
just few considerations.
About portability: no mention to Java.
I think that CORBA C++ portability troubles experienced by Michi,
almost vanishes with Java.
Are you going to dismiss Java support in favour to C# ?
(Don't worry, I think I know the answer !).
And two words on Webservices.
I think that the only advantage is SOAP over HTTP, that lets you
avoid firewall.
All the rest is a deja-vu with a LOT of missing pieces.
wsdl ("and the idl that it is not", recalling a wonderful article). I challenge
anyone to repeat twice the experience of writing a wsdl by hand.
Server deployment.
(I hope Michi not shooting me !).
Well, I think, wrt the situation at that time, POA is a great idea !
Yes, TOO MUCH complicated in many aspects but the separation
of object references from servant, POA current, ServantLocator,
lifespan policy, id assignment, I think that are concepts that
mark a milestone of what a server deployment environment MUST
provide to the applications.

My 1 cent (surely not necessary)

Guido

[michi]

Originally posted by ganzuoni
Hello,
just few considerations.
About portability: no mention to Java.
I think that CORBA C++ portability troubles experienced by Michi,
almost vanishes with Java.
Are you going to dismiss Java support in favour to C# ?
(Don't worry, I think I know the answer !).

No, I don't think we'd abandon Java

And, yes, I agree -- the CORBA Java mapping has far fewer problems than the CORBA C++ mapping. (But CORBA has lots of other problems that have nothing to do with the language mappings.)

And two words on Webservices.
I think that the only advantage is SOAP over HTTP, that lets you
avoid firewall.

I don't think that's an advantage at all. At first, it seems attractive. But then, once you realize that this effectively disables the entire firewall and allows absolutely anything to happen to the machines behind the firewall, this isn't so attractive anymore. Compare this with the Glacier approach: it gives you better control and is much safer than tunneling things over HTTP.

All the rest is a deja-vu with a LOT of missing pieces.
wsdl ("and the idl that it is not", recalling a wonderful article). I challenge
anyone to repeat twice the experience of writing a wsdl by hand.
Server deployment.
(I hope Michi not shooting me !).

No, not at all. The entire notion that XML is "human-readable" is a joke. Every time I look at anything but the most trivial XML, my eyes water. IDL (and other languages) are both machine- and human-readable. XML is machine-readable and, just maybe, masochist-readable

Well, I think, wrt the situation at that time, POA is a great idea !
Yes, TOO MUCH complicated in many aspects but the separation
of object references from servant, POA current, ServantLocator,
lifespan policy, id assignment, I think that are concepts that
mark a milestone of what a server deployment environment MUST
provide to the applications.

Right. To build decent applications, I need those concepts, or at least some of them. For example, I would argue that POAManagers are not necessary and just complicate the API (and its semantics) and that the LIFESPAN_POLICY is a waste of time, as is the idea of implicit object activation and the distinction between USER_ID and SYSTEM_ID. Ice proves that all of these concepts can be realized with a much simpler and smaller API, with no loss of functionality. Just compare the POA IDL to the Slice definition for the Communicator and the ObjectAdapter. Same functionality, but much easier to use API.

Cheers,

Michi.