Prev: Design by Contract vs Law of Demeter : Preconditions
Next: New England Patriot jerseys for men,worldwide express, paypal payment
From: Phlip on 24 Aug 2007 03:35 Michi Henning wrote: > I tend to agree. It's death by a thousand wounds. All the little bits > that are wrong in minor ways (and sometimes major ways) add up to a > considerable amount of pain. I believe that, had this pain not been > experienced by users, the current SOA/WS/SOAP/XML craze would never > have happened. Talk about jumping from the frying pan into the fire... Why is the cost of any of them justified? What am I missing here? This is the Ruby dRB call to make an object available on a server: DRb.start_service("druby://server:7777", SongNameServer.new("/tmp/songname")) The innards of SongNameServer is just a standard Ruby object. Here's the call to connect from a client to that object: DRb.start_service ro = DRbObject.new(nil, 'druby://server:2001') And 'ro.songname' will call one of the object's methods. What does CORBA purport to have that this lite rig doesn't have? And would do we need to write the billions of lines of CORBA (or SOAP or whatever) required just to say "hello world" across a wire? -- Phlip http://www.oreilly.com/catalog/9780596510657/
From: kjin101 on 24 Aug 2007 12:52 Phlip wrote: > Michi Henning wrote: > > > I tend to agree. It's death by a thousand wounds. All the little bits > > that are wrong in minor ways (and sometimes major ways) add up to a > > considerable amount of pain. I believe that, had this pain not been > > experienced by users, the current SOA/WS/SOAP/XML craze would never > > have happened. Talk about jumping from the frying pan into the fire... > > Why is the cost of any of them justified? What am I missing here? > > This is the Ruby dRB call to make an object available on a server: > > DRb.start_service("druby://server:7777", > SongNameServer.new("/tmp/songname")) > > The innards of SongNameServer is just a standard Ruby object. > > Here's the call to connect from a client to that object: > > DRb.start_service > ro = DRbObject.new(nil, 'druby://server:2001') > > And 'ro.songname' will call one of the object's methods. > > What does CORBA purport to have that this lite rig doesn't have? And would > do we need to write the billions of lines of CORBA (or SOAP or whatever) > required just to say "hello world" across a wire? > 1. For a simple hello world application, a CORBA server doesn't require user to write billions of lines of code. if you talk about CORBA ORB's code, then you can ask the similar question of: "Why we need billions of lines of code of linux/unix or windows just to display hello world on a screen?". The billions lines (I guess more than 99% of your billions LoC ORB code are blank and/or code comments) of ORB code are for things like worker thread management, optimized concurrent request dispatching, various local IPC mechanisms (e.g. unix-domain socket, shared memory or memory mapping file, solaris door, etc. etc.) or co-host optization, memory/object pooling, connection management, request intercepting callback, request context handling, objects to implementations resolvations (mapping to different server policies and scenarios), instead of a primitive, coarse-grained server that use one-shoe-fit-all default scenario to handle a "hello world" request from remote clients. 2. your example discuss about the deployment model of a server application. That is exactly what I mentioned yesterday, namely CORBA fails to define a straightforward and effective server deployment model. if it did and did it at the right time, then history could be different .... Regards, Ke > -- > Phlip > http://www.oreilly.com/catalog/9780596510657/
From: Rob Ratcliff on 25 Aug 2007 11:59 I guess it is good to see that there is no lack of hyperbolic opinions and extreme dogma in our industry! :-) Dumping rather than incrementally improving working solutions seems to be common place and perhaps even encouraged to spur on new business opportunities. It'd be nice to see continual progress such as you might see in other hard engineering industries (I came from the aerospace industry) rather than all of this sideways and even backwards movement and churn. I've been developing with CORBA in various languages for 7 years now and I fail to see it as "horrific" failure. It performs great, isn't that hard to use (especially for the typical RPC or event-driven application), provides lots of mature verticals and with all the interoperable open source implementations offers a lot of choice. Of course there are things that I would like to see improved like: modern language bindings based on current best practices, making bi-directional comms the norm, support for simple versioning, friendly reflective-type parsers to better handle additions to data structures without recompiling, friendlier error messages, IDL with annotations and such, but those are all things that could be incrementally improved rather than dumping the solution completely. I was happy to see that some of the current OMG members are pushing for improvements to the Java and C++ language bindings. I think there is still lots of future potential for CORBA, especially if people remain flexible and plan for success! JMHO, Rob kjin101(a)gmail.com wrote: > ap...(a)student.open.ac.uk wrote: >> On 18 Aug, 03:37, "Phlip" <phlip...(a)yahoo.com> wrote: >>> CORBA's main problem is it grew under a broken "request for proposals" >>> model. The stakeholding committees chartered their proposal system to >>> discourage and inhibit reference implementations for new feature requests. >>> This simple but horrific mistake allowed client companies to compete with >>> each other by submitting elaborate requests, allowing the CORBA >>> specification to clutter up with endless cruft. >>> I predict that CORBA as we know it will not last another few years, and that >>> something else will take its spot. Maybe a simplified version of the >>> ACE-TAO-CIAO framework(s). >> I agree that CORBA is the worst example of committee-itus that the >> world has ever seen. The C++ language binding is horrific and IMO will >> never ever be fixed. But the binding for java is ok and I think CORBA >> works quite well with java. Also despite the poor language bindings in >> other languages the fact that there are other language binding makes >> CORBA a good way to interface to legacy systems (with java on the >> frontend of course). IMO. So I think its got a good for several years >> yet. > > The C++ binding is out-of-date but not that horrific and is an > insignificant reason in CORBA's failure (or fall). Even if CORBA had a > perfect C++ binding, it would still as miserable as it today. The > major technique problem of CORBA is not its some how out-of-date > language mappings, not the data aligment in CDR encoding, not the > unnatural OBV, the chatty OTS, the braindead AMI, FT, etc. etc., but > the lack of a simple, light while still superb component assembly, > deployment and configure model/framework that canceals complexities in > building CORBA server, and/or publish/subscribe (either event/ > notification or data distributation), secured, and/or transactional > (as well as persistent, fault tolerant, etc.) applications. \
From: Phlip on 25 Aug 2007 12:05 Rob Ratcliff wrote: > I was happy to see that some of the current OMG members are pushing for > improvements to the Java and C++ language bindings. I think there is > still lots of future potential for CORBA, especially if people remain > flexible and plan for success! I sure wish I could flame three whole newsgroups so subtly and devastatingly! (-; -- Phlip http://www.oreilly.com/catalog/9780596510657/ "Test Driven Ajax (on Rails)" assert_xpath, assert_javascript, & assert_ajax
From: JPWoodruff on 2 Sep 2007 18:49
On Aug 17, 4:30 pm, philip_b_tay...(a)yahoo.co.uk wrote: <... all context elided ...> I would direct your attention to the International Conference on Accelerator and Large Experimental Physics Control Systems. ICALEPCS is a biennial series of conferences where large distributed real time systems are discussed. Some ongoing projects give progress reports per two years. CORBA is well represented in these systems -- at least the "new" ones (the ones that were new 5 years or so ago). I worked on one of them - the National Ignition Facility laser - at the end of my work, then retired in 2002. You can read reports of the software framework used there in both ICALPECS and SigAda publications. > > There has certainly been no marketing hype anywhere I for one thought your reasoning made sense so far. John - sorry for long latency. I wasn't paying attention..... |