ASTA review
The year was 2001, when ASTA came out, people were curious to make their Delphi apps work over the Internet.
They had many choices, but too much work:
- Java, requires Java-server, Java-back-end, Java client. The results were stymied by Microsoft's lousy JVM which shipped with IE. If you downloaded Sun Java and used that, the Java would run quite fast on those old Pentium II computers.
Java required learning new language, new API and lots of buzz words, and resulting in curiously slow applications working over the Internet.
- there was NSAPI/ ISAPI v1.0, if people still remember Internet Explorer 3/Internet Explorer 4 period with either Apache 1.0 and Microsoft Internet Server 2.0.
The problem were those "rich" FAT client with bloated memory requirements and fancy GUI would could not be easily crafted with HTML.
The people using NSAPI / ISAPI were stymied by various problems, such as lack of session (because the session number is intentionally missing) handling and web-pages being in infancy.
For example, to implement client-side (or browser-side validation), that would require many web-page refreshes. In those days of 56k dial-up modems and 64k leased lines, it was really slow.
- then came Perl and PHP, the language with weird syntax, which Delphi users consider inferior and less-than perfect: Perl came along with this huge run-time (but hey, the scripts were good), all sorts of Perl mods (which require more and more learning).
PHP was interpreted, which Delphi users consider less than perfect. The compiler would validate all my syntax bugs before it goes on the web.
- ColdFusion and Python required learning some "dumb-down" (by Delphi user's definition) programming language and all sorts of weird kludges, such as CFML tags and Python bracing to make it work.
Then came Asta...
No, there was DbOvernet (a derivative of ICS Midware) which half worked, and half gave crashes.
and in infancy kbmMW with their proprietary protocol,
and various forms of HTTP add-ons, such as ASP for Delphi (company was sold), HREF and others.
Asta was an instant magic, it used HTTP sockets internally (usually TSocket over HTTP), custom protocol, offering the middle-ware everyone wanted: easy transition to web-based applications that work over the Internet, and just switching data-sets from TxxDataSet to TAstaClientDataSet.
In those days, Asta was really great, better solution than DbOverNet, ICS-Midware or custom-http calls.
Like magic, when the dust gathers, the real magic comes out.
Asta was advanced in those days, and worked with nearly every TDataSet client, notably Firebird 1.0 (the free version of Interbase), but problems started to occur.
Asta's problem is in it's code-base:
Server-side:- The Firebird adapter (at that time) would crash often, there was a page recommending people to buy IBObjects rather than use IBX, Borland's free Interbase client. The problems were concurrency and multiple sockets and multi-threading.
The biggest problem is changing Firebird syntax (Type 1 and Type 3), obviously, the database query and table generator is not so robust.
Since the firebird adapter stopped development at Firebird 1.0, we're not sure if it works with Firebird 2.2...
- The ADO Asta Server suffers from Borland's neglect, the TAdoDataSet, TAdoQuery, TAdoTable uses ADO 2.1 and not the latest and greatest. The problem boils down to large queries and large data-sets being transferred. The larger the dataset, the more prone it is to crashing.
- The ODBC98 Asta Server, where's the vendor?
- Diamond Access Asta Server, the vendor does not support anything above Delphi 6, oh well...
- NativeDb, ditto, vendor went out of business...
- BDE server, uses depreciated BDE engine.
DelphiHater wishes Asta could make, for example, Asta DBExpress Server, Asta UniDac server or Asta AnyDac server or Asta MySQL server, but that could be wishful thinking...
Database Abstraction problems:The strength of the client rests in server it uses, so you could pick and choose any client and get some kind of "database" abstraction. For example, you could pick Firebird Asta client and then MSSQL client, and supposedly the same SQL would work, but that's plain false.
The database resolver only resolves Metadata, but does not abstract differences between, say, MSSQL and Firebird.
For example, Unidac and Anydac abstract between MSSQL and Firebird easily; RemObjecs AnyDac has SQL-scripting to change True to 'Y' in MSSQL, True to 1/0 in Firebird, ByteBool in MySQL.
Another problem was getting unicode over-the-wire, where Russian, Turkish, Chinese would turn to '????' text, but of course, since there are few Russian, Turkish, Chinese customers, why bother making a Unicode version?
The SQL transaction were plagued with errors, for example, the Asta data clients would fetch data, but that would cause the Asta server to increase in memory. Worse, since Delphi VCL is not very-thread-safe, that would cause sporadic crashing.
Doing high-speed operations, such as posting say, 1000 records feels really slow., even slower than RemObjects Data Abstract, DevArt's UniDac or even kbmMW.
Middleware problems:
Since Asta does not support SOAP fully (not updated since 4 years ago) and Asta EJB here is very little information.
For example, J2EE Server stack is almost free, and there are plenty of Java developers who can build working, decent solutions over Java.
With standards like SOAP, JMI (Java Messaging Interface), HTTP, JSF (Java Server Faces), who needs Asta?
The Asta SQL explorer demo would go to http://www.astawireless.com/skywire/eval/AstaSQLDemo.exe,
probably, a domain once used by Astatech.
Sync problemsTheir Asta wireless is really nothing special, the AstaServer transmits over HTTP, so Windows CE, Palm Mobile (now called Palm-Pre) would read Asta data. The Windows CE would read/write in Asta-protocol format, ignoring Unicode, and as you guessed, uses NET 1.0...
DelphiHater wishes there was WAP server, support for Nokia, Symbian and Blackberry, but that could be wishful thinking.
Asta Deployment Problems
Like all socket-servers, requires lots of attention. In order to deploy Asta, you need to find an ISP which hosts socket-servers and direct database connections. Year 2009 prices are US$59 per socket-server, or if you prefer the whole server to yourself, look at larger ISPs.
Each Asta-server deployment costs US$299, and SOAP-add-on, adds another US$200 to your development costs.
If you want to communicate with say, ASP or Mobile devices, you would need either Asta COM client (US$499).
Of course, since your customers won't blink, why not order Asta unlimited license at US$7500? I'm sure some people would love Steve Garland to renovate his house by giving him US$7500 instead :)
Code Review
Most of Asta is coded slopply, such as:
or
good grief...
AstaDES comes from Eldos:
Maybe, because the source codes for the above are not available any-more, then, there are problems moving to Delphi 2009?
The code suffers from not being updated - the last update (as of writing this review) is 2006, or 3 years ago.
The Delphi 2009 version was promised, but requires lots of work (it is ANSI-only right now), such as:
- Unicode encryption,
- Unicode handling over HTTP,
- Unicode DES, AES, encoding,
- Unicode LZH, UUEncode, Mime64 encoding.
- Using other transports, such as Indy 10, Synapse, ICS Delphi 2009 version, and others.
- Winning back customers since Development stopped many years ago.
Useful Asta Alternatives
In today's age, there are few useful alternatives:
- why not make your site fully using C#, Perl or PHP?
- write your site in Java
- use SOAP for communications. There are so many SOAP adapters around...
Article updates 2013 March
See: Wanted alive: Asta
See: QA Dept Asta Support
See: Exception error gem
See: Article corrections
The year was 2001, when ASTA came out, people were curious to make their Delphi apps work over the Internet.
They had many choices, but too much work:
- Java, requires Java-server, Java-back-end, Java client. The results were stymied by Microsoft's lousy JVM which shipped with IE. If you downloaded Sun Java and used that, the Java would run quite fast on those old Pentium II computers.
Java required learning new language, new API and lots of buzz words, and resulting in curiously slow applications working over the Internet.
- there was NSAPI/ ISAPI v1.0, if people still remember Internet Explorer 3/Internet Explorer 4 period with either Apache 1.0 and Microsoft Internet Server 2.0.
The problem were those "rich" FAT client with bloated memory requirements and fancy GUI would could not be easily crafted with HTML.
The people using NSAPI / ISAPI were stymied by various problems, such as lack of session (because the session number is intentionally missing) handling and web-pages being in infancy.
For example, to implement client-side (or browser-side validation), that would require many web-page refreshes. In those days of 56k dial-up modems and 64k leased lines, it was really slow.
- then came Perl and PHP, the language with weird syntax, which Delphi users consider inferior and less-than perfect: Perl came along with this huge run-time (but hey, the scripts were good), all sorts of Perl mods (which require more and more learning).
PHP was interpreted, which Delphi users consider less than perfect. The compiler would validate all my syntax bugs before it goes on the web.
- ColdFusion and Python required learning some "dumb-down" (by Delphi user's definition) programming language and all sorts of weird kludges, such as CFML tags and Python bracing to make it work.
Then came Asta...
No, there was DbOvernet (a derivative of ICS Midware) which half worked, and half gave crashes.
and in infancy kbmMW with their proprietary protocol,
and various forms of HTTP add-ons, such as ASP for Delphi (company was sold), HREF and others.
Asta was an instant magic, it used HTTP sockets internally (usually TSocket over HTTP), custom protocol, offering the middle-ware everyone wanted: easy transition to web-based applications that work over the Internet, and just switching data-sets from TxxDataSet to TAstaClientDataSet.
In those days, Asta was really great, better solution than DbOverNet, ICS-Midware or custom-http calls.
Like magic, when the dust gathers, the real magic comes out.
Asta was advanced in those days, and worked with nearly every TDataSet client, notably Firebird 1.0 (the free version of Interbase), but problems started to occur.
Asta's problem is in it's code-base:
Server-side:- The Firebird adapter (at that time) would crash often, there was a page recommending people to buy IBObjects rather than use IBX, Borland's free Interbase client. The problems were concurrency and multiple sockets and multi-threading.
The biggest problem is changing Firebird syntax (Type 1 and Type 3), obviously, the database query and table generator is not so robust.
Since the firebird adapter stopped development at Firebird 1.0, we're not sure if it works with Firebird 2.2...
- The ADO Asta Server suffers from Borland's neglect, the TAdoDataSet, TAdoQuery, TAdoTable uses ADO 2.1 and not the latest and greatest. The problem boils down to large queries and large data-sets being transferred. The larger the dataset, the more prone it is to crashing.
- The ODBC98 Asta Server, where's the vendor?
- Diamond Access Asta Server, the vendor does not support anything above Delphi 6, oh well...
- NativeDb, ditto, vendor went out of business...
- BDE server, uses depreciated BDE engine.
DelphiHater wishes Asta could make, for example, Asta DBExpress Server, Asta UniDac server or Asta AnyDac server or Asta MySQL server, but that could be wishful thinking...
Database Abstraction problems:The strength of the client rests in server it uses, so you could pick and choose any client and get some kind of "database" abstraction. For example, you could pick Firebird Asta client and then MSSQL client, and supposedly the same SQL would work, but that's plain false.
The database resolver only resolves Metadata, but does not abstract differences between, say, MSSQL and Firebird.
For example, Unidac and Anydac abstract between MSSQL and Firebird easily; RemObjecs AnyDac has SQL-scripting to change True to 'Y' in MSSQL, True to 1/0 in Firebird, ByteBool in MySQL.
Another problem was getting unicode over-the-wire, where Russian, Turkish, Chinese would turn to '????' text, but of course, since there are few Russian, Turkish, Chinese customers, why bother making a Unicode version?
The SQL transaction were plagued with errors, for example, the Asta data clients would fetch data, but that would cause the Asta server to increase in memory. Worse, since Delphi VCL is not very-thread-safe, that would cause sporadic crashing.
Doing high-speed operations, such as posting say, 1000 records feels really slow., even slower than RemObjects Data Abstract, DevArt's UniDac or even kbmMW.
Middleware problems:
Since Asta does not support SOAP fully (not updated since 4 years ago) and Asta EJB here is very little information.
For example, J2EE Server stack is almost free, and there are plenty of Java developers who can build working, decent solutions over Java.
With standards like SOAP, JMI (Java Messaging Interface), HTTP, JSF (Java Server Faces), who needs Asta?
The Asta SQL explorer demo would go to http://www.astawireless.com/skywire/eval/AstaSQLDemo.exe,
probably, a domain once used by Astatech.
Sync problemsTheir Asta wireless is really nothing special, the AstaServer transmits over HTTP, so Windows CE, Palm Mobile (now called Palm-Pre) would read Asta data. The Windows CE would read/write in Asta-protocol format, ignoring Unicode, and as you guessed, uses NET 1.0...
DelphiHater wishes there was WAP server, support for Nokia, Symbian and Blackberry, but that could be wishful thinking.
Asta Deployment Problems
Like all socket-servers, requires lots of attention. In order to deploy Asta, you need to find an ISP which hosts socket-servers and direct database connections. Year 2009 prices are US$59 per socket-server, or if you prefer the whole server to yourself, look at larger ISPs.
Each Asta-server deployment costs US$299, and SOAP-add-on, adds another US$200 to your development costs.
If you want to communicate with say, ASP or Mobile devices, you would need either Asta COM client (US$499).
Of course, since your customers won't blink, why not order Asta unlimited license at US$7500? I'm sure some people would love Steve Garland to renovate his house by giving him US$7500 instead :)
Code Review
Most of Asta is coded slopply, such as:
type
TAstaAboutBox = class(TForm)
Panel1: TPanel;
Panel2: TPanel;
StaticText1: TStaticText;
VersionLabel: TStaticText;
StaticText3: TStaticText;
StaticText2: TStaticText;
StaticText4: TStaticText;
StaticText5: TStaticText;
StaticText6: TStaticText;
BitBtn1: TBitBtn;
Image2: TImage;
...
or
type
TAutoUpdateForm = class(TForm)
OpenDialog1: TOpenDialog;
Label1: TLabel;
Panel1: TPanel;
Bevel1: TBevel;
Bevel2: TBevel;
BitBtn1: TBitBtn;
BitBtn2: TBitBtn;
ADS1: TAstaDataSet;
DataSource1: TDataSource;
DBGrid1: TDBGrid;
Memo1: TMemo;
StaticText1: TStaticText;
eAppName: TEdit;
StaticText2: TStaticText;
eVersion: TEdit;
Button1: TButton;
good grief...
AstaDES comes from Eldos:
(**************************************************)
(* *)
(* Data Encryption Standard (DES) *)
(* Advanced Encryption Standard (AES) *)
(* *)
(* Copyright (c) 1998-2001 *)
(* EldoS *)
(* *)
(**************************************************)
Maybe, because the source codes for the above are not available any-more, then, there are problems moving to Delphi 2009?
The code suffers from not being updated - the last update (as of writing this review) is 2006, or 3 years ago.
The Delphi 2009 version was promised, but requires lots of work (it is ANSI-only right now), such as:
- Unicode encryption,
- Unicode handling over HTTP,
- Unicode DES, AES, encoding,
- Unicode LZH, UUEncode, Mime64 encoding.
- Using other transports, such as Indy 10, Synapse, ICS Delphi 2009 version, and others.
- Winning back customers since Development stopped many years ago.
Useful Asta Alternatives
In today's age, there are few useful alternatives:
- why not make your site fully using C#, Perl or PHP?
- write your site in Java
- use SOAP for communications. There are so many SOAP adapters around...
Article updates 2013 March
See: Wanted alive: Asta
See: QA Dept Asta Support
See: Exception error gem
See: Article corrections
7 comments:
Well, you should have chosen kbmMW then, because this one is still being developed and works. Also you could/can use delphi own middle tier framework, midas/datasnap.
Of course you could also swap to RemObjects now. So options enough, you just must do your homework to pick the right one!
Hi Rob,
READ THIS:
http://qc.codegear.com/wc/qcmain.aspx?d=66864
Why do I need to vote for SOAP 1.2 support, when NET has it, Java has it, and ...
Delphi's SOAP support is "nearly bankrupt" ?
for kbmMW, how many people actually visit the kbmMW newsgroups?
SELECT COUNT(DISTINCT posters) as "UNIQUE_POSTERS"
FROM personal_newsgroup_archive
might give you some answers
Rob,
what ISP do you deploy / or host your kbmMW servers to?
do you have large customer base to boast about using midas/datasnap, kbmMW?
or how about interoperability between NET, Java, Perl, Ruby and PHP?
do you have an IntraWeb-deployed website I can take look at?
I've got my own server on which I run some kbmmw servers on. Although I don't use delphi/kbmmw any more in new projects, at the moment I use my own asp.net based REST framework with html/css/javascript clientside.
I only recommend kbmmw to you if you have an application which uses Asta and want to convert that with an other delphi middle-tier framework, in that case you can pretty quickly replace asta with kbmmw. Deploying the serverside will be difficult if you don't have your own server.
Rob, you're right on,
that's where the troubles starts - deployment.
but wait, Java, PHP, C#, ASP.NET are mostly free.
I haven't seen any affordable ISP plan to host socket servers, except renting an expensive servers.
BTW, glad to know you use C# instead. I wish people were smarter :)
C# is a nice language but hey look who is the architect... But that I now use C# won't say that Delphi didn't did his job in the past! Delphi was and still is not perfect, but I'm still glad that I have used it in the past, instead of visual basic. Delphi have been very good to me, but times are changing and you have to move on.
At the moment I'm doing a lot of javascript coding, compared to that Delphi is a great language!
I've started this Delphi 7 project: http://xxm.sourceforge.net/ to have another alternative to build web-apps with Delphi. I skip most of the IDE and use the compiler and a pre-parser to have both HTML and Delphi int he same files, and haev auto-compile on refresh (using an InternetExplorer protocol handler). Let me know what you think.
Post a Comment