(Part of the CORBA FAQ, Copyright © 1996)
[Recently added first paragraph and spelled lifecycle correctly (7/1997). Click here to go to the next FAQ in the “chain” of recent changes]
Oh, yes. Lots of good stuff.
CORBA defines roughly 15 different services. These services augment the basic CORBA architecture. These services are horizontal application services. They apply to different types of applications. These include naming, events, lifecycle, transactions, security, persistence, etc. Application functionality can be greatly enhanced by leveraging available services. At one level, the basic CORBA architecture provides distribution of objects. Implementing the objects is left up to software developers. The CORBA services represent a set of pre-implemented distributed objects that software developers will typically need.
[ Top | Bottom | Previous section | Next section ]
[Recently added first paragraph (7/1997). Click here to go to the next FAQ in the “chain” of recent changes]
Because it is the most flexible and easy-to-use way to find and use objects.
The CORBA name service provides a mechanism to obtain an object reference. Applications first obtain an object reference to a name context. This might occur by calling ORB::resolve_initial_references(“NameService”). Once obtained, applications can call the resolve() operation on the name context. The call to resolve will return an object reference to from a logical name. This assumes that a distributed object has been named within the name context. Once the application obtains the object reference they can make distributed invocations of operations on it. By using the name service to obtain object references, applications do not need to concern themselves with the actual location of a distributed object.
[ Top | Bottom | Previous section | Next section ]
[Recently spelled lifecycle correctly, added first paragraph (7/1997). Click here to go to the next FAQ in the “chain” of recent changes]
To handle the messy but essential administrative aspects of working with distributed objects.
The CORBA lifecycle service allows an application to request the ORB to create, destroy or move and object within the network. Applications can create or destroy objects explicitly or implicitly. Objects can be created or referenced by application factories. The CORBA lifecycle service allows applications to explicitly create or destroy distributed objects in a standard fashion.
[ Top | Bottom | Previous section | Next section ]
[Recently added first paragraph (7/1997). Click here to go to the next FAQ in the “chain” of recent changes]
Because you will need it sooner or later, and it’s no fun writing your own.
The CORBA event service provides a framework, in the form of an IDL interface, to support notification of events between applications. Events are generated and responded to at a coarse grained level. The event service relies on a “channel” to manage creation of and response to events. Applications are aware of every event that occurs on a given channel. The event service is anonymous. This means that an application might be notified of an event on a channel but the application will not know the origin of the event.
[ Top | Bottom | Previous section | Next section ]
E-mail us