Thursday, July 30, 2009

Wanted alive: ASTA, A Smart Thin Architecture review

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:


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

Tuesday, July 28, 2009

Eddie Shipman Pwned !

Just when you think Tim K. got owned:
https://forums.codegear.com/thread.jspa?threadID=19882

Another person got owned:
https://forums.embarcadero.com/thread.jspa?threadID=19966&tstart=0

Wow - Mr. Eddie Shipman using unlicensed DevExpress software!

Quoted from Julian B.:
No, Eddie, they didn't say that. They marked the issue as "Insufficient Information" because they couldn't find the license you are using. So, they quite rightly asked you for your registration information because your customer record on our system had no products assigned to it.

DelphiHater wonders what "other" things he did not license, such as:

CleverComponents?
http://www.delphigroups.info/2/8/510403.html

InfoPower?
http://coding.derkeiler.com/Archive/Delphi/borland.public.delphi.thirdpartytools.general/2007-09/msg00067.html

maybe even Delphi itself... :)

Friday, July 10, 2009

Joys of watermarking

Note: this was changed to include Delphi itself :)

Watermark: to prevent or deter unauthorized copying of [Delphi components]/[Delphi]

Kudos to XXXXX for starting to watermark their [components]/[Delphi]. DelphiHater salutes to XXXXX for stopping pirated components/delphi from leaking out their [customer's download site]/[betas site] and blocking abused customer accounts (used to share pirated materials)

Q: How do I watermark files?
A: You need to first encrypt the sources in your install. If you use InnoSetup, you need to use a password, but wait - if you have a password, there's Innounp (google for it) so obviously you would need another installer. try writing your own. it's not that hard.

Q: How do i write my own installer?
A: Look at Innosetup sources for ideas, or other vendors, such as GhostInstaller, SetupFactory.

Q: What kind of copy-protection should I use?
A: You should use on-line activation kind, the type which calls home via SSL to your web-server and get a response.

Q: Should I ship DCUs?
A: You should ship only BPLs

Q: Should I use IceLicense?
A: Only if you feel confident you can pay US$299 per copy for each time you ship, since you are linking with source-code to their libraries.

Q: Should I use GPL components?
A: If you need to also ship your product as full source code, but wait, remember the money?

Q: What kind of files should I watermark?
A: At some places, like the TLB files, where you can slip in an extra GUID of the customer, or resource file, where it is not easily found.

Q: Does it work?
A: DelphiHater could find XXXXX watermarked files easily, and it prevents software piracy.

:)

Wednesday, July 8, 2009

kbmMemTable review

Some time ago, Kbm developer wrote "Invalid publication of licensed materials!" we decided to respond in kind.

Website overview:
- Components4Developers, well, if you look at their site, it uses frames, strange fonts (Arial Narrow?) i thought website design should be modern. I wish it looked more better.

- Some of their partners Jasmine Components (dead), StarMax (dead), Heidi.ie (is not active?) may not even use Components4Developers anymore :)

- Either it's just me or CodeGear's logo is distorted? In the age of modern website design, it's just plain unprofessional.

- Media page is not available (coming soon) since three years ago (make that four years since 2005).

- Case study for Apollo is sooo big I can't see it. no really, the thing flickers and Firefox hides it.

back to the review.


kbmMemTable 6.10 - is it really necessary?
Many years ago, from Delphi 4/5/6/7 times, kbmMemTable was a must-have component during those days. Mr Kim made it for free and the former website was linked to his optical scanning business website. Later, kbmMemTable was getting more better and better.


The wannabe database
I really wish kbmMemTable would start to grow up, like other in-memory tables, like the one found in RemObject's remoting datasets, or for ease of use, like in DevExpress memory dataset (it comes with DevExpress and good with filters), or DBISAM's in-memory table (you can save and load to in-memory DBISAM) or Nexus in-memory database.

For starters, if you try to, say, store 10000 records in-memory (fair enough, for a report), what about the "other" 100,000 records? then you need a database library, such as DBISAM/ELEVATEDB/NEXUSDB. Then wait! they have their own in-memory tables. It simply does not make sense to use kbmMemTable and say, use ElevateDB or Nexus in-memory tables.

Ditto for MySQL/ MSSQL/ Oracle access. If you get UniDac/ or AnyDac or RemObjects, they come with their own in-memory table component.

Of course, you could use kbmMemTable, but with a choice, you could go "native" and delete kbmMemTable...

DelphiHater remembers the time when Mr. Kim was advertising his kbmMemTable in the DevExpress dxmemtable newsgroups and asked "to stop promoting competing products" :)

Also, the time when AidAim.com released their shareware in-memory table (without sources) and there were long fingers pointing about "copied" code, but any proof? I don't know except that most of kbmMemTable sources were for looking and, and copying ideas from.

Anyone remembers the WideString fiasco which needed a "paid" upgrade to fix? or how the primary key would go haywire after some time.

The heart of kbmMemTable is custom TList. The paid extensions are simply faster variant of TList instead of Delphi's usual TList. (not worth the price, IMHO).

To top it off, the paid help file and annual subscription.


The wannabe Remoting table
The most interesting thing is kbmMemTable does not have linkes to SOAP/WSDL or RPC/XML or ADO in-memory table links.


Verdict
In the end, your reviewer, who brought kbmMemTable subscriptions and dropped it, still wonders what value kbmMemTable have, against - other bundled in-memory suites.

It's a nice to have, but if you want to buy it, along with Delphi, RemObjects (contains an in-memory table), DevExpress (contains an in-memory table), ElevateSoft/Nexus (contains in-memory tables as well), then UniDac (contains in-memory table)...


Non-Standard Future
DelphiHater wonders what future is there left for a stand-alone in-memory table.

there are two directions, develop a database connectivity kit (the type that works) or develop a remoting framework...

DelphiHater uses SOAP/XML, ActiveMQ, XML/RPC remoting, Spring, Hibernate because it talks with open standards, not some binary non-standard protocol.

The world is full of open standards - XML, SOAP, ActiveMQ, SOAP, Ajax, Amazon Web Services, Google Web Services, RSS... and unfortunately, kbmMemTable can't talk with them without much effort and coding.

Last:
How to prevent software piracy


Article update in March 2013:
This article is outdated. The outdated information is striked out. The website Component4Developers now goes to Component4Programmers. They have since updated their kbmMemTable with SQL support, OSX and 64-bits and fixed tons of bugs that plagued their product since then.

Article referencing kbmMW is also at Rudolph's Dental Software AG.

See article corrections.


DelphiHaters' Blog wishes Mr. Kim Madsen best of luck with his product.