|
...However, their core, enterprise Web applications differ very little from past incarnations transactional processing systems. Over the past several years, as more and more businesses have automated and integrated business processes, the result has been that the number of individuals developing enterprise applications has grown dramatically. In the past, developers building enterprise applications formed a relatively small community with specialized skills to develop high-throughput, reliable transactional systems. As the number of developers building enterprise applications has grown, more and more general software developers have moved into the development of enterprise applications. In this context it is useful to examine the issues facing the platforms on which enterprise Web applications are built.
At their most basic level, enterprise Web applications are used for transaction processing. Therefore, it stands to reason that the well-known issues from the rich history of transaction processing apply equally well to enterprise Web applications as to past transactional processing systems. The main issues that must be dealt with in the development of transactional systems include: resource management and utilization, concurrency and parallelism, failure management, persistence of data, and configuration management. Since enterprise Web applications do more than just transaction processing, other issues must be examined in addition to the characteristic transaction processing (TP) issues. These nontransaction processing (non-TP) issues include memory leaks, the efficiency at which data flows through the layers of the application and underlying frameworks, and overly generalized application components and frameworks. An understanding of both the characteristic transaction processing issues and the nontransaction processing issues is not only necessary to develop and deploy successful enterprise Web applications, but is also necessary in looking to the future of the platforms that support these applications. Similar to the spirit of the article "Hints for Computer System Design," (1) which illustrated the issues in the development of operating systems, this paper shows the issues in the development of transactional Web applications.
The next section gives a brief introduction to the topology of the environment in which transactional Web applications execute. The intent of this section is not a tutorial on how these applications can be configured; rather it is to describe the distributed nature and the complexity of the environment in which these applications run. We then discuss the TP issues in the third section. The fourth section discusses the non-TP issues, and the last section concludes the paper.
Topology of Web applications
Figure 1 shows an example of a topology for a Web application, taken from the WebSphere* 5.0 handbook. (2) This topology is not meant to be representative, but rather just a simple example to illustrate the concepts in the layout of Web applications. (3) Real topologies are typically much more complex when the goal of the deployment is integration of disparate sources of data or functionality. In this topology, a Web server node sits between the application servers and the Internet. The Web server services static content (such as HyperText Markup Language, or HTML, pages). Any requests that require dynamic content, that is, processing by servlets, JavaServer Pages** (JSP**), Enterprise JavaBeans (EJB**), back-end data, and so forth are sent to the application server node.
[FIGURE 1 OMITTED]
There can be multiple application servers (multiple Java Virtual Machines each running an application server) on a single machine or multiple hardware platforms running application servers. When a single hardware platform (application server node) runs multiple application servers, the scaling of application servers is referred to as vertical scaling. When multiple physical application server nodes exist in the picture, the scaling is referred to as horizontal scaling. Multiple application servers can run the same individual units of work in the Web application. For example, in one scenario, two application server nodes can exist, each running one application server. On one node, the application server may be executing the presentation layer of the application, and on another node, the application server may be executing the business logic layer. The business logic application server will be mostly interacting with the database server.
In this topology, the Web server sits between two firewalls, increasing the levels of protection. On one side, the Web server links to the outside Internet using the protocol firewall, and on the other side, the application server nodes are protected still further by the domain firewall. The directory services back end (Lightweight Directory Access Protocol, or LDAP) typically provides other security services for users of the Web application--password, user name, authentication, authorization, and so forth. Finally, the database servers provide persistent storage for retrieval and storage of user data related to the business transactions.
Characteristic issues in TP application design
In this section, we discuss transactional processing issues.
Transactional servers are different from clients. The vast majority of application programmers begin their careers writing applications for clients. Beginning in this way is only natural, because the vast majority of humans begin their experience with computers by using client applications. Those programmers who are experienced with using shared computing resources rarely write transactional applications. As a result, application programmers approach their work with the point of view of client-side, interactive applications on machines where CPU and other resource utilization is not a problem, where concurrency is minimal (since eventually everything is bounded by user-interaction rates), using a particular set of application libraries (e.g., windowing toolkits based on graphical user interfaces, or GUts, and event-based programming paradigms), and, when using shared resources, with the assumptions of time-sharing systems.
None of these habits, libraries, and patterns serve the programmer writing server-side applications well, for reasons which we will expand upon in this and the following subsections. First, and most important, are issues of resources, scheduling, and concurrency. On a transactional server, unlike on a client, a unit of work has the following properties:
* It almost invariably executes with only its initial input from the user.
* Its output is not complete (and often not even transmitted) until the unit of work is completed.
* Unlike on a time-shared system, every unit of work that actually starts executing must be completed, unless it is aborted, in which case it never is completed.
* The concurrency model that is...
NOTE: All illustrations and photos
have been removed from this article.
Looking for additional articles?
Search our database of over 3 million articles.
Looking for more in-depth information on this industry?
Search our complete database of Industry & Market reports by text, subject, publication
name or publication date.
About Goliath
Whether you're looking for sales prospects, competitive information, company
analysis or best practices in managing your organization,
Goliath can help you meet your business needs.
Our extensive business information databases empower business
professionals with both the breadth and depth of credible,
authoritative information they need to support their business
goals. Whether it be strategic planning, sales prospecting,
company research or defining management best practices -
Goliath is your leading source for accurate information.
|
