Slashdot Mirror

Issue 8 of the ZeroC (creators of the Ice RPC protocol) linked to an active discussion in the rpc blogosphere on the legacy of CORBA, the fate of SOAP, and the age old problems of RPC:

* exhibit A: 11:40 Oct 3, 05: Mark Baker claims CORBA was a technical failure ( http://www.markbaker.ca/2002/09/Blog/2005/10/03#20 05-10-ws-corba )
* exhibit B: 15:38 Oct 3, 05: Steve Vinoski of Iona (leading CORBA vendor) begs to differ ( http://www.iona.com/blogs/vinoski/archives/000214. html ); a long discussion including Michi Henning from ZeroC ensues in the comments, including:

Even if I do define WSDL that is "loose" and makes lots of things optional, that typically doesn't help me. Loose coupling isn't of interest just for its own sake, but is of interest because people are looking for a way to solve the versioning problem: how can I evolve a distributed application over time without breaking everything that is deployed already, and without having to recompile and redeploy the universe? If I define WSDL that is "loose" to start with, so I get the loose coupling I so much need, by implication, I know in advance how the application will evolve: I put the "loose" bits in the WSDL definitions where I expect future variation in the data. But real life doesn't work that way. None of us is prescient and, as a rule, what makes the versioning problem so hard is that we *don't* know how an application will evolve in the future. In other words, people who say that I can solve the problem by writing "loose" WSDL are kidding themselves: the real world is not cooperative enough for this to work.

* Michi Henning

It's odd that CORBA should end up being sidelined by most of its original supporters, in favour of a supposedly simpler and cheaper system that ends up being frantically complicated (well over 100 related specifications, and counting) and far more expensive. But that's business for you!

* Tom Welsh

* exhibit C: 23:05 Oct 13, 05: Ted Neward discovers and enters the discussion ( http://blogs.tedneward.com/CommentView,guid,070274 e8-ccfd-4ebd-87b5-494564c39b77.aspx )

And here is another prediction: once people get over their current fixation with loose coupling, they will finally realize that, to get loose coupling, I don't need loose type systems that throw away compile-time type safety, and I don't need support at the protocol level at horrendous cost in performance. All I need is intelligent system design, a middleware that offers a workable implementation of multiple interfaces (check out Ice facets), and domain-specific standardization. With that, I get type safety, flexibility, and performance.

* Michi Henning

* exhibit D: 17:32 Oct 22, 05: Ken Horn comments on the issue ( http://kendes.blogspot.com/2005/10/loose-coupling- corba-vs-ws.html )

Links

* PEPt - An Architecture for Adaptable Remoting Systems ( http://haroldcarr.net/pept/ )
* YAML ( http://www.yaml.org/ )
* A Conversation with Roger Sessions and Terry Coatta ( http://www.acmqueue.com/m

And you forgot to mention that much of the J2EE standards and APIs have a grounding in CORBA, in fact I was just reading that JTS (Java Transaction Service) borrows much from OMG's Object Transaction Service, to name one example.

Too bad that with Web Services they are making the same mistakes all over again. Henning is a bit of a griper, surprised he didn't tout his zeroC CORBA-like app in the article, or maybe I missed it, for more interesting reading see Steve Vinoski's blog

Sign me another corporate hacker I guess. No fancy, glitzy buzzwordy smack for us, but hey, it gets the job done.

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.

You will probably need some toolkits. Basic things like multi-threading are generally non-portable.

For a GUI, FOX or wxWindows may help. For threads, you may want to consider JThreads/C++, especially if you intend to add a Java front-end to a client-server style system. Alternatively, there are packages like pth or various MPI products to fit the bill. The MPI products have slightly higher overhead/configuration, but open the door to Beowulf applications.

Since you have a functional Makefile system, I would recommend keeping it unless you get some big bang (e.g. current system is very badly written) by ditching it. You can help by using GNU's make instead of the platform's native make. This will remove the portability issues from Makefiles and adds "if then else" constructs to better handle portability. Remember that a Makefile is a set of AI inference rules and not a procedural language (though many try to use it as such).

One thing I learned a long time ago. Do the research first, then make the statement.

I'll provide only one example to refute the claim above. If you go to the XMLBUS site run by Iona Technologies, you'll find a rather nice set of tutorials about IONA's Web Services implementation on UNIX, and their toolsets for generating a SOAP gateway into Java classes or EJBs.

Not to put to fine a point on it, you can consume, and produce SOAP on any platform capable of communicating HTTP and parsing a bit of text.

It's only Moft FUD that suggests otherwise. So they can get a head start. So don't be defeatist.

TomV

You can find the website for MovieAction (the Unicef/Neeson project) here.

Yes cross platform C++ development is not there and few people are trying to make it work. I consider this a problem.

CORBA is neat. It is very cool and fun for writing distributed NETWORK applications. CORBA at this point is only well supported for C++. Several people do have C bindings, but all that I have played with are weak compared to the C++. If I wasn't distributing my processing across a network I might think again about why I need CORBA.

Perl is nice, for any application of any size be prepared to write your own interface. Consider tcl, doesn't do that much, but it embedds itself really nicely and doesn't have any licencing issues to worry about.

Java, is cross platform ready, has some CORBA support, but I believe you have to be careful what orbs you use or write your own interface.

I have worked on several projects that did UNIX/NT work. Both were with companies with a fair ammount of money.

One solution was purchase roguewave (which finally supports linux!) and Iona/Orbix. Roguewave provide very nice C++ libraries, and they are cross platform, among UNIXen and NT. I would love for someone to copy these to the open source world. Orbix is very feature rich, deploys on UNIX and NT (no Linux booo), though at times can be buggy, especially if you try to integrate security into your application. But iona does provide easy programming intrerfaces. End users saw web pages in this particular application. Used CORBA to wrap legacy applications and then quickly integrate them into new applications. Also I have seen nice CORBA implementations on Mainframe which is extremly nice, since talking to mainframes is generally a nightmare. but CORBA isn't very portable either and you have to commit to a specific CORBA.

The second project stuck with C, used plain old Socket Communication. Went with writing an object layer in house (simple but did the job) then writing a tool to create the .h and .c files out of the simple object language (simply impliment objects as structures, or multi-dimensional arrays) and just use a C compiler to get your binaries. This doesn't give you any performance hits compared to C++, and it makes your underlying application code very portable. Abstract out your database interfaces and don't wory about them untill you work with a new version. Build your own communication server that all applications register there messages with and recieve messages from (old style of programming, but it works) and use Inet Sockets. The end result is you can get applications that are n nodes clusterable and the platforms don't matter. The GUI a poor choice was done in this regard they went with Neuron Data (Now Blaze Soft, Formerly Elements, formerly OIT) which really is as slow as tcl/TK at run time without the portability. They now have a Java product that I haven't tried. Right now either TK or Java make the most sense for GUI's to me.

Having seen what happens when you go vendor bound, building code interfaces in house with extensability and portability in mind gives you the greatest flexability in the future.

so that is my thoughts about how to tackle cross platfrom distributed appliations.

If you're looking for a good introduction to CORBA concepts, check out this article by Steve Vinoski (here). It does a good job of explaining the "whys" of CORBA. Don't be intimidated by the "Advanced" in the title. The book goes into the basics of implementation, just not detailed coverage of why one would use CORBA.