Fog Creek Software
Discussion Board




n-tier programming with Delphi

I'm getting ready to start a big database application project that I'll be building as an n-tier app using Delphi. 

My resulting app will be deployed in three different ways:  (1) to single-user desktops (3 tiers on a single computer), (2) to LAN installations (presentation and middleware tier on client computers, and database on a server), and (3) to the internet (middleware and database on an internet server, zero-configuration downloadable clients). 

The slick thing about the solutions I've found is that they'll let me use the same code base for all three deployments.  So my users can start out using a local install (desktop or LAN) and if they decide to have me host it as an ASP they'll be able to make the transition with zero retraining, since the application front end will be identical using all three deployment methods.

I've already pretty much decided against Borland's own Midas/Datasnap solution.

So far I've identified a few possibilities for the middleware software.  These are:

Asta (at www.astatech.com)

kbmMW (at www.components4developers.com), and

remObjects (at www.remobjects.com)

Does anyone have experience with any of these?  Any comments?

Herbert Sitz
Tuesday, October 08, 2002

Well, I do have a few suggestions for you, as I was faced with similar design decisions with the project I am currently working on.  I had invesitgated the products you mentioned or ones very similar to them before beginning the design of our solution. 

Our product is a real-time industrial control and billing system which collects about 1 million records a month for a low end installation.  It has a no-client UI (ASP currently being migrated to .NET), a thick-client admin utility (ActiveX), with our business and data tiers in COM+.

So, a few things I learned on the way.  Despite what you read, COM+ is your friend.  This alternative was noticably absent from the list of solutions that you are considering.  The amount of time you invest in this technology will pay significant dividends over the course of your project.  The allure of a 3rd party out of the box product, is that you hit the ground running.  This may be a concern for you, it usually is, however I think you find yourself in a very uncomfortable situation in about 6 months.

I say this based on a snippet from the Asta site:

"We want you to concentrate on coding your application rather than dealing with low level issues like threading, encryption, or writing SQL update statements. With ASTA you set properties rather than have to implement with code."

Over the course of the last two years, I have come to realize that these are issues you DO want to deal with, especially in a distributed system.  One of your major concerns in a large system will be how you construct your framework with regards to database interaction.  If this code is hidden deep away from you, it may lead to a nightmare trying to optimize for performance.

I personally believe that the hallmark of a good technology is that it is well documented and supported.  This is a specific criteria our group has institued when requisitioning 3rd party tools.  You will find a plethora of COM/COM+ literature suitable to your skill level, both on the internet and at your local bookstore.

Finally, I will say that for as many times I have cursed COM, it has come back to save me.  Clients can be demanding and the flexibility you derive from the COM architecture will be a pleasant surprise.

I could go on and on about why might want to look into this as a possible solution.  However, ultimately your design and time requirements will define you choice.  I only encourage you to look into this as a possibility since Delphi does a nice job allowing you work with this technology in a friendly way.

Chad R. Millen
Tuesday, October 08, 2002

Herbert,

Just curious, why did you decide against DataSnap?  We've been successful with it.

Jim Elden
Wednesday, October 09, 2002

Jim -- Well, I guess maybe I'll reconsider things.  Basically I've just tinkered a tiny bit with Datasnap, Asta, and kbmMW.

Asta has some built in stuff, or already coded stuff, that can help you hit the ground running.  That was initially attractive to me.    Especially the automatic handling of threading, as Chad points out.  But I'm starting to think he's right that I shouldn't place much importance on that.  I do think Asta still allows you to tweak for performance (you have the source, after all), but if I'm going to have to do that anyway, perhaps I shouldn't be very concerned about "hitting the ground running." 

Asta comes in two different flavors now, which is somewhat confusing.  Asta3 is the "tried and true" version, while AstaIO is a new version rebuilt from the ground up that allows pluggable transport protocols, among other things.

One downside of Asta is the licensing.  Royalty free licensing is quite expensive, $7,500 for Asta 3 and $15,000 for AstaIO.  Both of these seem quite expensive for small software shops, particularly now that a royalty free license to Datasnap is included with Delphi 7 Enterprise.

Datasnap seemed fine, but I have heard in general bad things about Com+, even though I don't actually know what it is.  But Datasnap doesn't even require the use of Com+, though, right?  I gather that Com+ is just a particular "transport protocol", and that you can use several others with Datasnap, like Corba, TCP/IP, HTML, SOAP.  What are the advantages of using Com+?

kbmMW is a package similar to Asta that I just discovered.  I've toyed with it and for some reason it's inspired a feeling of confidence in me.  The design seems extremely well thought out, lets you deal neatly with low level issues like pool threading, and has good support by its designer, Kim Madsen.

remObjects is a new package that somehow fits in here, but I'm not sure exactly how.  They just made available a Datasnap Integration Pack: http://www.remobjects.com/page.asp?id=E14CFBEA-4C10-4202-8869-F5231E3BB9E9.

I guess I need to do a bit more research on this stuff and work a little more with several trial versions before I commit to any solution.

But I'd still like to hear comments/experiences from anyone who's willing to share.

Herbert Sitz
Wednesday, October 09, 2002

As one example of why I would choose against using a Datasnap/Com+ solution, here's what Marco Cantu says in his book Mastering Delphi 6:

"Due to the complexity of DCOM configuration and of its problems in passing through firewalls, even Microsoft is abandoning DCOM in favor of SOAP based solutions."

Is that not true?

Herbert Sitz
Wednesday, October 09, 2002

To answer a few questions:

"I gather that Com+ is just a particular "transport protocol"

No.  COM+ provides the 'plumbing' that allows you to architect a scalable solution.  You can preform business logic and data access from the COM+ objects you create.  They are course grained objects that are stateless in nature.  COM+ is a substitue for all of the products you are currently considering using.

"What are the advantages of using Com+?"

1. COM+ allows several concurrent users access to the same information.  Provided that you have written your objects correctly, the idea is that the solution is hardware scalable.
2. It integrates nicely into ASP, Win32 or ASP.NET applications.
3. COM+ allows you to pool objects, just in time object creation and integrates full transactional support.  All considerations when constructing a middle tier.
4. No need for any additional 3rd party tools - Datasnap, Asta, etc.  Provided you have Windows 2000 Pro, Server or Advanced Server the COM+ architecture is built into these operating systems.  This means, no licensing or royalty issues.
5. If done properly, your product will have an API for your clients to extend.  This can be a nice benefit depending on the nature of your product.

To clarify:
"Due to the complexity of DCOM configuration and of its problems in passing through firewalls, even Microsoft is abandoning DCOM in favor of SOAP based solutions."

1.  This is true.
2.  The purpose of DCOM is much different in nature than COM+.  You would not build a middle tier system with DCOM.
3. Firewall issues are difficult to deal with period.  If it were easy to get through firewalls, they wouldn't be much use.
4. SOAP is the preferred method of solving this problem.  Luckily, wrapping COM+ objects in the SOAP protocol isn't that difficult (well relatively).

To shed a little light on all of this COM/DCOM/COM+/ActiveX stuff:

COM - Component Object Model.  Billed as a bigger better CORBA (some debate about that, but I would agree).  Create objects that can be reused by almost any language (VB, Delphi, C++, and so forth).

DCOM - Distributed COM.  Allows you to invoke COM objects remotely. 

MTS - Microsoft Transaction Server.  This technology preceeded COM+.  MTS allowed you to pool COM objects and provided transaction support.  (i.e. You could roll back almost any action preformed by a COM object including database interactions).

COM+ - The next generation of MTS.  Combined COM and MTS into one homogenous framework.  Allows queued objects (very useful in distributed systems) and inherited all of the benefits of MTS.

ActiveX - Similar to COM, but allows you to integrate visual objects.  Create an ActiveX control and you can now use it any laguage that supports COM (VC++, Delphi, VB, etc.).

The best way to get introduced to this technology would be to pick up any Wrox press book on the subject.  The 'Windows DNA' book by Wrox will illustrate most of the concepts I have discussed here.  Although the Wrox books are usually pretty light, they do a good job of introducing a technology to the reader.


Good Luck!

Chad Millen
Thursday, October 10, 2002

Chad -- Thanks again.  I have a basic familiarity with COM and ActiveX just from doing some basic MS Office automation stuff in VB.  It's the remote access of objects that I've got to get my brain around.

OK, now I've got that whether Datasnap uses DCOM, TCP/IP, HTTP, or SOAP, in each case it's using COM to create the remote object that is being transported from server to client.  Is that right?

If I don't need Datasnap to use Com+, why would anybody want to use (and pay for) Datasnap?  I assume because it's giving some higher level interface or wrapper around Com+ that makes things easier.  Is it? 

From what I've been able to gather so far all the options I've mentioned (Datasnap, Asta, kbmMW, remObjects) are capable of providing good enough performance for my intended use.  At least good enough that they'll cover the economic requirements well enough (need to serve x number of clients per server), and if more performance is needed then that could be solved by employing more servers.  (Not to distribute loads but just to accommodate more unrelated clients: my clients will mostly be accessing different databases so it's not like I've got to make sure a single database is usable by hundreds of users.  The opposite, in fact, each database will probably have no more than 10 concurrent clients, if that.)

Thanks for pointing me in the direction of COM+.  I already had a recommendation on that Wrox book as a good thing to look at even I'm not going to use COM+, since the theory is similar regardless of what technology is used.

Herbert Sitz
Thursday, October 10, 2002

>whether Datasnap uses DCOM, TCP/IP, HTTP, or SOAP, in each case it's using COM to create the remote object that is being transported from server to client.  Is that right?

We're using Datasnap (was MIDAS.) I don't know much about MTS or COM+.

The main thing that Datasnap provides is disconnected datasets in a client application. The client dataset maintains a change log which it can save and load from a local file, and send back to the server at its discretion, and Datasnap creates the update SQL to post changes back within a single transaction.

Datasnap is wire protocol "agnostic", but ships with connection components for DCOM, TCP/IP, "local" connection and possibly others. You could probably write your own connection component. It provides data to the client from any TDataSet descendant.

Datasnap applies updates in a single transaction when datasets are connected in a master/detail relationship. There is publicly available code to manage transactions involving multiple datasets when that is not the case.

There is also publicly available code to support server object pooling. This is not built in. With the off-the-shelf code, I think you can choose between a server thread per client or a server process per client, both stateful.

Datasnap supports custom remote method calls which work over any of the supported connection types. These are actually events on provider components on the server that you can trigger from the client application. It also supports callbacks (server to client notifications) through COM interfaces too, which I'm not sure if work over all connections.

On the server side, the application server itself is a COM component. How the client communicates with the server depends on the connection, but it is transparent to the client.

Big B
Thursday, October 10, 2002

BigB -- I think almost all of what you said about Datasnap also could have been said about Asta, kbmMW, and remObjects -- except that none of them are based on COM.

I'm still wondering what advantage I get from COM that would make Datasnap preferable to any of the above.  It may be too complicated for a message board; guess I'll have to turn to the books.

Herbert Sitz
Thursday, October 10, 2002

Hi Herbert,

WRT COM and DataSnap "out of the box", one of the key DataSnap components is the TRemoteDataModule, which in itself is a COM object that does need to be registered on the server, which is easy enough.  That's about all the COM you really need to think about if you are using Sockets or HTTP to connect clients to app server.

I should be fair and say that I don't have any experience with ASTA or KbmMW other than having at one time considered them.

The RemObjects DataSnap Integration Pack looks VERY interesting and I will for sure take a serious  look at it.

You are doing the right thing by testing each solution.  In testing DataSnap, make sure to look at Nested DataSets, something that has saved us a lot of work.  Check out borland.public.datasnap newsgroup as well.

For Big B:  TDCOMConnection supports callbacks, and TSocketConneciton does but needs WinSock2.  TWebConnection does not support callbacks.

Jim Elden
Thursday, October 10, 2002


  Herbert, I've been using Asta for two years.  It's very easy to use.

  I don´t know the others though, so I can't say if ASTA is the best choice, but for us it is working fine.

Ricardo Antunes da Costa
Thursday, October 10, 2002

One other solution would DbOvernet. www.dbovernet.com. It uses a socket server and is very fast. You can write the complete middleware as ServerObjects. I'm more than happy with it.

Paul Sjoerdsma
Friday, October 11, 2002

*  Recent Topics

*  Fog Creek Home