Re: Comments requested on VB4 OLE2 client/server architecture with multiple RDBMS

From: P. Jespersen <pjespe_at_hevanet.com>
Date: 1996/01/31
Message-ID: <311059E3.4488_at_hevanet.com>#1/1


Derek Cummings wrote:
>
> We are developing a number of PC based Windows client/server
> applications using VB4 over the coming months....
> Our aim is to provide completed
> applications which are composed of reusable OLE2 Automation Server
> 'objects'....
>
> Our three tier model is as follows:
>
> PRESENTATION LAYER - VB4 Win3.x/Win'95 form based GUI
>
> (OLE2 interface)
>
> BUSINESS OBJECT LAYER - for internal processing of queries
>
> (OLE2 interface)
>
> DATA ACCESS LAYER - to access data from an RDBMS
 

>
> Derek Cummings
> Derek Cummings
> Leeds, UK
>
> EMail: derek_at_dac1.demon.co.uk

What you are about to do sounds, from an architecture standpoint, almost exactly like what we are in the process of finishing, but with one big difference. We are only using OLE2 on the client side. We brought in Microsoft consultants, and their opinion was emphatically that DCOM and Distributed OLE2 is NOT ready for prime time in a multi-threaded, thread-safe server. They indicated that not only was it NOT stable, but that the performance would be a real dog. They would not even consider it at this time.

We have built our corporate middleware based loosely on the kind of architecture presented in the book "Network Programming in Windows NT", by Alok K. Sinha (Addison Wesley 1996). Our VB4.0 clients use 'Business-object Broker' controls to, in a crude sense, pass GUIDs to the server over named pipes. These GUIDs obviously point to appropriate DLL entry points, which carry out the mutli-platform ODBC requests and Buisness logic.

I cannot really say much more, nor can I tell you about my organization, since it has very strict policy about divulging company 'secrets'. I would definitely review carefully the DCOM / OLE2 aspects of your design!

p. Received on Wed Jan 31 1996 - 00:00:00 CET

Original text of this message