Issue 4079: Component home polymorphism (components-ftf)
Source: Iconixx (Mr. Thomas S. Hawker, )
Nature: Uncategorized Issue
Severity: 
Summary: See the CORBA Component Specification, orbos/99-07-01, and Persistent
State Service issue #4074.  Is there any reason why homes cannot support
(manage) multiple component types?  This seems like a perfect case for
polymorphism;  the only time you really need a new home type is when you
change the behavior or have some other incompatibility.  Is it possible
to do instances of homes, one per component type (perhaps instances of
components acting as managers for other components)?  I simply do not
understand why these are one-to-one with parallel but distinct
derivations.  I realize the requirements were to maximize code
generation, but I don't see that this is a conflict.

Resolution: rejected
Revised Text: 
Actions taken:
November 24, 2000: received issue
May 13, 2002: closed issue
Discussion: 
The CORBA Component model explicitly separates the component and home
concepts, i.e. a component could not be a home and a home could not be a
component. In the CCM, a home type manages only one component type and a
component type could be managed by several home types. However the CCM
does not avoid a home implementation to manage several component
implementations. In this use case, these component implementations must
implement at least the component type managed by the home type. But these
component implementations could also implement derived component types as
shown in the following IDL example:
component C1 { ... };
component C2 : C1 { ... };
valuetype K : ::Components::PrimaryKeyBase { ... };
home H1 manages C1 primarykey K { ... };
and
. CI1 is an implementation of the C1 type;
. CI2 is an implementation of the C2 type but also of the C1 type transitively as
C2 inherits from C1; and HI1 is an implementation of the H1 type and must manage at least C1
instances.
As both CI1 and CI2 implement C1 then HI1 could manage both CI1 and CI2
instances. Then it is not required to define a specific home type to manage C2
components.
Defining a home type H2 managing C2 components is only required if the IDL
designer wants to for instance:
. identity its components with a primary key completely different from K (or a
sub-type of K),
. define new explicit operations like factory and finder ones, and/or
. provide to clients a resulting H2Implicit interface, i.e. an interface that
provides standard create, finder and remove operations dedicated to the C2
type.
End of Annotations:=====
From: thomas.s.hawker@mail.sprint.com
X-OpenMail-Hops: 1
Date: Fri, 24 Nov 2000 16:09:27 -0600
Message-Id: <H00025510d14f471.0975103764.kcopmp01@MHS>
Subject: Component home polymorphism
MIME-Version: 1.0
TO: issues@omg.org
Content-Type: multipart/mixed;
boundary="openmail-part-35a6c226-00000001"
X-UIDL: @3%!!oZdd9n9He9Cj%"!

See the CORBA Component Specification, orbos/99-07-01, and Persistent
State Service issue #4074.  Is there any reason why homes cannot
support
(manage) multiple component types?  This seems like a perfect case for
polymorphism;  the only time you really need a new home type is when
you
change the behavior or have some other incompatibility.  Is it
possible
to do instances of homes, one per component type (perhaps instances of
components acting as managers for other components)?  I simply do not
understand why these are one-to-one with parallel but distinct
derivations.  I realize the requirements were to maximize code
generation, but I don't see that this is a conflict.
 
Tom Hawker, Iconixx
thawker@iconixx.com