 |
VCL for writing stable HTTP(S) Servers,
ISAPI extensions and Clients
with Borland Delphi 4-7,
BCB 4-6, BDS 2005-2007, Turbo Delphi/C++ 2006-2007 and CodeGear Delphi 2009 |
 |
|
RealThinClient SDK 2.85 is 100% FREE under a BSD Style License
and
ready to be used with D4, D5, D6, D7, D2005, D2006 and D2007 - but not D2009.
RealThinClient SDK 3.0 is a commercial component set
compatible with
RealThinClient SDK 2.85 and updated
to seamlessly work
with Delphi 2009
as well as older Delphi versions, utilizing the new Unicode features in D2009.
For more information on both versions, please CLICK HERE.
|
 |
Write Firewall-friendly Clients, Servers and
ISAPI
Extensions (Apache 2.x and MS IIS 5.x compatible) |
 |
One code compiles as Stand-alone Server
and/or ISAPI Extension for MS IIS, Apache, etc. |
 |
Debug ISAPI extensions using the RTC WebServer
(full source code in Delphi included) |
 |
Make your Client and/or Server Multi-Threaded,
simply by setting a property (built-in thread-pooling) |
 |
Enable Auto-Compression and strong Encryption
- Built-in Compression enabled by setting a property
- Built-in Encryption enabled by setting a property
- Advanced SSL using third-party components |
 |
Empower your "static" HTML pages and use the
RTC Scripting Engine to create a bridge between
your
Delphi code and your visual HTML presentation |
|
 |
 |
Component-based and Modular Design allows you to
add new Remote Client/Server functionality into your
existing Delphi applications and re-use existing code |
 |
Write and call flexible Remote Functions empowered by
the compact RTC format or the standard XML-RPC format
(simply pick your format by setting a property) |
 |
Use the Remote Functions Wizard to easily write
client-side classes for calling server-side functions. |
 |
Delphi components with full source code ready for: |
| |
- Borland Delphi 4 - 7 |
| |
- BDS 2005 and 2006 (Win32) |
| |
- CodeGear Turbo Delphi 2006 and 2007 for Win32 |
| |
- CodeGear Delphi 2009 (RTC SDK 3.0 and beyond) |
|
|
| RealThinClient SDK : Short Description of included Features |
Multi-Deployment:
ISAPI Extensions,
Stand-alone Servers,
Third-party Servers |
Write one server app and compile it as (a) robust Stand-alone Server, capable of serving unlimited number of clients, or as (b) ISAPI DLL extension which can be deployed to any ISAPI-capable Web Server (for example: MS IIS or Apache), or (c) integrate your application into third-party Message-based Servers like the NexusDB Server. |
RAD:
Write events,
not interfaces |
Everything you do with RTC is component-based, while all the code you will ever need to write is defined as events, so you can design your server and client applications, without the need to use wizards or write interfaces. |
Easy MultiThreading:
turn on/off with
a simple switch |
A very sophisticated Threading mechanism is built into all RTC Connection components, which allows thousands of active connections to be running in separate threads, all at the same time. And the only thing you need to do is change a simple MultiThreaded property to True. Then, any newly received connection will be handled by a thread pooling mechanism which saves valuable System resources, while still enabling nearly unlimited number of simultaneous connections at the same time. |
HTTP protocol:
No Firewall problems |
RTC Clients will never have to be specially configured to get through corporate firewall's and reach the internet. Simply by setting the UseProxy property to True, Data Client connection will use a connection provider which uses the same settings to read and send its data to the internet, as MS Internet Explorer does for browsing the Web. This means that Clients can work in any corporate LAN and have full access to the internet. |
| Non-Blocking |
Other than most other internet components, RTC connection components are non-blocking and event-driven. This means that, even when not using a multithreaded mode, your users will not be blocked ("Application Not Responding") during communication between your client and the server. For each state change in the connection, there is an event that will be triggered. |
Remote Functions:
reusable,
easy to write,
easy to call
|
Implementing and using remote functions is as easy as writing local functions. You just place a RtcFunction component on your Form or a DataModule, set function name and write your OnExecute event. OnExecute event receives the Connection object, Function Parameters and a Result object. You just have to use the parameters passed to the function to prepare the result. The rest is done "under the hood" by RealThinClient components. |
Strong encryption &
automatic compression |
RTC components offer built-in, easy-to-use strong encryption with Encryption Keys of variable length and automatic data compression. You don't even have to think about encryption keys or data compression, everything will be generated and maintained for you. Using strong encryption and compression with remote functions is completely transparent, you will never have to worry about encryption or compression again. Simply set Encryption and Compression parameters in RtcClientModule and RtcServerModule, the rest is up to RTC. |
Plug-In Framework:
write your own plug-ins
or use 3rd-party plug-ins |
All Client and Server code you write using RTC SDK is ready to be used as building blocks or plug-ins in any application that uses RTC SDK. For example, you can combine a Web Server, Messenger server, Application server, Database server and your own functions in one Data Server, even when those components weren't specially designed to share the same Server space. Because of the easy-to-use plug-in framework on top of which all RTC Components are built, you can link unlimited number of functionality and data providing components like RtcDataProvider, RtcServerModule and/or RtcDataServerLink to one Data Server connection component, enhancing that server's functionality with each new component. And by keeping code in separate units (Data Modules), you can even provide your own plug-ins (and sell those plug-ins) to anyone who uses the RTC SDK Library. |
| Small footprint |
A complete Web Server implementation, using RTC SDK, is less than 600 KBytes when compiled with D7. Even though it is so small, it offers enough functionality with great stability and scalability. |
|
| Build rock-solid Internet-ready applications |
All RTC components are stress-tested for the highest stability. Check Test Results for more info.
By using non-blocking event-driven communication with a built-in thread-pooling mechanism, RealThinClient SDK can handle thousands of active connections by using a limited number of threads in a real multi-threaded environment (for example, 100 threads will be more than enough to handle several thousand active connections). Combined with reduced need for all important resources (CPU, Memory, Threads, Timers, Handles, etc), automatic handling of all communication-related objects, flexible remote functions (accept any structure for parameters and return any other structure as a result), automatic session handling (integrated time-out with variable life time) and a lot more, makes writing stable and performant Servers and Clients very easy with RealThinClient components. |
|
| What
is inside the RealThinClient SDK package? |
|
| RealThinClient SDK : Server-side components |
| RtcHttpServer: implements
the HTTP protocol over TCP/IP and is used
to compile RTC components into a stand-alone
server application (extends TRtcDataServer).
All high-level server-side RTC components
use TRtcDataServer descendants to communicate
with HTTP Clients (RTC Clients, Web Browsers,
SOAP Clients, etc). Best practice is to write
all your code using high-level server-side
RTC components separated on different data
modules, then use one extra DataModule where
you will use one RtcHttpSever to compile the
functionality into a stand-alone server application
(EXE). |
| RtcISAPIServer:
implements the ISAPI interface and
is used for for writing extensions for ISAPI-compatible
web servers (extends TRtcDataServer). All
high-level server-side RTC components use
TRtcDataServer descendants to communicate
with HTTP Clients (RTC Clients, Web Browsers,
SOAP Clients, etc). Best practice is to write
all your code using high-level server-side
RTC components separated on different data
modules, then use one extra DataModule where
you will use one RtcISAPISever to compile
the functionality into one ISAPI extension
(DLL). |
| RtcMessageServer: implements an extensible Message-based Server-side component, which can be used to access RTC applications through third-party communication layers. RTC SDK includes a ready-to-use NexusDB plugin, which uses the RtcMessageServer component to integrate RTC applications into a NexusDB Server. |
| RtcDataServerLink: very useful when you have a number of Data Provider or Server Module components spread across units, because it groups related Data Provider components and links them to their Data Server connection. If you only have one or any small number of Data Provider components, you can link them directly to Data Server connection component, without the need of a RtcDataServerLink. |
| RtcDualDataServerLink: Link a group of RTC components to 2 or more Server connection components (RtcHttpServer and RtcMessageServer). This allows you, for example, to write your application code once, but make it accessible through the standard HTTP protocol, through a secure HTTPS protocol and (if required) through different message-based transports like the NexusDB transport layer. |
| RtcDataProvider:
used to implement events which will handle
HTTP requests and prepare responses (for
example, client requests a file, which has
to be read from a local drive and written
out as a response). Each Data Provider only
responds to his requests, ignoring the rest.
This makes Data Providers work as plug-ins
for the Server, which can be used alone
or in combination with other RTC components
to create a powerful and multifunctional
Server.
Here is a short list of possible Data Providers:
- File provider to send files
- PHP provider to process php scripts and
send HTML pages out
- SOAP provider to implement different Web
Services
- Page providers to generate dynamic HTML
pages
- Image providers to dynamically generate
images for the Web
- anything else, there is no limit |
| RtcServerModule: execution point for a group of Remote Functions. It enables the Server to provide remote access to its remote functions. RtcServerModule has no events which would have to be implemented, you just link a RtcServerModule with its Server on one side and a RtcFunctionGroup on the other side to enable remote functions. |
RtcFunctionGroup: provides access to a group of functions. When used by a RtcServerModule, it automatically enables access to remote functions for all RTC Clients. When used by a RtcClientModule, it gives server the ability to call client-side functions as a result of client's function calls.
To implement remote functions, you will need at least one RtcFunctionGroup component and link one or more RtcFunction components to it. Function Groups also enable you to call other functions from the same group to fill parameters for other function calls. RtcFunctionGroup is primarily used by the RtcServerModule and RtcClientModule components to hold implementations for their remote functions, but it can also be used directly by any other component. |
RtcFunction: link
one RtcFunction to a RtcFunctionGroup, check that the Function Group is assigned to a
RtcServerModule, then choose a "FunctionName" and
write your function code in the OnExecute
event. That's all you have to do to add a
new remote function to your RTC Server.
When writing a remote function, you don't
have to think about anything but your function
code. In case of an exception (which you can
also raise inside your OnExecute event handler),
client will get the exception message as a
result (Result.isType=rtc_Exception), so you
don't even have to worry about that. |
| RtcScriptEngine: makes it possible to use a Pascal-like
scripting language from within HTML and/or XML files. When using the RTC
Scripting Engine, you can decide for yourself how much of your application
code you want to have in form of Delphi functions, compiled inside your
Server or ISAPI extension, and how much you want to have in form of scripts
inside your HTML/XML files. This allows you to combine the power of Delphi
with the flexibility of scripting languages like PHP and JSP. |
| |
| RealThinClient SDK : Client-side components |
| RtcHttpClient: this is the component that will be responsible
for direct communication with your servers when using the HTTP or HTTPS protocol.
It sends requests prepared by higher-level
client-side RTC components like RtcDataRequest
and RtcClientModule, then accepts responses
and uses the same higher-level components
to process those responses. |
RtcMessageClient: this is the
component which you can use to integrate your higher-level Client-side components (like DataRequest and ClientModule) into third-party transport layers. For example, by using the included NexusDB plugin, you can call RTC remote functions integrated in your NexusDB Server. |
| RtcDataClientLink: very useful when you have a number of Data Request or Client Module components spread across units, because it groups related client request components and links them to their Data Client connection. If you only have one or two data request components, you can link them directly to Data Client connection component, without the need of a RtcDataClientLink. |
| RtcDualDataClientLink: use to create a small pool of client connections, allowing the component to decide which connection to use when posting a request, depending on the number of currently pending requests on available connections. A new request will be posted through the connection with the lowest number of pending/active requests, unless you explicitly specify a different connection object. |
| RtcDataRequest:
client-side counterpart to RtcDataProvider.
It enables the client to post requests to
a RTC Server or any other HTTP Server. Using
this component, you can request files from
a Web Server, post a SOAP request to a Web
Service, execute a server-side PHP script,
etc. Everything any HTTP Server is providing,
you can request it using this component. |
RtcClientModule:
client-side counterpart to RtcServerModule.
It enables the client to call functions provided
by the Server through one of its Server Modules.
RtcClientModule has no events which would
have to be implemented, you just link a RtcClientModule
to a Client connection component (RtcHttpClient)
and you can call remote functions.
If you define client-side functions and link
them to this RtcClientModule, this will be
the execution point of those client-side remote
functions. No special implementation needed.
Client-side remote functions are functions
which server can call on the client-side as
a result of client's calls to a server-side
function. |
| RtcResult:
process results received from remote function
call(s). Using the "OnResult" event,
which receives the connection (Sender:TRtcConnection),
parameters sent (Param:TRtcValue) and the
result received (Result:TRtcValue), you can
easily write the code to process the result.
Maybe only do a simple check if function executed
successfully, or show a message dialog, or
create a separate form containing all data
received, or fill received content into other
component on the same form or datamodule (for
example, fill ClientDataSet with records from
a database). |
| |
| RealThinClient
SDK : Data types used with Remote
Functions, Sessions and Scripting |
RTC SDK supports all native and complex data types for working with Sessions and Remote Functions. You can use any data type to store and access data in a session and/or to send and receive data between clients and servers using RTC remote functions.
All complex data types (record, array, dataset, function) can hold objects of any data type. For example, you can put integers, strings, records, arrays datasets and even remote function calls inside other arrays, records and datasets, as well as use any combination of RTC data types as parameters and/or return values from RTC remote functions. |
| RTC Type |
Access /
Make New |
Description |
| any |
isType |
returns type of data stored in a specific
variable, used mostly in check if and what
kind of data has client sent as parameters
to a remote function call and to check if
and what kind of data has server sent back
to the client as a result from a remote function
call. |
| Null |
isNull |
returns True if parameter is not set (it
is "NULL"). You can set "isNull"
to True to clear the variable/parameter. |
| Boolean |
asBoolean |
Boolean value (Delphi type: boolean) |
| Integer |
asInteger |
Integer value (Delphi type: longint) |
| LargeInt |
asLargeInt |
Large Integer value (Delphi type: int64)
|
| Float |
asFloat |
Float value (Delphi type: double) |
| Currency |
asCurrency |
Currency value (Delphi type: currency) |
| DateTime |
asDateTime |
Date and Time value. Always use this type
to work with Dates and Times (Delphi type:
TDateTime) |
| String |
asString |
String value (Delphi type: AnsiString, up
to 2GB in size) |
| Text |
asText |
Text value, automaticaly coded and encoded
using UTF-8 (Delphi type: AnsiString) |
| WideString |
asWideString |
Wide String value (Delphi type: WideString,
up to 2GB in size) |
| Variable |
asVariable |
use to send/receive variable names (Delphi
type: AnsiString) |
| Exception |
asException |
use to send/receive exception message (string).
If exception is raised from the OnExecute
event (and not handled by that event), client
will receive the exception message "asException". |
| ByteStream |
asByteStream /
newByteStream |
use to work with Streams. When you use "newByteStream",
an in-memory stream will be created, which
you can access using "asByteStream".
When used with remote functions, data stored
in a stream will be sent/received between
client/server as any other data type. |
| Record |
asRecord /
newRecord |
use to work with records. In records, each
element is accessed using a name (string).
Each element in a record can be of any type
(even an array, record, dataset or function
call). |
| Array |
asArray /
newArray |
use to work with arrays. In arrays, each
element is accessed using an index of type
integer. Each element in an array can be of
any type (even an array, record, dataset or
function call). |
| DataSet |
asDataSet /
newDataSet |
use to work with datasets. In datasets,
you browse/insert/delete records as you would
usualy do with Delphi's TDataSet (using prior/next/insert/append/delete),
while you have access to fields from a current
record using names (same as in a record).
Each field in a dataset can be of any type
(even an array, record, dataset or function
call). |
| Function |
Param /
newFunction |
use "newFunction" to prepare a
remote function call, seting function name
and all parameters. Each parameter can be
of any type supported by TRtcValue. This means
that one parameter of TRtcFunctionInfo can
hold virtually anything, from a simple value
to a complex data structure or another remote
function call (even a complete set of function
calls). |
|
|
|