-Draft-
Architectural Patterns for Web Applications Jörg Noack1, Hamarz Mehmaneche 2, Homayoun Mehmaneche 2, Andreas Zendler2 1
Informatikzentrum der Sparkassenorganisation (SIZ) Bonn/Germany
[email protected] 2
MGM GmbH Munich/Germany
2
{hamarz.mehmaneche, homayoun.mehmaneche, andreas.zendler}@mgm-edv.de
Abstract As the Internet has dynamically evolved over the last few years Internet-derived technologies such as Java become more and more serious for enterprise computing. With the occurrence of new application types ranging from small-scale presentation services to large-scale mission-critical systems the lines between the original World Wide Web (based on static contents) and conventional applications begin to blur. However, major problems with ad-hoc developed Web applications like poor maintainability and poor scalability demonstrate that a well-established software architecture is a key factor for success. In this paper we study the definition of architectural patterns for Web applications and give hints for the selection and consistent implementation under certain circumstances.
Keywords Web applications, architectural description language, multi-tier architecture, components
1 Introduction Internet-based technologies have become more and more popular for enterprise computing. In a first wave the intranets had been introduced. They offer many advantages over traditional LANs. Their strength is based on extremely pervasive standards and protocols like HTML, HTTP and TCP/IP. Frequently used documents, multimedia objects and small programs can easily be made available to the employees over the internal networks. Browsers that reside on nearly every workstations serve as a universal front-end. The introduction of a “thin client“ on the workstation is a relevant strategy when heterogeneous operating systems (e.g. Windows and OS/2) have to be integrated [Dewi98]. The effort for expensive GUI-programming on multiple platforms can be reduced by defining the browser as the universal client. Moreover, Internet technology allows organizations to rethink their existing applications. Huge volumes of business data exist on centralized mainframes. Due to cost, performance and legal issues it cannot be moved to client/server or workstation platforms. In the past the access to this data was reserved for those users who had a mainframe connection (e.g. 3270 terminal) on their desktop. Using Internet technologies internal systems can be externalized to new user groups such as trading
partners, suppliers and customers. Under the marketing slogan “network computing“ a new paradigm of enterprise computing is propagated which combines the advantages of centralized data storage and decentralized processing. However, the development of new application types must address several challenges like • • • •
multiple platform standards scalability legacy integration and mission-critical performance.
Therefore, the selection of an adequate software architecture and implementation strategy become key issues IT management has to deal with. The rest of the paper is organized as follows. In the next section we study the building blocks of Web applications. Section 3 examines the process of deriving an architecture for client/server systems and extends it to Web applications. Section 4 defines a graphical description language which can be used in section 5 to discuss some selected architectures relevant for typical application scenarios in network computing. Section 6 concludes the paper with a summary and an outlook.
2 Building Blocks The structure of Web applications can be categorized as services and communication mechanisms. 2.1 System Services This block deals with vendor-offered standard services, which can be integrated into Web applications: • Browser, plug-ins, helper, Java Virtual Machine (JVM) • Web server (system) • TP monitor • Database management system (DBMS). 2.2 Application Services Presentation and Business Logic has to be created by the developers. It can be classified as follows: • Presentation Elements consist of HTML pages, multimedia objects (audio, video, 2D and 3D graphics) and scripts. • Program Code can be interpreted by a virtual machine when loaded as an applet or servlet or executed as machine code. • Components are software blocks fulfilling the requirements of a specific component model. Widespread examples are ActiveX [Chap96], Java Beans [Hunt98] and Enterprise JavaBeans (EJB) [SUN99a]. 2.3 Communication Mechanisms The communication between the different services is based on a set of protocols or interfaces: • Browser/ Web server: HTTP (and its secure variants S-HTTP and HTTP-S) is the standard protocol for the communication between a browser and a Web server. Since HTTP is a stateless protocol, its usage is restricted.
• Web server / server application program: The communication between a Web server and an application program extending its functionality can be based on different APIs like CGI, ServletAPI, ISAPI, NSAPI etc. [Linth98]. • Object communication: Distributed objects written in Java or in any another Web programming language can talk to each other using different protocols like RMI, IIOP and RPC [OrHa97]. • Database access: There are several standards like SQL, ODBC and JDBC to interface databases [OrHa97]. • Gateways: They bridge the gap between a mainframe and a Web environment. The “CICS gateway for Java“ connects a Java-enabled browser to a CICS program running on the mainframe [IBM99].
3 Describing Software Architectures Layering is an engineering principle that helps to reduce the complexity of systems. Each layer is an abstraction of a specific problem domain. It provides well-defined interfaces. A hierarchical order guaranties that a layer can be implemented using the interfaces provided by lower layers. The reduction of dependencies between modules, the local treatment of changes, portability and reuse aspects are well-known benefits of a layering approach [BPRS96, p.31]. Logical layers
Physical tiers
UI
User interface (UI) Presentation
Dialog control (DC)
Technichal infrastructure
Remote Presentation
DC
Workstation (Client) n
Application Kernel
Data management
Business process control(BPC)
BPC
Physical data access (PDA)
1
BDO
Business objects (BO) Logical access (LDA)
LAN
Remote Data
LDA
Departmental Server
PDA
Figure 1: Architectural Mappings in a client/server environment
The six layers in fig. 1 represent a refinement of the standard three-layer architecture also known as “Seeheim-model“[NoSc99]. The presentation layer contains the user interface and the dialog control. The application kernel consists of the business domain objects, which implement the business needs, and the business process control objects, which implement workflow specific information. The data management layer provides data access functions and deals with object persistence issues. In order to define the distribution of application components the logical architecture must be mapped to physical tiers. Gartner Group [Schul95] defines five distribution patterns for the 2-tier client/server paradigm: • Distributed Presentation • Remote Presentation
• Distributed Function • Remote Data • Distributed Data These patterns being orthogonal to each other can be combined for multi-tier approaches: Fig.1 illustrates a 3-tier architecture derived from the parallel application of the remote presentation and distributed data pattern. In the next step the distribution units have to be allocated on the processing nodes of the technical infrastructure. Whereas the user interface is mapped on the workstation-node, there are alternatives for the other tiers in a client/server environment [Bers96]. Scalability is the reason why distribution units, which originally run on the same node, should be separated in different tiers. In fig. 1 a black border is put around the 3 tiers. The user interface is allocated on the workstation. The two others run on the departmental server. The architectural process described above can easily be adapted to network computing environments. While logical layering applies as well, there are some particularities when mapping logical to physical tiers. In the following we distinguish between 4 tiers: • The Web client typically presents the user interface in a browser. • The Web server is responsible for the distribution of HTML-documents, multimedia objects or Java-applets requested via HTTP from a Web client. • The application server controls the business processes and domain objects. • The data server provides data access functions and deals with persistence. 2-tiers
3-tiers
4-tiers
4-tiers with partitioning
Web client
Web client
Web client
Web client
Web server
Web server
Web server
Web server
data server
application server
application server
data server
data server
Figure 2: Physical tiers of Web applications
Different types of Web applications can be described using a relevant combination of tiers (fig. 2). The 2-tier architecture can be used for the simple presentation of static HTML documents requested from a browser while a high-sophisticated scenario with multiple application and data servers is based on the partitioned 4-tier architecture.
4 A Graphical Description Language According to [GTP95] an architectural description encloses a vocabulary of design elements (components and connectors), constraints describing the valid combinations of these elements and a semantic interpretation for a system description. The pole shoe notation (fig. 3) provides a description language for physical architectures. The pragmatic approach considers constraints but omits formal aspects of semantic interpretation. System service HTML
Multimedia
(a) JavaApplet
Program
Protocol
System service
(b)
Application Service
(c)
Service 1
Protocol P Service 2
Figure 3: Pole shoe notation
The building blocks of section 2 represent design elements of the language. System and application services correspond to components and communication mechanisms to connectors (fig. 3a). The fact that a system service is represented as a pole shoe surrounding an application service means that the application service is executed under control of the system service (fig. 3b). A protocol defines the basic communication mechanism between two services (fig. 3c). Obvious constraints, which can be derived from the preceded discussions, are the following: • A browser is part of the Web client tier. • The Web server system is part of the Web server tier. • A DBMS is part of a data server tier. • A TP monitor is part of an application server tier.
5 Architectural Patterns In this section we discuss three architectural patterns for Web applications considering the following aspects. • Problem: addresses the problem domain for which the architecture defines a solution. • Example: describes a real-world example demonstrating the existence of the problem. • Structure: specifies the architecture using the pole shoe notation. • Implementation: gives some advice which technology can be used. • Remarks: evaluate scalability and performance aspects. In order to simplify matters we omit further aspects like security or development strategy, which are also relevant when applying the patterns.
5.1 Web-enabled databases Problem A browser front-end should be attached to a (new or existing) database. The information retrieved from the database has to be presented in different shape (e.g. documents and multimedia objects). Constraints have to be checked before updating the database. Example A manufacturer decides to externalize his product database to the WWW. Product information should be offered using audio and video animations. Individual discounts for specific products can be calculated. Structure The architecture of fig.4 consists of three tiers: a web client, a web server and a data server. The (relational) DBMS sends data to a web server and receives updates from it. Transaction management is handled by the DBMS. The web server prepares an interactive view for the information from the database. The web client views HTML documents and multimedia objects. Browser Web client HTML
JavaVM Multimedia
Applet
Objekt communication
HTTP
Web server system Web server Server Program WS-API DB-Interface
DBMS Data server
Queries & Updates
Figure 4: Web-interface to existing database
Implementation HTML pages, included applets and multimedia objects will be uploaded from the web server site when requested via HTTP. The browser’s functionality must be extended with a JVM to run the applet and with plug-ins to present the multimedia objects. There are several technological alternatives for the implementation of the web server. The selection of a specific web server-API can induce a certain implementation strategy. E.g. programs using the common gateway interface (CGI) are usually implemented in Perl or Tcl, whilst the servlet interface is reserved for Java-servlets. In a pure Java environment Remote Method Invocation (RMI) can be used for client-communication and JDBC for database-communication [SUN99b].
Remarks The architecture implies one process per database-client and therefore, it suffers from limited scalability. 5.2 Web-enabled legacy applications Problem A legacy application running under the control of a TP monitor should be extended to serve new clients working with a browser front-end. Example A business process-reengineering project comes to the conclusion that all the suppliers of a company should get direct access to the inventory system. Structure Fig. 5 describes a 4-tier architecture. Since web server / web client -communication has been discussed in the preceding architecture, we concentrate on the integration of the legacy application. Typically, the application logic of the legacy system runs on an IBM-mainframe under control of a TP monitor using the TP/XA interface for the connection to a DBMS. A gateway program talks to the TP monitor in a program-to-program mode (e.g. using SNA-protocol LU 6.2). The gateway program acting as a client to the TP monitor can be connected to the CGI-program using IBM’s External Call/ External Program Interface (ECI/EPI).
Browser Web client
Web server system Web server
CGI
Program (PERL, TCL,...)
ECI/EPI
TP-Client program
(LU6.2, ...)
TP monitor Application server
Program Program
(TP/XA)
Legacy application
DBMS Data server
Query & Updates
Figure 5: Web-enabled legacy applications
Implementation The task of converting input and output screens into HTML pages can be automated using some standard software (cf. [IBM99]). A more detailed discussion for accessing mainframe information can be found in [TLRH98].
Remarks Although thousands of clients could be handled through a TP monitor [GrRe93], the bottleneck of this architecture lies in the CGI, which restricts performance and the number of concurrent users.
5.3 Component architecture Problem Legacy services and data should be bundled with new functionality in order to build a highperformance application. Example A bank decides to connect its existing securities-trading application and customer relationship database to the WWW for online-brokerage. Structure Enterprise JavaBeans is a component model for the integration of new application functions with enterprise information systems. Fig. 6 presents a multi-tier architecture based on this model. The structure of legacy services and data is faded out. To simplify matters even more, the web server tier has been omitted.
Client object
EJB client
EJB stub
IIOP
EJB server EJB container EJB1
EJB server
EJB2 EJB3
Legacy application
Legacy data
Figure 6: EJB-based component architecture
Implementation The reader may assume that the considered client object resides in an applet being loaded from a web server or resides in a stand-alone program. Client objects use a stub-mechanism to talk via IIOP to the EJB server. Since the EJB specification [EJB99] does not imply a certain protocol, RMI or RPC could be used as well. The EJB server tier represents the kernel of this architecture. It consists of three layers. The EJB server (software) (which encloses one or more EJB containers) provides services for the management of distributed transactions. EJBs are components that encapsulate a certain part of the application logic (s. EJBs 1-3 in fig.5). The container insulates the
EJBs from the server by supplying a standard interface to messaging, transaction and data access services. Remarks The EJB-based component architecture is appropriate for small-scale applications and large-scale business transactions. Additional clients can be added without modifications of the application kernel.
6 Conclusions Internet-based technologies move into enterprise computing. However, the usability of Web applications depends on the selection of an adequate architecture. In this paper we have pointed out that well-known client/server architecture principles like layering and distribution patterns can easily be applied to Web application architecture. With the pole shoe notation an architectural description language has been introduced which reflects the building blocks of Web applications and allows for discussions on an abstract rather than an implementation level. The suitability of our approach is underpinned with three architectural patterns relevant for typical scenarios. The strong need for an integration of enterprise data and services leads to multi-tier architectures, which help to achieve the following goals: • Scale to high user loads • Simplify and standardize development of business applications. • Separate application logic from system services • Enable development of portable components and • allow multi-vendor interoperability. Broadly accepted standards like Enterprise JavaBeans and the forthcoming vendor-neutral CORBA 3 [OMG99], which supports other languages (C++, Cobol) in addtion to Java, may help to escape from proprietary solutions. References [Bers96]
A. Berson: Client/Server Architecture, McGraw-Hill, 1996.
[BMRS96]
F. Buschman, R. Meunier, H. Ronert, P. Sommerlad, M. Stal: Pattern-Oriented Software Architecture, A System of Patterns, John Wiley 1996
[Dewi98]
D.T. Dewire: Thin Clients - Delivering Information Over the Web, McGraw-Hill, 1998
[Drey98]
P. Dreyfus: The Second Wave, Netscape on Usability in the Services-Based Internet, IEEE Internet Computing, Vol. 2, No. 2., March/April 1998, 36-40
[GrRe93]
J. Gray, A. Reuter: Transaction Processing, Concepts and Techniques, Morgan Kaufmann Publishers 1993
[GTP95]
D. Garlan, W. Tichy, F. Paulisch: Dagstuhl Software Architecture Workshop, ACM Software Engineering Notes, 20 (3), July 1995, 63-83
[GVWV98] A. Gupta, C. Ferris, Y. Wilson, K. Venkatasubramanian: Implementing Java Computing - Sun on Architecture and Applications Deployment, IEEE Internet Computing, Vol. 2, No. 2., March/April 1998, 60-64 [Hunt98]
J. Hunt: Essential JavaBeans fast, Springer Verlag, 1998
[IBM99]
IBM: CICS Internet Gateway, 1999, http://www.software.ibm.com/ts/cics/platforms/internet/igateway/index.html
[Chapl96]
D. Chappell: Understanding ActiveX and OLE, Microsoft Press,1996
[Lint97]
D. Linthicum: Guide to Client/Server and Intranet Development. John Wiley & Sons, 1997
[OrHa97]
R. Orfali, D. Harkey: Client/Server Programming with Java and CORBA, John Wiley & Sons, 1997
[PCCR98]
C. Peng, S. Chen, J. Chung, A. Roy-Chowdhury, V. Srinivasan: Accessing business data from the World Wide Web, IBM Systems Journal, Vol. 37, No. 1, 1998, 115132
[NoSc97]
J. Noack, B. Schienmann: Introducing Object Technology in a Large Banking Organization, IEEE Software, May 1999, 71-81
[OMG99]
OMG: CORBA Components Specification, 1999 http://www.omg.org/docs/orbos/9902-05.pdf
[Schul95]
R. Schulte: Three-Tier Computing Architectures and Beyond. Gartner Group, 1995
[SUN99a]
Sun Microsystems: Enterprise JavaBeans Specification 1.1, 1999 http://java.sun.com/products/ejb/docs.html
[SUN99b]
Sun Microsystems: Java 2 Platform, 1999, http://java.sun.com/jdk/
[TLRH98]
Y.S. Tan, D.B. Lindquist, T.O.Rowe, J.R. Hind: IBM eNetwork Host on Demand: The beginning of a new era for accessing host information in a Web environment, IBM Systems Journal, Vol. 37, No. 1, 1998, 133-152
