From: Manfred M. <man...@gm...> - 2001-11-07 21:24:16
|
Hallo Eric >A stub usually refers to something that something is normal base of >something with more to be connected with it...a little bit of a bad example, >but a person with a missing arm has a stub where the full arm was once >connected..an artificial arm can be attached to the stub where the origi= nal >arm use to be. > >In programming, I believe this is were a basic interface is made which i= s >built upon...there maybe other interpretations as well. In Client/Server programming, a stub is a "thing" on the server side, whe= re a client will connect to. >>The client receives some information about this object. The >>object ID and the Visum. > >And on the client, this is stored in what class? Is this the same >class that is on the server? It is (logically) stored in the stub object for the client object. >So no identification of possible methods that can be performed on the object >are presented? Or are these method/procedures defined else where and ar= e >assumed to be known by the user of the object? No identification of possible methods that can be performed on the stub object are presented. The client knows his stub on the server side and is unable to request other methods than his RMC enalbed methods (he already knows) on the server side. >I guess what I am saying, is (and taking from UDDI and related standards= ), >you advertise the methods that can be executed on the object...and then >based on the interface to the object, use these methods. I'm not sure if I'm able to translate this correct, but I hope so. RMC do= es not explain anything about RMC enabled objects, neither over the net, nor against a application. >>The client uses the (_his very own_) remote object to access whatever t= his >>remote object will be able to access on the server site. Further, the > >client > >>object is allowed, to initiate the deletion of his stub. This will be d= one >>automatically in the destructor in the client sided object >> (=3D proxy object). > >Is (_his very own_) object on the client with the client application whi= ch >has a corresponding version on the server, or is it located only on the >server, accessible only through remote procedure calls? Each client object (proxy object) has it's _very own_ server object (stub object). >In other words: > >Client: > - Client Application (say an Chat application) > - Client Object (say a output Window[On Client] for the client) > * links to Client Object Stub > * object attributes > * object methods/procedures > - (the connection between client and server) The window object on the client side should use a communication object to communicate. This is for better structure af the cl=F6ient application an= d for better cross acces, because application windows are typical GUI dependend= , and server will (1) Not open any windows on the server side (2) Not run the same OS, the same GUI or anything other related to the GU= I >Server > - Object Factory > - Client Object Stub (output Window[On Server] for the client) > * links to Client's Client Object > * object attributes > * object methods/procedures > - Server Application (chat server which links chat clients) > + Chat Area Object > * object attributes > * object methods/procedures As suggested above, server objects has no use for any window. >When client makes a request to update the output Window[On Client] local= ly, >say with a Window[On Client].update("Hello World");, the method call is >called, then the the remote request is passed to be handed to the server >(maybe in a message queue or something) by the link between client serve= r >(RMC I'm guessing), makes a window[To Server].update("Hello World"), whi= ch >is received on the server, executed on the server as Window[On >Server].update("Hello World"), and finally possibly give them some retur= n >status information or return object information. Right, but the "window problem". > > (6) When a request is made by the client with a remote call to the > >server, > >> There is no previously existing object. The Stub object exists or not. >> Remember: The client application does not (need to) know, that an obje= ct > >on the > >> client site ist remotely connected - this is completely transparent fo= r > >the > >> application. The client application only uses objects, some may be > >connected to > >> a remote facility, some not. Remote calls are initiated by the methods= of > >an > >> RMC enabled object. And this object has a stub on the server site. > >But on the client side, a local object is present to allow access to the >object on the server...right? Or is this just a pointer to something in the >mechanism that links the remote object to the local object. There has to be a client sided object to access a server sided object. If the client sided object terminates, the server sided object terminates to= o. >I can see that when the object factory creates an object, it may return = a >pointer or reference to the object which is used by the client which wil= l >seem invisible to the local client based client application...right? See this value as "unique identifier of the serversided object". It will change it source and contents . >>A second and third client object registers and get new stub objects, ea= ch >>for his own. No client object does know anything about any other client >>object >>connected to the server. Each client object feels allown with his serve= r >>representant. And no one else as a specific proxy object knows or has >>access to the matching stub object. > >This still doesn't seem very practical in a database or object oriented >nature...If you are >creating a user interface and want the interface to communicate via a window >object (this is >just an abstract window object not 2d or 3d based), then you will have >multiple threads interacting >with that window object...say several buttons are part of that window >object, and when you press one >button it minimize the window and another it maximizes it...what if both are >at the same time? What happens? This is a problem for your application, that is to be solved in a way you have to solve it - if you are RMC'd or not. A clean software architecture will not allow Buttons to acces a record in a database. There are lots of models, like Document/View or Document/Object modell, to design your application. Look at your RMC-class as if it were your Database-API - thi= nk it's your ODBC-driver, if this is easier to you. The functionality to wor= k like a ODBC-driver has to be inserted to your RMC-class-pair by any you o= r programmer, but I think, the image from a RMC-object as an ODBC-driver is close to the theoretical truth. You may instanciate 100 client objects - but you have to be aware, that y= ou may deathlock your application on this way - as if you create a deathlock= on a local database using ODBC by using concurrent threads. >Okay, so Client2 registers, and has a Window2 Object which is on the ser= ver >and the client..now the 1 or 3 client can't access this because it is no= t >included in any way to have a way of interacting with it.. > >Do we have on the server a global Chat Area Object, that both Client1 an= d >Client2's Window Objects are a part of, then any changes which are part = of >the Client1 or Client2 Windows are passed to Chat Area Object which in t= urn >is based to everyone that is viewing the Chat Area Object? Yes, if the server is designed to provide interaction between remote objects, he needs anything "global" inside itself and some mechanisms to handle it. So, you can say: Remote object are able to interact each with = the other in the case, the server has implemented it. Remember, RMC is a "remote methode call" mechanism, not an application framework. RMC transports your object calls to other objects anywhere in = the net and let they do for what they are programmed. And RMC only handles th= e call and manages the instanciation and deletion of these objects. The mission of these objects, the services these objects and/or there server will provide is up to you. >> Chat-Demo / global Text-List > >So how is that permission to access the IRC-string list (say a global >object) given? > >Does the server application, take a reference to a client stub when the >client application >registers with the server application, which creates the link? The stub object lives in the server, the server may be programmed, to giv= e the stub object access to the text list. This is up to the programmer. In our sample, the text list is global in the server, so any RMC server obje= ct is able to access it freely. This is no security or stability problem, becasue server objects are full trusted. Which is an great advantage agai= nst CORBA and related. >SO are you saying there are RMC objects and transport objects? What is = the >difference? An RMC object is an object that is splitted in two parts, the client part and the server part. The client part resides in the client application an= d the server part resides in the server application/service. There is no mo= ve in this construction. A transported object resides anywhere and is movabl= e. The RMC mechanism provides the transport for transportable objects, but t= o drive them, you need any matching runtime environment. >Where is the proxy object again? Is this on the client? So the Proxy a= nd >the Stub are linked? The proxy is the thing that will connect to the stub. Because the stub is= in the server, the proxy is in the client. >Sorry, haven't looked in the code for a while...and forgive me if you ar= e >familiar with this but, are you using templates in C++?? yes >I seem to recall, with templates, you implement an abstract class and th= en >basically >substitute the actual variable type, which implments the real class usin= g >the specified variable class... This is, how templates work - but at compile time, not at runtime. >In otherword I make a link list abstract class (it is probably not reall= y an >abstract, i just >can't remember the real term for it), which then gets instanciated as li= nk >list using int for the >object that is contained by the linked list.. dependend on how you mean it, this is what RMC does over the net =3D polymophism. Greetings, KM ------------------------------------------------------- |