ASTA Inter Op for Linux and Windows

Background

The development of ASTA 2 for Windows commenced in 1997 using Delphi 3. This has provided the basis of the product which has been built upon ever since. In March of 2000 Borland invited ASTA to view their exciting new product for Linux coded named Kylix. Kylix was designed to be cross platform and although the first release was for Intel computers, the architecture will allow Borland to support other hardware in the future (eg Solaris and other non-Intel platforms).

[Delphi] Backward Compatibility

When designing the version of ASTA for Linux we had to decide whether to worry about backwards compatibility or to just code things the most elegant way. We chose to support Kylix and Delphi 5 and 6 and not to worry about backwards compatibility with versions of Delphi before Delphi 5. Borland has slowly been moving database functions from BDE specific units to those that are abstracted to the TDataSet level and we wanted to be able to take advantage of all the VCL code that was available. The use of TParams is an example of something we can use now since it is no longer tied to BDE code.

Transport Layer

ASTA has used the Borland sockets that were first released in Delphi 3 and made available in the Professional versions of Delphi since Delphi 3.01. Since these sockets were based on TCustomWinSocket these classes are certainly not applicable to Linux. ASTA has always used non-blocking event driven sockets. However, under Linux and Unix blocking sockets have always been the standard. There is much debate as to blocking versus non-blocking sockets and instead of taking sides in this debate we decided to have an open architecture for the transport layer of the Linux version of ASTA.

Conclusion

At this point we realized that the product we were working on was not really ASTA 3 as the successor of ASTA 2, but a new product which we called Asta Inter Op to signify the cross platform nature of the product and also the open architecture. ASTA 2 will continue to evolve as a Windows only product with free updates available to all ASTA users for Delphi 6.

Open Transport Architecture

ASTA for Windows had the following design goals:

Allow database developers to use their existing skills to develop n-tier applications so that existing applications could be quickly ported to ASTA using client side SQL
Allow experienced n-tier developers to use their existing skills in extending ASTA servers using advanced n-tier features
Build very scalable and easy to deploy servers and handle all threading issues internally so that developers could concentrate on building applications
Allow thin client applications that could be deployed with no DLL's and build in the ability to have client executables update themselves when new versions were registered on the server
Require only SQL SELECT statements so that all insert, update and delete SQL could be generated by ASTA components
Build an easy to use messaging layer so that database application developers with no TCP/IP experience could easily stream any kind of data across the internet
Abstract the server side so that any Delphi 3rd party component could be easily plugged into an ASTA Server

Point 7 is what we call the “Switzerland” concept - ie ASTA is “database neutral”. Any database can be plugged into the ASTA architecture in a very straightforward manner. In ASTA Inter Op, the database abstraction is contained in a component called the DatabasePlugin. This Switzerland concept also extends to the transport layer by also “abstracting the wire”.

Abstracting the Wire

ASTA Inter Op has an interface based architecture that will allow for any kind of transport to be plugged in. We have tested ASTA Inter Op with sockets from Indy (www.nevrona.com), DXSocks (www.dxsocks.com), IP*Works (www.nsoftware.com) and ASTA’s own socket implementation using the ASTA PAL Sockets. There is also an example using a shared buffer that will allow ASTA servers and clients to be compiled together to create a 2 tier application that doesn’t require TCP/IP and will have virtually no impact on performance. It would be possible to use other transports, for example named pipes.

TAstaServerWire

Following is the interface defined for the TAstaServerWire. It includes methods that apply to sockets since most transports will be TCP/IP based – therefore, we felt that it was appropriate to include them to provide a “roadmap” to know all the methods that must be implemented in order to plug in any transport.

IAstaServerTransportInterface = interface
procedure DoClientConnect(Client : TObject);
procedure DoClientDisconnect(Client : TObject);
procedure ReceiveString(Client : TObject; S : string);
procedure SendString(Client : TObject; S : string);
procedure DisconnectClient(Client : TObject);
function RemoteAddress(Client : TObject): string;
function RemotePort(Client : TObject): word;
function GetPort : word;
procedure SetPort(Value : word);
function GetActive : boolean;
procedure SetActive(Value : boolean);
function ClientComponentAssertion(AnObject : TObject) : boolean;
end;

TCustomAstaServerWire = class(TComponent, IAstaServerTransportInterface);

By descending from TAstaServerWire and implementing the above interface, a transport can be created in a straight forward manner. This is demonstrated in the following example which shows the interface part of the declaration for TAstaIndyServerWire (based on the Indy socket components).

TAstaIndyServerWire = class(TAstaServerWire)
private
    FAbout : TAboutString;
    FIndyServerSocket : TIdTCPServer;
    procedure SocketConnect(AThread : TIdPeerThread);
    procedure SocketExecute(AThread : TIdPeerThread);
    procedure SocketDisconnect(AThread : TIdPeerThread);
    function GetIndyServer : TIdTCPServer;
    procedure SetIndyServer(Value : TIdTCPServer);
protected
    function ClientComponentAssertion(AnObject : TObject) : boolean; override;
    procedure SetActive(Value : Boolean); override;
    function GetActive : boolean; override;
    function GetPort: word; override;
    procedure SetPort(Value : word); override;
    procedure Notification(AComponent : TComponent; Operation : TOperation); override;
public
    procedure DisconnectClient(Client : TObject); override;
    function RemoteAddress(Client : TObject): string; override;
    function RemotePort(Client : TObject): word; override;
    procedure SendString(Client : TObject; S : string); override;
    constructor Create(AOwner : TComponent); override;
    destructor Destroy; override;
published
    property About : TAboutString read FAbout write FAbout;
    property IndyServerSocket : TidTCPServer read GetIndyServer write SetIndyServer;
end;

Shown here is the property editor for TAstaIndyServerWire. Notice it has a property pointing to an Indy specific Component (IndyServerSocket) and also a property pointing to a TAstaDatabasePlugin.

TAstaClientWire

On the client side, ASTA Inter Op uses the idea of an abstract class and associated interface. Shown below is the interface for the IAstaClientMessageTransport. Once again, methods for TCP/IP are contained in the interface where in a pure world they are really not needed, but since most implementations will use sockets, we decided to add them. By descending from the TAstaCustomClientWire and implementing the IAstaClientMessageTransport interface a custom transport can quickly be defined.

IAstaClientMessageTransport = interface
procedure DoConnect(Sender : TObject);
procedure DoDisconnect(Sender : TObject);
procedure ReceiveString(S : string);
procedure SendString(S : string);
function SendGetString(S : string) : string;
function GetActive : boolean;
procedure SetActive(Value : boolean);
function GetPort : word;
procedure SetPort(Port : word);
procedure SetAddress(Value : string);
end;

TAstaCustomClientWire = class(TComponent, IAstaClientMessageTransport);

Shown here is the object inspector from Delphi showing a TAstaIndyClientWire.

Postscript

ASTA Inter Op provides unprecedented flexibility for n-tier developers. It allows you to easily create cross-platform applications running in both Windows and Linux environments. In addition it provides an extremely open architecture allowing you to easily swap in various database connection and transport components without the need for complex rewrites within your applications.