interfaces in IDL. In a conventional CORBA system, an application communicates with local and
remote service objects by way of the ORB. In Bionic Buffalo's U-N system, the application
communicates with service objects which implement the U-N protocols. The client normally doesn't
see U-N server objects directly, or vice versa. Instead, the remote objects are seen only through the
services of local objects. Thus, Bionic Buffalo's implementation of U-N is similar to that of U-U
implementations which use proxy objects:
CORBA it is also possible with Bionic Buffalo's product to communicate directly with remote objects.
In other words, it is possible to have application - local ORB - remote ORB - remote U-N object - U-N
protocol - differently-remote U-N server. This feature isn't expected to find normal use, but rather
value in support and development situations.)
considered here) define the over-the-wire interaction, but don't define an API for applications. They
define protocols, not objects. To implement SSP and LSCP, Bionic Buffalo uses local and proxy
objects.
the same as used for basic U-N:
dialect. (A modification wasn't, strictly speaking, necessary. However, it makes the API easier to use.)
The same objects, with the same API, can be used for basic U-N, as for the SSP dialect.
defines a client-server protocol. The playback engine embodies the same state machine as does a
operations not directly related to playback and the state machine, such as those for access control,
security, and event management. Where Pegasus has equivalent functionality, these are handled in
different ways.) The data formats, such as the one used for time and the time base, are a little different
between Pegasus and DSM-CC. Altogether, the differences are slight enough that the API representing
the
object to implement LSCP. The model is