The Enterprise Application Framework (EAF) is
the foundation on which each Q4W product is developed.
The EAF consists of a multi-tier component-based
architecture with web-based clients. This promotes
a clean separation of presentation/user interaction,
core business logic, and data management. This
also extends client/server computing to support
application partitioning, more effectively develop
and deploy application business logic and to manage
the reliable execution in a network environment.
Each Server side component provides services through
public interfaces (API). Other components, including
3rd-party, can request services only through these
public interfaces. This is a natural extension
of the encapsulation concept introduced in Object
Oriented design and development. At the component
level, as long as the same public interfaces are
maintained, the system will function no matter
what components plug in.
The Application Server is implemented using COM+
configured services with .NET components. This
approach allows caching the information and pooling
the server side components, including connections
to the database, to use multi-threading and COM+
transaction mechanism. All components are highly
isolated from any RDBMS-specific features. Q4W
also has a version of the Application Server implemented
as set of Web Services, which work independently
or together with COM+ components. The EAF takes
advantage of new technologies such as Microsoftâ
.NET, XML and Web Services (SOAP).
The Enhanced Client Interface supports:
- Mature data validation
- Date/time checking
- HTML creation and caching (any data retuned
from server can be cached)
- Appending data on the client side
- Drilling up/down without requests to the server
- Standard form elements, tables and grids are
very well supported
As opposed to a standard web application where
the entire HTML page is generated in the application
server, the EAF sends an HTML template to the
client along with an encoded data stream. The
client then completes generation of the HTML page
by filling-in the encoded data into the template.
As a result, HTML pages along with specific data
are cached on the client, thereby significantly
The following diagram overviews the Enterprise
Application Framework Multi-tier Architecture:
In conjunction with Microsoft's strategy to support
multiple programming languages that compile into
Microsoft Intermediate Language (MSIL), supplemented
with the Common Language Runtime (CLR) environment,
C# and VB.NET are the predominate programming
languages used in Q4W's object-oriented Framework.
Should a customer prefer to work in only C# or
only in VB.NET, the EAF can accommodate this easily;
Visual Studio .NET is the IDE used for all development.
a dynamic HTML user interface running within Internet
Explorer *. The back-end relational database can
be SQL Server, Oracle, Access or MySQL.
* Users must have Microsoft® Internet Explorer
5.1 browser or later in order to activate over
The Q4W EAF provides a base framework of industry-neutral
components which remain constant across all applications,
as well as business specific framework components
which are common to vertical industry sectors.
The ndustry specific components typically focus
around user interface nomenclature, preferences,
validation constraints, business logic rules and
The following diagram overviews the Component
Level Enterprise Application Architecture:
Database Access library (DAL) - provides
communication interfaces with database using ADO.NET.
All functions are database independent and ready
to be used as part of a COM+ or ADO.NET transaction.
This component includes functions such as DataSet/Data
Adapter, Data Reader, and Store Procedures, Returning
String, DataSet, DataTable and Command. Component
automatically recognizes database type through
connection string, which is passed as a COM+ constructor
string. Implemented as COM+ configured service,
written in C# and VB.NET. When started, the Application
Server creates a pool of DAL COM+. The pool size
is increased dynamically by the limit, specified
as COM+ attribute.
Utility Library (UL)
- provides string and date/time manipulation functions.
Functions which are common across the Application
Server are located here. Implemented as a COM+
configured service, written in C# and VB.NET.
When started, the Application Server creates a
pool of UL COM+. The pool size is increased dynamically
by the limit, specified as COM+ attribute.
Web Service Template
- provides a prototype of Web Service code, which
includes main operations such as retrieve, insert,
update and delete data; used as a template for
any business component. Also provides examples
on using functions from DAL and UL; written in
C# and VB.NET.
COM+ Template - provides a prototype of
COM+ managed code, which includes main operations
such as retrieve, insert, update, and delete data;
used as a template for any business component.
Also provides examples on using functions from
DAL and UL; written in C# and VB.NET.
File Manager Serv(er) - built-in component
publishes interfaces for operations with files,
including file uploading and downloading. Implemented
as COM+ and Web Service; written in C# and VB.NET.
Admin Serv(er) - built-in component publishes
interfaces for user management, security, user
access roles, user and system preferences. Implemented
as COM+ and Web Service; written in C# and VB.NET.
Lookup Serv(er) - built-in component publishes
interfaces for information retrieving from different
tables and shown as pop-up helper dialogs. Information
about dialogs' content are defined in an XML file.
Implemented as COM+ and Web Service, written in
C# and VB.NET.
EDI Serv(ers) - built-in components for
receiving inbound and generating outbound messages.
Each EDI message can be flat text or XML format.
Transmits messages using FTP, MQ, MSMQ and e-mail.
Information about each message content, format,
and execution logic are defined in XML files.
Implemented as standalone applications (servers),
written in C# and VB.NET.
Report Serv(er) - built-in component publishes
interfaces for report generation. Provides functionality
for sorting and paging as well as reports configuration.
Report can be generated in HTML and Excel format.
Information about each report view and content
defined in an XML file. Implemented as COM+ and
Web Service; written in C# and VB.NET.
Utility Serv(er) - built-in component publishes
interfaces for operations with utilities tables.
Implemented as COM+ and Web Service; written in
C# and VB.NET.
Provide an Enhanced Client Interface? Although
a standard thin client interface may satisfy the
vast majority of application users today, the
departure away from a desktop rich client has
reduced some of those advanced capabilities. As
such the EAF provides an enhanced interface that
is the best of both worlds, while maintaining
the low maintenance of a thin client environment.
- The addition of rich client
side features discussed above
- Superior performance due to a reduction in
data transferred between client and server,
along with a reduction of requests to the server
due to more processing done at the client.
But there is another not so obvious reason, but
one important for any enterprise application.
Developing enterprise-level applications presents
you with a series of design challenges. A browser-based
interface poses the challenge of state management.
The EAF provides state management and effectively
handles it with minimal effort, so customers can
focus on core business logic. According to Leonard
Lobel ("Manage Session State on the Client",
Visual Studio Magazine, September 2003 Issue)
" Web-based applications use HTTP as the
protocol for transporting page requests and responses
between the user (running an ordinary Web browser)
and the application (running on a Web server).
HTTP is a stateless protocol, which means that
the server "forgets" about each client
the instant it delivers the response to the client's
page request. The Web server lacks any context
for previously served pages and treats subsequent
requests from the same client anew. This behavior
enables the Web server to satisfy thousands, even
millions, of users. Such a high degree of scalability
is impossible if the server must consume resources
in order to maintain each client's state between
This scheme works perfectly for static Web sites.
However, HTTP's stateless nature is an issue you
must resolve in order to deliver dynamic user
applications. Your application must keep track
of what a particular user is doing from page to
page, even though the server treats each page
as if it were the first and only one. You must
respond to users' actions as they navigate through
a series of pages within your application. In
other words, you must manage state in your Web
To handle this problem applications use of the
- Cookies to transfer data from page to page
for small pieces of state information.
Pros: You control how long the value
persists on the client machine, even after the
user terminates the session by closing the browser.
Cons: Cookies have unfavorable reputation
from a privacy and security standpoint.
certainty that your application functions even
if the user turns off cookie support.
- Hidden Fields are implemented as input values
in HTML forms and can be used to pass data from
one page to another without requiring cookies
or server resources.
Pros: ASP.NET makes it easy to manipulate
hidden fields from code; extremely large values
can be accommodated.
Cons: Must create one hidden field within
a form for each piece of data passed to the
Must be implemented for each page.
Must pass HTML page template and extra data
from server to client and back for each transaction.
Information is lost when user clicks on the
browser's Back button.
- Query strings.
Pros: Requires page to append desired
state information to next page's URL.
Cons: Less secure because data is exposed
to user in URL. Restrictive, because URLs are
limited in length and information is lost when
user clicks on the browser's Back button
- ViewState from .NET maintain the state of
input elements between postbacks of the same
Pros: Technique similarly to hidden fields
but much easier to implement.
Cons: ASP.NET encodes a Web page's input
elements into one long hidden field that is
passed between the client and server. Can only
use ViewState collection when state information
in postbacks is passed to the same page. Large
amounts of data cause long request and response
transmissions, which can result in noticeable
delays in serving pages. Complex data types
(such as objects and structures) are difficult
or impossible to manage.
The EAF provides a unique solution to the state
problem by maintaining state information in the
hidden page. The information is added or/and updated
from the server as part of transactions and holds
the necessary data for any page(s). This approach
dramatically simplifies navigation between pages,
reduces the amount of server's calls as well as
the volume of information passed to the server.
HTML pages are only templates for showing data,
which is then cached on the client browser after
the first request. This is included as part of
the Framework and requires no additional implementation.
Note: The EAF approach works not only in the .NET
environment, but also with other Microsoft technologies
as well as in Java server side implementations.
There are several levels of security built into
the EAF. The first is the ability to define user
roles and thereby enable/disable individual feature-sets.
At the communications level, the use of Secure
Sockets Layer (SSL) is supported.
... Loss of Connectivity
Should the client loose connection with the rest
of the network, the user has the ability to continue
to input data, but until the database connection
returns will the data be refreshed and current.