Copyright: Copyright (c) RemObjects Software, LLC, 2002-2006. All rights reserved.
Citation: Copyright (c) RemObjects Software, LLC, 2002-2006. All rights reserved.


RemObjects SDK for Delphi


Welcome to RemObjects SDK

RemObjects SDK is a RAD multi-tier solution that allows you to easily build distributed cross platform applications.

It is currently available in two distinct editions, for .NET (supporting .NET 1.1 and 2.0, the Compact Framework 1.0 and 2.0 and Mono) and Delphi (supporting Win32 and Linux/Kylix).

RemObjects SDK for .NET and Delphi are designed with portability in mind and are binary compatible, allowing you to mix Delphi servers with .NET clients, and vice versa.

Contents of this Help File

Separate help files are provided for the .NET and Delphi editions of the product. Many topics are identical or almost identical for the two editions, but there are some concepts which differ slightly between versions. This is highlighted by green/blue color coding for .NET/Delphi.

The top level topics provided in this help file consist of:

Welcome: this topic.

Overview of RO Components explains the various components provided by RemObjects SDK and how they fit together.

Programming with RemObjects SDK provides detailed introductions to the core concepts involved with the RemObjects SDK and the underlying architecture that makes RO work.

Tools introduces you to the tools provided with Data Abstract, in particular the Service Builder and Service Tester .

RemObjects SDK Reference provides a detailed reference of the classes, methods and properties that make up RemObjects SDK Library.


Topics

Topics

What's New in RemObjects SDK

For a detailed list of changes and fixes in each updated release, please check the online Change Log for RemObjects SDK 4.0 for Delphi.

Overview of RO Components

RemObjects SDK provides the following components in the Delphi Component Palette (or Tool Palette) that can be dropped onto your forms, data modules or services at design time.

Some of these components are intended to be used on the client side (such Channels, Remote Service, Dynamic Request), some on the server (Servers, Session Managers, etc.) and yet others will be shared on both sides (such as Messages).


What's New in RemObjects SDK

For a detailed list of changes and fixes in each updated release, please check the online Change Log for RemObjects SDK 4.0 for Delphi.


Topics

Topics

Breaking Changes

This topic provides a list of breaking changes in new major versions of RemObjects SDK for Delphi, and points out areas that might need your attention when upgrading to new versions.


Breaking Changes

This topic provides a list of breaking changes in new major versions of RemObjects SDK for Delphi, and points out areas that might need your attention when upgrading to new versions.

Breaking Changes in RemObjects SDK 4.0.9 for Delphi

TRODBSessionManager.ClearSessions was renamed to ClearSessionsDataset for consistency and to avoid it hiding the same-named method in the base class. This will require opening the designer and adjusting the property value, in projects that make use of this.

Breaking Changes in RemObjects SDK 4.0.7 for Delphi

TROEventSessionManager.OnFindSession event signature had to be changed for future C++Builder compatibility. This will affect applications using that component; it will be necessary to open the DFM, ignore the error and manually convert the event handler (bug id #1550).

The IROServerEventsBroker .RegisterClient and UnregisterClient method have been renamed to RegisterEventClient and UnregisterEventClient, for clarity. These methods should not have been used directly by existing user code (but are needed in the future for compatibility with .NET event callback clients), so existing code should not be affected (bug id #1439).

CodeGen for Delphi will now always prefix enum value names with the enum type name (ie "Color_Blue"), to avoid conflicts with duplicate names in several enums (say, "Mood_Blue"), which are nut supported by the Delphi language. The previous system of only prefixing conflicting values produced inconsistent results when the RODL file changed.

Breaking Changes in RemObjects SDK 4.0 for Delphi

Due to slight changes in the architecture, _Intf and _Invk files need to be regenerated to compile with version 4.0. In most scenarios, this will happen automatically when you rebuild your applications from the IDE.

TRODynamicRequest has been reworked to make use of a TRORemoteService internally and to be usable by Data Abstract's Data Table and Remote Data Adapter. As a result, some property names and event names have changed.

Code Generation in v3 and below used Library Name and RODL file name inconsistently for unit name generation. This has been addressed to always use the Library name. Manual adjustments of your RODL files to match the proper unit file name might be required in some rare cases. (bug id #118)

In v3, Variants containing WideString types were streamed as 8-bit strings, losing data. This has been addressed to use UTF-8 for v4, but might break wire-compatibility against affected v3 clients or servers that do not expect UTF-8 encoded data. (bug id #549)

Several exception classes have been renamed and restructured. These changes are unlikely to affect user code unless you have explicit references to them in your try/except statements. If you encounter compile errors, please refer to the (short) list of exceptions in the Reference to find the new respective exception type.


Overview of RO Components

RemObjects SDK provides the following components in the Delphi Component Palette (or Tool Palette) that can be dropped onto your forms, data modules or services at design time.

Some of these components are intended to be used on the client side (such Channels, Remote Service, Dynamic Request), some on the server (Servers, Session Managers, etc.) and yet others will be shared on both sides (such as Messages).

Component List

The following components are provided by RemObjects SDK:
Component(s)	Description
Channel Components	These are the channel components, that are used on the client side to establish a communication to the server. Different types of channels are available (indicated by the overlay icon in the bottom corner), and for some of the types, different implementations are provided (indicated by letters in the top left corner, for Indy, or Synapse). Channels and Servers of same type are wire-compatible. Please refer to the Channels topic for a detailed comparison of the different channels and servers.
Server Components (aka Server Channel Components)	These are the server components, which are used ton the server side to make the application accessible to clients. As with channels, different types are available (indicated by the overlay icon in the bottom corner), and for some of the types, different implementations are provided (again, indicated by letters in the top left corner, for Indy, BPDX or Synapse). Channels and Servers of same type are wire-compatible. Please refer to the Channels topic for a detailed comparison of the different channels and servers.
Message Components	These are the message components, used to encode the requests and responses that are passed between client and server. The message format is indicated by a small letter in the upper right corner, for BinMessage PostMessage, SOAP and XMLRPC. Please refer to the Messages topic for a detailed comparison of the different message formats.
Session Manager Components	Session Managers are used to persist per-client information, so called session data, between calls. Different types of Session Managers are provided out of the box to suit individual needs; please refer to the Session Management help topic for a more detailed discussion on sessions and the different session manager components
Event Repository Components	Event Repositories build on top of the session manages to store and process callback events that will be sent back to individual clients. Please refer to the upcoming Event Sinks and Server Callbacks topic for more details.
Event Receiver Component	Event Receivers are used on the client side to poll or actively receive callback event messages from a server, and initiate execution of the events. Please refer to the upcoming Event Sinks and Server Callbacks topic for more details.
Discovery Components	The Discovery Client and Server are special components that can be used to discover available servers on the local network, based on load or published services.
Remote Service Component	The Remote Service component is used to represent the connection to a remote service - both the channel and message component as well as the name of the service. See the TRORemoteService help topic for more details
Dynamic Request Component	The Dynamic Request component can be used to construct requests to a server dynamically a runtime, without the method information or a proxy object being available at compile time. See the TRODynamicRequest help topic for more details.
"Powered By" Button	Let the world know that you use RemObjects SDK by adding this button to your application's About Box. The button provides two views, featuring the client and the server icon. Clicking the button will launch the RemObjects Software website (www.remobjects.com) in the user's web browser.


TROEncryption.UseCompression

Specifies whether to compress the messages as part of the encryption process, or not. Compression will only apply if the EncryptionMethod is set to a value other then tetNone.

Notes

The use of UseCompression is discouraged, instead, we recommend to use the compression provided by the BinMessage message format.

See Also

EncryptionMethod property


See Also

EncryptionMethod property


TROEncryption.EncryptionMethod

Specifies the type of encryption method to be used. Available options are:

None - no encryption, default

DES encryption

BlowFish

TwoFish

Rijndael (AES)

See Also

EncryptionSendKey and EncryptionRecvKey properties


See Also

EncryptionSendKey and EncryptionRecvKey properties


TROEncryption.EncryptionRecvKey

Specifies the key to be used for decrypting incoming messages. This must match the EncryptionSendKey, on the other side of the communication.

Note that the specific content of the key depends on the selected EncryptionMethod; property editors are provided at design-time to allow you to specify and generate appropriate keys.

See Also

EncryptionSendKey and EncryptionMethod properties


See Also

EncryptionSendKey and EncryptionMethod properties


TROEncryption.EncryptionSendKey

Specifies the key to be used for encrypting outgoing messages. This must match the EncryptionRecvKey, on the other side of the communication.

Note that the specific content of the key depends on the selected EncryptionMethod; property editors are provided at design-time to allow you to specify and generate appropriate keys.

See Also

EncryptionRecvKey and EncryptionMethod properties


See Also

EncryptionRecvKey and EncryptionMethod properties


Programming with RemObjects SDK

This topic collection provides you with information about the architecture of RemObjects SDK and the Concepts involved with writing RemObjects SDK applications.

It will also introduce you to the IDE Integration provided for Microsoft Visual Studio (Edition for .NET) and Borland Delphi/Developer Studio (Editions for .NET and Delphi)

Finally, it will provide an overview of the differences between the .NET and Delphi versions of RemObjects SDK, making it easy for users familiar with the Delphi edition to get productive using RemObjects SDK for .NET (or vice-versa).

See Also

Tutorials and Additional Information help topic


Topics

Topics

Concepts

This topic collection provides you with information about the architecture of RemObjects SDK and the concepts involved with writing RemObjects SDK applications.


IDE Integration

IDE Integration

The RemObjects Menu

RemObjects SDK adds a new top level item to the Delphi main menu that provides access to functionality specific to RemObjects SDK (and related products, such as Data Abstract, where applicable).

The items available in this menu will vary dynamically depending on whether the active project is supported by RemObjects SDK for Delphi and whether the current project already is a a RemObjects SDK Server or not.

New Project Templates

RemObjects SDK integrates with Delphi's New Item dialog to provide an extensive set of different project templates to help you get started writing RemObjects SDK server projects.

These templates can be found in a special RemObjects SDK sub-folder below Delphi Projects (in Delphi 2005 and up), and on the RemObjects SDK tab in Delphi 7 and below:

Importing Services

Client applications can use the Import RemObjects SDK Service... item on the RemObjects menu to import the definition of an existing service (either from a local RODL file or from a live HTTP server running on the net).

Selecting the menu item will present the following dialog which allows to specify the location of the RODL or the address of the server.

After importing, the IDE will generate an Intf source file in the appropriate language and add it to the project.

When importing into a Visual Studio 2005 Web project, the dialog will offer the option to choose the... more


See Also

Tutorials and Additional Information help topic


Concepts

This topic collection provides you with information about the architecture of RemObjects SDK and the concepts involved with writing RemObjects SDK applications.


Topics

Topics

Channels

Channel components are the heart of RemObjects SDK. They connect your client applications and your server applications by sending Messages back and forth, to submit a request, return a response, fire a callback event, etc. No matter what type of application you are building with RemObjects SDK, channels will be an integral part of it.

To accommodate for a wide variety of scenarios and provide flexibility, RemObjects SDK includes a pretty extensive list of channel components, which in some cases might be difficult to choose for the novice user. This topic provides a brief overview of all available channel types.

Note... more

Messages

Messages provide the second corner stone of client/server communication in RemObjects SDK, next to Channels.

In order for any information to be passed from client to server or from server to client, this information must be encoded in a way that both sides can understand it. Message components provide this functionality by offering the means to encode parameters, method name and other related information in a predetermined format and writing it to a stream that can be passed over the network - or reading a stream and decoding the respective information again.

Different message formats are provided for different needs... more

Class Factories

RemObjects SDK uses so called Class Factories to control how and when instances of your service implementations will be created and destroyed, and how they will serve requests coming on from remote clients.

Each service you define in your RODL file, and subsequently implement, will be associated with a specific type of class factory. Whenever a new request comes in from a client, its class factory will be asked to provide an available instance that can serve the request, and whenever a request is finished, that instance is released back to the class factory.

It is up to the... more

Statelessness

One of the cornerstones of creating multi-tier applications that can easily be scaled up and scaled out is the avoidance of per-client state in the server-side objects.

Session Management

Sometimes it is sensible to maintain a little bit of client state between calls, even if your application is designed for statelessness. For example, your might want to implement access control and provide a Login method to initiate authentication, rather than retransmitting the password for each and every remote call. This can be achieved through so called Sessions that allow you to store per-client information outside of your service objects. It will be up to your service implementation to store this data inside the session before a call finishes, and obtain it again, when needed, in subsequent calls.

RemObjects SDK... more

Login and Authentication

One of the key requirements of most multi-tier applications is to limit access to a specific group of authorized users, and possibly to apply different restrictions of access to different users accessing the server.

When writing real life business applications with RemObjects SDK or Data Abstract, one important concern is security. Chances are that your middle tier server is exposing sensitive data that you would not want any anonymous user on your local LAN (or worse, the entire Internet) to access or even modify. A login system is needed to ensure that only authorized users can get access to the... more

RODL Files

RODL (short for RemObjects Definition Language) files form one one the foundations of RemObjects SDK, and are used to define the interface of the services that a RemObjects 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 several advantages over these:

they are XML based, which makes them easily readable by both humans and computers... more

Data Types

RemObjects SDK supports a variety of data types that are available when designing your service interface in Service Builder. Because RemObjects SDK supports different platforms, it uses common names to refer to these data types - which might not necessarily be the same as those used by your language of choice.

The following section gives a brief introduction to the data types available and it explains what underlying .NET or Delphi types are used by RemObjects SDK.

Smart Services

When it was first released in 2003, RemObjects SDK introduced the concept of Smart Services™, the idea to combine efficient, proprietary communication methods with open standard systems to make your services available to a wide range of clients without compromising efficiency.

Often times you are implementing a service that you want to open up to third parties - either by making it publicly accessible to any users or by selling access to the service to selective customers. In this scenario, one cannot reasonably expect all clients to use RemObjects SDK (or even one of the languages, platforms or operating systems... more

Asynchronous Calls

Since version 3.0, RemObjects SDK provides the option to execute requests against remote services in an asynchronous fashion.

When performing normal (synchronous) calls against your server, the thread making the server call will block, and wait until the request has been executed on the server and a response has been received. In most cases this is the preferred way to make calls, as it closely resembles the paradigm you are used to from calling local methods within your application.

In some scenarios, it might be helpful to trigger an action on the server, but continue with local processing as the... more

Event Sinks and Server Callbacks

In most scenarios of multi-tier applications the client takes the active role of sending requests to the server, while the server passively waits for requests, processes them and sends back a response.

Sometimes, you will find the need to have the server actively contacting one of more clients to notify them of specific events. For example, a database application might notify a client about changes to specific records made by a different user, or a chat system might forward messages sent by one client to a group of other clients logged onto the same chat room.

RemObjects SDK provides the... more

Service Discovery

RemObjects SDK provides a default infrastructure for discovering servers and services available on the local network. This can be used to automatically detect new servers that have become available if an old server has gone down, or to automatically distribute calls to different servers across the network based on information such as server load or custom criteria.

The Service discovery infrastructure is implemented using standard principles on top of the general RemObjects SDK architecture - it provides merely a reference implementation, and you could easily implement your own similar or different solution to fit your needs.


Channels

Channel components are the heart of RemObjects SDK. They connect your client applications and your server applications by sending Messages back and forth, to submit a request, return a response, fire a callback event, etc. No matter what type of application you are building with RemObjects SDK, channels will be an integral part of it.

To accommodate for a wide variety of scenarios and provide flexibility, RemObjects SDK includes a pretty extensive list of channel components, which in some cases might be difficult to choose for the novice user. This topic provides a brief overview of all available channel types.

Note that for historic reasons, the SDK for Delphi uses the terminology "Channel" for client channels, and "Server" for server channels, while the .NET edition properly refers to "client channel" and "server channel". Besides these naming differences, the same concepts apply for both platforms.

Commonly Used Channels

HTTP Channels - flexible and network independent communication using the World Wide Web's Hypertext Transfer Protocol.

Super TCP Channel - sophisticated and flexible two-way communication between clients and servers.

Frequently Users Channels

Legacy TCP Channels - lightweight communication over raw TCP.

Email Channels - asynchronous communication over existing email infrastructure (Delphi only, as of now).

Local Channels - direct communication within the same application.

Rarely Used Channels

UDP and Broadcast Channels - lightweight packet based communication (Delphi only).

Named Pipe Channel - inner-LAN communication without TCP/IP network protocol (Delphi only).

WinMessage Channel - inter-process communication without network on a local computer (Delphi only).

See Also

Messages help topic


Topics

Topics

Compatible Channels

The following table lists all ClientChannels (Channels) and ServerChannels (Servers) available with the .NET and Delphi editions of the product.

Client and server components listed in the same table row are interchangeable and compatible with each other, both within the same platform, and between Delphi and .NET. For example, any of the available HTTP clients can talk to any of the HTTP servers.

The color-coding indicates which components are available for .NET (green) and which for Delphi (blue).

Please refer to the individual topics for the specific channel types for more detailed information.

HTTP Channels

The most commonly used channels are probably those based on the Hypertext Transfer Protocol. The HTTP protocol, which forms the basis for the world wide web, is one of the most used protocols on the internet, and provides a variety of benefits when used for communication within RO: 	Due to the widespread use of HTTP, the protocol can be easily used even in restrictive network environments where firewalls or proxy servers are used to sperate the client from the internet. If end-users have access to the internet via web browser, chances are high that HTTP based channels will work out-of-the-box,... more

Super TCP Channel

The new Super TCP Channel components, introduced in version 4.0 of the SDK, provide a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

Leveraging a custom-defined protocol on top of a raw TCP connection, the channel allows for many advanced features lacking for the more traditional channel types:

Keep-Alive connections, with flexible ping/pong system to discover broken connections (for example due to network outages) and seamless recovery.

Out of band server/client communications enable the server to actively send events or asynchronous responses back to the client without need for polling... more

Legacy TCP Channels

TCP, the Transmission Control Protocol, is one of the two basic low-level protocols that for the basis of the internet with its TCP/IP network stack, and provides a stream based connection between a client and a server host. While TCP also provides the foundation for most more complex protocols such as HTTP, POP3 etc, the TCP Channels uses a lightweight protocol over raw TCP, introducing basically zero traffic overhead on top of the transmitted message data.

Email Channels

The Email channels implements asynchronous communication by using standard email and existing POP3 and SMTP servers to send requests to a server and retrieve responses.

The client channel will be configured with the server's email address and use that address to send requests off to the server for processing. The server will retrieve these emails from a POP3 mailbox, process the requests and eventually send the results back to the client, again via email. The client channel can poll its own POP3 mailbox to obtain the response.

Local Channels

The Local channels allows RemObjects SDK based communication within a single .NET or Delphi application; enabling you easily to reuse your client and server in a monolithic application, or to build single tier applications that can later be scaled out easily by changing cannel types.

In addition, the (currently Delphi only) DLL channel allows you to implement server logic inside a DLL and access it using the standard RemObjects SDK calling mechanisms. The channel will automatically load the DLL into the client process and expose the server methods in the same fashion as a remote server would.

UDP and Broadcast Channels

Next to TCP, UDP is the second base transfer protocol of the internet's TCP/IP network infrastructure. In contrast to TCP, UDP does not provide the concept of a stream based connection between client and server, but instead sends individual data packets - so called datagrams over the network.

UDP also provides no error correction or guaranteed delivery, so packets sent via UDP might get lost and not arrive at the target destination, or get corrupted and simply discarded. On the upside, the UDP protocol is very fast and efficient compared to TCP.

Named Pipe Channel

This (currently Delphi only) channel provides communication between a client and server using Window's Named Pipes feature. Please refer to the Platform SDK or MSDN documentation on Named Pipes for more details.

WinMessage Channel

This (currently Delphi only) channel provides communication by sending Windows Messages between the client and the server application.

While providing an easy way for Inter Process Communication on a single computer, Windows Messages have several limitations - they cannot be used to communicate servers running as Windows Services, and they rely on a Windows Message Loop being active in both client and server. Please refer to the Platform SDK or MSDN for more details on these concepts.


See Also

Messages help topic


Compatible Channels

The following table lists all ClientChannels (Channels) and ServerChannels (Servers) available with the .NET and Delphi editions of the product.

Client and server components listed in the same table row are interchangeable and compatible with each other, both within the same platform, and between Delphi and .NET. For example, any of the available HTTP clients can talk to any of the HTTP servers.

The color-coding indicates which components are available for .NET (green) and which for Delphi (blue).

Please refer to the individual topics for the specific channel types for more detailed information.

Client Channels	Server Channels
IpHttpClientChannel WinInetHttpClientChannel TROIndyHttpChannel TROWinInetNetHttpChannel See HTTP Channels for more details	IpHttpServerChannel TROPIndyHttpServer TROBPDXHttpServer TROWebBrokerServer
IpTcpClientChannel TROIndyTcpChannel See Legacy TCP Channels for more details	IpTcpServerChannel TROIndyTcpServer TROBPDXTcpServer
SuperTcpClientChannel TROSuperTcpChannel See Super TCP Channel for more details	SuperTcpServerChannel TROSuperTcpServer
EmailClientChannel TROEmailChannel See Email Channels for more details	EmailServerChannel TROEmailServer
LocalClientChannel See Local Channels for more details	LocalServerChannel
TROLocalChannel See Local Channels for more details	TRPOLocalServer
TRODLLChannel See Local Channels for more details	"DLL Server" Project template
TRONamedPipeChannel See Named Pipe Channel for more details	TRONamedPipeServer
TROIndyUdpChannel See UDP and Broadcast Channels for more details	TROIndyUdpServer
TROBroadcastChannel See UDP and Broadcast Channels for more details	TROBroadcastServer


HTTP Channels

The most commonly used channels are probably those based on the Hypertext Transfer Protocol. The HTTP protocol, which forms the basis for the world wide web, is one of the most used protocols on the internet, and provides a variety of benefits when used for communication within RO:

Due to the widespread use of HTTP, the protocol can be easily used even in restrictive network environments where firewalls or proxy servers are used to sperate the client from the internet. If end-users have access to the internet via web browser, chances are high that HTTP based channels will work out-of-the-box, as well.

Server addresses are identified by standard URLs, making it easy and intuitive for the end user to handle addressing.

If desired, HTTP channels can provide human-readable information about the server and the published services, when accessed from a standard web browser.

In summary, HTTP is the best protocol to use if you have little control over the network infrastructure at the deployment site, and want your clients to easily work on a wide variety of networks.

Several implementations of HTTP client and server channels are provided in both editions, and the decision over which ones to use is mostly a matter of preference and taste. All of the HTTP clients are compatible with any of the HTTP servers, and vice versa.

It is worth noting that the WinINET based client channels for both Delphi and .NET will make use of networking options set up for Internet Explorer, including proxy settings and automatic dialup rules, while the Indy and Internet Pack channels use their own HTTP implementation on top of raw TCP.

On the Delphi side, the BPDX server channels provide the best performance and most flexibility, but can be more resource-hungry than the light-weight Indy server channels.

Client Channel Components

IpHttpClientChannel (.NET)

WinInetHttpClientChannel (.NET)

TROIndyHttpChannel (Delphi)

TROWinInetHTTPChannel (Delphi)

Server Channel Components

IpHttpServerChannel (.NET)

WebProcessor (ASP.NET)

TROIndyHTTPServer (Delphi)

TROBPDXHttpServer (Delphi)

TROWebBrokerServer (Delphi)

See Also

HyperText Transfer Protocol on Wikipedia


See Also

HyperText Transfer Protocol on Wikipedia


Super TCP Channel

The new Super TCP Channel components, introduced in version 4.0 of the SDK, provide a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

Leveraging a custom-defined protocol on top of a raw TCP connection, the channel allows for many advanced features lacking for the more traditional channel types: 	Keep-Alive connections, with flexible ping/pong system to discover broken connections (for example due to network outages) and seamless recovery.

Out of band server/client communications enable the server to actively send events or asynchronous responses back to the client without need for polling - reducing network traffic and efficiency for these callbacks.

Use Cases

Use this channel for scenarios where extensive use is made of events and server callbacks, and wherever firewalls and proxy servers do no require the use of HTTP based channels.

Client Channel Components

SuperTcpClientChannel  (.NET)

TROSuperTcpChannel (Delphi)

Server Channel Components

SuperTcpServerChannel  (.NET)

TROSuperTcpServer (Delphi)

Notes

The Super TCP Channel is not wire compatible with the legacy TCP Channel components.


Legacy TCP Channels

TCP, the Transmission Control Protocol, is one of the two basic low-level protocols that for the basis of the internet with its TCP/IP network stack, and provides a stream based connection between a client and a server host. While TCP also provides the foundation for most more complex protocols such as HTTP, POP3 etc, the TCP Channels uses a lightweight protocol over raw TCP, introducing basically zero traffic overhead on top of the transmitted message data.

Use Cases

The TCP Channels are the perfect choice when traffic minimization is a must and firewalls are not an issue. The TCP channel will provide the best possible performance for method calls, in this scenario.

On the Delphi side, the BPDX server channels provide the best performance and most flexibility, but can be more resource-hungry then the light-weight Indy server channels.

Client Channel Components

IpTcpClientChannel  (.NET)

TROIndyTcpChannel (Delphi)

Server Channel Components

IpTcpServerChannel  (.NET)

TROIndyTcpServer (Delphi)

TROBPDXTcpServer (Delphi)

Notes

The TCP Channel components are not wire compatible with the new Super TCP Channel.

See Also

Transmission Control Protocol on Wikipedia


See Also

Transmission Control Protocol on Wikipedia


Email Channels

The Email channels implements asynchronous communication by using standard email and existing POP3 and SMTP servers to send requests to a server and retrieve responses.

The client channel will be configured with the server's email address and use that address to send requests off to the server for processing. The server will retrieve these emails from a POP3 mailbox, process the requests and eventually send the results back to the client, again via email. The client channel can poll its own POP3 mailbox to obtain the response.

Use Cases

This channel is ideal for running requests with long execution times that could potentially outlive a single client session. Since requests and responses are persisted in POP3 email boxes, a client application could send a request, exit, and then retrieve the response hours or even days later. Similarly, requests can be sent to a server that might not currently be running - when the server starts up it will catch up and process emails that are waiting in its email inbox.

Client Channel Components

EmailClientChannel (.NET)

TROEmailChannel (Delphi)

Server Channel Components

EmailServerChannel (.NET)

TROEmailServer (Delphi)


Local Channels

The Local channels allows RemObjects SDK based communication within a single .NET or Delphi application; enabling you easily to reuse your client and server in a monolithic application, or to build single tier applications that can later be scaled out easily by changing cannel types.

In addition, the (currently Delphi only) DLL channel allows you to implement server logic inside a DLL and access it using the standard RemObjects SDK calling mechanisms. The channel will automatically load the DLL into the client process and expose the server methods in the same fashion as a remote server would.

Use Cases

While at first sight it might seem useless to partition application logic into client and server and then proceed to embed both parts in the same executable, these channels are helpful for two scenarios, especially when combined with the Data Abstract database multi-tier architecture: 	to implement a single-tier application with scalability in mind, so that it can easily be scaled up to a true multi-tier solution, when the need arises.

to reuse an existing multi-tier application and deploy it in a single-tier environment - for example to sell a single-user edition of the product, or to provide a desktop version of a client/server database front end.

In both cases, and similar scenarios, the local channels make it easy to combine the client and server tier in a single application, with negligible communication overhead between the tiers, but maintaining the logical multi-tier separation.

Client Channel Components

LocalClientChannel  (.NET)

TROLocalChannel (Delphi)

TRODLLChannel (Delphi)

Server Channel Components

LocalServerChannel  (.NET)

TROLocalServer (Delphi)


UDP and Broadcast Channels

Next to TCP, UDP is the second base transfer protocol of the internet's TCP/IP network infrastructure. In contrast to TCP, UDP does not provide the concept of a stream based connection between client and server, but instead sends individual data packets - so called datagrams over the network.

UDP also provides no error correction or guaranteed delivery, so packets sent via UDP might get lost and not arrive at the target destination, or get corrupted and simply discarded. On the upside, the UDP protocol is very fast and efficient compared to TCP.

Use Cases

You should consider using the UDP based channels if you need to send small data packets at high frequency and very efficiently, and you don't need to rely on network error correction and package recovery features provided by TCP. Most likely this will be in LAN scenarios, where network infrastructure is dependable and chances of packet loss are minimal.

The Broadcast channel is a variation of the UDP channel that allows to send requests to all available servers listening on the local network using UDP broadcast. This is useful in notification scenarios, or for discovering available servers.

You will usually use both of these channels in asynchronous mode; For broadcast scenarios, your servers will either call ROSendNoResponse to prevent any response form being sent (so that a large number of recipients can quietly swallow a notification message), or your client will be prepared to receive multiple responses.

Client Channel Components

TROIndyUdpChannel (Delphi)

TROBroadcastChannel (Delphi)

Server Channel Components

TROIndyUdpServer (Delphi)

TROBroadcastServer (Delphi)

See Also

User Datagram Protocol on Wikipedia


See Also

User Datagram Protocol on Wikipedia


Named Pipe Channel

This (currently Delphi only) channel provides communication between a client and server using Window's Named Pipes feature. Please refer to the Platform SDK or MSDN documentation on Named Pipes for more details.

Client Channel Components

TRONamedPipeChannel (Delphi)

Server Channel Components

TRONamedPipeServer (Delphi)


WinMessage Channel

This (currently Delphi only) channel provides communication by sending Windows Messages between the client and the server application.

While providing an easy way for Inter Process Communication on a single computer, Windows Messages have several limitations - they cannot be used to communicate servers running as Windows Services, and they rely on a Windows Message Loop being active in both client and server. Please refer to the Platform SDK or MSDN for more details on these concepts.

Client Channel Components

TROWinMessageChannel (Delphi)

Server Channel Components

TROWinMessageServer (Delphi)


Messages

Messages provide the second corner stone of client/server communication in RemObjects SDK, next to Channels.

In order for any information to be passed from client to server or from server to client, this information must be encoded in a way that both sides can understand it. Message components provide this functionality by offering the means to encode parameters, method name and other related information in a predetermined format and writing it to a stream that can be passed over the network - or reading a stream and decoding the respective information again.

Different message formats are provided for different needs and both client and server must use compatible message formats to successfully communicate - for example a BinMessage encoded call cannot be decoded by a SOAP message, or vice versa.

Just like with channels, matching message types are compatible between the different editions of RemObjects SDK for .NET or Delphi, so for example a .NET client can use the RemObjects.SDK.BinMessage class to talk to a Delphi server using TROBinMessage.

The preferred message format for the vast majority of cases will be BinMessage, as it provides the most efficient transfer, both from a seep and bandwidth perspective. SOAP, on the other hand is useful for accessing existing Web Services provided by third parties using this widely-used format, or to publish servers that should be accessible by non-RemObjects SDK clients.

To provide more flexibility, RemObjects SDK introduces the concept of Smart Services™ that allows you to create servers that are exposed through a variety of different message formats, at the same time. This enables you to create servers that can use the efficient BinMessage when talking to your own clients, while still being open to third parties via SOAP and/or XML-RPC.

Commonly Used Message Types

BinMessage - fast and efficient communication using a proprietary binary format.

SOAP Message - standards based communication with SOAP Web Services.

Infrequently Used Message Types

XML-RPC Message - standards based communication using the simple XML-RPC protocol.

PostMessage - simple text-based messaging (Delphi only).

See Also

Channels help topic


Topics

Topics

BinMessage

BinMessage is by far the preferred message format for the vast majority of RemObjects SDK applications.

It provides the best performance and keeps network traffic to a minimum by using a highly condensed binary format that contains little-to-none overhead on top of the actual data. It also provides compression options (using the ZLib compression format) to reduce packet size even further, for cases where network bandwidth is limited.

Implementations of BinMessage are provided for both .NET and Delphi, and both implementations are wire compatible, allowing you to mix clients and servers from the different platforms.

SOAP Message

The Simple Object Access Protocol (SOAP) is a standardized XML based protocol for exchanging messages between client and server, and forms the foundation of Web Services.

SOAP is widely used across the internet and implementations exist for virtually every conceivable platform - making SOAP messaging the ideal format for exposing your services to a wide variety of consumers, or accessing existing web services provided by others.

Since SOAP is an open standard and not specific to RemObjects SDK, it easily enables communication with non-RO systems.

SOAP has disadvantages over the RO's own BinMessage format in that it is based on XML... more

XML-RPC Message

XML-RPC is an standards-based protocol that can be considered the predecessor of SOAP.

Like SOAP, it is based on XML, but its definition is a lot simpler, resulting in a cleaner message format and less risk of differences and incompatibilities than SOAP.

PostMessage

PostMessage is a simple text-based messaging format that is compatible with the way HTML Forms are posted back to the server via HTTP.


See Also

Channels help topic


BinMessage

BinMessage is by far the preferred message format for the vast majority of RemObjects SDK applications.

It provides the best performance and keeps network traffic to a minimum by using a highly condensed binary format that contains little-to-none overhead on top of the actual data. It also provides compression options (using the ZLib compression format) to reduce packet size even further, for cases where network bandwidth is limited.

Implementations of BinMessage are provided for both .NET and Delphi, and both implementations are wire compatible, allowing you to mix clients and servers from the different platforms.

Use Cases

You will generally use BinMessage for the majority of applications as it provides the best performance and network throughput, unless you have explicit seasons to use one of the other messaging formats, instead.

Components

BinMessage (.NET)

TROBinMessage (Delphi)


SOAP Message

The Simple Object Access Protocol (SOAP) is a standardized XML based protocol for exchanging messages between client and server, and forms the foundation of Web Services.

SOAP is widely used across the internet and implementations exist for virtually every conceivable platform - making SOAP messaging the ideal format for exposing your services to a wide variety of consumers, or accessing existing web services provided by others.

Since SOAP is an open standard and not specific to RemObjects SDK, it easily enables communication with non-RO systems.

SOAP has disadvantages over the RO's own BinMessage format in that it is based on XML and very verbose, adding a substantial overhead on the data with a message that is often larger than the actual data. The specification is also very ambiguous, resulting in potential differences and incompatibilities with the many SOAP implementations out there.

SOAP also provides its own format for defining the structure of services, comparable to RO's RODL files , so called WSDL (Web Service Definition Language).

RemObjects SDK provides support for importing WSDL files from within Service Builder and the Delphi IDE , and allows clients to retrieve WSDL for services exposed via SOAP Message and HTTP.

Use Cases

Due to its disadvantages over BinMessage, you generally use SOAP only to either communicate with existing Web Services that are provided using SOAP/WSDL by third parties, or to open your own services up to access by other third parties not using RemObjects SDK. In the latter case, you will most likely use Smart Services™ to expose your services as SOAP and BinMessage at the same time.

Components

SoapMessage (.NET)

TROSOAPMessage (Delphi)

See Also

W3C XML Protocol Working Group homepage

Simple Object Access Protocol on Wikipedia


See Also

W3C XML Protocol Working Group homepage

Simple Object Access Protocol on Wikipedia


XML-RPC Message

XML-RPC is an standards-based protocol that can be considered the predecessor of SOAP.

Like SOAP, it is based on XML, but its definition is a lot simpler, resulting in a cleaner message format and less risk of differences and incompatibilities than SOAP.

Use Cases

You would use XML-RPC in scenarios where you need to communicate with existing XML-RPC services, or when communicating with platforms not directly supported by the RemObjects SDK that do provide an XML-RPC implementation - such as Java or PHP.

You might also use XML-RPC when you need a simple human-readable messaging format - for example for debugging or monitoring purposes. In this case, you might also want to consider PostMessage.

Components

XmlRpcMessage (.NET)

TROXmlRpcMessage (Delphi)

See Also

XML-RPC.Com protocol homepage

XML-RPC on Wikipedia


See Also

XML-RPC.Com protocol homepage

XML-RPC on Wikipedia


PostMessage

PostMessage is a simple text-based messaging format that is compatible with the way HTML Forms are posted back to the server via HTTP.

Use Cases

While not really useful in production scenarios, PostMessage makes it easy to post data directly from a HTML form to a service by simply specifying the service url as the "Action" attribute.

You can also use PostMessage when you need a simple human-readable messaging format - for example for debugging or monitoring purposes. In this case, you might also want to consider XML-RPC.

Components

TROPostMessage (Delphi)


Class Factories

RemObjects SDK uses so called Class Factories to control how and when instances of your service implementations will be created and destroyed, and how they will serve requests coming on from remote clients.

Each service you define in your RODL file, and subsequently implement, will be associated with a specific type of class factory. Whenever a new request comes in from a client, its class factory will be asked to provide an available instance that can serve the request, and whenever a request is finished, that instance is released back to the class factory.

It is up to the class factory implementation itself to determine how and when to create and dispose service instances, or how to match existing instances to any given incoming request.

Available Class Factory Types

RemObjects SDK comes with a number of ready-to-use class factories that cover the most common use cases. The class factory framework is extensible, allowing you to implement your own class factories if you need more control or have a scenario not covered by the existing ones.

The class factories provided with RemObjects SDK include: 	Per-request instantiation - a new service instance will be created for each incoming request, and destroyed afterwards (default)

Singletons - a single service instance will be used to serve all calls (with different synchronization options for thread safety)

Pooling - a pool of instances will be maintained to server incoming requests

Per-Client instantiation - every client will be served by a distinct service instance

Selecting the Class Factory

How RemObjects SDK determines the class factory to use for your service implementation differs slightly between the different platforms.

In .NET, attributes are attached to the implementation class to select the appropriate class factory. The RemObjects.SDK.Server.ClassFactories namespace provides attributes for each of the available class factories. Where additional configurations are available, parameters can be passed to the attribute.

In Delphi, a class factory is created and registered in the initialization section of the service implementation unit.

On both platforms, the default class factory used is the per-request Standard Class Factory; you can change this simply by providing the proper type name of the class factory you want to use instead.


Topics

Topics

Standard Class Factory

This is the default class factory for new services and it implements a minimal activation model by simply creating a new instance for each incoming request and destroying the instance after the request has completed.

Singleton Class Factory

The Singleton Class Factory creates a single instance of the service class and uses this same instance to execute all requests coming in from clients.

Options are provided to either allow several client requests to run simultaneously, or to synchronize requests so that only one request at a time is answered. It depends on whether the implementation of your service is already thread-safe or does its own thread synchronization where needed.

Pooled Class Factory

The Pooled Class Factory maintains a list of instances of services available to serve requests. Rather than creating a separate instance for each call or always using the same instance, TROPooledClassFactory creates a predefined number of instances and returns the first one currently available to the caller.

Options are provided to control the size of the pool and the behavior in case all pooled instances are active; please refer to the class reference for the factories for details.

Per-Client Class Factory

The Per-Client Class Factory will maintain separate service instances on each client and ensure that subsequent calls from the same client will be served by the same instance. This allows to store per-client state inside the class fields between calls, but limits scalability of the server, because the the number of active service instances (and with it, the memory consumption) will grow linearly with the number of clients.

A timeout can be provided, after which services instances linked to clients that have been inactive will be destroyed.


Standard Class Factory

This is the default class factory for new services and it implements a minimal activation model by simply creating a new instance for each incoming request and destroying the instance after the request has completed.

Use Cases

This class factory is most commonly used for simple service objects that are cheap to construct and destroy, and on servers with low or average load.

Class Factory Types

StandardClassFactory (.NET)

TROClassFactory (Delphi)


Singleton Class Factory

The Singleton Class Factory creates a single instance of the service class and uses this same instance to execute all requests coming in from clients.

Options are provided to either allow several client requests to run simultaneously, or to synchronize requests so that only one request at a time is answered. It depends on whether the implementation of your service is already thread-safe or does its own thread synchronization where needed.

Use Cases

Use the singleton class factory in scenarios where a common set of server data is shared by all clients, or for simplistic services that do not rely on any per-instance state to be stored inside the class.

If your service code is fully contained in the respective method and does not rely on any class-wide fields, the (unsynchronized) singleton model will provide best performance.

Class Factory Types

SingletonClassFactory (.NET)

TROSingletonClassFactory (Delphi)

TROSynchronizedSingletonClassFactory (Delphi)


Pooled Class Factory

The Pooled Class Factory maintains a list of instances of services available to serve requests. Rather than creating a separate instance for each call or always using the same instance, TROPooledClassFactory creates a predefined number of instances and returns the first one currently available to the caller.

Options are provided to control the size of the pool and the behavior in case all pooled instances are active; please refer to the class reference for the factories for details.

Use Cases

The pooled class factory is the most commonly used factory for high performance and high load services. It avoids the cost of repeatedly creating/destroying service instances (as with the Standard Class Factory) while at the same eliminating the overhead of keeping an instance per client (as with the Per-Client Class Factory).

It is worth mentioning that with this class factory (as with the Singleton one), instances will be shared between different clients, so care must be taken that the service is designed with statelessness in mind, and no client-specific data is stored in class fields between calls. Refer to the Session Management topic for alternative ways to persist per-client information between calls.

Class Factory Types

PooledClassFactory (.NET)

TROClassFactory (Delphi)


Per-Client Class Factory

The Per-Client Class Factory will maintain separate service instances on each client and ensure that subsequent calls from the same client will be served by the same instance. This allows to store per-client state inside the class fields between calls, but limits scalability of the server, because the the number of active service instances (and with it, the memory consumption) will grow linearly with the number of clients.

A timeout can be provided, after which services instances linked to clients that have been inactive will be destroyed.

Use Cases

Use the per-client class factory if you need per-client data in class fields to be persisted between calls. You should limit the use of this class factory to scenarios where the number of users is reasonably small, and consider use of the Pooled Class Factory and Session Management if you expect a large or unlimited number of users accessing your server.

Class Factory Types

PerClientClassFactory (.NET)

TROPerClientClassFactory (Delphi)


Statelessness

One of the cornerstones of creating multi-tier applications that can easily be scaled up and scaled out is the avoidance of per-client state in the server-side objects.

Stateful Servers

Service objects that maintain per-client state between calls must remain live for the entire duration the client is working with the server, so that the state contained within the object remains available for every call made by the client. What's more, because state is specific to individual clients, separate copies of the server objects must be kept alive for each individual client.

As your server scales up and the number of clients talking to the server increases, the number of active service instances will increase, and with it the memory footprint of your server application.

Assume you have a server that is capable of handling 100 requests per second, and your average client application will talk to the server every 5 minutes. This would allow your application to serve roughly 30,000 individual clients. Furthermore, assume that every service instance will consume a moderate 10 kB of memory - a conservative assumption for a business object and reasonable working data.

The total memory consumption for all active business objects alone would be roughly 300 MB. At first sight, this might seem like an acceptable load for a dedicated application server - but what happens when you need to scale up? Say you upgrade your connection and CPU to allow 1000 requests per second. Also you might redesign your client application to only talk to the server every 10 minutes, on average, to increase the number of clients you can served. But as your clients increase to 600.000 and beyond, memory load keep increasing with them, to 6000 GB.

Clearly, this approach does not scale up well.

Enter Stateless Servers

If you consider the numbers above, it is apparent that between calls each per-client service instance is stilling idle for a considerable amount of time (4:59 of 5 minutes), waiting for the next call. Since your server is handling 100 requests per second, only 1 MB of memory is actually in active use - the remainder is just waiting for other clients that might - or might not - call sometime in the future.

Service objects designed for statelessness will allow your server to scale up much better, as you will not need to keep individual instances of the service around for each client. Instead, your server will only keep the minimum set of 100 service instances active, and reuse these to process all the requests. After an object is done processing one request, rather then being put to sleep for an average of 5 minutes, it will go right on service the next request (from a different client).

How to Design for Statelessness

The key factor for writing stateless server objects is to write your code so that it does not rely on client-specific information to be stored in fields of your class and be reused between different calls. An example of stateful design would be loading a large set of data into the service during one call from a client, and working with this data on subsequent calls (say, repeated calls to fetch additional rows of a record).

In a stateless server object, each call from the client would be completely independent and not rely on data left over from previous calls. For example, a call to fetch incremental data could pass back the offset from the last call, so the server would know where to resume.

A good practice to make sure your server objects remain stateless is to simply not define any fields for the class, but access only method-local variables and parameters passed from the client.

Class factories for Statelessness

RemObjects SDK provides three Class Factories that work well with stateless services: 	The Singleton Class Factory works well for perfectly stateless server objects, as it forces all calls to be handled by the very same service instance. If your service object is well designed to not use any class fields (and thus is fully thread-safe and reentrant), there is no better and memory-friendlier way then to have one single instance process all requests.

The Pooled Class Factory provides the next best level of stateless services by providing a pool of objects that will be reused to execute requests. If your class does rely on class fields during the execution of individual requests or is for other reasons not fully reentrant, this is your best option, as you can be sure that each instance will only serve one request at a time. However you must sure to not leave client state behind when your calls exit, as the individual instances will be executing requests for other clients.

Finally the Standard Class Factory not only supports but practically enforces statelessness, as it will destroy each service instance after a call finishes - losing any client state - and create a new one for the next call.

Maintaining State in a Stateless World

Sometimes it is sensible to maintain a little bit of client state between calls, even if your application is designed for statelessness. For example, your might want to implement access control and provide a Login method to initiate authentication, rather than retransmitting the password for each and every remote call. This can be achieved through so called Sessions that allow you to store per-client information outside of your service objects. It will be up to your service implementation to store this data inside the session before a call finishes, and obtain it again, when needed, in subsequent calls.

RemObjects SDK provides extensive Session Management capabilities to make this easy.

See Also

Class Factories and Session Management help topics


See Also

Class Factories and Session Management help topics


Session Management

Sometimes it is sensible to maintain a little bit of client state between calls, even if your application is designed for statelessness. For example, your might want to implement access control and provide a Login method to initiate authentication, rather than retransmitting the password for each and every remote call. This can be achieved through so called Sessions that allow you to store per-client information outside of your service objects. It will be up to your service implementation to store this data inside the session before a call finishes, and obtain it again, when needed, in subsequent calls.

RemObjects SDK passes a so called Client ID (sometimes also referred to as Session ID) back and forth for each call made from a client to the server. This client ID is a GUID that uniquely identifies each clients and allows the server to determine which calls are received from the same client.

Sessions

Sessions can be used to store data for a specific client ID and later retrieve the same data again. To make this easy, the base classes for new services (RemObjects.SDK.Server.Service for .NET and TRORemoteDataModule for Delphi) encapsulate the communication with the underlying session manager and expose properties to check if session data exists, and to store and retrieve data from the session.

Session Managers

Session data is stored and maintained by a global Session Manager instance. Different implementations of session managers are provided to suit different needs, for example to store session data in memory or a back-end database. 	In-Memory Session Manager - stores session data in local memory within the application server. This provides fast access, but does not allow to persist session information when the server is restarted, or to share common session data by a server farm.

Database Session Manager - stores session data in a database table accessible via ADO.NET, a Delphi TDataSet component or a Data Abstract server. This allows sharing of session data between servers, and keeps session information persisted across server restarts (currently Delphi-only).

Master Server Session Manager - stores session data in a pre-compiled mini database server provided with the RemObjects SDK, the so called Master Server . Provides the same benefits as the database session managers, without the need to manually maintain a database or database server.

Event-Driven Session Manager - provides an easy way to use custom code to manually store and retrieve session data (currently Delphi-only).

The session manager architecture is flexible and extensible, allowing you to easily implement custom session managers to suit your specific needs, if necessary.

Session Timeouts

Application servers are usually intended to run continuously 24/7, without ever shutting down. As such, session memory would continue to grow slowly but steadily over the lifetime of a server, as new clients connect and disconnect. What's more, in most scenarios client applications will not maintain their unique client ID across restarts (although such functionality is possible, if required), so each restarted client will create a new session.

To avoid the server memory (or session database) filling up with stale and unused session data, Session Managers implement automatic session timeouts. The session managers keep track of sessions as they are accessed, and will destroy any session that has not been accessed for a given amount of time (by default 20 minutes).

Client applications that are expected to run longer periods of time without communication with the server should either implemented regular "keep-alive" server calls to keep the session from expiring or - preferred - handle expired sessions gracefully, for example by handling the OnLoginNeeded event on the channels.

See Also

Login and Authentication and Statelessness help topics

SessionManager and descendant classes (.NET)

TROCustomSessionManager and descendant classes (Delphi)


Topics

Topics

In-Memory Session Manager

The in-memory session managers store session data in local memory within the application server.

Database Session Manager

The database-driven session managers will use a back-end database to store data in a data table.

Depending on the platform, ADO.NET, a Delphi TDataSet component or a Data Abstract server will be used to access the underlying database, store session data and retrieve it.

Master Server Session Manager

This session manager will use the precompiled Master Server back-end database to store data in a data table and use RemObjects SDK itself to communicate with the Master Server.

Basically the Master Server is a standalone database server (based on the powerful NexusDB 2.0 database engine) that you can run on one host in your server farm to store session data. You can then use use the Master Server Session Manager component in your RO server(s) and access this common server to store and locate session data.

Use Cases

Use these session managers when you need session data to persist between server... more

Event-Driven Session Manager

The event-driven session manager does not provide its own storage mechanism for session data. Instead it will fire events whenever session data needs to be stored and retrieved, allowing you to use custom code to perform these tasks.

Session Management in TRORemoteDataModule


See Also

Login and Authentication and Statelessness help topics

SessionManager and descendant classes (.NET)

TROCustomSessionManager and descendant classes (Delphi)


In-Memory Session Manager

The in-memory session managers store session data in local memory within the application server.

Use Cases

Use these session managers when you need maximum speed access to session data within a single server executable and persistence of sessions across server restarts is not needed.

Components

MemorySessionManager (.NET)

TROInMemorySessionManager (Delphi)


Database Session Manager

The database-driven session managers will use a back-end database to store data in a data table.

Depending on the platform, ADO.NET, a Delphi TDataSet component or a Data Abstract server will be used to access the underlying database, store session data and retrieve it.

Use Cases

Use these session managers when you need session data to persist between server restarts, or during crashes and power outages, or if you are deploying several server executables - either on the same hardware or across a server farm - that need to share the same session data.

Components

TRODBSessionManager (Delphi)

TDADBSessionManager provided with Data Abstract (Delphi)


Master Server Session Manager

This session manager will use the precompiled Master Server back-end database to store data in a data table and use RemObjects SDK itself to communicate with the Master Server.

Basically the Master Server is a standalone database server (based on the powerful NexusDB 2.0 database engine) that you can run on one host in your server farm to store session data. You can then use use the Master Server Session Manager component in your RO server(s) and access this common server to store and locate session data.

Use Cases

Use these session managers when you need session data to persist between server restarts, or during crashes and power outages, or if you are deploying several server executables - either on the same hardware or across a server farm - that need to share the same session data.

You will use Master Server instead of the other database-driven session managers if you do not want to setup or maintain a full database or database server for session data.

Components

MasterServerSessionManager (.NET)

TROMasterServerSessionManager (Delphi)


Event-Driven Session Manager

The event-driven session manager does not provide its own storage mechanism for session data. Instead it will fire events whenever session data needs to be stored and retrieved, allowing you to use custom code to perform these tasks.

Use Cases

Use this session manager if you need to maintain session data in a custom way, but do not want to implement a full-blown session manager on your own,.

Components

TROEventSessionManager (Delphi)


Session Management in TRORemoteDataModule


Login and Authentication

One of the key requirements of most multi-tier applications is to limit access to a specific group of authorized users, and possibly to apply different restrictions of access to different users accessing the server.

When writing real life business applications with RemObjects SDK or Data Abstract, one important concern is security. Chances are that your middle tier server is exposing sensitive data that you would not want any anonymous user on your local LAN (or worse, the entire Internet) to access or even modify. A login system is needed to ensure that only authorized users can get access to the data, and/or that these authorized users only get access to the subset of data they are allowed to access.

This topic describes the default, "best practices" login and user authentication system that is recommended for RemObjects SDK applications that require user-level security. This system is built on top of the basic RemObjects SDK architecture, and there is nothing stopping you from using a different system or using the principles outlined here in different ways to better suit your particular needs.

Session Management & Authentication

Session management provides the foundation of login and authentication in RemObjects SDK.

By default, the instances of your Data Abstract service are created without reference to a specific client, and subsequent calls into your server might be served by different instances. You cannot assume that field values from a previous call are still accessible when the next call from a client comes in. This is what makes RemObjects SDK servers stateless and forms the foundation of proper scalability.

Sessions provide a means of storing client-specific information in a separate storage that is independent of the actual service instances processing the request. There could be a different instance for each call, or they might even be running on different physical servers in a server farm, but data is persisted between calls.

For authentication, a session is used to store the identity (and possibly details about the privileges) of the user, as he logs in. This information is then available in subsequent data access calls. If no session or no valid login information is found in a data call (because the user did not authenticate correctly before), the request will be rejected immediately.

Login and the Service Base Classes

The service base classes (RemObjects.SDK.Server.Service in .NET and TRORemoteDataModule in Delphi)that are used as the base for your own service implementations already contain the necessary code to handle sessions for you. In particular, the Session[] indexer property wraps all session accesses, allowing you to store custom named values such as User ID or privileges in one call and retrieve them again in the next.

Also, the RequireSession property can be set to true to force all calls in a particular service to require an existing session - basically preventing any access to a particular service until a session has been established by talking to another service class (typically a specific Login service).

More details about sessions and session management can be found in the Statelessness and Session Management help topics.

The Login Service

A login service is a secondary service implemented in your RemObjects SDK server that is provided for the sole purpose of having clients log in (authenticate) and log out. Usually, this service will be implemented independently of the "real" services (which could be Data Abstract data services or standard RemObjects SDK services exposing your custom business logic).

A typical login service will expose two methods, Login and Logout. The Login method will verify the authentication info received from the client (commonly a user name and password), create a session and fill it with information about the user (which could include the User ID, a list of privileges specific to the user, or any other custom information relevant to your real services). The Logout method will simply undo a previous login by destroying the session.

The specific details of how to handle authentication are of course entirely up to you. Login can be defined to receive a user name and password, use a shared key or any other system of uniquely identifying a user that you may find suitable. You may also use additional security measures such as verifying the client's IP address against a list of approved addresses, to tighten security. Also, up to your design is how to look up the actual user information. Depending on your needs, your server might for example use a single login specified in a local configuration file or obtain a list of valid users from a database table.

The key is that your Login method will create a session only if the login was considered successful.

Enforcing Authentication

Enforcing authenticated access in your "real" services can happen on several levels.

Firstly, setting the RequireSession property mentioned above to true will ensure that your service methods will only execute if a session has previously been established through login. This will function without the need of any custom code.

Secondly, you can use the either the OnActivate event of your service or your actual method implementations to perform additional checks based on privileges stored in the session. For example, during login you could store a flag indicating whether the user is an administrator or not, and reject certain actions based on this flag.

Automatic Login on the Client Side

On the client side, RemObjects SDK provides infrastructure to seamlessly integrate login and authentication.

Whenever the server rejects a request because authentication is needed, a SessionNotFoundException (.NET) or EROSessionNotFound exception (Delphi) will be sent back to the client.

The client channels provide special logic to trap this exception and fire an OnLoginNeeded event when this occurs, giving your client the chance to perform a login manually, and then retry the request. If the login is successful and the request succeeds at the second attempt, the entire login process will be transparent to your application - the code that initiated the original request will never know it failed and a login was required.

A typical implementation of the OnLoginNeeded event handler would be to show a login dialog to ask for username and password (possibly persisting this information locally, for future use), call the Login method on the server, and then set the aRetry parameter of the event to true.

Note that both editions of RemObjects SDK for .NET and Delphi are prepared to handle the respective "session not found" exceptions from the other SKUs, so that this mechanism will work seamlessly between platforms.

Handling Session Timeouts

This entire process will occur both when an initial login for a newly connected client is needed and when a session on the server has timed out because the client has been idle for a given amount of time.

Depending on your specifications and the security needs for your client application, you might want to prompt to (re-)enter user name and password each time OnLoginNeeded is fired, or store the login information locally after it was first entered and silently call Login as needed so the user never notices his session on the server had timed out.

Design Time Login

In some scenarios, most notably for Data Abstract, it will be necessary to communicate with a secure service from within the IDE - for example to obtain database meta data.

The RemObjects SDK IDE integration provides a default Design Time Login Dialog for this purpose. This dialog will obtain the list of services and methods available on the server and allow you to call any one (or more) methods to manually perform the necessary authentication:

From this dialog, you can select the login service and method (if you're using the default names provided by the template, the right items will be pre-selected for you), enter your login information and perform the login call to the server.

Once this is done, the IDE will re-attempt the original request which, if your login was successful, will now succeed.

As at runtime, your session will be maintained during design time, so for subsequent requests the login dialog will not reappear until your session has expired on the server.

See Also

RemObjects.SDK.Server.Service (.NET) and TRORemoteDataModule (Delphi) classes

SessionNotFoundException (.NET) and EROSessionNotFound (Delphi) exceptions

Statelessness, Session Management and Channels help topics.

Online article DA24 - Authentication in Data Abstract


See Also

RemObjects.SDK.Server.Service (.NET) and TRORemoteDataModule (Delphi) classes

SessionNotFoundException (.NET) and EROSessionNotFound (Delphi) exceptions

Statelessness, Session Management and Channels help topics.

Online article DA24 - Authentication in Data Abstract


RODL Files

RODL (short for RemObjects Definition Language) files form one one the foundations of RemObjects SDK, and are used to define the interface of the services that a RemObjects 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 several 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, RemObjects SDK provides the Service Builder, which offers an intuitive GUI and a RAD approach to defining services. The user interface of Service Builder is covered in detail in the Service Builder section of this help file.

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 RemObjects 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. Event sinks are covered in more detail in the Event Sinks and Server Callbacks help topic.

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 visually structuring large RODL files.

How RODLs are used in RemObjects SDK

As mentioned before, RODL files are used to define the services and related types of your RemObjects SDK servers. As such, the process of working with RODL files is usually such 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 (again, see the Files Generated from RODL help topic for more details).

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 TRODynamicRequest (currently Delphi only) class.

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.

Borland 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, Borland 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 RemObjects 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 RemObjects.SDK.Rodl.RodlLibrary (.NET) and TRODLLibrary (Delphi) classes and provide properties and sub-classes that give access to all elements of a loaded RODL

See Also

Files Generated from RODL, Service Builder, Service Tester and Event Sinks and Server Callbacks help topics

TRODynamicRequest (Delphi) and DynamicRequest (provided by Data Abstract for .NET) classes

RemObjects.SDK.Rodl.RodlLibrary (.NET) and TRODLLibrary (Delphi) classes

RemObjects.SDK.Rodl.RodlLibrary (.NET) and TRODLLibrary (Delphi) classes


Topics

Topics

Files Generated from RODL

RemObjects SDK automatically generates several source code files from your RODL files, in order to make the types and services defined therein available to your project at compile time.

The benefit of this is that you can use strongly typed code to call your service and work with your types, giving you Intellisense and code completion as you type your code, and compiler validation as you build your project.

How and when these source files will be generated depends on the IDE and the edition of RemObjects SDK you are using, as discussed further below.


See Also

Files Generated from RODL, Service Builder, Service Tester and Event Sinks and Server Callbacks help topics

TRODynamicRequest (Delphi) and DynamicRequest (provided by Data Abstract for .NET) classes

RemObjects.SDK.Rodl.RodlLibrary (.NET) and TRODLLibrary (Delphi) classes

RemObjects.SDK.Rodl.RodlLibrary (.NET) and TRODLLibrary (Delphi) classes


Files Generated from RODL

RemObjects SDK automatically generates several source code files from your RODL files, in order to make the types and services defined therein available to your project at compile time.

The benefit of this is that you can use strongly typed code to call your service and work with your types, giving you Intellisense and code completion as you type your code, and compiler validation as you build your project.

How and when these source files will be generated depends on the IDE and the edition of RemObjects SDK you are using, as discussed further below.

File Types

There are 5 types of source files that RemObjects SDK generates from your RODL. These files can be generated in all supported languages, including C#, Chrome, Delphi for (Win32 and .NET) and Visual Basic. 	_Intf files. One Interface file will be generated for each RODL, containing definitions for all the types defined in the RODL, the interface definitions of all the services, and client-side proxies for all the services. Under normal circumstances, the Intf file is the only file that will be needed on the client.

_Impl files. One Implementation file will be generated for each Service defined in the RODL, containing a stub implementation for the service. Once generated, an Impl file will never be overwritten, as the Impl file will be filled by the developer with the actual code to implement the service.

_Invk files. One Invoker file will be generated per RODL, containing server-side stubs used to invoke the service methods. These stubs are used internally by the framework, and it's very unlikely that you will ever have to deal directly with it.

_Events files. One Events file will be generated for each RODL that contains event sinks. The file will contain the proxy code that will be used on the server to fire events. Events files are only generated by RemObjects SDK for .NET; in the Delphi edition the Interface file is used for these types.

_Async files. One Async Interface file can be generated for each RODL when needed. The file will contain the proxy code that allows service methods to be called in an asynchronous fashion; please refer to the Asynchronous Calls help topic for details. Asynchronous calls are currently only supported for Delphi.

Note that all files except the Implementations will be automatically regenerated by the IDE whenever needed, so you should not make any custom modifications.

Generating Files Inside the IDE

There are two scenarios where the IDE will generate source files from RODL for you automatically and add them to your project.

When you're building a RemObjects SDK Server, your project will contain a RODL file and a complete set of files (_Intf, _Invk, _Impl and possibly _Events) will be generated for your project. In the edition for Delphi, these files will be generated whenever you build your project; in the edition for .NET this will happen whenever you edit your RODL library from within the IDE. In both editions, you can use the RemObjects menu will provide an option to regenerate files on request, if a server project is active.

As mentioned above, the _Impl files that contain the implementation of your services will only be generated the first time around - once the file exists, it will not ever be overwritten.

When you're building a RemObjects SDK client, you have two options for obtaining interface code for your server. If you have access to the server source-code and the server is implemented in the same language, you can simply reference or copy the _Intf file from the server. Otherwise, you can use the Import Service item of the RemObjects menu to import a service, either via the network or from a local RODL file. During this import, a _Intf source file will automatically be generated in the proper language, and added t your project.

Generating Code for Other .NET Languages

For .NET, code generation is accomplished using CodeDom, so that support for other third party languages can be accomplished with some minimal code, if these languages provide a full CodeDom implementation. The RODL Sample included with RemObjects SDK for .NET shows how to do this at the example of using the C#, Visual Basic and Chrome CodeDoms from custom code.

See Also

Asynchronous Calls and The RemObjects Menu help topics


See Also

Asynchronous Calls and The RemObjects Menu help topics


Data Types

RemObjects SDK supports a variety of data types that are available when designing your service interface in Service Builder. Because RemObjects SDK supports different platforms, it uses common names to refer to these data types - which might not necessarily be the same as those used by your language of choice.

The following section gives a brief introduction to the data types available and it explains what underlying .NET or Delphi types are used by RemObjects SDK.

Binary

The Binary type is used to pass unstructured binary data between tiers in your application.

For .NET, RemObjects SDK uses a custom class (Binary ) descending from MemoryStream to represent this binary data. See the description for Binary for more details on how to work with this class.

For Delphi, a similar custom class (TROBinaryMemoryStream) is used.

Boolean

Used to send Boolean values of true or false. On .NET, this uses the System.Boolean type (bool in C#).

Currency

The Currency type is used to pass fixed-point decimal numbers between the tiers of your application.

For .NET, this maps to the System.Decimal type, but note that the streaming format for BinMessage uses a different binary representation for this type, equal to the OleAutomation and Delphi "Currency" type, which is basically a 64 bit integer shifted so that the 4 least significant digits represent decimals.

(Due to constraints with the Compact Framework's Decimal type, Currency is not supported on the Compact Framework for the first release)

For Delphi, this maps to the language's "currency" type, which is a 64-bit fixed-point numerical type with 4 significant decimal points.

DateTime

System.DateTime

Double

System.Double

Int64

64-bit signed integer type. System.Int64 (long in C#) for .NET, Int64 for Delphi.

Integer

32-bit signed integer type. System.Int32 (int in C#) for .NET, Integer for Delphi.

String

The "String" data type is used to represent strings of characters.

While on the .NET platform all strings map to System.String, the "String" data type will be serialized as 8-bit ANSI string (and might be represented as such on other platforms). The system's current ANSI code page will be used for encoding, so the actual encoding will be dependent on the system locale.

If you need to send strings while preserving the full 16 bit Unicode character set, define your services to use the WideString or Utf8String types discussed below. In general, Utf8String will be the best option for strings when using .NET on one or both sides of the communication.

In Delphi, this type maps directly to the 8-bit "string" language type.

Utf8String

The "Utf8String" data type is used to represent strings of characters. As a compromise between the plain "String" data type and "WideStrings", Utf8Strings will be serialized as UTF-8 encoded 8 bit strings preserving any Unicode characters, while maintaining a smaller memory footprint than WideStrings.

In .NET, Utf8Strings will atomatically be converted back and forth to the 16-bit System.String type; application code will notice no different between using WideString and Utf8String.

In Delphi, the String and Utf8String data types will be handled identically, and mapped to the "string" language type. It is up to the application's code to treat received strings as UTF-8 encoded and use the RTL functions to convert them back from and to ANSI or WideString, where needed.

Variant

The variant type can be used to represent a field or parameter of unknown type and can hold different types of data at runtime.

For .NET, variants are represented as System.Object and support any of the following .NET data types: 	Binary

Boolean

Byte

DateTime

Decimal

Double

Int32

Int64

String

arrays of any of the above, including nested arrays

Passing any other type of object into or out of a service method (whether as a parameter or nested inside a struct) will cause an InvalidVariantValueException at runtime.

For Delphi, this maps directly to the languages "Variant" type.

WideString

The "WideString" data type is used to represent strings of characters. In contrast to the "String" data type, WideStrings will be serialized as true 16 bit strings, preserving any Unicode characters. As a downside, they will consume twice as much space (in the uncompressed message) as normal String types.

Arrays

Arrays can be defined in the RODL library in order to pass arrays of any other valid type between the tiers of your application. For .NET, arrays will be represented as standard system arrays (System.Array) just as if you defined them in code. RODL only supports single-dimension arrays, although you can use "array of array of" nesting to create non-rectangular arrays.

In Delphi, custom class types are generated in the Intf unit to represent array types.

Structs

Structs are used to define record like groups of fields, much like a regular C# "struct" or Pascal "record". RODL Structs are implemented as custom classes descending from ComplexType and code for them will be created in the auto-generated _Intf file of your library.

Structs can contain any number of elements of all the types described here (including arrays and other structs).


Smart Services

When it was first released in 2003, RemObjects SDK introduced the concept of Smart Services™, the idea to combine efficient, proprietary communication methods with open standard systems to make your services available to a wide range of clients without compromising efficiency.

Often times you are implementing a service that you want to open up to third parties - either by making it publicly accessible to any users or by selling access to the service to selective customers. In this scenario, one cannot reasonably expect all clients to use RemObjects SDK (or even one of the languages, platforms or operating systems supported by it), so it is reasonable to make the service accessible using open standards such as SOAP Web Services or the simpler XML-RPC.

These communication protocols have known down-sides (such as higher bandwidth consumption and lower efficiency parsing the verbose and text-based XML messages), but in this case, the benefit of enabling access from virtually any platform outweigh these disadvantages.

At the same time, you might be implementing your own client software for your services, using RemObjects SDK, and you will of course want to reap the full benefits of using the SDK's fast but proprietary BinMessage protocol, to make sure your client can communicate with the server as efficiently as possible.

Enter Smart Services

Using the Smart Services architecture, RemObjects SDK allows you to publish the same service using different protocols at the same time. This way, your own client applications (or any third party using RemObjects SDK or the free RemObjects Client SDK for .NET) can use the most efficient communication possible, without sacrificing openness to other platforms.

Relevant Message Types

An application that uses Smart Services will usually publish its services using the BinMessage and SOAP message types, although both XML-RPC and PostMessage provide additional options for open or easy to parse message formats that can be easily be handled by non-RO clients.

Support for SOAP Web Services is available in countless different implementations, for every conceivable platform, making it the ideal choice. XML-RPC is a bit less known, but provides a simpler and more streamlined XML based message format than SOAP, making it a good choice for those platforms where an XML-RPC implementation is available.

Of course, Smart Services allow the use of more then two message protocols at the same time, so it is perfectly possible to provide support for SOAP and XML-RPC, in addition to BinMessage.

There are two options for enabling your server for Smart Services, depending on the type of server channel (a.k.a. server) you are using:

Exposing your Service Using Different Message Types

The HTTP based servers provide the option to support multiple message formats at the same time, using different URL end points. Using the Dispatchers collection property of the server component, you can set up multiple message formats and assign them to different paths in your server URL. For example you could make BinMessage available at http://yourserver/bin and SOAP at http://yourserver/soap. The HTTP server will automatically process incoming requests using the proper message format, depending on the URL they come in under.

Since HTTP is the defacto standard transmission protocol for SOAP (although the SOAP specification allows for different transfer channels) and XML-RPC, you will not usually make use of the other service types for SOAP and XML-RPC, since most non-RO clients would not be able t communicate with them, anyway.

Exposing your Service Using Different Server Channel Types

While the other servers do not support multiple message formats at the same time, RemObjects SDK allows the use of multiple server components at the same time. For example, you could provide a Super TCP Channel server with BinMessage, in addition to a HTTP server that provides BinMessage and SOAP.

See Also

Messages and Channels help topics

ServerChannel .Dispatchers (.NET) and TROServer.Dispatchers (Delphi) properties


See Also

Messages and Channels help topics

ServerChannel .Dispatchers (.NET) and TROServer.Dispatchers (Delphi) properties


Asynchronous Calls

Since version 3.0, RemObjects SDK provides the option to execute requests against remote services in an asynchronous fashion.

When performing normal (synchronous) calls against your server, the thread making the server call will block, and wait until the request has been executed on the server and a response has been received. In most cases this is the preferred way to make calls, as it closely resembles the paradigm you are used to from calling local methods within your application.

In some scenarios, it might be helpful to trigger an action on the server, but continue with local processing as the server executes the request, without waiting for the response first. The response could be collected at a later time, or might even not be relevant at all.

RemObjects SDK provides an infrastructure for making such asynchronous calls to your services. Asynchronous calls are handled entirely on the client side and in the communication layer of the server, making them work against your existing servers without change.

Async Interface Files

Support for asynchronous calls starts with a special _Async interface file.

Similar to the familiar _Intf file, this unit provides special version of your server interfaces prepared for asynchronous use. Every service method defined in a service interface will be split in two parts for this, one method prefixed with Invoke_ that will initiate the request, and one prefixed with Retrieve_ that will complete a previously invoked request and retrieve any results. (Methods that do not contain any out or result parameters will only be represented by an Invoke_ method).

For example if your original service defined a method Sum:

  INewService = interface

    function Sum(A: Integer; B: Integer): Integer;

  end;

this method would result in to split methods in the async interface:

  INewService_Async = interface(IROAsyncInterface)

    procedure Invoke_Sum(A: Integer; B: Integer);

    function Retrieve_Sum: Integer;

  end;

In your application code you would call Invoke_Sum(5,10), which would initiate the request to the server but return right away, without result. Your client application would continue performing other tasks, and a some point in time call x := RetrieveSum() to opbtain the actual result.

Working with Async Interfacs

In addition to the split invoke/retrieve methods of your service, the async interface also contains a number of helpful properties it inherits from IROAsyncInterface. The AnswerReceived property will specify if an answer for the previous Invoke call has been received yet.

You can use this to determine whether your code should call the Receive_ method yet. Calling Receive_ when an answer is not available yet will raise an EROAsyncNoAnswerYet exception.

Similarly, the AnswerReceivedEvent property can be used on channels that support active asynchronous calls to get a Win32 event object that will be triggered when an answer comes in.

Under the Hood of Asynchronous Calls

How asynchronous method calls are handled internally depends to a large degree on the channel type.

Some channels, including the new Super TCP Channel, the UDP Channel and the Email Channel, provide active support for asynchronous calls. They know how to transmit an async request to the server and to actively handle receiving a response.

Other channels, including the standard HTTP and TCP channels are unaware of asynchronous requests. When executing an async call on one of these channels, the asynchronous behavior will be simulated on the client side, by spawning of a worker thread that performs the actual (synchronous) call and waits for the response.

This difference is handled internally by the asynchronous proxy, so your application code will not know the difference.

Generating the Async_ interface unit

Since most applications do not make use of asynchronous calls, the Async_ interface unit will not be generated or regenerated automatically on every compile. Instead the RemObjects menu provides a "Regenerate Async Unit from RODL" menu item to manually create or recreate this unit, as needed.

See Also

IROAsyncInterface interface

EROAsyncNoAnswerYet exception

TROAsyncProxy class

Channels, Files Generated from RODL and The RemObjects Menu help topics


See Also

IROAsyncInterface interface

EROAsyncNoAnswerYet exception

TROAsyncProxy class

Channels, Files Generated from RODL and The RemObjects Menu help topics


Event Sinks and Server Callbacks

In most scenarios of multi-tier applications the client takes the active role of sending requests to the server, while the server passively waits for requests, processes them and sends back a response.

Sometimes, you will find the need to have the server actively contacting one of more clients to notify them of specific events. For example, a database application might notify a client about changes to specific records made by a different user, or a chat system might forward messages sent by one client to a group of other clients logged onto the same chat room.

RemObjects SDK provides the concept of Event Sinks to achieve this functionality.

Event Sinks

Principally, you can consider an Event Sink to be a service interface that will be implemented by the client, instead of the server. When designing your service structure in Service Builder, event sinks will look similar to services - they are a collection of methods grouped together in an interface.

Since events are uni-directional (meaning the server can invoke them on the client, but the clients will not send a response), event methods can only contain parameters that will be sent into the event - they do not provide a result value or any outgoing return parameters.

But besides this restrictions, events can make use of all the functionality of a service definition, including the use of all the types supported by RemObjects SDK as parameters.

Implementing Event Handlers

Just like services, every event sink defined in your RODL will be represented as interface in the _Intf source file. To implement event handler for a particular event sink on the client, all you need to do is implement the interface and provide implementation bodies for all the event methods it defines.

The class that implements can be any class in your project - it could be your main form or a class you specifically define just to handle the events.

Event subscription in RemObjects SDK is handled on a per-sink level - a client can subscribe to receive all events in a particular event sink, or none of them, it cannot subscribe to a subset only. But of course the client is free to ignore certain events by simply providing an empty implementation for the respective event method.

Receiving Events on the Client

The SDK includes the EventReceiver (.NET) or TROEventReceiver (Delphi) components that handle the retrieval and dispatching of events. Enabling a client to receive events consists of 4 simple steps 	Drop an event receiver component onto your client application

Assign its Channel property to the channel you wish to use to communicate with the server

Assign its Message property to the message you use to communicate with the server (note that since events are dispatched based on the ClientID, this must be the same Message component you also use for your regular communication)

Register your event handler (the object implementing the event interface) by calling the RegisterEventHandler (.NET) or RegisterEventHandlers (Delphi) method.

Sending Events on the Server (.NET)

In RemObjects SDK for .NET, the Service .GetEventSink methods allows you to obtain an event proxy object for any event sink defined in your RODL simply by passing the type of the required interface, and casting the result, such as

 IChatEvents ev = GetEventSink(typeof(IChatEvents)) as IChatEvents;

This will return a proxy object on which you can call any of the event methods - which will then automatically be dispatched to all clients registered to receive the events.

GetEventSink also provides different overloads that allow to specify a restricted list of recipient IDs, or a IEventTargets interface for more detailed control.

Sending Events on the Server (Delphi)

In RemObjects SDK for Delphi, event repositories (descendants of the TROEventRepository class) are used to store and dispatch event calls. To obtain an event proxy for any particular event sink, simply cast your service's EventRepository to the desired event sink writer interface that is defined in your _Intf unit, such as:

ev := (EventRepository as IChatEvents_Writer);

In addition to the actual event methods, this event writer interface contains additional properties inherited from the IROEventsWriter base interface that you can use to control the recipients of the events in detail.

Deciding which Clients will Receive Events

How it is decided which clients will actually be signed up for a particular event sink depends on the platform used. in the Delphi edition of the SDK, the event receiver will automatically perform a call to the server to register the client to receive the registered event sink(s), when you call RegisterEventHandlers. In the version for .NET, the server implementation has more explicit control over this thru the SubscribeClientEventSink and UnubscribeClientEventSink methods of the service, which must be called to let clients receive events.

Note that for compatibility reasons, the Delphi TRORemoteDataModule also exposes RegisterEventClient and UnregisterEventClient methods to perform this operation. These methods are not needed in a pure Delphi environment, but they are called if you expect your Delphi server to send events to .NET clients.

Polling vs. Active Events

Depending on the Channel type you are using, events can either be actively delivered to the client, or stored on the server and retrieved via polling. At this time, only the Super TCP Channel supports active event delivery, for all other types, the event receiver will poll the server at regular intervals. Please refer to the documentation for EventReceiver (.NET) or TROEventReceiver (Delphi) for more details on how to fine-tune the polling operation.

This difference is handled internally in the channel and event receiver components, your application code doesn't need to distinguish between the two modes of retrieving events.

See Also

Channels, Service Builder and Files Generated from RODL help topics

EventReceiver (.NET) or TROEventReceiver (Delphi) components

IEventTargets (.NET) and IROEventsWriter (Delphi) interface

SubscribeClientEventSink and UnubscribeClientEventSink methods (.NET)


See Also

Channels, Service Builder and Files Generated from RODL help topics

EventReceiver (.NET) or TROEventReceiver (Delphi) components

IEventTargets (.NET) and IROEventsWriter (Delphi) interface

SubscribeClientEventSink and UnubscribeClientEventSink methods (.NET)


Service Discovery

RemObjects SDK provides a default infrastructure for discovering servers and services available on the local network. This can be used to automatically detect new servers that have become available if an old server has gone down, or to automatically distribute calls to different servers across the network based on information such as server load or custom criteria.

The Service discovery infrastructure is implemented using standard principles on top of the general RemObjects SDK architecture - it provides merely a reference implementation, and you could easily implement your own similar or different solution to fit your needs.

The Components

Service Discovery is implemented through the TRODiscoveryClient and TRODiscoveryServer components, which handle the client and server side of the discovery, respectively.

These components will use the Broadcast Channel to communicate. The client component will require a Channel and Message to be assigned that will be used to contact the server, while the server will automatically be made available through the standard RemObjects SDK server architecture, if a TROBroadcastServer is configured for your server application.

Publishing Services for Discovery

The discovery server provides two options for configuring the list of available services it will make available 	using the SupportRegisteredServerClasses property you can configure if all RemObjects SDK Services registered within the server should automatically be listed as available (the default), or not.

using the ServiceList string collection, you can provide a custom list of service names that will be made available.

Note that a "service" in this context must not necessarily map directly to a RemObjects SDK Service implemented by your server - you can use service names to reference any concept of services that your client will understand.

For example, you could have a method to query different databases defined in your RemObjects SDK Service, and use the ServiceList to specify which particular data tables are available on the given server - even though the same underlying service method will eventually be used by the client to access the database.

Fine-Tuning Discovery at Runtime

In addition to the above properties, the OnServiceFound event will give you additional control over what services will be published as response to a specific discovery request. This event will fire every time a request service was found on the local server, but will grant your code the final decision on whether the service will be shown as supported, or not.

For example, the event handler could evaluate the current server load, and dynamically decide to hide the service for the moment (allowing the client to direct the request to a different server).

Discovering Services from on Client

Discovering available services is a very straightforward process for the client. After setting ServiceName to the name of the client you are looking for, a call to RefreshServerList will initiate a broadcast request across the network to look for servers implementing the service.

As servers that provide the desired service respond to the request, the OnServiceFound event will fire for each server that is discovered; the server address will also be added to the ServerList property for future reference.

Note that due to the asynchronous nature of the discovery broadcast, the RefreshServerList method will return right away, and the actual responses form the servers (which could be none, one, or more than one) will come in at undetermined intervals, depending on the network structure and load. Since the number of servers on the network is unknown, there is no definitive way to tell at which point all servers have responded and/or no further responses can be expected - although it can be reasonably assumed that responses should come in within a short period of time.

Passing Custom Discovery Options between Clients and Servers

For advanced discovery uses, the discovery components allow passing of custom data to and from individual discovery requests - for example to further qualify the requirements of the service that is being sought or the capabilities of the service that is being returned.

To pass this custom information, one or more structs must be defined in your server's RODL file, descending from TRODiscoveryOptions (defined in Discovery.RODL) and containing whatever custom information you want to pass back and forth. Different specialized struct types may be used for either direction.

Clients can pass this type into their call to RefreshServerList - the data will then be streamed to the server along with the broadcast request. On the server, the information received from the client will be passed into the OnServiceFound event, allowing the server to evaluate the data before making the decision of returning an answer or not (see above under Fine-Tuning Discovery at Runtime).

Finally, the server can pass options back to the client from the OnServiceFound event by either filling or replacing the struct that was originally passed in or by instantiating a new struct.

For example, a chat client might send the name of the chat partner it wants to initiate contact with as part of the custom data. Each server on the network could then determine if the respective user is connected - and only the one server that has a connection to the target user will actually send a discovery response.

See Also

TRODiscoveryClient and TRODiscoveryServer components

UDP and Broadcast Channels, RODL Files and Service Builder.Structs help topics


See Also

TRODiscoveryClient and TRODiscoveryServer components

UDP and Broadcast Channels, RODL Files and Service Builder.Structs help topics


The RemObjects Menu

RemObjects SDK adds a new top level item to the Delphi main menu that provides access to functionality specific to RemObjects SDK (and related products, such as Data Abstract, where applicable).

The items available in this menu will vary dynamically depending on whether the active project is supported by RemObjects SDK for Delphi and whether the current project already is a a RemObjects SDK Server or not.

Edit Service Library

Starts an instance of the Service Builder to edit the RODL file for the current project. This item is only available if the active project is a RemObjects SDK Server.

Import RemObjects SDK Service... / Import SOAP Web Service...

Allows you to import an existing service and generate the Interface unit necessary to communicate with it. You can import either from a RODL or WSDL file on your local hard disk, or point to a URL to get the RODL or WSDL directly from the server.

See Importing Services and Importing SOAP Web Services for more details.

Service Tester

Launches the standalone Service Tester tool to enable you to run performance and scalability tests against your server.

Schema Modeler

Launches the Data Abstract Schema Modeler tool. This menu item is only available if RemObjects Data Abstract is installed, as well.

Regenerate Units from RODL

Will generate or re-generate the Interface and Invoker files for your RODL library or libraries, and add them to the project. If necessary, it will also generate implementation stubs for the services defined in your RODL. It performs the same operation that is also executed automatically when you compile your server project within the IDE.

This menu item is only available if the current project is a RemObjects SDK Server project.

Regenerate Async Unit from RODL

Generates a special interface unit that can be used to make asynchronous calls to the server.

This menu item is only available if the current project is a RemObjects SDK Server project.

Turn <Project Name> into a RemObjects SDK Server

Converts the existing project into a RemObjects SDK Server project, adds a RODL file to the project and, optionally, launches Service Builder to start designing your service.

This menu item is only available if the current project is not already a RemObjects SDK Server.

Launch Server Executable

Launches your server project outside the debugger, so that the server will be available for design-time connects or for debugging your client.

This menu item is only available if your project group contains a RemObjects SDK Server project.

Check for New Versions

Checks online if newer versions of RemObjects SDK or related installed products (such as Data Abstract) are available.

About RemObjects SDK

Displays the About Box dialog, with copyright information and version number.

See Also

Importing Services and Importing SOAP Web Services help topics

Service Builder and Service Tester help topics


See Also

Importing Services and Importing SOAP Web Services help topics

Service Builder and Service Tester help topics


New Project Templates

RemObjects SDK integrates with Delphi's New Item dialog to provide an extensive set of different project templates to help you get started writing RemObjects SDK server projects.

These templates can be found in a special RemObjects SDK sub-folder below Delphi Projects (in Delphi 2005 and up), and on the RemObjects SDK tab in Delphi 7 and below:

WebBroker Servers

The following four templates create projects based on Delphi's WebBroker technology and TROWebBrokerServer to integrate with an existing web server such as IIS, Apache or the like: 	Apache 1.0 DSO Server

Apache 2.0 DSO Server

CGI Server

ISAPI/NSAPI Server

Standalone Executable Servers

The following templates create standalone executable servers that can be deployed without requiring an existing web server installation: 	VCL Standalone

CLX Standalone (Delphi 6/7 and Kylix 3 only)

Windows Service Application

Combo Service/Standalone

The last option combines a VCL Standalone server with a Windows Service, resulting i one executable that can be deployed both ways - either by just running as a standard Windows application, or being installed as Windows Service.

Single-Tier Servers

The following two templates create projects to allow deployment of client and server code on the same machine: 	DLL Server

Local Application

See Also

The New RemObjects SDK Server Dialog help topic


Topics

Topics

The New RemObjects SDK Server Dialog

The New RemObjects SDK Server dialog will be launched whenever you start a new project using one of the New Project Templates. In version 4.0 of RemObjects SDK, this dialog has been split into two parts, showing the most commonly needed options in the main dialog, and moving more advanced options into a separate dialog.


See Also

The New RemObjects SDK Server Dialog help topic


The New RemObjects SDK Server Dialog

The New RemObjects SDK Server dialog will be launched whenever you start a new project using one of the New Project Templates. In version 4.0 of RemObjects SDK, this dialog has been split into two parts, showing the most commonly needed options in the main dialog, and moving more advanced options into a separate dialog.

New RemObjects SDK Server

The Project Options dialog allows you to select the destination folder for your new project, as well as the name for the new project.

You can also select whether you want to create a matching client project and project group as well.

Finally, if the templates provides this (such as the Data Abstract 4.0 New Project Templates do), you can decide whether you want to run an extended New Server Wizard that will guide you through additional template-specific options.

Advanced Project Options

Additional options for the new project are available through the Advanced Project Options button, which will open an additional dialog.

Here you can specify names for the RODL Library and the first Service that will defined for you (options you can later change manually in Service Builder, if needed), as well as choose the server and message type you want to use for your application.

(Depending on the template you chose, the choice if server types might be limited or even disabled; for example WebBroker based templates will always use TROWebBrokerServer).

See Also

New Project Templates help topic

Channels and Messages help topics


See Also

New Project Templates help topic

Channels and Messages help topics


Importing Services

Client applications can use the Import RemObjects SDK Service... item on the RemObjects menu to import the definition of an existing service (either from a local RODL file or from a live HTTP server running on the net).

Selecting the menu item will present the following dialog which allows to specify the location of the RODL or the address of the server.

After importing, the IDE will generate an Intf source file in the appropriate language and add it to the project.

When importing into a Visual Studio 2005 Web project, the dialog will offer the option to choose the desired language, as ASP.NET 2.0 web projects are mixed-language. Please refer to the Visual Studio 2005 and .NET 2.0 documentation for considerations and limitations when mixing different languages in ASP.NET projects.

See Also

Importing SOAP Web Services help topic

The RemObjects Menu, RODL Files and Files Generated from RODL help topics


See Also

Importing SOAP Web Services help topic

The RemObjects Menu, RODL Files and Files Generated from RODL help topics


Service Builder

Welcome to the RemObjects Service Builder!

The RemObjects Service Builder is a powerful tool that integrates with the IDE of Delphi, Visual Studio .NET or C#Builder and is used to define the services and data types available in your RemObjects server application by Building a Library and allowing you to Generate Access to your Library.


Topics

Topics

Welcome to Service Builder

Welcome to the RemObjects Service Builder!

The RemObjects Service Builder is a powerful tool that integrates with the IDE of Delphi, Visual Studio .NET or C#Builder and is used to define the services and data types available in your RemObjects server application by Building a Library and allowing you to Generate Access to your Library.

Getting Started with Service Builder

The RemObjects Service Builder consists of a Main Menu, a toolbar, a Library Panel, and a Details Panel.

The Main Menu contains all of the available commands for the Service Builder, while the Toolbar contains quick access to the most common ones.

The Library Panel displays the structure of the library, including Services, Structs, Arrays, Enums, Exceptions, Event Sinks and used Libraries. Any item in the Library Panel can be selected so that its details are displayed in the Details Panel.

To start the Service Builder, launch it from the RemObjects menu item of your IDE. You can now create a... more

Service Builder Plugins

Service Builder 3 comes with an extensive plugin framework, which allows almost all of its parts to be extended.

Among the extendable areas are: 	Code Generators

Validators

Library Views

Library Editors

Importers

Custom Actions

Most of the elements you see and work with, including the default editor in the Details Pane, the standard Delphi or C# code generators, or the Library Validator, are plugins and can be theoretically replaced or extended with custom solutions.

You can see the installed plugins by selecting the "Library|Plugins" menu, which will give you a list similar to this:

The number of plugins that... more

Service Builder Toolbar Commands

The Service Builder Toolbar contains the most commonly used functionality, which encompasses five sections: File, Elements, Edit, View, and Help.

File Commands

 	New - Creates a new Library. If the current Library has changed, you will be prompted to save it.

Import - Allows you to import an existing Library and add its services and types to the current Library.

Open - Provides a Most Recently Used list and allows you to open an existing library. If the current Library has changed, you will be prompted to save it.

Save - Gives several options to save the current Library.

Close... more

Building a Library

Building a Library consists of defining one or more Services, as well as any Struct, Array, Enum, Event Sinks and Exception elements that might be needed to represent the data used by your service.

The Service Builder allows you to re-use existing libraries by importing their elements and allowing you to re-define or modify them. It also allows you to use existing libraries, extend them and re-use them.

Generating Access to your Library

The RemObjects Service Builder allows you to generate files that describe your Library. These files can then be imported into your project to consume the services defined within the library. Supported export formats include RODL, WSDL, and Source Code. In order to ensure that the export will be successful, before a library can be exported it needs to be Validated. You may preview the available formats by clicking the corresponding format button on the toolbar.

If you are using the RemObjects SDK in combination with Delphi, Visual Studio .NET or C#Builder, most of these generation tasks will be automated by... more

Command Line Switches

Command Line Switches * Service Builder knows and reacts to the following command line switches.

Most of these switches are used by the IDE integration and other RemObjects SDK tools when communicating with the Service Builder and should not be useful to start it manually.

<file-name> If the first parameter passed to the Service Builder is a filename, it will automatically load the specified RODL at startup. If the file is not found, a new Library will be created.

/autosave Used with the IDE integration. If called with this switch, Service Builder will automatically save changes to the RODL when... more

Writing Plugins

An article describing how to write custom Plugins for Service Builder 3 is available on our website. Click here.


Welcome to Service Builder

Welcome to the RemObjects Service Builder!

The RemObjects Service Builder is a powerful tool that integrates with the IDE of Delphi, Visual Studio .NET or C#Builder and is used to define the services and data types available in your RemObjects server application by Building a Library and allowing you to Generate Access to your Library.


Getting Started with Service Builder

The RemObjects Service Builder consists of a Main Menu, a toolbar, a Library Panel, and a Details Panel.

The Main Menu contains all of the available commands for the Service Builder, while the Toolbar contains quick access to the most common ones.

The Library Panel displays the structure of the library, including Services, Structs, Arrays, Enums, Exceptions, Event Sinks and used Libraries. Any item in the Library Panel can be selected so that its details are displayed in the Details Panel.

To start the Service Builder, launch it from the RemObjects menu item of your IDE. You can now create a new library by selecting "File" and then "New" from the Main Menu, or by clicking "New" on the Toolbar. You may also open an existing library by selecting "File|Open" from the Main Menu, or by clicking "Open" on the Toolbar. Once your initial library has been created, you can start Building a Library.


Service Builder Plugins

Service Builder 3 comes with an extensive plugin framework, which allows almost all of its parts to be extended.

Among the extendable areas are:

Code Generators

Validators

Library Views

Library Editors

Importers

Custom Actions

Most of the elements you see and work with, including the default editor in the Details Pane, the standard Delphi or C# code generators, or the Library Validator, are plugins and can be theoretically replaced or extended with custom solutions.

You can see the installed plugins by selecting the "Library|Plugins" menu, which will give you a list similar to this:

The number of plugins that you see depends on the edition of the RemObjects SDK that you have installed.


Service Builder Toolbar Commands

The Service Builder Toolbar contains the most commonly used functionality, which encompasses five sections: File, Elements, Edit, View, and Help.

File Commands

 	New - Creates a new Library. If the current Library has changed, you will be prompted to save it.

Import - Allows you to import an existing Library and add its services and types to the current Library.

Open - Provides a Most Recently Used list and allows you to open an existing library. If the current Library has changed, you will be prompted to save it.

Save - Gives several options to save the current Library.

Close - Closes the current library. If the current Library has changed, you will be prompted to save it.

Validate - Validates the current Library and reports any hints, warnings, and errors that were found during validation.

Element Commands

 	Struct - Creates a new Struct.

Enum - Creates a new Enum.

Array - Creates a new Array.

Service - Creates a new Service.

Exception - Creates a new Exception.

Edit Commands

 	Delete - Deletes the Element selected in the Library Panel.

Clear - Clears all Elements from the current library.

View Commands

 	RODL - Shows a preview of the RODL file in the Details Panel.

WSDL - Shows a preview of the WSDL file that can be generated by the Service Builder.

Source - Shows a preview of the source code that can be generated by the Service Builder.

Docs - Shows a preview of the documentation that can be generated by the Service Builder.

Help Commands

Help - Launches the help file that you are currently reading.


Building a Library

Building a Library consists of defining one or more Services, as well as any Struct, Array, Enum, Event Sinks and Exception elements that might be needed to represent the data used by your service.

The Service Builder allows you to re-use existing libraries by importing their elements and allowing you to re-define or modify them. It also allows you to use existing libraries, extend them and re-use them.


Topics

Topics

Reusing Existing Libraries

The Service Builder offers two options for reusing existing types and services in a project, you can Use an Existing RODL or you can Import one.

The Use an Existing RODL option adds a reference to an existing RODL to your project. If you make changes to the existing RODL later then those changes will be reflected in your new Library as well. When this option is chosen, no code will be generated for the definitions pulled in from the existing RODL, instead the CodeGen will add the units from the existing RODL to your uses clauses (in Delphi), or... more

Structs

A struct is an object that contains properties, but no actual functionality. The properties of a struct can consist of primitive types or complex types defined in your Library or in a Library that you are using.

To create a struct, select "Edit|New|Struct" or click the "Struct" button on the Toolbar.

Selecting the Struct in the Library Panel will load the details into the Details Panel. From here you can assign a name to the Struct, inherit the Struct from an existing one by specifying the Ancestor, or write documentation for the Struct.

Adding Fields

To add fields to a... more

Enums

An Enum is a list of pre-defined values. To create an Enum select "Edit|New|Enum" or click the "Enum" button on the Toolbar.

Selecting the Enum in the Library Panel will load the details into the Details Panel, in which you can assign a name to the Enum or write documentation for it.

Adding Values

To add a value to the Enum, click the "+ Add Value" button in the Values section of the Details Panel. To remove a value, click the "-" button. Finally to name or rename a value, select the value in the table and type the new... more

Arrays

An array is a list of elements that have the same type. An array can consist of primitive types or complex types defined in your Library or in a Library that you are using. To create an Array, select "Edit|New|Array" or click the "Array" button on the Toolbar.

Selecting the Array in the Library Panel will load the details into the Details Panel, from which you can name the Array, specify the type of elements the array will contain or write documentation for it.

Services

A service is the base foundation of your RemObjects SDK server and it defines the methods that will be made available to your RemObjects SDK clients. To create a service, select "Edit|New|Service" or click the "Service" button on the Toolbar.

Selecting the service in the Library Panel will load the details into the Details Panel. From there you can assign a name to the service, inherit the service from an existing one by specifying the Ancestor or write documentation for it.

Adding and Removing Operations (Methods)

In the Operations section of the Details Panel, you can define the operations or... more

Event Sinks

An Event Sink provides a collection of event methods that your server can use to propagate events back to the clients. In essence, Event Sinks are services that work "backwards", allowing your Client to implement the defined operations and the server to call them.

To create a service, select "Edit|New|Event Sink" or click the "Event Sink" button on the Toolbar.

Selecting the Event Sink in the Library Panel will load the details into the Details Panel. In the Details Panel you can assign a name to the event sink, inherit the event sink from an existing one by specifying the... more

Exceptions

An Exception is an object that represents a programming exception.

To create an Exception, select "Edit|New|Exception" or click the "Exception" button on the Toolbar.

Selecting the Exception in the Library Panel will load the details into the Details Panel, from which you can assign a name to the Exception, inherit the Exception from an existing one by specifying the Ancestor, or write documentation for it.

Adding Fields

To add fields to an exception, click the "+ Add Field" button in the Fields section of the Details Panel. To remove an element, click the "-" button. Finally to name or rename... more

Documentation Editor

The Documentation Editor provides you a way to edit the documentation for the items in your library.

You can invoke it by double-clicking the Documentation field of top level items such as Services and Structs in the Details Pane or by selecting the "Document this..." button for sub-items such as Fields, Operations, Parameters, etc.

For convenience, while typing descriptions, the "Enter" key has not been bound to the "Ok" button, but will work as standard Carriage Return/Line Feed in the Editor. Use Ctrl+Enter to close the editor and accept your changes, or use Esc to close the dialog without keeping your changes.... more


Reusing Existing Libraries

The Service Builder offers two options for reusing existing types and services in a project, you can Use an Existing RODL or you can Import one.

The Use an Existing RODL option adds a reference to an existing RODL to your project. If you make changes to the existing RODL later then those changes will be reflected in your new Library as well. When this option is chosen, no code will be generated for the definitions pulled in from the existing RODL, instead the CodeGen will add the units from the existing RODL to your uses clauses (in Delphi), or it will rely on them to being defined in the same Namespace as the new RODL (in C#).

The Import RODL option will simply copy the definitions from the old RODL to your new one, which will then be treated as if you had manually entered them.

You should choose to Import a RODL when the project you are working on is completely independent from the previous RODL and you only want a shortcut to re-create the types and services needed. You should Use an Existing RODL when the two libraries depend on each other and the new library will physically build on the existing one.

Think of it as the difference between copy/pasting a class to your new project by pasting it in a new source file (Import RODL), as opposed to merely referencing the existing unit that implements it (Use Existing RODL).


Topics

Topics

Using Existing Libraries

Similar to a uses clause in Delphi or a using statement in C#, RemObjects Libraries can use existing services. By using an existing Library in your project, you can use and extend all its elements.

To use an existing library, click "Edit" then select "Include Existing RODL".

In the resulting dialog, browse to or enter the file path of the desired RODL file. The Service Builder will then add a new item to the Library Panel to indicate that you are using the Library.

Depending on the edition of the RemObjects SDK that you have installed, certain predefined RODL files... more

Importing Libraries

When you wish to create a totally new library based on the design of an existing one, simply import it and modify it as needed. The RemObjects Service Builder allows you to import existing libraries from SOAP Web Services (WSDL) and native RemObjects SDK Services (RODL).

The Importer interface is also plugable, so additional import can be provided through plugins.

All available importers can be invoked from the "Edit | Import" menu item:

Depending on the importer, you will presented with a file dialog or an importer-specific dialog that allows you to select which one to import.

When importing a library, the... more


Using Existing Libraries

Similar to a uses clause in Delphi or a using statement in C#, RemObjects Libraries can use existing services. By using an existing Library in your project, you can use and extend all its elements.

To use an existing library, click "Edit" then select "Include Existing RODL".

In the resulting dialog, browse to or enter the file path of the desired RODL file. The Service Builder will then add a new item to the Library Panel to indicate that you are using the Library.

Depending on the edition of the RemObjects SDK that you have installed, certain predefined RODL files might be available for you to reuse directly from the menu - e.g. for DataSnap or Data Abstract:

After choosing the RODL file to use, you will see this item listed in the Library tree with all the elements provided by this library listed underneath it:

From here, you can change the name, the file name and the documentation for the use of the RODL file.

Note that all elements defined in the used RODL are listed in the Library pane in gray and are in read-only mode; you can select them to view their details, but you cannot modify them.


Importing Libraries

When you wish to create a totally new library based on the design of an existing one, simply import it and modify it as needed. The RemObjects Service Builder allows you to import existing libraries from SOAP Web Services (WSDL) and native RemObjects SDK Services (RODL).

The Importer interface is also plugable, so additional import can be provided through plugins.

All available importers can be invoked from the "Edit | Import" menu item:

Depending on the importer, you will presented with a file dialog or an importer-specific dialog that allows you to select which one to import.

When importing a library, the importer might issue warnings or even errors about its elements, which will be shown in the message pane at the bottom of the Service Builder window, once the import has completed.

In many cases, you can work around problems encountered during import by manually changing the library to your needs. Consult the provider of the imported data or the RemObjects SDK newsgroups if you have specific import problems.

IDE Integration

Depending on the development environment that you use, one or more of the provided importers might also be available directly in your IDE's "RemObjects" menu.


Topics

Topics

Import SOAP Web Service (WSDL)

The SOAP Web Service (WSDL) importer presents you with the following dialog, which allows you to import either a WSDL file from your local hard disk or connect directly to a SOAP server and download a description (WSDL) file:

Once you have browsed for the correct file or entered the URL of your web service, click the "Import" button to import the service into your library.

Import RemObjects SDK Service (RODL)

The RemObjects SDK Service (RODL) importer presents you with the following dialog, which allows you to import either a RODL file from your local hard disk or connect directly to a RemObjects SDK server and download a description (RODL) file:

Once you have browsed for the correct file or entered the URL of your web service, click the "Import" button to import the service into your library.


Import SOAP Web Service (WSDL)

The SOAP Web Service (WSDL) importer presents you with the following dialog, which allows you to import either a WSDL file from your local hard disk or connect directly to a SOAP server and download a description (WSDL) file:

Once you have browsed for the correct file or entered the URL of your web service, click the "Import" button to import the service into your library.


Import RemObjects SDK Service (RODL)

The RemObjects SDK Service (RODL) importer presents you with the following dialog, which allows you to import either a RODL file from your local hard disk or connect directly to a RemObjects SDK server and download a description (RODL) file:

Once you have browsed for the correct file or entered the URL of your web service, click the "Import" button to import the service into your library.


Structs

A struct is an object that contains properties, but no actual functionality. The properties of a struct can consist of primitive types or complex types defined in your Library or in a Library that you are using.

To create a struct, select "Edit|New|Struct" or click the "Struct" button on the Toolbar.

Selecting the Struct in the Library Panel will load the details into the Details Panel. From here you can assign a name to the Struct, inherit the Struct from an existing one by specifying the Ancestor, or write documentation for the Struct.

Adding Fields

To add fields to a struct, click the "+ Add Field" button in the Fields section of the Details Panel. To remove an element, click the "-" button. Finally, to name or rename an element, select the element name in the table and type the new name. As explained above, an element data type can be a primitive type or a complex type defined in your Library or in a Library that you are using.

Change the order of the fields with the Up/Down buttons, or the Ctrl+Up and Ctrl+Down keyboard shortcuts.

You can also provide documentation for your struct fields by selecting the individual items and clicking the "Document this Field" button. This will bring up the Documentation Editor, where you can type your description.


Enums

An Enum is a list of pre-defined values. To create an Enum select "Edit|New|Enum" or click the "Enum" button on the Toolbar.

Selecting the Enum in the Library Panel will load the details into the Details Panel, in which you can assign a name to the Enum or write documentation for it.

Adding Values

To add a value to the Enum, click the "+ Add Value" button in the Values section of the Details Panel. To remove a value, click the "-" button. Finally to name or rename a value, select the value in the table and type the new name.

Change the order of the values with the Up/Down buttons, or the Ctrl+Up and Ctrl+Down keyboard shortcuts.

You can also provide documentation for your enum values by selecting the individual items and clicking the "Document this Value" button. This will bring up the Documentation Editor, where you can type your description.


Arrays

An array is a list of elements that have the same type. An array can consist of primitive types or complex types defined in your Library or in a Library that you are using. To create an Array, select "Edit|New|Array" or click the "Array" button on the Toolbar.

Selecting the Array in the Library Panel will load the details into the Details Panel, from which you can name the Array, specify the type of elements the array will contain or write documentation for it.


Services

A service is the base foundation of your RemObjects SDK server and it defines the methods that will be made available to your RemObjects SDK clients. To create a service, select "Edit|New|Service" or click the "Service" button on the Toolbar.

Selecting the service in the Library Panel will load the details into the Details Panel. From there you can assign a name to the service, inherit the service from an existing one by specifying the Ancestor or write documentation for it.

Adding and Removing Operations (Methods)

In the Operations section of the Details Panel, you can define the operations or methods of your service. To define a new operation, click the "+ Add Operation" button above the Operation table. To remove an operation, click the "-" button. Finally, to name or rename an operation, select the operation in the operations table and type the new name.

Change the order of the operations with the Up/Down buttons, or the Ctrl+Up and Ctrl+Down keyboard shortcuts.

You can also provide documentation for your operations by selecting the individual items and clicking the "Document this Operation" button. This will bring up the Documentation Editor, where you can type your description.

Adding and Removing Parameters (Arguments) for an Operation

You can add arguments by clicking the "+ Add Parameter" button above the arguments table and remove them by clicking the "-" button.

The Flag property of an argument defines how the argument is passed between the client and server. A value of in means that the client will pass the value to the server. out means that the server will pass the value back to the client. Finally, in/out means that the client may pass the value to the server and the server may also pass the value (possibly modified) back to the client.

The Name property of an argument simply defines the argument name.

The Datatype property of an argument defines the argument type. This can be a "primitive" type, such as Integer, or a complex type defined in your Library or in a Library that you are using.

Change the order of the parameters with the Up/Down buttons, or the Ctrl+Up and Ctrl+Down keyboard shortcuts.

You can also provide documentation for your parameters by selecting the individual items and clicking the "Document this Parameter" button. This will bring up the Documentation Editor, where you can type your description.

Operation Result Types

The final consideration, when creating an operation, is the result type. The result is the expected result of the operation, which can be a "primitive" type, such as Integer, or a complex type defined in your Library or in a Library that you are using.


Event Sinks

An Event Sink provides a collection of event methods that your server can use to propagate events back to the clients. In essence, Event Sinks are services that work "backwards", allowing your Client to implement the defined operations and the server to call them.

To create a service, select "Edit|New|Event Sink" or click the "Event Sink" button on the Toolbar.

Selecting the Event Sink in the Library Panel will load the details into the Details Panel. In the Details Panel you can assign a name to the event sink, inherit the event sink from an existing one by specifying the Ancestor or write documentation for it.

Adding and Removing Events (Methods)

In the Operations section of the Details Panel you can define the events, or callback-methods, of your event sink. To define a new event, click the "+ Add Event button above the Events table. To remove an event, click the "-" button. Finally to name or rename an event, select the event in the events table and type the new name.

Change the order of the events with the Up/Down buttons, or the Ctrl+Up and Ctrl+Down keyboard shortcuts.

You can also provide documentation for your events by selecting the individual items and clicking the "Document this Event" button. This will bring up the Documentation Editor, where you can type your description.

Adding and Removing Parameters (Arguments) for an Event

You can add arguments by clicking the "+ Add Parameter" button above the arguments table, or remove them by clicking the "-" button.

Because Events are one-way calls from the Server to the client, the only supported Flag type is in.

Change the order of the parameters with the Up/Down buttons, or the Ctrl+Up and Ctrl+Down keyboard shortcuts.

You can also provide documentation for your parameters by selecting the individual items and clicking the "Document this Parameter" button. This will bring up the Documentation Editor, where you can type your description.


Exceptions

An Exception is an object that represents a programming exception.

To create an Exception, select "Edit|New|Exception" or click the "Exception" button on the Toolbar.

Selecting the Exception in the Library Panel will load the details into the Details Panel, from which you can assign a name to the Exception, inherit the Exception from an existing one by specifying the Ancestor, or write documentation for it.

Adding Fields

To add fields to an exception, click the "+ Add Field" button in the Fields section of the Details Panel. To remove an element, click the "-" button. Finally to name or rename an element, select the element name in the table and type the new name. As explained above, an element data type can be a primitive type, or a complex type defined in your Library or in a Library that you are using.

Change the order of the fields with the Up/Down buttons, or the Ctrl+Up and Ctrl+Down keyboard shortcuts.

You can also provide documentation for your exception fields by selecting the individual items and clicking the "Document this Field" button. This will bring up the Documentation Editor, where you can type your description.


Documentation Editor

The Documentation Editor provides you a way to edit the documentation for the items in your library.

You can invoke it by double-clicking the Documentation field of top level items such as Services and Structs in the Details Pane or by selecting the "Document this..." button for sub-items such as Fields, Operations, Parameters, etc.

For convenience, while typing descriptions, the "Enter" key has not been bound to the "Ok" button, but will work as standard Carriage Return/Line Feed in the Editor. Use Ctrl+Enter to close the editor and accept your changes, or use Esc to close the dialog without keeping your changes.


Generating Access to your Library

The RemObjects Service Builder allows you to generate files that describe your Library. These files can then be imported into your project to consume the services defined within the library. Supported export formats include RODL, WSDL, and Source Code. In order to ensure that the export will be successful, before a library can be exported it needs to be Validated. You may preview the available formats by clicking the corresponding format button on the toolbar.

If you are using the RemObjects SDK in combination with Delphi, Visual Studio .NET or C#Builder, most of these generation tasks will be automated by your IDE. For example, if you choose to "Import RemObjects SDK Service" from your IDE, the appropriate Interface File will automatically be generated and added to your project.


Topics

Topics

Validating the Library

You can invoke the Validation via the "Tools|Check Library for Problems" menu. This will run the default validator as well as any custom validation plugins that you might have registered.

If any problems arise during validation, the Messages panel will appear at the bottom with Hints, Warnings or Errors.

In order to fix a problem, simply double-click on a message to locate the element.

RODL

An RODL file defines a Library in the RemObjects Definition Language XML file format. The RODL file can be previewed by choosing the "View|RODL" menu.

WSDL

An WSDL file defines a Library in the Web Services Definition Language XML file format. The WSDL file can be previewed by choosing the "View|WSDL" menu.

To save the library definition file in WSDL format on disk, click the "Save As..." button in the WSDL Pane:

Source Code

The Service Builder can export a Library to several languages including Delphi, C#, Delphi for .NET and C++.

Similar to all other Service Builder components, the number of languages available depends on the version of the RemObjects SDK that you have installed.

To generate a source code file on disk, select "Generate" and then select the type of file that you wish to create.

Docs

When Building a Library, you can specify documentation text for each of its elements. The Service Builder enables you to generate HTML documentation that describes all the elements defined in your Library.

This documentation file can be previewed by choosing the "View|Documentation" menu.


Validating the Library

You can invoke the Validation via the "Tools|Check Library for Problems" menu. This will run the default validator as well as any custom validation plugins that you might have registered.

If any problems arise during validation, the Messages panel will appear at the bottom with Hints, Warnings or Errors.

In order to fix a problem, simply double-click on a message to locate the element.


RODL

An RODL file defines a Library in the RemObjects Definition Language XML file format. The RODL file can be previewed by choosing the "View|RODL" menu.


WSDL

An WSDL file defines a Library in the Web Services Definition Language XML file format. The WSDL file can be previewed by choosing the "View|WSDL" menu.

To save the library definition file in WSDL format on disk, click the "Save As..." button in the WSDL Pane:


Source Code

The Service Builder can export a Library to several languages including Delphi, C#, Delphi for .NET and C++.

Similar to all other Service Builder components, the number of languages available depends on the version of the RemObjects SDK that you have installed.

To generate a source code file on disk, select "Generate" and then select the type of file that you wish to create.


Docs

When Building a Library, you can specify documentation text for each of its elements. The Service Builder enables you to generate HTML documentation that describes all the elements defined in your Library.

This documentation file can be previewed by choosing the "View|Documentation" menu.

Note: you can provide your own layout for the generated documentation by creating a custom XSLT Style sheet file, named "ROSBStandardViews.documentation.xsl", and by placing it next to the Service Builder. To restore the original format, simply remove or rename the file.


Command Line Switches

Command Line Switches * Service Builder knows and reacts to the following command line switches.

Most of these switches are used by the IDE integration and other RemObjects SDK tools when communicating with the Service Builder and should not be useful to start it manually.

<file-name> If the first parameter passed to the Service Builder is a filename, it will automatically load the specified RODL at startup. If the file is not found, a new Library will be created.

/autosave Used with the IDE integration. If called with this switch, Service Builder will automatically save changes to the RODL when losing focus. This enables you to keep the Service Builder open next to Delphi, make changes in it and have them automatically reflected when you switch back to the Delphi IDE.

/projectname:<name> Used with the IDE integration. If called with this switch, Service Builder will display the passed project name in the titlebar and the Taskbar button, instead of the filename of the actual RODL.

/displayname:<name> If called with this switch, Service Builder will display the passed project name in the titlebar and the Taskbar button.

/import:<type> Used by the IDE integration. The Service Builder launches the importer specified by <type>. The <type> can refer to any importer plugin, such as Import.Rodl, Import.Soap.Wsdl or any custom importer installed with Service Builder.

/quietimport The Service Builder will exit after importing instead of keeping the library open for editing.

/export:<type> Upon exiting, Service Builder will export the library using the specified codegen. <type> must be one or more of the registered CodeGens. Wildcards may be used to specify a group of codegens. Examples: CodeGen.CSharp.Intf or CodeGen.Delphi.*

/export-file:<file-name> File name to save the exported code to.

/export-folder:<folder-name> Folder name to save all exported code files to; default names provided by CodeGen will be used.

/execute:<plugin> Execute the custom action plugin (for example "DataAbstract.PublishSchemaWizard").

/register The Service Builder will create file associations for the extension ".rodl" in the registry and then exit immediately. If you install the RemObjects SDK via the installer provided, this is done for you automatically.

/ns Omit the display of the splash screen


Writing Plugins

An article describing how to write custom Plugins for Service Builder 3 is available on our website. Click here.


RemObjects SDK Reference

This reference section provides detailed information about all the components, classes and types that make up the RemObjects SDK library.

You can not only browse the reference based help by hierarchy here, but you can also invoke context sensitive help on identifiers and components directly from your source code or form designers in Delphi, by simply pressing F1.


RemObjects SDK Reference Classes

Classes

EROAsyncException

This class provides the base for exceptions related to asynchronous calls.

Please refer to the Asynchronous Calls help topic for more detailed information.

EROAsyncNoAnswerYet

This exception is raised if the Retrieve_ method for an asynchronous call is called,but no response is available yet.

This is an expected exception in asynchronous scenarios, and the usual reaction should be to catch this exception and retry the call to the Retrieve_ method at a later time. Alternatively, the AnswerReceived flag of the IROAsyncInterface can be used to actively check if a response is available yet, or the AnswerReceivedEvent Win32 event object can be used to pause the current thread until a response is available.

Please refer to the IROAsyncInterface interface and the Asynchronous Calls help topic for more detailed information.

EROChannelBusy

This exception is raised if an attempt is made to send a remote request to a channel that is busy.

While some channels (such as the TROSuperTcpChannel) are capable of transmitting several requests simultaneously, most of them, including the commonly used TCP and HTTP based channels, can only process one request at a time. If you need to send requests from multiple threads at the same time, you will need to create separate instances of the channel, one for each thread.

EROException

This class provides the base for all custom exception types defined within the RemObjects SDK. It provides no additional functionality on top of Delphi's base Exception class, except that it can provide an easy way to catch any RemObjects SDK related exception in a try/except statement.

EROPoolNoFreeObjects

This exception is raised by the TROPooledClassFactory if its pool behavior is set to pbFail and all pool instances are currently active serving requests.

This can be intentional, if access is supposed to be restricted to a maximum number of active instances (for example to accommodate limited server resources); to avoid this exception, consider changing the pool behavior to pbWait or pbCreateAdditional , instead.

Please refer to the TROPoolBehavior help topic for a more detailed discussion of the available options.

EROUnregisteredServerException

This exception is raised on a client if any exception has been received form the server that is not known to the client application.

For exceptions to be properly propagated from the server to the client, the respective exception classes must be registered on the client using the RegisterExceptionClass procedure. This is done automatically for classes defined within the RemObjects SDK or in the applications's RODL file, but any additional exceptions classes defined by the Delphi RTL, third party libraries or custom user code will be unknown to the RemObjects SDK, and raised in form of an EROUnregisteredServerException.

To make... more

EROSendNoResponse

This exception type is used internally by the ROSendNoResponse method. Please refer to the ROSendNoResponse method and Asynchronous Calls help topics for more information.

You will usually not raise or catch instances of this exception in your own code.

EROServerException

This exception provides the base class for all custom exceptions defined in your application's RODL file and provides the basic functionality for enabling exceptions to be propagated from the server to the client and re-raised properly.

EROSessionExpired

This exception class is a descendant of the more generic EROSessionNotFound exception that is raised if a session still exists, but has expired since the last call.

Please refer to the EROSessionNotFound help topic for more information.

EROSessionNotFound

This exception is raised by servers requiring authentication, for example implemented using the RemObjects SDK standard authentication pattern, to indicate that no session exists on the server yet, and a login is needed.

This can happen automatically, when the RequiresSession property of a remote service is set, or manually, as needed.

Client channels have special logic in place to catch this exception and fire a OnLoginNeeded event, which can be handled to perform a login on the fly and restart the failed request.

Please refer to the Login and Authentication help topic for a more detailed exploration of the login and authentication... more

EROUnknownType

This exception is raised by the RemObjects SDK streaming infrastructure if a complex type, that has not been registered, is found in the received message.

The most common cause for this exception is a mismatch between _Intf on client and server. For example new types have been added to the RODL on the server side, but the client application has not been updated to use the latest version of the _Intf file. Or the application uses complex types defined in code, that are not properly registered on both client and server.

SessionNotFoundException

This exception type is provided for compatibility with RemObjects SDK for .NET Servers only; it should not be used in your code.

Similar to the EROSessionNotFound exception class used by the Delphi edition, RemObjects SDK for .NET raises a RemObjects.SDK.Exception.SessionNotFoundException when a login is needed before accepting calls into a specific server. This exception type is provided as a descendant from EROSessionNotFound so that exceptions raised on a .NET server can be handled appropriately in Delphi clients.

TROArray

TROArray forms the base class for all "array" types defined in your library.

TROAsyncProxy

This class forms the base for proxy classes in the _Async units generated from your RODL.

TROBaseConnection

TROBaseConnection forms the base class for RemObjects SDK Clients (Channels) and Servers.

TRODiscoveryOptions

TRODiscoveryOptions is an (empty) struct that forms a base for passing custom data between clients and server when using Service Discovery.

To pass actual information, you would add a new struct to your RODL file, descending from RODiscoveryOptions, and pass instances of that class to the TRODiscoveryClient.RefreshServerList method or back from the TRODiscoveryServer.OnServiceFound event.

TROBinaryMemoryStream

The TROBinaryMemoryStream (or short Binary) class builds upon the standard memory stream provided by the Delphi VCL to extend it with additional methods that make it easier to use.

The class forms the basis for passing unstructured binary data between clients and servers, and will be used whenever you declare "Binary" types in your RODL files.

TROBinMessage

TROBinMessage implements message encoding for the efficient and proprietary BinMessage message format.

BinMessage provides the best performance of all the provided message formats, resulting in very small data packets that can be read and written with little processing overhead. It also supports compression to decrease the wire size of larger messages.

Please refer to the BinMessage help topic for more details on the this message format.

TROBPDXHTTPServer

TROBPDXHTTPServer implements a HTTP based server that uses the HTTP implementation provided by the third party DXSock 3.0 library that is shipped free with the RemObjects SDK.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

TROBPDXTCPServer

TROBPDXHTTPServer implements a TCP based server that uses the socket implementation provided by the third party DXSock 3.0 library that is shipped free with the RemObjects SDK.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

TROBroadcastChannel

TROBroadcastChannel implements a UDP based channel that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Building upon the TROIndyUDPChannel, the broadcast channel will not send its requests to one specific server, but will broadcast them to all servers listening on the local subnet.

The OnBroadcastResponseReceived event will be fired for each response that is received.

TROBroadcastServer

TROBroadcastServer implements a UDP based server that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Building upon the TROIndyUDPServer, the broadcast server is intended to work with broadcast messages that are sent to a (possibly large) number of hosts on the local network.

Essential Properties 	Active toggles whether the server ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests are processed and dispatched.

TROClassFactory

TROClassFactory forms the base class of all class factories provided with the RemObjects SDK.

TROComplexType

TROComplexType forms the base class for all "struct" types defined in your library.

TROConstantMemoryStream

TROConstantMemoryStream is a custom memory stream implementation, optimized for read-only access.

TROCustomDiscoveryClient

This class implements the client side of the local network server discovery infrastructure in the RemObjects SDK.

TROCustomDiscoveryServer

This class implements the server side of the local network server discovery infrastructure in the RemObjects SDK.

TROCustomEmailChannel

TROEmailChannel implements a channel that uses standard email infrastructure to send messages between client and server. The channel is based on the open source Indy components that ship with Delphi.

Due to the nature of how email delivery works, this channel is best-suited for asynchronous communications and scenarios where a response to a request is not expected in real time or even during the lifetime of the application.

TROCustomEmailServer

TROEmailServer implements a server that uses standard email infrastructure to send messages between client and server. The channel is based on the open source Indy components that ship with Delphi.

Due to the nature of how email delivery works, this channel is best-suited for asynchronous communications and scenarios where a response to a request is not expected in real time or even during the lifetime of the application.

TROCustomIndyTCPChannel

TROIndyTCPChannel implements a TCP based channel that uses the socket implementation provided by the open source Indy components that ship with Delphi.

TROCustomIndyTCPServer

TROIndyHTTPServer implements a TCP based server that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

TROCustomSessionManager

TROCustomSessionManager forms the base class of all session managers provided by the RemObjects SDK, and can also be used as the base class for implementing your own special session manager.

TROCustomSuperTcpChannel

TROSuperTCPChannel implements the new and enhanced TCP based channel introduced with the RemObjects SDK 4.0, which provides a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

The channel is based on the open source Indy components that ship with Delphi.

TROCustomSuperTcpServer

TROSuperTCPServer implements the server side of the new and enhanced TCP based channel introduced with the RemObjects SDK 4.0, which provides a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

The channel is based on the open source Indy components that ship with Delphi.

TRODBSessionManager

TRODBSessionManager implements a sophisticated session manager that stores session data in a database accessed by standard Delphi data access components. This database can in theory be shared by multiple servers, allowing session state to be accessible across a server farm.

TRODiscoveryClient

TRODiscoveryServer

This class implements the server side of the local network server discovery infrastructure in the RemObjects SDK.

TRODLLChannel

TRODLLChannel implements a channel that talks to services located in a local DLL file.

The server must be a .dll created using the DLL Server New Project Template.

TRODLLibrary

The TRODLLibrary class is used as an in-memory representation of a RODL file. It provides strongly-typed access to the services, and types defined within the RODL.

TRODynamicRequest

The Dynamic Request component can be used to construct requests to a server dynamically at runtime, without the method information or a proxy object being available at compile time.

This can be done by setting up the request based on data from a RODL file, or by manually specifying the method name and defining parameters for the call in code.

TROEmailChannel

TROEmailChannel implements a channel that uses standard email infrastructure to send messages between client and server. The channel is based on the open source Indy components that ship with Delphi.

Due to the nature of how email delivery works, this channel is best-suited for asynchronous communications and scenarios where a response to a request is not expected in real time or even during the lifetime of the application.

TROEmailServer

TROEmailServer implements a server that uses standard email infrastructure to send messages between client and server. The channel is based on the open source Indy components that ship with Delphi.

Due to the nature of how email delivery works, this channel is best-suited for asynchronous communications and scenarios where a response to a request is not expected in real time or even during the lifetime of the application.

TROEncryption

This class provides settings for encrypting and decrypting communication at the channel level. It's available through the Encryption property on all channels and servers.

TROEventReceiver

The Event Receiver component is used on the client to enable receiving callback events from the server.

Depending on the channel type, this will be done by regularly polling the server for new events or, if the channel supports active sending of events, by simply awaiting events to be sent from the server.

TROEventRepository

TROEventRepository forms the base class of all event repository components provided by the RemObjects SDK, and can also be used as the base class for implementing your own.

TROEventSessionManager

TROEventSessionManager implements a session manager that uses events to allow the use of custom code to access and store session data in user-defined ways.

Whenever the session manager needs to access or update session data, an event is fired.

TROIndyHTTPChannel

TROIndyHTTPChannel implements an HTTP based channel that uses the HTTP implementation provided by the open source Indy components that ship with Delphi.

TROIndyHTTPServer

TROIndyHTTPServer implements an HTTP based server that uses the HTTP implementation provided by the open source Indy components that ship with Delphi.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients or not

Dispatchers specifies how incoming requests will be processed and dispatched

TROIndyTCPChannel

TROIndyTCPChannel implements a TCP based channel that uses the socket implementation provided by the open source Indy components that ship with Delphi.

TROIndyTCPServer

TROIndyHTTPServer implements a TCP based server that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

TROIndyUDPChannel

TROIndyUDPChannel implements a UDP based channel that uses the socket implementation provided by the open source Indy components that ship with Delphi.

TROIndyUDPServer

TROIndyHTTPServer implements a UDP based server that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

TROInMemoryEventRepository

TROInMemoryEventRepository implements an event repository that stores event data in local memory.

TROInMemorySessionManager

TROInMemorySessionManager implements a session manager that stores session data in local memory.

TROLocalChannel

TROLocalChannel implements a channel that talks to services in the same executable via a TROLocalServer.

This channel is helpful when creating a single-tier version of an existing client/server application, and you want to combine client and server logic in the same executable and avoid the overhead of a "real" communication channel between client and server.

TROLocalServer

TROLocalServer implements a server that makes services available for consumption from within the same executable via a TROLocalChannel.

This channel is helpful when creating a single-tier version of an existing client/server application, and you want to combine client and server logic in the same executable and avoid the overhead of a "real" communication channel between client and server.

TROMasterServerEventRepository

TROMasterServerEventRepository implements an event repository that uses the Master Server back-end to store event data.

TROMasterServerSessionManager

TROMasterServerSessionManager implements a session manager that uses the Master Server back-end to store and access session data.

TROMessage

TROMessage is the base class for all message format components provided with the SDK.

You will usually not create instances of this class directly, but use the four descendant components, instead.

TROMessageDispatcher

This class is used by the TROServer component to configure the list of dispatchers provided by the server.

You will usually not create instances of this class yourself, but work with them using the TROServer.Dispatchers collection property.

TRONamedPipeChannel

TRONamedPipeChannel implements a channel that uses Windows Named Pipes to communicate between a client and a server on the same machine or local network.

TRONamedPipeServer

TRONamedPipeServer implements a server that is accessible from clients on the same machine or local network using Windows Named Pipes.

TROPerClientClassFactory

TROPerClientClassFactory provides a class factory that ties each service instance to a particular client.

Service instances will be associated with a client using the ClientID, and each request form the same client will be served by the same instance.

TROPooledClassFactory

TROPooledClassFactory is a class factory that maintains a list of instances of server objects.

Rather than creating a separate instance for each call or always using the same instance, TROPooledClassFactory creates a predefined number of instances and returns the first one currently available to the caller.

You can control some aspects of class factory behavior via the TROPooledClassFactory.Create constructor.

Please refer to the Class Factories help topic for a more detailed discussion of available class factory types.

TROPostMessage

TROPostMessage implements message encoding using a simple text messaging format compatible with HTTP "Post" data.

Please refer to the PostMessage help topic for more details on this message format.

TROPoweredByRemObjectsButton

TROPoweredByButton is a visual component that shows an image button with the RemObjects SDK logo and the text "powered by RemObjects SDK". You can use it in your application's About box to let users know that your application was build with RO.

Clicking the button will open the RemObjects Software homepage (http://www.remobjects.com) in the user's default web browser.

TROProxy

This class forms the base for proxy classes in the _Intf units generated from your RODL.

TRORemoteDataModule

TRORemoteDataModule is the default base class for implementing new services using the RemObjects SDK.

It descends from TDataModule and as such provides a design surface that you can use to drop non-visual components on at design time. You can also use the Object Inspector to change its published properties.

TRORemoteService

The Remote Service component is used to represent the connection to a remote service - both the channel and message component as well as the name of the service.

TRORequestParam

The TRORequestParam class is used to represent an individual parameter in a TRODynamicRequest.

TRORequestParamCollection

The TRORequestParamCollection class is used to represent the list of parameters for a TRODynamicRequest.

TROServer

TROServer is the common base class for all server channel implementations in the RemObjects SDK.

You will not use instances of this class directly, but work with the descendant server implementations. Please refer t the Channels help topic, for a complete overview of available channels and servers.

TROServerLocator

This class contains configuration data for an individual server that will be included in fail-over and load balancing support of a TROTransportChannel component.

You will not instantiate instances of this class yourself, but rather use the TROTransportChannel.ServerLocators collection property to define server locators for your channel.

TROService

TROService is a helper class used to implement the Combo templates that can act as Windows Service and standalone VCL application. It descends from Delphi's TService implementation to provide some extended internal functionality needed for the dual use.

TROSession

The TROSession class represents an individual user session within the RemObjects SDK Session Management system.

TROSingletonClassFactory

TROSingletonClassFactory provides a class factory that implements the Singleton pattern: only one instance of the service class will ever be created, and this same class will be used to service all requests.

TROSOAPMessage

TROSoapMessage implements message encoding using the Simple Object Access Protocol (SOAP), a standardized XML based protocol for exchanging messages between client and server that forms the foundation of Web Services.

Please refer to the SOAP Message help topic for more details on SOAP and Web Services.

TROSuperTcpChannel

TROSuperTCPChannel implements the new and enhanced TCP based channel introduced with the RemObjects SDK 4.0, which provides a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

The channel is based on the open source Indy components that ship with Delphi.

TROSuperTcpServer

TROSuperTCPServer implements the server side of the new and enhanced TCP based channel introduced with the RemObjects SDK 4.0, which provides a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

The channel is based on the open source Indy components that ship with Delphi.

TROSynapseHTTPChannel

TROSynapseHTTPChannel implements an HTTP based channel that uses the HTTP implementation provided by the open source Synapse components that are available at http://synapse.ararat.cz.

TROSynchronizedSingletonClassFactory

This class provides a class factory that implements the Singleton pattern: only one instance of the service class will ever be created, and this same class will be used to service all requests.

In contrast to its base class, the TROSingletonClassFactory, this factory will not allow simultaneous access by several clients. Instead, access will by synchronized using a critical section, to make sure only one request executes at the same time.

TROTransportChannel

TROTransportChannel is the common base class for all client channel implementations in the RemObjects SDK.

You will not use instances of this class directly, but work with the descendant channel implementations. Please refer to the Channels help topic, for a complete overview of available channels and their compatible servers.

TROWebBrokerServer

TROWebBrokerPServer implements an HTTP server based on Delphi's WebBroker infrastructure.

The resulting server is a not a standalone server, but a ISAPI/NSAPI, Apache DSO or CGI module that can be hosted in an existing web server such as IIS or Apache.

Essential Properties 	Active toggles whether the server ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

TROWinInetHTTPChannel

TROWinInetHTTPChannel implements an HTTP based channel that uses the WinInet HTTP implementation provided by the Windows operating system.

As such, the channel will automatically make use of options such as proxy and firewall settings, and the online/offline state configured for Internet Explorer or using the Internet Control Panel. It is the most commonly used and recommended HTTP channel.

TROWinMessageChannel

TROWinMessageChannel implements a channel that uses Windows Messages to communicate between a client and a server on the same local machine.

TROWinMessageServer

TROWinMessageChannel implements a server that uses Windows Messages to communicate between a client and a server on the same local machine.

TROXmlRpcMessage

TROXmlRpcMessage implements message encoding using the XMLRPC protocol, a predecessor of SOAP and WebServices.

Please refer to the XML-RPC Message help topic for more details on this message format.


RemObjects SDK Reference Interfaces

Interfaces

 IROAsyncInterface

This interface provides control of the proxy object for an asynchronous service interface.

You can obtain this interface by casting a service interface from your auto-generated _Async unit to IROAsyncInterface.

 IROEventWriter

IROEventsWriter forms the base interface for Event Sink proxies on the server.

It contains a number of properties that allow you to control how events are dispatched to clients.

 IROStream

The IROStream interface wraps access to a Delphi TStrean instance to provide a reference-counted, interface-based reference that can be freed automatically as it goes out of scope.

IROStream exposes all the basic methods and properties of TStream, and also exposes the underlying wrapped object via the Stream property. Use one of the overloads of the global NewROStream function to instantiate a new IROStream instance.

 IROStrings

The IROStrings interface wraps access to a Delphi TStrings instance to provide a reference-counted, interface-based reference that can be freed automatically as it goes out of scope.

IROStrings exposes all the basic methods and properties of TStrings, and also exposes the underlying wrapped object via the Strings property. Use one of the overloads of the global NewROStrings function to instantiate a new IROStrings instance.

 IROTCPTransport


Legend

Interface


RemObjects SDK Reference Structs, Records, Enums

Structs, Records, Enums

 TRODataType

This enum lists all the data types that are supported for remoting by the RemObjects SDK, with the exception of custom arrays and custom structs, which are both represented by the rtUserDefined value.

Please refer to the Data Types help topic for a detailed description of all supported types.

 TRODispatchOption

This enum provides the different options used to configure failover and load balancing

 TRODLParamFlag

This enum defines the different flags (or directions) that can be applied to a parameter:

 TROPoolBehavior

Determines how the TROPooledClassFactory behaves when more simultaneous calls than can be served by the objects in the pool, come in.

 TROPostMessageBinaryType

Specifies what format is used to encode binary data, Hex or Base64.

 TROProbingOption

This enum provides the different options how sever will be handled during probing.

 TROXMLSerializationOption

Defines several options used to control the exact layout of SOAP messages.


Legend

Enumeration


RemObjects SDK Reference Functions

Functions

 NewROStream

Creates and returns a new IROStream implementation.

Overloads that wrap an existing stream, or create a new wrapped memory stream, are provided.

 NewROStrings

Creates and returns a new IROStrings implementation.

Overloads that wrap an existing TStrings instance, or create a new wrapped TStringList, are provided.

 NewROXmlDocument

Creates and returns a new IXMLDocument implementation.

Depending on the platform (Delphi vs. Kylix) and the configured conditional defines, the XML document will be either based on Microsoft's MSXML implementation or OpenXML.

 RegisterExceptionClass

Registers an Exception class for streaming from servers to clients so that exceptions of this type can be seamlessly re-raised client side.

Usually, RegisterExceptionClass is called for you in the Intf code generated from your RODL file; however you can also call it to register custom exception classes you created in code, if they descend from EROServerException.

 RegisterMessageClass

Registers a TROMessage descendant so that it shows up in the IDE Wizards.

When implementing a new server, you should use this method in the initialization section to make the channel available at design time.

 RegisterROClass

Registers a "complex type" class for streaming between clients and servers.

Usually, RegisterROClass is called for you in the Intf code generated from your RODL file; however you can also call it to register custom exception classes you created in code, if they descend from TROComplexType.

 RegisterServerClass

Registers a TROServer descendant so that it shows up in the IDE Wizards.

When implementing a new server, you should use this method in the initialization section to make the channel available at design time.

 RegisterTransportChannelClass

Registers a TROTransportChannel descendant so that it shows up in the IDE Wizards.

When implementing a new channel, you should use this method in the initialization section to make the channel available at design time.

 ROSendNoResponse

Call this function at the end of your server implementation to return from an asynchronous call without sending a response message.

This is helpful when using asynchronous requests for notifications or to trigger actions on the server, but no information or acknowledgement is expected or needed on the client.

 UnregisterExceptionClass

Registers an exception class that was previously registered via RegisterExceptionClass.

 UnregisterMessageClass

Unregisters a TROMessage descendant that was previously registered with RegisterServerClass.

When implementing a new server, you should use this method in the finalization section.

 UnregisterROClass

Unregisters a "complex type" class that was previously registered via RegisterROClass.

 UnregisterServerClass

Unregisters a TROServer descendant that was previously registered with RegisterServerClass.

When implementing a new server, you should use this method in the finalization section.

 UnregisterTransportChannelClass

Unregisters a TROTransportChannel descendant that was previously registered with RegisterTransportChannelClass.

When implementing a new channel, you should use this method in the finalization section.


Legend

Method


Topics

Topics

Functions

This section lists global procedures and functions included as part of the RemObjects SDK library. While the RemObjects SDK is largely object oriented sand class based, these functions are provided as helper functions or to register/unregister types with the library.


RemObjects SDK Reference Types

Types

Binary

The Binary type is an alias for the TROBinaryMemoryStream class, defined for convenience.

DateTime

The DateTime type is an alias for the Delphi TDateTime type, defined for convenience.

IROEventsWriter

TRODispatchOptions

A set of TRODispatchOption values.

TROProbingOptions

A set of TROProbingOption values.

TROXMLSerializationOptions

A set of TROXMLSerializationOption values.


Legend

Legend

Interface

Enumeration

Method


EROAsyncException Class

This class provides the base for exceptions related to asynchronous calls.

Please refer to the Asynchronous Calls help topic for more detailed information.

Class Hierarchy

File

uROAsync

See Also

Asynchronous Calls help topic

EROException, EROAsyncNoAnswerYet and EROAsyncNoMoreAnswers exceptions

Pascal

EROAsyncException = class(EROException);


See Also

Asynchronous Calls help topic

EROException, EROAsyncNoAnswerYet and EROAsyncNoMoreAnswers exceptions


EROAsyncNoAnswerYet Class

This exception is raised if the Retrieve_ method for an asynchronous call is called,but no response is available yet.

This is an expected exception in asynchronous scenarios, and the usual reaction should be to catch this exception and retry the call to the Retrieve_ method at a later time. Alternatively, the AnswerReceived flag of the IROAsyncInterface can be used to actively check if a response is available yet, or the AnswerReceivedEvent Win32 event object can be used to pause the current thread until a response is available.

Please refer to the IROAsyncInterface interface and the Asynchronous Calls help topic for more detailed information.

Class Hierarchy

File

uROAsync

See Also

Asynchronous Calls help topic

IROAsyncInterface interface

AnswerReceived and AnswerReceivedEvent properties

Pascal

EROAsyncNoAnswerYet = class(EROAsyncException);


See Also

Asynchronous Calls help topic

IROAsyncInterface interface

AnswerReceived and AnswerReceivedEvent properties


EROChannelBusy Class

This exception is raised if an attempt is made to send a remote request to a channel that is busy.

While some channels (such as the TROSuperTcpChannel) are capable of transmitting several requests simultaneously, most of them, including the commonly used TCP and HTTP based channels, can only process one request at a time. If you need to send requests from multiple threads at the same time, you will need to create separate instances of the channel, one for each thread.

Class Hierarchy

File

uROClient

See Also

Channels help topic

TROTransportChannel.Busy property

Pascal

EROChannelBusy = class(EROException);


See Also

Channels help topic

TROTransportChannel.Busy property


EROException Class

This class provides the base for all custom exception types defined within the RemObjects SDK. It provides no additional functionality on top of Delphi's base Exception class, except that it can provide an easy way to catch any RemObjects SDK related exception in a try/except statement.

Class Hierarchy

File

uROClasses

See Also

EROServerException class

Pascal

EROException = class(Exception);


See Also

EROServerException class


EROPoolNoFreeObjects Class

This exception is raised by the TROPooledClassFactory if its pool behavior is set to pbFail and all pool instances are currently active serving requests.

This can be intentional, if access is supposed to be restricted to a maximum number of active instances (for example to accommodate limited server resources); to avoid this exception, consider changing the pool behavior to pbWait or pbCreateAdditional , instead.

Please refer to the TROPoolBehavior help topic for a more detailed discussion of the available options.

Class Hierarchy

File

uROClassFactories

See Also

Class Factories help topic

TROPooledClassFactory class

TROPoolBehavior enumeration

Pascal

EROPoolNoFreeObjects = class(EROException);


See Also

Class Factories help topic

TROPooledClassFactory class

TROPoolBehavior enumeration


EROUnregisteredServerException Class

This exception is raised on a client if any exception has been received form the server that is not known to the client application.

For exceptions to be properly propagated from the server to the client, the respective exception classes must be registered on the client using the RegisterExceptionClass procedure. This is done automatically for classes defined within the RemObjects SDK or in the applications's RODL file, but any additional exceptions classes defined by the Delphi RTL, third party libraries or custom user code will be unknown to the RemObjects SDK, and raised in form of an EROUnregisteredServerException.

To make your own exception types known to the streaming infrastructure, make sure to call RegisterExceptionClass and register your exception in the initialization section of the unit that defines your exception classes.

Class Hierarchy

File

uROClasses

See Also

RegisterExceptionClass procedure

Pascal

EROUnregisteredServerException = class(EROServerException);


See Also

RegisterExceptionClass procedure


EROSendNoResponse Class

This exception type is used internally by the ROSendNoResponse method. Please refer to the ROSendNoResponse method and Asynchronous Calls help topics for more information.

You will usually not raise or catch instances of this exception in your own code.

Class Hierarchy

File

uROServer

See Also

Asynchronous Calls help topic

ROSendNoResponse method

Pascal

EROSendNoResponse = class(EROException);


See Also

Asynchronous Calls help topic

ROSendNoResponse method


EROServerException Class

This exception provides the base class for all custom exceptions defined in your application's RODL file and provides the basic functionality for enabling exceptions to be propagated from the server to the client and re-raised properly.

Class Hierarchy

File

uROClasses

See Also

Files Generated from RODL help topic

EROException class

RegisterExceptionClass procedure

Pascal

EROServerException = class(EROException);


See Also

Files Generated from RODL help topic

EROException class

RegisterExceptionClass procedure


EROSessionExpired Class

This exception class is a descendant of the more generic EROSessionNotFound exception that is raised if a session still exists, but has expired since the last call.

Please refer to the EROSessionNotFound help topic for more information.

Class Hierarchy

File

uROClient

See Also

EROSessionNotFound exception

Pascal

EROSessionExpired = class(EROSessionNotFound);


See Also

EROSessionNotFound exception


EROSessionNotFound Class

This exception is raised by servers requiring authentication, for example implemented using the RemObjects SDK standard authentication pattern, to indicate that no session exists on the server yet, and a login is needed.

This can happen automatically, when the RequiresSession property of a remote service is set, or manually, as needed.

Client channels have special logic in place to catch this exception and fire a OnLoginNeeded event, which can be handled to perform a login on the fly and restart the failed request.

Please refer to the Login and Authentication help topic for a more detailed exploration of the login and authentication mechanisms used by the RemObjects SDK.

Class Hierarchy

File

uROClient

See Also

Login and Authentication topic

TRORemoteDataModule.RequiresSession property

TROTransportChannel.OnLoginNeeded event

SessionNotFoundException class provided for compatibility with .NET

Pascal

EROSessionNotFound = class(EROException);


See Also

Login and Authentication topic

TRORemoteDataModule.RequiresSession property

TROTransportChannel.OnLoginNeeded event

SessionNotFoundException class provided for compatibility with .NET


EROUnknownType Class

This exception is raised by the RemObjects SDK streaming infrastructure if a complex type, that has not been registered, is found in the received message.

The most common cause for this exception is a mismatch between _Intf on client and server. For example new types have been added to the RODL on the server side, but the client application has not been updated to use the latest version of the _Intf file. Or the application uses complex types defined in code, that are not properly registered on both client and server.

Class Hierarchy

File

uROClient

See Also

Files Generated from RODL help topic

RegisterROClass procedure

Pascal

EROUnknownType = class(EROUnknownItem);


See Also

Files Generated from RODL help topic

RegisterROClass procedure


SessionNotFoundException Class

This exception type is provided for compatibility with RemObjects SDK for .NET Servers only; it should not be used in your code.

Similar to the EROSessionNotFound exception class used by the Delphi edition, RemObjects SDK for .NET raises a RemObjects.SDK.Exception.SessionNotFoundException when a login is needed before accepting calls into a specific server. This exception type is provided as a descendant from EROSessionNotFound so that exceptions raised on a .NET server can be handled appropriately in Delphi clients.

Class Hierarchy

Notes

You will not usually raise exceptions of this type manually in your own Delphi code. Use EROSessionNotFound instead.

File

uROClient

See Also

EROSessionNotFound exception

Pascal

SessionNotFoundException = class(EROSessionNotFound);


See Also

EROSessionNotFound exception


TROArray Class

TROArray forms the base class for all "array" types defined in your library.

Use Case

You will usually not instantiate instances of this class itself, but use the descendant classes that will be auto-generated in your _Intf unit for every array defined in your RODL file. These descendant classes will contain strongly-typed properties and methods to access the array elements as defined in your RODL.

Class Hierarchy

File

uROTypes

See Also

TROComplexType class

Data Types and RODL Files help topics

Pascal

TROArray = class(TROComplexType);


TROArray Class Methods

Methods

 Clone

Creates and returns a second copy of the Struct.

The new instance will be a deep copy of the original struct, all nested members that are arrays, structs or binaries will be duplicated as part of the cloning process, so that the new instance and its members will be completely independent from the original class.

TROArray Class

 Clear

Empties the entire array and sets its size to zero. If the elements of the array are structs, binaries or other arrays, they will be freed before the array is cleared.

 Clone

Will create and return a second copy of the Array.

The new instance will be a deep copy of the original array; if the members are structs binaries or arrays themselves, they too will be duplicated as part of the cloning process, so that the new instance and its members will be completely independent of the original class.

 Resize

Resizes the array to the specified size.


Legend

Method

abstract


TROArray Class Properties

Properties

TROArray Class

 Count

Returns the number of elements contained in the array.


Legend

Property

read only


Legend

Legend

Method

abstract

Property

read only


TROArray Class Members

Members

Methods

 Clone

Creates and returns a second copy of the Struct.

The new instance will be a deep copy of the original struct, all nested members that are arrays, structs or binaries will be duplicated as part of the cloning process, so that the new instance and its members will be completely independent from the original class.

TROArray Class

 Clear

Empties the entire array and sets its size to zero. If the elements of the array are structs, binaries or other arrays, they will be freed before the array is cleared.

 Clone

Will create and return a second copy of the Array.

The new instance will be a deep copy of the original array; if the members are structs binaries or arrays themselves, they too will be duplicated as part of the cloning process, so that the new instance and its members will be completely independent of the original class.

 Resize

Resizes the array to the specified size.

Properties

TROArray Class

 Count

Returns the number of elements contained in the array.


Legend

Method

abstract

Property

read only


See Also

TROComplexType class

Data Types and RODL Files help topics


TROArray.Count Property

Returns the number of elements contained in the array.

Pascal

property Count: integer;


TROArray.Clear Method

Empties the entire array and sets its size to zero. If the elements of the array are structs, binaries or other arrays, they will be freed before the array is cleared.

Pascal

procedure Clear; virtual; abstract;


TROArray.Clone Method

Will create and return a second copy of the Array.

The new instance will be a deep copy of the original array; if the members are structs binaries or arrays themselves, they too will be duplicated as part of the cloning process, so that the new instance and its members will be completely independent of the original class.

See Also

TROComplexType.Clone method

Pascal

function Clone: TROArray;


See Also

TROComplexType.Clone method


TROArray.Resize Method

Resizes the array to the specified size.

Use Case

Since arrays are not a very dynamic data structure, repeatedly adding single elements can be a costly procedure, since memory needs to be reallocated for the grown array, with each addittion. If the final size of the array is known in advance, it will perform better if you size it to the proper count in advance, and then simply fill the new vacancies.

Pascal

procedure Resize(ElementCount: integer); virtual; abstract;


TROAsyncProxy Class

This class forms the base for proxy classes in the _Async units generated from your RODL.

Use Case

You will usually not deal directly with classes of this type, but cast client-side service interfaces to the IROAsyncInterface interface to access some of the properties it provides.

Class Hierarchy

File

uROAsync

See Also

IROAsyncInterface interface

Asynchronous Calls and RODL Files help topics

Pascal

TROAsyncProxy = class(TInterfacedObject, IUnknown, IROAsyncInterface);


TROAsyncProxy Class Properties

Properties

 AnswerReceived

Specifies whether an answer has been received for the previous asynchronous request (true) or not (false).

You can use this property to poll the current status of the request. For example to enable a user interface option to retrieve the result.

 AnswerReceivedEvent

For channels that support active asynchronous results, this property returns a Win32 event object (wrapped inside a TEvent) that can be used to wait for an answer to the previous asynchronous request.

 Busy

Specifies whether the proxy is currently busy processing an asynchronous call (true) or not (false).

Asynchronous proxies are only capable of dispatching one asynchronous call at a time, and attempts to make a second call while the proxy is busy will result in an EROChannelBusy exception.

 MessageID

Contains the MessageID of the request currently being executed.

Since true asynchronous channels (such as the Super TCP Channel) can execute multiple requests at the same time, they assign an internal message to each request sent, to later match up the received response with the right request.

TROAsyncProxy Class

 __InterfaceName

Contains the name of the interface (service) that this proxy is configured to talk to.

 __Message

Contains a reference to the Message component that this proxy is configured to use.

 __TransportChannel

Contains a reference to the Channel component that this proxy is configured to use to communicate with the server.


Legend

Property

read only

protected


Legend

Legend

Property

read only

protected


TROAsyncProxy Class Members

Members

Properties

 AnswerReceived

Specifies whether an answer has been received for the previous asynchronous request (true) or not (false).

You can use this property to poll the current status of the request. For example to enable a user interface option to retrieve the result.

 AnswerReceivedEvent

For channels that support active asynchronous results, this property returns a Win32 event object (wrapped inside a TEvent) that can be used to wait for an answer to the previous asynchronous request.

 Busy

Specifies whether the proxy is currently busy processing an asynchronous call (true) or not (false).

Asynchronous proxies are only capable of dispatching one asynchronous call at a time, and attempts to make a second call while the proxy is busy will result in an EROChannelBusy exception.

 MessageID

Contains the MessageID of the request currently being executed.

Since true asynchronous channels (such as the Super TCP Channel) can execute multiple requests at the same time, they assign an internal message to each request sent, to later match up the received response with the right request.

TROAsyncProxy Class

 __InterfaceName

Contains the name of the interface (service) that this proxy is configured to talk to.

 __Message

Contains a reference to the Message component that this proxy is configured to use.

 __TransportChannel

Contains a reference to the Channel component that this proxy is configured to use to communicate with the server.


Legend

Property

read only

protected


See Also

IROAsyncInterface interface

Asynchronous Calls and RODL Files help topics


TROAsyncProxy.__InterfaceName Property

Contains the name of the interface (service) that this proxy is configured to talk to.

Notes

This property is used by auto-generated code in your _Async units; you will not usually access this property directly.

Pascal

property __InterfaceName: string;


TROAsyncProxy.__Message Property

Contains a reference to the Message component that this proxy is configured to use.

Notes

This property is used by auto-generated code in your _Async units; you will not usually access this property directly.

Pascal

property __Message: IROMessage;


TROAsyncProxy.__TransportChannel Property

Contains a reference to the Channel component that this proxy is configured to use to communicate with the server.

Notes

This property is used by auto-generated code in your _Async units; you will not usually access this property directly.

Pascal

property __TransportChannel: IROTransportChannel;


TROBaseConnection Class

TROBaseConnection forms the base class for RemObjects SDK Clients (Channels) and Servers.

Use Case

You will usually not use this class directly, or even descend from it directly. Instead, you will use the concrete Channel and Server classes, or descend from TROTransportChannel or TROServer to implement your own servers or channels.

Relevant Properties

Encryption allows to control encryption and compression settings on a per server/channel basis. Note that the use of tis property has been deprecated, and is only supported for Delphi/Win32; it is not available in Kylix and Free Pascal, not is it compatible with the RemObjects SDK for .NET. Future versions of the SDK will introduce more flexible and cross-platform encryption capabilities, at the Message level.

Class Hierarchy

File

uROClient

See Also

TROTransportChannel and TROServer classes

Channels help topic

Pascal

TROBaseConnection = class(TROComponent);


TROBaseConnection Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.


Legend

Property


Legend

Legend

Property


TROBaseConnection Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.


Legend

Property


See Also

TROTransportChannel and TROServer classes

Channels help topic


TROBaseConnection.Encryption Property

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

Essential Sub-Properties

EncryptionMethod specifies the encryption method to be used (default is tetNone, no encryption).

EncryptionSendKey specifies the key to be used for encrypting outgoing messages.

EncryptionRecvKey specifies the key to be used for decrypting incoming messages.

Notes

Note that the use of this property has been deprecated, and is only supported for Delphi/Win32; it is not available in Kylix and Free Pascal, nor is it compatible with the RemObjects SDK for .NET. Future versions of the SDK will introduce more flexible and cross-platform encryption capabilities, at the Message level.

See Also

TROEncryption class

Pascal

property Encryption: TROEncryption;


See Also

TROEncryption class


TRODiscoveryOptions Class

TRODiscoveryOptions is an (empty) struct that forms a base for passing custom data between clients and server when using Service Discovery.

To pass actual information, you would add a new struct to your RODL file, descending from RODiscoveryOptions, and pass instances of that class to the TRODiscoveryClient.RefreshServerList method or back from the TRODiscoveryServer.OnServiceFound event.

Class Hierarchy

File

uRODiscovery_Intf

See Also

TRODiscoveryClient.RefreshServerList method

Service Discovery help topic

"Service Discovery" sample application

Pascal

TRODiscoveryOptions = class(TROComplexType);


TRODiscoveryOptions Class Methods

Methods

 Clone

Creates and returns a second copy of the Struct.

The new instance will be a deep copy of the original struct, all nested members that are arrays, structs or binaries will be duplicated as part of the cloning process, so that the new instance and its members will be completely independent from the original class.


Legend

Method


Legend

Legend

Method


TRODiscoveryOptions Class Members

Members

Methods

 Clone

Creates and returns a second copy of the Struct.

The new instance will be a deep copy of the original struct, all nested members that are arrays, structs or binaries will be duplicated as part of the cloning process, so that the new instance and its members will be completely independent from the original class.


Legend

Method


See Also

TRODiscoveryClient.RefreshServerList method

Service Discovery help topic

"Service Discovery" sample application


TROBinaryMemoryStream Class

The TROBinaryMemoryStream (or short Binary) class builds upon the standard memory stream provided by the Delphi VCL to extend it with additional methods that make it easier to use.

The class forms the basis for passing unstructured binary data between clients and servers, and will be used whenever you declare "Binary" types in your RODL files.

Class Hierarchy

File

uROClasses

See Also

Binary type

Data Types help topic

Pascal

TROBinaryMemoryStream = class(TMemoryStream);


TROBinaryMemoryStream Class Methods

Methods

 Clone

Creates and returns a new memory stream that is an identical copy of the current stream.

The new stream will receive its own copy of the data, and any changes to data or stream position will not affect the original version.

 LoadFromHexString

Loads the binary from a string containing data in hexadecimal representation.

The new data will replace the entire stream, and the stream will be positioned at the beginning.

 LoadFromString

Loads the binary from a string.

The new data will replace the entire stream, and the stream will be positioned at the beginning.

 ToHexString

Emits the data in the stream as a string containing hexadecimal characters. For each byte in the original stream, two characters between '0' and 'F' will be emitted to the string.

 ToReadableString

Emits the data in the stream as ANSI string for display purposes.

For each byte in the original stream, the corresponding ASCII character will be emitted to the string if the value is $0D or between $20 and $7F, and a "period" character will be emitted otherwise. This results in a string that can cleanly be displayed and does not contain ASCII control characters.

 ToString

Emits the data in the stream as ANSI string. For each byte in the original stream, the corresponding ANSI character will be emitted to the string.


Legend

Method

virtual


Legend

Legend

Method

virtual


TROBinaryMemoryStream Class Members

Members

Methods

 Clone

Creates and returns a new memory stream that is an identical copy of the current stream.

The new stream will receive its own copy of the data, and any changes to data or stream position will not affect the original version.

 LoadFromHexString

Loads the binary from a string containing data in hexadecimal representation.

The new data will replace the entire stream, and the stream will be positioned at the beginning.

 LoadFromString

Loads the binary from a string.

The new data will replace the entire stream, and the stream will be positioned at the beginning.

 ToHexString

Emits the data in the stream as a string containing hexadecimal characters. For each byte in the original stream, two characters between '0' and 'F' will be emitted to the string.

 ToReadableString

Emits the data in the stream as ANSI string for display purposes.

For each byte in the original stream, the corresponding ASCII character will be emitted to the string if the value is $0D or between $20 and $7F, and a "period" character will be emitted otherwise. This results in a string that can cleanly be displayed and does not contain ASCII control characters.

 ToString

Emits the data in the stream as ANSI string. For each byte in the original stream, the corresponding ANSI character will be emitted to the string.


Legend

Method

virtual


See Also

Binary type

Data Types help topic


TROBinaryMemoryStream.Clone Method

Creates and returns a new memory stream that is an identical copy of the current stream.

The new stream will receive its own copy of the data, and any changes to data or stream position will not affect the original version.

Pascal

function Clone: TROBinaryMemoryStream;


TROBinaryMemoryStream.LoadFromHexString Method

Loads the binary from a string containing data in hexadecimal representation.

The new data will replace the entire stream, and the stream will be positioned at the beginning.

See Also

ToHexString and LoadFromString methods

Pascal

procedure LoadFromHexString(const iString: string);


See Also

ToHexString and LoadFromString methods


TROBinaryMemoryStream.LoadFromString Method

Loads the binary from a string.

The new data will replace the entire stream, and the stream will be positioned at the beginning.

See Also

ToString and LoadFromHexString methods

Pascal

procedure LoadFromString(const iString: string);


See Also

ToString and LoadFromHexString methods


TROBinaryMemoryStream.ToHexString Method

Emits the data in the stream as a string containing hexadecimal characters. For each byte in the original stream, two characters between '0' and 'F' will be emitted to the string.

See Also

LoadFromHexString, ToString and ToReadableString methods

Pascal

function ToHexString: string;


See Also

LoadFromHexString, ToString and ToReadableString methods


TROBinaryMemoryStream.ToReadableString Method

Emits the data in the stream as ANSI string for display purposes.

For each byte in the original stream, the corresponding ASCII character will be emitted to the string if the value is $0D or between $20 and $7F, and a "period" character will be emitted otherwise. This results in a string that can cleanly be displayed and does not contain ASCII control characters.

See Also

LoadFromString, ToHexString and ToReadableString methods

Pascal

function ToReadableString: string;


See Also

LoadFromString, ToHexString and ToReadableString methods


TROBinaryMemoryStream.ToString Method

Emits the data in the stream as ANSI string. For each byte in the original stream, the corresponding ANSI character will be emitted to the string.

See Also

LoadFromString, ToHexString and ToReadableString methods

Pascal

function ToString: string; override;


See Also

LoadFromString, ToHexString and ToReadableString methods


TROBinMessage Class

TROBinMessage implements message encoding for the efficient and proprietary BinMessage message format.

BinMessage provides the best performance of all the provided message formats, resulting in very small data packets that can be read and written with little processing overhead. It also supports compression to decrease the wire size of larger messages.

Please refer to the BinMessage help topic for more details on the this message format.

Essential Properties

None; The BinMessage component is usable after being dropped from the component palette.

Relevant Properties

UseCompression toggles whether outgoing messages are automatically compressed using ZLib, if they exceed a specific size.

MinSizeForCompression specifies the minimum size for a message before compression will be applied (default is 4096 bytes).

Class Hierarchy

File

uROBinMessage

See Also

Messages and BinMessage help topics

Pascal

TROBinMessage = class(TROMessage, IROBinMessage, IROStreamAccess);


TROBinMessage Class Properties

Properties

 ClientID

Contains the Client ID for the message.

 InterfaceName

Contains the name of the interface (service) that this message is calling.

 MessageName

Contains the name of the method that this message is calling.

TROBinMessage Class

 CompressionBufferSize

Specifies the size of the buffer used for compression (default is 256 kilobytes).

Increasing the buffer increases compression performance for large messages, but it also increases memory footprint. Best performance is reached with a buffer that's large enough for the maximum expected message size.

 MinSizeForCompression

Specifies the minimum size for a message before compression is applied (default is 4096 bytes).

Messages below this threshold are sent uncompressed, as the overhead of compressing and decompressing the data would likely outweigh the gain of having only slightly smaller packet on the network.

 UseCompression

Toggles whether outgoing messages will be automatically compressed using ZLib, if they exceed a specific size.


Legend

Property


TROBinMessage Class Events

Events

 OnFinalizeMessage

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

 OnInitializeMessage

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

 OnReadFromStream

Fires before the message is read from the stream that was received over the network.

 OnReadMessageParameter

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnServerException

Fires if an exception message is received from the server.

 OnWriteException

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

 OnWriteMessageParameter

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnWriteToStream

Fires after the message was written to the stream that will be sent over the network.

TROBinMessage Class

 OnCompress

Is fired after the message is compressed.

 OnDecompress

Will be fired after a received compressed message has been decompressed.


Legend

Event


Legend

Legend

Property

Event


TROBinMessage Class Members

Members

Properties

 ClientID

Contains the Client ID for the message.

 InterfaceName

Contains the name of the interface (service) that this message is calling.

 MessageName

Contains the name of the method that this message is calling.

TROBinMessage Class

 CompressionBufferSize

Specifies the size of the buffer used for compression (default is 256 kilobytes).

Increasing the buffer increases compression performance for large messages, but it also increases memory footprint. Best performance is reached with a buffer that's large enough for the maximum expected message size.

 MinSizeForCompression

Specifies the minimum size for a message before compression is applied (default is 4096 bytes).

Messages below this threshold are sent uncompressed, as the overhead of compressing and decompressing the data would likely outweigh the gain of having only slightly smaller packet on the network.

 UseCompression

Toggles whether outgoing messages will be automatically compressed using ZLib, if they exceed a specific size.

Events

 OnFinalizeMessage

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

 OnInitializeMessage

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

 OnReadFromStream

Fires before the message is read from the stream that was received over the network.

 OnReadMessageParameter

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnServerException

Fires if an exception message is received from the server.

 OnWriteException

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

 OnWriteMessageParameter

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnWriteToStream

Fires after the message was written to the stream that will be sent over the network.

TROBinMessage Class

 OnCompress

Is fired after the message is compressed.

 OnDecompress

Will be fired after a received compressed message has been decompressed.


Legend

Property

Event


See Also

Messages and BinMessage help topics


TROBinMessage.CompressionBufferSize Property

Specifies the size of the buffer used for compression (default is 256 kilobytes).

Increasing the buffer increases compression performance for large messages, but it also increases memory footprint. Best performance is reached with a buffer that's large enough for the maximum expected message size.

See Also

UseCompression and MinSizeForCompression properties

Pascal

property CompressionBufferSize: integer;


See Also

UseCompression and MinSizeForCompression properties


TROBinMessage.MinSizeForCompression Property

Specifies the minimum size for a message before compression is applied (default is 4096 bytes).

Messages below this threshold are sent uncompressed, as the overhead of compressing and decompressing the data would likely outweigh the gain of having only slightly smaller packet on the network.

See Also

UseCompression and CompressionBufferSize properties

Pascal

property MinSizeForCompression: integer;


See Also

UseCompression and CompressionBufferSize properties


TROBinMessage.OnCompress Event

Is fired after the message is compressed.

Use Case

You can use this event to keep track of compression, and possibly to run statistics on compression ratios and dynamically adjust the UseCompression and MinSizeForCompression properties.

See Also

OnDecompress event

UseCompression and MinSizeForCompression properties

Pascal

property OnCompress: TROCompressionEvent;


See Also

OnDecompress event

UseCompression and MinSizeForCompression properties


TROBinMessage.OnDecompress Event

Will be fired after a received compressed message has been decompressed.

Use Case

You can use this event to keep track of decompression, and possibly to run statistics on compression ratios and dynamically adjust the UseCompression and MinSizeForCompression properties.

See Also

OnCompress event

UseCompression and MinSizeForCompression properties

Pascal

property OnDecompress: TROCompressionEvent;


See Also

OnCompress event

UseCompression and MinSizeForCompression properties


TROBinMessage.UseCompression Property

Toggles whether outgoing messages will be automatically compressed using ZLib, if they exceed a specific size.

See Also

MinSizeForCompression and CompressionBufferSize properties

Pascal

property UseCompression: boolean;


See Also

MinSizeForCompression and CompressionBufferSize properties


TROBPDXHTTPServer Class

TROBPDXHTTPServer implements a HTTP based server that uses the HTTP implementation provided by the third party DXSock 3.0 library that is shipped free with the RemObjects SDK.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

Relevant Properties

Port specifies the network socket that the server will be listening on (default is 8099).

Class Hierarchy

File

uROBPDXHTTPServer

See Also

Channels and HTTP Channels help topics

TROIndyHTTPServer and TROWebBrokerServer components

Pascal

TROBPDXHTTPServer = class(TROBPDXTCPServer);


TROBPDXHTTPServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROBPDXTCPServer Class

 BPDXServer

Provides direct access to the underlying BPDX implementation. You can use this property to control advanced settings on the BPDX object.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

TROBPDXHTTPServer Class

 BPDXServer

Provides direct access to the underlying BPDX implementation. You can use this property to control advanced settings on the BPDX object.

 SendExceptionsAs500

Specifies whether exception messages will be sent back using a HTTP "500" error code (true, default), or a standard "200" message code (false).

 ServeInfoPage

Specifies whether the HTTP server will serve up a page with human-readable information about the server when being accessed from a web browser. This information page will contain details about the registered dispatchers and the documentation for the services.

 ServeRodl

Specifies whether the HTTP server will make the contained RODL file available to clients (true, default) or not.

Keep this property set to true if clients need to access the RODL (ore WSDL), for example so that third parties (including Service Tester) can import services. Set it to false if you do not want to provide this information, for example for security reasons.

 SupportKeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.


Legend

Property

read only


TROBPDXHTTPServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

read only

Event


TROBPDXHTTPServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROBPDXTCPServer Class

 BPDXServer

Provides direct access to the underlying BPDX implementation. You can use this property to control advanced settings on the BPDX object.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

TROBPDXHTTPServer Class

 BPDXServer

Provides direct access to the underlying BPDX implementation. You can use this property to control advanced settings on the BPDX object.

 SendExceptionsAs500

Specifies whether exception messages will be sent back using a HTTP "500" error code (true, default), or a standard "200" message code (false).

 ServeInfoPage

Specifies whether the HTTP server will serve up a page with human-readable information about the server when being accessed from a web browser. This information page will contain details about the registered dispatchers and the documentation for the services.

 ServeRodl

Specifies whether the HTTP server will make the contained RODL file available to clients (true, default) or not.

Keep this property set to true if clients need to access the RODL (ore WSDL), for example so that third parties (including Service Tester) can import services. Set it to false if you do not want to provide this information, for example for security reasons.

 SupportKeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

read only

Event


See Also

Channels and HTTP Channels help topics

TROIndyHTTPServer and TROWebBrokerServer components


TROBPDXHTTPServer.BPDXServer Property

Provides direct access to the underlying BPDX implementation. You can use this property to control advanced settings on the BPDX object.

See Also

BPDX documentation

Pascal

property BPDXServer: TDXHTTPServerCore;


See Also

BPDX documentation


TROBPDXHTTPServer.SendExceptionsAs500 Property

Specifies whether exception messages will be sent back using a HTTP "500" error code (true, default), or a standard "200" message code (false).

Use Case

Some proxy servers might perform special handling on 500 error messages that will prevent exception messages sent back as 500 to be recognized properly. If you are seeing this problem, try setting this property to false. If not, it is recommended to keep the default value.

Pascal

property SendExceptionsAs500: boolean;


TROBPDXHTTPServer.ServeInfoPage Property

Specifies whether the HTTP server will serve up a page with human-readable information about the server when being accessed from a web browser. This information page will contain details about the registered dispatchers and the documentation for the services.

Pascal

property ServeInfoPage: Boolean;


TROBPDXHTTPServer.ServeRodl Property

Specifies whether the HTTP server will make the contained RODL file available to clients (true, default) or not.

Keep this property set to true if clients need to access the RODL (ore WSDL), for example so that third parties (including Service Tester) can import services. Set it to false if you do not want to provide this information, for example for security reasons.

See Also

RODL Files and Service Tester help topics

Pascal

property ServeRodl: Boolean;


See Also

RODL Files and Service Tester help topics


TROBPDXHTTPServer.SupportKeepAlive Property

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

Notes

For Keep-Alive to work, the option must be supported and enabled on both client and server.

See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties

Pascal

property SupportKeepAlive: Boolean;


See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties


TROBPDXTCPServer Class

TROBPDXHTTPServer implements a TCP based server that uses the socket implementation provided by the third party DXSock 3.0 library that is shipped free with the RemObjects SDK.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

Relevant Properties

Port specifies the network socket that the server will be listening on (default is 8090).

Class Hierarchy

File

uROBPDXTCPServer

See Also

Channels and Legacy TCP Channels help topics

TROIndyTCPServer component

Pascal

TROBPDXTCPServer = class(TROServer);


TROBPDXTCPServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROBPDXTCPServer Class

 BPDXServer

Provides direct access to the underlying BPDX implementation. You can use this property to control advanced settings on the BPDX object.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).


Legend

Property

read only


TROBPDXTCPServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

read only

Event


TROBPDXTCPServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROBPDXTCPServer Class

 BPDXServer

Provides direct access to the underlying BPDX implementation. You can use this property to control advanced settings on the BPDX object.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

read only

Event


See Also

Channels and Legacy TCP Channels help topics

TROIndyTCPServer component


TROBPDXTCPServer.BPDXServer Property

Provides direct access to the underlying BPDX implementation. You can use this property to control advanced settings on the BPDX object.

See Also

BPDX documentation

Pascal

property BPDXServer: TDXServerCore;


See Also

BPDX documentation


TROBPDXTCPServer.Port Property

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

Pascal

property Port: integer;


TROBroadcastChannel Class

TROBroadcastChannel implements a UDP based channel that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Building upon the TROIndyUDPChannel, the broadcast channel will not send its requests to one specific server, but will broadcast them to all servers listening on the local subnet.

The OnBroadcastResponseReceived event will be fired for each response that is received.

Essential Properties

Port specifies the port number the servers are listening on.

Class Hierarchy

Notes

Due to a bug in Indy, the Indy HTTP, TCP and UDP Channels cannot be used inside the IDE at design time.

If you need to use your channels a design time, for example in combination with Data Abstract to receive schema information or live data preview, we recommend using one of the other channels such as the TROWinInetHTTPChannel.

File

uROBroadcastChannel

See Also

TROIndyUDPChannel component

Channels and UDP and Broadcast Channels help topics

Pascal

TROBroadcastChannel = class(TROIndyUDPChannel);


TROBroadcastChannel Class Properties

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROIndyUDPChannel Class

 AsyncTimeOut

Specifies the timeout for waiting for an asynchronous response from the server, in milliseconds. The default value is 1000 (1 second).

If no response is received from the server after the given timeout, the OnAsyncResponseTimeout event will fire. Due to the nature of asynchronous calls, no exception will be raised.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.


Legend

Property

read only


TROBroadcastChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROIndyUDPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnAsyncResponseTimeOut

Fires if no response for an asynchronous call is received within the timeframe specified by the AsyncTimeOut property.

Due to the nature of asynchronous calls, no exception will be raised.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROBroadcastChannel Class

 OnBroadcastResponseReceived

Fires for each response that is received. The passed ResponseUID can be used to obtain the actual response data, using the GetResponseByUID method.


Legend

Event


TROBroadcastChannel Class Methods

Methods

TROIndyUDPChannel Class

 GetResponseByUID

Returns the response for the specified ID.

This method can be used by the Broadcast Channel to access the different responses that might be received from all the servers reacting on a broadcast request.


Legend

Method


Legend

Legend

Property

read only

Event

Method


TROBroadcastChannel Class Members

Members

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROIndyUDPChannel Class

 AsyncTimeOut

Specifies the timeout for waiting for an asynchronous response from the server, in milliseconds. The default value is 1000 (1 second).

If no response is received from the server after the given timeout, the OnAsyncResponseTimeout event will fire. Due to the nature of asynchronous calls, no exception will be raised.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROIndyUDPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnAsyncResponseTimeOut

Fires if no response for an asynchronous call is received within the timeframe specified by the AsyncTimeOut property.

Due to the nature of asynchronous calls, no exception will be raised.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROBroadcastChannel Class

 OnBroadcastResponseReceived

Fires for each response that is received. The passed ResponseUID can be used to obtain the actual response data, using the GetResponseByUID method.

Methods

TROIndyUDPChannel Class

 GetResponseByUID

Returns the response for the specified ID.

This method can be used by the Broadcast Channel to access the different responses that might be received from all the servers reacting on a broadcast request.


Legend

Property

read only

Event

Method


See Also

TROIndyUDPChannel component

Channels and UDP and Broadcast Channels help topics


TROBroadcastChannel.OnBroadcastResponseReceived Event

Fires for each response that is received. The passed ResponseUID can be used to obtain the actual response data, using the GetResponseByUID method.

See Also

GetResponseByUID method

Pascal

property OnBroadcastResponseReceived: TROResponseReceivedEvent;


See Also

GetResponseByUID method


TROBroadcastServer Class

TROBroadcastServer implements a UDP based server that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Building upon the TROIndyUDPServer, the broadcast server is intended to work with broadcast messages that are sent to a (possibly large) number of hosts on the local network.

Essential Properties 	Active toggles whether the server ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests are processed and dispatched.

Relevant Properties

Port specifies the network socket that the server will be listening on (default is 8090).

Class Hierarchy

File

uROBroadcastServer

See Also

TROIndyUDPServer component

Channels and UDP and Broadcast Channels help topics

Pascal

TROBroadcastServer = class(TROIndyUDPServer);


TROBroadcastServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROIndyUDPServer Class

 IndyUDPServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK UDP servers is 8090).

TROBroadcastServer Class

 OnRORequest


Legend

Property

read only


TROBroadcastServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

read only

Event


TROBroadcastServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROIndyUDPServer Class

 IndyUDPServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK UDP servers is 8090).

TROBroadcastServer Class

 OnRORequest

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

read only

Event


See Also

TROIndyUDPServer component

Channels and UDP and Broadcast Channels help topics


TROBroadcastServer.OnRORequest Property

property OnRORequest: TNotifyEvent;


TROClassFactory Class

TROClassFactory forms the base class of all class factories provided with the RemObjects SDK.

Use Case

Class factories are used to register and instantiate service classes to be available for remote requests.

This is usually done by creating a new instance of a class factory in the implementation section of the service's unit by code that is auto-generated from your RODL file.

Please refer to the Class Factories help topic for a more detailed discussion of available class factory types.

Class Hierarchy

File

uROServer

See Also

TROPooledClassFactory, TROSingletonClassFactory, TROSynchronizedSingletonClassFactory and TROPerClientClassFactory classes

Class Factories and RODL Files help topics

Pascal

TROClassFactory = class(TInterfacedObject, IROClassFactory);


TROClassFactory Class Methods

Methods

 Create

Creates a new instance of the class factory

 CreateInstance

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

 ReleaseInstance

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.


Legend

Constructor

protected

virtual


Legend

Legend

Constructor

protected

virtual


TROClassFactory Class Members

Members

Methods

 Create

Creates a new instance of the class factory

 CreateInstance

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

 ReleaseInstance

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.


Legend

Constructor

protected

virtual


See Also

TROPooledClassFactory, TROSingletonClassFactory, TROSynchronizedSingletonClassFactory and TROPerClientClassFactory classes

Class Factories and RODL Files help topics


TROClassFactory.Create Constructor

Creates a new instance of the class factory
aInterfaceName	Specifies the interface name (service name) of the service to be registered. This must be the same name that clients will use to access the service.
aCreatorFunc	Specifies the function that will be used to create new instances of the service class, when needed. When and how often instances are created will depend on the type of the used class factory. Usually, the creator function will be auto-generated as part of the _Impl unit for your service.
aInvokerClass	The Invoker class to be used to invoke methods on your service. Usually, this will be the auto-generated invoker class from the _Invk unit.
See Also

Class Factories and RODL Files help topics

Pascal

constructor Create(const anInterfaceName: string; aCreatorFunc: TRORemotableCreatorFunc; anInvokerClass: TROInvokerClass);


See Also

Class Factories and RODL Files help topics


TROClassFactory.CreateInstance Method

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

See Also

ReleaseInstance method

Class Factories help topic

Pascal

procedure CreateInstance(const aClientID: TGUID; out anInstance: IInterface); virtual;


See Also

ReleaseInstance method

Class Factories help topic


TROClassFactory.ReleaseInstance Method

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.

See Also

CreateInstance method

Class Factories help topic

Pascal

procedure ReleaseInstance(const aClientID: TGUID; var anInstance: IInterface); virtual;


See Also

CreateInstance method

Class Factories help topic


TROComplexType Class

TROComplexType forms the base class for all "struct" types defined in your library.

Use Case

You will usually not instantiate instances of this class itself, but use the descendant classes that will be auto-generated in your _Intf unit for every Struct defined in your RODL file. These descendant classes will contain properties for all fields you defined in your RODL.

Class Hierarchy

File

uROTypes

See Also

TROArray class

Data Types and RODL Files help topics

Pascal

TROComplexType = class(TCollectionItem);


TROComplexType Class Methods

Methods

 Clone

Creates and returns a second copy of the Struct.

The new instance will be a deep copy of the original struct, all nested members that are arrays, structs or binaries will be duplicated as part of the cloning process, so that the new instance and its members will be completely independent from the original class.


Legend

Method


Legend

Legend

Method


TROComplexType Class Members

Members

Methods

 Clone

Creates and returns a second copy of the Struct.

The new instance will be a deep copy of the original struct, all nested members that are arrays, structs or binaries will be duplicated as part of the cloning process, so that the new instance and its members will be completely independent from the original class.


Legend

Method


See Also

TROArray class

Data Types and RODL Files help topics


TROComplexType.Clone Method

Creates and returns a second copy of the Struct.

The new instance will be a deep copy of the original struct, all nested members that are arrays, structs or binaries will be duplicated as part of the cloning process, so that the new instance and its members will be completely independent from the original class.

See Also

TROArray.Clone method

Pascal

function Clone: TROComplexType;


See Also

TROArray.Clone method


TROConstantMemoryStream Class

TROConstantMemoryStream is a custom memory stream implementation, optimized for read-only access.

Use Case

This class was originally implemented for internal use within the RemObjects SDK library, but provided publicly for your convenience. You can use TROConstantMemoryStream wherever a un-modifiable memory stream optimized for fast read-only access is needed.

Class Hierarchy

File

uROClasses

See Also

TROBinaryMemoryStream class

Pascal

TROConstantMemoryStream = class(TROBinaryMemoryStream);


TROConstantMemoryStream Class Methods

Methods

 Clone

Creates and returns a new memory stream that is an identical copy of the current stream.

The new stream will receive its own copy of the data, and any changes to data or stream position will not affect the original version.

 LoadFromHexString

Loads the binary from a string containing data in hexadecimal representation.

The new data will replace the entire stream, and the stream will be positioned at the beginning.

 LoadFromString

Loads the binary from a string.

The new data will replace the entire stream, and the stream will be positioned at the beginning.

 ToHexString

Emits the data in the stream as a string containing hexadecimal characters. For each byte in the original stream, two characters between '0' and 'F' will be emitted to the string.

 ToReadableString

Emits the data in the stream as ANSI string for display purposes.

For each byte in the original stream, the corresponding ASCII character will be emitted to the string if the value is $0D or between $20 and $7F, and a "period" character will be emitted otherwise. This results in a string that can cleanly be displayed and does not contain ASCII control characters.

 ToString

Emits the data in the stream as ANSI string. For each byte in the original stream, the corresponding ANSI character will be emitted to the string.


Legend

Method

virtual


Legend

Legend

Method

virtual


TROConstantMemoryStream Class Members

Members

Methods

 Clone

Creates and returns a new memory stream that is an identical copy of the current stream.

The new stream will receive its own copy of the data, and any changes to data or stream position will not affect the original version.

 LoadFromHexString

Loads the binary from a string containing data in hexadecimal representation.

The new data will replace the entire stream, and the stream will be positioned at the beginning.

 LoadFromString

Loads the binary from a string.

The new data will replace the entire stream, and the stream will be positioned at the beginning.

 ToHexString

Emits the data in the stream as a string containing hexadecimal characters. For each byte in the original stream, two characters between '0' and 'F' will be emitted to the string.

 ToReadableString

Emits the data in the stream as ANSI string for display purposes.

For each byte in the original stream, the corresponding ASCII character will be emitted to the string if the value is $0D or between $20 and $7F, and a "period" character will be emitted otherwise. This results in a string that can cleanly be displayed and does not contain ASCII control characters.

 ToString

Emits the data in the stream as ANSI string. For each byte in the original stream, the corresponding ANSI character will be emitted to the string.


Legend

Method

virtual


See Also

TROBinaryMemoryStream class


TROCustomDiscoveryClient Class

This class implements the client side of the local network server discovery infrastructure in the RemObjects SDK.

Essential Properties

Channel specifies the TROBroadcastChannel to use to locate servers.

Message specifies the message format to use to talk to the servers.

ServiceName specifies the service name to look for.

Relevant Properties and Methods

ServerList contains the list of servers that offer the requested service.

RefreshServerList performs a network broadcast to find new servers.

Class Hierarchy

File

uRODiscovery

See Also

TRODiscoveryServer component

Service Discovery help topic

"Service Discovery" sample application

Pascal

TROCustomDiscoveryClient = class(TROComponent, IROBroadcastNotification);


TROCustomDiscoveryClient Class Properties

Properties

 Channel

Specifies the TROBroadcastChannel to use to locate servers.

 Message

Specifies the message format to use to talk to the servers.

 OnNewServersFound

Fires whenever the ServerList has been updated; whether new servers have been found or old servers have been removed.

 ServerList

Contains the list of servers that have been found to provide the requested service.

Call the RefreshServerList to (re)query the network and find new servers.

 ServiceName

Specifies the service name to look for on the local network.


Legend

Property

read only


TROCustomDiscoveryClient Class Events

Events

 OnDiscoveryException

Fires if any exception was raised while probing for servers.

If an event handler is assigned, exceptions will not be re-raised after the event handler has executed.

 OnNewServiceFound

Fires whenever a new server responded to the broadcast.

The event gets passed the server name, as well as any user-specific TRODiscoveryOptions that might have been returned from the server. The event gets fired before the newly found server is added to the ServerList .


Legend

Event


TROCustomDiscoveryClient Class Methods

Methods

 RefreshServerList

Performs a network broadcast to find new servers.

If needed, a user-defined TRODiscoveryOptions descendant class might be passed to the server to provide additional details or requirements for the desired service.

As responses from servers come in, the ServerList property is filled and the OnNewServiceFound and OnNewServersFoundevents are fired.


Legend

Method


Legend

Legend

Property

read only

Event

Method


TROCustomDiscoveryClient Class Members

Members

Properties

 Channel

Specifies the TROBroadcastChannel to use to locate servers.

 Message

Specifies the message format to use to talk to the servers.

 OnNewServersFound

Fires whenever the ServerList has been updated; whether new servers have been found or old servers have been removed.

 ServerList

Contains the list of servers that have been found to provide the requested service.

Call the RefreshServerList to (re)query the network and find new servers.

 ServiceName

Specifies the service name to look for on the local network.

Events

 OnDiscoveryException

Fires if any exception was raised while probing for servers.

If an event handler is assigned, exceptions will not be re-raised after the event handler has executed.

 OnNewServiceFound

Fires whenever a new server responded to the broadcast.

The event gets passed the server name, as well as any user-specific TRODiscoveryOptions that might have been returned from the server. The event gets fired before the newly found server is added to the ServerList .

Methods

 RefreshServerList

Performs a network broadcast to find new servers.

If needed, a user-defined TRODiscoveryOptions descendant class might be passed to the server to provide additional details or requirements for the desired service.

As responses from servers come in, the ServerList property is filled and the OnNewServiceFound and OnNewServersFoundevents are fired.


Legend

Property

read only

Event

Method


See Also

TRODiscoveryServer component

Service Discovery help topic

"Service Discovery" sample application


TROCustomDiscoveryClient.Channel Property

Specifies the TROBroadcastChannel to use to locate servers.

See Also

TROBroadcastChannel component

Pascal

property Channel: TROBroadcastChannel;


See Also

TROBroadcastChannel component


TROCustomDiscoveryClient.Message Property

Specifies the message format to use to talk to the servers.

See Also

TROBroadcastChannel class

Messages and UDP and Broadcast Channels help topics

Pascal

property Message: TROMessage;


See Also

TROBroadcastChannel class

Messages and UDP and Broadcast Channels help topics


TROCustomDiscoveryClient.OnDiscoveryException Event

Fires if any exception was raised while probing for servers.

If an event handler is assigned, exceptions will not be re-raised after the event handler has executed.

Pascal

property OnDiscoveryException: TRODiscoveryException;


TROCustomDiscoveryClient.OnNewServersFound Property

Fires whenever the ServerList has been updated; whether new servers have been found or old servers have been removed.

See Also

ServerList property

OnNewServiceFound event

TRODiscoveryOptions class

Pascal

property OnNewServersFound: TNotifyEvent;


See Also

ServerList property

OnNewServiceFound event

TRODiscoveryOptions class


TROCustomDiscoveryClient.OnNewServiceFound Event

Fires whenever a new server responded to the broadcast.

The event gets passed the server name, as well as any user-specific TRODiscoveryOptions that might have been returned from the server. The event gets fired before the newly found server is added to the ServerList .

See Also

ServerList property

OnNewServersFound event

TRODiscoveryOptions class

Pascal

property OnNewServiceFound: TRODiscoveryNewServiceFoundEvent;


See Also

ServerList property

OnNewServersFound event

TRODiscoveryOptions class


TROCustomDiscoveryClient.ServerList Property

Contains the list of servers that have been found to provide the requested service.

Call the RefreshServerList to (re)query the network and find new servers.

See Also

ServiceName property

RefreshServerList method

Pascal

property ServerList: TStrings;


See Also

ServiceName property

RefreshServerList method


TROCustomDiscoveryClient.ServiceName Property

Specifies the service name to look for on the local network.

Pascal

property ServiceName: string;


TROCustomDiscoveryClient.RefreshServerList Method

Performs a network broadcast to find new servers.

If needed, a user-defined TRODiscoveryOptions descendant class might be passed to the server to provide additional details or requirements for the desired service.

As responses from servers come in, the ServerList property is filled and the OnNewServiceFound and OnNewServersFoundevents are fired.

See Also

ServerList property

OnNewServiceFound and OnNewServersFound.

Pascal

procedure RefreshServerList(aDiscoveryOptions: TRODiscoveryOptions = nil);


See Also

ServerList property

OnNewServiceFound and OnNewServersFound.


TROCustomDiscoveryServer Class

This class implements the server side of the local network server discovery infrastructure in the RemObjects SDK.

Essential Properties

ServerList specifies the list of services that should be made available for discovery.

SupportRegisteredServerClasses specifies whether all standard RemObjects services registered in the server executable should automatically be made available for discovery.

Relevant Properties and Methods

ServerAddress can override the server address to send back to clients.

Class Hierarchy

File

uRODiscovery

See Also

TRODiscoveryClient component

Service Discovery help topic

"Service Discovery" sample application

Pascal

TROCustomDiscoveryServer = class(TROComponent);


TROCustomDiscoveryServer Class Events

Events

 OnServiceFound

This event is fired when a service probed for by a client was found on the local server.

The event gives the opportunity to stop the service from being returned as available, on a case by case basis. Also, any user-defined TRODiscoveryOptions descendant class passed from the client is available in the event for inspection, and (possibly different) TRODiscoveryOption can be returned to the server.


Legend

Event


TROCustomDiscoveryServer Class Properties

Properties

 ServerAddress

This property can be used to override the server address to send it back to clients. By default, if no value is specified, the actual IP address of the server will be used.

 ServiceList

Specifies the list of services that should be made available for discovery. This is a simple string list of names that the server will react to when being probed.

In addition to this list, the SupportRegisteredServerClasses property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable, as well.

 SupportRegisteredServerClasses

This property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable (true) or not (false).

If set t false, only the service names manually specified in the ServiceList property will be discoverable. It is of course possible to manually add a subset of the registered services to ServiceList, if desired.


Legend

Property


Legend

Legend

Event

Property


TROCustomDiscoveryServer Class Members

Members

Events

 OnServiceFound

This event is fired when a service probed for by a client was found on the local server.

The event gives the opportunity to stop the service from being returned as available, on a case by case basis. Also, any user-defined TRODiscoveryOptions descendant class passed from the client is available in the event for inspection, and (possibly different) TRODiscoveryOption can be returned to the server.

Properties

 ServerAddress

This property can be used to override the server address to send it back to clients. By default, if no value is specified, the actual IP address of the server will be used.

 ServiceList

Specifies the list of services that should be made available for discovery. This is a simple string list of names that the server will react to when being probed.

In addition to this list, the SupportRegisteredServerClasses property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable, as well.

 SupportRegisteredServerClasses

This property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable (true) or not (false).

If set t false, only the service names manually specified in the ServiceList property will be discoverable. It is of course possible to manually add a subset of the registered services to ServiceList, if desired.


Legend

Event

Property


See Also

TRODiscoveryClient component

Service Discovery help topic

"Service Discovery" sample application


TROCustomDiscoveryServer.OnServiceFound Event

This event is fired when a service probed for by a client was found on the local server.

The event gives the opportunity to stop the service from being returned as available, on a case by case basis. Also, any user-defined TRODiscoveryOptions descendant class passed from the client is available in the event for inspection, and (possibly different) TRODiscoveryOption can be returned to the server.

Use Case

Using this event, the discovery server can take more detailed control over what services it declares as available. For example, the TRODiscoveryOptions passed by the client might define certain conditions that are expected form the service, that the server evaluates.

For example, multiple servers might be located on the local network to handle calculation tasks. The client might pass a value describing the complexity of the needed work when probing for servers, and each server could evaluate its own current CPU load when handling the OnServiceFound event, to determine if it is currently able to accommodate the request, or not. The client would only receive responses from those servers that currently are available.

The "Service Discovery" sample application included with the RemObjects SDK illustrates this by introducing a fictitious "Server Load" value.

See Also

ServiceList and SupportRegisteredServerClasses properties

TRODiscoveryOptions class

"Service Discovery" sample application

Pascal

property OnServiceFound: TRODiscoveryServiceFoundEvent;


See Also

ServiceList and SupportRegisteredServerClasses properties

TRODiscoveryOptions class

"Service Discovery" sample application


TROCustomDiscoveryServer.ServerAddress Property

This property can be used to override the server address to send it back to clients. By default, if no value is specified, the actual IP address of the server will be used.

Use Case

You might want to override this address to send back a host name or the address of a proxy server, instead of the local hosts address.

Also, the discovery server could be acting on behalf of a different host on the network that implements the actual services, and should return that host's address.

See Also

ServiceList and SupportRegisteredServerClasses properties

Pascal

property ServerAddress: string;


See Also

ServiceList and SupportRegisteredServerClasses properties


TROCustomDiscoveryServer.ServiceList Property

Specifies the list of services that should be made available for discovery. This is a simple string list of names that the server will react to when being probed.

In addition to this list, the SupportRegisteredServerClasses property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable, as well.

See Also

SupportRegisteredServerClasses property

Pascal

property ServiceList: TStrings;


See Also

SupportRegisteredServerClasses property


TROCustomDiscoveryServer.SupportRegisteredServerClasses Property

This property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable (true) or not (false).

If set t false, only the service names manually specified in the ServiceList property will be discoverable. It is of course possible to manually add a subset of the registered services to ServiceList, if desired.

See Also

SupportRegisteredServerClasses property

Pascal

property SupportRegisteredServerClasses: boolean;


See Also

SupportRegisteredServerClasses property


TROCustomEmailChannel Class

TROEmailChannel implements a channel that uses standard email infrastructure to send messages between client and server. The channel is based on the open source Indy components that ship with Delphi.

Due to the nature of how email delivery works, this channel is best-suited for asynchronous communications and scenarios where a response to a request is not expected in real time or even during the lifetime of the application.

Essential Properties

Pop3ServerAddress, Pop3Username and Pop3Password specify the POP3 server that will be used to collect response emails.

SmtpServerAddress specifies the address of the SMTP server that will be used to send of request emails.

ClientEmail specifies the email address of the client.

ServerEmail specifies the email address of the server.

Class Hierarchy

File

uROIndyEmailChannel

See Also

Channels, Email Channels and Asynchronous Calls help topics

Pascal

TROCustomEmailChannel = class(TROTransportChannel, IROTransport, IROAsyncTransportChannel);


TROCustomEmailChannel Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomEmailChannel Class

 ClientEmail

Specifies the email address of the client. This address will be used in the "From:" field of sent emails, and the server will evaluate to obtain the return address for its responses.

This email address should match the POP3 account configured for the client, so that the client will be able to access the responses directed at it.

 DeleteOldResponses

Specifies if old/unmatched response emails are automatically deleted as part of the POP3 polling process (default is false).

Enable this option, if the POP3 account is used exclusively by this one client, and the account should be automatically cleaned of all unexpected or old response emails that might still be in the inbox.

Keep this option disabled if several client applications will be sharing the POP3 account, so that they will not delete each other's messages.

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect response emails.

This can be a host name or an IP address, and should point to the POP3 server that emails directed at the email specified in ClientEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ServerEmail

Specifies the email address of the server. This address will be used in the "To:" field of sent emails to deliver them to the server.

This email address should match the POP3 account configured for the server.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.


Legend

Property

read only


TROCustomEmailChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROCustomEmailChannel Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomEmailChannel Class

 ClientEmail

Specifies the email address of the client. This address will be used in the "From:" field of sent emails, and the server will evaluate to obtain the return address for its responses.

This email address should match the POP3 account configured for the client, so that the client will be able to access the responses directed at it.

 DeleteOldResponses

Specifies if old/unmatched response emails are automatically deleted as part of the POP3 polling process (default is false).

Enable this option, if the POP3 account is used exclusively by this one client, and the account should be automatically cleaned of all unexpected or old response emails that might still be in the inbox.

Keep this option disabled if several client applications will be sharing the POP3 account, so that they will not delete each other's messages.

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect response emails.

This can be a host name or an IP address, and should point to the POP3 server that emails directed at the email specified in ClientEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ServerEmail

Specifies the email address of the server. This address will be used in the "To:" field of sent emails to deliver them to the server.

This email address should match the POP3 account configured for the server.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels, Email Channels and Asynchronous Calls help topics


TROCustomEmailChannel.ClientEmail Property

Specifies the email address of the client. This address will be used in the "From:" field of sent emails, and the server will evaluate to obtain the return address for its responses.

This email address should match the POP3 account configured for the client, so that the client will be able to access the responses directed at it.

See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

ServerEmail property

Pascal

property ClientEmail: string;


See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

ServerEmail property


TROCustomEmailChannel.DeleteOldResponses Property

Specifies if old/unmatched response emails are automatically deleted as part of the POP3 polling process (default is false).

Enable this option, if the POP3 account is used exclusively by this one client, and the account should be automatically cleaned of all unexpected or old response emails that might still be in the inbox.

Keep this option disabled if several client applications will be sharing the POP3 account, so that they will not delete each other's messages.

Notes

The email channel will never delete any email messages that did not originate from a RemObjects SDK server. So it is completely safe to use the channel on a POP3 account that is also used for normal email correspondence.

Pascal

property DeleteOldResponses: boolean;


TROCustomEmailChannel.Pop3Client Property

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

See Also

Indy documentation

Pascal

property Pop3Client: TIdPOP3;


See Also

Indy documentation


TROCustomEmailChannel.Pop3Password Property

Specifies the password to be used to authenticate with the POP3 server.

See Also

Pop3Username, Pop3ServerAddress and ClientEmail properties

Pascal

property Pop3Password: string;


See Also

Pop3Username, Pop3ServerAddress and ClientEmail properties


TROCustomEmailChannel.Pop3ServerAddress Property

Specifies the address of the POP3 server that will be used to collect response emails.

This can be a host name or an IP address, and should point to the POP3 server that emails directed at the email specified in ClientEmail will be delivered to.

See Also

ClientEmail, Pop3Username and Pop3Password properties

Pop3Client property

Pascal

property Pop3ServerAddress: string;


See Also

ClientEmail, Pop3Username and Pop3Password properties

Pop3Client property


TROCustomEmailChannel.Pop3Username Property

Specifies the login name to be used to authenticate with the POP3 server.

See Also

Pop3Password, Pop3ServerAddress and ClientEmail properties

Pascal

property Pop3Username: string;


See Also

Pop3Password, Pop3ServerAddress and ClientEmail properties


TROCustomEmailChannel.ServerEmail Property

Specifies the email address of the server. This address will be used in the "To:" field of sent emails to deliver them to the server.

This email address should match the POP3 account configured for the server.

See Also

ClientEmail property

TROEmailServer.Pop3ServerAddress property

Pascal

property ServerEmail: string;


See Also

ClientEmail property

TROEmailServer.Pop3ServerAddress property


TROCustomEmailChannel.SmtpClient Property

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

See Also

Indy documentation

Pascal

property SmtpClient: TIdSMTP;


See Also

Indy documentation


TROCustomEmailChannel.SmtpServerAddress Property

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

See Also

SmtpClient property

Pascal

property SmtpServerAddress: string;


See Also

SmtpClient property


TROCustomEmailServer Class

TROEmailServer implements a server that uses standard email infrastructure to send messages between client and server. The channel is based on the open source Indy components that ship with Delphi.

Due to the nature of how email delivery works, this channel is best-suited for asynchronous communications and scenarios where a response to a request is not expected in real time or even during the lifetime of the application.

Essential Properties

Pop3ServerAddress, Pop3Username and Pop3Password specify the POP3 server that will be used to collect response emails.

SmtpServerAddress specifies the address of the SMTP server that will be used to send of request emails.

ServerEmail specifies the email address of the server.

Class Hierarchy

File

uROIndyEmailServer

See Also

Channels, Email Channels and Asynchronous Calls help topics

Pascal

TROCustomEmailServer = class(TROServer, IROTransport);


TROCustomEmailServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomEmailServer Class

 Pop3CheckInterval

Specifies the interval, in seconds, in which the server will check the POP3 account for new incoming requests (default is 60, 1 minute).

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect incoming request emails.

This can be a host name or IP address, and should point to the POP3 server that emails directed at the email specified in ServerEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ServerEmail

Specifies the email address of the server. This address will be used by clients to deliver emails to this server, and it will also be placed in the "From:" field of sent emails.

This email address should match the POP3 account configured for the server, so that the server will be able to access the requests directed at it.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.


Legend

Property


TROCustomEmailServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.

TROCustomEmailServer Class

 OnException

Fires if an exception occurred during the polling of the POP3 account.

Because polling the account happens in a worker thread, any problems encountered during polling (such as failed authentication with the POP3 server) will not bubble up to the main application. It is therefore important to handle this event if you want to be informed of error conditions.


Legend

Event


Legend

Legend

Property

Event


TROCustomEmailServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomEmailServer Class

 Pop3CheckInterval

Specifies the interval, in seconds, in which the server will check the POP3 account for new incoming requests (default is 60, 1 minute).

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect incoming request emails.

This can be a host name or IP address, and should point to the POP3 server that emails directed at the email specified in ServerEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ServerEmail

Specifies the email address of the server. This address will be used by clients to deliver emails to this server, and it will also be placed in the "From:" field of sent emails.

This email address should match the POP3 account configured for the server, so that the server will be able to access the requests directed at it.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.

TROCustomEmailServer Class

 OnException

Fires if an exception occurred during the polling of the POP3 account.

Because polling the account happens in a worker thread, any problems encountered during polling (such as failed authentication with the POP3 server) will not bubble up to the main application. It is therefore important to handle this event if you want to be informed of error conditions.


Legend

Property

Event


See Also

Channels, Email Channels and Asynchronous Calls help topics


TROCustomEmailServer.OnException Event

Fires if an exception occurred during the polling of the POP3 account.

Because polling the account happens in a worker thread, any problems encountered during polling (such as failed authentication with the POP3 server) will not bubble up to the main application. It is therefore important to handle this event if you want to be informed of error conditions.

See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

Pop3CheckInterval property

Pascal

property OnException: TROExceptionEvent;


See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

Pop3CheckInterval property


TROCustomEmailServer.Pop3CheckInterval Property

Specifies the interval, in seconds, in which the server will check the POP3 account for new incoming requests (default is 60, 1 minute).

See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

OnException event

Pascal

property Pop3CheckInterval: integer;


See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

OnException event


TROCustomEmailServer.Pop3Client Property

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

See Also

Indy documentation

Pascal

property Pop3Client: TIdPOP3;


See Also

Indy documentation


TROCustomEmailServer.Pop3Password Property

Specifies the password to be used to authenticate with the POP3 server.

See Also

Pop3Username, Pop3ServerAddress and ServerEmail properties

Pascal

property Pop3Password: string;


See Also

Pop3Username, Pop3ServerAddress and ServerEmail properties


TROCustomEmailServer.Pop3ServerAddress Property

Specifies the address of the POP3 server that will be used to collect incoming request emails.

This can be a host name or IP address, and should point to the POP3 server that emails directed at the email specified in ServerEmail will be delivered to.

See Also

ServerEmail, Pop3Username and Pop3Password properties

Pop3CheckInterval property

OnException event

Pascal

property Pop3ServerAddress: string;


See Also

ServerEmail, Pop3Username and Pop3Password properties

Pop3CheckInterval property

OnException event


TROCustomEmailServer.Pop3Username Property

Specifies the login name to be used to authenticate with the POP3 server.

See Also

Pop3Password, Pop3ServerAddress and ServerEmail properties

Pascal

property Pop3Username: string;


See Also

Pop3Password, Pop3ServerAddress and ServerEmail properties


TROCustomEmailServer.ServerEmail Property

Specifies the email address of the server. This address will be used by clients to deliver emails to this server, and it will also be placed in the "From:" field of sent emails.

This email address should match the POP3 account configured for the server, so that the server will be able to access the requests directed at it.

See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

Pascal

property ServerEmail: string;


See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties


TROCustomEmailServer.SmtpClient Property

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

See Also

Indy documentation

Pascal

property SmtpClient: TIdSMTP;


See Also

Indy documentation


TROCustomEmailServer.SmtpServerAddress Property

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

See Also

SmtpClient property

Pascal

property SmtpServerAddress: string;


See Also

SmtpClient property


TROCustomIndyTCPChannel Class

TROIndyTCPChannel implements a TCP based channel that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Essential Properties

Host specifies address of the server to talk to.

Port specifies the port number the server is listening on.

Class Hierarchy

Notes

Due to a bug in Indy, the Indy HTTP and TCP Channels cannot be used inside the IDE at design time.

If you need to use your channels at design time, for example in combination with Data Abstract to receive schema information or live data preview, we recommend using one of the other channels such as the TROWinInetHTTPChannel.

File

uROIndyTCPChannel

See Also

Channels and Legacy TCP Channels help topics

Pascal

TROCustomIndyTCPChannel = class(TROTransportChannel, IROTransport, IROTCPTransport);


TROCustomIndyTCPChannel Class Properties

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomIndyTCPChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.


Legend

Property

read only


TROCustomIndyTCPChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROCustomIndyTCPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROCustomIndyTCPChannel Class Members

Members

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomIndyTCPChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROCustomIndyTCPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels and Legacy TCP Channels help topics


TROCustomIndyTCPChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TROCustomIndyTCPChannel.Host Property

Specifies the address of the server to talk to. This can be a host name or an IP address.

Pascal

property Host: string;


TROCustomIndyTCPChannel.IndyClient Property

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

See Also

Indy documentation

Pascal

property IndyClient: TIdTCPClientBaseClass;


See Also

Indy documentation


TROCustomIndyTCPChannel.KeepAlive Property

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

Notes

For Keep-Alive to work, the option must be supported and enabled on both client and server.

See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties

Pascal

property KeepAlive: boolean;


See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties


TROCustomIndyTCPChannel.OnAfterProbingServer Event

Fires after the channel is done probing a specific server for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServer: TROEndProbeServerEvent;


See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROCustomIndyTCPChannel.OnAfterProbingServers Event

Fires after the channel is done probing all servers for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServers: TROEndProbeServersEvent;


See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROCustomIndyTCPChannel.OnBeforeProbingServer Event

Fires before the channel starts probing a specific server for availability.

Use Case

You can use this event to check or adjust the server configuration, or to include/exclude the server from being probed by changing the TROServerLocator.Enabled property.

See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServer: TROBeginProbeServerEvent;


See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROCustomIndyTCPChannel.OnBeforeProbingServers Event

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServers: TROBeginProbeServersEvent;


See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROCustomIndyTCPChannel.OnLoginNeeded Event

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

Use Case

The most common use for this event is to perform a call to a special Login service provided by the server (possibly after prompting the user to enter username ad password), and to set the aRetry parameter to true if login was successful.

See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic

Pascal

property OnLoginNeeded: TROExceptionEvent;


See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic


TROCustomIndyTCPChannel.OnReceiveStream Event

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnReceiveStream: TStreamDispatch;


See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROCustomIndyTCPChannel.OnSendStream Event

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnSendStream: TStreamDispatch;


See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROCustomIndyTCPChannel.Port Property

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

Pascal

property Port: integer;


TROCustomIndyTCPChannel.ProbeFrequency Property

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

Notes

Although somewhat misnamed, this property defines the Interval between probes, not the actual probing Frequency. The property name is persisted for backward compatibility, we apologize.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeFrequency: cardinal;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROCustomIndyTCPChannel.ProbeServers Property

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeServers: boolean;


See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROCustomIndyTCPChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TROCustomIndyTCPChannel.SynchronizedProbing Property

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property SynchronizedProbing: Boolean;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROCustomIndyTCPServer Class

TROIndyHTTPServer implements a TCP based server that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

Relevant Properties

Port specifies the network socket that the server will be listening on (default is 8090).

Class Hierarchy

File

uROIndyTCPServer

See Also

Channels and Legacy TCP Channels help topics

TROBPDXTCPServer component

Pascal

TROCustomIndyTCPServer = class(TROServer, IROTransport);


TROCustomIndyTCPServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomIndyTCPServer Class

 IndyServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).


Legend

Property

read only


TROCustomIndyTCPServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

read only

Event


TROCustomIndyTCPServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomIndyTCPServer Class

 IndyServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

read only

Event


See Also

Channels and Legacy TCP Channels help topics

TROBPDXTCPServer component


TROCustomIndyTCPServer.IndyServer Property

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

See Also

Indy documentation

Pascal

property IndyServer: TROTIdTCPServer;


See Also

Indy documentation


TROCustomIndyTCPServer.KeepAlive Property

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

Notes

For Keep-Alive to work, the option must be supported and enabled on both client and server.

See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties

Pascal

property KeepAlive: boolean;


See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties


TROCustomIndyTCPServer.Port Property

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

Pascal

property Port: Integer;


TROCustomSessionManager Class

TROCustomSessionManager forms the base class of all session managers provided by the RemObjects SDK, and can also be used as the base class for implementing your own special session manager.

Essential Properties

None; Session Managers are fully usable with their default configuration

Relevant Properties

SessionDuration specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes)

MaxSessions specifies the maximum number of sessions that will be allowed

Class Hierarchy

File

uROSessions

See Also

Session Management and Statelessness help topics

Pascal

TROCustomSessionManager = class(TROComponent, IROSessionsChangesNotifier);


TROCustomSessionManager Class Properties

Properties

 Clearing

 Critical

 MaxSessions

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.


Legend

Property

protected

read only


TROCustomSessionManager Class Methods

Methods

 CheckSessionIsExpired

 ClearSessions

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

 CreateSession

 DeleteSession

 GetAllSessions

Returns a string list containing the IDs of all currently active sessions.

 GetSessionCount

 ReleaseSession


Legend

Method


Legend

Legend

Property

protected

read only

Method


TROCustomSessionManager Class Members

Members

Properties

 Clearing

 Critical

 MaxSessions

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

Methods

 CheckSessionIsExpired

 ClearSessions

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

 CreateSession

 DeleteSession

 GetAllSessions

Returns a string list containing the IDs of all currently active sessions.

 GetSessionCount

 ReleaseSession


Legend

Property

protected

read only

Method


See Also

Session Management and Statelessness help topics


TROCustomSessionManager.Clearing Property

property Clearing: boolean;


TROCustomSessionManager.Critical Property

property Critical: TCriticalSection;


TROCustomSessionManager.MaxSessions Property

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

Notes

Allowing a server to run without enforcing any limit on number of sessions might pose a security risk, as malicious clients could theoretically start an infinite number of sessions by performing repeated requests with changing Client IDs, until server memory is depleted.

You should make sure to either set a limit, or tie session creation to user authentication, so that only valid client users can obtain a session (and possibly only one session per login).

Pascal

property MaxSessions: integer;


TROCustomSessionManager.SessionDuration Property

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

Notes

Note that the exact handling of the timeout processing depends on the implementation of the specific session manager, which might check session timeouts at intervals. Therefore, sessions might live slightly longer then the specified timeout.

See Also

ClearSessions method

Pascal

property SessionDuration: integer;


See Also

ClearSessions method


TROCustomSessionManager.CheckSessionIsExpired Method

function CheckSessionIsExpired(aSession: TROSession): boolean;


TROCustomSessionManager.ClearSessions Method

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

See Also

SessionDuration property

Pascal

procedure ClearSessions(OnlyExpired: boolean);


See Also

SessionDuration property


TROCustomSessionManager.CreateSession Method

function CreateSession(const aSessionID: TGUID): TROSession;


TROCustomSessionManager.DeleteSession Method

procedure DeleteSession(const aSessionID: TGUID; IsExpired: boolean);


TROCustomSessionManager.GetAllSessions Method

Returns a string list containing the IDs of all currently active sessions.

Notes

Note that depending on the uses of session manager and on your application architecture, this list can be huge, especially when using a database based session list that is shared by a large server farm. Obtaining the full list of sessions can be a costly process.

Pascal

procedure GetAllSessions(Dest: TStringList);


TROCustomSessionManager.GetSessionCount Method

function GetSessionCount: integer;


TROCustomSessionManager.ReleaseSession Method

procedure ReleaseSession(var aSession: TROSession; NewSession: boolean);


TROCustomSuperTcpChannel Class

TROSuperTCPChannel implements the new and enhanced TCP based channel introduced with the RemObjects SDK 4.0, which provides a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

The channel is based on the open source Indy components that ship with Delphi.

Essential Properties

Host specifies address of the server to talk to.

Port specifies the port number the server listens to.

Class Hierarchy

File

uROSuperTCPChannel

See Also

Channels and Legacy TCP Channels help topics

Pascal

TROCustomSuperTcpChannel = class(TROTransportChannel, IROTransport, IROTCPTransport, IROActiveEventChannel, IROMultiThreadAwareChannel, IROAsyncTransportChannel, IROActiveAsyncTransportChannel, IROTransportChannelEx);


TROCustomSuperTcpChannel Class Properties

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomSuperTcpChannel Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent request (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed.

 Active

Specifies whether the channel is currently active, which means has an open connection to the server, or is in the process of (re-)establishing a connection (true) or not (false).

 AutoReconnect

Specifies if the Super TCP Channel should automatically re-establish a connection to the server if the current connection is lost (true) or not (false, default).

 Client

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 ClientID

Contains the ClientID of the client.

 Connected

Returns whether the client currently has an active connection to the server (true) or not (false).

 Host

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 OnConnected

Fires when an active TCP connection to the server has been (re-)established.

 OnDisconnected

Fires when the active TCP connection to the server has been dropped or lost.

 Port

Specifies the port number the server is listening on (default for the RemObjects SDK TCP servers is 8095).

 ReconnectDelay

Specifies the time, in milliseconds, that the channel will wait after an unsuccessful (re-)connect, before it attempts the next connect, if AutoReconnect is true. Default is 500, half a second.

 RequestTimeout

Specifies the time frame, in milliseconds, within which the response for any given request must be received (default is 60,000, 1 minute). If no response has been received after the specified time, an exception is raised and the call will fail.

 StoreActive

Specifies whether the design time value of the Active property should be stored in in the form's DFM file (true, default), or not (false).


Legend

Property

read only


TROCustomSuperTcpChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROCustomSuperTcpChannel Class Members

Members

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomSuperTcpChannel Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent request (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed.

 Active

Specifies whether the channel is currently active, which means has an open connection to the server, or is in the process of (re-)establishing a connection (true) or not (false).

 AutoReconnect

Specifies if the Super TCP Channel should automatically re-establish a connection to the server if the current connection is lost (true) or not (false, default).

 Client

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 ClientID

Contains the ClientID of the client.

 Connected

Returns whether the client currently has an active connection to the server (true) or not (false).

 Host

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 OnConnected

Fires when an active TCP connection to the server has been (re-)established.

 OnDisconnected

Fires when the active TCP connection to the server has been dropped or lost.

 Port

Specifies the port number the server is listening on (default for the RemObjects SDK TCP servers is 8095).

 ReconnectDelay

Specifies the time, in milliseconds, that the channel will wait after an unsuccessful (re-)connect, before it attempts the next connect, if AutoReconnect is true. Default is 500, half a second.

 RequestTimeout

Specifies the time frame, in milliseconds, within which the response for any given request must be received (default is 60,000, 1 minute). If no response has been received after the specified time, an exception is raised and the call will fail.

 StoreActive

Specifies whether the design time value of the Active property should be stored in in the form's DFM file (true, default), or not (false).

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels and Legacy TCP Channels help topics


TROCustomSuperTcpChannel.AckWaitTimeout Property

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent request (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed.

See Also

RequestTimeout and MaxPackageSize property

Pascal

property AckWaitTimeout: Integer;


See Also

RequestTimeout and MaxPackageSize property


TROCustomSuperTcpChannel.Active Property

Specifies whether the channel is currently active, which means has an open connection to the server, or is in the process of (re-)establishing a connection (true) or not (false).

See Also

StoreActive and Conncted properties

Pascal

property Active: Boolean;


See Also

StoreActive and Conncted properties


TROCustomSuperTcpChannel.AutoReconnect Property

Specifies if the Super TCP Channel should automatically re-establish a connection to the server if the current connection is lost (true) or not (false, default).

Use Case

Set this property to true if your client needs a constant connection to the server, for example to receive callback events or asynchronous responses.

See Also

ReconnectDelay property

OnDisconnected and OnConnected events

Event Sinks and Server Callbacks and Asynchronous Calls help topics

Pascal

property AutoReconnect: Boolean;


See Also

ReconnectDelay property

OnDisconnected and OnConnected events

Event Sinks and Server Callbacks and Asynchronous Calls help topics


TROCustomSuperTcpChannel.Client Property

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

See Also

Indy documentation

Pascal

property Client: TIdTCPClient;


See Also

Indy documentation


TROCustomSuperTcpChannel.ClientID Property

Contains the ClientID of the client.

Use Case

Because the Super TCP Channel is capable of receiving event callbacks and asynchronous messages actively, it maintains the ClientID independently of the Message that is used to send requests.

In most scenarios, this ID will automatically be synchronized with the Message object, ensuring the events and sessions work as expected. However in some advanced scenarios (for example if you are persisting the ClientID between application restarts) you might need to assign this ID manually, in addition to assigning the ID of the message.

See Also

TROMessage.ClientID property

Event Sinks and Server Callbacks and Session Management help topics

Pascal

property ClientID: TGUID;


See Also

TROMessage.ClientID property

Event Sinks and Server Callbacks and Session Management help topics


TROCustomSuperTcpChannel.Connected Property

Returns whether the client currently has an active connection to the server (true) or not (false).

See Also

Active property

Pascal

property Connected: Boolean;


See Also

Active property


TROCustomSuperTcpChannel.Host Property

Pascal

property Host: string;


TROCustomSuperTcpChannel.MaxPackageSize Property

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

See Also

RequestTimeout property

Pascal

property MaxPackageSize: Integer;


See Also

RequestTimeout property


TROCustomSuperTcpChannel.OnConnected Property

Fires when an active TCP connection to the server has been (re-)established.

See Also

OnDisconnected event

AutoReconnect and ReconnectDelay properties

Pascal

property OnConnected: TNotifyEvent;


See Also

OnDisconnected event

AutoReconnect and ReconnectDelay properties


TROCustomSuperTcpChannel.OnDisconnected Property

Fires when the active TCP connection to the server has been dropped or lost.

See Also

OnConnected event

AutoReconnect and ReconnectDelay properties

Pascal

property OnDisconnected: TNotifyEvent;


See Also

OnConnected event

AutoReconnect and ReconnectDelay properties


TROCustomSuperTcpChannel.Port Property

Specifies the port number the server is listening on (default for the RemObjects SDK TCP servers is 8095).

Pascal

property Port: Integer;


TROCustomSuperTcpChannel.ReconnectDelay Property

Specifies the time, in milliseconds, that the channel will wait after an unsuccessful (re-)connect, before it attempts the next connect, if AutoReconnect is true. Default is 500, half a second.

See Also

AutoReconnect property

Pascal

property ReconnectDelay: Integer;


See Also

AutoReconnect property


TROCustomSuperTcpChannel.RequestTimeout Property

Specifies the time frame, in milliseconds, within which the response for any given request must be received (default is 60,000, 1 minute). If no response has been received after the specified time, an exception is raised and the call will fail.

See Also

MaxPackageSize property

Pascal

property RequestTimeout: Integer;


See Also

MaxPackageSize property


TROCustomSuperTcpChannel.StoreActive Property

Specifies whether the design time value of the Active property should be stored in in the form's DFM file (true, default), or not (false).

Use Case

Set this property to false if you want to activate the the component at design time but do not want Active to automatically be set to true when running your application (for example if you want to perform custom initialization in code, such as reading the host name from a config file) before activating the channel.

See Also

Active property

Pascal

property StoreActive: Boolean;


See Also

Active property


TROCustomSuperTcpServer Class

TROSuperTCPServer implements the server side of the new and enhanced TCP based channel introduced with the RemObjects SDK 4.0, which provides a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

The channel is based on the open source Indy components that ship with Delphi.

Essential Properties

Port specifies the port number the server is listening on.

Class Hierarchy

File

uROSuperTCPServer

See Also

Channels and Legacy TCP Channels help topics

Pascal

TROCustomSuperTcpServer = class(TROServer);


TROCustomSuperTcpServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomSuperTcpServer Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent event (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed and the event will be stored in the queue for future retries.

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 Port

Specifies the network socket that the server will be listening on (default for the RemObjects SDK Super TCP servers is 8095).

 Server

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using


Legend

Property

read only


TROCustomSuperTcpServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

read only

Event


TROCustomSuperTcpServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomSuperTcpServer Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent event (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed and the event will be stored in the queue for future retries.

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 Port

Specifies the network socket that the server will be listening on (default for the RemObjects SDK Super TCP servers is 8095).

 Server

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

read only

Event


See Also

Channels and Legacy TCP Channels help topics


TROCustomSuperTcpServer.AckWaitTimeout Property

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent event (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed and the event will be stored in the queue for future retries.

See Also

RequestTimeout and MaxPackageSize property

Pascal

property AckWaitTimeout: Integer;


See Also

RequestTimeout and MaxPackageSize property


TROCustomSuperTcpServer.MaxPackageSize Property

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

See Also

RequestTimeout property

Pascal

property MaxPackageSize: Integer;


See Also

RequestTimeout property


TROCustomSuperTcpServer.Port Property

Specifies the network socket that the server will be listening on (default for the RemObjects SDK Super TCP servers is 8095).

Pascal

property Port: Integer;


TROCustomSuperTcpServer.Server Property

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

See Also

Indy documentation

Pascal

property Server: TIdTcpServer;


See Also

Indy documentation


TRODBSessionManager Class

TRODBSessionManager implements a sophisticated session manager that stores session data in a database accessed by standard Delphi data access components. This database can in theory be shared by multiple servers, allowing session state to be accessible across a server farm.

Essential Properties

SelectDataset, InsertDataset, UpdateDataset and DeleteDataset specify the TDataset components used to access and store session information in the database.

Relevant Properties

FieldNameSessionID, FieldNameData, FieldNameCreated and FieldNameLastAccessed specify the fields used to store the respective information in the database.

SessionDuration specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

MaxSessions specifies the maximum number of sessions that will be allowed.

Class Hierarchy

File

uRODBSessionManager

See Also

TROCustomSessionManager, TROEventSessionManager and TROInMemorySessionManager and TROMasterServerSessionManager classes

Session Management and Statelessness help topics

Database Session Manager help topic

Pascal

TRODBSessionManager = class(TROCustomSessionManager);


TRODBSessionManager Class Properties

Properties

 Clearing

 Critical

 MaxSessions

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

TRODBSessionManager Class

 ClearSessionsDataset

Specifies the TDataset component that will be used to DELETE all sessions from the database, when ClearSessions is called or if the ClearSessionsOnCreate or ClearSessionsOnDestroy properties are set to true.

 ClearSessionsOnCreate

Specifies whether the session manager should clear the database of old sessions when the component is created (i.e. usually at application startup).

 ClearSessionsOnDestroy

Specifies whether the session manager should clear the database of old sessions when the component is destroyed (i.e. usually at application shutdown).

 DeleteDataset

Specifies the TDataset component that will be used to DELETE sessions from the database, when they expire or are explicitly deleted.

 FieldNameCreated

Specifies the database field used to store the time and date the session was originally created.

 FieldNameData

Specifies the database field used to store the session data. This must be a BLOB field.

 FieldNameLastAccessed

Specifies the database field used to store the time and date the session was last accessed.

 FieldNameSessionID

Specifies the database field used to store the session ID. This must be a GUID field, or a string field of 38 characters.

 GetCountDataset

Specifies the TDataset component that will be used to get the number of sessions contained in the database.

 InsertDataset

Specifies the TDataset component that will be used to INSERT new sessions into the database, when they are first created.

 SelectAllDataset

Specifies the TDataset component that will be used to get the complete list of session IDs from the database.

 SelectDataset

Specifies the TDataset component that will be used to SELECT (i.e. retrieve) sessions from the database, when needed.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

 UpdateDataset

Specifies the TDataset component that will be used to UPDATE sessions in the database, when they have been touched by the user.


Legend

Property

protected

read only


TRODBSessionManager Class Methods

Methods

 CheckSessionIsExpired

 ClearSessions

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

 CreateSession

 DeleteSession

 GetAllSessions

Returns a string list containing the IDs of all currently active sessions.

 GetSessionCount

 ReleaseSession


Legend

Method


TRODBSessionManager Class Events

Events

TRODBSessionManager Class

 OnConvertGUID

Fires whenever a Session ID is used to access the database, allowing to convert the actual GUIDs used by the session management to a different format for storage in a database.


Legend

Event


Legend

Legend

Property

protected

read only

Method

Event


TRODBSessionManager Class Members

Members

Properties

 Clearing

 Critical

 MaxSessions

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

TRODBSessionManager Class

 ClearSessionsDataset

Specifies the TDataset component that will be used to DELETE all sessions from the database, when ClearSessions is called or if the ClearSessionsOnCreate or ClearSessionsOnDestroy properties are set to true.

 ClearSessionsOnCreate

Specifies whether the session manager should clear the database of old sessions when the component is created (i.e. usually at application startup).

 ClearSessionsOnDestroy

Specifies whether the session manager should clear the database of old sessions when the component is destroyed (i.e. usually at application shutdown).

 DeleteDataset

Specifies the TDataset component that will be used to DELETE sessions from the database, when they expire or are explicitly deleted.

 FieldNameCreated

Specifies the database field used to store the time and date the session was originally created.

 FieldNameData

Specifies the database field used to store the session data. This must be a BLOB field.

 FieldNameLastAccessed

Specifies the database field used to store the time and date the session was last accessed.

 FieldNameSessionID

Specifies the database field used to store the session ID. This must be a GUID field, or a string field of 38 characters.

 GetCountDataset

Specifies the TDataset component that will be used to get the number of sessions contained in the database.

 InsertDataset

Specifies the TDataset component that will be used to INSERT new sessions into the database, when they are first created.

 SelectAllDataset

Specifies the TDataset component that will be used to get the complete list of session IDs from the database.

 SelectDataset

Specifies the TDataset component that will be used to SELECT (i.e. retrieve) sessions from the database, when needed.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

 UpdateDataset

Specifies the TDataset component that will be used to UPDATE sessions in the database, when they have been touched by the user.

Methods

 CheckSessionIsExpired

 ClearSessions

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

 CreateSession

 DeleteSession

 GetAllSessions

Returns a string list containing the IDs of all currently active sessions.

 GetSessionCount

 ReleaseSession

Events

TRODBSessionManager Class

 OnConvertGUID

Fires whenever a Session ID is used to access the database, allowing to convert the actual GUIDs used by the session management to a different format for storage in a database.


Legend

Property

protected

read only

Method

Event


See Also

TROCustomSessionManager, TROEventSessionManager and TROInMemorySessionManager and TROMasterServerSessionManager classes

Session Management and Statelessness help topics

Database Session Manager help topic


TRODBSessionManager.ClearSessionsDataset Property

Specifies the TDataset component that will be used to DELETE all sessions from the database, when ClearSessions is called or if the ClearSessionsOnCreate or ClearSessionsOnDestroy properties are set to true.

See Also

ClearSessions method

SessionDuration property

ClearSessionsOnCreate and ClearSessionsOnDestroy properties

Pascal

property ClearSessionsDataset: TDataset;


See Also

ClearSessions method

SessionDuration property

ClearSessionsOnCreate and ClearSessionsOnDestroy properties


TRODBSessionManager.ClearSessionsOnCreate Property

Specifies whether the session manager should clear the database of old sessions when the component is created (i.e. usually at application startup).

Use Case

Set this property to true if you want your server to start with a clean slate on each startup; keep it to false if you want sessions from previous executions to persist when the server shuts down and is restarted, or if multiple servers will share the same session database.

See Also

ClearSessions method

ClearSessionsOnDestroy and ClearSessionsDataset properties

Pascal

property ClearSessionsOnCreate: boolean;


See Also

ClearSessions method

ClearSessionsOnDestroy and ClearSessionsDataset properties


TRODBSessionManager.ClearSessionsOnDestroy Property

Specifies whether the session manager should clear the database of old sessions when the component is destroyed (i.e. usually at application shutdown).

Use Case

Set this property to true if you want your server to leave a clean slate on shutdown; keep it to false if you want sessions from previous executions to persist when the server shuts down and is restarted, or if multiple servers will share the same session database.

See Also

ClearSessions method

ClearSessionsOnCreate and ClearSessionsDataset properties

Pascal

property ClearSessionsOnDestroy: boolean;


See Also

ClearSessions method

ClearSessionsOnCreate and ClearSessionsDataset properties


TRODBSessionManager.DeleteDataset Property

Specifies the TDataset component that will be used to DELETE sessions from the database, when they expire or are explicitly deleted.

See Also

SelectDataset, InsertDataset and UpdateDataset properties

FieldNameSessionID, FieldNameData, FieldNameCreated and FieldNameLastAccessed properties

Pascal

property DeleteDataset: TDataset;


See Also

SelectDataset, InsertDataset and UpdateDataset properties

FieldNameSessionID, FieldNameData, FieldNameCreated and FieldNameLastAccessed properties


TRODBSessionManager.FieldNameCreated Property

Specifies the database field used to store the time and date the session was originally created.

See Also

FieldNameSessionID, FieldNameData and FieldNameLastAccessed properties

SelectDataset, InsertDataset, UpdateDataset and DeleteDataset properties

Pascal

property FieldNameCreated: string;


See Also

FieldNameSessionID, FieldNameData and FieldNameLastAccessed properties

SelectDataset, InsertDataset, UpdateDataset and DeleteDataset properties


TRODBSessionManager.FieldNameData Property

Specifies the database field used to store the session data. This must be a BLOB field.

See Also

FieldNameSessionID, FieldNameCreated and FieldNameLastAccessed properties

SelectDataset, InsertDataset, UpdateDataset and DeleteDataset properties

Pascal

property FieldNameData: string;


See Also

FieldNameSessionID, FieldNameCreated and FieldNameLastAccessed properties

SelectDataset, InsertDataset, UpdateDataset and DeleteDataset properties


TRODBSessionManager.FieldNameLastAccessed Property

Specifies the database field used to store the time and date the session was last accessed.

See Also

FieldNameSessionID, FieldNameData and FieldNameCreated properties

SelectDataset, InsertDataset, UpdateDataset and DeleteDataset properties

Pascal

property FieldNameLastAccessed: string;


See Also

FieldNameSessionID, FieldNameData and FieldNameCreated properties

SelectDataset, InsertDataset, UpdateDataset and DeleteDataset properties


TRODBSessionManager.FieldNameSessionID Property

Specifies the database field used to store the session ID. This must be a GUID field, or a string field of 38 characters.

See Also

FieldNameData, FieldNameCreated and FieldNameLastAccessed properties

SelectDataset, InsertDataset, UpdateDataset and DeleteDataset properties

Pascal

property FieldNameSessionID: string;


See Also

FieldNameData, FieldNameCreated and FieldNameLastAccessed properties

SelectDataset, InsertDataset, UpdateDataset and DeleteDataset properties


TRODBSessionManager.GetCountDataset Property

Specifies the TDataset component that will be used to get the number of sessions contained in the database.

See Also

SelectAllDataset property

Pascal

property GetCountDataset: TDataset;


See Also

SelectAllDataset property


TRODBSessionManager.InsertDataset Property

Specifies the TDataset component that will be used to INSERT new sessions into the database, when they are first created.

See Also

SelectDataset, UpdateDataset and DeleteDataset properties

FieldNameSessionID, FieldNameData, FieldNameCreated and FieldNameLastAccessed properties

Pascal

property InsertDataset: TDataset;


See Also

SelectDataset, UpdateDataset and DeleteDataset properties

FieldNameSessionID, FieldNameData, FieldNameCreated and FieldNameLastAccessed properties


TRODBSessionManager.OnConvertGUID Event

Fires whenever a Session ID is used to access the database, allowing to convert the actual GUIDs used by the session management to a different format for storage in a database.

Pascal

property OnConvertGUID: TConvertGUIDEvent;


TRODBSessionManager.SelectAllDataset Property

Specifies the TDataset component that will be used to get the complete list of session IDs from the database.

See Also

GetAllSessions method

GetCountDataset property

Pascal

property SelectAllDataset: TDataSet;


See Also

GetAllSessions method

GetCountDataset property


TRODBSessionManager.SelectDataset Property

Specifies the TDataset component that will be used to SELECT (i.e. retrieve) sessions from the database, when needed.

See Also

InsertDataset, UpdateDataset and DeleteDataset properties

FieldNameSessionID, FieldNameData, FieldNameCreated and FieldNameLastAccessed properties

Pascal

property SelectDataset: TDataset;


See Also

InsertDataset, UpdateDataset and DeleteDataset properties

FieldNameSessionID, FieldNameData, FieldNameCreated and FieldNameLastAccessed properties


TRODBSessionManager.SessionDuration Property

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

Notes

Note that the exact handling of the timeout processing depends on the implementation of the specific session manager, which might check session timeouts at intervals. Therefore, sessions might live slightly longer then the specified timeout.

See Also

ClearSessions method

Pascal

property SessionDuration: integer;


See Also

ClearSessions method


TRODBSessionManager.UpdateDataset Property

Specifies the TDataset component that will be used to UPDATE sessions in the database, when they have been touched by the user.

See Also

SelectDataset, InsertDataset and DeleteDataset properties

FieldNameSessionID, FieldNameData, FieldNameCreated and FieldNameLastAccessed properties

Pascal

property UpdateDataset: TDataset;


See Also

SelectDataset, InsertDataset and DeleteDataset properties

FieldNameSessionID, FieldNameData, FieldNameCreated and FieldNameLastAccessed properties


TRODiscoveryClient Class

File

uRODiscovery

Pascal

TRODiscoveryClient = class(TROCustomDiscoveryClient);


TRODiscoveryClient Class Properties

Properties

 Channel

Specifies the TROBroadcastChannel to use to locate servers.

 Message

Specifies the message format to use to talk to the servers.

 OnNewServersFound

Fires whenever the ServerList has been updated; whether new servers have been found or old servers have been removed.

 ServerList

Contains the list of servers that have been found to provide the requested service.

Call the RefreshServerList to (re)query the network and find new servers.

 ServiceName

Specifies the service name to look for on the local network.

TRODiscoveryClient Class

 Channel

Specifies the TROBroadcastChannel to use to locate servers.

 Message

Specifies the message format to use to talk to the servers.

 OnNewServersFound

Fires whenever the ServerList has been updated; whether new servers have been found or old servers have been removed.

 ServerList

Contains the list of servers that have been found to provide the requested service.

Call the RefreshServerList to (re)query the network and find new servers.

 ServiceName

Specifies the service name to look for on the local network.


Legend

Property

read only


TRODiscoveryClient Class Events

Events

 OnDiscoveryException

Fires if any exception was raised while probing for servers.

If an event handler is assigned, exceptions will not be re-raised after the event handler has executed.

 OnNewServiceFound

Fires whenever a new server responded to the broadcast.

The event gets passed the server name, as well as any user-specific TRODiscoveryOptions that might have been returned from the server. The event gets fired before the newly found server is added to the ServerList .

TRODiscoveryClient Class

 OnDiscoveryException

Fires if any exception was raised while probing for servers.

If an event handler is assigned, exceptions will not be re-raised after the event handler has executed.

 OnNewServiceFound

Fires whenever a new server responded to the broadcast.

The event gets passed the server name, as well as any user-specific TRODiscoveryOptions that might have been returned from the server. The event gets fired before the newly found server is added to the ServerList .


Legend

Event


TRODiscoveryClient Class Methods

Methods

 RefreshServerList

Performs a network broadcast to find new servers.

If needed, a user-defined TRODiscoveryOptions descendant class might be passed to the server to provide additional details or requirements for the desired service.

As responses from servers come in, the ServerList property is filled and the OnNewServiceFound and OnNewServersFoundevents are fired.


Legend

Method


Legend

Legend

Property

read only

Event

Method


TRODiscoveryClient Class Members

Members

Properties

 Channel

Specifies the TROBroadcastChannel to use to locate servers.

 Message

Specifies the message format to use to talk to the servers.

 OnNewServersFound

Fires whenever the ServerList has been updated; whether new servers have been found or old servers have been removed.

 ServerList

Contains the list of servers that have been found to provide the requested service.

Call the RefreshServerList to (re)query the network and find new servers.

 ServiceName

Specifies the service name to look for on the local network.

TRODiscoveryClient Class

 Channel

Specifies the TROBroadcastChannel to use to locate servers.

 Message

Specifies the message format to use to talk to the servers.

 OnNewServersFound

Fires whenever the ServerList has been updated; whether new servers have been found or old servers have been removed.

 ServerList

Contains the list of servers that have been found to provide the requested service.

Call the RefreshServerList to (re)query the network and find new servers.

 ServiceName

Specifies the service name to look for on the local network.

Events

 OnDiscoveryException

Fires if any exception was raised while probing for servers.

If an event handler is assigned, exceptions will not be re-raised after the event handler has executed.

 OnNewServiceFound

Fires whenever a new server responded to the broadcast.

The event gets passed the server name, as well as any user-specific TRODiscoveryOptions that might have been returned from the server. The event gets fired before the newly found server is added to the ServerList .

TRODiscoveryClient Class

 OnDiscoveryException

Fires if any exception was raised while probing for servers.

If an event handler is assigned, exceptions will not be re-raised after the event handler has executed.

 OnNewServiceFound

Fires whenever a new server responded to the broadcast.

The event gets passed the server name, as well as any user-specific TRODiscoveryOptions that might have been returned from the server. The event gets fired before the newly found server is added to the ServerList .

Methods

 RefreshServerList

Performs a network broadcast to find new servers.

If needed, a user-defined TRODiscoveryOptions descendant class might be passed to the server to provide additional details or requirements for the desired service.

As responses from servers come in, the ServerList property is filled and the OnNewServiceFound and OnNewServersFoundevents are fired.


Legend

Property

read only

Event

Method


TRODiscoveryClient.Channel Property

Specifies the TROBroadcastChannel to use to locate servers.

See Also

TROBroadcastChannel component

Pascal

property Channel: TROBroadcastChannel;


See Also

TROBroadcastChannel component


TRODiscoveryClient.Message Property

Specifies the message format to use to talk to the servers.

See Also

TROBroadcastChannel class

Messages and UDP and Broadcast Channels help topics

Pascal

property Message: TROMessage;


See Also

TROBroadcastChannel class

Messages and UDP and Broadcast Channels help topics


TRODiscoveryClient.OnDiscoveryException Event

Fires if any exception was raised while probing for servers.

If an event handler is assigned, exceptions will not be re-raised after the event handler has executed.

Pascal

property OnDiscoveryException: TRODiscoveryException;


TRODiscoveryClient.OnNewServersFound Property

Fires whenever the ServerList has been updated; whether new servers have been found or old servers have been removed.

See Also

ServerList property

OnNewServiceFound event

TRODiscoveryOptions class

Pascal

property OnNewServersFound: TNotifyEvent;


See Also

ServerList property

OnNewServiceFound event

TRODiscoveryOptions class


TRODiscoveryClient.OnNewServiceFound Event

Fires whenever a new server responded to the broadcast.

The event gets passed the server name, as well as any user-specific TRODiscoveryOptions that might have been returned from the server. The event gets fired before the newly found server is added to the ServerList .

See Also

ServerList property

OnNewServersFound event

TRODiscoveryOptions class

Pascal

property OnNewServiceFound: TRODiscoveryNewServiceFoundEvent;


See Also

ServerList property

OnNewServersFound event

TRODiscoveryOptions class


TRODiscoveryClient.ServerList Property

Contains the list of servers that have been found to provide the requested service.

Call the RefreshServerList to (re)query the network and find new servers.

See Also

ServiceName property

RefreshServerList method

Pascal

property ServerList: TStrings;


See Also

ServiceName property

RefreshServerList method


TRODiscoveryClient.ServiceName Property

Specifies the service name to look for on the local network.

Pascal

property ServiceName: string;


TRODiscoveryServer Class

This class implements the server side of the local network server discovery infrastructure in the RemObjects SDK.

Essential Properties

ServerList specifies the list of services that should be made available for discovery.

SupportRegisteredServerClasses specifies whether all standard RemObjects services registered in the server executable should automatically be made available for discovery.

Relevant Properties and Methods

ServerAddress can override the server address to send back to clients.

Class Hierarchy

File

uRODiscovery

See Also

TRODiscoveryClient component

Service Discovery help topic

"Service Discovery" sample application

Pascal

TRODiscoveryServer = class(TROCustomDiscoveryServer);


TRODiscoveryServer Class Events

Events

 OnServiceFound

This event is fired when a service probed for by a client was found on the local server.

The event gives the opportunity to stop the service from being returned as available, on a case by case basis. Also, any user-defined TRODiscoveryOptions descendant class passed from the client is available in the event for inspection, and (possibly different) TRODiscoveryOption can be returned to the server.

TRODiscoveryServer Class

 OnServiceFound

This event is fired when a service probed for by a client was found on the local server.

The event gives the opportunity to stop the service from being returned as available, on a case by case basis. Also, any user-defined TRODiscoveryOptions descendant class passed from the client is available in the event for inspection, and (possibly different) TRODiscoveryOption can be returned to the server.


Legend

Event


TRODiscoveryServer Class Properties

Properties

 ServerAddress

This property can be used to override the server address to send it back to clients. By default, if no value is specified, the actual IP address of the server will be used.

 ServiceList

Specifies the list of services that should be made available for discovery. This is a simple string list of names that the server will react to when being probed.

In addition to this list, the SupportRegisteredServerClasses property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable, as well.

 SupportRegisteredServerClasses

This property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable (true) or not (false).

If set t false, only the service names manually specified in the ServiceList property will be discoverable. It is of course possible to manually add a subset of the registered services to ServiceList, if desired.

TRODiscoveryServer Class

 ServiceList

Specifies the list of services that should be made available for discovery. This is a simple string list of names that the server will react to when being probed.

In addition to this list, the SupportRegisteredServerClasses property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable, as well.

 SupportRegisteredServerClasses

This property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable (true) or not (false).

If set t false, only the service names manually specified in the ServiceList property will be discoverable. It is of course possible to manually add a subset of the registered services to ServiceList, if desired.


Legend

Property


Legend

Legend

Event

Property


TRODiscoveryServer Class Members

Members

Events

 OnServiceFound

This event is fired when a service probed for by a client was found on the local server.

The event gives the opportunity to stop the service from being returned as available, on a case by case basis. Also, any user-defined TRODiscoveryOptions descendant class passed from the client is available in the event for inspection, and (possibly different) TRODiscoveryOption can be returned to the server.

TRODiscoveryServer Class

 OnServiceFound

This event is fired when a service probed for by a client was found on the local server.

The event gives the opportunity to stop the service from being returned as available, on a case by case basis. Also, any user-defined TRODiscoveryOptions descendant class passed from the client is available in the event for inspection, and (possibly different) TRODiscoveryOption can be returned to the server.

Properties

 ServerAddress

This property can be used to override the server address to send it back to clients. By default, if no value is specified, the actual IP address of the server will be used.

 ServiceList

Specifies the list of services that should be made available for discovery. This is a simple string list of names that the server will react to when being probed.

In addition to this list, the SupportRegisteredServerClasses property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable, as well.

 SupportRegisteredServerClasses

This property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable (true) or not (false).

If set t false, only the service names manually specified in the ServiceList property will be discoverable. It is of course possible to manually add a subset of the registered services to ServiceList, if desired.

TRODiscoveryServer Class

 ServiceList

Specifies the list of services that should be made available for discovery. This is a simple string list of names that the server will react to when being probed.

In addition to this list, the SupportRegisteredServerClasses property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable, as well.

 SupportRegisteredServerClasses

This property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable (true) or not (false).

If set t false, only the service names manually specified in the ServiceList property will be discoverable. It is of course possible to manually add a subset of the registered services to ServiceList, if desired.


Legend

Event

Property


See Also

TRODiscoveryClient component

Service Discovery help topic

"Service Discovery" sample application


TRODiscoveryServer.OnServiceFound Event

This event is fired when a service probed for by a client was found on the local server.

The event gives the opportunity to stop the service from being returned as available, on a case by case basis. Also, any user-defined TRODiscoveryOptions descendant class passed from the client is available in the event for inspection, and (possibly different) TRODiscoveryOption can be returned to the server.

Use Case

Using this event, the discovery server can take more detailed control over what services it declares as available. For example, the TRODiscoveryOptions passed by the client might define certain conditions that are expected form the service, that the server evaluates.

For example, multiple servers might be located on the local network to handle calculation tasks. The client might pass a value describing the complexity of the needed work when probing for servers, and each server could evaluate its own current CPU load when handling the OnServiceFound event, to determine if it is currently able to accommodate the request, or not. The client would only receive responses from those servers that currently are available.

The "Service Discovery" sample application included with the RemObjects SDK illustrates this by introducing a fictitious "Server Load" value.

See Also

ServiceList and SupportRegisteredServerClasses properties

TRODiscoveryOptions class

"Service Discovery" sample application

Pascal

property OnServiceFound: TRODiscoveryServiceFoundEvent;


See Also

ServiceList and SupportRegisteredServerClasses properties

TRODiscoveryOptions class

"Service Discovery" sample application


TRODiscoveryServer.ServiceList Property

Specifies the list of services that should be made available for discovery. This is a simple string list of names that the server will react to when being probed.

In addition to this list, the SupportRegisteredServerClasses property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable, as well.

See Also

SupportRegisteredServerClasses property

Pascal

property ServiceList: TStrings;


See Also

SupportRegisteredServerClasses property


TRODiscoveryServer.SupportRegisteredServerClasses Property

This property controls if all RemObjects SDK service classes registered within the server will automatically be discoverable (true) or not (false).

If set t false, only the service names manually specified in the ServiceList property will be discoverable. It is of course possible to manually add a subset of the registered services to ServiceList, if desired.

See Also

SupportRegisteredServerClasses property

Pascal

property SupportRegisteredServerClasses: boolean;


See Also

SupportRegisteredServerClasses property


TRODLLChannel Class

TRODLLChannel implements a channel that talks to services located in a local DLL file.

The server must be a .dll created using the DLL Server New Project Template.

Essential Properties

DLLName specifies the name of the DLL that contains the server.

Class Hierarchy

File

uRODLLChannel

See Also

Channels and Local Channels help topics

DLL Server New Project Template

Pascal

TRODLLChannel = class(TROTransportChannel, IROActiveEventChannel, IRODllEventCallback);


TRODLLChannel Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TRODLLChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 DLLHandle

Returns the handle of the loaded server DLL, or 0 if no DLL is loaded.

 DLLLoaded

Returns whether the server DLL is currently loaded, or not.

 DLLName

Specifies the name of the DLL that contains the server.

The name can be a fully qualified file name, or the name of a DLL in the processes search path.

 KeepDLLLoaded

Specifies wether the DLL should be kept in memory once it was loaded (true, default), or if it should be unloaded after each request (false).

Set this property to false if you expect the DLL to be changed between requests.

 OnDLLUnloaded

Fires after the server DLL has been successfully unloaded.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.


Legend

Property

read only


TRODLLChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TRODLLChannel Class

 OnDLLLoaded

Fires after the server DLL has been successfully loaded.


Legend

Event


TRODLLChannel Class Methods

Methods

TRODLLChannel Class

 UnloadDLL

Forces an unload of the DLL. Call this method manually if you need to change or updated the DLL before the next call, or if you need to have it unloaded from the process.


Legend

Method


Legend

Legend

Property

read only

Event

Method


TRODLLChannel Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TRODLLChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 DLLHandle

Returns the handle of the loaded server DLL, or 0 if no DLL is loaded.

 DLLLoaded

Returns whether the server DLL is currently loaded, or not.

 DLLName

Specifies the name of the DLL that contains the server.

The name can be a fully qualified file name, or the name of a DLL in the processes search path.

 KeepDLLLoaded

Specifies wether the DLL should be kept in memory once it was loaded (true, default), or if it should be unloaded after each request (false).

Set this property to false if you expect the DLL to be changed between requests.

 OnDLLUnloaded

Fires after the server DLL has been successfully unloaded.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TRODLLChannel Class

 OnDLLLoaded

Fires after the server DLL has been successfully loaded.

Methods

TRODLLChannel Class

 UnloadDLL

Forces an unload of the DLL. Call this method manually if you need to change or updated the DLL before the next call, or if you need to have it unloaded from the process.


Legend

Property

read only

Event

Method


See Also

Channels and Local Channels help topics

DLL Server New Project Template


TRODLLChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TRODLLChannel.DLLHandle Property

Returns the handle of the loaded server DLL, or 0 if no DLL is loaded.

See Also

DLLLoaded property

UnloadDLL method

Pascal

property DLLHandle: THandle;


See Also

DLLLoaded property

UnloadDLL method


TRODLLChannel.DLLLoaded Property

Returns whether the server DLL is currently loaded, or not.

See Also

OnDLLLoaded and OnDLLUnloaded events

UnloadDLL method

Pascal

property DLLLoaded: Boolean;


See Also

OnDLLLoaded and OnDLLUnloaded events

UnloadDLL method


TRODLLChannel.DLLName Property

Specifies the name of the DLL that contains the server.

The name can be a fully qualified file name, or the name of a DLL in the processes search path.

See Also

DLLHandle and KeepDLLLoaded properties

Pascal

property DLLName: string;


See Also

DLLHandle and KeepDLLLoaded properties


TRODLLChannel.KeepDLLLoaded Property

Specifies wether the DLL should be kept in memory once it was loaded (true, default), or if it should be unloaded after each request (false).

Set this property to false if you expect the DLL to be changed between requests.

See Also

UnloadDLL method

Pascal

property KeepDLLLoaded: boolean;


See Also

UnloadDLL method


TRODLLChannel.OnDLLLoaded Event

Fires after the server DLL has been successfully loaded.

See Also

OnDLLUnloaded event

UnloadDLL method

Pascal

property OnDLLLoaded: TDLLLoadEvent;


See Also

OnDLLUnloaded event

UnloadDLL method


TRODLLChannel.OnDLLUnloaded Property

Fires after the server DLL has been successfully unloaded.

See Also

KeepDLLLoaded property

OnDLLUnloaded event

UnloadDLL method

Pascal

property OnDLLUnloaded: TDLLUnloadEvent;


See Also

KeepDLLLoaded property

OnDLLUnloaded event

UnloadDLL method


TRODLLChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TRODLLChannel.UnloadDLL Method

Forces an unload of the DLL. Call this method manually if you need to change or updated the DLL before the next call, or if you need to have it unloaded from the process.

See Also

DLLLoaded and KeepDLLLoaded properties

Pascal

procedure UnloadDLL;


See Also

DLLLoaded and KeepDLLLoaded properties


TRODLLibrary Class

The TRODLLibrary class is used as an in-memory representation of a RODL file. It provides strongly-typed access to the services, and types defined within the RODL.

Class Hierarchy

File

uRODL

See Also

RODL Files help topic

Pascal

TRODLLibrary = class(TRODLComplexEntity);


See Also

RODL Files help topic


TRODynamicRequest Class

The Dynamic Request component can be used to construct requests to a server dynamically at runtime, without the method information or a proxy object being available at compile time.

This can be done by setting up the request based on data from a RODL file, or by manually specifying the method name and defining parameters for the call in code.

Essential Properties

RemoteService links to a TRORemoteService component that defines the service to be called

MethodName specifies the name of the method to be executed on the server

Params contains the list of parameters to send to and/or receive back from the server

Essential Methods

Execute performs the remote request and executes the service method on the server, based on the settings of the above properties.

Class Hierarchy

File

uRODynamicRequest

Pascal

TRODynamicRequest = class(TROComponent);


TRODynamicRequest Class Properties

Properties

 IsFunction

 MethodName

Specifies the name of the method to be executed on the server.

 Params

Contains the list of parameters used for the remote request, in form of a TRORequestParamCollection. Before executing the request, these parameters must be set to match the parameters expected by the server.

If a RODL defining the method call is available at runtime, the CopyRODLOperation method can be used to automatically configure the parameter based on an operation defined in there.

 RemoteService

Specifies a TRORemoteService component that defines the service to be called.


Legend

Property

read only


TRODynamicRequest Class Events

Events

 OnAfterExecute

Fires just after the remote call has executed (whether successfully or with an exception).

You can use this event to inspect the returned Params, or to log execution.

 OnBeforeExecute

Fires just before the remote call is executed.

You can use this event to make last changes to the list of Params, or to log execution.

 OnChangeServiceName

 OnExecuteError

Fires if an exception was raised during the execution of the remote request (whether this was an exception sent back from the server, or a local one).

You can use this event to inspect the raised exception, and optionally choose to not re-raise it, by setting the Ignore to true.

 OnFindCustomTypeImplementation


Legend

Event


TRODynamicRequest Class Methods

Methods

 Execute

Executes the remote request specified by the properties by writing the configured parameters to a message, executing the call and then loading the resulting parameters back.

 FindParam

A shortcut to the Params.FindParam method

 ParamByName

 RefreshParams

Reloads the parameter definitions for the call.

Overloads are provided to load the parameters from a specific RODL operation, or to automatically retrieve the RODL from the RemoteService and locate the operation based on the MethodName.

Also, an option is given to persist any values that might already be assigned to the Params, by passing true to aPersistValues.


Legend

Method


Legend

Legend

Property

read only

Event

Method


TRODynamicRequest Class Members

Members

Properties

 IsFunction

 MethodName

Specifies the name of the method to be executed on the server.

 Params

Contains the list of parameters used for the remote request, in form of a TRORequestParamCollection. Before executing the request, these parameters must be set to match the parameters expected by the server.

If a RODL defining the method call is available at runtime, the CopyRODLOperation method can be used to automatically configure the parameter based on an operation defined in there.

 RemoteService

Specifies a TRORemoteService component that defines the service to be called.

Events

 OnAfterExecute

Fires just after the remote call has executed (whether successfully or with an exception).

You can use this event to inspect the returned Params, or to log execution.

 OnBeforeExecute

Fires just before the remote call is executed.

You can use this event to make last changes to the list of Params, or to log execution.

 OnChangeServiceName

 OnExecuteError

Fires if an exception was raised during the execution of the remote request (whether this was an exception sent back from the server, or a local one).

You can use this event to inspect the raised exception, and optionally choose to not re-raise it, by setting the Ignore to true.

 OnFindCustomTypeImplementation

Methods

 Execute

Executes the remote request specified by the properties by writing the configured parameters to a message, executing the call and then loading the resulting parameters back.

 FindParam

A shortcut to the Params.FindParam method

 ParamByName

 RefreshParams

Reloads the parameter definitions for the call.

Overloads are provided to load the parameters from a specific RODL operation, or to automatically retrieve the RODL from the RemoteService and locate the operation based on the MethodName.

Also, an option is given to persist any values that might already be assigned to the Params, by passing true to aPersistValues.


Legend

Property

read only

Event

Method


TRODynamicRequest.IsFunction Property

property IsFunction: boolean;


TRODynamicRequest.MethodName Property

Specifies the name of the method to be executed on the server.

See Also

RemoteService and Params properties

Execute method

Pascal

property MethodName: string;


See Also

RemoteService and Params properties

Execute method


TRODynamicRequest.OnAfterExecute Event

Fires just after the remote call has executed (whether successfully or with an exception).

You can use this event to inspect the returned Params, or to log execution.

See Also

Execute method

Pascal

property OnAfterExecute: TRODynamicRequestNotifyEvent;


See Also

Execute method


TRODynamicRequest.OnBeforeExecute Event

Fires just before the remote call is executed.

You can use this event to make last changes to the list of Params, or to log execution.

See Also

Execute method

Pascal

property OnBeforeExecute: TRODynamicRequestNotifyEvent;


See Also

Execute method


TRODynamicRequest.OnChangeServiceName Event

property OnChangeServiceName: TROStringPropertyChangeEvent;


TRODynamicRequest.OnExecuteError Event

Fires if an exception was raised during the execution of the remote request (whether this was an exception sent back from the server, or a local one).

You can use this event to inspect the raised exception, and optionally choose to not re-raise it, by setting the Ignore to true.

See Also

Execute method

Pascal

property OnExecuteError: TRODynamicRequestErrorEvent;


See Also

Execute method


TRODynamicRequest.OnFindCustomTypeImplementation Event

property OnFindCustomTypeImplementation: TROFindCustomTypeImplementationEvent;


TRODynamicRequest.Params Property

Contains the list of parameters used for the remote request, in form of a TRORequestParamCollection. Before executing the request, these parameters must be set to match the parameters expected by the server.

If a RODL defining the method call is available at runtime, the CopyRODLOperation method can be used to automatically configure the parameter based on an operation defined in there.

See Also

TRORequestParamCollection class

RemoteService and Params properties

Execute method

Pascal

property Params: TRORequestParamCollection;


See Also

TRORequestParamCollection class

RemoteService and Params properties

Execute method


TRODynamicRequest.RemoteService Property

Specifies a TRORemoteService component that defines the service to be called.

See Also

TRORemoteService component

RemoteService and Params properties

Execute method

Channels and Messages help topics

Pascal

property RemoteService: TRORemoteService;


See Also

TRORemoteService component

RemoteService and Params properties

Execute method

Channels and Messages help topics


TRODynamicRequest.Execute Method

Executes the remote request specified by the properties by writing the configured parameters to a message, executing the call and then loading the resulting parameters back.

See Also

RemoteService, MethodName and Params properties

OnBeforeExecute, OnAfterExecute and OnExecuteError events

Pascal

procedure Execute(aParams: TRORequestParamCollection = nil);


See Also

RemoteService, MethodName and Params properties

OnBeforeExecute, OnAfterExecute and OnExecuteError events


TRODynamicRequest.FindParam Method

A shortcut to the Params.FindParam method

See Also

TRORequestParamCollection class

TRORequestParamCollection.FindParam method

Pascal

function FindParam(const aParamName: string): TRORequestParam;


See Also

TRORequestParamCollection class

TRORequestParamCollection.FindParam method


TRODynamicRequest.ParamByName Method

function ParamByName(const aParamName: string): TRORequestParam;


RefreshParams Method

Reloads the parameter definitions for the call.

Overloads are provided to load the parameters from a specific RODL operation, or to automatically retrieve the RODL from the RemoteService and locate the operation based on the MethodName.

Also, an option is given to persist any values that might already be assigned to the Params, by passing true to aPersistValues.

See Also

RemoteService, MethodName and Params properties


RefreshParams Method Methods

Methods

 RefreshParams

 RefreshParams


Legend

Method


Legend

Legend

Method


See Also

RemoteService, MethodName and Params properties


TRODynamicRequest.RefreshParams Method (TRODLOperation, boolean)

procedure RefreshParams(aOperation: TRODLOperation; aPersistValues: boolean = false); overload;


TRODynamicRequest.RefreshParams Method (boolean)

procedure RefreshParams(aPersistValues: boolean = false); overload;


TROEmailChannel Class

TROEmailChannel implements a channel that uses standard email infrastructure to send messages between client and server. The channel is based on the open source Indy components that ship with Delphi.

Due to the nature of how email delivery works, this channel is best-suited for asynchronous communications and scenarios where a response to a request is not expected in real time or even during the lifetime of the application.

Essential Properties

Pop3ServerAddress, Pop3Username and Pop3Password specify the POP3 server that will be used to collect response emails.

SmtpServerAddress specifies the address of the SMTP server that will be used to send of request emails.

ClientEmail specifies the email address of the client.

ServerEmail specifies the email address of the server.

Class Hierarchy

File

uROIndyEmailChannel

See Also

Channels, Email Channels and Asynchronous Calls help topics

Pascal

TROEmailChannel = class(TROCustomEmailChannel);


TROEmailChannel Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomEmailChannel Class

 ClientEmail

Specifies the email address of the client. This address will be used in the "From:" field of sent emails, and the server will evaluate to obtain the return address for its responses.

This email address should match the POP3 account configured for the client, so that the client will be able to access the responses directed at it.

 DeleteOldResponses

Specifies if old/unmatched response emails are automatically deleted as part of the POP3 polling process (default is false).

Enable this option, if the POP3 account is used exclusively by this one client, and the account should be automatically cleaned of all unexpected or old response emails that might still be in the inbox.

Keep this option disabled if several client applications will be sharing the POP3 account, so that they will not delete each other's messages.

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect response emails.

This can be a host name or an IP address, and should point to the POP3 server that emails directed at the email specified in ClientEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ServerEmail

Specifies the email address of the server. This address will be used in the "To:" field of sent emails to deliver them to the server.

This email address should match the POP3 account configured for the server.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

TROEmailChannel Class

 ClientEmail

Specifies the email address of the client. This address will be used in the "From:" field of sent emails, and the server will evaluate to obtain the return address for its responses.

This email address should match the POP3 account configured for the client, so that the client will be able to access the responses directed at it.

 DeleteOldResponses

Specifies if old/unmatched response emails are automatically deleted as part of the POP3 polling process (default is false).

Enable this option, if the POP3 account is used exclusively by this one client, and the account should be automatically cleaned of all unexpected or old response emails that might still be in the inbox.

Keep this option disabled if several client applications will be sharing the POP3 account, so that they will not delete each other's messages.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect response emails.

This can be a host name or an IP address, and should point to the POP3 server that emails directed at the email specified in ClientEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerEmail

Specifies the email address of the server. This address will be used in the "To:" field of sent emails to deliver them to the server.

This email address should match the POP3 account configured for the server.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.


Legend

Property

read only


TROEmailChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROEmailChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROEmailChannel Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomEmailChannel Class

 ClientEmail

Specifies the email address of the client. This address will be used in the "From:" field of sent emails, and the server will evaluate to obtain the return address for its responses.

This email address should match the POP3 account configured for the client, so that the client will be able to access the responses directed at it.

 DeleteOldResponses

Specifies if old/unmatched response emails are automatically deleted as part of the POP3 polling process (default is false).

Enable this option, if the POP3 account is used exclusively by this one client, and the account should be automatically cleaned of all unexpected or old response emails that might still be in the inbox.

Keep this option disabled if several client applications will be sharing the POP3 account, so that they will not delete each other's messages.

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect response emails.

This can be a host name or an IP address, and should point to the POP3 server that emails directed at the email specified in ClientEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ServerEmail

Specifies the email address of the server. This address will be used in the "To:" field of sent emails to deliver them to the server.

This email address should match the POP3 account configured for the server.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

TROEmailChannel Class

 ClientEmail

Specifies the email address of the client. This address will be used in the "From:" field of sent emails, and the server will evaluate to obtain the return address for its responses.

This email address should match the POP3 account configured for the client, so that the client will be able to access the responses directed at it.

 DeleteOldResponses

Specifies if old/unmatched response emails are automatically deleted as part of the POP3 polling process (default is false).

Enable this option, if the POP3 account is used exclusively by this one client, and the account should be automatically cleaned of all unexpected or old response emails that might still be in the inbox.

Keep this option disabled if several client applications will be sharing the POP3 account, so that they will not delete each other's messages.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect response emails.

This can be a host name or an IP address, and should point to the POP3 server that emails directed at the email specified in ClientEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerEmail

Specifies the email address of the server. This address will be used in the "To:" field of sent emails to deliver them to the server.

This email address should match the POP3 account configured for the server.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROEmailChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels, Email Channels and Asynchronous Calls help topics


TROEmailChannel.ClientEmail Property

Specifies the email address of the client. This address will be used in the "From:" field of sent emails, and the server will evaluate to obtain the return address for its responses.

This email address should match the POP3 account configured for the client, so that the client will be able to access the responses directed at it.

See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

ServerEmail property

Pascal

property ClientEmail: string;


See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

ServerEmail property


TROEmailChannel.DeleteOldResponses Property

Specifies if old/unmatched response emails are automatically deleted as part of the POP3 polling process (default is false).

Enable this option, if the POP3 account is used exclusively by this one client, and the account should be automatically cleaned of all unexpected or old response emails that might still be in the inbox.

Keep this option disabled if several client applications will be sharing the POP3 account, so that they will not delete each other's messages.

Notes

The email channel will never delete any email messages that did not originate from a RemObjects SDK server. So it is completely safe to use the channel on a POP3 account that is also used for normal email correspondence.

Pascal

property DeleteOldResponses: boolean;


TROEmailChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TROEmailChannel.OnAfterProbingServer Event

Fires after the channel is done probing a specific server for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServer: TROEndProbeServerEvent;


See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROEmailChannel.OnAfterProbingServers Event

Fires after the channel is done probing all servers for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServers: TROEndProbeServersEvent;


See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROEmailChannel.OnBeforeProbingServer Event

Fires before the channel starts probing a specific server for availability.

Use Case

You can use this event to check or adjust the server configuration, or to include/exclude the server from being probed by changing the TROServerLocator.Enabled property.

See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServer: TROBeginProbeServerEvent;


See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROEmailChannel.OnBeforeProbingServers Event

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServers: TROBeginProbeServersEvent;


See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROEmailChannel.OnLoginNeeded Event

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

Use Case

The most common use for this event is to perform a call to a special Login service provided by the server (possibly after prompting the user to enter username ad password), and to set the aRetry parameter to true if login was successful.

See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic

Pascal

property OnLoginNeeded: TROExceptionEvent;


See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic


TROEmailChannel.OnReceiveStream Event

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnReceiveStream: TStreamDispatch;


See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROEmailChannel.OnSendStream Event

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnSendStream: TStreamDispatch;


See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROEmailChannel.Pop3Client Property

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

See Also

Indy documentation

Pascal

property Pop3Client: TIdPOP3;


See Also

Indy documentation


TROEmailChannel.Pop3Password Property

Specifies the password to be used to authenticate with the POP3 server.

See Also

Pop3Username, Pop3ServerAddress and ClientEmail properties

Pascal

property Pop3Password: string;


See Also

Pop3Username, Pop3ServerAddress and ClientEmail properties


TROEmailChannel.Pop3ServerAddress Property

Specifies the address of the POP3 server that will be used to collect response emails.

This can be a host name or an IP address, and should point to the POP3 server that emails directed at the email specified in ClientEmail will be delivered to.

See Also

ClientEmail, Pop3Username and Pop3Password properties

Pop3Client property

Pascal

property Pop3ServerAddress: string;


See Also

ClientEmail, Pop3Username and Pop3Password properties

Pop3Client property


TROEmailChannel.Pop3Username Property

Specifies the login name to be used to authenticate with the POP3 server.

See Also

Pop3Password, Pop3ServerAddress and ClientEmail properties

Pascal

property Pop3Username: string;


See Also

Pop3Password, Pop3ServerAddress and ClientEmail properties


TROEmailChannel.ProbeFrequency Property

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

Notes

Although somewhat misnamed, this property defines the Interval between probes, not the actual probing Frequency. The property name is persisted for backward compatibility, we apologize.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeFrequency: cardinal;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROEmailChannel.ProbeServers Property

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeServers: boolean;


See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROEmailChannel.ServerEmail Property

Specifies the email address of the server. This address will be used in the "To:" field of sent emails to deliver them to the server.

This email address should match the POP3 account configured for the server.

See Also

ClientEmail property

TROEmailServer.Pop3ServerAddress property

Pascal

property ServerEmail: string;


See Also

ClientEmail property

TROEmailServer.Pop3ServerAddress property


TROEmailChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TROEmailChannel.SmtpClient Property

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

See Also

Indy documentation

Pascal

property SmtpClient: TIdSMTP;


See Also

Indy documentation


TROEmailChannel.SmtpServerAddress Property

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

See Also

SmtpClient property

Pascal

property SmtpServerAddress: string;


See Also

SmtpClient property


TROEmailChannel.SynchronizedProbing Property

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property SynchronizedProbing: Boolean;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROEmailServer Class

TROEmailServer implements a server that uses standard email infrastructure to send messages between client and server. The channel is based on the open source Indy components that ship with Delphi.

Due to the nature of how email delivery works, this channel is best-suited for asynchronous communications and scenarios where a response to a request is not expected in real time or even during the lifetime of the application.

Essential Properties

Pop3ServerAddress, Pop3Username and Pop3Password specify the POP3 server that will be used to collect response emails.

SmtpServerAddress specifies the address of the SMTP server that will be used to send of request emails.

ServerEmail specifies the email address of the server.

Class Hierarchy

File

uROIndyEmailServer

See Also

Channels, Email Channels and Asynchronous Calls help topics

Pascal

TROEmailServer = class(TROCustomEmailServer);


TROEmailServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomEmailServer Class

 Pop3CheckInterval

Specifies the interval, in seconds, in which the server will check the POP3 account for new incoming requests (default is 60, 1 minute).

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect incoming request emails.

This can be a host name or IP address, and should point to the POP3 server that emails directed at the email specified in ServerEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ServerEmail

Specifies the email address of the server. This address will be used by clients to deliver emails to this server, and it will also be placed in the "From:" field of sent emails.

This email address should match the POP3 account configured for the server, so that the server will be able to access the requests directed at it.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

TROEmailServer Class

 Pop3CheckInterval

Specifies the interval, in seconds, in which the server will check the POP3 account for new incoming requests (default is 60, 1 minute).

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect incoming request emails.

This can be a host name or IP address, and should point to the POP3 server that emails directed at the email specified in ServerEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ServerEmail

Specifies the email address of the server. This address will be used by clients to deliver emails to this server, and it will also be placed in the "From:" field of sent emails.

This email address should match the POP3 account configured for the server, so that the server will be able to access the requests directed at it.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.


Legend

Property


TROEmailServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.

TROCustomEmailServer Class

 OnException

Fires if an exception occurred during the polling of the POP3 account.

Because polling the account happens in a worker thread, any problems encountered during polling (such as failed authentication with the POP3 server) will not bubble up to the main application. It is therefore important to handle this event if you want to be informed of error conditions.

TROEmailServer Class

 OnException

Fires if an exception occurred during the polling of the POP3 account.

Because polling the account happens in a worker thread, any problems encountered during polling (such as failed authentication with the POP3 server) will not bubble up to the main application. It is therefore important to handle this event if you want to be informed of error conditions.


Legend

Event


Legend

Legend

Property

Event


TROEmailServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomEmailServer Class

 Pop3CheckInterval

Specifies the interval, in seconds, in which the server will check the POP3 account for new incoming requests (default is 60, 1 minute).

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect incoming request emails.

This can be a host name or IP address, and should point to the POP3 server that emails directed at the email specified in ServerEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ServerEmail

Specifies the email address of the server. This address will be used by clients to deliver emails to this server, and it will also be placed in the "From:" field of sent emails.

This email address should match the POP3 account configured for the server, so that the server will be able to access the requests directed at it.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

TROEmailServer Class

 Pop3CheckInterval

Specifies the interval, in seconds, in which the server will check the POP3 account for new incoming requests (default is 60, 1 minute).

 Pop3Client

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

 Pop3Password

Specifies the password to be used to authenticate with the POP3 server.

 Pop3ServerAddress

Specifies the address of the POP3 server that will be used to collect incoming request emails.

This can be a host name or IP address, and should point to the POP3 server that emails directed at the email specified in ServerEmail will be delivered to.

 Pop3Username

Specifies the login name to be used to authenticate with the POP3 server.

 ServerEmail

Specifies the email address of the server. This address will be used by clients to deliver emails to this server, and it will also be placed in the "From:" field of sent emails.

This email address should match the POP3 account configured for the server, so that the server will be able to access the requests directed at it.

 SmtpClient

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

 SmtpServerAddress

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.

TROCustomEmailServer Class

 OnException

Fires if an exception occurred during the polling of the POP3 account.

Because polling the account happens in a worker thread, any problems encountered during polling (such as failed authentication with the POP3 server) will not bubble up to the main application. It is therefore important to handle this event if you want to be informed of error conditions.

TROEmailServer Class

 OnException

Fires if an exception occurred during the polling of the POP3 account.

Because polling the account happens in a worker thread, any problems encountered during polling (such as failed authentication with the POP3 server) will not bubble up to the main application. It is therefore important to handle this event if you want to be informed of error conditions.


Legend

Property

Event


See Also

Channels, Email Channels and Asynchronous Calls help topics


TROEmailServer.OnException Event

Fires if an exception occurred during the polling of the POP3 account.

Because polling the account happens in a worker thread, any problems encountered during polling (such as failed authentication with the POP3 server) will not bubble up to the main application. It is therefore important to handle this event if you want to be informed of error conditions.

See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

Pop3CheckInterval property

Pascal

property OnException: TROExceptionEvent;


See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

Pop3CheckInterval property


TROEmailServer.Pop3CheckInterval Property

Specifies the interval, in seconds, in which the server will check the POP3 account for new incoming requests (default is 60, 1 minute).

See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

OnException event

Pascal

property Pop3CheckInterval: integer;


See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

OnException event


TROEmailServer.Pop3Client Property

Provides direct access to the underlying Indy POP3 Client implementation. You can use this property to control advanced settings on the Indy POP3 object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

The SmtpClient property can be used to control advanced options.

See Also

Indy documentation

Pascal

property Pop3Client: TIdPOP3;


See Also

Indy documentation


TROEmailServer.Pop3Password Property

Specifies the password to be used to authenticate with the POP3 server.

See Also

Pop3Username, Pop3ServerAddress and ServerEmail properties

Pascal

property Pop3Password: string;


See Also

Pop3Username, Pop3ServerAddress and ServerEmail properties


TROEmailServer.Pop3ServerAddress Property

Specifies the address of the POP3 server that will be used to collect incoming request emails.

This can be a host name or IP address, and should point to the POP3 server that emails directed at the email specified in ServerEmail will be delivered to.

See Also

ServerEmail, Pop3Username and Pop3Password properties

Pop3CheckInterval property

OnException event

Pascal

property Pop3ServerAddress: string;


See Also

ServerEmail, Pop3Username and Pop3Password properties

Pop3CheckInterval property

OnException event


TROEmailServer.Pop3Username Property

Specifies the login name to be used to authenticate with the POP3 server.

See Also

Pop3Password, Pop3ServerAddress and ServerEmail properties

Pascal

property Pop3Username: string;


See Also

Pop3Password, Pop3ServerAddress and ServerEmail properties


TROEmailServer.ServerEmail Property

Specifies the email address of the server. This address will be used by clients to deliver emails to this server, and it will also be placed in the "From:" field of sent emails.

This email address should match the POP3 account configured for the server, so that the server will be able to access the requests directed at it.

See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties

Pascal

property ServerEmail: string;


See Also

Pop3ServerAddress, Pop3Username and Pop3Password properties


TROEmailServer.SmtpClient Property

Provides direct access to the underlying Indy SMTP Client implementation. You can use this property to control advanced settings on the Indy SMTP object, such as setting authentication options.

The exact available properties and settings depend on the version of Indy you are using.

See Also

Indy documentation

Pascal

property SmtpClient: TIdSMTP;


See Also

Indy documentation


TROEmailServer.SmtpServerAddress Property

Specifies the address of the SMTP server that will be used to dispatch outgoing messages.

This can be a host name or an IP address, and can be any SMTP server capable of relaying mails to the destination, including an open relay or the ISP's email server.

The SmtpClient property can be used to control advanced options such as authentication.

See Also

SmtpClient property

Pascal

property SmtpServerAddress: string;


See Also

SmtpClient property


TROEncryption Class

This class provides settings for encrypting and decrypting communication at the channel level. It's available through the Encryption property on all channels and servers.

Essential Properties

EncryptionMethod specifies the encryption method to be used (default is tetNone, no encryption).

EncryptionSendKey specifies the key to be used for encrypting outgoing messages.

EncryptionRecvKey specifies the key to be used for decrypting incoming messages.

Relevant Properties

UseCompression specifies whether to compress the messages during encryption, or not.

Class Hierarchy

Notes

The use of UseCompression is discouraged, instead, we recommend to use the compression provided by the BinMessage message format.

Also, encryption is only supported for Delphi/Win32; it is not available in Kylix and Free Pascal, nor is it compatible with the RemObjects SDK for .NET. Future versions of the SDK will introduce more flexible and cross-platform encryption capabilities, at the Message level.

File

uROEncryption

See Also

TROBaseConnection.Encryption property

TROBinMessage component

BinMessage help topic

Pascal

TROEncryption = class(TROCustomEncryption);


TROEncryption Class Events

Events

 OnAfterDecryption

Fires after the decryption task has finished, giving you access to both the original (encrypted) and processed (decrypted) stream.

 OnBeforeEncryption

Fires before the encryption task starts.


Legend

Event


Legend

Legend

Event


TROEncryption Class Members

Members

Events

 OnAfterDecryption

Fires after the decryption task has finished, giving you access to both the original (encrypted) and processed (decrypted) stream.

 OnBeforeEncryption

Fires before the encryption task starts.


Legend

Event


See Also

TROBaseConnection.Encryption property

TROBinMessage component

BinMessage help topic


TROEncryption.OnAfterDecryption Event

Fires after the decryption task has finished, giving you access to both the original (encrypted) and processed (decrypted) stream.

See Also

OnBeforeEncryption property

Pascal

property OnAfterDecryption;


See Also

OnBeforeEncryption property


TROEncryption.OnBeforeEncryption Event

Fires before the encryption task starts.

See Also

OnAfterDecryption property

Pascal

property OnBeforeEncryption;


See Also

OnAfterDecryption property


TROEventReceiver Class

The Event Receiver component is used on the client to enable receiving callback events from the server.

Depending on the channel type, this will be done by regularly polling the server for new events or, if the channel supports active sending of events, by simply awaiting events to be sent from the server.

Essential Properties

Channel specifies the channel to be used for receiving events. Unless the channel type is explicitly designed for consecutive requests (such as the Super TCP Channel), it is recommended to not use the same channel instance that you use for your regular communication, but to drop a second channel component.

Message specifies the message format used to decode the received events. Because events are handled based on the ClientID stored in the message, it is recommended to assign the same message that you are also using for your regular communication or to manually sync the ClientID between the two messages.

ServiceName specifies the name of the service that events should be received from.

Active specifies whether the event receiver is currently processing events or not.

Essential Methods

RegisterEventHandlers is used to register one or more classes to receive events.

Relevant Properties and Events

Interval specifies the interval, in milliseconds, at which the receiver will poll for new events. Default is 30,000 (30 seconds).

SynchronizeInvoke specifies whether events will be fired in the context of the main VCL thread (true, default) or not (false).

OnPollException gets fired when the event receiver has encountered an error while polling for events.

Class Hierarchy

File

uROEventRepository

See Also

Messages help topic

Pascal

TROEventReceiver = class(TROChannelAwareComponent, IROObjectRetainer, IROEventReceiver, IROEventReceiverInvokers);


TROEventReceiver Class Properties

Properties

 Active

Specifies whether the event receiver is currently processing events (true), or not (false).

This property must be set to true before any actual event processing will occur.

 Channel

Specifies the channel to be used for receiving events.

Unless the channel type is explicitly designed for consecutive requests (such as the Super TCP Channel), it is recommended to not use the same channel instance that you use for your regular communication, but to drop a second channel component.

 Interval

Specifies the interval, in milliseconds, at which the receiver will poll for new events. The Default value is 30,000 (30 seconds).

 Message

Specifies the message format used to decode the received events. Because events are handled based on the ClientID stored in the message, it is recommended to assign the same message that you are also using for your regular communication or to manually sync the ClientID between the two messages.

 OnActivate

This event gets fired when the event receiver has been activated and will start receiving events.

 OnDeactivate

This event gets fired when the event receiver has been deactivated and will stop receiving events.

 ServiceName

Specifies the name of the service that events should be received from.

 SynchronizeInvoke

Specifies whether events will be fired in the context of the main VCL thread (true, default) or not (false).

By default, the Event Receiver will synchronize all events back to the main VCL thread, which makes it save to access the user interface from your event handler code.


Legend

Property


TROEventReceiver Class Events

Events

 OnPollException

This event gets fired when the event receiver has encountered an error while polling for or dispatching events.


Legend

Event


TROEventReceiver Class Methods

Methods

 Activate

 AreEventHandlersRegistered

Checks whether the passed event handlers are currently registered.

 Deactivate

 IsEventHandlerRegistered

Checks whether the passed event handler is currently registered.

 RegisterEventHandlers

This method is is used to register one or more classes to receive events.

 ReleaseObject

 RetainObject

 UnregisterEventHandlers

This method is is used to unregister one or more event handlers previously registered via RegisterEventHandlers.


Legend

Method


Legend

Legend

Property

Event

Method


TROEventReceiver Class Members

Members

Properties

 Active

Specifies whether the event receiver is currently processing events (true), or not (false).

This property must be set to true before any actual event processing will occur.

 Channel

Specifies the channel to be used for receiving events.

Unless the channel type is explicitly designed for consecutive requests (such as the Super TCP Channel), it is recommended to not use the same channel instance that you use for your regular communication, but to drop a second channel component.

 Interval

Specifies the interval, in milliseconds, at which the receiver will poll for new events. The Default value is 30,000 (30 seconds).

 Message

Specifies the message format used to decode the received events. Because events are handled based on the ClientID stored in the message, it is recommended to assign the same message that you are also using for your regular communication or to manually sync the ClientID between the two messages.

 OnActivate

This event gets fired when the event receiver has been activated and will start receiving events.

 OnDeactivate

This event gets fired when the event receiver has been deactivated and will stop receiving events.

 ServiceName

Specifies the name of the service that events should be received from.

 SynchronizeInvoke

Specifies whether events will be fired in the context of the main VCL thread (true, default) or not (false).

By default, the Event Receiver will synchronize all events back to the main VCL thread, which makes it save to access the user interface from your event handler code.

Events

 OnPollException

This event gets fired when the event receiver has encountered an error while polling for or dispatching events.

Methods

 Activate

 AreEventHandlersRegistered

Checks whether the passed event handlers are currently registered.

 Deactivate

 IsEventHandlerRegistered

Checks whether the passed event handler is currently registered.

 RegisterEventHandlers

This method is is used to register one or more classes to receive events.

 ReleaseObject

 RetainObject

 UnregisterEventHandlers

This method is is used to unregister one or more event handlers previously registered via RegisterEventHandlers.


Legend

Property

Event

Method


See Also

Messages help topic


TROEventReceiver.Active Property

Specifies whether the event receiver is currently processing events (true), or not (false).

This property must be set to true before any actual event processing will occur.

Pascal

property Active: boolean;


TROEventReceiver.Channel Property

Specifies the channel to be used for receiving events.

Unless the channel type is explicitly designed for consecutive requests (such as the Super TCP Channel), it is recommended to not use the same channel instance that you use for your regular communication, but to drop a second channel component.

See Also

TROTransportChannel class

Channels help topic

Pascal

property Channel;


See Also

TROTransportChannel class

Channels help topic


TROEventReceiver.Interval Property

Specifies the interval, in milliseconds, at which the receiver will poll for new events. The Default value is 30,000 (30 seconds).

See Also

SynchronizedProbing property

Pascal

property Interval: integer;


See Also

SynchronizedProbing property


TROEventReceiver.Message Property

Specifies the message format used to decode the received events. Because events are handled based on the ClientID stored in the message, it is recommended to assign the same message that you are also using for your regular communication or to manually sync the ClientID between the two messages.

See Also

TROMessage class

Messages help topic

Pascal

property Message;


See Also

TROMessage class

Messages help topic


TROEventReceiver.OnActivate Property

This event gets fired when the event receiver has been activated and will start receiving events.

See Also

Active property

OnDeactivate event

Pascal

property OnActivate: TNotifyEvent;


See Also

Active property

OnDeactivate event


TROEventReceiver.OnDeactivate Property

This event gets fired when the event receiver has been deactivated and will stop receiving events.

See Also

Active property

OnActivate event

Pascal

property OnDeactivate: TNotifyEvent;


See Also

Active property

OnActivate event


TROEventReceiver.OnPollException Event

This event gets fired when the event receiver has encountered an error while polling for or dispatching events.

Use Case

Because event polling happens in a background thread, exceptions that occur during polling will not automatically bubble up to the main application and show an exception dialog. As such, it is important to handle this event of the Event Receiver in order to be notified of any problems that might arise during event polling.

Pascal

property OnPollException: TROOnEventExceptionEvent;


TROEventReceiver.ServiceName Property

Specifies the name of the service that events should be received from.

Pascal

property ServiceName: string;


TROEventReceiver.SynchronizeInvoke Property

Specifies whether events will be fired in the context of the main VCL thread (true, default) or not (false).

By default, the Event Receiver will synchronize all events back to the main VCL thread, which makes it save to access the user interface from your event handler code.

Use Case

If UI access is not needed, and your event handlers are implemented in a thread-safe fashion, you can disable this property to gain performance by having events fire in the thread they have been received on.

Also, if you are performing lengthy operations in your event handlers, your UI might freeze while event handlers execute and block the main VCL thread (which is responsible for user interaction); disable this property to avoid that.

See Also

SynchronizedProbing property

Pascal

property SynchronizeInvoke: Boolean;


See Also

SynchronizedProbing property


TROEventReceiver.Activate Method

procedure Activate;


TROEventReceiver.AreEventHandlersRegistered Method

Checks whether the passed event handlers are currently registered.

See Also

IsEventHandlerRegistered, RegisterEventHandlers and UnregisterEventHandlers methods

Pascal

function AreEventHandlersRegistered(const aEventIDs: array of string; const aEventHandlers: array of TObject): boolean;


See Also

IsEventHandlerRegistered, RegisterEventHandlers and UnregisterEventHandlers methods


TROEventReceiver.Deactivate Method

procedure Deactivate;


TROEventReceiver.IsEventHandlerRegistered Method

Checks whether the passed event handler is currently registered.

See Also

AreEventHandlersRegistered, RegisterEventHandlers and UnregisterEventHandlers methods

Pascal

function IsEventHandlerRegistered(const aEventID: string; const aEventHandler: TObject): boolean;


See Also

AreEventHandlersRegistered, RegisterEventHandlers and UnregisterEventHandlers methods


TROEventReceiver.RegisterEventHandlers Method

This method is is used to register one or more classes to receive events.
aEventIDs	An array of strings containing the IDs of the events you want to subscribe to. Event ID constants are generated in the _Intf unit of your library for each defined Event Sink, and start with EID_.
aEventHandlers	An array of objects that will be registered to receive the events. Each of the objects must implement the respective event sink interfaces defined in your _Intf unit.
See Also

UnregisterEventHandlers and AreEventHandlersRegistered methods

Pascal

procedure RegisterEventHandlers(const EventIDs: array of string; const EventHandlers: array of TObject); overload;


See Also

UnregisterEventHandlers and AreEventHandlersRegistered methods


TROEventReceiver.ReleaseObject Method

procedure ReleaseObject(const anObject: TObject);


TROEventReceiver.RetainObject Method

procedure RetainObject(const anObject: TObject);


TROEventReceiver.UnregisterEventHandlers Method

This method is is used to unregister one or more event handlers previously registered via RegisterEventHandlers.

See Also

RegisterEventHandlers and AreEventHandlersRegistered methods

Pascal

procedure UnregisterEventHandlers(const EventIDs: array of string); overload;


See Also

RegisterEventHandlers and AreEventHandlersRegistered methods


TROEventRepository Class

TROEventRepository forms the base class of all event repository components provided by the RemObjects SDK, and can also be used as the base class for implementing your own.

Essential Properties

Message specifies the message format used to encode event data.

SessionManager specifies the session manager that maintains the the server's user sessions.

Class Hierarchy

File

uROEventRepository

See Also

Event Sinks and Server Callbacks help topics

Pascal

TROEventRepository = class(TROComponent, IROEventRepository);


TROEventRepository Class Properties

Properties

 Message

Specifies the message format used to encode event data.

This must match the message format used on the client-side TROEventReceiver.

 SessionManager

Specifies the session manager that maintains the server's user sessions.

RemObjects SDK events are tied to user sessions. Fired events are stored in the session until delivered to clients, while undelivered events expire and are discarded when the session expires.

As such, every Event Repository must have a session manager assigned, to function.


Legend

Property


Legend

Legend

Property


TROEventRepository Class Members

Members

Properties

 Message

Specifies the message format used to encode event data.

This must match the message format used on the client-side TROEventReceiver.

 SessionManager

Specifies the session manager that maintains the server's user sessions.

RemObjects SDK events are tied to user sessions. Fired events are stored in the session until delivered to clients, while undelivered events expire and are discarded when the session expires.

As such, every Event Repository must have a session manager assigned, to function.


Legend

Property


See Also

Event Sinks and Server Callbacks help topics


TROEventRepository.Message Property

Specifies the message format used to encode event data.

This must match the message format used on the client-side TROEventReceiver.

See Also

TROMessage and TROEventReceiver classes

Messages help topic

Pascal

property Message: TROMessage;


See Also

TROMessage and TROEventReceiver classes

Messages help topic


TROEventRepository.SessionManager Property

Specifies the session manager that maintains the server's user sessions.

RemObjects SDK events are tied to user sessions. Fired events are stored in the session until delivered to clients, while undelivered events expire and are discarded when the session expires.

As such, every Event Repository must have a session manager assigned, to function.

See Also

TROCustomSessionManager class

Session Management help topic

Pascal

property SessionManager: TROCustomSessionManager;


See Also

TROCustomSessionManager class

Session Management help topic


TROEventSessionManager Class

TROEventSessionManager implements a session manager that uses events to allow the use of custom code to access and store session data in user-defined ways.

Whenever the session manager needs to access or update session data, an event is fired.

Essential Events

OnFindSession, OnReleaseSession, OnDeleteSession events are fired to access and store session data. These three events must be assigned for the session manager to be functional.

Relevant Properties

SessionDuration specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes)

MaxSessions specifies the maximum number of sessions that will be allowed

Class Hierarchy

File

uROSessions

See Also

TROCustomSessionManager, TRODBSessionManager, TROInMemorySessionManager and TROMasterServerSessionManager classes

Session Management and Statelessness help topics

Event-Driven Session Manager help topic

Pascal

TROEventSessionManager = class(TROCustomSessionManager);


TROEventSessionManager Class Properties

Properties

 Clearing

 Critical

 MaxSessions

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

TROEventSessionManager Class

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.


Legend

Property

protected

read only


TROEventSessionManager Class Methods

Methods

 CheckSessionIsExpired

 ClearSessions

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

 CreateSession

 DeleteSession

 GetAllSessions

Returns a string list containing the IDs of all currently active sessions.

 GetSessionCount

 ReleaseSession


Legend

Method


TROEventSessionManager Class Events

Events

TROEventSessionManager Class

 OnClearSessions

This event is fired when the session storage should be cleared.

Depending on the value of the OnlyExpired parameter, the event handler should either clear the entire session list (on false), or only remove those sessions that have expired (on true).

 OnDeleteSession

This event is fired when a specific session should be deleted, either because it has expired or it has explicitly been destroyed. It is up the the event handler to remove the session from storage.

 OnFindSession

This event is fired when session data for a specific session is needed. It is up to the event handler to obtain this data from storage or create a new session, if necessary.

 OnGetAllSessions

This event is fired to obtain a list of all available session IDs, when GetAllSessions is called.

 OnGetSessionCount

This event is fired to obtain the total number of sessions available.

 OnReleaseSession

This event is fired when a specific session is released. It is up to the event handler to store the data so that future calls to OnFindSession can access it.


Legend

Event


Legend

Legend

Property

protected

read only

Method

Event


TROEventSessionManager Class Members

Members

Properties

 Clearing

 Critical

 MaxSessions

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

TROEventSessionManager Class

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

Methods

 CheckSessionIsExpired

 ClearSessions

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

 CreateSession

 DeleteSession

 GetAllSessions

Returns a string list containing the IDs of all currently active sessions.

 GetSessionCount

 ReleaseSession

Events

TROEventSessionManager Class

 OnClearSessions

This event is fired when the session storage should be cleared.

Depending on the value of the OnlyExpired parameter, the event handler should either clear the entire session list (on false), or only remove those sessions that have expired (on true).

 OnDeleteSession

This event is fired when a specific session should be deleted, either because it has expired or it has explicitly been destroyed. It is up the the event handler to remove the session from storage.

 OnFindSession

This event is fired when session data for a specific session is needed. It is up to the event handler to obtain this data from storage or create a new session, if necessary.

 OnGetAllSessions

This event is fired to obtain a list of all available session IDs, when GetAllSessions is called.

 OnGetSessionCount

This event is fired to obtain the total number of sessions available.

 OnReleaseSession

This event is fired when a specific session is released. It is up to the event handler to store the data so that future calls to OnFindSession can access it.


Legend

Property

protected

read only

Method

Event


See Also

TROCustomSessionManager, TRODBSessionManager, TROInMemorySessionManager and TROMasterServerSessionManager classes

Session Management and Statelessness help topics

Event-Driven Session Manager help topic


TROEventSessionManager.OnClearSessions Event

This event is fired when the session storage should be cleared.

Depending on the value of the OnlyExpired parameter, the event handler should either clear the entire session list (on false), or only remove those sessions that have expired (on true).

See Also

ClearSessions method

SessionDuration property

Pascal

property OnClearSessions: TClearSessionsEvent;


See Also

ClearSessions method

SessionDuration property


TROEventSessionManager.OnDeleteSession Event

This event is fired when a specific session should be deleted, either because it has expired or it has explicitly been destroyed. It is up the the event handler to remove the session from storage.

See Also

OnFindSession and OnReleaseSession events

Pascal

property OnDeleteSession: TDeleteSessionEvent;


See Also

OnFindSession and OnReleaseSession events


TROEventSessionManager.OnFindSession Event

This event is fired when session data for a specific session is needed. It is up to the event handler to obtain this data from storage or create a new session, if necessary.

See Also

OnReleaseSession and OnDeleteSession events

Pascal

property OnFindSession: TFindSessionEvent;


See Also

OnReleaseSession and OnDeleteSession events


TROEventSessionManager.OnGetAllSessions Event

This event is fired to obtain a list of all available session IDs, when GetAllSessions is called.

See Also

GetAllSessions method

Pascal

property OnGetAllSessions: TGetAllSessionsEvent;


See Also

GetAllSessions method


TROEventSessionManager.OnGetSessionCount Event

This event is fired to obtain the total number of sessions available.

Pascal

property OnGetSessionCount: TGetSessionCountEvent;


TROEventSessionManager.OnReleaseSession Event

This event is fired when a specific session is released. It is up to the event handler to store the data so that future calls to OnFindSession can access it.

See Also

OnFindSession and OnDeleteSession events

Pascal

property OnReleaseSession: TReleaseSessionEvent;


See Also

OnFindSession and OnDeleteSession events


TROEventSessionManager.SessionDuration Property

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

Notes

Note that the exact handling of the timeout processing depends on the implementation of the specific session manager, which might check session timeouts at intervals. Therefore, sessions might live slightly longer then the specified timeout.

See Also

ClearSessions method

Pascal

property SessionDuration: integer;


See Also

ClearSessions method


TROIndyHTTPChannel Class

TROIndyHTTPChannel implements an HTTP based channel that uses the HTTP implementation provided by the open source Indy components that ship with Delphi.

Essential Properties

TargetURL specifies the address of the server to talk to.

Class Hierarchy

Notes

Due to a bug in Indy, the Indy HTTP and TCP Channels cannot be used inside the IDE at design time. If you need to use your channels a design time, for example in combination with Data Abstract to receive schema information or live data preview, we recommend using one of the other channels such as the TROWinInetHTTPChannel.

File

uROIndyHTTPChannel

See Also

Channels and HTTP Channels help topics

TROWinInetHTTPChannel and TROSynapseHTTPChannel components

Pascal

TROIndyHTTPChannel = class(TROCustomIndyTCPChannel, IROTransport, IROTCPTransport, IROHTTPTransport);


TROIndyHTTPChannel Class Properties

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomIndyTCPChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROIndyHTTPChannel Class

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 TargetURL

Specifies the address of the server to talk to.

By default, this is usually he host name of your server, followed by the 8099, plus the name of the dispatcher configured on the server; for example http://myserver:8099/bin.


Legend

Property

read only


TROIndyHTTPChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROCustomIndyTCPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROIndyHTTPChannel Class Members

Members

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomIndyTCPChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROIndyHTTPChannel Class

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 TargetURL

Specifies the address of the server to talk to.

By default, this is usually he host name of your server, followed by the 8099, plus the name of the dispatcher configured on the server; for example http://myserver:8099/bin.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROCustomIndyTCPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels and HTTP Channels help topics

TROWinInetHTTPChannel and TROSynapseHTTPChannel components


TROIndyHTTPChannel.IndyClient Property

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

See Also

Indy documentation

Pascal

property IndyClient: TIdHTTP;


See Also

Indy documentation


TROIndyHTTPChannel.KeepAlive Property

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

Notes

For Keep-Alive to work, the option must be supported and enabled on both client and server.

See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties

Pascal

property KeepAlive: boolean;


See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties


TROIndyHTTPChannel.TargetURL Property

Specifies the address of the server to talk to.

By default, this is usually he host name of your server, followed by the 8099, plus the name of the dispatcher configured on the server; for example http://myserver:8099/bin.

Pascal

property TargetURL: string;


TROIndyHTTPServer Class

TROIndyHTTPServer implements an HTTP based server that uses the HTTP implementation provided by the open source Indy components that ship with Delphi.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients or not

Dispatchers specifies how incoming requests will be processed and dispatched

Relevant Properties

Port specifies the network socket that the server will be listening to (default is 8099)

Class Hierarchy

File

uROIndyHTTPServer

See Also

Channels and HTTP Channels help topics

TROBPDXHTTPServer and TROWebBrokerServer components

Pascal

TROIndyHTTPServer = class(TROCustomIndyTCPServer);


TROIndyHTTPServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomIndyTCPServer Class

 IndyServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

TROIndyHTTPServer Class

 IndyServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK HTTP servers is 8099).

 SendExceptionsAs500

Specifies whether exception messages will be sent back using a HTTP "500" error code (true, default), or a standard "200" message code (false).

 ServeInfoPage

Specifies whether the HTTP server will serve up a page with human-readable information about the server when being accessed from a web browser. This information page will contain details about the registered dispatchers and the documentation for the services.

 ServeRodl

Specifies whether the HTTP server will make the contained RODL file available to clients (true, default) or not.

Keep this property set to true if clients need to access the RODL (ore WSDL), for example so that third parties (including Service Tester) can import services. Set it to false if you do not want to provide this information, for example for security reasons.


Legend

Property

read only


TROIndyHTTPServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

read only

Event


TROIndyHTTPServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomIndyTCPServer Class

 IndyServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

TROIndyHTTPServer Class

 IndyServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK HTTP servers is 8099).

 SendExceptionsAs500

Specifies whether exception messages will be sent back using a HTTP "500" error code (true, default), or a standard "200" message code (false).

 ServeInfoPage

Specifies whether the HTTP server will serve up a page with human-readable information about the server when being accessed from a web browser. This information page will contain details about the registered dispatchers and the documentation for the services.

 ServeRodl

Specifies whether the HTTP server will make the contained RODL file available to clients (true, default) or not.

Keep this property set to true if clients need to access the RODL (ore WSDL), for example so that third parties (including Service Tester) can import services. Set it to false if you do not want to provide this information, for example for security reasons.

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

read only

Event


See Also

Channels and HTTP Channels help topics

TROBPDXHTTPServer and TROWebBrokerServer components


TROIndyHTTPServer.IndyServer Property

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

See Also

Indy documentation

Pascal

property IndyServer: TROIdHTTPServer;


See Also

Indy documentation


TROIndyHTTPServer.KeepAlive Property

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

Notes

For Keep-Alive to work, the option must be supported and enabled on both client and server.

See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties

Pascal

property KeepAlive: boolean;


See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties


TROIndyHTTPServer.Port Property

Specifies the network socket that the server will be listening on (default for RemObjects SDK HTTP servers is 8099).

Pascal

property Port: Integer;


TROIndyHTTPServer.SendExceptionsAs500 Property

Specifies whether exception messages will be sent back using a HTTP "500" error code (true, default), or a standard "200" message code (false).

Use Case

Some proxy servers might perform special handling on 500 error messages that will prevent exception messages sent back as 500 to be recognized properly. If you are seeing this problem, try setting this property to false. If not, it is recommended to keep the default value.

Pascal

property SendExceptionsAs500: boolean;


TROIndyHTTPServer.ServeInfoPage Property

Specifies whether the HTTP server will serve up a page with human-readable information about the server when being accessed from a web browser. This information page will contain details about the registered dispatchers and the documentation for the services.

Pascal

property ServeInfoPage: Boolean;


TROIndyHTTPServer.ServeRodl Property

Specifies whether the HTTP server will make the contained RODL file available to clients (true, default) or not.

Keep this property set to true if clients need to access the RODL (ore WSDL), for example so that third parties (including Service Tester) can import services. Set it to false if you do not want to provide this information, for example for security reasons.

See Also

RODL Files and Service Tester help topics

Pascal

property ServeRodl: Boolean;


See Also

RODL Files and Service Tester help topics


TROIndyTCPChannel Class

TROIndyTCPChannel implements a TCP based channel that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Essential Properties

Host specifies address of the server to talk to.

Port specifies the port number the server is listening on.

Class Hierarchy

Notes

Due to a bug in Indy, the Indy HTTP and TCP Channels cannot be used inside the IDE at design time.

If you need to use your channels at design time, for example in combination with Data Abstract to receive schema information or live data preview, we recommend using one of the other channels such as the TROWinInetHTTPChannel.

File

uROIndyTCPChannel

See Also

Channels and Legacy TCP Channels help topics

Pascal

TROIndyTCPChannel = class(TROCustomIndyTCPChannel, IROTransport, IROTCPTransport);


TROIndyTCPChannel Class Properties

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomIndyTCPChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROIndyTCPChannel Class

 DisableNagle

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).


Legend

Property

read only


TROIndyTCPChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROCustomIndyTCPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROIndyTCPChannel Class Members

Members

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomIndyTCPChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROIndyTCPChannel Class

 DisableNagle

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROCustomIndyTCPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels and Legacy TCP Channels help topics


TROIndyTCPChannel.DisableNagle Property

property DisableNagle;


TROIndyTCPChannel.Host Property

Specifies the address of the server to talk to. This can be a host name or an IP address.

Pascal

property Host: string;


TROIndyTCPChannel.IndyClient Property

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

See Also

Indy documentation

Pascal

property IndyClient: TIdTCPClientBaseClass;


See Also

Indy documentation


TROIndyTCPChannel.KeepAlive Property

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

Notes

For Keep-Alive to work, the option must be supported and enabled on both client and server.

See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties

Pascal

property KeepAlive: boolean;


See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties


TROIndyTCPChannel.Port Property

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

Pascal

property Port: integer;


TROIndyTCPServer Class

TROIndyHTTPServer implements a TCP based server that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

Relevant Properties

Port specifies the network socket that the server will be listening on (default is 8090).

Class Hierarchy

File

uROIndyTCPServer

See Also

Channels and Legacy TCP Channels help topics

TROBPDXTCPServer component

Pascal

TROIndyTCPServer = class(TROCustomIndyTCPServer, IROTransport);


TROIndyTCPServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomIndyTCPServer Class

 IndyServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

TROIndyTCPServer Class

 DisableNagle

 IndyServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).


Legend

Property

read only


TROIndyTCPServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

read only

Event


TROIndyTCPServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomIndyTCPServer Class

 IndyServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

TROIndyTCPServer Class

 DisableNagle

 IndyServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

read only

Event


See Also

Channels and Legacy TCP Channels help topics

TROBPDXTCPServer component


TROIndyTCPServer.DisableNagle Property

property DisableNagle;


TROIndyTCPServer.IndyServer Property

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

See Also

Indy documentation

Pascal

property IndyServer: TROTIdTCPServer;


See Also

Indy documentation


TROIndyTCPServer.KeepAlive Property

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

Notes

For Keep-Alive to work, the option must be supported and enabled on both client and server.

See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties

Pascal

property KeepAlive: boolean;


See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties


TROIndyTCPServer.Port Property

Specifies the network socket that the server will be listening on (default for RemObjects SDK TCP servers is 8090).

Pascal

property Port: Integer;


TROIndyUDPChannel Class

TROIndyUDPChannel implements a UDP based channel that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Essential Properties

Host specifies address of the server to talk to.

Port specifies the port number the server is listening on.

Class Hierarchy

Notes

Due to a bug in Indy, the Indy HTTP, TCP and UDP Channels can not be used inside the IDE at design time.

If you need to use your channels a design time, for example in combination with Data Abstract to receive schema information or live data preview, we recommend using one of the other channels such as the TROWinInetHTTPChannel.

File

uROIndyUDPChannel

See Also

Channels and UDP and Broadcast Channels help topics

Pascal

TROIndyUDPChannel = class(TROTransportChannel, IROTransport, IROTCPTransport, IROAsyncTransportChannel, IROAsyncResponseStorage);


TROIndyUDPChannel Class Properties

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROIndyUDPChannel Class

 AsyncTimeOut

Specifies the timeout for waiting for an asynchronous response from the server, in milliseconds. The default value is 1000 (1 second).

If no response is received from the server after the given timeout, the OnAsyncResponseTimeout event will fire. Due to the nature of asynchronous calls, no exception will be raised.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.


Legend

Property

read only


TROIndyUDPChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROIndyUDPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnAsyncResponseTimeOut

Fires if no response for an asynchronous call is received within the timeframe specified by the AsyncTimeOut property.

Due to the nature of asynchronous calls, no exception will be raised.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


TROIndyUDPChannel Class Methods

Methods

TROIndyUDPChannel Class

 GetResponseByUID

Returns the response for the specified ID.

This method can be used by the Broadcast Channel to access the different responses that might be received from all the servers reacting on a broadcast request.


Legend

Method


Legend

Legend

Property

read only

Event

Method


TROIndyUDPChannel Class Members

Members

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROIndyUDPChannel Class

 AsyncTimeOut

Specifies the timeout for waiting for an asynchronous response from the server, in milliseconds. The default value is 1000 (1 second).

If no response is received from the server after the given timeout, the OnAsyncResponseTimeout event will fire. Due to the nature of asynchronous calls, no exception will be raised.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

Specifies the address of the server to talk to. This can be a host name or an IP address.

 IndyClient

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 Port

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROIndyUDPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnAsyncResponseTimeOut

Fires if no response for an asynchronous call is received within the timeframe specified by the AsyncTimeOut property.

Due to the nature of asynchronous calls, no exception will be raised.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

Methods

TROIndyUDPChannel Class

 GetResponseByUID

Returns the response for the specified ID.

This method can be used by the Broadcast Channel to access the different responses that might be received from all the servers reacting on a broadcast request.


Legend

Property

read only

Event

Method


See Also

Channels and UDP and Broadcast Channels help topics


TROIndyUDPChannel.AsyncTimeOut Property

Specifies the timeout for waiting for an asynchronous response from the server, in milliseconds. The default value is 1000 (1 second).

If no response is received from the server after the given timeout, the OnAsyncResponseTimeout event will fire. Due to the nature of asynchronous calls, no exception will be raised.

See Also

OnAsyncResponseTimeout event

Asynchronous Calls help topic

Pascal

property AsyncTimeOut: Integer;


See Also

OnAsyncResponseTimeout event

Asynchronous Calls help topic


TROIndyUDPChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TROIndyUDPChannel.Host Property

Specifies the address of the server to talk to. This can be a host name or an IP address.

Pascal

property Host: string;


TROIndyUDPChannel.IndyClient Property

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

See Also

Indy documentation

Pascal

property IndyClient: TIdUDPClient;


See Also

Indy documentation


TROIndyUDPChannel.OnAfterProbingServer Event

Fires after the channel is done probing a specific server for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServer: TROEndProbeServerEvent;


See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROIndyUDPChannel.OnAfterProbingServers Event

Fires after the channel is done probing all servers for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServers: TROEndProbeServersEvent;


See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROIndyUDPChannel.OnAsyncResponseTimeOut Event

Fires if no response for an asynchronous call is received within the timeframe specified by the AsyncTimeOut property.

Due to the nature of asynchronous calls, no exception will be raised.

See Also

OnAsyncResponseTimeout event

Asynchronous Calls help topic

Pascal

property OnAsyncResponseTimeOut: TROAsyncTimeOutEvent;


See Also

OnAsyncResponseTimeout event

Asynchronous Calls help topic


TROIndyUDPChannel.OnBeforeProbingServer Event

Fires before the channel starts probing a specific server for availability.

Use Case

You can use this event to check or adjust the server configuration, or to include/exclude the server from being probed by changing the TROServerLocator.Enabled property.

See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServer: TROBeginProbeServerEvent;


See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROIndyUDPChannel.OnBeforeProbingServers Event

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServers: TROBeginProbeServersEvent;


See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROIndyUDPChannel.OnLoginNeeded Event

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

Use Case

The most common use for this event is to perform a call to a special Login service provided by the server (possibly after prompting the user to enter username ad password), and to set the aRetry parameter to true if login was successful.

See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic

Pascal

property OnLoginNeeded: TROExceptionEvent;


See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic


TROIndyUDPChannel.OnReceiveStream Event

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnReceiveStream: TStreamDispatch;


See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROIndyUDPChannel.OnSendStream Event

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnSendStream: TStreamDispatch;


See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROIndyUDPChannel.Port Property

Specifies the port number the server is listening on (default for RemObjects SDK TCP servers is 8090).

Pascal

property Port: integer;


TROIndyUDPChannel.ProbeFrequency Property

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

Notes

Although somewhat misnamed, this property defines the Interval between probes, not the actual probing Frequency. The property name is persisted for backward compatibility, we apologize.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeFrequency: cardinal;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROIndyUDPChannel.ProbeServers Property

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeServers: boolean;


See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROIndyUDPChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TROIndyUDPChannel.SynchronizedProbing Property

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property SynchronizedProbing: Boolean;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROIndyUDPChannel.GetResponseByUID Method

Returns the response for the specified ID.

This method can be used by the Broadcast Channel to access the different responses that might be received from all the servers reacting on a broadcast request.

See Also

TROBroadcastChannel component

TROBroadcastChannel.OnBroadcastResponseReceived event

UDP and Broadcast Channels

Pascal

function GetResponseByUID(aUID: String): TROResponseItem;


See Also

TROBroadcastChannel component

TROBroadcastChannel.OnBroadcastResponseReceived event

UDP and Broadcast Channels


TROIndyUDPServer Class

TROIndyHTTPServer implements a UDP based server that uses the socket implementation provided by the open source Indy components that ship with Delphi.

Essential Properties 	Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

Relevant Properties

Port specifies the network socket that the server will be listening on (default is 8090).

Class Hierarchy

File

uROIndyUDPServer

See Also

Channels and UDP and Broadcast Channels help topics

Pascal

TROIndyUDPServer = class(TROServer, IROTransport);


TROIndyUDPServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROIndyUDPServer Class

 IndyUDPServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK UDP servers is 8090).


Legend

Property

read only


TROIndyUDPServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

read only

Event


TROIndyUDPServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROIndyUDPServer Class

 IndyUDPServer

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 Port

Specifies the network socket that the server will be listening on (default for RemObjects SDK UDP servers is 8090).

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

read only

Event


See Also

Channels and UDP and Broadcast Channels help topics


TROIndyUDPServer.IndyUDPServer Property

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

See Also

Indy documentation

Pascal

property IndyUDPServer: TXPIdUDPServer;


See Also

Indy documentation


TROIndyUDPServer.Port Property

Specifies the network socket that the server will be listening on (default for RemObjects SDK UDP servers is 8090).

Pascal

property Port: integer;


TROInMemoryEventRepository Class

TROInMemoryEventRepository implements an event repository that stores event data in local memory.

Essential Events

Message specifies the message format used to encode event data.

SessionManager specifies the session manager that maintains the the server's user sessions.

Class Hierarchy

File

uROEventRepository

See Also

Event Sinks and Server Callbacks help topics

Pascal

TROInMemoryEventRepository = class(TROEventRepository, IROSessionsChangesListener);


TROInMemoryEventRepository Class Properties

Properties

 Message

Specifies the message format used to encode event data.

This must match the message format used on the client-side TROEventReceiver.

 SessionManager

Specifies the session manager that maintains the server's user sessions.

RemObjects SDK events are tied to user sessions. Fired events are stored in the session until delivered to clients, while undelivered events expire and are discarded when the session expires.

As such, every Event Repository must have a session manager assigned, to function.


Legend

Property


Legend

Legend

Property


TROInMemoryEventRepository Class Members

Members

Properties

 Message

Specifies the message format used to encode event data.

This must match the message format used on the client-side TROEventReceiver.

 SessionManager

Specifies the session manager that maintains the server's user sessions.

RemObjects SDK events are tied to user sessions. Fired events are stored in the session until delivered to clients, while undelivered events expire and are discarded when the session expires.

As such, every Event Repository must have a session manager assigned, to function.


Legend

Property


See Also

Event Sinks and Server Callbacks help topics


TROInMemorySessionManager Class

TROInMemorySessionManager implements a session manager that stores session data in local memory.

Essential Proeprties

None; the in-memory session manager is usable with default settings.

Class Hierarchy

File

uROSessions

See Also

TROCustomSessionManager, TRODBSessionManager, TROEventSessionManager and TROMasterServerSessionManager classes

Session Management and Statelessness help topics

Pascal

TROInMemorySessionManager = class(TROCustomSessionManager);


TROInMemorySessionManager Class Properties

Properties

 Clearing

 Critical

 MaxSessions

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

TROInMemorySessionManager Class

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.


Legend

Property

protected

read only


TROInMemorySessionManager Class Methods

Methods

 CheckSessionIsExpired

 ClearSessions

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

 CreateSession

 DeleteSession

 GetAllSessions

Returns a string list containing the IDs of all currently active sessions.

 GetSessionCount

 ReleaseSession


Legend

Method


Legend

Legend

Property

protected

read only

Method


TROInMemorySessionManager Class Members

Members

Properties

 Clearing

 Critical

 MaxSessions

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

TROInMemorySessionManager Class

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

Methods

 CheckSessionIsExpired

 ClearSessions

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

 CreateSession

 DeleteSession

 GetAllSessions

Returns a string list containing the IDs of all currently active sessions.

 GetSessionCount

 ReleaseSession


Legend

Property

protected

read only

Method


See Also

TROCustomSessionManager, TRODBSessionManager, TROEventSessionManager and TROMasterServerSessionManager classes

Session Management and Statelessness help topics


TROInMemorySessionManager.SessionDuration Property

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

Notes

Note that the exact handling of the timeout processing depends on the implementation of the specific session manager, which might check session timeouts at intervals. Therefore, sessions might live slightly longer then the specified timeout.

See Also

ClearSessions method

Pascal

property SessionDuration: integer;


See Also

ClearSessions method


TROLocalChannel Class

TROLocalChannel implements a channel that talks to services in the same executable via a TROLocalServer.

This channel is helpful when creating a single-tier version of an existing client/server application, and you want to combine client and server logic in the same executable and avoid the overhead of a "real" communication channel between client and server.

Essential Properties

ServerChannel specifies the local server to talk to.

Class Hierarchy

File

uROLocalChannel

See Also

TROLocalServer component

Channels and Local Channels help topics

Pascal

TROLocalChannel = class(TROTransportChannel);


TROLocalChannel Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROLocalChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ServerChannel

Specifies the local server to talk to.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.


Legend

Property

read only


TROLocalChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROLocalChannel Class

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROLocalChannel Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROLocalChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ServerChannel

Specifies the local server to talk to.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROLocalChannel Class

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

TROLocalServer component

Channels and Local Channels help topics


TROLocalChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TROLocalChannel.OnLoginNeeded Event

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

Use Case

The most common use for this event is to perform a call to a special Login service provided by the server (possibly after prompting the user to enter username ad password), and to set the aRetry parameter to true if login was successful.

See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic

Pascal

property OnLoginNeeded: TROExceptionEvent;


See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic


TROLocalChannel.OnReceiveStream Event

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnReceiveStream: TStreamDispatch;


See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROLocalChannel.OnSendStream Event

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnSendStream: TStreamDispatch;


See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROLocalChannel.ServerChannel Property

Specifies the local server to talk to.

See Also

TROLocalServer component

Pascal

property ServerChannel: TROLocalServer;


See Also

TROLocalServer component


TROLocalChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TROLocalServer Class

TROLocalServer implements a server that makes services available for consumption from within the same executable via a TROLocalChannel.

This channel is helpful when creating a single-tier version of an existing client/server application, and you want to combine client and server logic in the same executable and avoid the overhead of a "real" communication channel between client and server.

Essential Properties

None.

Class Hierarchy

File

uROLocalServer

See Also

TROLocalChannel component

Channels and Local Channels help topics

Pascal

TROLocalServer = class(TROServer, IROTransport);


TROLocalServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROLocalServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.


Legend

Property


TROLocalServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

Event


TROLocalServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROLocalServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

Event


See Also

TROLocalChannel component

Channels and Local Channels help topics


TROLocalServer.Active Property

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

Pascal

property Active: boolean;


TROMasterServerEventRepository Class

TROMasterServerEventRepository implements an event repository that uses the Master Server back-end to store event data.

Essential Events

Message specifies the message format used to encode event data.

SessionManager specifies the session manager that maintains the the server's user sessions.

Channel specifies the channel component to be used to communicate with the Master Server.

Class Hierarchy

File

uROMasterServerEventRepository

See Also

Event Sinks and Server Callbacks help topics

Master Server help topic

Pascal

TROMasterServerEventRepository = class(TROEventRepository);


TROMasterServerEventRepository Class Properties

Properties

 Message

Specifies the message format used to encode event data.

This must match the message format used on the client-side TROEventReceiver.

 SessionManager

Specifies the session manager that maintains the server's user sessions.

RemObjects SDK events are tied to user sessions. Fired events are stored in the session until delivered to clients, while undelivered events expire and are discarded when the session expires.

As such, every Event Repository must have a session manager assigned, to function.

TROMasterServerEventRepository Class

 Channel

Specifies the channel component to be used to communicate with the Master Server , which can be running locally or on a remote system.

This must be a channel supported by the Master Server application; please refer to the Master Server help topics for more details.

 SessionManager

Specifies the session manager that maintains the server's user sessions.

RemObjects SDK events are tied to user sessions. Fired events are stored in the session until delivered to clients, while undelivered events expire and are discarded when the session expires.

As such, every Event Repository must have a session manager assigned, to function.


Legend

Property

read only


Legend

Legend

Property

read only


TROMasterServerEventRepository Class Members

Members

Properties

 Message

Specifies the message format used to encode event data.

This must match the message format used on the client-side TROEventReceiver.

 SessionManager

Specifies the session manager that maintains the server's user sessions.

RemObjects SDK events are tied to user sessions. Fired events are stored in the session until delivered to clients, while undelivered events expire and are discarded when the session expires.

As such, every Event Repository must have a session manager assigned, to function.

TROMasterServerEventRepository Class

 Channel

Specifies the channel component to be used to communicate with the Master Server , which can be running locally or on a remote system.

This must be a channel supported by the Master Server application; please refer to the Master Server help topics for more details.

 SessionManager

Specifies the session manager that maintains the server's user sessions.

RemObjects SDK events are tied to user sessions. Fired events are stored in the session until delivered to clients, while undelivered events expire and are discarded when the session expires.

As such, every Event Repository must have a session manager assigned, to function.


Legend

Property

read only


See Also

Event Sinks and Server Callbacks help topics

Master Server help topic


TROMasterServerEventRepository.Channel Property

Specifies the channel component to be used to communicate with the Master Server , which can be running locally or on a remote system.

This must be a channel supported by the Master Server application; please refer to the Master Server help topics for more details.

See Also

TROTransportChannel component

Master Server help topic

Pascal

property Channel: TROTransportChannel;


See Also

TROTransportChannel component

Master Server help topic


TROMasterServerEventRepository.SessionManager Property

Specifies the session manager that maintains the server's user sessions.

RemObjects SDK events are tied to user sessions. Fired events are stored in the session until delivered to clients, while undelivered events expire and are discarded when the session expires.

As such, every Event Repository must have a session manager assigned, to function.

See Also

TROCustomSessionManager class

Session Management help topic

Pascal

property SessionManager: IROSessionManager;


See Also

TROCustomSessionManager class

Session Management help topic


TROMasterServerSessionManager Class

TROMasterServerSessionManager implements a session manager that uses the Master Server back-end to store and access session data.

Essential Events

Channel specifies the channel component to be used to communicate with the Master Server

Class Hierarchy

Notes

The SessionDuration and MaxSessions properties off the base class will be ignored for the Master Server session manager, as these settings are configured within Master Server itself.

File

uROMasterServerSessionManager

See Also

TROCustomSessionManager, TRODBSessionManager, TROEventSessionManager and TROInMemorySessionManager classes

Session Management and Statelessness help topics

Master Server Session Manager help topic

Master Server help topic

Pascal

TROMasterServerSessionManager = class(TROCustomSessionManager);


TROMasterServerSessionManager Class Properties

Properties

 Clearing

 Critical

 MaxSessions

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

TROMasterServerSessionManager Class

 Channel

Specifies the channel component to be used to communicate with the Master Server , which can be running locally or on a remote system.

This must be a channel supported by the Master Server application; please refer to the Master Server help topics for more details.


Legend

Property

protected

read only


TROMasterServerSessionManager Class Methods

Methods

 CheckSessionIsExpired

 ClearSessions

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

 CreateSession

 DeleteSession

 GetAllSessions

Returns a string list containing the IDs of all currently active sessions.

 GetSessionCount

 ReleaseSession


Legend

Method


Legend

Legend

Property

protected

read only

Method


TROMasterServerSessionManager Class Members

Members

Properties

 Clearing

 Critical

 MaxSessions

Specifies the maximum number of sessions that will be allowed. -1 (the default) indicates that no limit on number of sessions will be enforced.

 SessionDuration

Specifies the time, in minutes, that sessions will persist before timing out (default is 15 minutes).

The timeout for each individual session will be reset every time the session is accessed; after SessionDuration minutes have passed without access to the session, it will be discarded.

TROMasterServerSessionManager Class

 Channel

Specifies the channel component to be used to communicate with the Master Server , which can be running locally or on a remote system.

This must be a channel supported by the Master Server application; please refer to the Master Server help topics for more details.

Methods

 CheckSessionIsExpired

 ClearSessions

Discards all sessions within the session manager, so that any new call from a client will start with a fresh session.

 CreateSession

 DeleteSession

 GetAllSessions

Returns a string list containing the IDs of all currently active sessions.

 GetSessionCount

 ReleaseSession


Legend

Property

protected

read only

Method


See Also

TROCustomSessionManager, TRODBSessionManager, TROEventSessionManager and TROInMemorySessionManager classes

Session Management and Statelessness help topics

Master Server Session Manager help topic

Master Server help topic


TROMasterServerSessionManager.Channel Property

Specifies the channel component to be used to communicate with the Master Server , which can be running locally or on a remote system.

This must be a channel supported by the Master Server application; please refer to the Master Server help topics for more details.

See Also

TROTransportChannel component

Master Server help topic

Pascal

property Channel: TROTransportChannel;


See Also

TROTransportChannel component

Master Server help topic


TROMessage Class

TROMessage is the base class for all message format components provided with the SDK.

You will usually not create instances of this class directly, but use the four descendant components, instead.

Essential Properties

None; message components are fully usable with their default settings.

Class Hierarchy

File

uROClient

See Also

TROBinMessage, TROPostMessage, TROSOAPMessage, TROXmlRpcMessage components

Messages help topic

Pascal

TROMessage = class(TROComponent, IUnknown, IROMessage, IROMessageCloneable, IROModuleInfo);


TROMessage Class Properties

Properties

 ClientID

Contains the Client ID for the message.

 InterfaceName

Contains the name of the interface (service) that this message is calling.

 MessageName

Contains the name of the method that this message is calling.


Legend

Property


TROMessage Class Events

Events

 OnFinalizeMessage

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

 OnInitializeMessage

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

 OnReadFromStream

Fires before the message is read from the stream that was received over the network.

 OnReadMessageParameter

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnServerException

Fires if an exception message is received from the server.

 OnWriteException

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

 OnWriteMessageParameter

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnWriteToStream

Fires after the message was written to the stream that will be sent over the network.


Legend

Event


Legend

Legend

Property

Event


TROMessage Class Members

Members

Properties

 ClientID

Contains the Client ID for the message.

 InterfaceName

Contains the name of the interface (service) that this message is calling.

 MessageName

Contains the name of the method that this message is calling.

Events

 OnFinalizeMessage

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

 OnInitializeMessage

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

 OnReadFromStream

Fires before the message is read from the stream that was received over the network.

 OnReadMessageParameter

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnServerException

Fires if an exception message is received from the server.

 OnWriteException

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

 OnWriteMessageParameter

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnWriteToStream

Fires after the message was written to the stream that will be sent over the network.


Legend

Property

Event


See Also

TROBinMessage, TROPostMessage, TROSOAPMessage, TROXmlRpcMessage components

Messages help topic


TROMessage.ClientID Property

Contains the Client ID for the message.

Use Case

Client IDs are used by the RemObjects SDK for session management and to uniquely identify individual clients on the server, for example by the Per-Client Class Factory or in your own custom code.

Generally, you will not need to assign or read this value; the framework will automatically create a new unique client ID whenever a Message object is instantiated on the client.

However, you do have the option to read and write the ClientID property manually, for example to persist a specific client ID between shutdown and restart of your application.

See Also

Session Management and Per-Client Class Factory help topics

TRORemoteDataModule.ClientID property

Pascal

property ClientID: TGuid;


See Also

Session Management and Per-Client Class Factory help topics

TRORemoteDataModule.ClientID property


TROMessage.InterfaceName Property

Contains the name of the interface (service) that this message is calling.

Use Case

This property is set by the RemObjects SDK framework, and you will not usually change it manually. However, you might want to evaluate it for logging purposes or security checks, in the events of TROTransportChannels or TROServers.

See Also

MessageName property

TROTransportChannel and TROServer components

Pascal

property InterfaceName: string;


See Also

MessageName property

TROTransportChannel and TROServer components


TROMessage.MessageName Property

Contains the name of the method that this message is calling.

Use Case

This property is set by the RemObjects SDK framework, and you will not usually change it manually. However, you might want to evaluate it for logging purposes or security checks, in the events of TROTransportChannels or TROServers.

See Also

InterfaceName property

TROTransportChannel and TROServer components

Pascal

property MessageName: string;


See Also

InterfaceName property

TROTransportChannel and TROServer components


TROMessage.OnFinalizeMessage Event

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

See Also

OnInitializeMessage event

Pascal

property OnFinalizeMessage: TROFinalizeMessageEvent;


See Also

OnInitializeMessage event


TROMessage.OnInitializeMessage Event

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

See Also

OnFinalizeMessage event

Pascal

property OnInitializeMessage: TROInitializeMessageEvent;


See Also

OnFinalizeMessage event


TROMessage.OnReadFromStream Event

Fires before the message is read from the stream that was received over the network.

Use Case

You can use this event to inspect the received stream, or to make manual modifications to it, for example to apply any custom decryption to the message stream before it is processed.

See Also

OnWriteStream event

TROServer.OnReadFromStream and TROTransportChannel.OnReceiveStream events

Pascal

property OnReadFromStream: TStreamOperation;


See Also

OnWriteStream event

TROServer.OnReadFromStream and TROTransportChannel.OnReceiveStream events


TROMessage.OnReadMessageParameter Event

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

Use Case

Use this event handler to inspect or log the parameters that are received. In theory, it is also possible to modify the value parameter using the DataRef pointer, but this should be done with extreme caution.

See Also

OnWriteMessageParameter and OnReadFromStream events

Pascal

property OnReadMessageParameter: TROReadMessageParameterEvent;


See Also

OnWriteMessageParameter and OnReadFromStream events


TROMessage.OnServerException Event

Fires if an exception message is received from the server.

Use Case

Use this event handler to provide a single point of interception to be notified of all exceptions raised on the server.

In contrast to the TROTransportChannel's OnException event, this event will not fire for communication errors or local exceptions during the processing of a request, but only for exceptions that truly originated on the server.

See Also

TROTransportChannel.OnException event

Pascal

property OnServerException: TROServerExceptionEvent;


See Also

TROTransportChannel.OnException event


TROMessage.OnWriteException Event

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

Use Case

You can use this event to inspect the exception message or the outgoing stream.

See Also

OnWriteToStream event

Pascal

property OnWriteException: TROWriteExceptionEvent;


See Also

OnWriteToStream event


TROMessage.OnWriteMessageParameter Event

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

Use Case

Use this event handler to inspect or log the parameters that are sent. In theory, it is also possible to modify the value parameter using the DataRef pointer, but this should be done with extreme caution.

See Also

OnReadMessageParameter and OnWriteToStream events

Pascal

property OnWriteMessageParameter: TROWriteMessageParameterEvent;


See Also

OnReadMessageParameter and OnWriteToStream events


TROMessage.OnWriteToStream Event

Fires after the message was written to the stream that will be sent over the network.

Use Case

You can use this event to inspect the outgoing stream, or to make manual modifications to it, for example to apply any custom encryption to the message stream before it is sent off.

See Also

OnReadFromStream event

TROServer.OnWriteToStream and TROTransportChannel.OnSendStream events

Pascal

property OnWriteToStream: TStreamOperation;


See Also

OnReadFromStream event

TROServer.OnWriteToStream and TROTransportChannel.OnSendStream events


TROMessageDispatcher Class

This class is used by the TROServer component to configure the list of dispatchers provided by the server.

You will usually not create instances of this class yourself, but work with them using the TROServer.Dispatchers collection property.

Essential Properties

Message specifies the message format to be used for this dispatcher.

Name specifies the name, or possibly the URL for the dispatcher.

Class Hierarchy

File

uROServer

See Also

TROServer.Dispatchers property

Pascal

TROMessageDispatcher = class(TCollectionItem);


TROMessageDispatcher Class Properties

Properties

 Enabled

Specifies whether the dispatcher is enabled (true) or not (false).

Only enabled dispatchers will be considered when processing requests from a client; a disabled dispatcher will behave as if it weren't defined at all.

 Message

Specifies the message format to be used for this dispatcher to decode and encode messages that are received from and sent to clients.

 Name

Specifies the name for the dispatcher.

In HTTP based servers, the Name will be appended as folder to the server URL, allowing the server to make multiple dispatchers available at different URLs.


Legend

Property


Legend

Legend

Property


TROMessageDispatcher Class Members

Members

Properties

 Enabled

Specifies whether the dispatcher is enabled (true) or not (false).

Only enabled dispatchers will be considered when processing requests from a client; a disabled dispatcher will behave as if it weren't defined at all.

 Message

Specifies the message format to be used for this dispatcher to decode and encode messages that are received from and sent to clients.

 Name

Specifies the name for the dispatcher.

In HTTP based servers, the Name will be appended as folder to the server URL, allowing the server to make multiple dispatchers available at different URLs.


Legend

Property


See Also

TROServer.Dispatchers property


TROMessageDispatcher.Enabled Property

Specifies whether the dispatcher is enabled (true) or not (false).

Only enabled dispatchers will be considered when processing requests from a client; a disabled dispatcher will behave as if it weren't defined at all.

Pascal

property Enabled: boolean;


TROMessageDispatcher.Message Property

Specifies the message format to be used for this dispatcher to decode and encode messages that are received from and sent to clients.

See Also

Messages help topic

Pascal

property Message: TROMessage;


See Also

Messages help topic


TROMessageDispatcher.Name Property

Specifies the name for the dispatcher.

In HTTP based servers, the Name will be appended as folder to the server URL, allowing the server to make multiple dispatchers available at different URLs.

See Also

TROIndyHTTPServer and TROBPDXHTTPServer classes

HTTP Channels help topic

Pascal

property Name: string;


See Also

TROIndyHTTPServer and TROBPDXHTTPServer classes

HTTP Channels help topic


TRONamedPipeChannel Class

TRONamedPipeChannel implements a channel that uses Windows Named Pipes to communicate between a client and a server on the same machine or local network.

Essential Properties

ServerID specifies the unique ID of the server to communicate with.

ServerName specifies the name of the host running the server.

Class Hierarchy

File

uRONamedPipeChannel

See Also

Channels and Named Pipe Channel help topics

Pascal

TRONamedPipeChannel = class(TROTransportChannel, IROTransport);


TRONamedPipeChannel Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TRONamedPipeChannel Class

 ActivateOnDemand

Specifies whether the channel may automatically open the named pipe to the server if needed (true, default) or not (false).

 Active

Gets or sets whether the named pipe to the server is currently active (true) or not (false).

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerID

Specifies the unique ID of the server to communicate with. This must match the ServerID specified on the TRONamedPipeServer in the server application.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerName

Specifies the name of the host running the server.

This can be a host name or IP address on the local net, or "." (default), which indicates the local machine.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.


Legend

Property

read only


TRONamedPipeChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TRONamedPipeChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TRONamedPipeChannel Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TRONamedPipeChannel Class

 ActivateOnDemand

Specifies whether the channel may automatically open the named pipe to the server if needed (true, default) or not (false).

 Active

Gets or sets whether the named pipe to the server is currently active (true) or not (false).

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerID

Specifies the unique ID of the server to communicate with. This must match the ServerID specified on the TRONamedPipeServer in the server application.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerName

Specifies the name of the host running the server.

This can be a host name or IP address on the local net, or "." (default), which indicates the local machine.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TRONamedPipeChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels and Named Pipe Channel help topics


TRONamedPipeChannel.ActivateOnDemand Property

Specifies whether the channel may automatically open the named pipe to the server if needed (true, default) or not (false).

See Also

Active property

Pascal

property ActivateOnDemand: Boolean;


See Also

Active property


TRONamedPipeChannel.Active Property

Gets or sets whether the named pipe to the server is currently active (true) or not (false).

See Also

ActivateOnDemand property

Pascal

property Active: Boolean;


See Also

ActivateOnDemand property


TRONamedPipeChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TRONamedPipeChannel.OnAfterProbingServer Event

Fires after the channel is done probing a specific server for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServer: TROEndProbeServerEvent;


See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TRONamedPipeChannel.OnAfterProbingServers Event

Fires after the channel is done probing all servers for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServers: TROEndProbeServersEvent;


See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TRONamedPipeChannel.OnBeforeProbingServer Event

Fires before the channel starts probing a specific server for availability.

Use Case

You can use this event to check or adjust the server configuration, or to include/exclude the server from being probed by changing the TROServerLocator.Enabled property.

See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServer: TROBeginProbeServerEvent;


See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TRONamedPipeChannel.OnBeforeProbingServers Event

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServers: TROBeginProbeServersEvent;


See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TRONamedPipeChannel.OnLoginNeeded Event

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

Use Case

The most common use for this event is to perform a call to a special Login service provided by the server (possibly after prompting the user to enter username ad password), and to set the aRetry parameter to true if login was successful.

See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic

Pascal

property OnLoginNeeded: TROExceptionEvent;


See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic


TRONamedPipeChannel.OnReceiveStream Event

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnReceiveStream: TStreamDispatch;


See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TRONamedPipeChannel.OnSendStream Event

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnSendStream: TStreamDispatch;


See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TRONamedPipeChannel.ProbeFrequency Property

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

Notes

Although somewhat misnamed, this property defines the Interval between probes, not the actual probing Frequency. The property name is persisted for backward compatibility, we apologize.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeFrequency: cardinal;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TRONamedPipeChannel.ProbeServers Property

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeServers: boolean;


See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TRONamedPipeChannel.ServerID Property

Specifies the unique ID of the server to communicate with. This must match the ServerID specified on the TRONamedPipeServer in the server application.

See Also

ServerName property

TRONamedPipeServer.ServerID property

Pascal

property ServerID: string;


See Also

ServerName property

TRONamedPipeServer.ServerID property


TRONamedPipeChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TRONamedPipeChannel.ServerName Property

Specifies the name of the host running the server.

This can be a host name or IP address on the local net, or "." (default), which indicates the local machine.

See Also

ServerID property

Pascal

property ServerName: string;


See Also

ServerID property


TRONamedPipeChannel.SynchronizedProbing Property

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property SynchronizedProbing: Boolean;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TRONamedPipeServer Class

TRONamedPipeServer implements a server that is accessible from clients on the same machine or local network using Windows Named Pipes.

Essential Properties

ServerID specifies the unique ID of the server to communicate with.

Class Hierarchy

File

uRONamedPipeServer

See Also

Channels and Named Pipe Channel help topics

Pascal

TRONamedPipeServer = class(TROServer, IROTransport);


TRONamedPipeServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TRONamedPipeServer Class

 AllowEveryone

Specifies whether access to the server will be granted to the virtual "Everyone" windows user, basically opening the server up to unauthorized access from any client in the network.

 ServerID

Specifies the unique ID of the server. This ID will be used by the client to uniquely identify the server among the several servers that might be running on a given system.

This ID can be any string, for example a human-readable name or a GUID, but it must consist of characters that are valid for a Windows file name.


Legend

Property


TRONamedPipeServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

Event


TRONamedPipeServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TRONamedPipeServer Class

 AllowEveryone

Specifies whether access to the server will be granted to the virtual "Everyone" windows user, basically opening the server up to unauthorized access from any client in the network.

 ServerID

Specifies the unique ID of the server. This ID will be used by the client to uniquely identify the server among the several servers that might be running on a given system.

This ID can be any string, for example a human-readable name or a GUID, but it must consist of characters that are valid for a Windows file name.

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

Event


See Also

Channels and Named Pipe Channel help topics


TRONamedPipeServer.AllowEveryone Property

Specifies whether access to the server will be granted to the virtual "Everyone" windows user, basically opening the server up to unauthorized access from any client in the network.

Pascal

property AllowEveryone: Boolean;


TRONamedPipeServer.ServerID Property

Specifies the unique ID of the server. This ID will be used by the client to uniquely identify the server among the several servers that might be running on a given system.

This ID can be any string, for example a human-readable name or a GUID, but it must consist of characters that are valid for a Windows file name.

See Also

TRONamedPipeChannel.ServerID property

Pascal

property ServerID: string;


See Also

TRONamedPipeChannel.ServerID property


TROPerClientClassFactory Class

TROPerClientClassFactory provides a class factory that ties each service instance to a particular client.

Service instances will be associated with a client using the ClientID, and each request form the same client will be served by the same instance.

Use Case

Use this class factory if you need to persist per-client state between calls that cannot easily be stored in Session data instead.

For example, incremental data fetching in DataSnap expects the state of server-side datasets to remain the same between calls, so that data retrieval can continue where the last call left off.

Class Hierarchy

Notes

Note that using per-client instantiation runs contrary to basic principles for scalable server design, based on statelessness. It is urged that you strongly consider the advantages and disadvantages before choosing the Per-Client class factory over a solution using sessions. Please refer to the Statelessness help topic for more details.

File

uROClassFactories

See Also

TROClassFactory, TROPooledClassFactory, TROSingletonClassFactory and TROSynchronizedSingletonClassFactory classes

Class Factories and RODL Files help topics

Statelessness help topic

Pascal

TROPerClientClassFactory = class(TROClassFactory);


TROPerClientClassFactory Class Methods

Methods

 Create

Creates a new instance of the class factory

 CreateInstance

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

 ReleaseInstance

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.

TROPerClientClassFactory Class

 TimeoutSessions

Manually frees all instantiated per-client service instances, as if they had expired. All future requests will be served by newly created instances.


Legend

Constructor

protected

virtual


Legend

Legend

Constructor

protected

virtual


TROPerClientClassFactory Class Members

Members

Methods

 Create

Creates a new instance of the class factory

 CreateInstance

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

 ReleaseInstance

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.

TROPerClientClassFactory Class

 TimeoutSessions

Manually frees all instantiated per-client service instances, as if they had expired. All future requests will be served by newly created instances.


Legend

Constructor

protected

virtual


See Also

TROClassFactory, TROPooledClassFactory, TROSingletonClassFactory and TROSynchronizedSingletonClassFactory classes

Class Factories and RODL Files help topics

Statelessness help topic


TROPerClientClassFactory.TimeoutSessions Method

Manually frees all instantiated per-client service instances, as if they had expired. All future requests will be served by newly created instances.

Pascal

procedure TimeoutSessions;


TROPooledClassFactory Class

TROPooledClassFactory is a class factory that maintains a list of instances of server objects.

Rather than creating a separate instance for each call or always using the same instance, TROPooledClassFactory creates a predefined number of instances and returns the first one currently available to the caller.

You can control some aspects of class factory behavior via the TROPooledClassFactory.Create constructor.

Please refer to the Class Factories help topic for a more detailed discussion of available class factory types.

Class Hierarchy

File

uROClassFactories

See Also

TROPooledClassFactory.Create constructor

EROPoolNoFreeObjects exception

TROPoolBehavior enumeration

TROClassFactory, TROSingletonClassFactory, TROSynchronizedSingletonClassFactory and TROPerClientClassFactory classes

Class Factories help topic

Pascal

TROPooledClassFactory = class(TROClassFactory, IROPooledClassFactory);


TROPooledClassFactory Class Methods

Methods

 Create

Creates a new instance of the class factory

 CreateInstance

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

 ReleaseInstance

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.

TROPooledClassFactory Class

 ClearPool

Frees all objects in the pool.

As new requests come in, the pool is gradually rebuilt, similarly to when the pool is first created with aPreInitializePool = false.

Note that server objects that are currently serving a call will not be freed immediately, but will simply be removed from the pool. Once their calls have completed, they will be freed.

 Create

Creates a new instance of the pooled class factory for the specified service, and registers it so that the service is available to serve client requests.


Legend

Constructor

protected

virtual


Legend

Legend

Constructor

protected

virtual


TROPooledClassFactory Class Members

Members

Methods

 Create

Creates a new instance of the class factory

 CreateInstance

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

 ReleaseInstance

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.

TROPooledClassFactory Class

 ClearPool

Frees all objects in the pool.

As new requests come in, the pool is gradually rebuilt, similarly to when the pool is first created with aPreInitializePool = false.

Note that server objects that are currently serving a call will not be freed immediately, but will simply be removed from the pool. Once their calls have completed, they will be freed.

 Create

Creates a new instance of the pooled class factory for the specified service, and registers it so that the service is available to serve client requests.


Legend

Constructor

protected

virtual


See Also

TROPooledClassFactory.Create constructor

EROPoolNoFreeObjects exception

TROPoolBehavior enumeration

TROClassFactory, TROSingletonClassFactory, TROSynchronizedSingletonClassFactory and TROPerClientClassFactory classes

Class Factories help topic


TROPooledClassFactory.ClearPool Method

Frees all objects in the pool.

As new requests come in, the pool is gradually rebuilt, similarly to when the pool is first created with aPreInitializePool = false.

Note that server objects that are currently serving a call will not be freed immediately, but will simply be removed from the pool. Once their calls have completed, they will be freed.

See Also

TROPooledClassFactory.Create constructor

Pascal

procedure ClearPool;


See Also

TROPooledClassFactory.Create constructor


TROPooledClassFactory.Create Constructor

Creates a new instance of the pooled class factory for the specified service, and registers it so that the service is available to serve client requests.

Parameters

aPoolSize: Integer

Determines how many items will be kept in the pool.

aPoolBehavior: TROPoolBehavior = pbCreateAdditional

Determines what happens when a request comes in and all pooled items are busy serving a call. You can choose one of three TROPoolBehavior options.

aPreInitializePool: Boolean = false

Determines whether the instances for all slots of the pool are created at startup (true) or if the pool will be filled on demand (false).

For example, if you have a pool size of 10 and set this parameter to true, 10 server objects will be created immediately at startup. If you set it to false, the nth pooled object will not be created until the first time n simultaneous calls are processed.

In both cases, all pooled items are not freed, but kept in the pool until the class factory is destroyed or the ClearPool method is manually called.

See Also

Class Factories help topic

ClearPool method

TROPoolBehavior enumeration

Pascal

constructor Create(const anInterfaceName: string; aCreatorFunc: TRORemotableCreatorFunc; anInvokerClass: TROInvokerClass; aPoolSize: Integer; aPoolBehavior: TROPoolBehavior = pbCreateAdditional; aPreInitializePool: Boolean = false);


See Also

Class Factories help topic

ClearPool method

TROPoolBehavior enumeration


TROPostMessage Class

TROPostMessage implements message encoding using a simple text messaging format compatible with HTTP "Post" data.

Please refer to the PostMessage help topic for more details on this message format.

Essential Properties

None; The PostMessage component is usable after being dropped from the component palette.

Relevant Properties

BinaryType specifies what format will be used to encode binary data, Hex or Base64.

Class Hierarchy

File

uROPostMessage

See Also

Messages and XML-RPC Message help topics

Pascal

TROPostMessage = class(TROMessage);


TROPostMessage Class Properties

Properties

 ClientID

Contains the Client ID for the message.

 InterfaceName

Contains the name of the interface (service) that this message is calling.

 MessageName

Contains the name of the method that this message is calling.

TROPostMessage Class

 BinaryType

Specifies what format will be used to encode binary data, Hex or Base64.


Legend

Property


TROPostMessage Class Events

Events

 OnFinalizeMessage

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

 OnInitializeMessage

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

 OnReadFromStream

Fires before the message is read from the stream that was received over the network.

 OnReadMessageParameter

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnServerException

Fires if an exception message is received from the server.

 OnWriteException

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

 OnWriteMessageParameter

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnWriteToStream

Fires after the message was written to the stream that will be sent over the network.


Legend

Event


Legend

Legend

Property

Event


TROPostMessage Class Members

Members

Properties

 ClientID

Contains the Client ID for the message.

 InterfaceName

Contains the name of the interface (service) that this message is calling.

 MessageName

Contains the name of the method that this message is calling.

TROPostMessage Class

 BinaryType

Specifies what format will be used to encode binary data, Hex or Base64.

Events

 OnFinalizeMessage

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

 OnInitializeMessage

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

 OnReadFromStream

Fires before the message is read from the stream that was received over the network.

 OnReadMessageParameter

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnServerException

Fires if an exception message is received from the server.

 OnWriteException

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

 OnWriteMessageParameter

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnWriteToStream

Fires after the message was written to the stream that will be sent over the network.


Legend

Property

Event


See Also

Messages and XML-RPC Message help topics


TROPostMessage.BinaryType Property

Specifies what format will be used to encode binary data, Hex or Base64.

See Also

TROPostMessageBinaryType enum

Pascal

property BinaryType: TROPostMessageBinaryType;


See Also

TROPostMessageBinaryType enum


TROPoweredByRemObjectsButton Class

TROPoweredByButton is a visual component that shows an image button with the RemObjects SDK logo and the text "powered by RemObjects SDK". You can use it in your application's About box to let users know that your application was build with RO.

Clicking the button will open the RemObjects Software homepage (http://www.remobjects.com) in the user's default web browser.

Relevant Properties

The ApplicationType property toggles the display between the "Client" and "Server" logo:

Class Hierarchy

File

uROPoweredByRemObjectsButton

Pascal

TROPoweredByRemObjectsButton = class(TGraphicControl);


TROPoweredByRemObjectsButton Class Properties

Properties

 ApplicationType

Toggles the display between the "Client" and "Server" logo:

Client:

Server:


Legend

Property


Legend

Legend

Property


TROPoweredByRemObjectsButton Class Members

Members

Properties

 ApplicationType

Toggles the display between the "Client" and "Server" logo:

Client:

Server:


Legend

Property


TROPoweredByRemObjectsButton.ApplicationType Property

Toggles the display between the "Client" and "Server" logo:

Client:

Server:

Pascal

property ApplicationType: TROPoweredByType;


TROProxy Class

This class forms the base for proxy classes in the _Intf units generated from your RODL.

Use Case

You will usually not deal directly with classes of this type.

Class Hierarchy

File

uROClient

See Also

RODL Files help topics

Pascal

TROProxy = class(TInterfacedObject, IUnknown);


TROProxy Class Properties

Properties

 __InterfaceName

Contains the name of the interface (service) that this proxy is configured to talk to.

 __Message

Contains a reference to the Message component that this proxy is configured to use.

 __TransportChannel

Contains a reference to the Channel component that this proxy is configured to use to communicate with the server.


Legend

Property

read only


Legend

Legend

Property

read only


TROProxy Class Members

Members

Properties

 __InterfaceName

Contains the name of the interface (service) that this proxy is configured to talk to.

 __Message

Contains a reference to the Message component that this proxy is configured to use.

 __TransportChannel

Contains a reference to the Channel component that this proxy is configured to use to communicate with the server.


Legend

Property

read only


See Also

RODL Files help topics


TROProxy.__InterfaceName Property

Contains the name of the interface (service) that this proxy is configured to talk to.

Notes

This property is used by auto-generated code in your _Intf units; you will not usually access this property directly.

Pascal

property __InterfaceName: string;


TROProxy.__Message Property

Contains a reference to the Message component that this proxy is configured to use.

Notes

This property is used by auto-generated code in your _Intf units; you will not usually access this property directly.

Pascal

property __Message: IROMessage;


TROProxy.__TransportChannel Property

Contains a reference to the Channel component that this proxy is configured to use to communicate with the server.

Notes

This property is used by auto-generated code in your _Intf units; you will not usually access this property directly.

Pascal

property __TransportChannel: IROTransportChannel;


TRORemoteDataModule Class

TRORemoteDataModule is the default base class for implementing new services using the RemObjects SDK.

It descends from TDataModule and as such provides a design surface that you can use to drop non-visual components on at design time. You can also use the Object Inspector to change its published properties.

Essential properties

None; TRORemoteDataModule is usable with the default settings

Relevant Properties

RequiresSession specifies if an existing session is needed for this service to be accessible by clients.

SessionManager specifies the session manager component to be used by this service

When using event sinks, EventRepository specifies the repository to be used for dispatching and storing events fired by this service.

Relevant Methods

Synchronize allows you to defer execution of a method to the main VCL thread.

Class Hierarchy

File

uRORemoteDataModule

See Also

Session Management and Session Management in TRORemoteDataModule help topics

Login and Authentication help topic

Event Sinks and Server Callbacks help topic

Pascal

TRORemoteDataModule = class(TDataModule, IROObjectActivation, IRODispatchNotifier, IROServerEventsBroker, IInterface, IROObjectRetainer);


TRORemoteDataModule Class Properties

Properties

 ClientID

Contains the ID of the client that is executing the current request.

 EventRepository

Specifies the repository to be used for dispatching and storing events that might be fired by this service.

 NewSession

Returns whether the current request resulted in a new session being created for the client (true) or an existing session was found for the client (false).

 RequiresSession

Specifies if an existing session is needed for this service to be accessible by clients.

 Session

Returns the Session object for the current client.

 SessionManager

Specifies the session manager component to be used by this service to locate and create user sessions.

 Transport

Provides a reference to the Transport object that was responsible for receiving the client request.


Legend

Property

read only


TRORemoteDataModule Class Events

Events

 OnActivate

This event fires when a service instance gets activated to serve a new request. Depending on the class factory used, the service instance might be freshly created or might have served other requests (for the same or different clients), before.

 OnDeactivate

This event fires before a service instance gets deactivated after serving a new request. Depending on the class factory used, the service instance might be freed, or kept alive to serve other requests (for the same or different clients), in the future.


Legend

Event


TRORemoteDataModule Class Methods

Methods

 Synchronize

This method provides the option to synchronize a method call to be executed in the context of the main VCL thread.


Legend

Method

protected


Legend

Legend

Property

read only

Event

Method

protected


TRORemoteDataModule Class Members

Members

Properties

 ClientID

Contains the ID of the client that is executing the current request.

 EventRepository

Specifies the repository to be used for dispatching and storing events that might be fired by this service.

 NewSession

Returns whether the current request resulted in a new session being created for the client (true) or an existing session was found for the client (false).

 RequiresSession

Specifies if an existing session is needed for this service to be accessible by clients.

 Session

Returns the Session object for the current client.

 SessionManager

Specifies the session manager component to be used by this service to locate and create user sessions.

 Transport

Provides a reference to the Transport object that was responsible for receiving the client request.

Events

 OnActivate

This event fires when a service instance gets activated to serve a new request. Depending on the class factory used, the service instance might be freshly created or might have served other requests (for the same or different clients), before.

 OnDeactivate

This event fires before a service instance gets deactivated after serving a new request. Depending on the class factory used, the service instance might be freed, or kept alive to serve other requests (for the same or different clients), in the future.

Methods

 Synchronize

This method provides the option to synchronize a method call to be executed in the context of the main VCL thread.


Legend

Property

read only

Event

Method

protected


See Also

Session Management and Session Management in TRORemoteDataModule help topics

Login and Authentication help topic

Event Sinks and Server Callbacks help topic


TRORemoteDataModule.ClientID Property

Contains the ID of the client that is executing the current request.

Use Case

This ClientID is used by the Session Management functionality integrated into the TRORemoteDataModule, but you can also use it for your own purposes to identify clients or persist per-client state in custom ways.

See Also

Session Management and Session Management in TRORemoteDataModule help topics

Pascal

property ClientID: TGUID;


See Also

Session Management and Session Management in TRORemoteDataModule help topics


TRORemoteDataModule.EventRepository Property

Specifies the repository to be used for dispatching and storing events that might be fired by this service.

Notes

Because event data is meant to be managed globally and persist across the creation and destruction of individual service instances, the Event Repository component must not be dropped onto the service designer itself, but should be referenced from a global data module or the main form.

See Also

TROEventRepository class

Event Sinks and Server Callbacks help topic

Pascal

property EventRepository: TROEventRepository;


See Also

TROEventRepository class

Event Sinks and Server Callbacks help topic


TRORemoteDataModule.NewSession Property

Returns whether the current request resulted in a new session being created for the client (true) or an existing session was found for the client (false).

See Also

SessionManager property

OnActivate event

Session Management and Session Management in TRORemoteDataModule help topics

Pascal

property NewSession: boolean;


See Also

SessionManager property

OnActivate event

Session Management and Session Management in TRORemoteDataModule help topics


TRORemoteDataModule.OnActivate Event

This event fires when a service instance gets activated to serve a new request. Depending on the class factory used, the service instance might be freshly created or might have served other requests (for the same or different clients), before.

Use Case

You can use this event for any custom initialization you might want to perform for your service, or to log access. The aMessage parameter of the event will give you full access to the message object, including the ability to inspect the name of the method that is about to be called.

See Also

OnDeactivate event

Class Factories help topic

Pascal

property OnActivate: TActivateEvent;


See Also

OnDeactivate event

Class Factories help topic


TRORemoteDataModule.OnDeactivate Event

This event fires before a service instance gets deactivated after serving a new request. Depending on the class factory used, the service instance might be freed, or kept alive to serve other requests (for the same or different clients), in the future.

Use Case

You can use this event for any custom cleanup you might want to perform for your service, or to log access.

See Also

OnDeactivate event

Class Factories help topic

Pascal

property OnDeactivate: TDeactivateEvent;


See Also

OnDeactivate event

Class Factories help topic


TRORemoteDataModule.RequiresSession Property

Specifies if an existing session is needed for this service to be accessible by clients.

Use Case

If this property is set to true, all attempts to access this service will fail, unless a session exists for the client. This can be used to implement a login system, where the secure service has this property set (disallowing any unauthorized access), and a second Login Service is provided to create/destroy user sessions after validating login information.

Please refer to the Login and Authentication help topic for more details on this pattern.

See Also

Session Management and Session Management in TRORemoteDataModule help topics

Login and Authentication help topic

OnActivate event

Pascal

property RequiresSession: boolean;


See Also

Session Management and Session Management in TRORemoteDataModule help topics

Login and Authentication help topic

OnActivate event


TRORemoteDataModule.Session Property

Returns the Session object for the current client.

Use case

You can use this object to store and access custom data that will be persisted between calls to your server.

Assuming the SessionManager property is assigned, the Session object will automatically be instantiated when your service gets activated. Once the service deactivates, any changes made to the session will be persisted back to the session manager.

See Also

TROSession class

SessionManager property

OnActivate and OnDeactivate events

Session Management and Session Management in TRORemoteDataModule help topics

Pascal

property Session: TROSession;


See Also

TROSession class

SessionManager property

OnActivate and OnDeactivate events

Session Management and Session Management in TRORemoteDataModule help topics


TRORemoteDataModule.SessionManager Property

Specifies the session manager component to be used by this service to locate and create user sessions.

Notes

Because session data is meant to be managed globally and persist across the creation and destruction of individual service instances, the Session Manager component must not be dropped onto the service designer itself, but should be referenced from a global data module or the main form.

See Also

TROSession class

SessionManager, Session and RequiresSession properties

OnActivate and OnDeactivate events

Session Management and Session Management in TRORemoteDataModule help topics

Pascal

property SessionManager: TROCustomSessionManager;


See Also

TROSession class

SessionManager, Session and RequiresSession properties

OnActivate and OnDeactivate events

Session Management and Session Management in TRORemoteDataModule help topics


TRORemoteDataModule.Transport Property

Provides a reference to the Transport object that was responsible for receiving the client request.

Use Case

This object is provided by the Server component, and can provide extended information on the origin of the request, such as the IP Address of the client, on TCP/IP-based servers.

See Also

IROTransport interface

Pascal

property Transport: IROTransport;


See Also

IROTransport interface


TRORemoteDataModule.Synchronize Method

This method provides the option to synchronize a method call to be executed in the context of the main VCL thread.

Use Case

Access to Windows UI controls or VCL controls is only safely permitted from within the main thread of the application. Because (depending on the channel) service requests are usually executed in secondary threads independently of the main thread, any such access to GUI elements can not be done directly from the service methods, but bust be Synchronized.

Notes

Note that synchronizing calls into the main thread will block the current execution until the method has finished. If multiple client requests synchronize calls at the same time, these calls will be queued up in the main thread and execute one after the other.

As such, synchronization should be used with care, as it can have a severe impact on scalability.

See Also

TThread.Synchronize in the Delphi online help.

Pascal

procedure Synchronize(aMethod: TThreadMethod);


See Also

TThread.Synchronize in the Delphi online help.


TRORemoteService Class

The Remote Service component is used to represent the connection to a remote service - both the channel and message component as well as the name of the service.

Essential Properties

Channel specifies the channel component that will be used to communicate with the service.

Message specifies the message format that will be used to communicate with the service.

ServiceName specifies the name of the service to talk to.

Class Hierarchy

File

uRORemoteService

See Also

TRODynamicRequest class

Pascal

TRORemoteService = class(TROComponent);


TRORemoteService Class Properties

Properties

 CacheRODL

Specifies whether the RODL Library available through the GetRODLLibrary method will be cached between calls, or not.

If set to false (default), the RODL file will be retrieved from the server every time GetRODLLibrary is called. If set t true, the RODL will only be downloaded once, the first time it is needed.

 Channel

Specifies the channel component that will be used to communicate with the service.

 Message

Specifies the message format that will be used to communicate with the service.

 ServiceName

Specifies the name of the service to talk to.


Legend

Property


TRORemoteService Class Methods

Methods

 GetRODLLibrary

Obtains the RODL file from the server (if needed) and returns a TRODLLibrary instance representing the content of the library.

 GetServiceMethods

Returns a list of all methods defined in the service.

 GetServiceNames

Returns a list of all services defined in the server's RODL library.


Legend

Method

virtual


Legend

Legend

Property

Method

virtual


TRORemoteService Class Members

Members

Properties

 CacheRODL

Specifies whether the RODL Library available through the GetRODLLibrary method will be cached between calls, or not.

If set to false (default), the RODL file will be retrieved from the server every time GetRODLLibrary is called. If set t true, the RODL will only be downloaded once, the first time it is needed.

 Channel

Specifies the channel component that will be used to communicate with the service.

 Message

Specifies the message format that will be used to communicate with the service.

 ServiceName

Specifies the name of the service to talk to.

Methods

 GetRODLLibrary

Obtains the RODL file from the server (if needed) and returns a TRODLLibrary instance representing the content of the library.

 GetServiceMethods

Returns a list of all methods defined in the service.

 GetServiceNames

Returns a list of all services defined in the server's RODL library.


Legend

Property

Method

virtual


See Also

TRODynamicRequest class


TRORemoteService.CacheRODL Property

Specifies whether the RODL Library available through the GetRODLLibrary method will be cached between calls, or not.

If set to false (default), the RODL file will be retrieved from the server every time GetRODLLibrary is called. If set t true, the RODL will only be downloaded once, the first time it is needed.

See Also

GetRODLLibrary method

RODL Files help topic

Pascal

property CacheRODL: boolean;


See Also

GetRODLLibrary method

RODL Files help topic


TRORemoteService.Channel Property

Specifies the channel component that will be used to communicate with the service.

See Also

TROTransportChannel class

Channels help topic

Pascal

property Channel: TROTransportChannel;


See Also

TROTransportChannel class

Channels help topic


TRORemoteService.Message Property

Specifies the message format that will be used to communicate with the service.

See Also

TROMessage class

Messages help topic

Pascal

property Message: TROMessage;


See Also

TROMessage class

Messages help topic


TRORemoteService.ServiceName Property

Specifies the name of the service to talk to.

See Also

GetServiceNames method

Pascal

property ServiceName: string;


See Also

GetServiceNames method


TRORemoteService.GetRODLLibrary Method

Obtains the RODL file from the server (if needed) and returns a TRODLLibrary instance representing the content of the library.

Notes

The returned TRODLLibrary instance is owned by the Remote Service component. It and all its elements are freed whenever a new RODL is downloaded (if CacheRODL is false), or when the service is freed.

See Also

CacheRODL property

RODL Files help topic

Pascal

function GetRODLLibrary: TRODLLibrary; virtual;


See Also

CacheRODL property

RODL Files help topic


TRORemoteService.GetServiceMethods Method

Returns a list of all methods defined in the service.

See Also

ServiceName property

GetRODLLibrary method

Pascal

function GetServiceMethods: IROStrings; virtual;


See Also

ServiceName property

GetRODLLibrary method


TRORemoteService.GetServiceNames Method

Returns a list of all services defined in the server's RODL library.

See Also

GetRODLLibrary method

Pascal

function GetServiceNames(aIncludeAbstractServices: boolean = false): IROStrings;


See Also

GetRODLLibrary method


TRORequestParam Class

The TRORequestParam class is used to represent an individual parameter in a TRODynamicRequest.

Essential Properties

Name specifies the name of the parameter.

DataType and TypeName specify the data type of the parameter.

Flag specifies the direction flag (in, out, var or result) of the parameter.

Value provides the value to be passed to or received back from the call.

Relevant Methods

CopyRODLParam initializes the parameter object based on a parameter defined in a RODL file.

Class Hierarchy

File

uRODynamicRequest

See Also

TRORequestParamCollection and TRODynamicRequest classes

Pascal

TRORequestParam = class(TCollectionItem);


TRORequestParam Class Properties

Properties

 AsBinary

Gets or sets the value of the parameter as Binary.

If the parameter is not of type Binary, nil will be returned.

 AsBoolean

Gets or sets the value of the parameter as Boolean.

 AsComplexType

Gets or sets the value of the parameter as ComplexType (Struct).

If the parameter is not a ComplexType, nil will be returned.

 AsCurrency

Gets or sets the value of the parameter as Currency.

 AsDateTime

Gets or sets the value of the parameter as DateTime.

 AsFloat

Gets or sets the value of the parameter as Float/Double.

 AsInt64

Gets or sets the value of the parameter as 64-bit Integer.

 AsInteger

Gets or sets the value of the parameter as 32-bit Integer.

 AsString

Gets or sets the value of the parameter as 8-bit ANSI String.

 AsVariant

Gets or sets the value of the parameter as Variant.

 AsWideString

Gets or sets the value of the parameter as 16-bit Unicode Widestring.

 DataType

Specifies the data type to be used for this parameter using a value from the TRODataType enum. If rtUserDefined is selected to specify a complext type / struct, then TypeName must also be set to the exact name of the type.

 Flag

Specifies the direction flag (in, out, var or result) of the parameter, as one of the values of TRODLParamFlag.

 IsNull

Returns whether the contained value is Null.

Depending on the DataType configured for the parameter, the property will either check the AsBinary or AsComplexType reference, or the internal Variant Value for null. As such, IsNull is valid for all data types.

 Name

Specifies the name of the parameter.

Depending on the message format used, this name must match the name specified in the RODL definition for the called service method.

 OwnsBinary

Specified whether the parameter owns the Binary value contained in AsBinary, and will automatically free it when the DataType changes or the parameter is destroyed (true), or not (false).

When setting DataType to rtBinary, the parameter will automatically instantiate a new Binary object if needed, and set OwnsBinary to true; conversely, if a Binary is manually assigned to AsBinary via code, OwnsBinary will be set to false.

You can manually set OwnsBinary to either value, to change the default behavior, either to hold on to the auto-created Binary and free it yourself, or to transfer ownership of a... more

 OwnsComplexType

Specified whether the parameter owns the ComplexType value contained in AsComplexType, and will automatically free it when the DataType changes or the parameter is destroyed (true), or not (false).

You can manually set OwnsComplexType to true in order to transfer ownership of a manually created Binary to the parameter.

 TypeName

Specifies the class name to be used for a complext type / struct parameter.

Setting TypeName to a non-empty value will automatically set DataType to rtUserDefined.

 Value

Gets or sets the contained variant value, if the DataType is not set to Binary or ComplexType.


Legend

Property

read only


TRORequestParam Class Methods

Methods

 ClearValue

Sets the internal value of the parameter to null.

If OwnsBinary or OwnsComplexType are true, objects assigned to AsBinary or AsComplexType will automatically be freed.


Legend

Method


Legend

Legend

Property

read only

Method


TRORequestParam Class Members

Members

Properties

 AsBinary

Gets or sets the value of the parameter as Binary.

If the parameter is not of type Binary, nil will be returned.

 AsBoolean

Gets or sets the value of the parameter as Boolean.

 AsComplexType

Gets or sets the value of the parameter as ComplexType (Struct).

If the parameter is not a ComplexType, nil will be returned.

 AsCurrency

Gets or sets the value of the parameter as Currency.

 AsDateTime

Gets or sets the value of the parameter as DateTime.

 AsFloat

Gets or sets the value of the parameter as Float/Double.

 AsInt64

Gets or sets the value of the parameter as 64-bit Integer.

 AsInteger

Gets or sets the value of the parameter as 32-bit Integer.

 AsString

Gets or sets the value of the parameter as 8-bit ANSI String.

 AsVariant

Gets or sets the value of the parameter as Variant.

 AsWideString

Gets or sets the value of the parameter as 16-bit Unicode Widestring.

 DataType

Specifies the data type to be used for this parameter using a value from the TRODataType enum. If rtUserDefined is selected to specify a complext type / struct, then TypeName must also be set to the exact name of the type.

 Flag

Specifies the direction flag (in, out, var or result) of the parameter, as one of the values of TRODLParamFlag.

 IsNull

Returns whether the contained value is Null.

Depending on the DataType configured for the parameter, the property will either check the AsBinary or AsComplexType reference, or the internal Variant Value for null. As such, IsNull is valid for all data types.

 Name

Specifies the name of the parameter.

Depending on the message format used, this name must match the name specified in the RODL definition for the called service method.

 OwnsBinary

Specified whether the parameter owns the Binary value contained in AsBinary, and will automatically free it when the DataType changes or the parameter is destroyed (true), or not (false).

When setting DataType to rtBinary, the parameter will automatically instantiate a new Binary object if needed, and set OwnsBinary to true; conversely, if a Binary is manually assigned to AsBinary via code, OwnsBinary will be set to false.

You can manually set OwnsBinary to either value, to change the default behavior, either to hold on to the auto-created Binary and free it yourself, or to transfer ownership of a... more

 OwnsComplexType

Specified whether the parameter owns the ComplexType value contained in AsComplexType, and will automatically free it when the DataType changes or the parameter is destroyed (true), or not (false).

You can manually set OwnsComplexType to true in order to transfer ownership of a manually created Binary to the parameter.

 TypeName

Specifies the class name to be used for a complext type / struct parameter.

Setting TypeName to a non-empty value will automatically set DataType to rtUserDefined.

 Value

Gets or sets the contained variant value, if the DataType is not set to Binary or ComplexType.

Methods

 ClearValue

Sets the internal value of the parameter to null.

If OwnsBinary or OwnsComplexType are true, objects assigned to AsBinary or AsComplexType will automatically be freed.


Legend

Property

read only

Method


See Also

TRORequestParamCollection and TRODynamicRequest classes


TRORequestParam.AsBinary Property

Gets or sets the value of the parameter as Binary.

If the parameter is not of type Binary, nil will be returned.

See Also

OwnsBinary and DataType properties

AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties

Pascal

property AsBinary: Binary;


See Also

OwnsBinary and DataType properties

AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties


TRORequestParam.AsBoolean Property

Gets or sets the value of the parameter as Boolean.

See Also

AsBinary, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariantand AsWideString properties

Pascal

property AsBoolean: boolean;


See Also

AsBinary, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariantand AsWideString properties


TRORequestParam.AsComplexType Property

Gets or sets the value of the parameter as ComplexType (Struct).

If the parameter is not a ComplexType, nil will be returned.

See Also

OwnsComplexType, DataType and TypeName property

AsBinary, AsBoolean, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties

TROComplexType class

Pascal

property AsComplexType: TROComplexType;


See Also

OwnsComplexType, DataType and TypeName property

AsBinary, AsBoolean, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties

TROComplexType class


TRORequestParam.AsCurrency Property

Gets or sets the value of the parameter as Currency.

See Also

AsBinary, AsBoolean, AsComplexType, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties

Pascal

property AsCurrency: currency;


See Also

AsBinary, AsBoolean, AsComplexType, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties


TRORequestParam.AsDateTime Property

Gets or sets the value of the parameter as DateTime.

See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties

Pascal

property AsDateTime: TDateTime;


See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties


TRORequestParam.AsFloat Property

Gets or sets the value of the parameter as Float/Double.

See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties

Pascal

property AsFloat: double;


See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties


TRORequestParam.AsInt64 Property

Gets or sets the value of the parameter as 64-bit Integer.

See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInteger, AsString, AsVariant and AsWideString properties

Pascal

property AsInt64: Int64;


See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInteger, AsString, AsVariant and AsWideString properties


TRORequestParam.AsInteger Property

Gets or sets the value of the parameter as 32-bit Integer.

See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsString, AsVariantand AsWideString properties

Pascal

property AsInteger: integer;


See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsString, AsVariantand AsWideString properties


TRORequestParam.AsString Property

Gets or sets the value of the parameter as 8-bit ANSI String.

See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsVariant and AsWideString properties

Pascal

property AsString: string;


See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsVariant and AsWideString properties


TRORequestParam.AsVariant Property

Gets or sets the value of the parameter as Variant.

See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString and AsWideString properties

Pascal

property AsVariant: variant;


See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString and AsWideString properties


TRORequestParam.AsWideString Property

Gets or sets the value of the parameter as 16-bit Unicode Widestring.

See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString and AsVariant properties

Pascal

property AsWideString: UnicodeString;


See Also

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString and AsVariant properties


TRORequestParam.DataType Property

Specifies the data type to be used for this parameter using a value from the TRODataType enum. If rtUserDefined is selected to specify a complext type / struct, then TypeName must also be set to the exact name of the type.

See Also

DataType and TypeName properties

TRODataType enum

TROComplexType class

Pascal

property DataType: TRODataType;


See Also

DataType and TypeName properties

TRODataType enum

TROComplexType class


TRORequestParam.Flag Property

Specifies the direction flag (in, out, var or result) of the parameter, as one of the values of TRODLParamFlag.

See Also

TRODLParamFlag enum

Pascal

property Flag: TRODLParamFlag;


See Also

TRODLParamFlag enum


TRORequestParam.IsNull Property

Returns whether the contained value is Null.

Depending on the DataType configured for the parameter, the property will either check the AsBinary or AsComplexType reference, or the internal Variant Value for null. As such, IsNull is valid for all data types.

See Also

DataType property

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties

Pascal

property IsNull: boolean;


See Also

DataType property

AsBinary, AsBoolean, AsComplexType, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties


TRORequestParam.Name Property

Specifies the name of the parameter.

Depending on the message format used, this name must match the name specified in the RODL definition for the called service method.

See Also

Messages help topic

Pascal

property Name: string;


See Also

Messages help topic


TRORequestParam.OwnsBinary Property

Specified whether the parameter owns the Binary value contained in AsBinary, and will automatically free it when the DataType changes or the parameter is destroyed (true), or not (false).

When setting DataType to rtBinary, the parameter will automatically instantiate a new Binary object if needed, and set OwnsBinary to true; conversely, if a Binary is manually assigned to AsBinary via code, OwnsBinary will be set to false.

You can manually set OwnsBinary to either value, to change the default behavior, either to hold on to the auto-created Binary and free it yourself, or to transfer ownership of a manually created Binary to the parameter.

See Also

DataType and AsBinary properties

TRODataType enum

Pascal

property OwnsBinary: boolean;


See Also

DataType and AsBinary properties

TRODataType enum


TRORequestParam.OwnsComplexType Property

Specified whether the parameter owns the ComplexType value contained in AsComplexType, and will automatically free it when the DataType changes or the parameter is destroyed (true), or not (false).

You can manually set OwnsComplexType to true in order to transfer ownership of a manually created Binary to the parameter.

See Also

DataType and AsComplexType properties

TRODataType enum

TROComplexType class

Pascal

property OwnsComplexType: boolean;


See Also

DataType and AsComplexType properties

TRODataType enum

TROComplexType class


TRORequestParam.TypeName Property

Specifies the class name to be used for a complext type / struct parameter.

Setting TypeName to a non-empty value will automatically set DataType to rtUserDefined.

See Also

DataType and AsComplexType properties

TRODataType enum

TROComplexType class

Pascal

property TypeName: string;


See Also

DataType and AsComplexType properties

TRODataType enum

TROComplexType class


TRORequestParam.Value Property

Gets or sets the contained variant value, if the DataType is not set to Binary or ComplexType.

Notes

AsBinary or AsComplexType must be used to set values of these, class-based types.

See Also

DataType property

AsBoolean, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties

AsBinary and AsComplexType properties.

Pascal

property Value: variant;


See Also

DataType property

AsBoolean, AsCurrency, AsDateTime, AsFloat, AsInt64, AsInteger, AsString, AsVariant and AsWideString properties

AsBinary and AsComplexType properties.


TRORequestParam.ClearValue Method

Sets the internal value of the parameter to null.

If OwnsBinary or OwnsComplexType are true, objects assigned to AsBinary or AsComplexType will automatically be freed.

See Also

OwnsBinary, OwnsComplexType, AsBinary and AsComplexType properties

TRORequestParamCollection.ClearValues method

Pascal

procedure ClearValue;


See Also

OwnsBinary, OwnsComplexType, AsBinary and AsComplexType properties

TRORequestParamCollection.ClearValues method


TRORequestParamCollection Class

The TRORequestParamCollection class is used to represent the list of parameters for a TRODynamicRequest.

Use Case

You will usually not create instances of this class yourself, but work with the Params property of a TRODynamicRequest component.

Class Hierarchy

File

uRODynamicRequest

See Also

TRORequestParam and TRODynamicRequest classes

Pascal

TRORequestParamCollection = class(TCollection);


TRORequestParamCollection Class Properties

Properties

 HasResultParam

Returns whether the collection contains a parameter marked as fResult.

Any request may only contain zero or one parameter marked as Result - any other parameters returned form the server must use the fOut flag, instead.

 Items

This indexer property gives access to the individual parameters contained in the collection.

 ResultParam

Returns the the parameter from the collection that is marked as fResult.

Any request may only contain zero or one parameter marked as Result - any other parameters returned form the server must use the fOut flag, instead. If no result parameter is found, this property returns nil.


Legend

Property

read only


TRORequestParamCollection Class Methods

Methods

 Add

Adds a new parameter to the collection.

 ClearInputValues

Sets the value to null for all parameters that are flagged as fIn or fInOut.

If OwnsBinary or OwnsComplexType of the parameter are true, objects assigned to AsBinary or AsComplexType will automatically be freed.

 ClearOutputValues

Sets the value to null for all parameters that are flagged as fInOut, fOut or fResult.

If OwnsBinary or OwnsComplexType of the parameter are true, objects assigned to AsBinary or AsComplexType will automatically be freed.

 ClearValues

Sets the internal value of all parameters to null.

If OwnsBinary or OwnsComplexType of the parameter are true, objects assigned to AsBinary or AsComplexType will automatically be freed.

 FindParam

Locates the TRORequestParam with a given name.

If no parameter by the name is found, nil is returned.

 ParamByName

Locates the TRORequestParam with a given name.

If no parameter by the name is found, an exception is raised.


Legend

Method


Legend

Legend

Property

read only

Method


TRORequestParamCollection Class Members

Members

Properties

 HasResultParam

Returns whether the collection contains a parameter marked as fResult.

Any request may only contain zero or one parameter marked as Result - any other parameters returned form the server must use the fOut flag, instead.

 Items

This indexer property gives access to the individual parameters contained in the collection.

 ResultParam

Returns the the parameter from the collection that is marked as fResult.

Any request may only contain zero or one parameter marked as Result - any other parameters returned form the server must use the fOut flag, instead. If no result parameter is found, this property returns nil.

Methods

 Add

Adds a new parameter to the collection.

 ClearInputValues

Sets the value to null for all parameters that are flagged as fIn or fInOut.

If OwnsBinary or OwnsComplexType of the parameter are true, objects assigned to AsBinary or AsComplexType will automatically be freed.

 ClearOutputValues

Sets the value to null for all parameters that are flagged as fInOut, fOut or fResult.

If OwnsBinary or OwnsComplexType of the parameter are true, objects assigned to AsBinary or AsComplexType will automatically be freed.

 ClearValues

Sets the internal value of all parameters to null.

If OwnsBinary or OwnsComplexType of the parameter are true, objects assigned to AsBinary or AsComplexType will automatically be freed.

 FindParam

Locates the TRORequestParam with a given name.

If no parameter by the name is found, nil is returned.

 ParamByName

Locates the TRORequestParam with a given name.

If no parameter by the name is found, an exception is raised.


Legend

Property

read only

Method


See Also

TRORequestParam and TRODynamicRequest classes


TRORequestParamCollection.HasResultParam Property

Returns whether the collection contains a parameter marked as fResult.

Any request may only contain zero or one parameter marked as Result - any other parameters returned form the server must use the fOut flag, instead.

See Also

ResultParam property

TRORequestParam.Flag property

TRODLParamFlag enum

Pascal

property HasResultParam: boolean;


See Also

ResultParam property

TRORequestParam.Flag property

TRODLParamFlag enum


TRORequestParamCollection.Items Property

This indexer property gives access to the individual parameters contained in the collection.

See Also

Add method

Pascal

property Items [Index: integer]: TRORequestParam;


See Also

Add method


TRORequestParamCollection.ResultParam Property

Returns the the parameter from the collection that is marked as fResult.

Any request may only contain zero or one parameter marked as Result - any other parameters returned form the server must use the fOut flag, instead. If no result parameter is found, this property returns nil.

See Also

ResultParam property

TRORequestParam.Flag property

TRODLParamFlag enum

Pascal

property ResultParam: TRORequestParam;


See Also

ResultParam property

TRORequestParam.Flag property

TRODLParamFlag enum


Add Method

Adds a new parameter to the collection.

See Also

Items indexer property


Add Method Methods

Methods

 Add

 Add


Legend

Method


Legend

Legend

Method


See Also

Items indexer property


TRORequestParamCollection.Add Method ()

function Add: TRORequestParam; overload;


TRORequestParamCollection.Add Method (string, TRODataType, TRODLParamFlag, string)

function Add(const aName: string; aDataType: TRODataType; aParamFlag: TRODLParamFlag; const aTypeName: string = ''): TRORequestParam; overload;


TRORequestParamCollection.ClearInputValues Method

Sets the value to null for all parameters that are flagged as fIn or fInOut.

If OwnsBinary or OwnsComplexType of the parameter are true, objects assigned to AsBinary or AsComplexType will automatically be freed.

See Also

ClearOutputValues and ClearValues methods

TRORequestParam.ClearValue method

TRODLParamFlag emum

Pascal

procedure ClearInputValues;


See Also

ClearOutputValues and ClearValues methods

TRORequestParam.ClearValue method

TRODLParamFlag emum


TRORequestParamCollection.ClearOutputValues Method

Sets the value to null for all parameters that are flagged as fInOut, fOut or fResult.

If OwnsBinary or OwnsComplexType of the parameter are true, objects assigned to AsBinary or AsComplexType will automatically be freed.

See Also

ClearInputValues and ClearValues methods

TRORequestParam.ClearValue method

TRODLParamFlag emum

Pascal

procedure ClearOutputValues;


See Also

ClearInputValues and ClearValues methods

TRORequestParam.ClearValue method

TRODLParamFlag emum


TRORequestParamCollection.ClearValues Method

Sets the internal value of all parameters to null.

If OwnsBinary or OwnsComplexType of the parameter are true, objects assigned to AsBinary or AsComplexType will automatically be freed.

See Also

ClearInputValues and ClearOutputValues methods

TRORequestParam.ClearValue method

Pascal

procedure ClearValues;


See Also

ClearInputValues and ClearOutputValues methods

TRORequestParam.ClearValue method


TRORequestParamCollection.FindParam Method

Locates the TRORequestParam with a given name.

If no parameter by the name is found, nil is returned.

See Also

ParamByName method

TRORequestParam class

Pascal

function FindParam(const aParamName: string): TRORequestParam;


See Also

ParamByName method

TRORequestParam class


TRORequestParamCollection.ParamByName Method

Locates the TRORequestParam with a given name.

If no parameter by the name is found, an exception is raised.

See Also

ParamByName method

TRORequestParam class

Pascal

function ParamByName(const aParamName: string): TRORequestParam;


See Also

ParamByName method

TRORequestParam class


TROServer Class

TROServer is the common base class for all server channel implementations in the RemObjects SDK.

You will not use instances of this class directly, but work with the descendant server implementations. Please refer t the Channels help topic, for a complete overview of available channels and servers.

Essential Properties

Active toggles whether the server is ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

Class Hierarchy

File

uROServer

See Also

Channels help topic

Pascal

TROServer = class(TROBaseConnection);


TROServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.


Legend

Property


TROServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

Event


TROServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

Event


See Also

Channels help topic


TROServer.Active Property

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

Pascal

property Active: boolean;


TROServer.Dispatchers Property

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

Essential Sub-Properties

Message specifies the message format to be used for this dispatcher.

Name specifies the name, or possibly the URL for the dispatcher.

Notes

In HTTP based servers (such as the TROIndyHTTPServer and TROBPDXHTTPServer), the Name will be appended as folder to the server URL allowing the server to make multiple dispatchers available at different URLs.

See Also

TROMessageDispatcher class

TROIndyHTTPServer and TROBPDXHTTPServer classes

HTTP Channels help topic

Pascal

property Dispatchers: TROMessageDispatchers;


See Also

TROMessageDispatcher class

TROIndyHTTPServer and TROBPDXHTTPServer classes

HTTP Channels help topic


TROServer.OnAfterServerActivate Property

Fires after the server has been activated.

See Also

OnBeforeServerActivate and OnAfterServerDeactivate events

Pascal

property OnAfterServerActivate: TNotifyEvent;


See Also

OnBeforeServerActivate and OnAfterServerDeactivate events


TROServer.OnAfterServerDeactivate Property

Fires after the server has been deactivated.

Use Case

You can use this event handler to perform any cleanup you might need after the server has stopped processing new requests.

See Also

OnBeforeServerDeactivate and OnAfterServerActivate events

Pascal

property OnAfterServerDeactivate: TNotifyEvent;


See Also

OnBeforeServerDeactivate and OnAfterServerActivate events


TROServer.OnBeforeServerActivate Property

Fires just before the server is activated.

Use Case

You can use this event handler to perform any initialization you might need before the server starts processing new requests.

See Also

OnAfterServerActivate and OnBeforeServerDeactivate events

Pascal

property OnBeforeServerActivate: TNotifyEvent;


See Also

OnAfterServerActivate and OnBeforeServerDeactivate events


TROServer.OnBeforeServerDeactivate Property

Fires just before the server is deactivated.

Use Case

You can use this event handler to perform any cleanup you might need before the server stops processing new requests.

See Also

OnAfterServerDeactivate and OnBeforeServerActivate events

Pascal

property OnBeforeServerDeactivate: TNotifyEvent;


See Also

OnAfterServerDeactivate and OnBeforeServerActivate events


TROServer.OnReadFromStream Event

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnWriteToStream event

TROTransportChannel.OnSendStream and TROMessage.OnReadFromStream event

Pascal

property OnReadFromStream: TStreamOperation;


See Also

OnWriteToStream event

TROTransportChannel.OnSendStream and TROMessage.OnReadFromStream event


TROServer.OnWriteToStream Event

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.

See Also

OnReadFromStream event

TROTransportChannel.OnReceiveStream and and TROMessage.OnReadFromStream event

Pascal

property OnWriteToStream: TStreamOperation;


See Also

OnReadFromStream event

TROTransportChannel.OnReceiveStream and and TROMessage.OnReadFromStream event


TROServerLocator Class

This class contains configuration data for an individual server that will be included in fail-over and load balancing support of a TROTransportChannel component.

You will not instantiate instances of this class yourself, but rather use the TROTransportChannel.ServerLocators collection property to define server locators for your channel.

Essential Properties

Enabled specifies whether the server is to be included in load balancing or fail-over support, or not.

Host specifies the TCP host address of the server.

Port specifies the TCP port of the server.

ProbingOptions specifies how and when the server will be probed.

Class Hierarchy

File

uROClientIntf

See Also

TROTransportChannel.ServerLocators property

Failover and Load Balancing help topic

Pascal

TROServerLocator = class(TCollectionItem);


TROServerLocator Class Properties

Properties

 DisableOnFailure

Specifies whether the server will automatically disabled, if a call fails.

How and if a once-disabled server will get re-enabled depends on the ProbingOptions property.

 Enabled

Specifies whether the server is to be included in load balancing or fail-over support, or not.

 Host

Specifies the TCP host address of the server.

 LoadBalancingServer

Specifies if this server is to be included in load balancing. If set to false, the server will only be considered for fail-over support if another server failed; it will not be included in normal load balancing scheduling.

 Name

Specifies a readable name for the server.

 Port

Specifies the TCP port of the server.

 ProbingOptions

Specifies how this sever will be handled during probing. The four available options include:


Legend

Property


TROServerLocator Class Events

Events

 OnEnabledChanged

Fires if the Enabled status of the server locator changes, due to probing, a failed request or manual change from code.


Legend

Event


Legend

Legend

Property

Event


TROServerLocator Class Members

Members

Properties

 DisableOnFailure

Specifies whether the server will automatically disabled, if a call fails.

How and if a once-disabled server will get re-enabled depends on the ProbingOptions property.

 Enabled

Specifies whether the server is to be included in load balancing or fail-over support, or not.

 Host

Specifies the TCP host address of the server.

 LoadBalancingServer

Specifies if this server is to be included in load balancing. If set to false, the server will only be considered for fail-over support if another server failed; it will not be included in normal load balancing scheduling.

 Name

Specifies a readable name for the server.

 Port

Specifies the TCP port of the server.

 ProbingOptions

Specifies how this sever will be handled during probing. The four available options include:

Events

 OnEnabledChanged

Fires if the Enabled status of the server locator changes, due to probing, a failed request or manual change from code.


Legend

Property

Event


See Also

TROTransportChannel.ServerLocators property

Failover and Load Balancing help topic


TROServerLocator.DisableOnFailure Property

Specifies whether the server will automatically disabled, if a call fails.

How and if a once-disabled server will get re-enabled depends on the ProbingOptions property.

See Also

Enabled and ProbingOptions properties

OnEnabledChanged event

Pascal

property DisableOnFailure: boolean;


See Also

Enabled and ProbingOptions properties

OnEnabledChanged event


TROServerLocator.Enabled Property

Specifies whether the server is to be included in load balancing or fail-over support, or not.

See Also

DisableOnFailure and ProbingOptions properties

OnEnabledChanged event

Pascal

property Enabled: boolean;


See Also

DisableOnFailure and ProbingOptions properties

OnEnabledChanged event


TROServerLocator.Host Property

Specifies the TCP host address of the server.

See Also

Port property

Pascal

property Host: string;


See Also

Port property


TROServerLocator.LoadBalancingServer Property

Specifies if this server is to be included in load balancing. If set to false, the server will only be considered for fail-over support if another server failed; it will not be included in normal load balancing scheduling.

Pascal

property LoadBalancingServer: boolean;


TROServerLocator.Name Property

Specifies a readable name for the server.

Pascal

property Name: string;


TROServerLocator.OnEnabledChanged Event

Fires if the Enabled status of the server locator changes, due to probing, a failed request or manual change from code.

Use Case

You can use this event to check the status of the server locator, possibly to update internal data structures to or to display server status in the user interface.

See Also

Enabled, DisableOnFailure and ProbingOptions properties

Pascal

property OnEnabledChanged: TROServerLocatorNotifyEvent;


See Also

Enabled, DisableOnFailure and ProbingOptions properties


TROServerLocator.Port Property

Specifies the TCP port of the server.

See Also

Host property

Pascal

property Port: integer;


See Also

Host property


TROServerLocator.ProbingOptions Property

Specifies how this sever will be handled during probing. The four available options include:
Value	Meaning
poProbeWhenEnabled	Include this server in probing, if it's already enabled.
poProbeWhenDisabled	Include this server in probing, if it's currently disabled. Activating this option is the only way a once-disabled server will ever be automatically re-enabled.
poEnableIfProbeSucceeded	(Re-)enable the server if it was successfully probed. Activating this option is the only way a once-disabled server will ever be automatically re-enabled.
poDisableIfProbeFailed	Disable this server if probing failed. (see also DisableOnFailure)
See Also

Enabled and DisableOnFailure properties

OnEnabledChanged event

TROProbingOption enum

Pascal

property ProbingOptions: TROProbingOptions;


See Also

Enabled and DisableOnFailure properties

OnEnabledChanged event

TROProbingOption enum


TROService Class

TROService is a helper class used to implement the Combo templates that can act as Windows Service and standalone VCL application. It descends from Delphi's TService implementation to provide some extended internal functionality needed for the dual use.

Use Case

You will usually not work with instances of this class directly, but use the "Combo Service/Standalone" project template included with RemObjects SDK to build combo servers.

Class Hierarchy

File

uROComboService

Pascal

TROService = class(TService);


TROSession Class

The TROSession class represents an individual user session within the RemObjects SDK Session Management system.

Use Cases

You will usually work with this class via the TRORemoteDataModule.Session property to access the current user's session.

Relevant Properties

SessionID is the ID that uniquely identifies the session, and matches the ClientID received from the user.

Values is an indexer property that gives access to all values stored in the session, by name.

Class Hierarchy

File

uROSessions

See Also

Session Management help topic

TROCustomSessionManager class

Pascal

TROSession = class;


TROSession Class Properties

Properties

 Count

Returns the number of Values contained in the session.

 Created

Returns the date and time when the session was originally created.

 LastAccessed

Returns the date and time when the session was last accessed.

This value will be used in combination with the session manager's SessionDuration property to determine if a session has expired.

 Names

Provides access to the list of names that session Values are stored in the session.

 SessionID

Contains the ID that uniquely identifies the session, and matches the ClientID received from the user.

 Values

Provides access to all values stored in the session, by name.


Legend

Property

read only


Legend

Legend

Property

read only


TROSession Class Members

Members

Properties

 Count

Returns the number of Values contained in the session.

 Created

Returns the date and time when the session was originally created.

 LastAccessed

Returns the date and time when the session was last accessed.

This value will be used in combination with the session manager's SessionDuration property to determine if a session has expired.

 Names

Provides access to the list of names that session Values are stored in the session.

 SessionID

Contains the ID that uniquely identifies the session, and matches the ClientID received from the user.

 Values

Provides access to all values stored in the session, by name.


Legend

Property

read only


See Also

Session Management help topic

TROCustomSessionManager class


TROSession.Count Property

Returns the number of Values contained in the session.

See Also

Values property

Pascal

property Count: integer;


See Also

Values property


TROSession.Created Property

Returns the date and time when the session was originally created.

See Also

LastAccessed property

Pascal

property Created: TDateTime;


See Also

LastAccessed property


TROSession.LastAccessed Property

Returns the date and time when the session was last accessed.

This value will be used in combination with the session manager's SessionDuration property to determine if a session has expired.

See Also

TROCustomSessionManager.SessionDuration

Created property

Pascal

property LastAccessed: TDateTime;


See Also

TROCustomSessionManager.SessionDuration

Created property


TROSession.Names Property

Provides access to the list of names that session Values are stored in the session.

See Also

Count and Values properties

Pascal

property Names [Index : integer]: string;


See Also

Count and Values properties


TROSession.SessionID Property

Contains the ID that uniquely identifies the session, and matches the ClientID received from the user.

See Also

TROMessage.ClientID

Pascal

property SessionID: TGUID;


See Also

TROMessage.ClientID


TROSession.Values Property

Provides access to all values stored in the session, by name.

See Also

Names property

Pascal

property Values [const Name : string]: Variant;


See Also

Names property


TROSingletonClassFactory Class

TROSingletonClassFactory provides a class factory that implements the Singleton pattern: only one instance of the service class will ever be created, and this same class will be used to service all requests.

Use Case

This class factory provides very efficient access to your service methods, if your service is implemented to be reentrant so that a single instance can serve multiple requests.

Use this class factory if none of your service methods rely on global per-class fields, or if you intend for data stored in the service class to be shared by all callers.

Class Hierarchy

Notes

If you design your service based on the guidelines outlined in the Statelessness help topic and do not rely on per-instance fields of the service class, this is the perfect and most efficient class factory to use.

File

uROClassFactories

See Also

TROSynchronizedSingletonClassFactory class

TROClassFactory, TROPooledClassFactory and TROPerClientClassFactory classes

Class Factories and RODL Files help topics

Statelessness help topic

Pascal

TROSingletonClassFactory = class(TROClassFactory);


TROSingletonClassFactory Class Methods

Methods

 Create

Creates a new instance of the class factory

 CreateInstance

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

 ReleaseInstance

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.


Legend

Constructor

protected

virtual


Legend

Legend

Constructor

protected

virtual


TROSingletonClassFactory Class Members

Members

Methods

 Create

Creates a new instance of the class factory

 CreateInstance

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

 ReleaseInstance

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.


Legend

Constructor

protected

virtual


See Also

TROSynchronizedSingletonClassFactory class

TROClassFactory, TROPooledClassFactory and TROPerClientClassFactory classes

Class Factories and RODL Files help topics

Statelessness help topic


TROSOAPMessage Class

TROSoapMessage implements message encoding using the Simple Object Access Protocol (SOAP), a standardized XML based protocol for exchanging messages between client and server that forms the foundation of Web Services.

Please refer to the SOAP Message help topic for more details on SOAP and Web Services.

Essential Properties

None; The SOAP Message component is usable after being dropped from the component palette.

Relevant Properties

SerializationOptions provides several options that control how SOAP messages are generated, which might be relevant when talking to third party SOAP implementations.

Class Hierarchy

File

uROSOAPMessage

See Also

Messages and SOAP Message help topics

Pascal

TROSOAPMessage = class(TROMessage, IROModuleInfo, IROSOAPMessage, IRONamedModuleInfo);


TROSOAPMessage Class Properties

Properties

 ClientID

Contains the Client ID for the message.

 InterfaceName

Contains the name of the interface (service) that this message is calling.

 MessageName

Contains the name of the method that this message is calling.

TROSOAPMessage Class

 BodyNode

Provides access to the Body XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

See Also 	EnvelopeNode, FaultNode, HeaderNode and MessageNode properties

 CustomLocation

This property can be set to override the "Location" value in WSDL files generated on the SOAP server.

By default, the WSDL's Location will point to the URL the server is running under.

 EnvelopeNode

Provides access to the SOAP Envelope XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

 FaultNode

Provides access to the Fault XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

 HeaderNode

Provides access to the Header XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

 MessageNode

Provides access to the Message XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

 SerializationOptions

Provides several options that control how SOAP messages are generated, which might be relevant when talking to third party SOAP implementations.

Please refer to the TROXMLSerializationOption enum for details.


Legend

Property

read only


TROSOAPMessage Class Events

Events

 OnFinalizeMessage

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

 OnInitializeMessage

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

 OnReadFromStream

Fires before the message is read from the stream that was received over the network.

 OnReadMessageParameter

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnServerException

Fires if an exception message is received from the server.

 OnWriteException

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

 OnWriteMessageParameter

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnWriteToStream

Fires after the message was written to the stream that will be sent over the network.

TROSOAPMessage Class

 OnEnvelopeComplete

Fires after the SOAP envelope has been complete generated, giving the option to inspect ad tweak the final result using the EnvelopeNode property.

 OnSOAPFault

Fires after an exception (fault) has been read from the received SOAP message, allowing to inspect the fault details before the actual exception is raised.

 OnWriteEnvelopeAttribute

This event fires before a given SOAP attribute is written to the envelope.

You can use this event to determine whether specific attributes will be written, and to exclude attributes that a particular third party SOAP implementation you are taking to might not understand.


Legend

Event


Legend

Legend

Property

read only

Event


TROSOAPMessage Class Members

Members

Properties

 ClientID

Contains the Client ID for the message.

 InterfaceName

Contains the name of the interface (service) that this message is calling.

 MessageName

Contains the name of the method that this message is calling.

TROSOAPMessage Class

 BodyNode

Provides access to the Body XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

See Also 	EnvelopeNode, FaultNode, HeaderNode and MessageNode properties

 CustomLocation

This property can be set to override the "Location" value in WSDL files generated on the SOAP server.

By default, the WSDL's Location will point to the URL the server is running under.

 EnvelopeNode

Provides access to the SOAP Envelope XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

 FaultNode

Provides access to the Fault XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

 HeaderNode

Provides access to the Header XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

 MessageNode

Provides access to the Message XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

 SerializationOptions

Provides several options that control how SOAP messages are generated, which might be relevant when talking to third party SOAP implementations.

Please refer to the TROXMLSerializationOption enum for details.

Events

 OnFinalizeMessage

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

 OnInitializeMessage

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

 OnReadFromStream

Fires before the message is read from the stream that was received over the network.

 OnReadMessageParameter

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnServerException

Fires if an exception message is received from the server.

 OnWriteException

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

 OnWriteMessageParameter

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnWriteToStream

Fires after the message was written to the stream that will be sent over the network.

TROSOAPMessage Class

 OnEnvelopeComplete

Fires after the SOAP envelope has been complete generated, giving the option to inspect ad tweak the final result using the EnvelopeNode property.

 OnSOAPFault

Fires after an exception (fault) has been read from the received SOAP message, allowing to inspect the fault details before the actual exception is raised.

 OnWriteEnvelopeAttribute

This event fires before a given SOAP attribute is written to the envelope.

You can use this event to determine whether specific attributes will be written, and to exclude attributes that a particular third party SOAP implementation you are taking to might not understand.


Legend

Property

read only

Event


See Also

Messages and SOAP Message help topics


TROSOAPMessage.BodyNode Property

Provides access to the Body XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

See Also 	EnvelopeNode, FaultNode, HeaderNode and MessageNode properties

Pascal

property BodyNode: IXMLNode;


TROSOAPMessage.CustomLocation Property

This property can be set to override the "Location" value in WSDL files generated on the SOAP server.

By default, the WSDL's Location will point to the URL the server is running under.

Pascal

property CustomLocation: string;


TROSOAPMessage.EnvelopeNode Property

Provides access to the SOAP Envelope XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

See Also

BodyNode, FaultNode, HeaderNode and MessageNode properties

OnEnvelopeComplete event

Pascal

property EnvelopeNode: IXMLNode;


See Also

BodyNode, FaultNode, HeaderNode and MessageNode properties

OnEnvelopeComplete event


TROSOAPMessage.FaultNode Property

Provides access to the Fault XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

See Also

BodyNode, EnvelopeNode, HeaderNode and MessageNode properties

OnSoapFault event

Pascal

property FaultNode: IXMLNode;


See Also

BodyNode, EnvelopeNode, HeaderNode and MessageNode properties

OnSoapFault event


TROSOAPMessage.HeaderNode Property

Provides access to the Header XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

See Also

BodyNode, EnvelopeNode, FaultNode and MessageNode properties

Pascal

property HeaderNode: IXMLNode;


See Also

BodyNode, EnvelopeNode, FaultNode and MessageNode properties


TROSOAPMessage.MessageNode Property

Provides access to the Message XML node of the SOAP message. You can access this node to inspect values or make manual modifications, if needed.

See Also

BodyNode, EnvelopeNode, FaultNode and HeaderNode properties

Pascal

property MessageNode: IXMLNode;


See Also

BodyNode, EnvelopeNode, FaultNode and HeaderNode properties


TROSOAPMessage.OnEnvelopeComplete Event

Fires after the SOAP envelope has been complete generated, giving the option to inspect ad tweak the final result using the EnvelopeNode property.

See Also

EnvelopeNode property

Pascal

property OnEnvelopeComplete: TROEnvelopeCompleteEvent;


See Also

EnvelopeNode property


TROSOAPMessage.OnSOAPFault Event

Fires after an exception (fault) has been read from the received SOAP message, allowing to inspect the fault details before the actual exception is raised.

See Also

FaultNode property

Pascal

property OnSOAPFault: TSOAPFaultEvent;


See Also

FaultNode property


TROSOAPMessage.OnWriteEnvelopeAttribute Event

This event fires before a given SOAP attribute is written to the envelope.

You can use this event to determine whether specific attributes will be written, and to exclude attributes that a particular third party SOAP implementation you are taking to might not understand.

See Also

EnvelopeNode property

OnEnvelopeComplete event

Pascal

property OnWriteEnvelopeAttribute: TROAttributeWriteEvent;


See Also

EnvelopeNode property

OnEnvelopeComplete event


TROSOAPMessage.SerializationOptions Property

Provides several options that control how SOAP messages are generated, which might be relevant when talking to third party SOAP implementations.

Please refer to the TROXMLSerializationOption enum for details.

See Also

TROXMLSerializationOption enum

Pascal

property SerializationOptions: TROXMLSerializationOptions;


See Also

TROXMLSerializationOption enum


TROSuperTcpChannel Class

TROSuperTCPChannel implements the new and enhanced TCP based channel introduced with the RemObjects SDK 4.0, which provides a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

The channel is based on the open source Indy components that ship with Delphi.

Essential Properties

Host specifies address of the server to talk to.

Port specifies the port number the server listens to.

Class Hierarchy

File

uROSuperTCPChannel

See Also

Channels and Legacy TCP Channels help topics

Pascal

TROSuperTcpChannel = class(TROCustomSuperTcpChannel);


TROSuperTcpChannel Class Properties

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomSuperTcpChannel Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent request (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed.

 Active

Specifies whether the channel is currently active, which means has an open connection to the server, or is in the process of (re-)establishing a connection (true) or not (false).

 AutoReconnect

Specifies if the Super TCP Channel should automatically re-establish a connection to the server if the current connection is lost (true) or not (false, default).

 Client

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 ClientID

Contains the ClientID of the client.

 Connected

Returns whether the client currently has an active connection to the server (true) or not (false).

 Host

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 OnConnected

Fires when an active TCP connection to the server has been (re-)established.

 OnDisconnected

Fires when the active TCP connection to the server has been dropped or lost.

 Port

Specifies the port number the server is listening on (default for the RemObjects SDK TCP servers is 8095).

 ReconnectDelay

Specifies the time, in milliseconds, that the channel will wait after an unsuccessful (re-)connect, before it attempts the next connect, if AutoReconnect is true. Default is 500, half a second.

 RequestTimeout

Specifies the time frame, in milliseconds, within which the response for any given request must be received (default is 60,000, 1 minute). If no response has been received after the specified time, an exception is raised and the call will fail.

 StoreActive

Specifies whether the design time value of the Active property should be stored in in the form's DFM file (true, default), or not (false).

TROSuperTcpChannel Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent request (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed.

 Active

Specifies whether the channel is currently active, which means has an open connection to the server, or is in the process of (re-)establishing a connection (true) or not (false).

 AutoReconnect

Specifies if the Super TCP Channel should automatically re-establish a connection to the server if the current connection is lost (true) or not (false, default).

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 OnConnected

Fires when an active TCP connection to the server has been (re-)established.

 OnDisconnected

Fires when the active TCP connection to the server has been dropped or lost.

 Port

Specifies the port number the server is listening on (default for the RemObjects SDK TCP servers is 8095).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ReconnectDelay

Specifies the time, in milliseconds, that the channel will wait after an unsuccessful (re-)connect, before it attempts the next connect, if AutoReconnect is true. Default is 500, half a second.

 RequestTimeout

Specifies the time frame, in milliseconds, within which the response for any given request must be received (default is 60,000, 1 minute). If no response has been received after the specified time, an exception is raised and the call will fail.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 StoreActive

Specifies whether the design time value of the Active property should be stored in in the form's DFM file (true, default), or not (false).

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.


Legend

Property

read only


TROSuperTcpChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROSuperTcpChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROSuperTcpChannel Class Members

Members

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROCustomSuperTcpChannel Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent request (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed.

 Active

Specifies whether the channel is currently active, which means has an open connection to the server, or is in the process of (re-)establishing a connection (true) or not (false).

 AutoReconnect

Specifies if the Super TCP Channel should automatically re-establish a connection to the server if the current connection is lost (true) or not (false, default).

 Client

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

 ClientID

Contains the ClientID of the client.

 Connected

Returns whether the client currently has an active connection to the server (true) or not (false).

 Host

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 OnConnected

Fires when an active TCP connection to the server has been (re-)established.

 OnDisconnected

Fires when the active TCP connection to the server has been dropped or lost.

 Port

Specifies the port number the server is listening on (default for the RemObjects SDK TCP servers is 8095).

 ReconnectDelay

Specifies the time, in milliseconds, that the channel will wait after an unsuccessful (re-)connect, before it attempts the next connect, if AutoReconnect is true. Default is 500, half a second.

 RequestTimeout

Specifies the time frame, in milliseconds, within which the response for any given request must be received (default is 60,000, 1 minute). If no response has been received after the specified time, an exception is raised and the call will fail.

 StoreActive

Specifies whether the design time value of the Active property should be stored in in the form's DFM file (true, default), or not (false).

TROSuperTcpChannel Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent request (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed.

 Active

Specifies whether the channel is currently active, which means has an open connection to the server, or is in the process of (re-)establishing a connection (true) or not (false).

 AutoReconnect

Specifies if the Super TCP Channel should automatically re-establish a connection to the server if the current connection is lost (true) or not (false, default).

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Host

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 OnConnected

Fires when an active TCP connection to the server has been (re-)established.

 OnDisconnected

Fires when the active TCP connection to the server has been dropped or lost.

 Port

Specifies the port number the server is listening on (default for the RemObjects SDK TCP servers is 8095).

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ReconnectDelay

Specifies the time, in milliseconds, that the channel will wait after an unsuccessful (re-)connect, before it attempts the next connect, if AutoReconnect is true. Default is 500, half a second.

 RequestTimeout

Specifies the time frame, in milliseconds, within which the response for any given request must be received (default is 60,000, 1 minute). If no response has been received after the specified time, an exception is raised and the call will fail.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 StoreActive

Specifies whether the design time value of the Active property should be stored in in the form's DFM file (true, default), or not (false).

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROSuperTcpChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels and Legacy TCP Channels help topics


TROSuperTcpChannel.AckWaitTimeout Property

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent request (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed.

See Also

RequestTimeout and MaxPackageSize property

Pascal

property AckWaitTimeout: Integer;


See Also

RequestTimeout and MaxPackageSize property


TROSuperTcpChannel.Active Property

Specifies whether the channel is currently active, which means has an open connection to the server, or is in the process of (re-)establishing a connection (true) or not (false).

See Also

StoreActive and Conncted properties

Pascal

property Active: Boolean;


See Also

StoreActive and Conncted properties


TROSuperTcpChannel.AutoReconnect Property

Specifies if the Super TCP Channel should automatically re-establish a connection to the server if the current connection is lost (true) or not (false, default).

Use Case

Set this property to true if your client needs a constant connection to the server, for example to receive callback events or asynchronous responses.

See Also

ReconnectDelay property

OnDisconnected and OnConnected events

Event Sinks and Server Callbacks and Asynchronous Calls help topics

Pascal

property AutoReconnect: Boolean;


See Also

ReconnectDelay property

OnDisconnected and OnConnected events

Event Sinks and Server Callbacks and Asynchronous Calls help topics


TROSuperTcpChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TROSuperTcpChannel.Host Property

Pascal

property Host: string;


TROSuperTcpChannel.MaxPackageSize Property

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

See Also

RequestTimeout property

Pascal

property MaxPackageSize: Integer;


See Also

RequestTimeout property


TROSuperTcpChannel.OnAfterProbingServer Event

Fires after the channel is done probing a specific server for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServer: TROEndProbeServerEvent;


See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSuperTcpChannel.OnAfterProbingServers Event

Fires after the channel is done probing all servers for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServers: TROEndProbeServersEvent;


See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSuperTcpChannel.OnBeforeProbingServer Event

Fires before the channel starts probing a specific server for availability.

Use Case

You can use this event to check or adjust the server configuration, or to include/exclude the server from being probed by changing the TROServerLocator.Enabled property.

See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServer: TROBeginProbeServerEvent;


See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSuperTcpChannel.OnBeforeProbingServers Event

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServers: TROBeginProbeServersEvent;


See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSuperTcpChannel.OnConnected Property

Fires when an active TCP connection to the server has been (re-)established.

See Also

OnDisconnected event

AutoReconnect and ReconnectDelay properties

Pascal

property OnConnected: TNotifyEvent;


See Also

OnDisconnected event

AutoReconnect and ReconnectDelay properties


TROSuperTcpChannel.OnDisconnected Property

Fires when the active TCP connection to the server has been dropped or lost.

See Also

OnConnected event

AutoReconnect and ReconnectDelay properties

Pascal

property OnDisconnected: TNotifyEvent;


See Also

OnConnected event

AutoReconnect and ReconnectDelay properties


TROSuperTcpChannel.OnLoginNeeded Event

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

Use Case

The most common use for this event is to perform a call to a special Login service provided by the server (possibly after prompting the user to enter username ad password), and to set the aRetry parameter to true if login was successful.

See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic

Pascal

property OnLoginNeeded: TROExceptionEvent;


See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic


TROSuperTcpChannel.OnReceiveStream Event

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnReceiveStream: TStreamDispatch;


See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROSuperTcpChannel.OnSendStream Event

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnSendStream: TStreamDispatch;


See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROSuperTcpChannel.Port Property

Specifies the port number the server is listening on (default for the RemObjects SDK TCP servers is 8095).

Pascal

property Port: Integer;


TROSuperTcpChannel.ProbeFrequency Property

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

Notes

Although somewhat misnamed, this property defines the Interval between probes, not the actual probing Frequency. The property name is persisted for backward compatibility, we apologize.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeFrequency: cardinal;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSuperTcpChannel.ProbeServers Property

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeServers: boolean;


See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSuperTcpChannel.ReconnectDelay Property

Specifies the time, in milliseconds, that the channel will wait after an unsuccessful (re-)connect, before it attempts the next connect, if AutoReconnect is true. Default is 500, half a second.

See Also

AutoReconnect property

Pascal

property ReconnectDelay: Integer;


See Also

AutoReconnect property


TROSuperTcpChannel.RequestTimeout Property

Specifies the time frame, in milliseconds, within which the response for any given request must be received (default is 60,000, 1 minute). If no response has been received after the specified time, an exception is raised and the call will fail.

See Also

MaxPackageSize property

Pascal

property RequestTimeout: Integer;


See Also

MaxPackageSize property


TROSuperTcpChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TROSuperTcpChannel.StoreActive Property

Specifies whether the design time value of the Active property should be stored in in the form's DFM file (true, default), or not (false).

Use Case

Set this property to false if you want to activate the the component at design time but do not want Active to automatically be set to true when running your application (for example if you want to perform custom initialization in code, such as reading the host name from a config file) before activating the channel.

See Also

Active property

Pascal

property StoreActive: Boolean;


See Also

Active property


TROSuperTcpChannel.SynchronizedProbing Property

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property SynchronizedProbing: Boolean;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSuperTcpServer Class

TROSuperTCPServer implements the server side of the new and enhanced TCP based channel introduced with the RemObjects SDK 4.0, which provides a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

The channel is based on the open source Indy components that ship with Delphi.

Essential Properties

Port specifies the port number the server is listening on.

Class Hierarchy

File

uROSuperTCPServer

See Also

Channels and Legacy TCP Channels help topics

Pascal

TROSuperTcpServer = class(TROCustomSuperTcpServer);


TROSuperTcpServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomSuperTcpServer Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent event (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed and the event will be stored in the queue for future retries.

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 Port

Specifies the network socket that the server will be listening on (default for the RemObjects SDK Super TCP servers is 8095).

 Server

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

TROSuperTcpServer Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent event (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed and the event will be stored in the queue for future retries.

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 Port

Specifies the network socket that the server will be listening on (default for the RemObjects SDK Super TCP servers is 8095).


Legend

Property

read only


TROSuperTcpServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

read only

Event


TROSuperTcpServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROCustomSuperTcpServer Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent event (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed and the event will be stored in the queue for future retries.

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 Port

Specifies the network socket that the server will be listening on (default for the RemObjects SDK Super TCP servers is 8095).

 Server

Provides direct access to the underlying Indy implementation. You can use this property to control advanced settings on the Indy object. The exact available properties and settings depend on the version of Indy you are using

TROSuperTcpServer Class

 AckWaitTimeout

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent event (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed and the event will be stored in the queue for future retries.

 MaxPackageSize

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

 Port

Specifies the network socket that the server will be listening on (default for the RemObjects SDK Super TCP servers is 8095).

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

read only

Event


See Also

Channels and Legacy TCP Channels help topics


TROSuperTcpServer.AckWaitTimeout Property

Specifies the time frame, in milliseconds, within which an "acknowledgement" message is expected to be received for a sent event (default is 10,000, 10 seconds). If no acknowledgement has been received after the specified time, delivery will be considered to have failed and the event will be stored in the queue for future retries.

See Also

RequestTimeout and MaxPackageSize property

Pascal

property AckWaitTimeout: Integer;


See Also

RequestTimeout and MaxPackageSize property


TROSuperTcpServer.MaxPackageSize Property

Specifies the maximum size of data package that the channel will transport (default is 1048576, 1MB).

See Also

RequestTimeout property

Pascal

property MaxPackageSize: Integer;


See Also

RequestTimeout property


TROSuperTcpServer.Port Property

Specifies the network socket that the server will be listening on (default for the RemObjects SDK Super TCP servers is 8095).

Pascal

property Port: Integer;


TROSynapseHTTPChannel Class

TROSynapseHTTPChannel implements an HTTP based channel that uses the HTTP implementation provided by the open source Synapse components that are available at http://synapse.ararat.cz.

Essential Properties

TargetURL specifies the address of the server to talk to.

Class Hierarchy

Notes

Because this channel is based on a third party component library, the component will not be installed automatically by the RemObjects SDK. To use the Synapse channels, please download and install Synapse from the URL provided above, and make sure it is on the Delphi Library Path, then build and install the RemObjects_Synapse_Dx package.

File

uROSynapseHTTPChannel

See Also

Channels and HTTP Channels help topics

TROWinInetHTTPChannel and TROSynapseHTTPChannel components

Pascal

TROSynapseHTTPChannel = class(TROTransportChannel, IROTransport, IROTCPTransport, IROHTTPTransport);


TROSynapseHTTPChannel Class Properties

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROSynapseHTTPChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 http

Provides direct access to the underlying Synapse HTTP implementation. You can use this property to control advanced settings on the object. The exact available properties and settings depend on the version of Synapse you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

 TargetURL

Specifies the address of the server to talk to.

By default, this is usually he host name of your server, followed by the 8099, plus the name of the dispatcher configured on the server; for example http://myserver:8099/bin.


Legend

Property

read only


TROSynapseHTTPChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROSynapseHTTPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROSynapseHTTPChannel Class Members

Members

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROSynapseHTTPChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 http

Provides direct access to the underlying Synapse HTTP implementation. You can use this property to control advanced settings on the object. The exact available properties and settings depend on the version of Synapse you are using

 KeepAlive

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

 TargetURL

Specifies the address of the server to talk to.

By default, this is usually he host name of your server, followed by the 8099, plus the name of the dispatcher configured on the server; for example http://myserver:8099/bin.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROSynapseHTTPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels and HTTP Channels help topics

TROWinInetHTTPChannel and TROSynapseHTTPChannel components


TROSynapseHTTPChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TROSynapseHTTPChannel.http Property

Provides direct access to the underlying Synapse HTTP implementation. You can use this property to control advanced settings on the object. The exact available properties and settings depend on the version of Synapse you are using

See Also

Synapse documentation

Pascal

property http: THTTPSend;


See Also

Synapse documentation


TROSynapseHTTPChannel.KeepAlive Property

Specifies if HTTP Keep-Alive is used to keep the connection alive between requests.

If enabled (true) , once a request is made and a connection is established, this connection is kept open and used for future requests. If disabled, the connection is closed, and a new connection is created for future requests.

Since establishing a connection is - relatively speaking - a costly and resource intensive operation for the network, compared to sending small amounts of data, it is recommended to keep this option enabled for optimal performance, if requests to the server are done relatively frequently.

Notes

For Keep-Alive to work, the option must be supported and enabled on both client and server.

See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties

Pascal

property KeepAlive: Boolean;


See Also

TROIndyHTTPServer.KeepAlive and TROBPDXHTTPServer.SupportKeepAlive properties


TROSynapseHTTPChannel.OnAfterProbingServer Event

Fires after the channel is done probing a specific server for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServer: TROEndProbeServerEvent;


See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSynapseHTTPChannel.OnAfterProbingServers Event

Fires after the channel is done probing all servers for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServers: TROEndProbeServersEvent;


See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSynapseHTTPChannel.OnBeforeProbingServer Event

Fires before the channel starts probing a specific server for availability.

Use Case

You can use this event to check or adjust the server configuration, or to include/exclude the server from being probed by changing the TROServerLocator.Enabled property.

See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServer: TROBeginProbeServerEvent;


See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSynapseHTTPChannel.OnBeforeProbingServers Event

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServers: TROBeginProbeServersEvent;


See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSynapseHTTPChannel.OnLoginNeeded Event

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

Use Case

The most common use for this event is to perform a call to a special Login service provided by the server (possibly after prompting the user to enter username ad password), and to set the aRetry parameter to true if login was successful.

See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic

Pascal

property OnLoginNeeded: TROExceptionEvent;


See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic


TROSynapseHTTPChannel.OnReceiveStream Event

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnReceiveStream: TStreamDispatch;


See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROSynapseHTTPChannel.OnSendStream Event

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnSendStream: TStreamDispatch;


See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROSynapseHTTPChannel.ProbeFrequency Property

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

Notes

Although somewhat misnamed, this property defines the Interval between probes, not the actual probing Frequency. The property name is persisted for backward compatibility, we apologize.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeFrequency: cardinal;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSynapseHTTPChannel.ProbeServers Property

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeServers: boolean;


See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSynapseHTTPChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TROSynapseHTTPChannel.SynchronizedProbing Property

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property SynchronizedProbing: Boolean;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROSynapseHTTPChannel.TargetURL Property

Specifies the address of the server to talk to.

By default, this is usually he host name of your server, followed by the 8099, plus the name of the dispatcher configured on the server; for example http://myserver:8099/bin.

Pascal

property TargetURL: string;


TROSynchronizedSingletonClassFactory Class

This class provides a class factory that implements the Singleton pattern: only one instance of the service class will ever be created, and this same class will be used to service all requests.

In contrast to its base class, the TROSingletonClassFactory, this factory will not allow simultaneous access by several clients. Instead, access will by synchronized using a critical section, to make sure only one request executes at the same time.

Use Case

Use this class factory if you intend for data stored in the service class to be shared by all callers and you do not want to handle synchronization and thread-safe access to this data yourself in code.

Class Hierarchy

Notes

By its very nature, this class factory will serialize requests from all clients and only ever execute one request at a time. Thus, using this class factory will result in your service not scaling up to large number of clients, as client requests will block each other.

If you are expecting your server to scale up beyond "a few" clients and still need to share global data between clients, it is recommended to implement manual and more finely-tuned synchronization for this data access within your service code.

File

uROClassFactories

See Also

TROSingletonClassFactory class

TROClassFactory, TROPooledClassFactory and TROPerClientClassFactory classes

Class Factories and RODL Files help topics

Statelessness help topic

Pascal

TROSynchronizedSingletonClassFactory = class(TROSingletonClassFactory);


TROSynchronizedSingletonClassFactory Class Methods

Methods

 Create

Creates a new instance of the class factory

 CreateInstance

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

 ReleaseInstance

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.


Legend

Constructor

protected

virtual


Legend

Legend

Constructor

protected

virtual


TROSynchronizedSingletonClassFactory Class Members

Members

Methods

 Create

Creates a new instance of the class factory

 CreateInstance

This virtual method of the class factory is created whenever a new request from a client needs to be served, in order to return the service instance to serve the request.

Whether the returned instance is actually created anew or obtained otherwise will depend on the type of class factory.

 ReleaseInstance

This virtual method of the class factory is created whenever a service instance previously acquired via CreateInstance has finished processing a request.

Whether the returned instance is actually destroyed or saved for future use will depend on the type of class factory.


Legend

Constructor

protected

virtual


See Also

TROSingletonClassFactory class

TROClassFactory, TROPooledClassFactory and TROPerClientClassFactory classes

Class Factories and RODL Files help topics

Statelessness help topic


TROTransportChannel Class

TROTransportChannel is the common base class for all client channel implementations in the RemObjects SDK.

You will not use instances of this class directly, but work with the descendant channel implementations. Please refer to the Channels help topic, for a complete overview of available channels and their compatible servers.

Class Hierarchy

File

uROClient

See Also

Channels help topic

Pascal

TROTransportChannel = class(TROBaseConnection, IROTransportChannel, IROTransport, IROMetadataReader);


TROTransportChannel Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.


Legend

Property

read only


TROTransportChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROTransportChannel Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels help topic


TROTransportChannel.Busy Property

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

See Also

EROChannelBusy exception

Super TCP Channel help topic

Pascal

property Busy: boolean;


See Also

EROChannelBusy exception

Super TCP Channel help topic


TROTransportChannel.CurrentLocator Property

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

See Also

ServerLocators and DispatchOptions properties

Pascal

property CurrentLocator: TROServerLocator;


See Also

ServerLocators and DispatchOptions properties


TROTransportChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TROTransportChannel.OnAfterProbingServer Event

Fires after the channel is done probing a specific server for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServer: TROEndProbeServerEvent;


See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROTransportChannel.OnAfterProbingServers Event

Fires after the channel is done probing all servers for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServers: TROEndProbeServersEvent;


See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROTransportChannel.OnBeforeProbingServer Event

Fires before the channel starts probing a specific server for availability.

Use Case

You can use this event to check or adjust the server configuration, or to include/exclude the server from being probed by changing the TROServerLocator.Enabled property.

See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServer: TROBeginProbeServerEvent;


See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROTransportChannel.OnBeforeProbingServers Event

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServers: TROBeginProbeServersEvent;


See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROTransportChannel.OnException Event

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

Use Case

Depending on the type of error, your event handler can try to rectify the problem, and set aRetry to true to have the channel try and perform the request again. For example, an application could show a dialog asking the user to confirm his internet connection is available, with Cancel and Retry buttons.

if aRetry is set to true and the call succeeds a the second attempt, the call will return to the original code that initiated the request, as if the exception never happened.

See Also

OnLoginNeeded event

TROMessage.OnServerException event

Pascal

property OnException: TROExceptionEvent;


See Also

OnLoginNeeded event

TROMessage.OnServerException event


TROTransportChannel.OnLoginNeeded Event

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

Use Case

The most common use for this event is to perform a call to a special Login service provided by the server (possibly after prompting the user to enter username ad password), and to set the aRetry parameter to true if login was successful.

See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic

Pascal

property OnLoginNeeded: TROExceptionEvent;


See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic


TROTransportChannel.OnProgress Event

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

Use Case

You can use this event to keep the user interface updated during lengthy transfers, for example by showing a progress bar or the remaining transfer volume.

Notes

Note that the accuracy and frequency of calls to OnProgress depends on the channel type; since channels transport data packets in different sized chunks (or even all-at-once), OnProgress might show a very fine progress for some channels, while jumping from 0 to 100% in one step with others.

Pascal

property OnProgress: TProgressEvent;


TROTransportChannel.OnReceiveStream Event

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnReceiveStream: TStreamDispatch;


See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROTransportChannel.OnSendStream Event

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnSendStream: TStreamDispatch;


See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROTransportChannel.ProbeFrequency Property

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

Notes

Although somewhat misnamed, this property defines the Interval between probes, not the actual probing Frequency. The property name is persisted for backward compatibility, we apologize.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeFrequency: cardinal;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROTransportChannel.ProbeServers Property

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeServers: boolean;


See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROTransportChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TROTransportChannel.SynchronizedProbing Property

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property SynchronizedProbing: Boolean;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWebBrokerServer Class

TROWebBrokerPServer implements an HTTP server based on Delphi's WebBroker infrastructure.

The resulting server is a not a standalone server, but a ISAPI/NSAPI, Apache DSO or CGI module that can be hosted in an existing web server such as IIS or Apache.

Essential Properties 	Active toggles whether the server ready to receive requests from clients, or not.

Dispatchers specifies how incoming requests will be processed and dispatched.

Class Hierarchy

File

uROWebBrokerServer

See Also

Channels and HTTP Channels help topics

TROIndyHTTPServer and TROBPDXHTTPServer components

Pascal

TROWebBrokerServer = class(TROServer, IROTransport, IROTCPTransport, IROHTTPTransport);


TROWebBrokerServer Class Properties

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROWebBrokerServer Class

 SendExceptionsAs500

Specifies whether exception messages will be sent back using a HTTP "500" error code (true, default), or a standard "200" message code (false).


Legend

Property

read only


TROWebBrokerServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

read only

Event


TROWebBrokerServer Class Members

Members

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROWebBrokerServer Class

 SendExceptionsAs500

Specifies whether exception messages will be sent back using a HTTP "500" error code (true, default), or a standard "200" message code (false).

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

read only

Event


See Also

Channels and HTTP Channels help topics

TROIndyHTTPServer and TROBPDXHTTPServer components


TROWebBrokerServer.SendExceptionsAs500 Property

Specifies whether exception messages will be sent back using a HTTP "500" error code (true, default), or a standard "200" message code (false).

Use Case

Some proxy servers might perform special handling on 500 error messages that will prevent exception messages sent back as 500 to be recognized properly. If you are seeing this problem, try setting this property to false. If not, it is recommended to keep the default value.

Pascal

property SendExceptionsAs500: boolean;


TROWinInetHTTPChannel Class

TROWinInetHTTPChannel implements an HTTP based channel that uses the WinInet HTTP implementation provided by the Windows operating system.

As such, the channel will automatically make use of options such as proxy and firewall settings, and the online/offline state configured for Internet Explorer or using the Internet Control Panel. It is the most commonly used and recommended HTTP channel.

Essential Properties

TargetURL specifies the address of the server to talk to.

Class Hierarchy

Notes

For obvious reasons, TROWinInetHTTPChannel is only supported under Windows, and not available for Kylix or when compiling for Linux using Free Pascal.

File

uROWinInetHttpChannel

See Also

Channels and HTTP Channels help topics

TROIndyHTTPChannel and TROSynapseHTTPChannel components

Pascal

TROWinInetHTTPChannel = class(TROTransportChannel, IROTransport, IROTCPTransport, IROHTTPTransport);


TROWinInetHTTPChannel Class Properties

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROWinInetHTTPChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Login

Specifies the username and password that should be used to authenticate with the server.

This login is used for HTTP-level authentication only. It should be set if your web server (or proxy server) is configured to require login at HTTP level to accept communication. This is not to be confused with the RemObjects SDK's own login on session level, discussed in the Login and Authentication help topic.

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

 TargetURL

Specifies the address of the server to talk to.

By default, this is usually he host name of your server, followed by the 8099, plus the name of the dispatcher configured on the server; for example http://myserver:8099/bin.

 Timeout

Specifies the timeout, in milliseconds, after which a request will be aborted if no response has been received. The default value is 600,000 (10 minutes).

If you are expecting long processing times on your server, make sure to adjust this timeout accordingly.

 UserAgent

Specifies the User Agent string to be sent to the server in the HTTP header.


Legend

Property

read only


TROWinInetHTTPChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROWinInetHTTPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROWinInetHTTPChannel Class Members

Members

Properties

 ClientAddress

TROBaseConnection Class

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROWinInetHTTPChannel Class

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 Login

Specifies the username and password that should be used to authenticate with the server.

This login is used for HTTP-level authentication only. It should be set if your web server (or proxy server) is configured to require login at HTTP level to accept communication. This is not to be confused with the RemObjects SDK's own login on session level, discussed in the Login and Authentication help topic.

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

 TargetURL

Specifies the address of the server to talk to.

By default, this is usually he host name of your server, followed by the 8099, plus the name of the dispatcher configured on the server; for example http://myserver:8099/bin.

 Timeout

Specifies the timeout, in milliseconds, after which a request will be aborted if no response has been received. The default value is 600,000 (10 minutes).

If you are expecting long processing times on your server, make sure to adjust this timeout accordingly.

 UserAgent

Specifies the User Agent string to be sent to the server in the HTTP header.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROWinInetHTTPChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels and HTTP Channels help topics

TROIndyHTTPChannel and TROSynapseHTTPChannel components


TROWinInetHTTPChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TROWinInetHTTPChannel.Login Property

Specifies the username and password that should be used to authenticate with the server.

This login is used for HTTP-level authentication only. It should be set if your web server (or proxy server) is configured to require login at HTTP level to accept communication. This is not to be confused with the RemObjects SDK's own login on session level, discussed in the Login and Authentication help topic.

See Also

Login and Authentication help topic

Pascal

property Login: TROLogin;


See Also

Login and Authentication help topic


TROWinInetHTTPChannel.OnAfterProbingServer Event

Fires after the channel is done probing a specific server for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServer: TROEndProbeServerEvent;


See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinInetHTTPChannel.OnAfterProbingServers Event

Fires after the channel is done probing all servers for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServers: TROEndProbeServersEvent;


See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinInetHTTPChannel.OnBeforeProbingServer Event

Fires before the channel starts probing a specific server for availability.

Use Case

You can use this event to check or adjust the server configuration, or to include/exclude the server from being probed by changing the TROServerLocator.Enabled property.

See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServer: TROBeginProbeServerEvent;


See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinInetHTTPChannel.OnBeforeProbingServers Event

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServers: TROBeginProbeServersEvent;


See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinInetHTTPChannel.OnLoginNeeded Event

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

Use Case

The most common use for this event is to perform a call to a special Login service provided by the server (possibly after prompting the user to enter username ad password), and to set the aRetry parameter to true if login was successful.

See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic

Pascal

property OnLoginNeeded: TROExceptionEvent;


See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic


TROWinInetHTTPChannel.OnProgress Event

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

Use Case

You can use this event to keep the user interface updated during lengthy transfers, for example by showing a progress bar or the remaining transfer volume.

Notes

Note that the accuracy and frequency of calls to OnProgress depends on the channel type; since channels transport data packets in different sized chunks (or even all-at-once), OnProgress might show a very fine progress for some channels, while jumping from 0 to 100% in one step with others.

Pascal

property OnProgress: TProgressEvent;


TROWinInetHTTPChannel.OnReceiveStream Event

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnReceiveStream: TStreamDispatch;


See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROWinInetHTTPChannel.OnSendStream Event

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnSendStream: TStreamDispatch;


See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROWinInetHTTPChannel.ProbeFrequency Property

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

Notes

Although somewhat misnamed, this property defines the Interval between probes, not the actual probing Frequency. The property name is persisted for backward compatibility, we apologize.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeFrequency: cardinal;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinInetHTTPChannel.ProbeServers Property

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeServers: boolean;


See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinInetHTTPChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TROWinInetHTTPChannel.SynchronizedProbing Property

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property SynchronizedProbing: Boolean;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinInetHTTPChannel.TargetURL Property

Specifies the address of the server to talk to.

By default, this is usually he host name of your server, followed by the 8099, plus the name of the dispatcher configured on the server; for example http://myserver:8099/bin.

Pascal

property TargetURL: string;


TROWinInetHTTPChannel.Timeout Property

Specifies the timeout, in milliseconds, after which a request will be aborted if no response has been received. The default value is 600,000 (10 minutes).

If you are expecting long processing times on your server, make sure to adjust this timeout accordingly.

Pascal

property Timeout: Integer;


TROWinInetHTTPChannel.UserAgent Property

Specifies the User Agent string to be sent to the server in the HTTP header.

Use Case

This string is sent for informational purposes only; you can set it to a custom value to detect and distinguish your client (as opposed to other client applications or web browsers accessing the server) in server log files or HTTP packet monitors.

Pascal

property UserAgent: string;


TROWinMessageChannel Class

TROWinMessageChannel implements a channel that uses Windows Messages to communicate between a client and a server on the same local machine.

Essential Properties

ServerID specifies the unique ID of the server to communicate with.

Relevant Properties

StartServer specifies whether the server should automatically be started, if it's not already running.

Class Hierarchy

File

uROWinMessageChannel

See Also

Channels and WinMessage Channel help topics

Pascal

TROWinMessageChannel = class(TROTransportChannel, IROActiveEventChannel);


TROWinMessageChannel Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROWinMessageChannel Class

 DefaultDirectory

Specifies the default directory to use when launching the server if the StartServer property is set to true.

 Delay

Specifies the time, in milliseconds, that the channel should wait after launching if the StartServer property is set to true. Default is 0.

Using this delay, you can fire the server process time to load and initialize, if necessary.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 FileName

Specifies the name of the executable to launch if the StartServer property is set to true.

 Parameters

Specifies the parameters to pass when launching the server if the StartServer property is set to true.

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerID

Specifies the unique ID of the server to communicate with. This must match the ServerID specified on the TROWinMessageServer in the server application.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 StartServer

Specifies whether the server should automatically be started by launching the executable specified in FileName, if it's not already running.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.


Legend

Property

read only


TROWinMessageChannel Class Events

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROWinMessageChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Event


Legend

Legend

Property

read only

Event


TROWinMessageChannel Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROTransportChannel Class

 Busy

Returns whether the channel is currently busy executing a remote request (true) or not (false).

Most channels (except most notably the Super TCP Channel) are only capable of performing one request at a time; if a second request is attempted while the channel is Busy, an EROChannelBusy exception will be raised

 CurrentLocator

Returns which of the fail-over/load balancing servers configured in the ServerLocators is currently active.

Depending on the defined DispatchOptions, this value might change with each request, or only if the current server fails.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

TROWinMessageChannel Class

 DefaultDirectory

Specifies the default directory to use when launching the server if the StartServer property is set to true.

 Delay

Specifies the time, in milliseconds, that the channel should wait after launching if the StartServer property is set to true. Default is 0.

Using this delay, you can fire the server process time to load and initialize, if necessary.

 DispatchOptions

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:

 FileName

Specifies the name of the executable to launch if the StartServer property is set to true.

 Parameters

Specifies the parameters to pass when launching the server if the StartServer property is set to true.

 ProbeFrequency

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

 ProbeServers

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 ServerID

Specifies the unique ID of the server to communicate with. This must match the ServerID specified on the TROWinMessageServer in the server application.

 ServerLocators

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

 StartServer

Specifies whether the server should automatically be started by launching the executable specified in FileName, if it's not already running.

 SynchronizedProbing

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

Events

TROTransportChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnException

Fires if an exception is raised during the execution of a remote request. This could be an exception returned from the server, a communication problem or an error within the client.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnProgress

This event fires as the channel is transferring data for a request or response to or from the server, informing of the current progress.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

TROWinMessageChannel Class

 OnAfterProbingServer

Fires after the channel is done probing a specific server for availability.

 OnAfterProbingServers

Fires after the channel is done probing all servers for availability.

 OnBeforeProbingServer

Fires before the channel starts probing a specific server for availability.

 OnBeforeProbingServers

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

 OnLoginNeeded

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

 OnReceiveStream

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnSendStream

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.


Legend

Property

read only

Event


See Also

Channels and WinMessage Channel help topics


TROWinMessageChannel.DefaultDirectory Property

Specifies the default directory to use when launching the server if the StartServer property is set to true.

See Also

StartServer, FileName, Parameters and Delay properties

Pascal

property DefaultDirectory: string;


See Also

StartServer, FileName, Parameters and Delay properties


TROWinMessageChannel.Delay Property

Specifies the time, in milliseconds, that the channel should wait after launching if the StartServer property is set to true. Default is 0.

Using this delay, you can fire the server process time to load and initialize, if necessary.

See Also

StartServer and FileName properties

Pascal

property Delay: word;


See Also

StartServer and FileName properties


TROWinMessageChannel.DispatchOptions Property

This property configures the available fail-over and load balancing options provided by the RemObjects SDK.

By default, channels are set up to talk to one specific server only. Two independent options are available to provide fail-over and load balancing:
Value	Meaning
doFaultTolerant	Enables fail-over support. If the connection to any given server fails, the cannel will automatically keep trying the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

Notes

Note that enabling any of these options obviously expects the server to be implemented in a stateless way, so that it does not depend on all requests from a client going to the same server. This implies using a class factory different than the Per-Client one, and - if sessions are used - a session manager that allows sharing of session state between servers.

See Also

ServerLocators property

Failover and Load Balancing help topic

Pascal

property DispatchOptions: TRODispatchOptions;


See Also

ServerLocators property

Failover and Load Balancing help topic


TROWinMessageChannel.FileName Property

Specifies the name of the executable to launch if the StartServer property is set to true.

See Also

StartServer, Parameters, DefaultDirectory and Delay properties

Pascal

property FileName: string;


See Also

StartServer, Parameters, DefaultDirectory and Delay properties


TROWinMessageChannel.OnAfterProbingServer Event

Fires after the channel is done probing a specific server for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServer: TROEndProbeServerEvent;


See Also

OnBeforeProbingServer and OnAfterProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinMessageChannel.OnAfterProbingServers Event

Fires after the channel is done probing all servers for availability.

Use Case

You can use this event to check the result of the probing, possibly to update internal data structures to or to display server status in the user interface.

See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnAfterProbingServers: TROEndProbeServersEvent;


See Also

OnBeforeProbingServers and OnAfterProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinMessageChannel.OnBeforeProbingServer Event

Fires before the channel starts probing a specific server for availability.

Use Case

You can use this event to check or adjust the server configuration, or to include/exclude the server from being probed by changing the TROServerLocator.Enabled property.

See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServer: TROBeginProbeServerEvent;


See Also

OnAfterProbingServer and OnBeforeProbingServers events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinMessageChannel.OnBeforeProbingServers Event

Fires before the channel starts probing all servers for availability.

Use Case

You can use this event to check or adjust the server configurations, or to include/exclude individual servers from being probed by changing their TROServerLocator.Enabled property.

See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property OnBeforeProbingServers: TROBeginProbeServersEvent;


See Also

OnAfterProbingServers and OnBeforeProbingServer events

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinMessageChannel.OnLoginNeeded Event

Fires if an EROSessionNotFound (or the descendant SessionNotFoundException) exception is raised during the execution of a remote request.

This usually indicates that the server requires a special Login call to authenticate the client, before allowing access to the method.

Use Case

The most common use for this event is to perform a call to a special Login service provided by the server (possibly after prompting the user to enter username ad password), and to set the aRetry parameter to true if login was successful.

See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic

Pascal

property OnLoginNeeded: TROExceptionEvent;


See Also

EROSessionNotFound and SessionNotFoundException exceptions

OnLoginNeeded event

Login and Authentication help topic


TROWinMessageChannel.OnReceiveStream Event

Fires after a stream with a response message has been received from the server.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnReceiveStream: TStreamDispatch;


See Also

OnSendStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROWinMessageChannel.OnSendStream Event

Fires just as a stream with a request message will be sent to the server.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the server.

See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event

Pascal

property OnSendStream: TStreamDispatch;


See Also

OnReceiveStream event

TROServer.OnReadFromStream and TROMessage.OnReadFromStream event


TROWinMessageChannel.Parameters Property

Specifies the parameters to pass when launching the server if the StartServer property is set to true.

See Also

StartServer, FileName, DefaultDirectory and Delay properties

Pascal

property Parameters: string;


See Also

StartServer, FileName, DefaultDirectory and Delay properties


TROWinMessageChannel.ProbeFrequency Property

Specifies at what intervals, in milliseconds, the channel will probe the servers configured in ServerLocators for availability. The default value is 60,000 (60 seconds).

Please refer to the ProbeServers property for a more detailed description.

Notes

Although somewhat misnamed, this property defines the Interval between probes, not the actual probing Frequency. The property name is persisted for backward compatibility, we apologize.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeFrequency: cardinal;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinMessageChannel.ProbeServers Property

Toggles whether the channel will continuously probe the servers configured in ServerLocators for availability.

If enabled (true), the channel will ping all servers at a regular interval to determine if they are reachable. If a server fails to respond, it will be disabled for future calls until a later probe can reach it again.

The interval between probes can be configured using the ProbeFrequency property.

By default, server probing is turned off.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property ProbeServers: boolean;


See Also

ProbeFrequency, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinMessageChannel.ServerID Property

Specifies the unique ID of the server to communicate with. This must match the ServerID specified on the TROWinMessageServer in the server application.

See Also

StartServer property

TROWinMessageServer.ServerID property

Pascal

property ServerID: string;


See Also

StartServer property

TROWinMessageServer.ServerID property


TROWinMessageChannel.ServerLocators Property

This collection property can optionally be filled to contain a list of possible servers to be used, for fail-over or load balancing purposes. Depending on the settings configured in DispatchOptions, the channel will automatically spread calls over the available servers, or fall back to another server if one fails.

Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic

Pascal

property ServerLocators: TROServerLocatorCollection;


See Also

DispatchOptions and CurrentLocator properties

Failover and Load Balancing help topic


TROWinMessageChannel.StartServer Property

Specifies whether the server should automatically be started by launching the executable specified in FileName, if it's not already running.

See Also

FileName, Parameters, DefaultDirectory and Delay properties

Pascal

property StartServer: boolean;


See Also

FileName, Parameters, DefaultDirectory and Delay properties


TROWinMessageChannel.SynchronizedProbing Property

Specifies whether server probing happens in the context of the main VCL thread (true, default) or in a background worker thread.

Please refer to the ProbeServers property for a more detailed description.

See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic

Pascal

property SynchronizedProbing: Boolean;


See Also

ProbeServers, DispatchOptions and ServerLocators properties

Failover and Load Balancing help topic


TROWinMessageServer Class

TROWinMessageChannel implements a server that uses Windows Messages to communicate between a client and a server on the same local machine.

Essential Properties

ServerID specifies the unique ID of the server.

Class Hierarchy

File

uROWinMessageServer

See Also

Channels and WinMessage Channel help topics

Pascal

TROWinMessageServer = class(TROServer, IROTransport, IROActiveEventServer);


TROWinMessageServer Class Properties

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROWinMessageServer Class

 ServerID

Specifies the unique ID of the server. This ID will be used by the client to uniquely identify the server among the several servers that might be running on a given system.

This ID can be any string, for example a human-readable name or a GUID.


Legend

Property


TROWinMessageServer Class Events

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Event


Legend

Legend

Property

Event


TROWinMessageServer Class Members

Members

Properties

 Encryption

Allows to control encryption and compression settings on a per server/channel basis.

Please refer to the TROEncryption class for more details on the available options.

TROServer Class

 Active

Toggles whether the server ready to receive requests from clients or not.

Depending on the server type, changing this property might open/close a network socket or otherwise toggle whether the server will process incoming requests or not.

 Dispatchers

Specifies how incoming requests will be processed and dispatched.

Depending on the server type, one or multiple dispatchers can be configured to receive messages from the client. Each dispatcher consists of a Message and an optional Name. Also, each dispatcher can be individually Enabled or disabled.

Each server must have at least one dispatcher configured, in order to be able to process messages.

 OnAfterServerActivate

Fires after the server has been activated.

 OnAfterServerDeactivate

Fires after the server has been deactivated.

 OnBeforeServerActivate

Fires just before the server is activated.

 OnBeforeServerDeactivate

Fires just before the server is deactivated.

TROWinMessageServer Class

 ServerID

Specifies the unique ID of the server. This ID will be used by the client to uniquely identify the server among the several servers that might be running on a given system.

This ID can be any string, for example a human-readable name or a GUID.

Events

TROServer Class

 OnReadFromStream

Fires after a stream with a request message has been received from the client.

The event handler can inspect and possibly modify the stream, before it continues to be processed by the higher levels of the RemObjects SDK framework.

 OnWriteToStream

Fires just before a stream with a response message is sent back to the client.

The event handler can inspect and possibly modify the stream, before it continues to be sent off to the client.


Legend

Property

Event


See Also

Channels and WinMessage Channel help topics


TROWinMessageServer.ServerID Property

Specifies the unique ID of the server. This ID will be used by the client to uniquely identify the server among the several servers that might be running on a given system.

This ID can be any string, for example a human-readable name or a GUID.

See Also

StartServer property

TROWinMessageChannel.ServerID property

Pascal

property ServerID: string;


See Also

StartServer property

TROWinMessageChannel.ServerID property


TROXmlRpcMessage Class

TROXmlRpcMessage implements message encoding using the XMLRPC protocol, a predecessor of SOAP and WebServices.

Please refer to the XML-RPC Message help topic for more details on this message format.

Essential Properties

None; The XML-RPC Message component is usable after being dropped from the component palette.

Class Hierarchy

File

uROXmlRpcMessage

See Also

Messages and XML-RPC Message help topics

Pascal

TROXmlRpcMessage = class(TROMessage);


TROXmlRpcMessage Class Properties

Properties

 ClientID

Contains the Client ID for the message.

 InterfaceName

Contains the name of the interface (service) that this message is calling.

 MessageName

Contains the name of the method that this message is calling.


Legend

Property


TROXmlRpcMessage Class Events

Events

 OnFinalizeMessage

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

 OnInitializeMessage

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

 OnReadFromStream

Fires before the message is read from the stream that was received over the network.

 OnReadMessageParameter

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnServerException

Fires if an exception message is received from the server.

 OnWriteException

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

 OnWriteMessageParameter

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnWriteToStream

Fires after the message was written to the stream that will be sent over the network.


Legend

Event


Legend

Legend

Property

Event


TROXmlRpcMessage Class Members

Members

Properties

 ClientID

Contains the Client ID for the message.

 InterfaceName

Contains the name of the interface (service) that this message is calling.

 MessageName

Contains the name of the method that this message is calling.

Events

 OnFinalizeMessage

Fires as a message object is getting finalized, to send a new request or response.

This happens after the entire message has been generated, all parameters have been added, and the message is ready to be sent off over the network.

 OnInitializeMessage

Fires as a message object is getting initialized, to send a new request or response.

This happens after the basic message options are set, but before any parameters or data have been stored in the message.

 OnReadFromStream

Fires before the message is read from the stream that was received over the network.

 OnReadMessageParameter

Fires after an individual message parameter has been read from the received message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnServerException

Fires if an exception message is received from the server.

 OnWriteException

Fires after an exception message was written to the stream that will be sent over the network. This event will fire in addition to (and before) the OnWriteToStream event.

 OnWriteMessageParameter

Fires before an individual message parameter will be written to the outgoing message.

The event call will include information about the name and type of the parameter, as well as an untyped pointer to the data.

 OnWriteToStream

Fires after the message was written to the stream that will be sent over the network.


Legend

Property

Event


See Also

Messages and XML-RPC Message help topics


IROAsyncInterface Interface

This interface provides control of the proxy object for an asynchronous service interface.

You can obtain this interface by casting a service interface from your auto-generated _Async unit to IROAsyncInterface.

Class Hierarchy

File

uROAsync

See Also

TROAsyncProxy class

Asynchronous Calls help topic

Pascal

IROAsyncInterface = interface;


IROAsyncInterface Interface Properties

Properties

 AnswerReceived

Specifies whether an answer has been received for the previous asynchronous request (true) or not (false).

You can use this property to poll the current status of the request. For example to enable a user interface option to retrieve the result.

 AnswerReceivedEvent

For channels that support active asynchronous results, this property returns a Win32 event object (wrapped inside a TEvent) that can be used to wait for an answer to the previous asynchronous request.

 Busy

Specifies whether the proxy is currently busy processing an asynchronous call (true) or not (false).

Asynchronous proxies are only capable of dispatching one asynchronous call at a time, and attempts to make a second call while the proxy is busy will result in an EROChannelBusy exception.

 MessageID

Contains the MessageID of the request currently being executed.

Since true asynchronous channels (such as the Super TCP Channel) can execute multiple requests at the same time, they assign an internal message to each request sent, to later match up the received response with the right request.


Legend

Property

read only


Legend

Legend

Property

read only


IROAsyncInterface Interface Members

Members

Properties

 AnswerReceived

Specifies whether an answer has been received for the previous asynchronous request (true) or not (false).

You can use this property to poll the current status of the request. For example to enable a user interface option to retrieve the result.

 AnswerReceivedEvent

For channels that support active asynchronous results, this property returns a Win32 event object (wrapped inside a TEvent) that can be used to wait for an answer to the previous asynchronous request.

 Busy

Specifies whether the proxy is currently busy processing an asynchronous call (true) or not (false).

Asynchronous proxies are only capable of dispatching one asynchronous call at a time, and attempts to make a second call while the proxy is busy will result in an EROChannelBusy exception.

 MessageID

Contains the MessageID of the request currently being executed.

Since true asynchronous channels (such as the Super TCP Channel) can execute multiple requests at the same time, they assign an internal message to each request sent, to later match up the received response with the right request.


Legend

Property

read only


See Also

TROAsyncProxy class

Asynchronous Calls help topic


IROAsyncInterface.AnswerReceived Property

Specifies whether an answer has been received for the previous asynchronous request (true) or not (false).

You can use this property to poll the current status of the request. For example to enable a user interface option to retrieve the result.

Notes

Note that depending on the channel type, querying this property can incur overhead. For example, the Email Channel will establish a connection to the POP3 server to check for a result message.

See Also

AnswerReceivedEvent property

Asynchronous Calls help topic

Pascal

property AnswerReceived: Boolean;


See Also

AnswerReceivedEvent property

Asynchronous Calls help topic


IROAsyncInterface.AnswerReceivedEvent Property

For channels that support active asynchronous results, this property returns a Win32 event object (wrapped inside a TEvent) that can be used to wait for an answer to the previous asynchronous request.

Notes

Note that this property is only available if the used channel implements the IROActiveAsyncTransportChannel interface and supports active asynchronous results (currently only the Super TCP Channel). For all other channels, the Boolean AnswerReceived property must be used.

See Also

AnswerReceived property

Asynchronous Calls help topic

Pascal

property AnswerReceivedEvent: TROEvent;


See Also

AnswerReceived property

Asynchronous Calls help topic


IROAsyncInterface.Busy Property

Specifies whether the proxy is currently busy processing an asynchronous call (true) or not (false).

Asynchronous proxies are only capable of dispatching one asynchronous call at a time, and attempts to make a second call while the proxy is busy will result in an EROChannelBusy exception.

See Also

TROTransportChannel.Busy property

EROChannelBusy exception

Pascal

property Busy: Boolean;


See Also

TROTransportChannel.Busy property

EROChannelBusy exception


IROAsyncInterface.MessageID Property

Contains the MessageID of the request currently being executed.

Since true asynchronous channels (such as the Super TCP Channel) can execute multiple requests at the same time, they assign an internal message to each request sent, to later match up the received response with the right request.

Use Case

While not relevant to the user in most scenarios, this property allows to persist the message ID of an ongoing request for later use. For example, a client application could initiate a lengthy process on the server, store the Message ID in an .ini file, and shut down. The application could then be restarted at a later time, reload the Message ID and obtain the result.

Note that this scenario is only possible for channels that are capable of storing the result for later retrieval, such as the Email Channel or the Super TCP Channel.

See Also

Email Channel and Super TCP Channel help topics

Pascal

property MessageID: string;


See Also

Email Channel and Super TCP Channel help topics


IROEventWriter Interface

IROEventsWriter forms the base interface for Event Sink proxies on the server.

It contains a number of properties that allow you to control how events are dispatched to clients.

Class Hierarchy

File

uROClientIntf

See Also

Event Sinks and Server Callbacks help topic

Pascal

IROEventWriter = interface;


IROEventWriter Interface Properties

Properties

 ExcludeSender

Specifies whether the sender that originated the event will be included in the list of recipients. If set to false (default), an even will be dispatched to all registered recipients except the one that originated the event (i.e. in whose session context the event is being fired).

 ExcludeSessionList

Allows to optionally specify a list if recipient session IDs that should not receive the event.

 SessionList

Allows to optionally specify a list if recipient session IDs that should receive the event. If empty, the event will be sent to all registered clients (except those listed in the ExcludeSessionList property).


Legend

Property

read only


Legend

Legend

Property

read only


IROEventWriter Interface Members

Members

Properties

 ExcludeSender

Specifies whether the sender that originated the event will be included in the list of recipients. If set to false (default), an even will be dispatched to all registered recipients except the one that originated the event (i.e. in whose session context the event is being fired).

 ExcludeSessionList

Allows to optionally specify a list if recipient session IDs that should not receive the event.

 SessionList

Allows to optionally specify a list if recipient session IDs that should receive the event. If empty, the event will be sent to all registered clients (except those listed in the ExcludeSessionList property).


Legend

Property

read only


See Also

Event Sinks and Server Callbacks help topic


IROEventWriter.ExcludeSender Property

Specifies whether the sender that originated the event will be included in the list of recipients. If set to false (default), an even will be dispatched to all registered recipients except the one that originated the event (i.e. in whose session context the event is being fired).

Pascal

property ExcludeSender: boolean;


IROEventWriter.ExcludeSessionList Property

Allows to optionally specify a list if recipient session IDs that should not receive the event.

See Also

SessionList property

Pascal

property ExcludeSessionList: boolean;


See Also

SessionList property


IROEventWriter.SessionList Property

Allows to optionally specify a list if recipient session IDs that should receive the event. If empty, the event will be sent to all registered clients (except those listed in the ExcludeSessionList property).

See Also

ExcludeSessionList property

Pascal

property SessionList: TStrings;


See Also

ExcludeSessionList property


IROStream Interface

The IROStream interface wraps access to a Delphi TStrean instance to provide a reference-counted, interface-based reference that can be freed automatically as it goes out of scope.

IROStream exposes all the basic methods and properties of TStream, and also exposes the underlying wrapped object via the Stream property. Use one of the overloads of the global NewROStream function to instantiate a new IROStream instance.

Class Hierarchy

File

uROClasses

See Also

Stream property

NewROStream function

Pascal

IROStream = interface;


IROStream Interface Properties

Properties

 Stream

Exposes the underlying TStream instance wrapped by this IROStream interface.


Legend

Property

read only


Legend

Legend

Property

read only


IROStream Interface Members

Members

Properties

 Stream

Exposes the underlying TStream instance wrapped by this IROStream interface.


Legend

Property

read only


See Also

Stream property

NewROStream function


IROStream.Stream Property

Exposes the underlying TStream instance wrapped by this IROStream interface.

Pascal

property Stream: TStream;


IROStrings Interface

The IROStrings interface wraps access to a Delphi TStrings instance to provide a reference-counted, interface-based reference that can be freed automatically as it goes out of scope.

IROStrings exposes all the basic methods and properties of TStrings, and also exposes the underlying wrapped object via the Strings property. Use one of the overloads of the global NewROStrings function to instantiate a new IROStrings instance.

Class Hierarchy

File

uROClasses

See Also

Strings property

NewROStrings function

Pascal

IROStrings = interface;


IROStrings Interface Properties

Properties

 Strings

Exposes the underlying TString instance wrapped by this IROString interface.


Legend

Property

read only


Legend

Legend

Property

read only


IROStrings Interface Members

Members

Properties

 Strings

Exposes the underlying TString instance wrapped by this IROString interface.


Legend

Property

read only


See Also

Strings property

NewROStrings function


IROStrings.Strings Property

Exposes the underlying TString instance wrapped by this IROString interface.

Pascal

property Strings: TStrings;


IROTCPTransport Interface

File

uROClientIntf

Pascal

IROTCPTransport = interface(IROTransport);


IROTCPTransport Interface Properties

Properties

 ClientAddress


Legend

Property

read only


Legend

Legend

Property

read only


IROTCPTransport Interface Members

Members

Properties

 ClientAddress


Legend

Property

read only


IROTCPTransport.ClientAddress Property

property ClientAddress: string;


TRODataType Enumeration

This enum lists all the data types that are supported for remoting by the RemObjects SDK, with the exception of custom arrays and custom structs, which are both represented by the rtUserDefined value.

Please refer to the Data Types help topic for a detailed description of all supported types.

File

uROTypes

See Also

TRORequestParam.DataType property

Data Types help topic

Pascal

TRODataType = (
);


See Also

TRORequestParam.DataType property

Data Types help topic


TRODispatchOption Enumeration

This enum provides the different options used to configure failover and load balancing
Value	Meaning
doFaultTolerant	Enables failover support. If the connection to any given server fails, the cannel will automatically try connecting the next server specified in ServerLocators, until a working server is found or all servers have been tried.
doLoadBalanced	Enables load-balancing support. Each request dispatched through the channel will go to a different server configured in ServerLocators, resulting in calls being more or less equally distributed over the available servers.
Please refer to the Failover and Load Balancing help topic for a more detailed discussion of the topic.

File

uROClient

See Also

TROTransportChannel.DispatchOptions

Failover and Load Balancing help topic

Pascal

TRODispatchOption = (
);


See Also

TROTransportChannel.DispatchOptions

Failover and Load Balancing help topic


TRODLParamFlag Enumeration

This enum defines the different flags (or directions) that can be applied to a parameter:
Value	Meaning
fIn	This parameter is uni-directional and will only be passed into the method.
fOut	This parameter is uni-directional and will only be passed back out of the method.
fInOut	This parameter is bi-directional and will only be passed both into the method and back out with a (possibly) different value.
fResult	This parameter is uni-directional and will only be passed back out of the method. In contrast to an fOut parameter, this parameter will be represented as the function result, on the code level.
File

uRODL

See Also

TRORequestParam.Flag property

Pascal

TRODLParamFlag = (
);


See Also

TRORequestParam.Flag property


TROPoolBehavior Enumeration

Determines how the TROPooledClassFactory behaves when more simultaneous calls than can be served by the objects in the pool, come in.
pbCreateAdditional	Will cause the class factory to create additional instances of the server object, when more calls come in than there are objects in the pool. These additional objects will not be pooled, but will be destroyed immediately after the call they are serving is completed. For example, if you have a pool size of 10, and 15 calls come in simultaneously, the first 10 calls will be served by objects from the pool and 5 additional objects will be created to serve the remaining calls. The first ten objects will be returned to the pool when their calls have completed, while the remaining 5 objects will simply be freed. The order in which the calls complete does not affect which objects will be placed in the pool; the objects that were taken from the pool will be placed back and all the additionally created objects will be freed, even if their calls return earlier and there would be pool slots available.
pbFail	Will cause the class factory to fail all calls that exceed the pool size. For example, if you have a pool size of 10, and 15 calls come in simultaneously, then the first ten calls are served with the objects from the pool, while the remaining 5 calls will get aborted with an EROPoolNoFreeObjects exception. This exception will be propagated to the server and re-raised there. The pbFail mode is useful if you want to limit your server to a specific number of simultaneous calls - for example to enforce a licence restriction on your server application, or if your server objects work with a limited number of resources.
pbWait	Will cause the class factory to put all calls that exceed the pool size on hold. For example, with a pool size of 10 and 15 calls coming in simultaneously, the first ten calls will be served by the objects from the pool, the remaining 5 calls will be paused. Once the first of the 10 calls returns, one of the 5 waiting calls is awakened and served by the object that just became available, and so on.
File

uROClassFactories

See Also

Class Factories help topic

TROPooledClassFactory class

EROPoolNoFreeObjects exception

Pascal

TROPoolBehavior = (
);


See Also

Class Factories help topic

TROPooledClassFactory class

EROPoolNoFreeObjects exception


TROPostMessageBinaryType Enumeration

Specifies what format is used to encode binary data, Hex or Base64.
Value	Meaning
btInlineBase64	Binary data will be encoded as a Base-64 character stream
btInlineHex	Binary data will be encoded as a Hex character stream
File

uROPostMessage

See Also

TROPostMessage component

Pascal

TROPostMessageBinaryType = (
);


See Also

TROPostMessage component


TROProbingOption Enumeration

This enum provides the different options how sever will be handled during probing.
Value	Meaning
poProbeWhenEnabled	Include this server in probing, if it's already enabled
poProbeWhenDisabled	Include this server in probing, if it's currently disabled. Activating this option is the only way a once-disabled server will ever be automatically re-enabled.
poEnableIfProbeSucceeded	(Re-)enable the server if it was successfully probed. Activating this option is the only way a once-disabled server will ever be automatically re-enabled.
poDisableIfProbeFailed	Disable this server if probing failed. (see also DisableOnFailure)
File

uROClientIntf

See Also

TROServerLocator.ProbingOptions property

Pascal

TROProbingOption = (
);


See Also

TROServerLocator.ProbingOptions property


TROXMLSerializationOption Enumeration

Defines several options used to control the exact layout of SOAP messages.
Value	Meaning
xsoWriteMultiRefArray	If this option is present, elements of the arrays will be written as tagged nodes outside of the regular SOAP value tag.
xsoWriteMultiRefObject	If this option is present, structs will be written as tagged nodes outside of the regular SOAP value tag.
xsoSendUntyped	If this option is present, type information will not be included in the envelope.
xsoStrictStructureFieldOrder	If this option is present, fields of structs will be streamed in the exact order they were defined, rather than alphabetically.
xsoIgnoreStructureType	If this option is present, type information from received messages will be ignored, and the exact types defined in RODL will be instantiated.
File

uROXMLSerializer

See Also

TROSOAPMessage component

Pascal

TROXMLSerializationOption = (
);


See Also

TROSOAPMessage component


Functions

This section lists global procedures and functions included as part of the RemObjects SDK library. While the RemObjects SDK is largely object oriented sand class based, these functions are provided as helper functions or to register/unregister types with the library.


Functions

Functions

 NewROStream

Creates and returns a new IROStream implementation.

Overloads that wrap an existing stream, or create a new wrapped memory stream, are provided.

 NewROStrings

Creates and returns a new IROStrings implementation.

Overloads that wrap an existing TStrings instance, or create a new wrapped TStringList, are provided.

 NewROXmlDocument

Creates and returns a new IXMLDocument implementation.

Depending on the platform (Delphi vs. Kylix) and the configured conditional defines, the XML document will be either based on Microsoft's MSXML implementation or OpenXML.

 RegisterExceptionClass

Registers an Exception class for streaming from servers to clients so that exceptions of this type can be seamlessly re-raised client side.

Usually, RegisterExceptionClass is called for you in the Intf code generated from your RODL file; however you can also call it to register custom exception classes you created in code, if they descend from EROServerException.

 RegisterMessageClass

Registers a TROMessage descendant so that it shows up in the IDE Wizards.

When implementing a new server, you should use this method in the initialization section to make the channel available at design time.

 RegisterROClass

Registers a "complex type" class for streaming between clients and servers.

Usually, RegisterROClass is called for you in the Intf code generated from your RODL file; however you can also call it to register custom exception classes you created in code, if they descend from TROComplexType.

 RegisterServerClass

Registers a TROServer descendant so that it shows up in the IDE Wizards.

When implementing a new server, you should use this method in the initialization section to make the channel available at design time.

 RegisterTransportChannelClass

Registers a TROTransportChannel descendant so that it shows up in the IDE Wizards.

When implementing a new channel, you should use this method in the initialization section to make the channel available at design time.

 ROSendNoResponse

Call this function at the end of your server implementation to return from an asynchronous call without sending a response message.

This is helpful when using asynchronous requests for notifications or to trigger actions on the server, but no information or acknowledgement is expected or needed on the client.

 UnregisterExceptionClass

Registers an exception class that was previously registered via RegisterExceptionClass.

 UnregisterMessageClass

Unregisters a TROMessage descendant that was previously registered with RegisterServerClass.

When implementing a new server, you should use this method in the finalization section.

 UnregisterROClass

Unregisters a "complex type" class that was previously registered via RegisterROClass.

 UnregisterServerClass

Unregisters a TROServer descendant that was previously registered with RegisterServerClass.

When implementing a new server, you should use this method in the finalization section.

 UnregisterTransportChannelClass

Unregisters a TROTransportChannel descendant that was previously registered with RegisterTransportChannelClass.

When implementing a new channel, you should use this method in the finalization section.


Legend

Method


Legend

Legend

Method


NewROStream Function

Creates and returns a new IROStream implementation.

Overloads that wrap an existing stream, or create a new wrapped memory stream, are provided.

File

uROClasses

See Also

IROStream interface

Pascal

function NewROStream: IROStream; overload;


See Also

IROStream interface


NewROStrings Function

Creates and returns a new IROStrings implementation.

Overloads that wrap an existing TStrings instance, or create a new wrapped TStringList, are provided.

File

uROClasses

See Also

IROStrings interface

Pascal

function NewROStrings: IROStrings; overload;


See Also

IROStrings interface


NewROXmlDocument Function

Creates and returns a new IXMLDocument implementation.

Depending on the platform (Delphi vs. Kylix) and the configured conditional defines, the XML document will be either based on Microsoft's MSXML implementation or OpenXML.

File

uROXMLIntf

See Also

IXMLDocument interface

Pascal

function NewROXmlDocument: IXMLDocument;


See Also

IXMLDocument interface


RegisterExceptionClass Function

Registers an Exception class for streaming from servers to clients so that exceptions of this type can be seamlessly re-raised client side.

Usually, RegisterExceptionClass is called for you in the Intf code generated from your RODL file; however you can also call it to register custom exception classes you created in code, if they descend from EROServerException.

File

uROClient

See Also

EROServerException exception

UnregisterExceptionClass and RegisterROClass procedures

Pascal

procedure RegisterExceptionClass(anExceptionClass: ExceptionClass);


See Also

EROServerException exception

UnregisterExceptionClass and RegisterROClass procedures


RegisterMessageClass Function

Registers a TROMessage descendant so that it shows up in the IDE Wizards.

When implementing a new server, you should use this method in the initialization section to make the channel available at design time.

File

uROClient

See Also

TROMessage class

UnregisterMessageClass, RegisterTransportChannelClass, RegisterServerClass procedures

Pascal

procedure RegisterMessageClass(aROMessageClass: TROMessageClass);


See Also

TROMessage class

UnregisterMessageClass, RegisterTransportChannelClass, RegisterServerClass procedures


RegisterROClass Function

Registers a "complex type" class for streaming between clients and servers.

Usually, RegisterROClass is called for you in the Intf code generated from your RODL file; however you can also call it to register custom exception classes you created in code, if they descend from TROComplexType.

File

uROTypes

See Also

TROComplexType class

UnregisterROClass and RegisterExceptionClass procedures

Pascal

procedure RegisterROClass(aComplexTypeClass: TROComplexTypeClass);


See Also

TROComplexType class

UnregisterROClass and RegisterExceptionClass procedures


RegisterServerClass Function

Registers a TROServer descendant so that it shows up in the IDE Wizards.

When implementing a new server, you should use this method in the initialization section to make the channel available at design time.

File

uROServer

See Also

TROServer class

UnregisteServerClass, RegisterTransportChannelClass, RegisterMessageClass procedures

Pascal

procedure RegisterServerClass(aROMessageClass: TROServerClass);


See Also

TROServer class

UnregisteServerClass, RegisterTransportChannelClass, RegisterMessageClass procedures


RegisterTransportChannelClass Function

Registers a TROTransportChannel descendant so that it shows up in the IDE Wizards.

When implementing a new channel, you should use this method in the initialization section to make the channel available at design time.

File

uROClient

See Also

TROTransportChannel class

UnregisterTransportChannelClass, RegisterServerClass, RegisterMessageClass procedures

Pascal

procedure RegisterTransportChannelClass(aTransportChannelClass: TROTransportChannelClass);


See Also

TROTransportChannel class

UnregisterTransportChannelClass, RegisterServerClass, RegisterMessageClass procedures


ROSendNoResponse Function

Call this function at the end of your server implementation to return from an asynchronous call without sending a response message.

This is helpful when using asynchronous requests for notifications or to trigger actions on the server, but no information or acknowledgement is expected or needed on the client.

Notes

This function raises a EROSendNoResponse exception to propagate the information to the calling Invoker. If the used server does not support asynchronous messages, it will ignore the exception and always send back a response.

File

uROServer

See Also

Asynchronous Calls help topic

EROSendNoResponse exception

Pascal

procedure ROSendNoResponse;


See Also

Asynchronous Calls help topic

EROSendNoResponse exception


UnregisterExceptionClass Function

Registers an exception class that was previously registered via RegisterExceptionClass.

File

uROClient

See Also

EROServerException exception

RegisterExceptionClass and UnregisterROClass procedures

Pascal

procedure UnregisterExceptionClass(anExceptionClass: ExceptionClass);


See Also

EROServerException exception

RegisterExceptionClass and UnregisterROClass procedures


UnregisterMessageClass Function

Unregisters a TROMessage descendant that was previously registered with RegisterServerClass.

When implementing a new server, you should use this method in the finalization section.

File

uROClient

See Also

TROMessage class

RegisterServerClass, UnregisterTransportChannelClass, UnregisterServerClass procedures

Pascal

procedure UnregisterMessageClass(aROMessageClass: TROMessageClass);


See Also

TROMessage class

RegisterServerClass, UnregisterTransportChannelClass, UnregisterServerClass procedures


UnregisterROClass Function

Unregisters a "complex type" class that was previously registered via RegisterROClass.

File

uROTypes

See Also

TROComplexType class

RegisterROClass and UnregisterExceptionClass procedures

Pascal

procedure UnregisterROClass(aComplexTypeClass: TROComplexTypeClass);


See Also

TROComplexType class

RegisterROClass and UnregisterExceptionClass procedures


UnregisterServerClass Function

Unregisters a TROServer descendant that was previously registered with RegisterServerClass.

When implementing a new server, you should use this method in the finalization section.

File

uROServer

See Also

TROServer class

RegisterServerClass, UnregisterTransportChannelClass, UnregisterMessageClass procedures

Pascal

procedure UnregisterServerClass(aROMessageClass: TROServerClass);


See Also

TROServer class

RegisterServerClass, UnregisterTransportChannelClass, UnregisterMessageClass procedures


UnregisterTransportChannelClass Function

Unregisters a TROTransportChannel descendant that was previously registered with RegisterTransportChannelClass.

When implementing a new channel, you should use this method in the finalization section.

File

uROClient

See Also

TROTransportChannel class

RegisterTransportChannelClass, UnregisterServerClass, UnregisterMessageClass procedures

Pascal

procedure UnregisterTransportChannelClass(aTransportChannelClass: TROTransportChannelClass);


See Also

TROTransportChannel class

RegisterTransportChannelClass, UnregisterServerClass, UnregisterMessageClass procedures


Binary Type

The Binary type is an alias for the TROBinaryMemoryStream class, defined for convenience.

File

uROTypes

See Also

TROBinaryMemoryStream class

Pascal

Binary = uROClasses.TROBinaryMemoryStream;


See Also

TROBinaryMemoryStream class


DateTime Type

The DateTime type is an alias for the Delphi TDateTime type, defined for convenience.

File

uROClientIntf

Pascal

DateTime = TDateTime;


IROEventsWriter Type

uROClientIntf

Pascal

IROEventsWriter = IROEventWriter deprecated ;


TRODispatchOptions Type

A set of TRODispatchOption values.

File

uROClient

See Also

TRODispatchOption enum

TROTransportChannel.DispatchOptions property

Pascal

TRODispatchOptions = set of TRODispatchOption;


See Also

TRODispatchOption enum

TROTransportChannel.DispatchOptions property


TROProbingOptions Type

A set of TROProbingOption values.

File

uROClientIntf

See Also

TROProbingOption enum

TROServerLocator.ProbingOptions property

Pascal

TROProbingOptions = set of TROProbingOption;


See Also

TROProbingOption enum

TROServerLocator.ProbingOptions property


TROXMLSerializationOptions Type

A set of TROXMLSerializationOption values.

File

uROXMLSerializer

See Also

TROXMLSerializationOption enum

TROSOAPMessage.SerializationOptions property

Pascal

TROXMLSerializationOptions = set of TROXMLSerializationOption;


See Also

TROXMLSerializationOption enum

TROSOAPMessage.SerializationOptions property


Samples

RemObjects SDK for Delphi ships with a large number of samples, and more are added with each subsequent release.

These samples are provided in the \Samples subfolder of your RemObjects SDK install, where you will also find a Samples.html file that describes each individual sample in detail.

See Also

Samples.html in your "RemObjects SDK for Delphi\Samples" folder


See Also

Samples.html in your "RemObjects SDK for Delphi\Samples" folder


Additional Information

Please make sure to visit the RemObjects Software website at remobjects.com, where up to date information on all our products is available.

RSS feeds are also provided, to help you stay informed about new articles and product news.


Topics

Topics

FAQs

Frequently asked questions (FAQs) about our products are maintained on our website and are often extended and enhanced based on feedback we receive via our newsgroups and support team.

We maintain a single FAQ database containing items for all our products and you can reach the FAQ home page via: remobjects.com/devcenter/faq

The FAQ page allows you to filter by product or category and also offers a text search facility.

Online Articles

RemObjects Software provides an extensive set of online articles and other resources, covering all aspects of our products in varying degrees of detail, from non-technical whitepapers over introductory articles to in-depth architecture reviews for experienced users.

The complete set of RemObjects developer resources can be accessed via our Developer Center at remobjects.com/devcenter.

Getting Technical Support

For more information on getting technical support for RemObjects products, please refer to the RemObjects website at remobjects.com/support.

Our goal is to help create success for you and your organization by leveraging RemObjects’ industry-leading solutions. RemObjects Support provides world class technical support, and you can email our support team at support@remobjects.com should you have any technical issues.

Paid per-incident Premium Support is also available, please visit remobjects.com?premiumsupport for details.

Newsgroups

Support newsgroups are available via NNTP at news.remobjects.com: 	For .NET Products:

remobjects.public.dataabstract.net

remobjects.public.hydra.net

remobjects.public.chrome

remobjects.public.sdk.net

For Delphi Products:

remobjects.public.dataabstract.delphi

remobjects.public.hydra.delphi

remobjects.public.sdk.delphi

Other Useful Groups:

remobjects.public.binaries

remobjects.public.bugreports

remobjects.public.non-tech

remobjects.public.suggestions

Please visit www.remobjects.com?newsgroups for more up to date information on available newsgroups and assistance for setting up newsgroup access.


FAQs

Frequently asked questions (FAQs) about our products are maintained on our website and are often extended and enhanced based on feedback we receive via our newsgroups and support team.

We maintain a single FAQ database containing items for all our products and you can reach the FAQ home page via: remobjects.com/devcenter/faq

The FAQ page allows you to filter by product or category and also offers a text search facility.

Notes

If you need to refer to a numbered item, you can use a shortcut, e.g. remobjects.com?faq112 to directly access the FAQ in question.

See Also

Online Articles, Newsgroups and Getting Technical Support help topics


See Also

Online Articles, Newsgroups and Getting Technical Support help topics


Online Articles

RemObjects Software provides an extensive set of online articles and other resources, covering all aspects of our products in varying degrees of detail, from non-technical whitepapers over introductory articles to in-depth architecture reviews for experienced users.

The complete set of RemObjects developer resources can be accessed via our Developer Center at remobjects.com/devcenter.

See Also

FAQs, Newsgroups and Getting Technical Support help topics


See Also

FAQs, Newsgroups and Getting Technical Support help topics


Getting Technical Support

For more information on getting technical support for RemObjects products, please refer to the RemObjects website at remobjects.com/support.

Our goal is to help create success for you and your organization by leveraging RemObjects’ industry-leading solutions. RemObjects Support provides world class technical support, and you can email our support team at support@remobjects.com should you have any technical issues.

Paid per-incident Premium Support is also available, please visit remobjects.com?premiumsupport for details.

See Also

FAQs, Online Articles and Newsgroups help topics


See Also

FAQs, Online Articles and Newsgroups help topics


Newsgroups

Support newsgroups are available via NNTP at news.remobjects.com: 	For .NET Products:

remobjects.public.dataabstract.net

remobjects.public.hydra.net

remobjects.public.chrome

remobjects.public.sdk.net

For Delphi Products:

remobjects.public.dataabstract.delphi

remobjects.public.hydra.delphi

remobjects.public.sdk.delphi

Other Useful Groups:

remobjects.public.binaries

remobjects.public.bugreports

remobjects.public.non-tech

remobjects.public.suggestions

Please visit www.remobjects.com?newsgroups for more up to date information on available newsgroups and assistance for setting up newsgroup access.

See Also

FAQs, Online Articles and Getting Technical Support help topics


See Also

FAQs, Online Articles and Getting Technical Support help topics


Copyright Notice

RemObjects SDK for Delphi Documentation

The Software as described in this online help system, is licensed under the software license agreement distributed with the product. The software may be used or copied only in accordance with the terms of its license.

RemObjects SDK for Delphi is copyright © RemObjects Software, LLC, 2002-2007. All Rights reserved.

This help file is copyright © RemObjects Software, LLC, 2002-2007. All Rights reserved.

This help file was created using doc-o-matic. We'd like to thank toolsfactory and Markus Spoettl for their continuous support!

Please also visit our online developer center at remobjects.com/devcenter.

Copyright

No part of this help can be reproduced, stored in any retrieval system, copied or modified, transmitted in any form or by any electronic or mechanical means, including photocopying and recording for purposes other than the purchaser's personal use.

Microsoft, Windows, Visual Studio, Microsoft .NET, Internet Information Server and Personal Web Server are registered trademarks or trademarks of Microsoft Corporation.

All other brands and names mentioned in this help system are the properties of their respective owners.

RemObjects Software Trademarks

Chrome™, Data Abstract™, DebugServer™, DevCenter™, DevStudio™, EWF Server Pack™, Hydra™, Internet Pack™, Pascal Script™, RemObjects™, RemObjects Software™, RemObjects SDK™, The Infrastructure Company™ and Wolpertinger™ as well as their respective logos are trademarks or registered trademarks of RemObjects Software, LLC in the United States of America and World-Wide.

The absence of a name or logo in the above list does not constitute a waiver of any and all intellectual property rights that RemObjects Software has established in any of its product, feature, or service names or logos.

Copyright © RemObjects Software, LLC, 2002-2007. All rights reserved.