Is CCM less trouble than it's worth?
phlip
Has anyone read the ACM Queue article "Rise and Fall of CORBA"?
Are its complaints about CCM useful?
--
Phlip
Gary Duzan
phlip <phli...@gEEEmail.com> wrote:
>Corbists:
>
>Has anyone read the ACM Queue article "Rise and Fall of CORBA"?
I've skimmed it now. The arguments are largely the same as ones
Michi has made here in the past.
>Are its complaints about CCM useful?
I suppose it depends on how you care to use them.
From my own experience, CCM as written is certainly more complex
than is desirable. Some things seem overspecified to the point
where it is hard to wrap your brain around it, while others seem
underspecified to the point where you have to work outside of the
CCM model to get anything useful done. The move to D&C might make
things more conceptually pure, but it added a lot of complexity
and lost some functionality in the process. With a really good set
of tools wrapped around it, I'm sure it would be usable, but then
I'd still have to wonder about the utility of having a standard if
it is all hidden by proprietary tools.
On the other hand, I really like some of the more basic ideas:
Specify both incoming and outgoing interfaces.
Specify an implementation description.
Specify how to instantiate and configure instances.
The first is useful for decomposing a system into understandable
parts. The second is an enabler for the third, and something of a
necessary evil. The third lets you build a system from the constituent
parts in a well defined way. I think CCM's primary sin was multiplying
the entities used to implement these ideas beyond necessity,
resulting in an overcomplicated mess.
Gary Duzan
Motorola CHS
phlip
>>Has anyone read the ACM Queue article "Rise and Fall of CORBA"?
>
> I've skimmed it now. The arguments are largely the same as ones
> Michi has made here in the past.
Ouch. Sorry guys - I know what that does to a newsgroup!
>>Are its complaints about CCM useful?
>
> I suppose it depends on how you care to use them.
>
> From my own experience, CCM as written is certainly more complex
> than is desirable. Some things seem overspecified to the point where it is
> hard to wrap your brain around it, while others seem underspecified to the
> point where you have to work outside of the CCM model to get anything
> useful done. The move to D&C might make things more conceptually pure, but
> it added a lot of complexity and lost some functionality in the process.
> With a really good set of tools wrapped around it, I'm sure it would be
> usable, but then I'd still have to wonder about the utility of having a
> standard if it is all hidden by proprietary tools.
I am currently writing a Mock DAnCE, to make certain we can unit-test our
objects, low-level, without pumping them into the real DAnCE and setting
up bogus end-to-end tests. So I think I took care of the one complaint my
colleague read out to me - that the deployment system is too complex.
> On the other hand, I really like some of the more basic ideas:
>
> Specify both incoming and outgoing interfaces. Specify an implementation
> description. Specify how to instantiate and configure instances.
>
> The first is useful for decomposing a system into understandable parts.
> The second is an enabler for the third, and something of a necessary evil.
> The third lets you build a system from the constituent parts in a well
> defined way. I think CCM's primary sin was multiplying the entities used
> to implement these ideas beyond necessity, resulting in an overcomplicated
> mess.
There are those who call that "big requirements up front". ;-)
--
Phlip
Michi Henning
> Gary Duzan wrote:
>
>
>>>Has anyone read the ACM Queue article "Rise and Fall of CORBA"?
>>
>> I've skimmed it now. The arguments are largely the same as ones
>>Michi has made here in the past.
>
>
> Ouch. Sorry guys - I know what that does to a newsgroup!
Yep :-) The article really isn't about CORBA so much as about
the failings of software consortiums and design by committee.
CORBA is merely one victim of these failings, and WS seems to
be another one.
BTW, the article is available on line at
http://www.zeroc.com/riseAndFallOfCorba.html
>> From my own experience, CCM as written is certainly more complex
>>than is desirable. Some things seem overspecified to the point where it is
>>hard to wrap your brain around it, while others seem underspecified to the
>>point where you have to work outside of the CCM model to get anything
>>useful done.
I agree. This is a prime indicator for a standard that is not based
on actual experience: some things are unreasonably hard to use, and other
things are missing or badly underspecified. A standard based on
existing best practice does not suffer such problems. (For an example, look
at the solidity of the Single UNIX Specification. That specification wasn't
written until after we had accumulated a lot of experience with the technology.)
>> On the other hand, I really like some of the more basic ideas:
>>
>> Specify both incoming and outgoing interfaces. Specify an implementation
>> description. Specify how to instantiate and configure instances.
There were good (if not new) ideas in CCM. The concept was fine, but
its execution wasn't.
The biggest problem is that standards with major flaws abuse thousands of
customers as guinea pigs. This is not only ethically questionable, but also
severely discredits our industry. (And, certainly, the OMG is not the only
black sheep in the pen...)
Cheers,
Michi.
Phlip
> Yep :-) The article really isn't about CORBA so much as about
> the failings of software consortiums and design by committee.
Ooh, he knows what to say to me!
Now why does Ruby come with a Win32 OLE binding, out-of-the-box, but no
simple Corba binding?
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
lakshm...@gmail.com
http://www.zeroc.com/riseAndFallOfCorba.html
/*
Over the span of a few years, CORBA moved from being a successful
middleware that was hailed as the Internet's next-generation e-commerce
infrastructure to being an obscure niche technology that is all but
forgotten. This rapid decline is surprising. How can a technology that
was produced by the world's largest software consortium fall from grace
so quickly? Many of the reasons are technical: poor architecture,
complex APIs, and lack of essential features all contributed to CORBA's
downfall. However, such technical shortcomings are a symptom rather
than a cause. Ultimately, CORBA failed because its standardization
process virtually guarantees poor technical quality. Seeing that other
standards consortia use a process that is very similar, this does not
bode well for the viability of other technologies produced in this
fashion.
*/
How even after so much of technical shortcomings and performance
bottleneck of CORBA OMG can claim this?
CORBA still delivering available at:
http://www.omg.org/docs/omg/06-04-01.pdf
Who is right? Just wondering....
regards,
Lakshmi
Douglas C. Schmidt
>Quoting from
>http://www.zeroc.com/riseAndFallOfCorba.html
>
>/*
>Over the span of a few years, CORBA moved from being a successful
>middleware that was hailed as the Internet's next-generation e-commerce
>infrastructure to being an obscure niche technology that is all but
>forgotten. This rapid decline is surprising. How can a technology that
>was produced by the world's largest software consortium fall from grace
>so quickly? Many of the reasons are technical: poor architecture,
>complex APIs, and lack of essential features all contributed to CORBA's
>downfall. However, such technical shortcomings are a symptom rather
>than a cause. Ultimately, CORBA failed because its standardization
>process virtually guarantees poor technical quality. Seeing that other
>standards consortia use a process that is very similar, this does not
>bode well for the viability of other technologies produced in this
>fashion.
>*/
>
>How even after so much of technical shortcomings and performance
>bottleneck of CORBA OMG can claim this?
>
>CORBA still delivering available at:
>
>http://www.omg.org/docs/omg/06-04-01.pdf
>
>Who is right? Just wondering....
Michi's right that the OMG standardization process leaves many things
to be desired. He's also right that many other standardization
processes leave many things to be desired, as well. In general,
standards organization work best when they standardized
well-established technologies. To the extent they try to "innovate"
without the benefit of solid, time-proven patterns and working
prototypes to guide them, their specs tend to be much less successful.
The OMG is also right, however. CORBA is very widely used and the
core parts of the spec (i.e., the parts that are based on solid,
time-proven patterns and working prototypes) are quite good, as
evidenced by many high-quality interoperable CORBA ORB
implementations. A remarkable number of real-world, mission-critical
systems use CORBA. For a colorful (literally) discussion of some of
them in some surprising domains (ie., non-defense and telecom, which
are the "bread and butter" of CORBA) check out
http://www.omg.org/cgi-bin/doc?omg/2006-04-01
Not surprisingly, I disagree with some of Michi's points and his
conclusions. These issues have been debated ad nauseum on
comp.object.corba for years, so I recommend you do a google search and
read the debates for yourself and make your own assessment. Rather
than rehashing these debates here, however, I'll give a quick summary
of where I see CORBA's main focus and value-added payoff these days.
(this is my view and is based on the work I do, so other CORBA
vendors/users may want to add their $0.02):
. Distributed real-time and embedded systems, e.g., telecom/datacomm,
aerospace, defense, control systems, industrial automation, online
financial services, gaming and multimedia, robotics, automotive
systems, etc. Please see
http://www.dre.vanderbilt.edu/users.html
http://www.ois.com/corporate/corp-2-1.asp
http://www.prismtechnologies.com/section-item.asp?sid4=&sid3=&sid2=22&sid=23&id=97
for lots of examples of CORBA usage in these domains. Some of the top
ORBs here include
. ORBexpress <http://www.ois.com>
. e*ORB <http://www.prismtechnologies.com> and
. TAO <http://www.dre.vanderbilt.edu/TAO>
which are widely used ORBs in these domains.
. General-purpose client/server and distributed computing applications
that simply need a low-/zero-cost object-oriented interprocess
communication mechanism. It appears that the open-source versions of
CORBA are widely used in this domain. In particular,
. JacORB <http://www.jacorb.org>
. TAO <http://www.dre.vanderbilt.edu/TAO>
. omniORB <http://omniorb.sourceforge.net/> and
. MICO <http://www.mico.org>
are widely used ORB for these types of general-purpose applications.
In the future, I see CORBA increasingly used in the distributed
real-time and embedded systems domain, where many companies need
1. Low-/zero-cost solutions that are based on standards
2. Have very mature/robust implementations and
3. Have excellent support for stringent quality of service properties.
In support of these characteristics, I see CORBA evolving in the
following ways:
. More standardized support for subsetting the CORBA specification to
meet the resource constraints of distributed real-time and embedded
systems. Please see
http://www.omg.org/news/releases/pr2006/06-05-06.htm
for more information on the CORBA/e specification, which was
recently adopted. There are a number of CORBA/e-compliant products
available now, with others on the way shortly.
. More standardized support for combined fault-tolerant (FT) and
real-time (RT) quality of service properties. There are activities
working their way through the OMG right now that will hopefully
yield a powerful, yet lightweight, FT/RT infrastructure.
. Integration of quality of service support with advanced component
technologies, as part of the Lightweight CORBA Component Model (CCM)
specification and its related specifications. Please see
http://ditec.um.es/~dsevilla/ccm/
for lots of information on Lightweight CCM et al. and
http://www.dre.vanderbilt.edu/~schmidt/OMG-CCM-Tutorial.ppt
for a tutorial on Lightweight CCM.
. Integration of CORBA and Lightweight CCM Service-Oriented Architecture
(SOA) platforms with the pub/sub services provided by the OMG Data
Distribution Service (DDS). There's a nice summary of DDS at
http://en.wikipedia.org/wiki/Data_Distribution_Service
and a tutorial on DDS is available at
http://www.dre.vanderbilt.edu/~schmidt/DDS.ppt
. Increased use of model-driven engineering methods and tools to help
simplify key aspects of middleware development and application,
including deployment, configuration, and quality assurance. There's a
lots of material available at
http://www.dre.vanderbilt.edu/cosmic
that summarizes some of the work on these topics. There are also
tutorials at
http://www.dre.vanderbilt.edu/~schmidt/OOP/oop-mdd-session.ppt
http://www.dre.vanderbilt.edu/~schmidt/OOP/oop-mdd-tutorial.ppt
that covers these topics, as well.
BTW, many of the topics I described above will be presented at the
upcoming OMG Real-Time and Embedded Systems Workshop
<http://www.omg.org/news/meetings/realtime2006/index.htm>, which will
be held July 10-14th 2006 in Washington DC. Please see
http://www.omg.org/news/meetings/realtime2006/Program.pdf
for the program of that conference for an overview of the current state
of CORBA and where it's headed in the future.
Finally, please see
http://se-radio.net/index.php?post_id=3D51700
for a Podcast interview I did several months ago that gives my broader
thoughts on future middleware and model-driven technologies.
If you have any questions, please let me know.
Thanks very much,
Doug
--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Institute for Software Integrated Systems FAX: (615) 343-7440
Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203 NET: d.sc...@vanderbilt.edu
spen...@ociweb.com
Hi Lakshmi, Doug Schmidt does good technical defence of CORBA in
response to your email.
More fundemantally we support the open source ORBs TAO and JacORB. We
are finding there are open source options that also factor in here.
Many of the complaints, about specs. from stds groups being
impractical, can be mitigated by clients taking the best of the spec.
and extending the open source implementations to satisfy their specific
needs, driven by actual use cases and real life situations.
The result is very pragmatic, free, community based implementations
that follow the philosophies and guidelines of stds. but also solve
very real problems.
CORBA is still the best cross platform, multi language, vendor neutral
distributed model and is attacking areas of the IT envelope that the
others still ignore. Real time is no longer a niche techniology. Now
called QoS it is becoming integral to many new systems.
Paraphrasing the words of the US civil war general, about why he won
battles. CORBA will be the firstest with the mostest in this arena and
is the reason our clients give us when their new projects adopt it.
regards Malcolm Spence
Director of Business Development
OCI St. Louis MO
TEL 1-314-579-0066 ext 206
FAX 1-314-579-0065
Phlip
> . Distributed real-time and embedded systems, e.g., telecom/datacomm,
> aerospace, defense, control systems, industrial automation, online
> financial services, gaming and multimedia, robotics, automotive systems,
> etc.
...
> In the future, I see CORBA increasingly used in the distributed real-time
> and embedded systems domain, where many companies need
>
> 1. Low-/zero-cost solutions that are based on standards
I respect the scope of Douglas's post, yet am compelled to report a
serious lack of warm-fuzzies for some very important details.
I need to guess that our expensive investment, so far of >100
engineer-hours building and integrating such a huge and intricate
code-base, will eventually return to us in the form of some kind of
distributed computing solution. Hearing about huge companies with endless
resources using CCM does not appease the spectacular distance between
glowing PDFs and our own feeble experience, so far.
> 2. Have very mature/robust implementations and
The obvious problem here is common to all Free Software. It doesn't come
with a hive of drones, mindlessly productizing everything for us. So we
must accomplish all productization ourselves.
Next, to implement the system using Test-First, I must constantly abuse
its internals. I have far too many crashes and dislocations to report in
endless PRFs. Here's just a trivial example:
Our test suite has a method OrbSuite::setUp(), which constructs the ORB
and some CIAO services. It runs before every test case, and an
OrbSuite::tearDown() runs after each one. So here's a sample test case:
TEST_(OrbSuite, loadSenderObject)
{
{
Container_Impl anImpl(orb, root_poa.in(), nodeapp_obj.in());
anImpl.init(NULL);
Session_Container aContainer(orb, &anImpl);
Components::CCMObject_var compSender = createSender(aContainer);
char const * id = compSender->_interface_repository_id();
CHECK_EQUAL(string("IDL:Hello/Sender:1.0"), id);
FacetDescriptionsPointer p(compSender->get_all_facets());
CHECK_EQUAL(1, p->length());
::Components::FacetDescription & desc = *(*p)[0];
CHECK_EQUAL("push_message", string(desc.name()));
}
if (orb) orb->destroy();
}
Note the orb->destroy() line is inside the test case, and outside the
scope of its local objects. They destroy first. But I can't move the
orb->destroy() line to the tearDown() method, where it belongs, even
though the destructor sequence would be exactly the same. The system
undiagnosably crashes (on a double-delete or something).
Don't request a PRF. That is just one example of endless minor glitches
and learning experiences. Everything from MACRO_MADNESS at build time to
CIDCL demanding the wrong flavor of Boost at link time, to orbsrvcs that
alternately fail and work at run-time.
> 3. Have excellent support for stringent quality of service properties.
That is indeed the plasma signature attracting us to the end of this
wormhole...
--
Phlip
Shashank D. Jha
You have more than impressive list of software systems based on CORBA
(TAO) :-).
spen...@ociweb.com wrote:
> CORBA is still the best cross platform, multi language, vendor neutral
> distributed model and is attacking areas of the IT envelope that the
> others still ignore. Real time is no longer a niche techniology. Now
> called QoS it is becoming integral to many new systems.
We believe the same.
With CCM now, it really makes specifying design, development and
deployment of complex systems easier. As it has really simplified
programming, assembly and deployment model for the users.
The abstraction of component (with ports) I believe is one of the most
powerful feature of CCM. Together with D&C spec. it does allow
distribution and deployment of complex scenarios in a well defined
manner.
---------------
Shashank D. Jha
iCMG
e-mail shas...@icmgworld.com
Douglas C. Schmidt
> I need to guess that our expensive investment, so far of >100
> engineer-hours building and integrating such a huge and intricate
> code-base, will eventually return to us in the form of some kind of
> distributed computing solution. Hearing about huge companies with endless
> resources using CCM does not appease the spectacular distance between
> glowing PDFs and our own feeble experience, so far.
There are several things to note here:
. I was talking primarily about CORBA and CORBA ORBs in my post, which
are very robust.
. You are talking primarily about your experience with CIAO/CCM, which
is is not yet as robust as TAO/CORBA - hence the 0.5.1 beta version
number..
. You are also trying to do rather odd things with CIAO/CCM, e.g.,
"Mock DAnCE", which is not at *all* how people typically use this
stuff.
>> 2. Have very mature/robust implementations and
>
> The obvious problem here is common to all Free Software. It doesn't come
> with a hive of drones, mindlessly productizing everything for us. So we
> must accomplish all productization ourselves.
As above, there are several things to note here:
. I was speaking about the CORBA marketplace in general, some of which
is open-source, some of which is non-open-source. There are quite a
few (i.e., ~8-10) mature/robust implementations of CORBA, both
open-source and non-open-source.
. As usual, you get what you pay for, i.e., if you decide to do things
yourself in a non-standard way vs. avail yourself of the mainstream
approaches and/or commercial companies then you'll have more work to
do. In particular, if you find yourself spending hundreds of hours
trying to do something internally it's probably a good indication
that hiring external consultants to help out would save you lots of
time, $$$, and frustration.
Well, you are choosing to do a bunch of very non-standard things,
using software that's still in its beta-stage, and to do it in-house
without investing the resources to sponsor companies who know how to
make this stuff stuff work. It's therefore not surprising that you're
having problems. Fortunately, there are many users of these
technologies who choose a different process and have more successful
experiences!
In sum, there's nothing "magic" about open-source, i.e., it works
because users work with the developers to improve the technology over
time, and because communities of users/developers become committed to
making things better. If this sort of a process isn't your cup of
tea, then by all means move to a different community/technology.
Thanks,
Phlip
> . You are also trying to do rather odd things with CIAO/CCM, e.g.,
> "Mock DAnCE", which is not at *all* how people typically use this stuff.
Okay. Ask a whole new question, from scratch:
. how to use pure Test Driven Development on CCM?
I want a test case like this (please do not comment on the terminology):
TEST_(OrbSuite, fooToBar)
{
Component aComp = createComponent("myComponent");
Component bComp = createComponent("otherComponent");
aComp.connectPort("linkie", bComp);
aComp.invoke("foo", 42); // <-- call method by name
int got = bComp.invoke("bar");
CHECK_EQUAL(42, got);
}
(createComponent() creates the container, home, and component within, then
returns a handle to the component.)
This situation is the basis for test-first, because I can write new test
cases that request new behaviors, and fail. Then I upgrade the components
to pass them. Then we deploy the components with the standard deployment
plan system, without wondering if they will work.
Does anyone know of any project using test-first for CIAO?
(The examples and tests in the project that I inspected are end-to-end
integration tests, not unit tests.)
--
Phlip
Gary Duzan
Phlip <phli...@gEEEmail.com> wrote:
>Douglas C. Schmidt wrote:
>
>> . You are also trying to do rather odd things with CIAO/CCM, e.g.,
>> "Mock DAnCE", which is not at *all* how people typically use this stuff.
>
>Okay. Ask a whole new question, from scratch:
>
> . how to use pure Test Driven Development on CCM?
Presumably you are supposed to write code which creates XML
files containing your test configuration and invoke the CCM tools
to put everything together. Not the most fun task, especially with
the D&C XML, but it should be doable. Mind you, if your CCM
implementation has support for particular XML-generation tools,
you may have trouble getting support for XML you generate yourself,
since the deployment tools likely only will have been tested against
the XML generated by their tools.
>I want a test case like this (please do not comment on the terminology):
>
> TEST_(OrbSuite, fooToBar)
> {
> Component aComp = createComponent("myComponent");
> Component bComp = createComponent("otherComponent");
> aComp.connectPort("linkie", bComp);
> aComp.invoke("foo", 42); // <-- call method by name
> int got = bComp.invoke("bar");
> CHECK_EQUAL(42, got);
> }
>
>(createComponent() creates the container, home, and component within, then
>returns a handle to the component.)
There appears to be a halfhearted attempt at supporting this sort
of thing in the spec, but it seems incomplete, some implementations
don't support those parts, and you still have to construct XML to
pass to some of the interfaces. The interfaces just don't seem very
CORBA-like. I imagine they are more EJB-like, from what I've heard,
but I haven't really worked with EJBs.
Gary Duzan
Motorola CHS
Phlip
> There appears to be a halfhearted attempt at supporting this sort
> of thing in the spec, but it seems incomplete, some implementations don't
> support those parts, and you still have to construct XML to pass to some
> of the interfaces. The interfaces just don't seem very CORBA-like. I
> imagine they are more EJB-like, from what I've heard, but I haven't really
> worked with EJBs.
Thanks. I want everything to work out of one button, including launching
whatever services are needed. I want as much as possible in the same
process, so the debugger can hit breakpoints on it. And I want it all to
report correctly when it goes down.
The "halfhearted attempt" would appear to be an attempt to use more CCM to
solve problems with CCM. I am, instead, targeting the non-standard C++
objects inside DAnCE. They nearly always work correctly, but when they
don't, they typically crash on Linux, with worse debugger support than
Win32.
And all because I'm afflicted with this sad notion that prevention is
better than a cure...
--
Phlip