Re: Problems with callbacks

The server is already implemented. I don`t have any server source, only what I`ve generated from the idl. There are no *POA or Skeleton files, I have an ServerStub, ServerHolder and ServerHelper but nothing else.

I`ve tought that I have to write an other idl, that holds only the callback interface, and create an server from this source. Than create an inside class that implements the TCClient interface. And then pass the reference to theregister method.
By doing so, there is a POA file created. 

I will trie...

Kind regars

Manuel Fünfrocken

---
University of Applied Science
Saarland/Germany





---------- Original Message ----------------------------------
From: Stefan Blum <[email protected]>
Date:  Tue, 23 Aug 2005 10:39:56 +0200

>Hi,
>
>(sorry, my first replay was not sent to the list.)
>
>Manuel Fünfrocken wrote:
>
>>The server is already given I can`t change anything with it, but the idl already defines the callback interface and the register method.(By the way: I use a nameserver to connect to the server). 
>>The idl: (only a part)
>>
>>  
>>
>
>What do you mean by "the server is already given"? You mean the
>interface and/or the implementation?
>
>>interface CallbackClient
>>{
>>  void data(in String data);
>>  void exit(); 
>>}
>>
>>
>>interface Server
>>{
>> boolean register(in CallbackClient client);
>>
>>};
>>
>>jidl already creates an _CallbackClientStub from that I inherit in my Client_impl.
>>
>>My Question: How could I implement Client_impl as server, without be able  to inherit from server relevatet classes?
>>
>
>Have a look in the manual, "Tie" is the key word.
>
>> 
>>First, I`ve think that the jidl has already created the Stub in a way, that make callbacks possible, but sending an reference of Client_impl (or _CallbackClientStub) to the register method, raises an exception (BAD_OPERATION ).
>>
>>  
>>
>
>The Stub is the client side. What you need is the "skeleton" and the
>"implementation" of the "Client". Beware of not get mixed up with client
>and server.
>Your "Client" has to be also be a server.
>
>Stefan
>
>>Kind Regards
>>Manuel Fünfrockne
>>
>>---
>>University of Applied Science
>>Saarland/Germany
>>
>>---------- Original Message ----------------------------------
>>From: Stefan Blum <[email protected]>
>>Date:  Tue, 23 Aug 2005 09:52:30 +0200
>>
>>  
>>
>>>Hi Manuel,
>>>
>>>Manuel Fünfrocken wrote:
>>>
>>>    
>>>
>>>>I`ve some questions about callbacks: 
>>>>Is it necessary to implement the client as an server? (with starting a POA, binding to a nameserver etc.) Or does ORBacus handle this?
>>>> 
>>>>
>>>>      
>>>>
>>>Yes, you have to implement a callback interface resulting in a
>>>client-server. It seems to be a little bit circumstantial, but keeps
>>>CORBA flexible.
>>>
>>>Do the following:
>>>
>>>// the "client"
>>>interface Callback
>>>{
>>>void callback();
>>>}
>>>
>>>
>>>// the "server"
>>>interface Server
>>>{
>>>void someMethod(); // will invoke Callback::callback() within the
>>>implementation
>>>void registerClient(in Callback Cb); // to store the object reference
>>>}
>>>
>>>the implementation class (servant) of Server contains the object
>>>reference as a member.
>>>
>>>within booting the application:
>>>- start the server
>>>- start the client
>>>- register the client to the server before you invoke someMethod();
>>>
>>>Alternatively, you may use a nameserver. In this case, you can skip the
>>>registerCallback() method.
>>>- start the server
>>>- start the client
>>>- register the client to the nameserver
>>>- in someMethod(): fetch the Callback object reference from  the nameserver.
>>>
>>>I prefer the first alternative, because you only need two "instances"
>>>and no nameserver.
>>>
>>>Isn't too complicated, is it?
>>>
>>>Best regards,
>>> Stefan
>>>
>>>
>>>
>>>
>>>    
>>>
>> 
>>                 
>>
>>  
>>
>
>
 
                 

_______________________________________________
OB-Users Mailing List - [email protected]
http://mail.ooc.nf.ca/mailman/listinfo/ob-users
Visit our support FAQ before you send a message.
http://www.orbacus.com/faq/support.html