N-Tier Archicture

[Craig Somberg]

Proposed Environment:
WIN2K IIS web servers
WIN2K server(s) for COM/COM+
WIN2K SQL Server 7
VB 6 - Primary tool
C++ - Where needed on COM layer

Hello everyone -

I have a new client I am working with who has programmed themselves into
a corner (oh yes, we've all been there) and I am now charged with archicting
them into the future.

My biggest concerns are the middle tier issues like:

-- Should we put both COM servers for Business Logic and Data Abstraction
- ie all COM components on the same servers.

-- How big is the cost going to be to marshall data across Tiers where each
Tier represents an actual set of servers ?

My biggest disaster at present:

-- My client has ( do not laugh now ) maxed out the number of fields allowed
in a SQL Server 7 table - ie there are over 250 fields per table in many
of the key tables ( and yes, there are SELECT * in the ASP Pages ). My approach
will be to create a Data COM layer FIRST, where all data will be accessed.
This will allow me to change the underlying schema to a more efficient without
heavy re-writes on the front end ASP. Thoughts ?

The complete application must end up being highly scalable and able to handle
over 5,000 concurrent users during a registration process. And the only way
we can attack the application re-writes is in an evolutionary approach and
not a complete re-write.

Thoughts ?

Thanks,

Craig

[Thomas Eyde]

I would skip the COM layer until the database schema stabilize. Rewriting
asp is simple, quick and easy to deploy. Use classes if you have VB Script 5
installed. Anyway, move all data access code into their own includes and use
them.

Evolutionary re-write sounds like a smart thing. Gives immediate feedback.

How concurrent are the all 5000 users? Are they like 5 minutes editing and
..01 sec updating? Maybe you can postpone the scalability issue until (if)
you need it?

/Thomas

[Jason Langston]

"Craig Somberg" <csomberg@stageone.com> wrote

> My biggest concerns are the middle tier issues like:
>
> -- Should we put both COM servers for Business Logic and Data Abstraction
> - ie all COM components on the same servers.

Tough question. I assume by your description that currently there is no
middle-tier? If not, you have nothing to measure against, so personally, I'd
start on one server and closely monitor the load. If you're careful in your
design, it should be easy to later seperate the Data Abstraction components
to a different server later.

> My biggest disaster at present:
>
> -- My client has ( do not laugh now ) maxed out the number of fields
allowed
> in a SQL Server 7 table - ie there are over 250 fields per table in many
> of the key tables ( and yes, there are SELECT * in the ASP Pages ). My
approach
> will be to create a Data COM layer FIRST, where all data will be accessed.
> This will allow me to change the underlying schema to a more efficient
without
> heavy re-writes on the front end ASP. Thoughts ?

Yeah, I'd do almost the same thing. I like stored procedures so I'd use them
to "insert" the layer of abstraction. But, same idea.

I'd also try to identify what your first real performance bottleneck is,
especially under the load you describe below. Is it serving up pages? (get
rid of those SELECT * 's first and make sure the queries use WHERE clauses
to limit the number of records returned) Is it submitting the registrations
to the database? (Optimize the update process/code.) I've found you can make
a client real happy, in a short time by tackling a simple problem first, one
with visible results to the client. (they all say they want scalable, but
rarely are they willing to wait months while you build a beautiful, scalable
middle-tier)

> The complete application must end up being highly scalable and able to
handle
> over 5,000 concurrent users during a registration process. And the only
way
> we can attack the application re-writes is in an evolutionary approach and
> not a complete re-write.

Good idea. I've gone down the complete re-write road only to have the
project start dying a slow, horrible death. After wasting months trying to
recreate existing functionality and pissing off the client, I went to an
evolutionary approach. The client became much happier because they were able
to see progress within a short time. I was happier because they were happy.
And contrary to my first instincts, it wasn't that horrible modifying the
existing code. As terrible as some of the code was IMO, some of it actually
worked!

HTH,
JasonL