Connecting to a Remoting SDK Server
Remoting SDK makes it easy to turn any existing Delphi project into a Remoting SDK client and have it talk to your Server. Simply select "Connect to Remoting SDK Server..." from the "Tools" menu:
This option is available for any project, regardless of whether it uses Remoting SDK yet or not.
Selecting it will bring up this simple dialog, where you can specify the URL of your service (complete with port and path to RODL, so commonly that will end in
:8099/bin) or browse for a local .RODL file on disk:
Note: HTTP, SuperHTTP, TCP and SuperTCP server are supported via specifying
supertcp://. DLL server is supported via 'file:///path/server.dll'
Enter your server's address and click "OK", and Remoting SDK will automatically retrieve the RODL, process it, and generate a handful of new files for your project, all using your server's name as the base name:
The three files are:
The YourServer.remoteRODL File is a small XML file that serves as the link between your project and the remote server, for this conversion and for future updates. Essentially, it just contains the URL of your server (or of the local .RODL file, if you selected one), and is provided for easy access to working with the server from the IDE. For example, you can update your code to changes in the server via this file, as explained in the Working with .remoteRODL Files topic.
The YourServer_Intf source file contains code generated by Remoting SDK to let you interact with the server. This includes interfaces/protocols for all the Remote Services exposed by your server, as well as any helper types these services use, such as custom enums or structs. You should not touch the code in this file, as it will be re-generated (thus losing any changes you make to it) when you update it to changes on the server. You can read more about
_Intf files here.
Finally, the YourServer_ServerAccess source file and matching .DFM contains a small helper class (based on a Data Module ) that provides a convenient starting point for encapsulating the access to your server from within your client app, alongside all the non-visual components needed for that. Once created, this file becomes "yours", and you will most likely expand it to expose functionality more specific to your concrete server.
The ServerAccess class is merely a suggestion and an assistance to get you started, you can feel free to simply remove the file from your project, if you want to structure your server access differently within the client app.
Let's have a closer look at what's inside the ServerAccess class. It's singleton class with a single instance, accessible via the static
instance property. It encapsulates your server URL and the Remoting SDK components needed for the communication, such as the Client Channel and Message instances, and it exposes public instances of your service .
Of course it is up to you to decide which aspects of this fit your application's design, and which need changing. For example, you might not want to expose all service proxies publicly, but instead encapsulate access to certain services with bespoke wrapper methods you add to
ToDo: expand this once the template is done