[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Re: Leightweight Components vs. Monolithic Server
From:       flynn () lure ! u-psud ! fr
Date:       2001-04-20 7:42:50
[Download RAW message or body]

On Thu, Apr 19, 2001 at 05:21:20PM +0200, Thomas Förster wrote:
> On Thursday 19 April 2001 13:34, Gerard wrote:
> > On Thu, Apr 19, 2001 at 09:38:31AM +0200, Thomas Förster wrote:
> > > So the question seems to be
> > >
> > > Do we want to implement a server which can do everything or should there
> > > ....
> >
> >   Actually my view of what libkuml should be is just a sort of bag of
> > components which implement CORBA interfaces (some OMG defined, others
> > specific to kuml).
> >
> >   If the only interactions between these components is via the CORBA
> > interfaces then there's nothing to require them all being implemented in a
> > single monolithic process.
> 
> Thats exactly the point and perhaps I just misunderstood your ideas. But I 
> think "library" isn't a good description. At least if you compare it to a 
> "normal" library.
> 
> >   As for the clients they can be anything you want from a full featured GUI
> > app like kUML itself to a small Python script but the basic philosophy is
> > that the essential application logic belongs in components which provide
> > CORBA interfaces so that they can be accessed by virtually any program
> > written in a large variety of languages.  The clients, whatever their form
> > are essentially just facades which provide some way for a user to take
> > advantage of the services offered by the component library.
> 
> >   You seem to be suggesting developing some other middleware layer or in
> > any case cross-language API for calling the components.
> 
> Thats right. The only difference between our two models seem to be the way of 
> calling the components. If I understand your idea correctly, there would be 
> some/a lot of facades (singletons mostly?)  implemented in the main server 
> process, which then call the single components. These facades are defined in 
> some CORBA interfaces. For my client to use the facades I have to make a few 
> CORBA method invokations.


  Just for clarification, my use of the word "facade" above was with respect
to the users, the "facades" I was talking about were the clients themselves.  I
could have just said "user interfaces" (not necessarily graphical).

> 
> Well, my main goal was splitting the server in several distinct components. 
> This will happen in any case, so this is just a question of the components 
> API now. I have no objections against using only CORBA interfaces. I only 
> wonder, if it is necessary to use such a complex technology for those really 
> simple API's as the exports are. It is just 1 method, but I have to know how 
> to invoke methods via CORBA (which itself is really simple but I've also to 
> know about ORB Initialization and Binding)


  I agree with what Chris said about the possibility of a simple client side library
to handle ORB initialization and all of that.  Once things are set up, CORBA is fairly
simple to use because CORBA references have virtually the same semantics as 
pointers to objects in C++.

  Gerard

[prev in list] [next in list] [prev in thread] [next in thread]