DCE/RPC Open Source kick-start

For the Unix world, CORBA already establishes itself and many free implementationds are available (even used in GNOME). For people looking for simpler ones, the original RPC (Sunrpc), SOAP, Jxta and so on are available.

Supporting DCE/RPC is not very productive. It makes sense only to interoperate with Microsoft products. That's not the direction for the future of Unix.

the market for dce/rpc is weird. it's almost invisible. the corporations that deploy dce/rpc applications are the _really large_ ones, where the negotiation of the contracts last eighteen months, the project development takes five years of which two years is product specification and requirements, and the product is deployed for the next ten.

so, your statement - corba, java, onc/rpc, soap, and .net are the future - is understandable.

it's also understandable from the perspective that corba was released in... 1996, by olivetti labs, under the gpl - 250,000 loc.

dce/rpc is now available for linux under the OSF/1 open source license, in the form of freedce.

now, that's a four year gap, so i am not surprised that corba is the 'de facto' standard. oh, and it's also 250,000 loc.

how much of what you say - corba is 'The Standard' - do you think is due to the fact that the code is, was, simply available earlier; how much of a bias towards linux, if any.

*interested*.

"8 million lines. 8 _million_ lines. 8 milllion _lines_" -- Danny DeVito, paraphrased by lkcl in another article's comment.

hiya,

well, since then i actually ran a wc on the dce 1.22 runtime env & applications: it's only 3.6 million lines, not 8 :)

the runtime library, endpoint mapper and idl compiler all still come only to a total of 250,000, in freedce (aka dce 1.1). dce 1.22, it's a little bit more, because it includes a kerberos security model which the apps that The Open Group have available with the 1.22 codebase need kerberos.

so, the code you _need_ to actually get going and actually doing apps - if you don't mind not having security for your first version - is the same size as the Olivetti Lab's GPL'd version of CORBA - 250,000 LOC.

The DCE src code has been available for quite some time. The real problem was getting it to compile on anything but the reference platform AIX 3.2.

The problem with DCE is that it can't be used in pieces, you have to swallow the whole magilla and your whole infrastructure has to use it as well. That's the large reason it failed outside of markets that could accept and enforce those requirements.

It has a lot of nice features ( some of which actually work), but unless your network groks it, it's a dead end.

We attempted to deploy DCE (mostly to use DFS), but it was as huge failure as the servers were unstable. From my experience, the sites that have successfully used DCE all used AIX servers.

Good Luck to those involved, but after much harse experience I think DCE is like an open src COBOL compiler. If you need it you know you need it. If you don't know you need it then then there are better choices.

- Booker C. Bense

dce 1.22 has been available in source form since it was released [um... yes, two years sounds about right: maybe more].

however it's _not_ an open source license, it's a compile-it-and-try 'educational, non-distributing-in-binary-form' license. you have to pay $ for a binary distro-license.

dce 1.1 (runtime lib/env) is an OSF/1 reference implementation - an accepted BSD style license. but it's _only_ the runtime lib/env.

funny, i've heard people say that they could only get it to compile on _their_ platform (e.g. HP/UX) :) :) that's the 1.22.

dce 1.1 was originally ported to redhat 5.2 linux and named freedce. the main sticking point was the POSIX draft 4 thread emulation library (sigsetjump / siglongjmp) it was a horrible hack. it failed miserably under glibc 2.1. it failed miserably under gdb. i gave up.

_now_, freedce's dcethreads library works a charm (it got fixed).

we're investigating APRitising dcethreads, not least because dcethreads is GPL'd which is a pain because it makes the whole of freedce's OSF/1 BSD license totally irrelevant.

grr.

so, to answer your points in summary:

- dce 1.22 is not open source. it works on specific platforms.

- dce 1.1 is (was), it's OSF/1 BSD license. yes, it didn't work :)

- freedce is OSF/1 BSD, with GPL thread library for linux, which we're going to APRitise which will make the whole of freedce more portable (at least, that's the aim :)

- freedce is autoconf'd, dce 1.N is not.

regarding your other point about swallowing dce/rpc: yes, you're right. NT swallowed dce/rpc whole, well over ten years ago, with the result that it's now an accepted and integrated part of the infrastructure such that any people at microsoft reading this article are going to look bewildered and confused, wondering what all the fuss is about :)

i'd like to see freedce mature to the point where it gains that same level of bedrock stability and acceptance. once there are a few serious applications available (DCOM, Exchange, MSSQL, NT Domains for Unix), then i think that it'll get there.

it's a chicken and egg problem. if you don't have the infrastructure available, you don't have the infrastructure available.

remember: _this_ is the technology that is the interoperability bridge that eric raymond noted is so damn wide that i don't think even _he_ realised it's a yawning chasm, not a gap.

if you want to live in a polarised world forever, stay away from freedce.

if you ever want to help take away some of microsoft's monopoly and give _real_ people the chance to choose linux, help with freedce-related projects, with WIne, and others.

for those people interested: here's a reference to a commercial dce/rpc vendor who have been in the game for years: they even ported dce/rpc to DOS, and are planning a linux port that keeps moving around, presumably because gradient was recently acquired by gradient.

in particular, one quote stands out:

Gradient DCE is the most widely accepted, enterprise-wide solution for developing and deploying secure distributed applications. DCE is used by the largest companies in the world to implement mission-critical high-performance applications in the intranet.

in other words, there are some very high-level markets which the open source community is totally excluded because there is no dce/rpc environment available. i'd like to see that corrected.

Entegrity DCE

hi there, i just remembered:

the reference implementation to which you are referring has known bugs.

ironically, the Open Group's source code license requires that all licensees post back to them all bugfixes. they're not being integrated.

The Open Group's resources are being stretched to the point where they are trying to release all of the DCE 1.22 code under an Open Source License - they considered the LGPL to be the most appropriate.

unfortunately, this has fallen by the wayside because The Open Group's original charter, under which they were granted the rights to distribute dce/rpc, does not allow them to release under any other license, without the permission of the original contributors - HP, IBM, Hitachi, DEC/Compaq, etc.

so it's with the lawyers, now.

and in the meantime, we still have freedce to play with :) :)

See the subject, Luke.

hiya :) yes, i was tired too, at 2am when i was writing this up. but seriously, remember that advogato is a forum where not only the people on it read it: we're representing opinions of open source, here. and more seriously, with a few more words, what opinion are you trying to get across to people who read advogato, some of whom i will be referring here, with your brief message [that _is_ intended as a genuine question regarding the article, not as a criticism].

this, posted in rant-mode by david, came up in the dcerpc lists. it looked like a relevant bit of interesting opinion and history to me (but then, the things that keep _me_ awake at night might be different from those that keep you awake, Zaitcev *grin*)

DCE was put forward as part of the OSF lets get "Sun/AT&T" Unix war technology swap.

Although the NDR "reader correct" technology was originally from Apollo (Sun biggest enemy back in there in the early days) you have to remember that there technology had failed and Sun's had won.

NFS & NIS and ONC/RPC as on all Unix platforms and Apollo stuff was on no ones.

Hence when the Anti-Sun/AT&T alliance started HP/Apollo/DEC saw this an an opportunity to under cut Sun/AT&T with there own technologies hence they all agree to use each others. So now we have several RPC standards rather than an ONC Hegemony.

Truthfully that was a bad thing. As it held back RPC technologies for 5 years. Until DCE effectly won because MS started to use it. But because it was MS not Sun instead of have an open spec RPC system which was simple to roll your own, we had a closed and almost arcane RPC system. This reduce the numbers of available suppliers and hence like Monotype System companies would not pay to use the technologies and did without or wrote there own.

Hence IMHO the whole Unix War put back RPC technology implementations in the main stream by 10 years. And I as a developer of RPC system are P*ss *ff by it. :-(

follow-up on dcerpc mailing lists to the dave-rant, with more history-related info and corrections. i particularly love the politics, which dce/rpc's history is just so full of...

I understand the frustration, but the rant has a number of factual errors.

When the DCE RFT (request for technology) started, it was 1988/89, far from clear that ONC RPC won and NCA/NCS lost. For example, http://www.mit.edu/afs/athena/astaff/project/vcenter/henry/osf-rft/dce/evaluation-criteria.rno

When OSF asked for submission, Sun mailed a set of the ONC docs -- where were pretty crappy at the time -- and said "here you go, take it or leave it." They were completely unresponsive and unhelpful and had no interest.

It wasn't until the first DCE technology integration was well along that OSF realized how helpful it could be to "wire the submissions" to get vendor buy-in.

Disclaimer: I didn't join until a couple of years later, but one of the first OSF staffers involved in the DCE RFT is a good friend.

When Corba finally got serious about interop, the DCE sponsors were willing to completely give away DCE if they would use that as the RPC system. In a closed-room meeting Sun said "NDR over my dead body" and the IBM corba team caved in, to the embarassment of the other IBM distributed computing folks. (At least they were shame-faced when they spoke with us. :)

There's enough blame to go around for everyone.

But hey, at least now it's solved. Every RPC other than SOAP is just legacy.

someone has asked the question, "why bother?". i'm cc'ing the question and my response, here.

> just one question,
> > why should the unix world be interested in DCOM support?
>
> To be honest, several customers who are large in Windows development
> asked for DCOM. It might be a transition utility.

it's the same story with samba and windows file sharing, all over again.

people have an enormous amount of distaste for windows and for smb, however _that's the monopoly situation_ and you don't have to like it.

showing distaste, fro a linux developer viewpoint, which a number of people did by clapping at the last ukuug developer conference when the same question was asked that you have, but with Exchange not DCOM, is not actually that helpful, to unix.

i mean, linux developers and established unix users are quite happy not to use windows tools. i _hate_ word etc, and just yesterday asked someone to resend a 140k .doc file as text: i got less than 100 lines back!

but your (my) own confidence with unix doesn't help people who have to interoperate with the dev^H^H^Hother side.

plus, there's no opportunity to wean people away from the choices that they think they didn't have if there's no bridge between the two polarised worlds - a state of affairs that microsoft is counting on to lock more and more people into their monopoly.

long answer to a short question.

If Linux is truly getting 30% market penetration overall in Germany and other European spots, then the pressure to support all the same proprietary protocols and formats of the Windows world should be getting lower -- why bother with Exchange if other technologies do just as well?

As Windows alternatives gather steam (if they do at all) those alternatives will be freer to replace Windows proprietary protocols/formats with [hopefully open] alternatives because there will be fewer users demanding access to those closed Windows technologies.

Multi-platform apps will also help greatly if alternative platforms gain steam.

Until Linux and other *nix platforms gain steam DCE/RPC support is going to be somewhat necessary in order to complete with MS.

Someone quoted some rather spurious history from "Rich":

When Corba finally got serious about interop, the DCE sponsors were willing to completely give away DCE if they would use that as the RPC system. In a closed-room meeting Sun said "NDR over my dead body" and the IBM corba team caved in, to the embarassment of the other IBM distributed computing folks. (At least they were shame-faced when they spoke with us. :)

Odd. I was in a lot of those meetings. Which IBM team were you talking about? IBM had two teams, which didn't talk to each other very much. Two submissions to the CORBA interop table, and the DCE team wasn't very active at all. NDR basically didn't come up ... except that Sun did (as a political move to mollify DEC) agree to use CDR, which is more like NDR (but bicanonical not N-canonical) instead of XDR (canonical). That was quickly recognized by engineers (at many companies) as a compromise it'd have been better not to have made. Multiple canonical forms (even just two) make things that should be simple and fast become complex and slow ... just like real NDR.

The discussion I recall best was actually an open meeting, where people were getting really serious about whether to basically commit to DCE, as DEC (not IBM !!!) was advocating, in part as the proxy for Microsoft. The comment was from a large financial end-user:

We want a system that has low costs both for entry and for exit.

That sort of concern basically kills DCE, since it's got adoption costs measurable in years and multi-megabucks. It's what attracted Microsoft, and held DEC (and various large customers of OSF corporations) hostage. It's what makes open source be the last hope for DCE, since nobody voluntarily pays such costs any more.

There's plenty more I could say, but I'll leave for the moment with that observation about entry/exit costs.

it just recently occurred to me that the comparisons between CORBA and DCE/RPC are incorrect. CORBA is similar to DCOM, not DCE/RPC. CORBA and DCOM are c++ based, or more specifically, object-orientated methodologies sitting on top of RPC mechanisms.

[yes i know you can do DCOM in c or even pascal but it's a _complete_ pain].

CORBA has its own RPC mechanism, i presume, which i also presume must be non-object-orientated in nature. it is this RPC mechanism to which DCE/RPC may be compared.

thanks for the corrections and further insight. DCE/RPC is one of those many-facetted developments... :)

regarding development costs: the freedce project is available under a BSD-like OSF/1 license, so cost of development of DCE/RPC [with no security] is now zero.