.RODL Files

.RODL files (short for RO Definition Language) contain XML-based meta-data that describes the services and auxiliary types exposed by a Remoting SDK server.

There are two forms in which RODL metadata can come to exist:

  • In classic RODL-based server projects, your server project will contain one or more .RODL files as physical files on disk.
  • Every server – Code-First or RODL-based – makes a RODL available for download (by clients and by IDEs) that describes the server.

Let's look at these scenarios in turn:

RODL-Based Servers

As mentioned above, for classic RODL-based server projects you have one or more actual .RODL files on disk and referenced in your project.

For .NET and more modern Delphi server projects, these RODL files will show in the project tree and can be interacted with; in older Delphi server projects the RODL file will be referenced by a {#ROGEN directive at the top of the .dpr project file.

Typically, the RODL file(s) in your server will have been created manually with the Service Builder tool, and you use Service Builder to update and maintain them as your project develops.

From the .RODL File, the IDE will generate a bunch of source files.

_Intf and _Invk source files will be created and automatically kept up to date as the RODL changes. These contain auxiliary types, interfaces for your services, as well as helper classes the Remoting SDK needs to do its job.

One _Impl source file will be generated for every service in your RODL. These files will be generated once, and then filled with your own code to implement the service. If RODL changes affect a service, its _Impl file needs to be adjusted manually, to match.

On compile time, the .RODL file is also embedded into the server application as a resource, so that it is available at runtime; more on that below.

Code-First Servers

Code-First Servers, the recommended mode for new projects, no longer use a .RODL file on disk. Instead, you simply define your services in code, and annotate them with attributes to make them published. You can read more about this in the Code-First Servers topic.

Serving the RODL

Any Remoting SDK Server, RODL-based or Code-First, serves a RODL that can be downloaded from the server, to describe its services and auxiliary types.

This RODL will be generated at runtime by merging any .RODL files embedded in the server (either by your server project, or by libraries that your server includes, such as Data Abstract, and metadata generated from Code-First services found in the server.

The RODL can be accessed from HTTP-based servers by appending the /rodl path suffix to your server's address as replacement of the message name slug (such as /bin). Some message types (such as BinMessage will also serve the RODL when the URL is accessed by a browser, while other messages (such as SOAP) will serve different information.

The RODL exposed by the server can be viewed in a browser as XML data, but the most common scenario for accessing the RODL will be when you Connect to a Server when working on a client project. When you do so, the IDE will download the RODL, and generate files for your project from it. Please refer to the Connecting to a Remoting SDK Server topic for more details.

The RODL Format

You will usually not create or edit .RODL files directly. If you create or maintain a RODL-based server, you will launch Service Builder from your IDE to edit your RODL. And you will rely on the Remoting SDK's IDE Integrations and tools such as Service Importer for accessing and viewing contents from a RODL and turning it into interface code for your client apps.

That said, RODL uses a rather straight-forward XML-based format that can be edited (or merged, for version control purposes) directly as plain text, if needed.

<?xml version="1.0" encoding="utf-8"?>
<Library Name="YourServer" UID="{...}" Version="3.2" Namespace="YourCompany.Server">
    <Structs>
        ...
    </Structs>
    <Arrays>
        ...
    </Arrays>
    <Enums>
        ...
    </Enums>
    <Exceptions>
        ...
    </Exceptions>
    <Services>
    <Service Name="YourService" UID="{...}" Ancestor="">
        <Interfaces>
            <Interface Name="Default" UID="{...}" Ancestor="">
                <Operations>
                    <Operation Name="Test" UID="{...}" Ancestor="">
                        <Parameters>
                            <Parameter Name="Ints" UID="{...}" DataType="IntegerArray" Flag="In"/>
                            <Parameter Name="Result" UID="{...}" DataType="IntegerArray" Flag="Result"/>
                        </Parameters>
                    </Operation>
                </Operations>
            </Interface>
        </Interfaces>
    </Service>
</Libray>

See Also: