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:
The innards of SongNameServer is just a standard Ruby object.
Here's the call to connect from a client to that object:
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?
From: kjin101 on 24 Aug 2007 12:52
> 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:
> The innards of SongNameServer is just a standard Ruby object.
> Here's the call to connect from a client to that object:
> 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
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!
> 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
> 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
"Test Driven Ajax (on Rails)"
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
> There has certainly been no marketing hype anywhere
I for one thought your reasoning made sense so far.
- sorry for long latency. I wasn't paying attention.....