Board index » delphi » Real world BO 3-tier implementation

Real world BO 3-tier implementation

Has anyone done this?  Did you use Midas, DCOM, ASTA, Midware?
 

Re:Real world BO 3-tier implementation


Quote
> Has anyone done this?  Did you use Midas, DCOM, ASTA,

Midware?

You proberly won't find many answers to this question, well
at least I didn't when I asked it. The general feeling I get
is most people are using 2 tier systems.

Anyway, at Sage Automation we are working on implementing a
3tier BO style app using ASTA. We chose not to use
Midas/DCOM becuase I believe the support & total cost of
ownership of DCOM based commercial apps is to high.

Unfortunatley none of the "out of the box" non-com based
components really support distrubuted objects, which meeans
a lot of custom mesagging etc...

We have only just begun the design and can't offer much to
help guide you as we don't expect to have the system
completed until the end of the year. (Still designing).

I am off for the next few days as I am installing a protoype
app using ASTA as a broker and the Business Logic in the
client at a test site. This was easy to implement and
designs like this you will find easy and well supported by
ASTA & dbOvernet (dbOvernet is the commerical version of
Midware). The client runs on any Win9x/NT/2K machine with no
client install (as long as they have TCP/IP networking).

Anyway, back to 3tier ... As a hybrid solution we will use
BO's on the middle tier then expose these via a custom
Dataset to ASTA, this then allows us to use the features of
ASTA (Providers ect..) and "traditional" DBaware programming
on the client. This however will only be stepping stone to a
true distributed object system. Only time will tell.

Looking at the amount of work ahead, I almost wish a 2 tier
system would work, however as the app has realtime links to
manufacturing equipment and messaging requirements amongst
others, we really need the server app.

Regards,

Anthony Richardson
anth...@viewpointsa.com

Re:Real world BO 3-tier implementation


Quote
"LD" wrote...

Hi,

Quote
> Has anyone done this?  Did you use Midas, DCOM, ASTA, Midware?

Yes.  I have developed a Delphi 'front end' to a Java middle tier using
Corba (not the MIDAS version).  It was quite straightforward as only
the 'Delphi' side was dealing with the BO's interface.  I had nothing to
do with the 'guts' of the system, which was totally Java.

Cheers

Phil

Re:Real world BO 3-tier implementation


I am doing it (notice the present tense) now using MIDAS and COM.  Only
about 25-30% complete, but its working.

R

Quote
LD <andi...@shepard-patterson.com> wrote in message news:3a7eea99_2@dnews...
> Has anyone done this?  Did you use Midas, DCOM, ASTA, Midware?

Re:Real world BO 3-tier implementation


Quote
"Ron" wrote...

Hi,

Quote
> I should also say that although the 3-tier implementation works. I am not
> impressed with its performance and sometimes wonder if it wouldn't be
better
> to go back to client-server simply for performance reasons.

This biggest problem with 3-tier systems is people using the middle tier
wrongly.  If you just stick a middle tier layer in-between your normal
client and server, performance will decrease.  I have seen a number of
3-tier systems (in all languages and platforms), that just act as a 'broker'
between the client app and database, for example client app requests
customerXYZ, middle tier receives the request, gets the data from the
database, and sends it back to the client. This is just adding unneeded
layers into the system and will affect performance.  The best 3-tier systems
I have seen, is where the middle-tier is treated as the 'database' is in the
2-tier world.  These systems do a lot of what I call 'intelligent caching
on the middle-tier, which means 90% of 'day to day' client requests can be
handled solely by the middle tier, without a trip to the database.  All
database 'interaction' (keeping the middle tier in sync) is done in
background threads, not when the client requests it.  I have seen some of
this type of 'middleware' take a couple of hours to start up and cache the
required data, but when finished, performance is at least as good as the
more traditional 2-tier systems.  Obviously this involves more work than
just creating a Remote Data Module and dropping some TClientDataSets in the
client application, but if you NEED to develop 3-tier systems, it is
necessary, which brings me on to my second point.

I also often see people developing 3-tiers systems when they are not needed,
or for the wrong reasons.  People are often mistaken that 3-tier systems
will perform better than 2-tier systems, but I have yet to see a multi-tier
system out perform a properly written 2-tier thin client system.  IMO there
are two reasons for using a 'middle tier', the first one is for load
balancing when your concurrent user count reaches a certain level (I
normally use the 250 mark) and/or you are dealing with multiple 'types' of
backend and/or 'client'.

Quote
> The amount of
> time required to open a TClientDataSet is about 1 second with only a few
> records being returned.  One of my forms has 6 ClientDataSets and requires
> about 6 seconds to open because of this....very slow to the user.  Unless
of
> course, I'm doing something wrong - but we all know THAT's impossible ;)

You don't have to use ClientDataSets; they bring a lot of advantages such as
client side caching and editing of data, so only changed data is sent back
to the server, but this will obviously come with some overheads.

I would look at a couple things in your situation.

(a) do you need to open all 6 CDS at once?.
(b) When you open the CDS, is the data already on the middle tier, or is the
middle tier requesting from the database and then sending it.  If the
latter, look into caching common data in the middle-tier to cut down on
network trips.
(c) Do you need to use CDS's.  They are worth the overhead if you need
'live' result sets of a number of records in the client, but if you are
dealing with records one at a time, it might be better to not use them, add
do direct calls to the middleware your self.

Cheers

Phil

Re:Real world BO 3-tier implementation


Hi, evrebody

We think to use 3 -tier with remote datamodule, because our customer has
differentes store tath must work on-line. Do you think tath for this example
we will have better performance ?

Marcelo Spak
"Phil" <p...@shrimpton.co.uk> escribi en el mensaje
news:3a811f60_2@dnews...

Quote

> "Ron" wrote...

> Hi,

> > I should also say that although the 3-tier implementation works. I am
not
> > impressed with its performance and sometimes wonder if it wouldn't be
> better
> > to go back to client-server simply for performance reasons.

> This biggest problem with 3-tier systems is people using the middle tier
> wrongly.  If you just stick a middle tier layer in-between your normal
> client and server, performance will decrease.  I have seen a number of
> 3-tier systems (in all languages and platforms), that just act as a
'broker'
> between the client app and database, for example client app requests
> customerXYZ, middle tier receives the request, gets the data from the
> database, and sends it back to the client. This is just adding unneeded
> layers into the system and will affect performance.  The best 3-tier
systems
> I have seen, is where the middle-tier is treated as the 'database' is in
the
> 2-tier world.  These systems do a lot of what I call 'intelligent caching
> on the middle-tier, which means 90% of 'day to day' client requests can be
> handled solely by the middle tier, without a trip to the database.  All
> database 'interaction' (keeping the middle tier in sync) is done in
> background threads, not when the client requests it.  I have seen some of
> this type of 'middleware' take a couple of hours to start up and cache the
> required data, but when finished, performance is at least as good as the
> more traditional 2-tier systems.  Obviously this involves more work than
> just creating a Remote Data Module and dropping some TClientDataSets in
the
> client application, but if you NEED to develop 3-tier systems, it is
> necessary, which brings me on to my second point.

> I also often see people developing 3-tiers systems when they are not
needed,
> or for the wrong reasons.  People are often mistaken that 3-tier systems
> will perform better than 2-tier systems, but I have yet to see a
multi-tier
> system out perform a properly written 2-tier thin client system.  IMO
there
> are two reasons for using a 'middle tier', the first one is for load
> balancing when your concurrent user count reaches a certain level (I
> normally use the 250 mark) and/or you are dealing with multiple 'types' of
> backend and/or 'client'.

> > The amount of
> > time required to open a TClientDataSet is about 1 second with only a few
> > records being returned.  One of my forms has 6 ClientDataSets and
requires
> > about 6 seconds to open because of this....very slow to the user.
Unless
> of
> > course, I'm doing something wrong - but we all know THAT's impossible ;)

> You don't have to use ClientDataSets; they bring a lot of advantages such
as
> client side caching and editing of data, so only changed data is sent back
> to the server, but this will obviously come with some overheads.

> I would look at a couple things in your situation.

> (a) do you need to open all 6 CDS at once?.
> (b) When you open the CDS, is the data already on the middle tier, or is
the
> middle tier requesting from the database and then sending it.  If the
> latter, look into caching common data in the middle-tier to cut down on
> network trips.
> (c) Do you need to use CDS's.  They are worth the overhead if you need
> 'live' result sets of a number of records in the client, but if you are
> dealing with records one at a time, it might be better to not use them,
add
> do direct calls to the middleware your self.

> Cheers

> Phil

Re:Real world BO 3-tier implementation


Quote
"Phil" <p...@shrimpton.co.uk> wrote in message news:3a811f60_2@dnews...

> I also often see people developing 3-tiers systems when they are not
needed,
> or for the wrong reasons.  People are often mistaken that 3-tier systems
> will perform better than 2-tier systems, but I have yet to see a
multi-tier
> system out perform a properly written 2-tier thin client system.  IMO
there
> are two reasons for using a 'middle tier', the first one is for load
> balancing when your concurrent user count reaches a certain level (I
> normally use the 250 mark) and/or you are dealing with multiple 'types' of
> backend and/or 'client'.

You make a lot of sense.

I am thinking about re-designing an application I have mainly because I am
not familiar with VB and the current design is not easily maintainable.
Most of the business rules live on the backend Oracle db and the rest live
in a VB COM object which spits out html to the client.   I have what seems
like billions of business rules and was thinking of pulling these out into a
Delphi middle tier.  The things I need most are better performance and
easier maintainability.  I only have about 10 users now but this could
increase.  The app interfaces with one other application and could possibly
interface with more in the future.

From what you say, it probably does not make sense for me to go the n-tier
route with this one.  Can you provide any advice?

Thanks,
Jan

Re:Real world BO 3-tier implementation


You already have 3 tiers:  an Oracle back end, a VB COM object, and an
html browser.  Delphi will probably perform better as the COM object.
Depending on how much interaction the user needs, you might want to
give them a Delphi client instead of the browser...

--
Brandon C. Smith
http://www.synature.com

Quote
"Delphi Fan" <delphifan2...@yahoo.com> wrote in message

news:95s2ga$4ug9@bornews.inprise.com...
Quote

> "Phil" <p...@shrimpton.co.uk> wrote in message

news:3a811f60_2@dnews...
Quote

> > I also often see people developing 3-tiers systems when they are
not
> needed,
> > or for the wrong reasons.  People are often mistaken that 3-tier
systems
> > will perform better than 2-tier systems, but I have yet to see a
> multi-tier
> > system out perform a properly written 2-tier thin client system.
IMO
> there
> > are two reasons for using a 'middle tier', the first one is for
load
> > balancing when your concurrent user count reaches a certain level
(I
> > normally use the 250 mark) and/or you are dealing with multiple
'types' of
> > backend and/or 'client'.

> You make a lot of sense.

> I am thinking about re-designing an application I have mainly
because I am
> not familiar with VB and the current design is not easily
maintainable.
> Most of the business rules live on the backend Oracle db and the
rest live
> in a VB COM object which spits out html to the client.   I have what
seems
> like billions of business rules and was thinking of pulling these
out into a
> Delphi middle tier.  The things I need most are better performance
and
> easier maintainability.  I only have about 10 users now but this
could
> increase.  The app interfaces with one other application and could
possibly
> interface with more in the future.

> From what you say, it probably does not make sense for me to go the
n-tier
> route with this one.  Can you provide any advice?

> Thanks,
> Jan

Other Threads