Implementation of a Lightweight Logging Service for CORBA-based Applications

Transcription

1 Implementation of a Lightweight Logging Service for CORBA-based Applications MARKUS ALEKSY, JAN KÄSTLE, MARTIN SCHADER Department of Information Systems III University of Mannheim D Mannheim GERMANY Abstract: In this paper, we present the implementation of a Lightweight Logging Service for CORBA-based applications. The service is based upon a CORBA specification and is primarily intended for usage in embedded environments. In the description of the details of our implementation, we elaborate on incompleteness of the existing Draft Adopted Specification. We discuss different architectural approaches and conduct a critical analysis of their pros and cons. Finally, we provide some examples that demonstrate potential application areas for the service. Key-Words: - Lightweight Logging, CORBA, Distributed Systems 1 Introduction The Common Object Request Broker Architecture (CORBA) standard [5] is widely used in the area of object-oriented and distributed systems. It allows for independence of the implementation from the computer architecture, the operating system, the programming language, and the vendor of the selected Object Request Broker (ORB). Independence from the underlying programming language is obtained through CORBA s Interface Definition Language (IDL). IDL describes the distributed objects public attributes and behavior in a standardized and implementation-independent way. Independence of a specific ORB product was provided in CORBA 2.0 through the introduction of a unique object reference, the Interoperable Object Reference (IOR), and the definition of a standardized transfer protocol, the Internet-Inter-ORB-Protocol (IIOP). The ORB is the basic component for communication in distributed applications. In order to support application developers, the Object Management Group (OMG) has standardized a number of fundamental services, the CORBAservices [1]. These services enhance the core of an ORB by including additional often-needed functionality, e.g., event handling, trading, or persistence. 2 Problem Formulation The Lightweight Logging Services (LLS) [3] is a CORBAservice that OMG officially categorizes as a Specialized CORBA Specification. It is primarily intended as an efficient, central facility inside an embedded or real-time environment that accepts and stores data sets containing logging information (Log- Records). These LogRecords are generated by other applications residing in the same environment. They are managed by the LLS and stored in its memory area. The service was originally designed as a subset of the Telecom Log Service [4]; it differs, however, in the way the LogRecords are written to or retrieved from the log. Due to resource constraints typically present in embedded or real-time systems, the LLS is subject to some restrictions: Only simple logging is supported. No connection to Event Listeners is provided. Instead, specific interfaces (LogProducer and LogConsumer) are defined. The LLS does not support any federation of logging services. In particular, forwarding of LogRecords to another Log object is not supported. The LogRecords are only stored in memory; persistent logging is not enabled. No means to filter LogRecords are provided. Due to the constraints of an embedded environment, the IDL type any is not supported. As a query operation, only looking up the logtime for a single LogRecord is provided. Otherwise, queries are achieved via a record s RecordId. Several possibilities to filter LogRecords with respect to attributes of the log written by the LogProducer exist. In addition, the LLS enables the reading of small consecutive chunks of a LogRecord, similar to the use of an iterator. Write operations are asynchronous. The log provides no feedback and raises no exceptions.

2 In this way, restrictions of an embedded ORB are taken into account. Bearing in mind that the LLS addresses primarily the needs of embedded systems, it relies only on a minimum set of system resources. The LLS is not dependent on any other component or service. In the definition of the enumeration type LogFullAction, parentheses, (), instead of braces, {} were used. This was corrected in our implementation. The interfaces LogConsumer and LogAdministrator contain (among others) the definitions of operations retrieve_by_id and set_max_size, respectively that may raise an exception of type InvalidParam. However, this exception type is not defined anywhere. In our LLS implementation, we supplied a simple exception type. Naming and usage of a sequence of ProducerLogRecords is inconsistent. It is defined as a LogProducerRecordSequence but then later used as a ProducerLog- RecordSequence. To correct this inconsistency, we adapted the IDL interface of the LLS to the first variant. The specification contains additional inconsistencies with regard to the naming of enum data types. These are defined as LogFullAction or AdministrativeState; however, they are then used later as LogFullActionType and AdministrativeStateType, respectively. In our implementation, we used the identifiers LogFullAction and AdministrativeState. As discussed above, we took measures to eliminate the inconsistencies that occurred in the IDL interface of the Draft Adopted Specification and to be able to conduct the implementation. In parallel, the OMG also undertook efforts to correct its own specification. In the Final Adopted Specification of May 22, 2003 [3], the problems identified above were eliminated. The solutions we and OMG found are largely identical which significantly simplified the adaptation of our implementation. The only notable difference concerned the definition of the InvalidParam exception, which contained no attributes in our original implementation and thus had to be enhanced with an attribute details of type string in order to be standard conformant. 3 Implementation Problems During implementation of the LLS specified by the OMG in the Draft Adopted Specification of Nov. 2, 2002 [2], we detected several deficiencies in the original IDL interface: 4 The Implementation of the LLS In the following sections, we present the architecture of the LLS, explain possible implementation alternatives, and discuss several application scenarios. 4.1 Architecture The LLS specification contains the definition of four interfaces. The interface LogStatus defines operations that allow for queries concerning the current state of a Log object. We find operations that return the current or the maximum size of the log in bytes. The number of stored LogRecords can be queried as well. Furthermore, the interface provides operations that report the administrative or the operational state of the log. Since the LogStatus interface serves as a base interface for the remaining three interfaces of the LLS specification, these common operations are inherited and, therefore, available in these interfaces. In addition to the LogStatus operations, the interface LogProducer provides operations that allow the insertion of new LogRecords into the log. Here, a data structure ProducerLogRecord is used. Besides the current log data (logdata), additional details, e.g., the producer s identity (producerid) and its name (producername), are supplied. In the log, this data is supplemented by the current time (LogTime) as well as a RecordID. The Final Adopted Specification defines not only the operation write_records but also the operation write_record. Both write operations are specified oneway and thus can neither return a result nor raise an exception. In this way, the LogProducer s implementation is decoupled from the implementation of the log so that difficulties in the log will not have side-effects on the LogProducer. Analogous to the LogProducer, the interface LogConsumer is derived from LogStatus and enhances it by providing operations that can retrieve LogRecords from the log. Therefore, it defines a multitude of operations, e.g., retrieve_records, retrieve_records_by_level, retrieve_- records_by_producer_id, and retrie-

3 ve_records_by_producer_name, which return entries from the log considering various criteria. The last interface defined in the LLS specification is the LogAdministrator. Also derived from interface LogStatus, it provides various administrative operations. These can be invoked, e.g., in order to set the maximum size of the log, to clear the log, or to destroy it. It is also possible to configure the actions that are to be taken if the log storage area should become full. In this case, it is possible to reject the acceptance of further LogRecords LogFullAction set to HALT or to overwrite the oldest records in the log LogFullAction set to WRAP. Figure 1 shows the architecture of the LLS. 4.2 Implementation Alternatives In CORBA we can chose between two different approaches when implementing the IDL interfaces of a CORBA-based application: the inheritance-based (POA- Approach) or delegation-based (TIE-Approach) implementation. An inheritance-based implementation defines a Servant class that inherits from a base class, named <interface-name>poa. This base class is generated by the IDL compiler. Due to the inheritance relationship, the servant must implement the operations defined in the IDL interface. It should be noted that, in the case of programming languages that do not support multiple inheritance such as Java, this implementation of the servant uses up its single inheritance by extending the POA base class. Figure 1: Architecture of the LLS

4 In the delegation-based implementation, we define a Delegator class for the respective interface. It adopts the role of the servant class but does not provide operations; instead, each operation invocation is delegated to an implementation class. In the case of Java, this implementation class must define the operations in the interface <interface-name>operations, which is generated by the IDL-compiler. In this way, an implementation class can inherit from multiple interfaces. So, a single delegator could service objects that represent different interfaces. A drawback of this approach is the additional level of indirection, which can have negative effects on the execution speed of the application. 4.3 Required Memory Resources We examined the two approaches discussed above POA and TIE with respect to their memory requirements. This is an interesting comparison since embedded systems with their severe resource constraints are one of the typical application areas of a LLS. First, static memory requirements were compared, i.e., we inspected the size of the class files. When implementing the interfaces with the TIE-Approach, the single resulting class file had a size of 6,722 bytes. For the implementation following the POA-Approach, we generated four class files with a total of 9,867 bytes, an additional 46.8% of bytecode. Subsequently, we measured the storage the two alternatives require when their classes are loaded. Here, both approaches yielded similar results. For the TIE-Approach, an average of 707,704 bytes were necessary; using the POA-Approach, the corresponding value was 707,568 bytes. Both values include the memory allocation for the ORB s runtime library. 4.4 Selection of the Appropriate Data Structure for LogRecords Our implementation of the LLS specification was carried out with the help of Sun s Standard Development Kit (SDK) [8]. In order to store LogRecords in memory, we used the SortedMap data structure provided by the SDK. Only one single implementation of SortedMap, the TreeMap, exists in the SDK. This implementation is based upon a red-black tree [8]. The keys in a TreeMap are always sorted. Their sequence is determined by the interface Comparable that must be implemented by the key. In the case of the LLS, the RecordId is used as a key; it is stored in the Long wrapper class. According to the characteristics of a red-black tree, the TreeMap supplies the methods containskey, get, and remove with logarithmic access times. These methods are invoked in the following situations: When we delete a LogRecord, we can determine the data set to be deleted with the SortedMap s method firstkey and then delete it by invoking SortedMap s remove(logs.first- Key()); note that the RecordIds are generated in ascending order. Also, it is possible to assert with logarithmic effort whether a LogRecord is contained in the log or not (e.g., by calling method retrieve_by_id). With the help of the SortedMap method submap, we can obtain a partial tree, which allows us to generate a sub-sequence of entries in the log within retrieve_records. In order to find a RecordId according to its LogTime in logarithmic time with the method get_record_id_from_time, we have to apply a different access strategy. Here, we implemented our own algorithm based upon binary search. Java offers several alternatives when realizing the data store compared to the TreeMap. A HashMap provides constant access times for its elements with the methods get and put. While this is an advantage, a HashMap stores its elements unsorted, which results in considerable cost when invoking method retrieve_records. First, all entries in the HashMap would have to be inspected, which would yield linear access times; additionally it would be necessary to sort the found LogRecords in order to determine which of those have to be returned. Using a HashMap, the rebalancing of the red-black tree necessary after inserting a LogRecord is dispensable. However, a HashMap s size must be adjusted to the size of the log [8]. An ArrayList also offers constant access time for its elements by invoking the method get. Iteration through a list in order to collect a number of LogRecords is then linear in the number of elements to be found. In amortized constant time, we can insert elements by calling the method add. In that respect, an ArrayList offers better performance than the TreeMap. However, due to the fact that an ArrayList is internally based upon an array, all other methods, including deletion of elements, are linear in time [8]. In the case that the attribute LogFullAction is set to the value WRAP, the method remove is often called. Here, the TreeMap with its O(log(n)) access time is considerably faster. At this point, we have to take into consideration how we want to work with the log. If we set LogFullAction to WRAP, then each write access deletes all existing LogRecords and therefore is O(n). In the case of a HALT strategy, no old LogRecord must be deleted and a write access needs constant time.

5 For our implementation, we decided to use a TreeMap since in both cases it offers an average access time of O(log(n)). Moreover, in many cases it would be recommendable to apply the WRAP strategy since the LLS has to perform under severe resource constraints and only a limited amount of memory will be available. With the HALT strategy, it would only be possible to store a few LogRecords and it would be necessary to reject additional entries. 4.5 An Example for Using the LLS In Figure 2 we show an example scenario of an application using the LLS. In this example, the Log- Administrator client sets the value of the LogFullAction attribute to WRAP. Then, a LogProducer client writes one or more Producer- LogRecord entries to the log. By invoking the operation get_record_id_from_time, a LogConsumer client can obtain a number of data records from the log. Here, the RecordId of the starting record as well as the number of records to retrieve must be specified. 5 Portability We tested our LLS implementation with two different ORBs: JacORB Version [6] and OpenORB [7]. JacORB was developed at the Freie Universität Berlin and is publicly available. OpenORB is an open source project of the ExoLab group. In addition to the ORB core, both distributions contain different CORBAservices. The porting of our LLS implementation from JacORB to OpenORB was successful without any additional coding. 6 Conclusion We encountered several problems during implementation of the LLS based on the Draft Adopted Specification. The reasons were inconsistencies in the definition of the IDL interfaces of that specification. Most of the problems could be solved with minor corrections and considerations that corresponded largely to the improvements introduced by OMG in its Final Adopted Specification. Therefore, only minor adjustments of our own service to the new specification were needed. Bearing in mind the resource constraints that are typical for applications using a LLS in embedded or realtime environments, we compared two different implementation approaches with respect to their memory requirements: the POA-Approach and the TIE- Approach. No relevant differences were detected. In the final section of our research, we analyzed portability of the solution we had implemented. Porting the LLS from JacORB to OpenORB, we did not encounter problems. With the help of our LLS implementation, CORBAbased applications can profit by enhanced functionality. Focusing primarily in application areas where system resources are limited, our implementation can further promote the popularity of the CORBA standard. Figure 2: Example Scenario for Using the LLS

6 References: [1] OMG (2003): Catalog of OMG CORBAservices specifications, [2] OMG (2002): Lightweight Log Service Specification ; Draft Adopted Specification; OMG Technical Document Number , [3] OMG (2003): Lightweight Log Service Specification ; Final Adopted Specification; OMG Technical Document Number , [4] OMG (2003): Telecom Log Service Version ; OMG Technical Document Number , [5] OMG (2002): The Common Object Request Broker: Architecture and Specification Version 3.0 ; OMG Technical Document Number , [6] JacORB, URL: [7] OpenORB, URL: [8] Sun Microsystems Inc. (2003), Java TM 2 Platform Standard Edition Version 1.4.1, API Specification