ASTA Vision ASTA/MIDAS Comparison The following are answers to questions posed by MIDAS Guru and all around great guy Dan Miser. >>Does it (ASTA) allow you to do RPC? That is actually what Josh Dahlby asked me a while back on the midas forum. ASTA doesn't use a "standard" RPC like DCOM or Corba. Here is a definition of RPC: "Abbreviation of remote procedure call, a type of protocol that allows a program on one computer to execute a program on a server computer. Using RPC, a system developer need not develop specific procedures for the server. The client program sends a message to the server with appropriate arguments and the server returns a message containing the results of the program executed. " ASTA supports this is a number of ways. 1. ASTA has a complete and easy to use messaging layer that was designed for Database application developers to use with no knowledge of sockets or DCOM. At the lowest level, you can just SendCodedMessage which sends a Msgid:Integer and a Msg:String. On the server, you code a Case Statement and do what ever needs to be done. 2. There is also a SendCodedStream and SendCodedParamList. Once we has the SendCodedParamList we had all we needed as TAstaParamLists can handle any kind of data including all the normal vcl types as well as binaries and even datasets and other ParamLists. 3. TAstaBusinessObjectsManager: Here you can define server side methods (remote procedures if you will) along with their Params. On the client the TAstaclientDataSet sees a list of available server methods at design time and pulls down the one to use. When that happens the Params are streamed down from the server along with the type (datatype, input type). At runtime you populate the Params and when you set active to true ,the Remote Procedure is executed and a dataset and any output params are returned to the client. There are additional options like to launch the action and return control immediately to the client (async) for long running server processes. And also the ability to send back the Field Properties of the attached DataSet. The DataSet can be attached directly to a server method OR a TAstaProvider can be used and that DataSet is used by the BizObject Method. Now get this: any Params defined by the TAstaProvider will come back to the client. Not only BDE Params (see how non bde midas support is) but *any* third party param even if it is not a TParam. More on NON BDE support (hey you started this!<g>) All of the above supported in all 3 ASTA threading Models. << o How does it handle threading on the server? Midas 3 introduced Pooled Threading which ASTA has had out of the gate. ASTA servers can be run in one of 3 threading models Single PersistentSession (the old midas one datamodule for each client) Pooled (the most scalable ) ASTA supports threading internally so you *never* have to create a thread or do anything with threads. This support extends to the 15 or so current Delphi 3rd party DAtabase components support by ASTA. Yes, 15 ASTA servers that all run threaded. And this is not COM threading but winapi threading which we feel is much lighter and scalable. <<How functional is the client side dataset support? Does it do filters, ranges, locates, indexes, sorting, storing to disk, etc? >> I'm attaching an ASTA help file so you can read about this in more detail but yes. we have filters (string and OnFitlerRecord, locates, sorting (one fields or multi, asc or desceding on each field). ASTADataSets are fully streamable and we even have calls like DataSetToString and StringToDataSet AND we can do this with any TDataSet not just the BDE ones (on the server to stream to the client). We don't have indexes but we have defined sorts. We don't have ranges but you can use filters. Nobody has really pushed us to implement say a FindKey (whooops recently added 4-15-2000, yes find key to the server! very fast and efficient) since our Locate is so fast. We did just recently code a HashTable class to use in calculated sort fields and have been thinking about implementing indexes but honestly, you can get by without them. We also support cloning where datasets can be edited and affect other datasets. (inserts, edit, deletes are cascaded. midas has this I believe) <<How complete is its master-detail support? Can you post the master-detail updates in a single transactions? Can you fetch details on demand? (With Delphi 4, the details can come in the single datapacket with the master, one of the cooler enhancements in D4.) >> You can post any number of AstaDataSets in one Transaction using the SendDatasetTransaction call which takes an Array of TDataSet. We support master detail either through the complete fetching of the detail and using filters or the firing of a paramterized query on each master change of the detail (no code required). We have not done the ftDataSet datatype that midas has to support the extended SQL syntax introduced by microsoft. We do have a little used feature we call Cyclops SQL where you can send multiple SQL statements in one SQLTStrings and a dataset is returned with all the datasets in a blob field. I did this one day when someone wanted to fetch a bunch of queries in one server round trip. <<Does it support constraints defined on the server that are enforced on the client? >> We have contraint support at the field level on the client and we do stream back field properites using ServerdataSets, TAstaProviders, and TAstaBizObjects but I'd have to test if we will get back a contraint defined at the field level. <<Does it propogate field properties to the client? (Another new feature in D4.) >> yes, using our server side components. Traditional multi tier midas programing requires a server side provider for each client. We support this but also pioneered Client side sql. Run any of our servers canned out of the box (try this with midas) and they will thread and you can develop and deploy a thin client (no dll's like midas) app using sql. Converting c/s apps can be very quick using this technique. We support pure ntier development but don't require it. ASTA learning curve (no com) can be much less than midas. <<How does it apply updates on the server? Does it generate SQL based on the updates? Can you customize how that SQL will be generated (New feature in D4)? >> We support AfterPost and Cached updates using client side sql and the SQL is configurable (for all our 15 servers!) with lots of properties and events. (eg post booleans as integers for ms sql server. just a property to set once on the TAstaclientSocket application wide). We also support server side sql generation where an oldvalue and current value dataset is shipped to the server and passed to TAstaProviders which have events that fire before insert, before update etc AND you can modify the datasets or handle the sql you want and have ASTA not fire sql. We also support refetching autoinc fields and default fields for all our 15 ASTA servers (well probably not tested on all of them but possible). If you have read this far, ask Dan if Midas has this: AstaProviders and a broadcast ability to send out any change to any table/row to any interested clients. With NO Code. Instant Auction app with no code. You will be reading about this in our upcoming (this spring we hope) review in the Delphi Informant. << o How does it handle reconciliation errors? >> We are not as strong as midas on this but we have a conflict management tutorial to show how it can be handled. we have uses that have code this but we don't deliver this out of the box. I can argue with you (another day perhaps) about the cost of going to the server too much for this<g>. but we can do it. <<o How much control does it give you over the data on the server? >> Not sure what you mean but this but using ASTA with NO COM is pretty easy. ASTA is a mature product now with many more features that I've discussed there. Midas is fabulous technology and we certainly don't do everything they do but: ASTA has an unlimited licensing available with full source ($249 for source with the Entry suite) We don't require any dll's. (the midas client dll's are written in c++) No DCOM No winsock2 You'll find our support the best that can be had and we listen to our users and implement new features almost upon demand. that's how ProviderBroadcasts came about. After ASTA 2.0 was released a couple of guys wanted to do it so we coded it. There has been dicussions whether compression is always faster or not, so we no provide selective compression on ANY individual query. write some sql. want it compressed at the server? set a property execute it. Don't want the next one compressed? turn it off.
ASTA in 60 Seconds | Products & Training | Developer Details | Free Internet Tools Demos | Support & Manuals | Business Views | ASTA Vision | Tutorial Central News | Contact Us | Testimonials | ASTA Links | Partners Copyright © 2000, ASTA Technology Group.