Design question: CORBA Object Implementation and Domain Object Models

Design question: CORBA Object Implementation and Domain Object Models

Post by Chris Mungal » Fri, 21 Aug 1998 04:00:00



I am developing a 3 tier system using Java and CORBA.  I have developed
a domain object layer which is completely independent of the
distribution technology; it knows nothing of CORBA, meaning I can change
the distribution model to RMI or XML/HTTP or whatever, without touching
the domain layer.

The CORBA object implementations are dependent upon the domain objects.
As a rule of thumb, I have one IDL interface and hence one corba class
for each abstract base class in the domain model (although I also make
extensive use of structs for efficiency).  Each corba object delegates
to the corresponding domain object or objects.

The consequences of this are a large number of active objects on the
middle tier.  I don't consider this too heavy a price as the number of
active corba objects never gets too high (structs are used for high
volume data, e.g.  populating listboxes in the GUI), and the main speed
bottleneck is in the distribution break anyway.

The coding for the corba implementation objects relies heavily on
delegation/object adapter and therefore tends to follow repetitive
structures, e.g:

public class CorbaMyClassImpl extends Module._CorbaMyClassImplBase {

  // reference to object in domain.
  private Domain.MyClass _d_myClassInstance;      

  public MyClassImpl(Domain.MyClass d_myClassInstance) {
    // new instance of corba object must refer to a domain object.
    _d_myClassInstance = d_myClassInstance;
  }

  public String oid() {
    // delegate request to domain object.
    return d_myClassInstance.oid();  
  }

  public void attribute(String setting) {
    // delegate request to domain object
    _d_myClassInstance.attribute(setting);
  }  // most setter methods follow this structure.

  public MyClass2 myAssociation() {
    // delegate request to domain object, and get
    // reference to domain object.
    Domain.MyClass2 d_myClassInstance2 =
      _d_myClassInstance.myAssociation();

    // convert domain object to corba object;
    // factory will either create a new instance, or get the one in use.
    return (MyClass2FactoryImpl.instance()).fetch(d_myClassInstance2);
  }
  // this is a typical way of implementing an association.

Quote:}

All operations are delegated to methods in the domain layer.  Every IDL
interface has a corresponding manager/factory, implemented as a
singleton class.  This is used to fetch sets of objects.  It is also
responsible for creation of that class of corba object, and keeps a
hashtable of corba objects keyed by the corresponding domain object's
OID.

The above is simplified code to illustrate some typical code, and
doesn't take into account exceptions or observer/observable
notifications.

The coding for all this is very tedious and repetitive.  If Java
supported multiple inheritance, then I could just make the corba classes
inherit from the domain classes - as it is, I must use delegation.  I
have written a perl module which helps out with automatic code
generation when using delegation.  This is getting unwieldy as I extend
this to delegating arrays, handling inheritance etc.  It isn't always
one-to-one delegation, sometimes the design follows the object adapter
pattern, as the IDL must be more course-grained than the domain model.

I'm considering converting the perl tool to java and using reflection,
but feel I must be re-inventing the wheel here.

My question is: does a tool exist for automatically generating this
kind of code? I came across Cocobase while evaluating
object/relational mapping tools - it seems to do something like this,
but is a little expensive for us. Is it worth my while developing an
inhouse tool?

While on this topic, I would also like to ask if there is any
documentation on patterns for designing IDLs derived from object models.
My approach here has been to derive heuristics as I go along - for
example, have an IDL interface for the domain base abstract classes
only, provide structs as well, provide alternative 'pre-flattened'
structs that give a view across multiple classes for high volume data,
make factories for providing datasets of either type...  there are many
tradeoffs where it is not obvious which approach to use.  One thing I
have learned from earlier mistakes is that most of it is down to a good
design in the domain object later; bad design here means very bad IDL.

If useful, I could provide a document describing this design in more
detail; first of all I'd like to hear the experiences of others using
similar designs/patterns. Maybe most people are using the corba
implementation and the domain model interchangeably and aren't worried
about re-using business rules in a non-CORBA environment? Or maybe
most people are using a language with multiple inheritance and are
subclassing the corba classes off the domain classes, so this isn't
such an issue?

Thanks for any comments,

---
Chris Mungall                Bioinformatics Group        

+44(0)131 527 4477           http://www.ri.bbsrc.ac.uk/bioinformatics/

 
 
 

Design question: CORBA Object Implementation and Domain Object Models

Post by Steve McWillia » Sat, 22 Aug 1998 04:00:00



>I am developing a 3 tier system using Java and CORBA.  I have developed
>a domain object layer which is completely independent of the
>distribution technology; it knows nothing of CORBA, meaning I can change
>the distribution model to RMI or XML/HTTP or whatever, without touching
>the domain layer.
>The CORBA object implementations are dependent upon the domain objects.
>As a rule of thumb, I have one IDL interface and hence one corba class
>for each abstract base class in the domain model (although I also make
>extensive use of structs for efficiency).  Each corba object delegates
>to the corresponding domain object or objects.
>The consequences of this are a large number of active objects on the
>middle tier.  I don't consider this too heavy a price as the number of
>active corba objects never gets too high (structs are used for high
>volume data, e.g.  populating listboxes in the GUI), and the main speed
>bottleneck is in the distribution break anyway.
>The coding for the corba implementation objects relies heavily on
>delegation/object adapter and therefore tends to follow repetitive
>structures, e.g:
>public class CorbaMyClassImpl extends Module._CorbaMyClassImplBase {
>  // reference to object in domain.
>  private Domain.MyClass _d_myClassInstance;      
>  public MyClassImpl(Domain.MyClass d_myClassInstance) {
>    // new instance of corba object must refer to a domain object.
>    _d_myClassInstance = d_myClassInstance;
>  }

>  public String oid() {
>    // delegate request to domain object.
>    return d_myClassInstance.oid();  
>  }

>  public void attribute(String setting) {
>    // delegate request to domain object
>    _d_myClassInstance.attribute(setting);
>  }  // most setter methods follow this structure.
>  public MyClass2 myAssociation() {
>    // delegate request to domain object, and get
>    // reference to domain object.
>    Domain.MyClass2 d_myClassInstance2 =
>      _d_myClassInstance.myAssociation();
>    // convert domain object to corba object;
>    // factory will either create a new instance, or get the one in use.
>    return (MyClass2FactoryImpl.instance()).fetch(d_myClassInstance2);
>  }
>  // this is a typical way of implementing an association.
>}
>All operations are delegated to methods in the domain layer.  Every IDL
>interface has a corresponding manager/factory, implemented as a
>singleton class.  This is used to fetch sets of objects.  It is also
>responsible for creation of that class of corba object, and keeps a
>hashtable of corba objects keyed by the corresponding domain object's
>OID.
>The above is simplified code to illustrate some typical code, and
>doesn't take into account exceptions or observer/observable
>notifications.
>The coding for all this is very tedious and repetitive.  If Java
>supported multiple inheritance, then I could just make the corba classes
>inherit from the domain classes - as it is, I must use delegation.  I
>have written a perl module which helps out with automatic code
>generation when using delegation.  This is getting unwieldy as I extend
>this to delegating arrays, handling inheritance etc.  It isn't always
>one-to-one delegation, sometimes the design follows the object adapter
>pattern, as the IDL must be more course-grained than the domain model.
>I'm considering converting the perl tool to java and using reflection,
>but feel I must be re-inventing the wheel here.
>My question is: does a tool exist for automatically generating this
>kind of code? I came across Cocobase while evaluating
>object/relational mapping tools - it seems to do something like this,
>but is a little expensive for us. Is it worth my while developing an
>inhouse tool?

I tend not to use it much, but doesn't the Tie-style of idl-generated Java
code take care of your delegation overhead?  You just define your Corba-
ignorant domain object to implement the Java interface which is generated
from the corresponding idl, then instantiate the idl-generated adapter (tie)
class with your domain object as its delegate.

Cheers,
Steve
--
Steve McWilliams
Software Engineer, www.access.digex.net/~stevemc

 
 
 

Design question: CORBA Object Implementation and Domain Object Models

Post by Sven Bra » Sun, 23 Aug 1998 04:00:00


Hi,

below you are decribing the tie-approach of the Corba-IDL to Java
Mapping, aren't you?

If this is true, then the idl-Compiler generates all the classes you
need. Ok, this approach is not CORBA compliant and one does need a
compiler that supports the tie-approach, as does OrbixWeb. I heard Suns
JDK idl2java compiler and Inprises/Visigenics product does so too, still
I am not sure about that.

The idl Compiler generates tie-Classes. Those represent the actuall
implementation object to the CORBA infrastructure and hold references to
objects actually implementing the functionality. That means there's an
association (many to one) from tie-Objects to implementation objects.

They are used as follows:

1 to 1 association:
-------------------
externalReference1 = new _tie_MyInterface1( new MyInterface1Impl() );

Many to 1 association:
----------------------
internalReference = new MyInterface1And2Impl();

externalReference1 = new _tie_MyInterface1( internalReference );
externalReference2 = new _tie_MyInterface2( internalReference );

Sincerly
Sven Braun


> public class CorbaMyClassImpl extends Module._CorbaMyClassImplBase {

>   // reference to object in domain.
>   private Domain.MyClass _d_myClassInstance;      

>   public MyClassImpl(Domain.MyClass d_myClassInstance) {
>     // new instance of corba object must refer to a domain object.
>     _d_myClassInstance = d_myClassInstance;
>   }

>   public String oid() {
>     // delegate request to domain object.
>     return d_myClassInstance.oid();  
>   }

>   public void attribute(String setting) {
>     // delegate request to domain object
>     _d_myClassInstance.attribute(setting);
>   }  // most setter methods follow this structure.

>   public MyClass2 myAssociation() {
>     // delegate request to domain object, and get
>     // reference to domain object.
>     Domain.MyClass2 d_myClassInstance2 =
>       _d_myClassInstance.myAssociation();

>     // convert domain object to corba object;
>     // factory will either create a new instance, or get the one in use.
>     return (MyClass2FactoryImpl.instance()).fetch(d_myClassInstance2);
>   }
>   // this is a typical way of implementing an association.

> }

--
Sven Braun            Sven.Braun"at"stud.uni-karlsruhe.de (preferred)
Karlsruhe, Germany    PGP 5.0 PublicKey Fingerprint:
                      5CEB 06B5 E1CF FD80 5914  DCC4 2E33 0EF6 04A4 B015
      commercial mail NOT permitted, unless I explicitly ask for.
 
 
 

Design question: CORBA Object Implementation and Domain Object Models

Post by Oliver Enselin » Sun, 23 Aug 1998 04:00:00


In fact, VisiBorker does support the tie approach.

Oliver Enseling


>Hi,

>below you are decribing the tie-approach of the Corba-IDL to Java
>Mapping, aren't you?

>If this is true, then the idl-Compiler generates all the classes you
>need. Ok, this approach is not CORBA compliant and one does need a
>compiler that supports the tie-approach, as does OrbixWeb. I heard Suns
>JDK idl2java compiler and Inprises/Visigenics product does so too, still
>I am not sure about that.

>The idl Compiler generates tie-Classes. Those represent the actuall
>implementation object to the CORBA infrastructure and hold references to
>objects actually implementing the functionality. That means there's an
>association (many to one) from tie-Objects to implementation objects.

>They are used as follows:

>1 to 1 association:
>-------------------
>externalReference1 = new _tie_MyInterface1( new MyInterface1Impl() );

>Many to 1 association:
>----------------------
>internalReference = new MyInterface1And2Impl();

>externalReference1 = new _tie_MyInterface1( internalReference );
>externalReference2 = new _tie_MyInterface2( internalReference );

>Sincerly
>Sven Braun


>> public class CorbaMyClassImpl extends Module._CorbaMyClassImplBase {

>>   // reference to object in domain.
>>   private Domain.MyClass _d_myClassInstance;

>>   public MyClassImpl(Domain.MyClass d_myClassInstance) {
>>     // new instance of corba object must refer to a domain object.
>>     _d_myClassInstance = d_myClassInstance;
>>   }

>>   public String oid() {
>>     // delegate request to domain object.
>>     return d_myClassInstance.oid();
>>   }

>>   public void attribute(String setting) {
>>     // delegate request to domain object
>>     _d_myClassInstance.attribute(setting);
>>   }  // most setter methods follow this structure.

>>   public MyClass2 myAssociation() {
>>     // delegate request to domain object, and get
>>     // reference to domain object.
>>     Domain.MyClass2 d_myClassInstance2 =
>>       _d_myClassInstance.myAssociation();

>>     // convert domain object to corba object;
>>     // factory will either create a new instance, or get the one in use.
>>     return (MyClass2FactoryImpl.instance()).fetch(d_myClassInstance2);
>>   }
>>   // this is a typical way of implementing an association.

>> }

>--
>Sven Braun            Sven.Braun"at"stud.uni-karlsruhe.de (preferred)
>Karlsruhe, Germany    PGP 5.0 PublicKey Fingerprint:
>                      5CEB 06B5 E1CF FD80 5914  DCC4 2E33 0EF6 04A4 B015
>      commercial mail NOT permitted, unless I explicitly ask for.

 
 
 

Design question: CORBA Object Implementation and Domain Object Models

Post by Andy L. Czerwon » Mon, 24 Aug 1998 04:00:00


[This followup was posted to comp.object and a copy was sent to the cited
author.]



Quote:> I am developing a 3 tier system using Java and CORBA.  I have developed
> a domain object layer which is completely independent of the
> distribution technology; it knows nothing of CORBA, meaning I can change
> the distribution model to RMI or XML/HTTP or whatever, without touching
> the domain layer.

> The CORBA object implementations are dependent upon the domain objects.
> As a rule of thumb, I have one IDL interface and hence one corba class
> for each abstract base class in the domain model (although I also make
> extensive use of structs for efficiency).  Each corba object delegates
> to the corresponding domain object or objects.

> The consequences of this are a large number of active objects on the
> middle tier.  I don't consider this too heavy a price as the number of
> active corba objects never gets too high (structs are used for high
> volume data, e.g.  populating listboxes in the GUI), and the main speed
> bottleneck is in the distribution break anyway.

> The coding for the corba implementation objects relies heavily on
> delegation/object adapter and therefore tends to follow repetitive
> structures, e.g:

> public class CorbaMyClassImpl extends Module._CorbaMyClassImplBase {

>   // reference to object in domain.
>   private Domain.MyClass _d_myClassInstance;      

>   public MyClassImpl(Domain.MyClass d_myClassInstance) {
>     // new instance of corba object must refer to a domain object.
>     _d_myClassInstance = d_myClassInstance;
>   }

>   public String oid() {
>     // delegate request to domain object.
>     return d_myClassInstance.oid();  
>   }

>   public void attribute(String setting) {
>     // delegate request to domain object
>     _d_myClassInstance.attribute(setting);
>   }  // most setter methods follow this structure.

>   public MyClass2 myAssociation() {
>     // delegate request to domain object, and get
>     // reference to domain object.
>     Domain.MyClass2 d_myClassInstance2 =
>       _d_myClassInstance.myAssociation();

>     // convert domain object to corba object;

1.  structs (it sounds like you are using C++) are identical to public
classes, therefor you have no performance gain.  Are you using the
preprocessor??

2.  what is your question??? :-)

--
Andy L. Czerwonka
Chief Architect
CORBATECH Inc.

 
 
 

Design question: CORBA Object Implementation and Domain Object Models

Post by Chris Mungal » Wed, 26 Aug 1998 04:00:00




>Hi,

>below you are decribing the tie-approach of the Corba-IDL to Java
>Mapping, aren't you?

I have to admit I wasn't aware of the tie-approach.  That's what comes
of trying to learn corba from a C++ book, then trying to transfer the
knowledge to java by speed-reading the docs...

Quote:>If this is true, then the idl-Compiler generates all the classes you
>need. Ok, this approach is not CORBA compliant and one does need a
>compiler that supports the tie-approach, as does OrbixWeb. I heard Suns
>JDK idl2java compiler and Inprises/Visigenics product does so too, still
>I am not sure about that.

I'm using Visibroker, and it supports tie.

I've had a look at the vbj docs and the Orfali java/corba book.  I don't
think tie by itself is enough for what I need to do.

Consider the following generic business object/domain object, which has
getters/setters for a few attributes, one of which is a reference to an
object of the same type (perhaps for representing trees)

public class Entity {

  public Entity(String name, float size) {
    _name = name;
    _size = size;
    _superEntity = null;
  }

  public float size() { return _size;}
  public void size(float size) { _size = size;}
  public String name() { return _name;}
  public Entity superEntity() {return _superEntity;}
  public void superEntity(Entity superEntity)
    { _superEntity = superEntity;}

  private float _size;
  private String _name;
  private Entity _superEntity;  

Quote:}

with the corresponding IDL:

interface Entity {
 readonly attribute string name;
 attribute float size;
 attribute Entity superEntity;

Quote:}

Using the tie approach, I create a class EntityImpl which extends the
above class and implements EntityOperations.

EntityImpl inherits the getter/setter methods for attributes that return
primitive types, so I don't have to write them again, which is nice.

However, for methods that use other domain objects as parameters or
return domain objects, conversions between domain objects and tie
objects still have to be performed.

For the above example:

public class EntityImpl extends Domain.Entity implements EntityOperations {
  EntityImpl(String name, float size) {
    super(name, size);
  }

  // calls the domain object's superEntity_ method and converts
  // the result from domain object to tie object
  public Entity superEntity() {

    // note the modification of domain class method name with underscore
    // so the signatures do not conflict
    return EntityManagerImpl.get((EntityImpl)superEntity_());
  }

  // calls the domain object's superEntity_ method first of all
  // converting the tie object parameter to a domain object
  public void superEntity(Entity se) {
    EntityImpl ei = (EntityImpl)((_tie_Entity)se)._delegate();
    superEntity_(ei);
  }

Quote:}

This also requires EntityManagerImpl to keep a hash/dictionary of all
Entity objects, to avoid creating multiple copies with the same
_tie_Entity.

I can see no way of avoiding these explicit conversions.

Since my domain model contains a lot of cross-referencing, this amounts
to a lot of coding which could be generated automatically.

Are there any free/cheap solutions for this, or am I better carrying on
with my own?

---
Chris Mungall                Bioinformatics Group        

+44(0)131 527 4477           http://www.ri.bbsrc.ac.uk/bioinformatics/

 
 
 

Design question: CORBA Object Implementation and Domain Object Models

Post by Chris Mungal » Wed, 26 Aug 1998 04:00:00




Quote:>1.  structs (it sounds like you are using C++) are identical to public
>classes, therefor you have no performance gain.  Are you using the
>preprocessor??

Errm, I'm using Java.

I was referring to IDL structs.

Quote:>2.  what is your question??? :-)

I'm looking for tools/ways of automatically generating the mapping
between the corba implementation objects and the domain objects

Quote:>--
>Andy L. Czerwonka
>Chief Architect
>CORBATECH Inc.

---
Chris Mungall                Bioinformatics Group        

+44(0)131 527 4477           http://www.ri.bbsrc.ac.uk/bioinformatics/
 
 
 

Design question: CORBA Object Implementation and Domain Object Models

Post by Antonio Carrasco-Valer » Thu, 27 Aug 1998 04:00:00


Chris,
Focusing in :

[] I am developing a 3 tier system using Java and CORBA.  I have
developed

Quote:> a domain object layer which is completely independent of the
> distribution technology  []

And :
[] > My question is: does a tool exist for automatically generating this
[]

I can point you to Java code generation from Component Definition
Language (CDL) of the OMG standard-to-be (someday) BOCA (Business Object
Component Architecture).

We have been targeting Java in the IBM San Francisco framework, and now
Enterprise Java Beans, both with CORBA support (and RMI), from the same
domain specs, and rich semantics.

While the implementation patterns may or not be of the style you
currently prefer, the code generation offered isolates your domain from
the underlying frameworks, and saves you a whole lot of effort.

You may visit :
www.dataaccess.com/dat

And feel free to mail or contact for additional info or feedback.


> I am developing a 3 tier system using Java and CORBA.  I have developed
> a domain object layer which is completely independent of the
> distribution technology; it knows nothing of CORBA, meaning I can change
> the distribution model to RMI or XML/HTTP or whatever, without touching
> the domain layer.

> The CORBA object implementations are dependent upon the domain objects.
> As a rule of thumb, I have one IDL interface and hence one corba class
> for each abstract base class in the domain model (although I also make
> extensive use of structs for efficiency).  Each corba object delegates
> to the corresponding domain object or objects.

> The consequences of this are a large number of active objects on the
> middle tier.  I don't consider this too heavy a price as the number of
> active corba objects never gets too high (structs are used for high
> volume data, e.g.  populating listboxes in the GUI), and the main speed
> bottleneck is in the distribution break anyway.

> The coding for the corba implementation objects relies heavily on
> delegation/object adapter and therefore tends to follow repetitive
> structures, e.g:

> public class CorbaMyClassImpl extends Module._CorbaMyClassImplBase {

>   // reference to object in domain.
>   private Domain.MyClass _d_myClassInstance;

>   public MyClassImpl(Domain.MyClass d_myClassInstance) {
>     // new instance of corba object must refer to a domain object.
>     _d_myClassInstance = d_myClassInstance;
>   }

>   public String oid() {
>     // delegate request to domain object.
>     return d_myClassInstance.oid();
>   }

>   public void attribute(String setting) {
>     // delegate request to domain object
>     _d_myClassInstance.attribute(setting);
>   }  // most setter methods follow this structure.

>   public MyClass2 myAssociation() {
>     // delegate request to domain object, and get
>     // reference to domain object.
>     Domain.MyClass2 d_myClassInstance2 =
>       _d_myClassInstance.myAssociation();

>     // convert domain object to corba object;
>     // factory will either create a new instance, or get the one in use.
>     return (MyClass2FactoryImpl.instance()).fetch(d_myClassInstance2);
>   }
>   // this is a typical way of implementing an association.

> }

> All operations are delegated to methods in the domain layer.  Every IDL
> interface has a corresponding manager/factory, implemented as a
> singleton class.  This is used to fetch sets of objects.  It is also
> responsible for creation of that class of corba object, and keeps a
> hashtable of corba objects keyed by the corresponding domain object's
> OID.

> The above is simplified code to illustrate some typical code, and
> doesn't take into account exceptions or observer/observable
> notifications.

> The coding for all this is very tedious and repetitive.  If Java
> supported multiple inheritance, then I could just make the corba classes
> inherit from the domain classes - as it is, I must use delegation.  I
> have written a perl module which helps out with automatic code
> generation when using delegation.  This is getting unwieldy as I extend
> this to delegating arrays, handling inheritance etc.  It isn't always
> one-to-one delegation, sometimes the design follows the object adapter
> pattern, as the IDL must be more course-grained than the domain model.

> I'm considering converting the perl tool to java and using reflection,
> but feel I must be re-inventing the wheel here.

> My question is: does a tool exist for automatically generating this
> kind of code? I came across Cocobase while evaluating
> object/relational mapping tools - it seems to do something like this,
> but is a little expensive for us. Is it worth my while developing an
> inhouse tool?

> While on this topic, I would also like to ask if there is any
> documentation on patterns for designing IDLs derived from object models.
> My approach here has been to derive heuristics as I go along - for
> example, have an IDL interface for the domain base abstract classes
> only, provide structs as well, provide alternative 'pre-flattened'
> structs that give a view across multiple classes for high volume data,
> make factories for providing datasets of either type...  there are many
> tradeoffs where it is not obvious which approach to use.  One thing I
> have learned from earlier mistakes is that most of it is down to a good
> design in the domain object later; bad design here means very bad IDL.

> If useful, I could provide a document describing this design in more
> detail; first of all I'd like to hear the experiences of others using
> similar designs/patterns. Maybe most people are using the corba
> implementation and the domain model interchangeably and aren't worried
> about re-using business rules in a non-CORBA environment? Or maybe
> most people are using a language with multiple inheritance and are
> subclassing the corba classes off the domain classes, so this isn't
> such an issue?

> Thanks for any comments,

> ---
> Chris Mungall                Bioinformatics Group

> +44(0)131 527 4477           http://www.ri.bbsrc.ac.uk/bioinformatics/

--
My Employers and Customers may not share this opinions, yet.
Antonio Carrasco-Valero    ...  Smalltalk, CORBA and BOCA consultant.
 
 
 

Design question: CORBA Object Implementation and Domain Object Models

Post by Sven Bra » Fri, 28 Aug 1998 04:00:00


Hi,


> However, for methods that use other domain objects as parameters or
> return domain objects, conversions between domain objects and tie
> objects still have to be performed.

I had a short look at your example, only.

Using references of the tie-Object internally and externally is a
solution to your problem, isn't it? If it isn't I have to have another
look at your example.

Generally a Tie-Object represent its Impl-Object.

The Impl-Class does not extend Interface, but _InterfaceOperations.
Therefore one can't put a reference of the Impl-Object in a variable of
type Interface.

The Impl-Class cannot extend Interface, since an Instance of Interface
has to implement org.omg.CORBA.Object which is provided by the
idl-compiler, whereas Impl-Class is not.

Sven
--
Sven Braun            Sven.Braun"at"stud.uni-karlsruhe.de (preferred)
Karlsruhe, Germany    PGP 5.0 PublicKey Fingerprint:
                      5CEB 06B5 E1CF FD80 5914  DCC4 2E33 0EF6 04A4 B015
      commercial mail NOT permitted, unless I explicitly ask for.

 
 
 

Design question: CORBA Object Implementation and Domain Object Models

Post by Chris Mungal » Tue, 01 Sep 1998 04:00:00




>Hi,

Hi

Quote:>I had a short look at your example, only.

>Using references of the tie-Object internally and externally is a
>solution to your problem, isn't it? If it isn't I have to have another
>look at your example.

The problem with this solution is that corba specific code enters the
domain layer / business objects.  I'd like this layer to be independent
of the distribution technology.

Quote:>[snip]
>Sven
>--
>Sven Braun            Sven.Braun"at"stud.uni-karlsruhe.de (preferred)
>Karlsruhe, Germany    PGP 5.0 PublicKey Fingerprint:
>                      5CEB 06B5 E1CF FD80 5914  DCC4 2E33 0EF6 04A4 B015
>      commercial mail NOT permitted, unless I explicitly ask for.

---
Chris Mungall                Bioinformatics Group        

+44(0)131 527 4477           http://www.ri.bbsrc.ac.uk/bioinformatics/
 
 
 

Design question: CORBA Object Implementation and Domain Object Models

Post by Andy L. Czerwonk » Wed, 02 Sep 1998 04:00:00


Use an adapter with a stict semantice.  ie aggregation

--
Andy L. Czerwonka
Chief Architect
CORBATECH Inc.