MegaDemo sample (Delphi)
Overview
The MegaDemo sample is an application that will show you how to use most of the features included in the Remoting SDK. The Remoting SDK includes several other demos as well. Upon installation, you can find the MegaDemo in the C:\Users\Public\Documents\RemObjects Samples\RemObjects SDK for Delphi folder.
To test the application, you need to open the project group MegaDemo.groupproj. This group contains several projects, including the standalone .exe's MegaDemoServer and MegaDemoClient (there is also a MegaDemoISAPI project that shows you how to host a RemObjects server in a standard IIS ISAPI DLL).
In the Delphi IDE, click Project -> Build All Projects to compile both .exe projects and then launch them both by clicking Run -> Run.
This is how the MegaServer looks like when you launch it:
Most real life servers are not implemented as GUI applications, but rather as Services. Using a GUI application for the demo makes it easier to demonstrate its different features.
Transport Channels
The MegaServer's services can be accessed using five different protocols, each with a separate groupbox and options that you can configure. A production server would not necessarily implement all five of these methods, but would rather focus on the one that is best suited for the current application. For demonstration purposes, the MegaDemo includes all of them in one single server.
The HTTP Transport Channel exposes the server object via the HTTP protocol. This is the default protocol used for almost all the SOAP services available today. If you are implementing a server that will be accessed by many different clients (some of which might not be developed with the Remoting SDK), a SOAP-HTTP Server will be the best choice.
The Super HTTP Channel exposes the server object via the HTTP protocol and offers two-way communication features. It uses two connections: one for sending requests and one that waits for responses and events to be available. This makes it possible to send multiple requests at once, making it a truly asynchronous channel.
The TCP Transport Channel uses plain TCP/IP to communicate. There are little technical advantages or disadvantages between this and the HTTP Channel, but using the TCP/IP protocol will eliminate a bit of the overhead involved with the HTTP protocol.
The Super TCP Channel provides a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks. It is useful for scenarios where extensive use of events and server callbacks is needed, and wherever firewalls and proxy servers do not require the use of HTTP based channels.
Finally, the WinMessage Transport Channel uses WM_COPYDATA, a Microsoft Windows specific Inter-Process Communication mechanism. This is a very fast method because it eliminates the use of the TCP/IP layer altogether, but its downside is that it only works if the Client and the Server are running on the same PC.
Message Types
In addition to providing a wide selection of network protocols, the Remoting SDK also allows you to choose between different message encodings to dispatch requests from clients to servers.
The BIN Message is the most efficient form of encoding. It uses a binary format to get the message into a very small block of data. In addition, it offers compression and four types of encryption.
The SOAP Message uses the well-defined SOAP format to encode the information sent between client and server. The advantage is that SOAP messages are compatible with any existing SOAP clients and servers, whether they are written with the Remoting SDK or not. The downside is that SOAP Messages tend to be large, because they are encoded in human-readable XML format, therefore any binary field passed between client and server is encoded in base64.
The Post Message makes it easy to post data directly from an HTML form to a service by simply specifying the service URL as the "Action" attribute. The Post Message can be also used when you need a simple human-readable messaging format - for example for debugging or monitoring purposes.
The XML-RPC Message uses the standard-based protocol XML-RPC that can be considered the predecessor of SOAP. It can be used in scenarios when communicating with existing XML-RPC services or when communicating with platforms not directly supported by the Remoting SDK that do provide an XML-RPC implementation - such as Java or PHP. The XML-RPC Message can be also used when you need a simple human-readable messaging format - for example for debugging or monitoring purposes.
The JSON Message is a simple, human readable data interchange format written in a subset of the Javascript syntax. JSON-RPC is a way of doing remote calls on top of JSON. It is ideal for calls from a Javascript client, and the Service Builder includes a header generator for Javascript that uses a JSON library from the Yahoo User Interface library. Of course RO isn't limited to YUI and can easily be used with other JSON implementations.
The Client
This is how the MegaClient looks like:
Here, you choose the communication methods described above. If you have activated all five servers in the MegaServer, you should be able to use either Transport Channel to communicate with the server.
Note also that you should set the message type to match client and server.
The bottom part of the form represents the different functions exposed by the server. Choosing any of the operations and clicking the Run Test Once or Run Test button will invoke the corresponding method on the server (you can specify the count of times and threads for testing).
Understanding the MegaDemo
How does the MegaServer define what methods it exposes? How does the MegaClient know how to call them?
Let's take a look behind the scenes to find out.
First, go back to the IDE and make sure that the MegaServer project is active, then click on the Tools -> Remoting SDK -> Service Builder from the IDE's menu.
This is how the Service Builder will look:
The Service Builder offers you a visual representation of the service definition, which is kept in a RemObjects Definition Language (RODL) file.
In the tree view on the left you can see all the items that are defined for the service: a complex type TPerson (a struct, or what Pascal would call a record), an enumeration, three array types and an exception.
You can also see the definition of a service called MegaDemoService. If you compare the Operations listed for the MegaDemoService, you will see that they exactly match the methods that the MegaClient allowed you to call (Sum, GetServerTime, etc.).
RODL Files
The information presented by the Service Builder and used by the server and the client to communicate is stored in an XML file encoded using the RemObjects Definition Language (RODL) convention. You can see the RODL file corresponding to the data shown in the Service Builder by clicking the RODL toolbar button or by selecting View -> RODL from the menu.
Starting from this RODL file, a preprocessor generates several Pascal source files that are then used by server and client to implement the communication.