Your company wants a new order processing system that will make available data
from its legacy corporate mainframe system to users in a networked Windows NT environment. Eventually
(exact timetable is uncertain) the legacy database will be converted to SQL Server.
Individual users will have state-of-the-art workstations with the fastest available processors
and a lot of memory. Management anticipates high growth for the system, both because business itself
will increase, creating the need for new data-entry personnel, and because users from other departments
will begin to use the system as the business operations become more integrated. Marketing, finance, and
accounting groups (and possibly others as well) will access the same data at some point in the
future, and their exact needs are unknown at the moment.
Again, management has not decided at what point in the system's development
that the cutover from the legacy database storage to SQL Server will happen.
REQUIREMENTS
The major concerns for this scenario seem to be scalability, availability,
and extensibility, with perhaps a secondary need for good maintainability. Scalability is an issue,
because rapid growth in the number of users and connections could overwhelm a single server before
management has a chance to upgrade hardware to keep pace with demand.
Availability is also an issue, going hand in hand with scalability, because the
business objects implemented by this system will need to be available to growing numbers of new
users in the future in different locations.
The system must be extensible as well, because different groups of users in
the future may have different needs that require different user interfaces and perhaps even enhanced
sets of business rules.
A secondary requirement would then be maintainability, because the dynamic nature
of the environment implies that there may be numerous far-reaching changes and enhancements to the system
in the future.
DESIGN SPECIFICATION
Because of the high need for extensibility and maintainability, you will definitely
want a multitier application divided into at least the following components:
• A client-side user interface tier, which you might consider implementing as
a DHTML application over the corporate intranet. This would enable you to offload some businessrule
processing from network servers to those high-powered client workstations.
Less server-side activity would improve scalability, because increases in user
population would create less of an increase in demand on server resources.
The DHTML solution would at the same time preserve maintainability, because the
DHTML application download could be updated in the server deployment files and automatically
would download the updated files when users connect with their browsers. Finally, the DHTML client-side
interface could be split into several versions for different user groups, and thus provide high
extensibility as well.
• One or more business logic tiers, which may split in the future depending
on the needs of new groups of users. This would enhance extensibility. The business logic tiers
could be implemented as out-ofprocess COM components for best maintainability and extensibility. When
business logic required a change, you could just swap out the old components for their new and
improved counterparts.
• A data-access tier separate from the dataservices tier. This would help insulate
the business logic tiers from changes in the back-end data-services tier when the cutover from the legacy
data services to SQL Server happens. You could write the dataaccess tier as a COM component exposing
a set of data-aware object classes. The actual data-access technology would be private to the
object classes, so the business logic clients would need no change if the data-access technology
changed when the data-services tier changed.
• A data-services tier, which would initially be the legacy database
engine and would at some point be replaced by SQL Server. It would be best to
implement as few data integrity or business rules at this level in the legacy
database engine, because any such implementation would have to be re-created in
SQL Server when the cut-over happened.
