Serialization

Entity data, i.e. complex data structures of moderate volume, are often represented as XML in the ALMA system. According to the ALMA Technical Architecture described in the ALMA Software Architecture[RD33], XML is used to:

• define the content and structure of the entity objects that are passed between subsystems

• automatically generate the classes needed to access the data contained in these entity objects, optionally validating changes to a data value by an explicit call to validate() or implicit validation during (un-)marshalling;

• serialize these objects for network transmission;

• facilitate the storage of these.

The primary language used to define data entities in ALMA is UML, c.f. ALMA Software Architecture[RD33].

UML is used as a higher-level layer, from which the previously hand-crafted XML Schemas are now automatically generated. The data transport format will remain XML though, and the XML schemas are still visible to developers when defining database queries.

Support for data modeling, code generation, and data handling in ALMA is split between ACS and the HLA subsystem:

• ACS provides the generator framework,

• HLA maintains the UML model and defines what code gets generated from it

• ACS provides generic mechanisms to generate Java binding classes from XML schema, and to present instances of these classes to application software, thus removing the need to explicitly deal with XML data. See below on details.

We assume that access to entity data will be primarily of concern to Java high level applications, therefore ACS priority is to provide optimal support for Java.

Entity data structures are conceptually defined as UML classes. Technically they are defined by means of XML Schemas which are derived automatically from UML.

Programming language classes (for example Java, C++ and Python) to wrap and facilitate access to entity structures could be generated automatically from the XML Schema (XML binding to language-specific classes). The Castor[RD36] open source framework is currently used for Java binding. Castor XML binding provides also validation code for the accessors, based on the XML Schema. A similar, but not as complete, open-source binding framework for Python, generateDS, will be delivered with ACS 8.0. No such facility is currently foreseen (or required) for C++.

For data structures defined in UML, code generators are based on the Open ArchitectureWare Project [RD39] generator framework. We generate from the XMI UML representation:

• XML Schema as described in the previous paragraphs

• Binding classes for Java (based on Castor), C++ and Python (custom made)

• IDL interface definition files

• HTML documentation

• any other format needed, by implementing custom generators

Entity data is passed among Components as XML strings[RD01 - 10.5.10 XML]. Each Component operation that sends/receives an entity data structure, will have an IDL interface where the corresponding parameter is represented as a CORBA string. This is a commonly accepted way of implementing serialization. [RD01 - 3.3.2. Serialization] and migration[RD01 - 3.3.3. Migration] of objects without using CORBA Object by Value (ObV). As already mentioned in the Error System section, ObV is not implemented by most ORBs, is still immature and its usage is problematic.

ACS Java Container makes (un)-marshalling transparent to the user, interposing a proxy class between the IDL stub/skeleton and the implementation:

• Given the IDL description of a Component, a code generator is used to generate a <Component>Interface class. In this class, every EntityDataXML parameter has been replaced by the corresponding EntityData binding class.

• Java introspection is used to dynamically generate a <Component>DynamicProxy and a <Component>DynamicSkeleton class.

• <Component>DynamicProxy is used by clients and converts client side calls from the EntityDataXML to the EntityData (un)-marshalled calls and forwards the messages to the <Component>Stub class generated by the IDL compiler.

• <Component>DynamicSkeleton is a delegation class that converts servant side calls from the EntityDataXML to the EntityData (un)-marshalled calls and forwards the message to the user defined <Componet>Impl real implementation class.

• Clients and the servant implementation of the component will therefore only see the interface of the <Component>Interface class, that does not use XML strings but binding classes.

Figure 3.16: Example of class diagram showing transparent Entity Data serialization

The usage of the proxy approach allows the container to:

•         Shortcut local calls (i.e. calls inside the same Container), so that no XML serialization is needed and the binding class is passed directly (not implemented yet).

•         Intercept calls to Components, allowing the implementation of the Tight Container pattern (see ACS Container section).

For C++ and Python it is not foreseen to implement transparent (un-)marshalling like in Java. This choice is based on the assumption that Java clients and Components will be the most adequate whenever serialization is needed. If C++ and Python support will be necessary, they will be implemented at a later stage based on the code generation engine (Not implemented yet).

In case no XML binding generator is available (for example for clients written in a language different from Java, C++ or Python), we anyway expect that it will be acceptable to work directly on the XML strings with an XML parser.