|Delphi Clinic||C++Builder Gate||Training & Consultancy||Delphi Notes Weblog||Dr.Bob's Webshop|
The MIDAS Touch Turns Your Apps To Gold
This session will use a practical real-world example to cover and explain the workings of the middle-ware technology from Inprise/borland.com called MIDAS. We'll do so in a practical way, by turning a regular client/server application and an ActiveForm into multi-tier applications, using MIDAS as middle-ware "glue".
The Computing Industry has faced many (r)evolutions. From stand-alone application to Client/Server and now multi-tier (distributed) programming. With the focus on thin clients. From decentralisation - fat, functional clients - we're now slowly turning back to centralisation - database servers and thin clients, with middle-ware in between. The internet technology has helped to strengthen the call (or need) for thin clients. And while Java is not yet able to fill this need, ActiveX controls and especially ActiveForms are a useful product of Delphi that can be used as client in distributed application architectures.
A disturbing problem, which will be solved in a moment, is the fact that data-aware ActiveForms - with or without packages - are so-called "fat" clients using the Borland Database Engine (BDE), and hence the BDE should be installed on the client machine (not something that you can expect from the average internet machine). Generally, a regular data-ware ActiveForm internet client may require the BDE on each client machine. And the only way to make sure every client is sharing tables (for multi-user access, for example), is by making sure that the Database Alias actually points to a shared resource, like a database server on a local network - again not something you might expect on the average internet client, but something that's actually quite common in an intranet environment!
In fact, at my company, we have a local network where the network fileserver is also the database server where a single Database Alias points to. You can place the CUSTOMER.DB and ORDERS.DB files on that shared server, and then every ActiveForm client will use and share those same tables. And since it's an intranet environment in our local office, I can pretty much guarantee not only that every machine runs Internet Explorer 3 or higher, but also that every client machine has the BDE installed (including the shared Database Alias, by the way). Still, this is only a half solution, since we still need the BDE, and hence still have a fat client.
Using components from the MIDAS tab of the component palette, we can turn "fat" ActiveForms into a thin client, and connect it to a middle ware remote data module. The core of MIDAS consists of the TClientDataSet (a self-contained DBMS and thin client component) and Provider and Connection components (on the server side) and the DBCLIENT.DLL (run-time MIDAS DLL). MIDAS can use different communication protocols, like TCP/IP sockets, (D)COM and CORBA.
During this session, I will develop a real-world (but fat) ActiveForm presenting a master-detail relationship of two tables (CUSTOMER.DB and ORDERS.DB). Once the ActiveForm is working, we'll remove the fat BDE components from it, and turn it into a thin client by using TClientDataSet components. We'll also implement a MIDAS middle-ware database server using both DCOM and CORBA as communication protocol.
Having made an N-tier application, we'll experiment a bit further and discover some features regarding robustness, the brief-case model and a few (network) efficiency issues that you should keep in mind when designing distributed architectures with MIDAS in mind.
Note that it's handy - but not required - to have followed the ClientDataSet, (D)COM and/or CORBA sessions before attending this one.