Slashdot Mirror

Utlimately, your take on mapping's place in middleware comes down to whether you accept the assertion - as I do - that enterprise computing systems tend toward diversity and heterogeneity. Those who understand and accept this assertion readily accept the need for mappings and the limitations they present. Those who continually strive to homogenize their computing systems, on the other hand, are essentially fighting a losing battle because they're swimming upstream against ever-advancing technology and ever changing business requirements. Change is, of course inevitable. Part of planning for change means making your middleware applications as loosely coupled and flexible as possible, and good mappings play an important part in achieving those goals.

Now, it might be fine for quickly whacking out a way to connect your favorite scripting language to C++, but for a commercial, production application I would go with a more proven, standardized solution such as CORBA. There are many excellent open source implementations (another good reason for using a standardized spec), such as omniorb.

Apparently freedesktop.org has devolved from a desktop standards initiative to a home of pointless wheel-reinvention. Here's a list of the projects listed above, followed by their existing, more mature counterparts:

Init Replacements: simpleinit, minit, jinit, runit, daemontools, serel. Progeny also has their own system based on Gooch's need/provide architecture.

D-BUS: CORBA

HAL: Discover

Why reinvent communication libs when we have CORBA?

Simply because Open Source projects do not use it does not make CORBA a failure. This is the same as saying Java/COM/iMacs/Oracle databases etc. are failures because you haven't seen an Open Source project that uses them.

There are a large number of closed source, large scale (millions of lines of code) products that use CORBA that the average sysadmin/linux hacker/whatever will never see or get to use. As an example, the company I worked at this summer (i2 technologies ITWO) has a been generating millions of dollars in revenue with a CORBA based Supply Chain Management application for the past couple of years.

You see Corba is broken. but only a little. In order to use it you must build something else on top that actually talks to your apps.

Isn't that what the CORBA Component Model was designed to fix?

PS: I am a distributed computing junkie and am currently doing research into RMI/CORBA/DCOM and have found a bunch of interesting articles that break down these technologies for people who are wondering what exactly they are...here's an article that compares all three.


(-1 Troll)

Do you realize that GNOME itself is the 1st successful software project based on Corba ?

This is simple NOT true. There are lots of software projects using CORBA, mostly closed source of course. GNOME might be the largest OPEN SOURCE software project using CORBA to date but AFAIK Bonobo still has to proove itself.

See http://www.corba.org/success.htm for some success stories.

You might want to look at CORBA which is the open standard equivalent of COM(+). The newer versions have stuff about services in. Remember it's only a standard though, so finding a suitable implementation for you is where the real problem lies.

How about real standards like CORBA, OpenGL and PHP or PERL. What comes to sound OpenAL is very promising.
_________________________

What you describe has already existed for some time now. It is called CORBA.