I'm not against using data-bound controls per say - I just against whole
heartedly betting your applications entire infrastructure on any proprietary
framework. It's too risky - it makes you too vulnerable to market
uncertainties and bugs in the technologies you're attempting to use.
The approach taken at Credit Suisse was to use RPC as the basic layer.
Straight TCP/IP would do also - it's a straightforward protocol - it ensures
that all the packets get to your destination. It's a stream based protocol -
so you have to devise a simple wrapper protocol to mark the beginning and end
of each "message".
The message is just a chunk of data which you can divide up in anyway you
like. C++ is the best language to divide up the chunk of data. C++ will be
around forever, is cross platform and has bridges to every protocol and
language environment possible - Java, COM, CORBA, DLLs, OleDB, ODBC driver
toolkits are all supported by C++.
Conceptually in the chunk of data you want to send over should have a small
header which should show the type of message and the version number and then a
hash table containing polymorphic objects indexed by names.
You'll need a C++ library which supports object streaming - either write your
own or use a commercial one like MFC,
OWL, Rogue Wave etc. (not a big risk since you have the source code for all
these libraries - the companies can go under and you're not going to be left in
the lurch - you can also debug them yourself) (I did our own streaming library
with own product HL7 Chameleon - anyone is welcome to that code - although it
only streams to disc currently).
The hash table approach makes it easy to add more information to the message
without breaking backward compatibility - new parameters can be added which
older clients ignore. The parameters can be identified at runtime to determine
their type.
The main object we sent across in the hash table in Credit Suisse was a C++
class called a "datatable". It was a
generic class which was a simple in memory abstraction of a database table. It
supported the five basic data
types you needed - Date, Time, Integer, Double and string. All the
applications were standardised on it. There were
all sorts of useful libraries for it - including making fast native queries to
Oracle, Infomix, Sybase etc.
To make the bridge to VB there was a COM interface on the datatable written
using the ActiveX Template library. We
also had ODBC and OleDB drivers written for it using third party development
toolkits.
We had datatable aware grid controls etc., routines which could format the
tables in comma delimited, fixed width,
HTML, crystal reports etc.etc. - all the wizz bang technology you want! <grin!>
I'm sure if Delphi was used in the company someone would have written a driver
for the data table to achieve
the benefits which Max has described.
The difference from Profax's approach and Credit Suisse is that Borland or
Microsoft could go belly up tommorrow and all Credit Suisse needs to do is
switch client technologies if it wants to continue development - Profax and any
company which completely bets on one company's technology for their
infra-structure is going to be in a sticky position if that company goes under.
It rather like say making the transition from a DOS accounting system written
in non-portable Modula 2 to Windows when not quite enough initial effort was
made to separate out the layers - there quite are a few companies in that
unhappy position of having a good DOS product which is impossible to port to
Windows.
It must send shivers up the spine everytime Borland announces another loss for
any company which completely bets it technology on Borland....
(BTW - I do practice what I preach - I think Delphi is great - but HL7
Chameleon only uses it for a thin front end - all the real work is done in C++
with a COM wrapper - both the GUI front end and the COM wrapper can be
completely replaced without touching the rest of the product.)
Cheers,
Eliot
--
Eliot Muir iNTERFACEWARE
mailto:[EMAIL PROTECTED]
Voice 64-9-5202077 http://www.interfaceware.com
Makers of HL7 Chameleon
"Program to the iNTERFACE not the the implementation"
========================================
Grant Black wrote:
> Very topical discussion as I am currently designing (from scratch) an
> application that will have to scale to be a distributed application.
>
> Perhaps I simply don't understand them, but to my mind DCOM/Corba and
> MIDAS are all overly complex solutions with big learning curves.
> When I simply want an application to send messages to another
> application (maybe on the same machine or across the world), to advise
> of an event or pass a packet of data, I think building a solution around
> UDP or similar IP technology (HTTP?) seems more intuitive. You can see
> the idea working every time you use the WWW.
>
> What I would like is a nice light weight framework that you can specify
> the messages and/or data payload between software components and have
> the framework deal with the issues of checking that packets arrive and
> are error free.
>
> For the record the app is designed to have 1 or more modem handling
> components that may be distributed around the world but send incoming
> files to 1 or more processing/db engines. Anybody know of any
> off-the-shelf solutions?
>
>
> Grant Black
> Software Developer
> SmartMove (NZ) Ltd
> Phone: +64 9 361-0219 extn 719
> Fax : +64 9 361-0211
> Email: [EMAIL PROTECTED]
>
> > -----Original Message-----
> > From: Eliot Muir [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 21, 1999 11:23 PM
> > To: Multiple recipients of list delphi
> > Subject: Re: [DUG]: How thin the client will be?
> >
> >
> > Call me a conservative....but why bother with all these
> > proprietary networking stuff? Bound data
> > type controls are renowned for making unscalable applications - the
> > little bit of time saved in throwing apps together is usually
> > absorbed in the
> > maintenance and slow performance that these complicated technologies
> > result in - especially when they don't work.
> >
> > DCOM and CORBA etc. don't achieve what they are supposed to - which is
> > transparent operation of applications over networks. I
> > haven't used MIDAS to
> > be
> > honest but I bet it's not the magic panacea that the spec
> > sheet describes.
> >
> > The best approach is also the simplest. Implement your own simple
> > client-server library
> > based on on straight TCP/IP or maybe RPC, stream over some
> > type of hash table
> > object with a
> > version numbering scheme, and get your server to decipher the
> > calls and talk to
> > the
> > database.
> >
> > The advantages are that it's transparent - you know exactly
> > when and what data
> > is being
> > sent across the network. It's easy to debug, you have
> > complete control so it's
> > easy to optimise
> > - you don't have to spend heaps of time evaluating crap third
> > party products
> > which don't work.
> > And lastly no license fees or danger of your client-server
> > architecture
> > becoming obsolete if
> > the product you used gets dumped or the company which makes
> > it goes under.
> >
> >
> > Yanbo Li wrote:
> >
> > > Thanks Nic, dbOverNet licence sounds much cheaper than Midia.
> > > I will contact with them.
> > > I've already developed a Midas prototype. But the licence is too
> > > expensive, we have to get rid of it.
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]] On Behalf Of Nic Wise
> > > Sent: Wednesday, April 21, 1999 9:23 AM
> > > To: Multiple recipients of list delphi
> > > Subject: Re: [DUG]: How thin the
> > client will be?
> > >
> > > have you thought about using dbOverNet?
> > > www.dbovernet.com - same idea as MIDAS (which, IMO, is your
> > best option,
> > > tho it IS expensive), but I'm guessing their cost structure
> > is a little
> > > different :)
> > > N
> > > Yanbo Li wrote:
> > > >
> > > > Thanks, Your information is very helpful.
> > > >
> > > > Cheers
> > > > Yanbo
> > > >
> > > > -----Original Message-----
> > > > From:
> > > [EMAIL PROTECTED]
> > > >
> > [mailto:[EMAIL PROTECTED]] On Behalf
> > > Of
> > > > [EMAIL PROTECTED]
> > > > Sent: Tuesday,
> > April 20, 1999
> > > 2:14 PM
> > > > To: Multiple
> > recipients of
> > > list delphi
> > > > Subject: RE:
> > [DUG]: How
> > > thin the client will be?
> > > >
> > > > IB Objects and
> > FIB components
> > > rep[lace the BDE for
> > > > Interbase but you still
> > > > need the IB Client.
> > > >
> > > > DCOM is not necessarily
> > > Windows only... but if you can
> > > > find anyone who nows
> > > > how to get DCOM for Mac or
> > > DCOM or Solaris working then
> > > > you are doing well.
> > > > It's hard enough to get it
> > > going on NT!
> > > >
> > > > You could use JBuilder and
> > > Corba for the server end
> > > > too...
> > > >
> > > > Peter Harrison IT
> > > <[EMAIL PROTECTED]> on 20/04/99
> > > > 14:45:54
> > > >
> > > > Please respond to
> > > [EMAIL PROTECTED]
> > > >
> > > > To: Multiple
> > recipients of
> > > list delphi
> > > > <[EMAIL PROTECTED]>
> > > > cc: (bcc: Peter
> > > Jones/Logistics&Information
> > > >
> > > Technology/Christchurch/Foodstuffs)
> > > > Subject: RE:
> > [DUG]: How
> > > thin the client will be?
> > > >
> > > > Using standard Delphi the
> > > TQuery requires the BDE to be
> > > > installed, along
> > > > with the database
> > client of
> > > choice. You don't mention
> > > > the database
> > > > type, so lets
> > assume we are
> > > talking Interbase. You will
> > > > need to install
> > > > the Interbase
> > Client on the
> > > client machines, the BDE,
> > > > and your
> > > > application.
> > > >
> > > > This is not
> > 'thin' client in
> > > the least.
> > > >
> > > > If you want to
> > use Interbase
> > > you havn't got much choice
> > > > about any of
> > > > this, except that
> > you might go
> > > with a product which
> > > > replaces the BDE
> > > > with a driver
> > specifically for
> > > Interbase eliminating the
> > > > need for the
> > > > BDE (do these exist?)
> > > >
> > > > If you want to go
> > with File
> > > Based Databases, such as
> > > > dBASE, you can
> > > > probably eliminate the
> > > database client and bde, and have
> > > > a single app,
> > > > and perhaps a DLL or two.
> > > 'Apollo' is an example
> > > > product for this
> > > > approach.
> > > >
> > > > Besides the n
> > tier stuff there
> > > isn't much alternative.
> > > > You could always
> > > > start writing
> > DCOM interfaces
> > > - conceivable by really
> > > > ugly - and Windows
> > > > dependant.
> > > >
> > > > Good luck...
> > > >
> > > > -----Original Message-----
> > > > From: Yanbo Li
> > > [mailto:[EMAIL PROTECTED]]
> > > > Sent: Tuesday,
> > April 20, 1999
> > > 1:10 PM
> > > > To: Multiple
> > recipients of
> > > list delphi
> > > > Subject:
> > [DUG]: How thin
> > > the client will be?
> > > >
> > > > Many thanks in advance.
> > > > I need to know
> > how thin the
> > > application will be if I
> > > > only use TQuery
> > > > and TDatabase to
> > connect to
> > > remote server. If the app is
> > > > still very fat,
> > > > I have to manage
> > to write my
> > > own driver which I am not
> > > > found of. Please
> > > > do not suggest me to use
> > > TClientDataSet and 3tier
> > > > technology.
> > > >
> > > >
> > >
> > --------------------------------------------------------------
> > ----------
> > > > ---
> > > > New Zealand
> > Delphi Users
> > > group - Delphi List -
> > > > [EMAIL PROTECTED]
> > > > Website:
> > > http://www.delphi.org.nz
> > > >
> > > >
> > >
> > --------------------------------------------------------------
> > ----------
> > > > ---
> > > > New Zealand
> > Delphi Users
> > > group - Delphi List -
> > > > [EMAIL PROTECTED]
> > > > Website:
> > > http://www.delphi.org.nz
> > > >
> > > >
> > >
> > --------------------------------------------------------------
> > ----------
> > > ---
> > > > New Zealand Delphi Users
> > group - Delphi
> > > List - [EMAIL PROTECTED]
> > > > Website:
> > > http://www.delphi.org.nz
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > > ---
> > > New Zealand Delphi Users group -
> > Delphi List -
> > > [EMAIL PROTECTED]
> > > Website: http://www.delphi.org.nz
> > >
> > >
> > --------------------------------------------------------------
> > -------------
> > > New Zealand Delphi Users group - Delphi List -
> > [EMAIL PROTECTED]
> > > Website: http://www.delphi.org.nz
> >
> >
> >
> > --------------------------------------------------------------
> > -------------
> > New Zealand Delphi Users group - Delphi List -
> > [EMAIL PROTECTED]
> > Website: http://www.delphi.org.nz
> >
> ---------------------------------------------------------------------------
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
