Web Services
    White Papers
    Industry Links
Contact Us

The Enterprise Application Framework (EAF) is the foundation on which each Q4W product is developed.

... Architecture
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:

  • Sorting
  • 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 improve performance.

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. On the client side JavaScript is used to provide 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 Internet.

... Framework
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 database elements.

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.

... Why 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.

  • 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 page requests.
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 applications."

To handle this problem applications use of the following techniques:

  1. 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.
    Cannot use cookies to manage state if you need certainty that your application functions even if the user turns off cookie support.
  2. 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 next page.
    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.
  3. 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
  4. ViewState from .NET maintain the state of input elements between postbacks of the same page.
    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.

... Security
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.