RODL (RemObjects Definition Language)

RODL Overview

RODL (short for RemObjects Definition Language) files form one of the foundations of Remoting SDK, and are used to define the interface of the services that a Remoting SDK server exposes - both the actual services as well as any user-defined types that might be passed in and out of these services.

Conceptually, RODL files can be compared to Type Libraries (TLB) files used in COM or the WSDL (Web Service Definition Language) files used in SOAP Web Services, but they provide advantages over these:

  • they are XML based, which makes them easily readable by both humans and computers using different platforms (unlike TLBs, which use a binary format) they provide a consistent and non-ambiguous definition language where any given service has one definitive representation (unlike WSDL, which can use countless different formats to express the same thing)
  • To enhance the experience of working with and creating RODL files, Remoting SDK provides the Service Builder, which offers an intuitive GUI and a RAD approach to defining services.

Elements of a RODL File

In addition to the services themselves, a RODL file can contain definitions for a number of different elements that make up your server. These are:

  • Services. A service defines a class, or a set of methods that you want to expose on the server. Typically, a particular service would group together methods that perform related functionality, and any given server might implement one or many separate services.
  • Types. In addition to a wide range of default "simple" data types supported by Remoting SDK, a RODL file can define a number of user defined types to be passed into or back from your services. These include Structs (records, a number of named fields grouped together to form a new entity, such as a Person that might consist of a Name, Age and Address), Enums (lists of named values) and Arrays (variable-length collections of a specific types, such as a list of Persons).
  • Exceptions. Exceptions are used to represent error conditions that occur during the execution of a service method; a service method might raise/throw a specific exception, and the same exception would be re-raised/thrown on the client. Custom exceptions may be defined in the RODL so they can be shared between client and server.
  • Event Sinks. Event sinks define a set of events that servers can send back to the client. You can consider them to be call backs, methods that a server can call on one or more client to notify them of certain events.
  • Uses. every RODL can contain references, or imports to one or more external RODL files, to make the types defined in that RODL available. Consider these references comparable to a "uses" clause in Delphi or "using" statements in C#.
  • Groups. Finally, a RODL file can contain groups, which are used to visually group elements inside Service Builder. Groups have no effect on the code or runtime behavior of the application, but they help when visually structuring large RODL files.

How RODLs are used in Remoting SDK

As mentioned above, RODL files are used to define the services and related types of your Remoting SDK servers. As such, the process of working with RODL files is usually that the architect of the service will use Service Builder to create a RODL file defining the service, which will then be used during the development of the service in several ways:

  • a number of source code files will be automatically generated from the RODL and included in the server project. These files can be generated automatically from within the IDE, or manually saved to files with Service Builder. The Files Generated from RODL help topic covers these files in more detail.
  • The RODL file will (optionally) be linked into the server executable, which will make it accessible and discoverable to clients.
  • Where needed, the server will also provide automatic conversion of the embedded RODL into different formats (such as WSDL for SOAP clients).
  • Client developers can import the RODL file provided by servers to generate interface units to consume the service.
  • Dynamic clients such as the Service Tester can query the RODL file from the server, dynamically discover the available services and types and generate calls on the fly, using the Dynamic Request component (for .NET, Dynamic Request is currently shipping as part of Data Abstract only).

RODL Files in Your Projects

Typically, RODL files will be considered part of the files that make up your project. How this is handled in the IDE's project management differs with the type of IDE you are using.

The Visual Studio IDEs will treat your RODL file as proper members of your project. You will see the file show up in Solution Explorer, and you can apply all common file operations to it, including dragging the file around the project, or using the Property Browser to change file properties (such as whether the RODL file will be embedded as resource). You can also double-click the RODL file in Solution Explorer to edit it.

CodeGear Delphi does not allow adding non-code files to the project, as such the RODL file will not show in Project Manager. Instead, a special {#ROGEN directive in the .dpr file is used to reference the RODL file, and the RemObjects menu must be used to edit the RODL in Service Builder.

Also, CodeGear Developer Studio does not support embedding resources in C# projects, so any functionality requiring an embedded RODL file (such as use of Service Tester) will not work in this combination of tools - we recommend using Visual Studio for C# development.

Accessing RODL Files from Your Own Code

Both editions of Remoting SDK provide class hierarchies that allow you to load and work with RODL files in a type-safe manner without having to manually parse the XML format. These classes are based around the RodlLibrary (.NET) and TRODLLibrary (Delphi) classes and provide properties and sub-classes that give access to all elements of a loaded RODL.