Entry
Why OSP and not Corba/RMI?
Oct 14th, 2004 07:30
Kalu Ral, Engineer TCSI, http://www.consolidate-loan-student.com , http://www.0-apr-credit-card.biz , http://www.clearpathoverseas.com
Solution Core provides a rich environment that allows developers to
quickly
begin implementing the application functionality without having to
first implement the computing infrastructure and services. This is a
mature platform that has been in use for over 8 years. In addition,
it is targetted specifically for use in Telecom NMS and OSS
applications.
Solution Core consists of several packages. OSP, the Object Service
Package, provides a distributed object environment (an ORB plus
services). CSP, the CORBA Services Package, provides full CORBA
interoperability for OSP objects. PSP, the presentation services
package, provides GUI development support for OSP objects. ATP,
Application templates package, provides telecom specific class
libraries, for example, alarm objects. TSP, TMN services package,
integrates CMIP and distributed objects.
OSP
In addition to the basic ORB functions of providing distributed
objects, OSP provides a number of services, and a base class for
objects (the Application Object or AO) which seamlessly integrates
thsee services. Also, OSP implements development services, for
example,
and error handling facility and a "watcher", which are provided to the
application developer. Today, CORBA products like Orbix provide the
ORB functionality at a level equivalent to what is provided by OSP.
They also provide a subset of the services. A detailed comparison of
OSP versus using Orbix by itself is given below.
Because the OSP services predate much of the OMG work, they are not all
fully compliant with the OMG Common Object Services. However, to
date, very few of the standard object services are available,
and those that are often not integrated with an "AO", requiring manual
coding within each operation to interact with these services. For
example, Orbix now provides an CORBA compliant Event service.
However, if the application needs to receive events about activities
such as an Object Creation or Object Deletion, the server developer
must write code to create and push these events for each object, or
must extend Orbix using Filter or other means to provide this
infrastructure. With the OSP event service, this integration is built
in.
The Object Services inlcude:
Persistence / Memory Management
Concurrency
Event
Query
List
Bulk
Access Control
Scripting
The AO features include:
Lifecycle (generic Create, Delete)
Multi Get/Set
Audit
Dynamic Servers (OSP 5.1)
Development services include:
Logging
Error
Tracing
Operation Timing
Thread Management (OSP 5.1)
These are covered in detail in the following sections.
Services
Persistence and Memory Management
OSP provides a tuned DB interface layer, targetted at storing the
attributes of an AO in an RDBMS. This persistence layer is integrated
with other services, allowing for higher performance. From the
interface description, the code to store the objects in the
DB is completely automated, so the developer can start immediately
writing the business logic of the objects, rather than the code
to interact with the database. In addition, over 8 years of real
life usage of OSP has led to a number of performance improvements,
including server side caching of data, lazy read of complex data, use
of cursor interfaces, etc. OSP based applications have
demonstrated the level of peformance requried to meet the needs of the
telecom industry.
Orbix provides integrations with several OODB products. They also
allow the use of products which work with relational database. This
can be a simple integration with the RDBMS client libraries, or an OO
to RDBMS mapping tool like provided by Persistence or Ardent CRB.
However, Orbix does not make any assumptions about the state of the
objects implementing an interface. Because of this, it is entirely a
manual process to define the schemas and implement the code which
loads objects from the DB and saves them back out.
In addition, OSP provides a memory management policy, which implements
server side caching. With Orbix, a "loader" class provides hooks to
implement such a mechanism, but the default behavior is to delete the
object from memory after each operation, requiring the data to be read
back from the DB the next time the object is accessed. With OSP,
default behavior is to provide a Least Recently Used (LRU) cache of
instances.
Concurrency
OSP provides a Lock service, which allows objects to be locked and
unlocked. This service is a global service, so the client does not
need to worry about sending requests to each of a number of servers to
lock the appropriate object. OSP automatically provides a Context for
each operation, which includes a client supplied lock handle, the
result returned by the Lock reequest. To invoke an operation on a
locked object, the client must provide the correct lock handle, or an
error is returned. This checking is done automatically by the OSP
code in the server.
The CORBA/Services Concurrency specification details how to request
and free a lock on an object. However, there is no mechanism to
enforce that an operation on an object is being performed by a client
with the correct lock. This can be implemented by the application
developer, in each operation, or possibly using an Orbix filter.
But, it requries some care in designing the IDL to make sure
that the lock can be passed to the operation.
Event
The OSP event service allows clients to register interest in certain
events. In addition to supporting application defined events, OSP
also pre-defines events for Object Created, Object Deleted, and
Attribute Changed. The event service is a global service, allowing
for a single registration for events from a number of servers.
The OSP AO infrastructure automatically posts the appropriate event
whenever an AO is created, deleted, or attributes change. These
events are sent even when an attribute is changed as a side effect of
a user defined operation. The OSP event dispatcher (like a channel)
supports filtering based on event source class, source instance, or
event type.
The CORBA Event service allows event consumers to register with an
event channel, and for event suppliers to provide events to the
channel. However, there are no predefined events, for example for
object created. In addition, there is no support for filtering or
a global service. Filtering and global services are provided in the
OMG
Notification Service. However, the Notification Service specification
is not yet finalized, and there are no commercial products available.
Query
The OSP Find service implements a Query service. This leverages the
RDBMS, and allows for attribute based queries of objects. With OSP, a
client simply invokes the service on one of the object servers, and
the DB interactions take place at the object server level. Like
Concurrency and Events, this is a global service, allowing a single
query to return results from many object servers.
To our knowledge, there is no commercial implementations of a Query
service available for Orbix. In general, developers who require this
have utilized the underlying DB for queries. However, this exposes
the database to the clients, and requries that any CORBA client
program also be a database client.
List
The list service is unique to OSP is a high value service which
greatly simplifies the task of building the kind of GUIs expected for
an NMS or OSS. The List service provides a dynamic, paged query
service - Dynamic meanging that the client is notified of changes to
entries in the list, and paged meaning that the client only sees one
page of results at a time rather than the entire list. The target
application is a GUI which is displaying a list of attributes of
objects, and the display needs to be updated automatically to reflect
the current state. Because the screen can only show a certain number
of lines, the IPC traffic is reduced by returning data one page at a
time. The List service is integrated with the OSP Persistence
service, event service, and AO event generation, so a list can be
requested against any AO class implemented by the application
developer without additional development effort.
There is no OMG service equivalent to the List service, and we do not
know of any implementations of similar services on Orbix.
Bulk
For performance reasons, it is necessary to operate on multiple
objects in the database. OSP provides a Bulk operation to Create and
Delete objects, and to get and set attributes of the objects. These
leverage the cursor operations provided by the DBMS, and can be an
order of magnitude faster than doing operations one object at a time.
There is no OMG Bulk operation service specified for CORBA. A full
implementation of the Query service provides bulk operations, but we
do not know of any implementation of this capabiliy for Orbix.
Access Control
The access control service allows the developer to specify a policy
for which clients can access which objects. Orbix provides a
Security service, which provides a similar capability. However, TCSI
is not aware if these services allow for access checking on an instance
by instance level, and what adminstration facilities there are for
implementing the security policies. This area is being investigated
further.
Scripting
OSP provides a script language interface. This is very useful for
testing, and is being extended to support fast development and field
patching. Iona professional services can assist with developing a
script binding for your application, but there are no plans for
product support for scripting.
AO Features
Lifecycle
The AO provides generic Create and Delete methods, so that when an AO
is defined, there is automatically an interface to allow instances to
be created. The CORBA Lifecycle service defines a pattern for a
Factory object, but these must be defined and implemented by the
application developer for each interface supported. The CORBA
Lifecycle service also defines an interface to delete objects. Iona
does not provide a Lifecycle service, so this must be implemented by
the application developer. In addition, there is some complexity in
implementing this in a multi-threaded environment, to make sure that
an object does not get deleted while in the process of executing an
operation on a different thread.
Multi Get/Set
The AO provides operations to Get and Set multiple attributes in a
single IPC invocation. For objects with many attributes, this can be
much more efficient than the CORBA approach of doing a separate
invocation for each attribute.
Audit
OSP provides hooks which allows the application to audit any operation
that is invoked. With Orbix, this can be provided by the Filter
mechanism, with the caveat that the tie approach must be used to allow
for filters for local calls.
Dynamic Servers
OSP 5.1 provides a feature that enables the objects in a server to be
modified without requiring code generation, coding, or linking. By
updating the interface description, the developer can define new
classes, new attributes, and new operations. In addition, either
static or dynamic operations can be defined as being implemented in
the script language rather than in C++. This allows for highly
configurable applictions to be implemented, for example, a
Surveillance system in which the attributes of the alarms are defined
from a configuration file rather than compiled in.
Development Services
OSP provides several development services which can be leveraged by
the application developer. Specific to the ORB is the thread
management, which is provided in OSP 5.1. For acceptable performance
in a distributed system, it is necessary to either implement
non-blocking calls or use multi-threaded processes. OSP currently
uses non-blocking calls, but will be providing support for
non-preemptive multi-threading in 5.1. By using non-preemptive
threads, the developer does not need to worry about thread safety
issues, and can utilize 3rd party libraries that are not thread safe
without having to write wrappers for each API that is used. OSP
implements a pool of threads, and re-uses them for each invocation.
Orbix provides a filter which allows for a multi-threaded server to be
implemented. However, the management of the thread pool, and any MT
locking schemes must be implemented by the application developer.
AO Integrated services
The integration of the AO with the services has been presented in the
discussion of the services. In summary, the OSP infrastructure
supporting an AO interacts with the concurrency service to check if
the object is locked, and if the client is passing a compatible lock
handle. It also checks if the object is busy, so either with the
current non-blocking model, or the OSP 5.1 thread model, the
application developer does not need to worry about mutexes to control
access to the object data. The memory manager pages in the AO from
the database if it is not resident in memory. The access is checked
to verify that the client is authorized to invoke the operation.
After the operation completes, an event is generated if necessary, and
the results are written out to the database. Also, the audit method
is called, allowing the application to log auditing information.
Finally, the DB representations of the AOs are accessed by the List,
Bulk, and Find services, without requiring additional coding by the
developer.
CSP
The Corba services package provides complete interoperability between
OSP and Orbix. CSP allows OSP objects to be accessed as CORBA objects
by any other CORBA client, and allows other CORBA objects to be
accessed from OSP servers. This is done in a high performance manner,
integrating the IIOP messages directly into the OSP server, so there
is not the additional overhead of a gateway process.
Of course, interoperability with Orbix is provided if implementing
directly on Orbix. Note however, that the same is not true of general
CORBA interoperability, there are several problems remainging that
prevent full interoperation between Orbix and other CORBA ORBs.
PSP/Motif, RPG
The current OSP GUI supports Motif GUI development. The RPG tool
generates the GUIs based on the object model. This allows the
developer to get a working system running with a GUI in a matter of
several hours. In addition, the GUI is integrated with the OSP
services, so that for example when an event indicates that the object
has changed, the GUI will automatically be updated. A List element
is integrated with the List service, and provides a GUI display of the
data from the list service, with automatic updating based on List
events. In addition, the GUI includes a map library.
PSP/Java
The PSP/Java product, due out in 3Q 98, provides Java Beans for the
OSP provided services, and an integrated map. This allows a developer
to use a high productivity Java IDE such as Symantec Visual Cafe to
rapidly build highly customized GUIs which interact with the OSP
objects and services.
ATP
ATP provides additional support for telecom applications. It includes
pre-built class libraries for Alarms, Trouble Tickets, Event Logging,
Hierarchical Maps, and efficient Alarm State Propagation. The OMG
Telecom Domain Task Force is currently defining standard IDL and
services for these features. However, the standards are not complete,
and to our knowledge, there are no commercial implementations of these
types of classes available for Orbix.
TSP
TSP provides a full integration of OSP with CMIP. Starting from GDMO,
the developer generates a communications gateway and a set of AOs.
These AOs provide a standard OSP interface for the application
developer, but implement the behavior by executing the CMIP
operations. This frees the developer from having to know about CMIP
in order to interact with the network devices. In addition, TSP
extends the OSP data types to support ASN.1, allowing the GDMO model
to be used as the internal data model.
Several companies are currently working on CMIP to CORBA mediation
products that will work with Orbix. We do not believe any of these
are yet commerically available.