Apunte curricular sobre el bloque de contenidos de análisis matemático en 1º de

IDL permits an operation to be declared as oneway:

interface Events {

oneway void send(in EventData data); };

Intuitively, oneway operations are intended for building unreliable signaling mechanisms with semantics similar to UDP datagrams (the send-and-forget approach). A oneway operation must adhere to the following rules.

It must have return type void.

It must not have any out or inout parameters. It must not have a raises expression.

These restrictions exist to disallow any traffic in the return direction from server to client. Because user exceptions are return values in disguise, they are included in the preceding list of restrictions. However, oneway calls may raise system exceptions.

Oneway operations have "best effort" semantics. This means that oneway calls may not be delivered but are guaranteed to be delivered at most once. Beyond this, the CORBA specification says nothing about the semantics of oneway. For example, an ORB that simply drops every oneway call on the floor is a compliant implementation. (Its best effort happens to be a very poor one.) Conversely, an ORB is entitled to simply ignore the oneway keyword and to dispatch oneway calls in the same way as any other call. (That ORB's best effort is a particularly good one because oneway calls are as reliable as ordinary calls.)

The CORBA specification makes no other guarantees. In particular, the specification does not guarantee non-blocking behavior, does not guarantee asynchronous call dispatch, and does not even guarantee that oneway calls will be received in the same order as they were sent. Do not create designs that assume either non-blocking or asynchronous behavior just because operations are declared oneway. The actual behavior at run time of such calls depends on the ORB and typically also depends on whether client and server are threaded and whether or not they are collocated.

IDL defines interfaces, but oneway has nothing to do with the interface of an operation. Instead, it influences the implementation of the operation's call dispatch. As you will see in Section 7.13.1, the C++ interfaces for oneway operations are identical to those of normal operations, and it is possible to invoke a normal operation as if it had been declared as oneway by using the Dynamic Invocation Interface. This indicates that oneway is really an implementation concern and should not have been made a part of IDL, because it operates at a different level of abstraction.

The semantics established by oneway are too weak to be really useful, and we recommend that you avoid the feature. If you need to guarantee non-blocking behavior or want to build some form of signaling mechanism, the CORBA Event Service (see

Chapter 20) is likely to be a much better choice. It has defined semantics and avoids the uncertainty associated with oneway. (The CORBA Messaging specification [20], adopted in 1998, has added features that permit you to control the semantics of oneway

invocations in more detail. However, ORB vendors are unlikely to offer implementations before mid-1999.)

4.13 Contexts

Operation definitions can optionally use a context clause. For example:

ValType read_value() context("USER", "GROUP", "X*");

The context clause must contain one or more string literals, starting with an alphabetic character and consisting of alphabetics, digits, period (.), underscore (_), and asterisk (*). An asterisk can occur only as the final character.

A context clause permits one or more values to be made available to the server implicitly with a call. The idea is similar to UNIX environment variables, in which a child process automatically inherits the environment of its parent. The preceding declaration states that when a client calls the read_value operation, the values of the client's context variables USER and GROUP, and the value of all context variables starting with X, will be made available to the server. CORBA defines a Context interface that allows you to connect context objects into defaulting hierarchies, something that creates a more powerful mechanism than just a single vector of variables.

If a particular context variable is not set by the client, its value is (silently) not transmitted to the server.

This means that the server cannot rely on the value of a particular context variable being available even though it appears in the context clause.

Context variables are untyped.

For the preceding example, the server may expect to find a numerical user ID in the

USER variable. However, the client may have placed the user name into the variable. This illustrates that context clauses provide no guarantees to the server implementation. A context variable may not be set at all, and, even if it is set, it may contain a string that does not correctly decode to the expected type. This is a recipe for disaster because it shoots a big hole through the IDL type system. CORBA implements strict type checking for operations, and that makes it impossible for a client to forget to supply a parameter or to supply a parameter of the wrong type.[3] In contrast, context variables provide no such guarantees.

[3] _{It is possible to violate the type system by using "sledgehammer" C++ casts. However, if}

you insist on using casts, you deserve what you get. It is also possible to violate the type system by using the DII incorrectly, but that is the price of its flexibility.

Because IDL contexts are unsafe, we recommend that you avoid using them. It is also possible that contexts may be removed from CORBA, so the future of this (mis)feature is uncertain anyway.