TIE vs BOA
Graham Fisher
How do you decide whether to use TIE or BOA? Is it just a 'personal
preference' or are the performance advantages of one over the other.
Thanks
Graham
Graham...@keane.uk.com
Thomas Borg Salling
> How do you decide whether to use TIE or BOA? Is it just a 'personal
> preference' or are the performance advantages of one over the other.
You [can] use TIE classes when the implementation classes cannot inherit
from the skeleton classes generated by the IDL compiler. This is the
case when e.g. the implementation classes come from a third party vendor
and you dont have the source code.
Or in case you want to avoid multiple inheritance in your own code.
There are situations were each class in an inheritance-chain needs an
IDL interface - and without TIE classes you will then run into multiple
inheritance (at least for C++, which I know best).
Thomas.
Paul Jackson
|> You [can] use TIE classes when ...
When wouldn't you use TIE, then? That is, why use BOA?
Suspected answer: use BOA whenever you can, if you prefer the
mixin style of class derivation, over explicit class membership.
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (p...@sgi.com; p...@usa.net) 3x1373 http://sam.engr.sgi.com/pj
Marcus Chan
or to other third party objects, then maybe BOA will have some
performance advantage, because TIE involves one more level of delegation
and more classes.
On the other hand, if there is inheritance involved, then you run into
multiple inheritance. If you are using C++, it maybe ok, but still
multiple inheritance is ugly and it is something I definitely want to
avoid. And if you are using Java, then you cannot do that at all. So you
have to use TIE. Or if you really want to use BOA, you may use
composition to simulate inheritance on your implementation. (You must
inherit from the CORBA skeleton classes, there's no negotiation.)
However, it will be even more complicated and you may need to modify the
generated code, and it maybe even worse in performance if your
inheritance hierarchy is deep since you need to walk up the hierarchy to
make a call in the base class.
--
Marcus Chan
Data Warehouse Program Office
200 Oracle Parkway, M/S 2op705
Redwood Shores, CA 94065
Email mcc...@us.oracle.com
Phone (650) 633-6198
Fax (650) 506-7414
Matthias Ernst
: Thomas Borg Salling <t...@navicon.dk> wrote:
: |> You [can] use TIE classes when ...
: When wouldn't you use TIE, then? That is, why use BOA?
TIE will give you some identity problems. Your actual implementation and
the servant registered in the ORB are now two different objects.
So in order to register a newly created implementation object with the ORB
you need to find out its tie, or create one. It's just a bit more
difficult.
In Java, you must use TIE because of the missing MI. I then chose TIE for
all my objects since then it's only one technique.
-- Matthias
Robert Huffman
> and it maybe even worse in performance if your
> inheritance hierarchy is deep since you need to walk up the hierarchy to
> make a call in the base class.
Uh, I don't think so. In general, depth of inheritance has nothing to
do with performance.
--
Robert Huffman
Marcus Chan
object.
--
Michi Henning
> Thomas Borg Salling <t...@navicon.dk> wrote:
> |> You [can] use TIE classes when ...
>
> When wouldn't you use TIE, then? That is, why use BOA?
>
> Suspected answer: use BOA whenever you can, if you prefer the
> mixin style of class derivation, over explicit class membership.
There are a number of more subtle issues about the TIE approach.
Yes, TIEs replace inheritance with delegation. That's useful mostly
if your implementation classes are forced to use some existing
framework that uses inheritance extensively. By using a TIE, you get
away from the very complex inheritance hierarchies that can result.
And as someone else pointed out, TIEs allow you to library code
as an implementation object.
That said, I much prefer the inheritance approach. That's because
TIEs create their own share of problems. For one, instead of a single
C++ object in memory, TIEs force you to have two: the TIE itself
plus the servant the TIE delegates to. Not nice, in particular for
life cycle operations. For example, to correctly implement a destroy()
operation, you have to keep a pointer to the TIE in the servant,
otherwise the destroy() can't be implemented. Not only does this
create a circular dependency between TIEs and servants, it also makes
object creation a three-step process:
1) instantiate the servant
2) instantiate the TIE, passing the address of the servant
3) call a method on the servant to pass the address of the
TIE into the servant to initialize the back pointer
In threaded servers, you must interlock around these three steps.
Another disadvantage of TIEs is that if in IDL, "Derived" inherits
from "Base", then the TIE for "Derived" does *not* inherit from the
TIE for "Base". This means you can no longer pass TIE objects
polymorphically in your address space because they are unrelated types.
Instead, you have to pass the objects the TIEs delegate to (which can
still be polymorphic). On occasion, that is inconvenient and can result
in convoluted coding logic, depending on exactly you do things.
In general, I see no advantage to using TIEs, except for the cases
I mentioned earlier. When you think about it, what's so great about
delegation versus inheritance? Inheritance is simpler, so why not use it?
You can also argue that the TIE approach was a mis-guided attempt at
getting more flexible object-to-servant mappings, so I can implement
several CORBA objects as a single C++ object. However, with the POA,
you get far better mechanisms for doing this, making TIEs still more
irrelevant.
Cheers,
Michi.
Copyright 1998 Michi Henning. All rights reserved.
--
Michi Henning +61 7 33654310
DSTC Pty Ltd +61 7 33654311 (fax)
University of Qld 4072 mi...@dstc.edu.au
AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html
Andreas Vogel
Paul Jackson wrote:
> Thomas Borg Salling <t...@navicon.dk> wrote:
> |> You [can] use TIE classes when ...
>
> When wouldn't you use TIE, then? That is, why use BOA?
>
> Suspected answer: use BOA whenever you can, if you prefer the
> mixin style of class derivation, over explicit class membership.
There are the object adapters BOA (now deprecated) and POA. You can glue
your implementation class (servant) together with the skeleton via
inheritance or via delegation, i.e. tie. Tie is useful for languages with
single class inheritance such as Java. You can than inherit an application
specific class.
Cheers,
Andreas