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

In comp.databases.oracle glong_at_magna.com (Gary Long) wrote:

>Or write the 3rd tier programs in a 3GL using ANSI E/SQL. Gives you good
>efficiency plus portability *if* you pay attention to the standards, etc.

Yup, that's another option we've considered and may in fact be the first one we experiment with although we have a concern that generating/parsing dynamic SQL on-the-fly will give us an immediate hit on performance compared to some of the other options. It would however give us maximum flexibility in terms of porting to other database.   

>Your software architecture - 3-tier -- is fine. My first concern would be
>limitations of OLE automation middleware and scalability of NT Servers.
>
>BUT if I understand the application you are deploying, it is:
> Fifty 200-user applications, isolated from each other
>not:
> One 10,000 user application, distributed across 50 server nodes
>
>Correct? If so the approach will probably work. For this application.

That's right, we're looking at distributed workgroup databases storing either replicated common data (e.g. corporate telephone directory) or data local to a particular site where it is highly unlikely that information stored in the database will be accessed by users/applications based at other sites (with the possible exception of associated mobile users).

>Yet you said you are "we are cutting our teeth [on this]" and moving towards
>3-tier development. Is this the model for future work?

For my particular development team this will be our first 'workgroup' C/S project. One of our other development teams however has recently delivered a middleware layer allowing access to the corporate mainframe based DB2 customer database using the 3-tier OLE2 paradigm described in the original posting. This did not include a GUI presentation layer and all components were developed using C++ as VB4 (with OLE Automation capabilities) was not available at the time.

>Perhaps heavy-duty
>OLTP with a larger workload? If so, I would recommend considering heavy duty
>middleware, perhaps even a true TP Monitor. Portable middleware should allow
>you access to not just NT, but also large UNIX-based servers and the like.
>Just in case you run out of horsepower and need some more.

I agree that for OLTP applications (e.g. our customer database) where large, centralised, mainframe databases are required, or legacy line of business applications exist, 'high-end' middleware products are a must. We are considering the use of IBM's MQ Series to provide a messaging/transport mechanism within the data access layer of our architecture to interact with this environment.

The original posting details our thoughts on how we could talk to non-mainframe based workgroup RDBMS's for new workflow, decision support and office automation applications which are currently under development. I am not convinced that we need to utilise a discreet 'high-end' middleware product to achieve this but I'm willing to listen to the arguments for and against...

(By the way Gary, thanks for emailing a draft of your paper on '3-Tier vs 2-Tier Architecture for CS/TP' back in October '95. It acted as a good sanity check for our architectural approach.)

Derek

---
Derek Cummings             
Leeds, UK

EMail:  derek_at_dac1.demon.co.uk