The Orbix doc does not really explain how callback works.
I recommend you to take a look to the OrbixWeb doc.
http://www.orbix.com/Products/Orbix/OrbixWeb/doc/pguide/callback.html
It's for the Java language, but you'll be able to map it easily to C++.
regards,
--
_______________________________________________________________
(______________________________________________________________()
| Cyril Bouteille (bout...@essi.fr) Sophia-Antipolis
| Student at ESSI (Ecole Superieure en Sciences Informatiques)
| Intern at DEC (Digital Equipment Corporation)
| HomePage: http://www.essi.fr/~bouteill Nickname: Hicks
|______________________________________________________________
We have implemented model-view mechanisms using Sunsoft's NEO, and it seems
to work quite well.
Anirban Sharma
ani...@gte.net
Cyril Bouteille <boute...@taec.enet.dec.com> wrote in article
<33CE3A...@taec.enet.dec.com>...
paul
--
Paul Jenkins Voyager(tm)
pjen...@objectspace.com Agent-Enhanced ORB for Java
http://www.objectspace.com Free for commercial use
Michi Henning <mi...@foxtail.dstc.edu.au> wrote in article
<Pine.OSF.3.95.970721...@foxtail.dstc.edu.au>...
> On 20 Jul 1997, Anirban Sharma wrote:
>
> > You should be able to use one-way calls or event channels to notify the
> > view about a change in the attributes of a model. The view can then
call a
> > method synchronously(default) or asynchronously(oneway) on the model.
>
> Be careful making assumptions about the behavior of oneway calls to avoid
> blocking or deadlock. There is *nothing* in the CORBA specification that
> obliges an ORB to implement oneway calls asynchrononously.
>
> All the spec says is that these calls have "best effort" semantics.
> To illustrate, an ORB that tosses every oneway call into the bit bucket
> is a compliant implementation (its "best effort" happens to be
particularly
> poor). An ORB that dispatches oneway calls synchronously also is a
compliant
> implementation (its "best effort" is particularly good because the
> client-side stub doesn't return until the call is received by the
server).
>
> The spec simply makes no statements as to whether the client calling the
> operation may or may not block.
>
> If you rely on oneway calls not to block you, you are relying on an
> implementation artifact of your particular ORB, and your code may not
> exhibit the same behavior with a different ORB.
>
> Cheers,
>
> Michi.
> --
> Michi Henning +61 7 33654310
> DSTC Pty Ltd +61 7 33654311 (fax)
> University of Qld 4072 mi...@dstc.edu.au
> AUSTRALIA
http://www.dstc.edu.au/BDU/staff/michi-henning.html
>
Hi,
take a look at the 'caching' demo. Note that it combines both smart
proxies and callbacks. This is because callbacks are almost always
needed when using smart proxies to maintain the valid state of the
cached data.
Regards,
Sam.
Please take a look at
http://www.cs.wustl.edu/~schmidt/report-doc.html
There are a series of columns that Steve Vinoski and I wrote for the
C++ Report on the topic of callbacks in CORBA.
Doug
--
Dr. Douglas C. Schmidt (sch...@cs.wustl.edu)
Department of Computer Science, Washington University
St. Louis, MO 63130. Work #: (314) 935-4215; FAX #: (314) 935-7302
http://www.cs.wustl.edu/~schmidt/
Often for the same reason that people build systems on top of IP or
UDP, i.e., by providing a higher-level reliability scheme.
++ I would not think that a oneway message would *ever* block
++ in a synchronous fashion.
You might think that, but you'd be incorrect. The main issue is that
the CORBA spec. doesn't define what happens if the underlying
transport (i.e., TCP) encounters flow control. Most implementations
of CORBA over TCP will block in this case.
> if that is true (your statement about oneways - which i am assuming is
> correct) then *WHY* would you ever use a oneway, the semantics of the call
> are undefined. I would not think that a oneway message would *ever* block
> in a synchronous fashion.
The problem with oneway is that it was specified in a deliberately loose
way to avoid constraining different ORB implementations. Also, with TCP
as the underlying protocol, getting true oneway calls is difficult
(you may block if the transport buffers fill up). In that case, the only
way to avoid blocking is to dispatch the call in a separate thread. However,
not all platforms and ORBs support threads.
Once we have a UDP-based protocol, oneway can be implemented as a true
asynchronous dispatch.
When you think about it though, adding the oneway keyword to IDL was a
silly idea in the first place. IDL is an *interface* definition language,
and oneway has *nothing* to do with an object's interface (only with
the method of call dispatch). This is evidenced by the fact that you
can dispatch a non-oneway call through the DII as if it was oneway.
In other words, oneway is at a totally inappropriate level of abstraction.
It simply doesn't belong into IDL because it deals with *implementation*...
Guess that is why they call them oneway and not async then? Seems to me
(and to a previous poster as well) that oneways aren't very useful in CORBA
systems, is that your opinion as well? I guess it goes back to CORBAs
least common denominator theory wrt threading and implementation
requirements. interesting....
paul
I too am interested in finding an answer to this question. I'm
using Sun's Neo 2.0 version of CORBA, however.
Rolf Behrsing
RHBeh...@lbl.gov
Rolf Behrsing wrote:
Here is a small test in VisiBroker:
// Callback.idl
module Callback
{
interface ClientObject ;
interface ServerObject
{
void call( in ClientObject client ) ;
} ;
interface ClientObject
{
void callback( in string msg ) ;
} ;
} ;
// eof
// ClientObject.java
public class ClientObject extends Callback._sk_ClientObject
{
/** Construct a transient object. */
public ClientObject()
{
super();
}
public void callback( java.lang.String msg )
{
System.out.println( "Message from the server : " + msg ) ;
}
}
// eof
// ServerObject.java
public class ServerObject
extends Callback._sk_ServerObject
{
/** Construct a persistently named object. */
public ServerObject(java.lang.String name) {
super(name);
}
public void call( Callback.ClientObject client )
{
client.callback( "Hello client!" ) ;
}
}
// eof
// Client.java
public class Client {
public static void main(String args[])
{
try {
// Initialize the ORB.
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();
// Locate the server object.
Callback.ServerObject server =
Callback.ServerObjectHelper.bind(orb, "Server");
// Create the client object.
ClientObject client = new ClientObject();
// Call the server.
server.call( client ) ;
}
catch(org.omg.CORBA.SystemException e) {
System.err.println(e);
}
}
}
// eof
// Server.java
public class Server {
public static void main(String[] args) {
try {
// Initialize the ORB.
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();
// Initialize the BOA.
org.omg.CORBA.BOA boa = orb.BOA_init();
// Create the server object.
ServerObject server = new ServerObject("Server");
// Export the newly created object.
boa.obj_is_ready(server);
System.out.println(server + " is ready.");
// Wait for incoming requests
boa.impl_is_ready();
}
catch(org.omg.CORBA.SystemException e) {
System.err.println(e);
}
}
}
// eof
Regards,
Dragan
--
-------------------------------------------------------------------
Dragan Nedeljkovic Rogers Wave
dra...@netcom.ca Toronto, Canada
--------------4B87112D86F47597AEE63033
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dragan Nedeljkovic
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Dragan Nedeljkovic
n: Nedeljkovic;Dragan
org: Rogers Wave
email;internet: dra...@netcom.ca
title: consultant
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
end: vcard
--------------4B87112D86F47597AEE63033--
Its particularly irritating when some ORBs do handle oneways as asynchronous
operations over a range of different network protocols but this is seen as a
disadvantage because it is not portable. Ho hum.
It is possible that the Messaging Service will address this, but some of the
responses to the RFP seem to imply the use of third-party MOM products, which
to me seems inappropriate for what should be a core (and universal) piece of
CORBA functionality.
On the subject of whether "oneway" should be in IDL at all, my problem with it
is more that it introduces an asymmetry between client and server - shouldn't
there be an equivalent indicator for async method calls from server to client
since the client/server relationship applies to a "transaction" between two
processes, not to the processes themselves ?
I know there are various discussions at the OMG at the moment as to how to add
semantic (is that the right word here ?) information in terms of, for example,
Quality Of Service parameters, and whether this should be done by extending IDL
or by having a higher-level design tool which generates IDL or whatever.
Perhaps the async/sync decision will end up as an effect of specifying such
parameters rather than as a separate decision by the implementor.
--
Roger Barnett
Real Objects Ltd, Leamington Spa, England
email: ro...@realobj.co.uk OR ro...@natron.demon.co.uk
Web: http://www.oot.co.uk/
http://www.iona.com/Products/Orbix/OrbixWeb/doc/pguide
I think you could find similar references for C++ manuals on this site
too.
Marcus
> > How do we implement callbacks in CORBA. All I have is ORBIX manuals. I
> > am afraid I did not find help there. Any pointers to reading material
> > and code samples will be greatly appreciated.
>
>
> I too am interested in finding an answer to this question. I'm
> using Sun's Neo 2.0 version of CORBA, however.
>
> Rolf Behrsing
> RHBeh...@lbl.gov
>
Marcus Hasslinger
Bachelor of Computing (Honours) Student
Monash University (Caulfield Campus)
Phone: +061 (03) 9903 1470
Email: marcus.h...@fcit-c1.monash.edu.au