WHEN
DO I NEED A SERVICE LIKE NOTIFICATION?
It depends
on what your business requirements dictate. We can see a need for Notification
in a scenario where you are interested in receiving certain information which
another source owns.
The example that
always comes to mind is the stock market. Information about stocks flows
rapidly, and frequently. This information can be supplied through a
Notification channel to which many consumers can register their interest in
certain stocks. As new information about the stocks is collected, a supplier
can push that information to the Notification channel which will pass this
information to all the interested consumers on that channel.
There are
many more examples but the bottom line here is that it can be used in a variety
of scenarios and they will have to be analyzed to see where Notification fits
in.
HOW
DO I DEFINE NOTIFICATION EVENTS?
Notification
events are defined using standard IDL. There are two types of events:
Structured
Events
Untyped
Events
Structured
events provide a well-defined data structure into which messages can be
inserted and sent to interested consumers. Messages can be defined using
standard IDL structs and provide,
both consumers and suppliers, with a much strongly typed event. In addition, a
sequence of these events can be transmitted between suppliers and consumers
that can increase the efficiency of communications between them. With the
sequence you can batch any number of events and trasmit
them all at once.
Structured
Events can constain all IDL types that are defined in
the standard IDL. Here’s an example:
struct
Message
{
long messageType;
string messageBody;
};
typedef
sequence<Message> MessageSeq;
Suppliers
would fill the contents of this messages and supply them to interested
consumers that have registered with the notification channel.
The untyped event is simply a CORBA::any into which the event
is inserted and sent to consumers. So the above example can be inserted into
the CORBA::Any type and sent to any consumers on the channel.
CAN
I FEDERATE NOTIFICATION CHANNELS?
Yes. You
will have to do this within your program but the concept becomes clear once you
have done it. The way you do the federation is to create two channels and
essentially connect them together logically. The consumer proxy of one channel,
channel A, is supplied to the supplier proxy of the other channel, channel B.
The reverse is done with the supplier proxy of channel B where it’s exchanged
with channel A and voila we are now federated.
So
essentially what you have is a channel that becomes a consumer and which will
forward the events to its consumers.
WHAT
IS THE PURPOSE OF THE LIFECYCLE SERVICE?
The basic
purpose of the Lifecycle Service is to provide basic capabilities to CORBA
Objects, such as the ability to create, copy, move and destroy themselves. More
than any other service, the Lifecycle Service is tied to the actual ORB
implementation used to provide CORBA support.
WHAT
IS THE PURPOSE OF THE OBJECT TRANSACTION SERVICE?
The OTS
provides a mechanism for distributed CORBA Objects to participate in a
distributed transaction through a two phase commit protocol.
WHAT
IS THE PURPOSE OF THE COS TRADER SERVICE?
The Trader Service
was designed to provide access to CORBA objects based upon capabilities as
opposed to name or interface type. The Trader Service is a factory since its
purpose is to return other CORBA Objects. Unlike the Naming Service, a global
name or identifier is NOT used to specify the CORBA Object to return. The
Trader Service has been likened to the Yellow Pages, while the Naming Service
is more like the White Pages.
WHAT
IS THE PURPOSE OF THE PERSISTENT OBJECT SERVICE?
The
Persistent Object Service was designed to provide two things:
A database
like access to CORBA objects. This provided CORBA clients with IDL control
interfaces to a CORBA object’s underlying storage.
A means for
CORBA objects to uniformly save their state into a database. This was an internal
API for implementation objects (the objects that really have the state) to save
their data into a database.
The
Persistent Object Service was not widely received and potentially never
implemented by any vendor. As a specification, it has been retracted. The Persistant State Service (PSS) superceedes
the POS.
WHAT
IS THE PURPOSE OF THE PERSISTENT STATE SERVICE?
The
Persistent State Service (PSS) is designed to be a CORBA-friendly form of
persistence management. The PSS superceeds the POS.
Unlike the
POS that attempted to provide both a client IDL interface for persistence
control and a server-side layer for allowing CORBA implementation objects to
save their state, the PSS focuses on only the latter.
At a
high-level the PSS is an IDL defined abstraction layer of data storage. It
needs to be implemented for a particular datastore,
such as a file system, a relational database, or an OODB. This allows CORBA
implementation objects to be abstracted from their storage mechanisms, much
like ODBC/JDBC abstract relational databases.
No comments:
Post a Comment