CORBA, CORBA, CORBA

CORBA, CORBA, CORBA

Post by Dan O'Brie » Fri, 24 Mar 2000 04:00:00



We are presently using a CORBA product by a major vendor in
a high performance, multi-threaded, interactive provisioning
application.

Users connect to the application via web browser technology using
web server side Java Server Pages and Java Servlets that connect
using CORBA to the application platform which itself is composed
of ~50 CORBA servers.  

These servers themselves interact for various functionality, plus
interact with a database for persistent.

We are finding that as we scale up the number of users, this vendors
CORBA starts running into deadlocks and other blocking issues where
the server becomes crusted over and quits functioning.

We are working with the vendor to provide a solution, but we are finding
ourselves less confident in this particular ORB and are looking to
make a change.

We presently use many proprietary extensions of this particular vendor's
ORB and are looking at ways to move our application platform away from the
proprietary extensions to using only (mostly) OMG CORBA 2.3 POA interfaces.
(Even the vendor of our current ORB is even pointing us to their follow on
product that implements OMG CORBA 2.3 using POA technology.)

So we are at a cross roads.

Are the problems we are seeing as we scale up a limitation of the CORBA
architecture we have chosen?  A limitation of CORBA itself?

Are there ORBs known for their scalabilty, performance,
multi-threaded safeness?  Is there some kind of comparison chart?

Can we practically achieve vendor independence using POA interfaces and
wrapping vendor-isms appropriately?

Given the effort to pry fixes out of our current vendor, I'm suggesting the use
of open source CORBAs like TAO, etc, but my management is concerned with having
"someone" to beat on when it breaks.  

Are there CORBA vendors that are known for providing sterling support?  

Can using the open source model for CORBA really work for production level
applications?   Using TAO for example, are their millions of net-heads using it,
testing it, fixing bugs, providing patches?  Or are we really on our own
and need to invest staff to support it ourselves?

Any and all comments are welcome.  

Cheers,


Work: 614-860-2392  Page: 614-520-5001
Cell: 614-783-4859  Home: 740-927-2178
----------------------------------------

 
 
 

CORBA, CORBA, CORBA

Post by Martin v.Loew » Fri, 24 Mar 2000 04:00:00




Quote:>We are finding that as we scale up the number of users, this vendors
>CORBA starts running into deadlocks and other blocking issues where
>the server becomes crusted over and quits functioning.

That smells a lot like the "nested calls problem". When a CORBA application,
as a client, makes a call, some implementations won't accept incoming
calls to that application (which would then act as a server), as long as
the original request is not complete. As a special case, truly nested
calls result in a deadlock in such an ORB.

You'll find a lot of discussion of this problem in this group; the two known
solutions are multithreading and the "reactive" model. Either has certain
limitations: In multithreading, you may run out of threads; in the reactive
model, the stack may overflow.

Quote:>Are the problems we are seeing as we scale up a limitation of the CORBA
>architecture we have chosen?  A limitation of CORBA itself?

It looks like a limitation of the particular implementation to me.

Quote:>Are there ORBs known for their scalabilty, performance,
>multi-threaded safeness?  Is there some kind of comparison chart?

These are hard-to-measure qualities, so you won't find such a table
easily. OTOH, support for nested calls can be determined objectively;
when you select a product, make sure they guarantee that function.

Quote:>Can we practically achieve vendor independence using POA interfaces and
>wrapping vendor-isms appropriately?

I think this particular aspect is still a quality-of-implementation issue.

Quote:>Given the effort to pry fixes out of our current vendor, I'm suggesting the use
>of open source CORBAs like TAO, etc, but my management is concerned with having
>"someone" to beat on when it breaks.  

>Are there CORBA vendors that are known for providing sterling support?  

There is a number of ORBs that are available commercially, and in source
form. ORBacus and TAO come to mind, although you'd have to check out the
specific support guarantees yourself.

Quote:>Can using the open source model for CORBA really work for production level
>applications?   Using TAO for example, are their millions of net-heads using it,
>testing it, fixing bugs, providing patches?  Or are we really on our own
>and need to invest staff to support it ourselves?

I think in the TAO example, you'll find that there is a commercial entity
(OCI) providing support for it. My experience with CORBA is that source
availability is a must-have, commercial or not.

I'd say that Open Source does work for CORBA as well. There are indeed
millions of net-heads using it, fixing bugs, and providing patches. One
problem is that they are spread over thousands of projects, so finding
a good free ORB is as difficult as finding a good commercial one. Look
for those with a large user base; from my experience, I'd say ORBit,
Mico, ILU, Fnorb, omniORB qualify here (me knowing nothing about Java).

Regards,
Martin

 
 
 

CORBA, CORBA, CORBA

Post by Carlos O'Rya » Fri, 24 Mar 2000 04:00:00


Hi,


> > of open source CORBAs like TAO, etc, but my management is concerned
> > with having
> > "someone" to beat on when it breaks.
> Perhaps management should revist the success of "beating" on your
> current ORB vendor before using this as a reason. I know TAO is
> supported through OCI (www.ociweb.com) so you can "beat" on them if
> necessary. I am not sure about the other Open Source ORBs..

        Just to set the record straight, my understanding of the
ORBacus model is that they are a commercial product with source freely
available, Michi or Mark or somebody else from OOC will surely correct
me if i'm wrong.  In practice i don't think this is no different from
the TAO model (open source with commercial support available).

        I believe that MICO had commercial support too, and you could
claim that RedHat is supporting ORBit (though i doubt they will
understand if you call them about some bug in the IDL compiler).

                                HTH

--

#include <std.disclaimer>
#include <cute.quote> // "Speak softly and carry a megawatt laser"
1024D/46936992 33B3 C4ED AA90 FA0F E8D1  D509 FE5E 8F79 4693 6992

 
 
 

CORBA, CORBA, CORBA

Post by Bill Beckwi » Sat, 25 Mar 2000 04:00:00



Quote:>Are the problems we are seeing as we scale up a limitation of the CORBA
>architecture we have chosen?

Possibly.

Quote:>A limitation of CORBA itself?

The quality of CORBA ORB implementations varies dramatically.
Please don't use a bad experience with one ORB to judge all
ORBs.

Quote:>Are there ORBs known for their scalabilty, performance,
>multi-threaded safeness?  Is there some kind of comparison chart?

Boeing did a trade study on Real-Time CORBA.  In the study
they benchmarked several ORBs.  They did not test scalability
however.  The study can be downloaded from:

  http://www.ois.com/technical/rt_diicoe/release.html

You may not have been thinking that you need a "real-time" ORB.
However, you will not find faster, more robust group of products
for building mission critical systems.

Note that real-time ORBs can vary dramatically in their ability
to scale well to large applications.  Scalability to me means
that the product's performance degradation (compared to sockets)
and memory usage remains small in the presence of large numbers of:

  * objects,
  * threads,
  * clients,
  * servers,
  * interfaces,
  * operations,
  * transports, and
  * POAs.

I can speak the scalability of ORBexpress.  We have many simulation
customers and their demands forced internal design decisions that
allow for graceful scaling in very large systems despite the very
small memory footprint of the product.

Quote:>Can we practically achieve vendor independence using POA interfaces and
>wrapping vendor-isms appropriately?

You should demand no less from your ORB vendor.

Quote:>Given the effort to pry fixes out of our current vendor, I'm suggesting
>the use of open source CORBAs like TAO, etc, but my management is
>concerned with having "someone" to beat on when it breaks.  

Some of the ORB vendors have grown so quickly that they didn't
keep up with their support requirements.  Good support from a
commercial vendor that partners with you for your success is
difficult to beat.

Quote:>Are there CORBA vendors that are known for providing sterling support?  

Check out the support survey in the Boeing trade study.

Quote:>Any and all comments are welcome.  >

Whew, I'm covered!  :-)

-- Bill

 
 
 

CORBA, CORBA, CORBA

Post by Michi Hennin » Sat, 25 Mar 2000 04:00:00


On Thu, 23 Mar 2000, Dan O'Brien wrote:
> We are finding that as we scale up the number of users, this vendors
> CORBA starts running into deadlocks and other blocking issues where
> the server becomes crusted over and quits functioning.

> We are working with the vendor to provide a solution, but we are finding
> ourselves less confident in this particular ORB and are looking to
> make a change.

Before you give the vendor a hard time, it is possible that the problem
is in your code, rather than the vendor's. Of course, not knowing which
vendor and not having seen your code, I can't judge exactly why you are
having problems. Given that you mention a pre-POA ORB, I wouldn't be
surprised to see threading problems though. Some pre-POA ORBs have
threading support that is, shall we say, sub-optimal and, in addition,
the BOA doesn't lend itself to threading all that well either, at least
not compared to the POA.

> We presently use many proprietary extensions of this particular vendor's
> ORB and are looking at ways to move our application platform away from the
> proprietary extensions to using only (mostly) OMG CORBA 2.3 POA interfaces.
> (Even the vendor of our current ORB is even pointing us to their follow on
> product that implements OMG CORBA 2.3 using POA technology.)

> So we are at a cross roads.

> Are the problems we are seeing as we scale up a limitation of the CORBA
> architecture we have chosen?  A limitation of CORBA itself?

There is no way to tell without knowing your architecture -- it may well
be contributing to your problems. In general, there are no inherent scalability
limitations in CORBA itself. In particular, with the POA, you can scale
to extremely large numbers of objects in a controlled memory footprint,
and you can take precise control over the performance vs memory consumption
trade-off. But, as with any powerful tool, you can also build something
with abysmal performance -- CORBA can't do your designing for you...

> Are there ORBs known for their scalabilty, performance,
> multi-threaded safeness?  Is there some kind of comparison chart?

There are a few benchmarks around. However, I don't recall any benchmarks
that address multi-threading.

> Can we practically achieve vendor independence using POA interfaces and
> wrapping vendor-isms appropriately?

You can get damn close if you choose an appropriate design. For one thing,
the POA is source-code portable. The only things left unspecified are
issues that can be dealt with in your build environment, such as file names,
location of header files, library names, etc. Second, the POA is well-designed
and provides a lot of functionality in a standard way that is essential
for scalable designs (such as servant managers, default servants, decoupling
of the life cycle of servant and reference, etc.)

But even with the POA, you will find vendor extensions. Not because the vendors
are evil and want to lock you in (well, maybe some are ;-), but usually
because some functionality isn't specified. For example, standardized
threading support in the POA is not as good as it could have been. And,
there are other parts of CORBA that are deliberately not standardized (such
as implementation repositories) because standardizing those makes little sense.

> Given the effort to pry fixes out of our current vendor, I'm suggesting the use
> of open source CORBAs like TAO, etc, but my management is concerned with having
> "someone" to beat on when it breaks.  

> Are there CORBA vendors that are known for providing sterling support?  

Ask around. You will probably find that smaller vendors tend to get much
more favourable judgments than big vendors when it comes to support.

> Can using the open source model for CORBA really work for production level
> applications?   Using TAO for example, are their millions of net-heads using it,
> testing it, fixing bugs, providing patches?  Or are we really on our own
> and need to invest staff to support it ourselves?

If you have an ORB you need to support yourself, then you are wasting your
time (unless you are an enthusiast and get a kick out of this sort of thing).
An ORB is infrastructure that is supposed to make your life easier, not
harder. You don't expect to have to debug your TCP/IP stack either, do you?

As far as Open Source is concerned, it's been very successful in some instances
(e.g. Linux and the GNU tools), but less successful in others. Basically,
for Open Source to be successful, you have to have something that is
sexy enough to attract developers' interest, and that is large enough to make
a living by providing professional support for it. There also seems
to be a focus for Open Source on tools, rather than end-user applications.
(Yes, I know that's a generalization and that there are exceptions.)

When you look at the vast amount of software out there, and compare it to
the amount of software available as Open Source, there actually isn't all
that much Open Source. That's not really surprising -- for example, I don't
know of an Open Source airline reservation system, or an Open Source
ignition controller for fuel injected cars. (Those things don't make
a lot of sense as Open Source, or at least they don't if you want
to make money off commercial support, either because they don't have wide
enough distribution and are not of general interest, or because they are
too specialized.) Also, a lot of Open Source contributors are motivated by
peer recognition, so the less visible and "sexy" a particular project is,
the less likely it is to attract Open Source contributors.

ORBs sort of qualify and don't qualify as Open Source, I think. They have
the tool and infrastructure aspect, and they are complex enough to
require commercial support. I'm not sure how "sexy" they are these days.
Many of the problems addressed by ORBs are no longer research material, but
are solved problems with known solutions. The research aspect in CORBA lies
in those bits that aren't standardized yet, such as multicast or fault
tolerance.

The main problem I have with Open Source is that, unless it has a very
wide following, such as Linux, there is a risk that the developers/maintainers
lose interest and move to bigger and better things. Sure, you have the source,
so you can take over. However, most accounting software firms are in the
business of doing accounting things, not in the business of maintaining ORBs.
Or, to put this differently, if you are using an Open Source ORB to get
some job done, you probably won't be interested in taking on maintenance
of the ORB, even though you could do that in theory. (Incidentally,
I see this as one of the big fallacies of Open Source proponents -- the
argument that I can always take over and maintain the source myself simply
is unrealistic in most commercial situations, even assuming that I have
the skills.)

People will also argue that Open Source is unlikely to be abandoned. For
something very large, like Linux, I agree that this is unlikely. For smaller
efforts, I'm not so sure. In my twenty years as a programmer, I have seen
plenty of Open Source find its way into the mainstream and disappear without
a trace because the developers lost interest.

So, for managers who like their security blanket, a commercial offering
may well be more attractive than an Open Source one. On the other hand,
Open Source is free, commercial software is not. The vexing thing is
that, often, source code products are technically superior to binary ones.
With ORBacus, we've gone down the middle path: not open source (although
you get the source), but not free either (although free for non-commercial
use).

As always, there is the whole spectrum: from binary-only and run-time
licensing to Open Source with no cost whatsoever, and quite a few
options in between. Where you want to be on that spectrum is up to you and
is a decision only you can make. However, I wouldn't judge the whole
of CORBA by one poor example (whether that is a binary-only commercial
offering, or an Open Source one). There are good and bad binary commercial
products around, just as you can find good and bad Open Source ones.
And, just because you can have the source for something, that most definitely
doesn't mean that it will be poor.

                                                        Cheers,

                                                                Michi.
--
Michi Henning               +61 7 3891 5744
Object Oriented Concepts    +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St     +61 7 3891 5009 (fax)
East Brisbane 4169          mi...@ooc.com.au
AUSTRALIA                   http://www.ooc.com.au/staff/michi-henning.html

 
 
 

CORBA, CORBA, CORBA

Post by Martin v.Loew » Sat, 25 Mar 2000 04:00:00




Quote:>    Just to set the record straight, my understanding of the
>ORBacus model is that they are a commercial product with source freely
>available, Michi or Mark or somebody else from OOC will surely correct
>me if i'm wrong.  In practice i don't think this is no different from
>the TAO model (open source with commercial support available).

I think there is a difference: TAO is open source (www.opensource.org),
whereas ORBacus is merely available in source form to users (i.e. the
source is not open). ORBacus is free for academic use, though, so it
is not purely commercial, either.

For people requiring commercial support, this difference is probably of
no importance. It matters for people who want to extend the implementation,
and share their extensions with others.

Regards,
Martin

 
 
 

CORBA, CORBA, CORBA

Post by Martin v.Loew » Sat, 25 Mar 2000 04:00:00




Quote:>Incidentally,
>I see this as one of the big fallacies of Open Source proponents -- the
>argument that I can always take over and maintain the source myself simply
>is unrealistic in most commercial situations, even assuming that I have
>the skills.

That the developers give up the project even when there is a large user
community is indeed a rare case, Michi. Projects die because nobody is
interested in it, including the authors. If you cannot maintain the source
yourself, you still can hire somebody. That wouldn't be that economic
anymore, but it also would be the last resort in the worst case.

With CORBA, you have an additional options: Switch to another
implementation of CORBA. CORBA is designed to allow portable applications,
which reduces the risk that your particular implementation is abandoned
by its authors - commercial or not.

Regards,
Martin

 
 
 

CORBA, CORBA, CORBA

Post by Gerald Bros » Sat, 25 Mar 2000 04:00:00



> > Can using the open source model for CORBA really work for production level
> > applications?   Using TAO for example, are their millions of net-heads using it,
> > testing it, fixing bugs, providing patches?  Or are we really on our own
> > and need to invest staff to support it ourselves?

> If you have an ORB you need to support yourself, then you are wasting your
> time (unless you are an enthusiast and get a kick out of this sort of thing).
> An ORB is infrastructure that is supposed to make your life easier, not
> harder. You don't expect to have to debug your TCP/IP stack either, do you?

Well, he asked about "using" the Open Source model rather than joining
the project, so let's focus on using open source products for a moment.
I would argue that CORBA is one of the few fields where the risk that
you run with using an Open Source product is minimal (the risk being
that the product stops being supported/developed any further).

Quote:> The main problem I have with Open Source is that, unless it has a
> very wide following, such as Linux, there is a risk that the
> developers/maintainers lose interest and move to bigger and better
> things. Sure, you have the source, so you can take over.

Taking for granted that customers don't want to take over, with
CORBA you don't need to - just switch to a different platform. Of
course, this has two obvious prerequisites:

a) compliant, interoperable ORB implementations
b) abolutely portable application code.

a) is getting better all the time, b) is sometimes hard to come
by, but in many cases it is possible. Striving for b) also has the
welcome side-effect of greatly improving application quality. Sure,
there are cases where applications just cannot live without vendor-
specific extensions, then this nice model breaks down, but it's
certainly possible for many others.

So, with a compliant Open Source ORB and a portable application,
the risk that you are locked into an ORB that has disappeared from
the market actually comes close to zero.

My second point is that some CORBA users do have to "take over" -
because their company is just not big enough to catch the big
vendor's interest in giving them the specialized support they need,
e.g. for their "very special" production environment such as their
homegrown brand of embedded controllers for the very special brand
of machines they sell. In this case, having the option of tuning the
ORB yourself is a very valuable one. Even TCP/IP stacks continue to
get tuned this way...

So, the bottom line is that Open Source ORBs can be safely used
for vanilla applications, you can always switch to a different
and *potentially* better ORB later. On the other hand, Open Source
ORBs come in handy for applications with very specific requirements
sometimes that require tuning the platform to your, if the vendor
simply won't do it for you. As an Open Source ORB developer myself,
I happily leave the "middle ground" to commercial ORBs such as
yours.

The only real problem for customers is that they had better know
their requirements to be able to make an informed choice, but that's
a problem anyway, isn't it.

Regards, Gerald Brose.
--

FU Berlin        (for PGP key see:) http://www.inf.fu-berlin.de/~brose
Institut f. Informatik              Ph-one:        (++49-30) 838-75112
Berlin, Germany                     Ph-ax:         (++49-30) 838-75109

 
 
 

CORBA, CORBA, CORBA

Post by Douglas C. Schmi » Sat, 25 Mar 2000 04:00:00


Hi Michi,

Quote:> People will also argue that Open Source is unlikely to be abandoned.

Taken out of context, that's clearly a silly statement.

Quote:> For something very large, like Linux, I agree that this is
> unlikely. For smaller efforts, I'm not so sure.

Right.

Quote:> In my twenty years as a programmer, I have seen plenty of Open
> Source find its way into the mainstream and disappear without a
> trace because the developers lost interest.

Of course.  Naturally, the same thing is true of commercial ORB
products, as well.  In fact, at this point, it's definitely the case
that many more non-open-source ORBs providers have closed up shop than
open-source ORB providers.  For example, take a look at the C++ ORBs
from other "mainstream" ORB providers over the same period and you'll
see that NEO/DOA from Sun, ORBplus from HP, COOL from Chorus, and
HARDPack from Lockheed Martin are all more or less defunct.  In
addition, there are a number of other commercial ORBs that might as
well be defunct at this point, as well, since they have a very small
user community and are clearly not making their owners much $$$.

In contrast, the main open-source C++ ORBs these days are omniORB,
Mico, TAO, and ORBacus (we'll give you guys the benefit of the doubt
on this since open-source doesn't have to mean "freely available for
commercial use" ;-)).  As far as I know, all of these efforts are
thriving.  I suspect in the long-run that the open-source projects
that'll survive will be those that successfully transition into a
commecially viable open-source model, a la Cygnus or RedHat.

In general, I believe open-source is more of a business model than a
technology model, i.e., its a way of being able to reduce engineering
costs while still providing a high quality product to consumers.  Open
source software is typically sold at very little cost since there are
generally no developer or run-time licensing fees.  Therefore,
companies that are providing open source business models are based on
making money using other means, such as support, consulting, training,
and general "shrink wrapping" of open source products to make them
"look and feel" just like conventional commercial products that *do*
charge developer and/or run-time licenses.  (BTW, for more insights on
this perspective, I recommend that you read Michael Tiemann's article
on "Future of Cygnus Solutions: An Entrepreneur's Account" in the book
"OpenSources: Voices from the Open Source Revolution").

Take care,

        Doug
--
Dr. Douglas C. Schmidt, Associate Professor  TEL: (949) 824-1901
Dept of Electrical & Computer Engineering    FAX: (949) 824-2321
616E Engineering Tower                       WEB: www.ece.uci.edu/~schmidt/

 
 
 

CORBA, CORBA, CORBA

Post by Stefan Seefel » Sat, 25 Mar 2000 04:00:00



> In general, I believe open-source is more of a business model than a
> technology model, i.e., its a way of being able to reduce engineering
> costs while still providing a high quality product to consumers.

I think it is difficult to separate these two issues. Both are of a
cultural nature, i.e. are dialectically twisted. Technology drives
the evolution of business models and the emergence of new business
models develops new demands on technology, such as transparency and
openness, now in terms of software architecture and design.

Regards,        Stefan

_______________________________________________________              

Stefan Seefeld
Departement de Physique
Universite de Montreal

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...

 
 
 

CORBA, CORBA, CORBA

Post by Douglas C. Schmi » Sat, 25 Mar 2000 04:00:00


Hi Michi,

I agree with much of what you wrote (as usual ;-)).  However, I want
to clarify a few things that are unclear from the wording in your
posting.  In particular, the following:

Quote:>> So, from the customer's perspective, it's similar to the TAO model in that
>> the source is available and that commercial support is available too.

>> However, there are a number of important differences as well:
...
>>        - There is no obligation on our customers to make source code
>>          available if they build products with ORBacus. There is no
>>          contamination of their code of any kind, unlike with the
>>          the GNU license (which, apart from the GPL, isn't considered
>>          Open Source anyway, at least not according to the definition in
>>          "Open Sources", published by O'Reilly.)

It's not clear from your wording if you're implying that ACE+TAO's
open-source license obligates customers to make their source code
available.  I just want to clarify unambiguously for the record that
this is NOT the case, i.e., ACE+TAO are examples of open-source
software that do *not* use the GPL.  Please see

http://www.cs.wustl.edu/~schmidt/TAO-copying.html

for the specific wording on this.

Quote:>>        - Derived works are not allowed without a licensing agreement with
>>          us. That's probably the most important difference to Open Source.
>>          You can't take our source, branch a new version off it and
>>          derive a new ORB (except for non-commercial purposes).

FYI, derived works have never been an issue with either ACE or TAO
over the past decade.  Although there's nothing to prevent this, in
practice no one has ever created a new version of TAO that ran
parallel to our main effort.  As a result, we get tremendous leverage
from hundreds of person-years of contributed effort to port, optimize,
debug, and document ACE+TAO.  That's one reason why I believe
open-source is such an effective business model, as well as a
technology model.

Quote:>> One key difference I see is that ORBacus isn't built for the
>> betterment of humankind (although we won't object to such
>> betterment :-) Instead, it's built as a commercial product, so we
>> can eat and pay our mortgages and such, and hopefully have some
>> money left over.

There's certainly nothing wrong with this.  You and the ORBacus team
have made a very positive contribution to the success of CORBA for
many years.  I look forward to your continued success for many more
years.

Take care,

        Doug

--
Dr. Douglas C. Schmidt, Associate Professor  TEL: (949) 824-1901
Dept of Electrical & Computer Engineering    FAX: (949) 824-2321
616E Engineering Tower                       WEB: www.ece.uci.edu/~schmidt/

 
 
 

CORBA, CORBA, CORBA

Post by Michi Hennin » Sun, 26 Mar 2000 04:00:00



Quote:> > Perhaps management should revist the success of "beating" on your
> > current ORB vendor before using this as a reason. I know TAO is
> > supported through OCI (www.ociweb.com) so you can "beat" on them if
> > necessary. I am not sure about the other Open Source ORBs..

>    Just to set the record straight, my understanding of the
> ORBacus model is that they are a commercial product with source freely
> available, Michi or Mark or somebody else from OOC will surely correct
> me if i'm wrong.  In practice i don't think this is no different from
> the TAO model (open source with commercial support available).

Well, ORBacus is distributed in source form. The main difference to Open Source
is that our licensing model means that we retain ownership, copyright, and
intellectual property rights on that source code. The source isn't freely
available in the sense that, if you use ORBacus for commercial purposes,
you are expected to buy development licenses. For non-commercial use,
ORBacus is free. Pragmatically, it's almost the same though because anyone
can download the source anytime they like. In effect, we are relying on
people's honesty to buy licenses when they use ORBacus for commercial
purposes and, to some extent, we are relying on people's honesty to respect
our copyright.

So, from the customer's perspective, it's similar to the TAO model in that
the source is available and that commercial support is available too.

However, there are a number of important differences as well:

        - We don't produce Open Source. OOC owns and controls the source.
          People are welcome to submit changes and make contributions, but
          OOC is the ultimate judge of what is accepted into the source
          base. (Usually, such cases are no-brainers because the source
          changes that we get from customers are usually bug fixes; more
          major things that customers contribute are made available by
          us by maintaining links to contributed source or tools, but we
          don't claim ownership on those, of course.)

        - For commercial purposes, you are not allowed to redistribute
          our source, and you can't on-sell it.

        - There is no obligation on our customers to make source code
          available if they build products with ORBacus. There is no
          contamination of their code of any kind, unlike with the
          the GNU license (which, apart from the GPL, isn't considered
          Open Source anyway, at least not according to the definition in
          "Open Sources", published by O'Reilly.)

        - Derived works are not allowed without a licensing agreement with
          us. That's probably the most important difference to Open Source.
          You can't take our source, branch a new version off it and
          derive a new ORB (except for non-commercial purposes).

One key difference I see is that ORBacus isn't built for the betterment
of humankind (although we won't object to such betterment :-) Instead, it's
built as a commercial product, so we can eat and pay our mortgages and such,
and hopefully have some money left over.

In short, it isn't free (which some people will not like). On the other hand,
it's being built by a dedicated team of professionals who are getting paid
to do what they are doing, so the product doesn't rely on the good will
and donated time of volunteer contributors. And, we are not just taking
things out, we are also putting things back into the CORBA community, mainly
through our participation in the OMG (which, as it turns out, consumes
prodigious amounts of both time and money...)

And, come to think of it, the postings I make here don't write themselves
in zero time either :-)

                                                        Cheers,

                                                                Michi.
--
Michi Henning               +61 7 3891 5744
Object Oriented Concepts    +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St     +61 7 3891 5009 (fax)

AUSTRALIA                   http://www.ooc.com.au/staff/michi-henning.html

 
 
 

CORBA, CORBA, CORBA

Post by Michi Hennin » Sun, 26 Mar 2000 04:00:00





> >Incidentally,
> >I see this as one of the big fallacies of Open Source proponents -- the
> >argument that I can always take over and maintain the source myself simply
> >is unrealistic in most commercial situations, even assuming that I have
> >the skills.

> That the developers give up the project even when there is a large user
> community is indeed a rare case, Michi. Projects die because nobody is
> interested in it, including the authors.

Yes. As I pointed out myself, the size of the project has a lot to do
with whether it might be abandoned. The larger the project, the less likely
that is to happen.

Quote:> If you cannot maintain the source
> yourself, you still can hire somebody. That wouldn't be that economic
> anymore, but it also would be the last resort in the worst case.

I don't think so. For one, as a CORBA user, I may simply not have the budget
to hire someone and take over maintenance of an ORB. But, more importantly,
where am I going to hire such a person from? I can tell you from first-hand
experience that hiring a good CORBA developer (with sufficient knowledge
to work on ORB internals) isn't something that's exactly easy. (Recent,
somewhat inappropriate, job ads posted to this group will back me up on
that ;-)

Quote:> With CORBA, you have an additional options: Switch to another
> implementation of CORBA. CORBA is designed to allow portable applications,
> which reduces the risk that your particular implementation is abandoned
> by its authors - commercial or not.

Yes. Portability is extremely important and worth a lot. But keep in mind
that the decision to switch an ORB involves a lot of hidden costs. You have
to modify the build environment, retest everything, deal with deployment
and licensing issues, deal with vendor-specific things in the old code base,
etc, etc. These things most definitely don't come at zero cost.

                                                        Cheers,

                                                                Michi.
--
Michi Henning               +61 7 3891 5744
Object Oriented Concepts    +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St     +61 7 3891 5009 (fax)

AUSTRALIA                   http://www.ooc.com.au/staff/michi-henning.html

 
 
 

CORBA, CORBA, CORBA

Post by Michi Hennin » Sun, 26 Mar 2000 04:00:00



Quote:> >> However, there are a number of important differences as well:
> ...
> >>   - There is no obligation on our customers to make source code
> >>     available if they build products with ORBacus. There is no
> >>     contamination of their code of any kind, unlike with the
> >>     the GNU license (which, apart from the GPL, isn't considered
> >>     Open Source anyway, at least not according to the definition in
> >>     "Open Sources", published by O'Reilly.)

> It's not clear from your wording if you're implying that ACE+TAO's
> open-source license obligates customers to make their source code
> available.

No, I didn't mean to imply that. Sorry if I gave the wrong impression.

Quote:> I just want to clarify unambiguously for the record that
> this is NOT the case, i.e., ACE+TAO are examples of open-source
> software that do *not* use the GPL.  Please see

BTW -- the GPL also does not contaminate things and is an example of an
Open Source license. (Licenses that contaminate your code, such as Copyleft,
are generally not considered Open Source licenses, at least not according to
the O'Reilly book.)

Quote:> >> One key difference I see is that ORBacus isn't built for the
> >> betterment of humankind (although we won't object to such
> >> betterment :-) Instead, it's built as a commercial product, so we
> >> can eat and pay our mortgages and such, and hopefully have some
> >> money left over.

> There's certainly nothing wrong with this.  You and the ORBacus team
> have made a very positive contribution to the success of CORBA for
> many years.  I look forward to your continued success for many more
> years.

Thanks! I can, of course, return the compliment :-)

                                                        Cheers,

                                                                Michi.
--
Michi Henning               +61 7 3891 5744
Object Oriented Concepts    +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St     +61 7 3891 5009 (fax)

AUSTRALIA                   http://www.ooc.com.au/staff/michi-henning.html

 
 
 

1. sharing structures between corba and non-corba source

Hello Everyone,

I'd like to know how you handle the cases where you have IDL structures
that are essentially the same as structures
in a non-corba class. For example

A.idl and B.h both have this:

                enum TIME_SOURCE {GPS_CLOCK, LOCAL_CPU_CLOCK,
CANONICAL_CLOCK, ANY_CLOCK, NO_CLOCK};
                struct  stamp
                        {
                        long                    HighTime;
                        unsigned long           LowTime;
                        TIME_SOURCE             Source;
                        unsigned long long      SampleID;
                        };

The implementation class for A contains an instance of the class B.... A
is just a CORBA wrapper.

I'd like to avoid the duplicate declarations (and also all the copying
back and forth for sequences<-->vectors, enum mappings, etc).

How do you all handling these cases?

Thanks,
Jeff

2. Wanted: 68000, Wordperfect 4.1

3. ANNOUNCE: Remoting.Corba 1.2 - CORBA/IIOP Support for .NET

4. Poor PocketPC Documentation Supplied with EM500

5. strange corba marshal error org.omg.CORBA.MARSHAL

6. Clipboard functions

7. Orbix 3.0.1 corba client wants to communicate with VisiBroker 4.5 corba

8. CORBA 2.4.x compliance w.r.t. messaging changes in CORBA core.

9. Embedded CORBA / Alternatives to CORBA

10. About CORBA/non-CORBA Gateway

11. Combine FT-CORBA and RT-CORBA

12. CORBA 2 IDL to CORBA 3 IDL