Chapter 24  Services not Discussed in this Book

• Persistent State Service (PSS)
• Other CORBA Services and Domain Specifications

This chapter briefly summarizes some of the CORBA Services that are not discussed in this book. Interested readers can find a discussion of some of these topics in other books, articles and Internet resources, many of which are listed in Chapter 26.

24.1  Persistent State Service (PSS)

Many real-world applications require the ability to maintain data in a persistent store. Unfortunately, in such applications, the low-level APIs required to access a persistent storage device, such as a file or a database, are often inter-mixed with the “business logic” code in the application. Furthermore, the APIs for accessing different type of persistent store vary enormously. These factors make it very time-consuming to modify an application that uses one type of persistent storage to use a different type of persistent storage instead. As an example of this, let us assume that you are given the task of implementing a CORBA server that must maintain some data in a persistent store. The development and maintenance of this application might proceed as follows:

1. The data-storage requirements of the application are quite modest so you decide to persist the data in files. The mainline of your server and the bodies of IDL operations are likely to contain a mixture of “business logic” code inter-mixed with code for opening, closing, reading and writing files. When you finish implementing the application, you deploy it and it works well.
2. During the next year, the load gradually increases and eventually it becomes apparent that there are some scalability limitations in your file-based persistence mechanism. You decide to switch over to using an object database for persisting data. This change requires that you remove a lot of the file-access code in the application and replace it with APIs that are specific to the object database. These modifications take several weeks/months of hard work, but once that work is complete, you are happy that your application can easily scale up to deal with the increased workload.
3. The next year, your company merges with another company. In the newly-merged company, a decision is made to streamline the extensive range of third-party software products being used within the company. As a result of this, you are told to remove use of the object database from your CORBA server and to replace it with, say, Oracle. You then spend several weeks/months to make the necessary modifications.

The intention of the Persistent State Service (PSS) is to eliminate the need for extensive source-code changes when switching from one persistence mechanism to another. PSS is an abstraction layer that insulates developers from the technology and APIs of the underlying persistent storage device. PSS deals only with persistence of data: it does not provide transactional or querying capabilities. Because of this, it is not a silver bullet, but a simple-to-use persistence mechanism is sufficient for the needs of many applications.

PSS provides the Persistent State Definition Language (PSDL), which is a superset of IDL. PSDL is used to define data-types that can be persisted. A PSDL compiler then translates the PSDL definitions into corresponding definitions in a programming language (such as C++ or Java). The PSDL compiler also generates the code required for these programming-language objects to be persisted in, and retrieved from, a file or database.

The long-term goal is that there will be PSS implementations for a wide variety of different storage devices, such as files, object databases and relational databases. An application developer who uses the PSS APIs will be able to easily switch from using a file-based PSS implementation to a relational database-based PSS implementation or vice versa. However, this long-term goal has not been fully met yet. Several CORBA vendors provide implementations of PSS, but it is common for a vendor to provide a mapping from PSS to only one type of persistent storage device. You can expect a CORBA vendor to be willing to implement PSS support for additional brand names of database or other storage technologies if there is enough customer interest for such support. This can easily become a chicken and egg situation: customers are likely to avoid PSS unless it already supports multiple storage technologies, and vendors will not support multiple storage technologies until they get sufficient PSS customers to make it worthwhile. An important point about this is that before deciding to use PSS, you should check that your CORBA vendor (or a third-party vendor) can provide you with PSS implementations for all the persistent storage technologies that you might require.

There are two final points to note. First, a good, technical overview of PSS can be found in the Java Programming with CORBA book [BVD01]. Second, PSS-based persistence is one of the infrastructure services that is provided by the CORBA Component Model (CCM), which is briefly discussed in Section 19.3.

24.2  Other CORBA Services and Domain Specifications

The OMG web site (www.omg.org) provides free-to-download PDF documents of all the different CORBA-related specifications. It is worthwhile browsing that web site in order to see the extensive range of services defined by CORBA. The services are optional parts of CORBA, so your CORBA vendor is likely to sell just a subset of them.

It should be noted that the term CORBA Services is used to refer to optional functionality that might be useful to applications in many different types of organization. Naming, Events and Transactions are examples of such services. The OMG recognizes that it is useful to define standards for functionality that has a more specialized purpose. Such functionality is called an OMG Domain Specification. The OMG web site lists domain specifications for a diverse range of specialized areas, such as air traffic control, audio/video streaming, computer aided design, telecommunications, finance, accountancy, manufacturing, distributed simulations, and life science research. The division between what is a CORBA Service and what is an OMG Domain Specification is somewhat subjective, and several specifications are listed in both categories on the OMG web site.

If your vendor does not implement a particular CORBA Service or OMG Domain Specification that you require then you might be able to purchase an implementation of the required functionality from a third-party company. You can use an Internet search engine (for example, www.google.com) to locate companies that sell implementations of particular CORBA Services or OMG Domain Specifications.