Originally, the two-tier, client-server application model promised improved scalability and functionality. Unfortunately, the complexity of delivering EIS services directly to every user and the administrative problems caused by installing and maintaining business logic on every user machine have proved to be major limitations. With these client-server model, ever changing business conditions and logic required enormous maintenance efforts and costs. Supporting such different layers of applications and potentially accessing data from a vast variety of sources and distributing it to multitude of clients proved to be inherently complex, costly and time consuming.

These inherent limitations of client-server architecture (two-tier) are avoided by implementing enterprise services as multi-tier applications. Multi-tier applications provide the increased accessibility that is now demanded by all elements of an enterprise. A multi-tier Enterprise Application Model should be designed to support applications that implement the enterprise services for enterprise's business actors, to name a few: customers, employees, suppliers, partners, and others who make demands on or contributions to the enterprise. As depicted in Figure-1, this strategic shift in enterprise backbode is driving major investments in the development of the middle-tier software.

To better control and manage the enterprise data, applications, and the business functions to support vast variety of users are conducted in the middle layer. The middle layer represents an environment that is closely controlled by an enterprise's information technology department. The middle layer is typically run on dedicated server hardware and has access to the full services of the enterprise.

Enterprise applications often rely on the EIS-Tier to store the enterprise's business-critical data. This data and the systems that manage it are at the inner-core of the enterprise.

Figure-1 Two-Tier vs Multi-Tier Enterprise Application Models

Developing multi-tier services has been complicated by the need to develop both the service's business function and the more complex infrastructure code required to access databases and other system resources. Because each multi-tier server product had its own application model, it was difficult to hire and train an experienced development staff. In addition, as service volume increased it was often necessary to change the whole multi-tier infrastructure, resulting in major porting costs and delays.

Enterprise Application Model defines a multi-tier architecture for implementing enterprise services that avoid problems associated with client-server model while delivering much needed scalability, accessibility, and manageability.

An important goal of the Enterprise Application Model is to minimize application programming. This is accomplished by shifting the burden of implementing common tasks from developers to the Enterprise Application Patform. These common tasks include enforcing an application’s security roles, implementing its transaction semantics, and linking its components to the resources and other components they require. Enterprise application model partitions the work needed to implement a multi-tier service into two parts: the business and presentation logic to be implemented by the developer, and the standard system services provided by the enterprise application platform. The developer can rely on the platform to provide the solutions for the hard systems-level problems of developing a middle-tier service.

The Java 2 Enterprise Edition (J2EE) application platform provides the benefits of Enterprise Application Model, at the same time it provides the Write Once, Run Anywhere(tm) portability and scalability for multi-tier applications. This standard model minimizes the cost of developer training while providing the enterprise with a broad choice of J2EE servers and development tools. The J2EE application model is a major step forward in simplifying and expediting application development, by minimizing the complexity of building multi-tier applications.

J2EE application model begins with the Java programming language and the Java virtual machine. With proven portability, security, and developer productivity, Java environment provide the basis of the enterprise application model.

The application model also includes the JavaBeans(tm) component model. JavaBeans components make it easy to componentize the Java technology-based code for common functions, then customize and combine these components visually with JavaBeans development tools.

While two-tier client-server application models require platform-specific security measures in each application, enterprise application platform's security environment enables security constraints to be defined at deployment time. By shielding applications from the complexity of implementing security, the enterprise application platform makes them portable to a wide variety of security implementations.

J2EE platform defines standard declarative access control rules to be defined by the application programmer/assembler and interpreted when the application is deployed on the enterprise platform. It also requires platform vendors to supply standard login mechanisms so applications do not have to incorporate these mechanisms into their logic. The same program works in a variety of different security environments without change to the source code.

As an example, an enterprise application developer can specify several levels of security (say user, super-user, and administrator), then write code to check the current user's permission level when accessing secure operations. At deployment time, the Application Deployer assigns groups of users to the appropriate security levels, enabling the application to easily verify permission level before performing the restricted operations.

The major benefit of the enterprise application model is in the middle layers of multi-tier applications. In the enterprise application platform, middle-tier business functions are implemented as Enterprise JavaBean(tm) (EJB) components, as shown in Figure-2 These enterprise beans allow service developers to concentrate on the business logic and let the EJB server handle the complexities of delivering a reliable, scalable service. JavaServer Pages(tm) (JSP) technology and Java servlets present middle-tier functions to the client tier as simple-to-access Internet-style services.

Figure-2 EJB Components Implement Business Logic in the Middle Layer

In multi-tiered enterprise platforms, implementation of middle tier is greatly scalable. Almost all enterprise platforms, it makes sense to separate the business logic layer from the presentation layer. As seen in Figure-3, separating the business layer from the complexities of dealing with constantly changing client layer (HTTP clients, wireless devices, Java programs, applets, etc.) without effecting the performance and/or integrity of the business logic. This strategy allows business logic layer to concentrate on enterprise rules with a clear vision of the business itself.

Figure-3 Middle Tier Scalability

Enterprise application platform supports variety of clients. Many enterprise services can be designed to support web browser clients interacting with clients via dynamically generated HTML pages and forms. Different and more sophisticated services can interact with the clients by directly exchanging business data. Here, Java Server Pages (JSP) and JavaServlets are used to format enterprise business data in a way that is easy for clients to work with. JSP technology makes it easy for developers to present dynamically generated user interface pages to any client with a browser. Java Servlets give more sophisticated developers of Java technology-based applications the freedom to implement dynamic presentations completely in the Java programming language. In addition, clients can be both Java applets running in a web browser and Java technology-based programs.

Again, it is important to note that security is an integral part of all multi-tiered enterprise services. In most cases, in an enterprise application platform, security is handled almost entirely by the platform itself and the administrators without requiring developer written security logic for the application services nor its clients.

Now, lets look at some of the most commonly used client types:

Web (HTML) Based Clients
A service can be presented directly to a user's web browser as dynamically generated HTML pages. JavaServer Pages technology is an easy way to dynamically compose these pages using a familiar scripting paradigm that combines HTML and Java technology-based code, as shown in Figure-4. In some cases, a service may require some fairly complex code. This can be handled by placing code in a JavaBeans component and calling it from a JSP. A service can also be directly programmed in the Java programming language using a Java servlet.

Figure-4 Presenting Services Directly to a Web Client

XML & HTTP Content Based Clients
XML allows enterprises to define standard data formats for exchanging data between disparate heterogeneous systems. Data formats are created by defining semantically rich tags that are able to describe the information they contain. In many respects the J2EE platform provides a heterogeneous framework for deploying distributed applications, while XML provides a cross-platform framework for manipulating information. It is often useful to provide functionality directly at the client that helps a user organize and interact with the service's information. In this case, the service exchanges raw content with the client instead of HTML pages. This content is typically in the form of XML documents that are exchanged between the client and the service using the HTTP protocol.

Typically this XML content can be handled in the client layer by JavaBeans components that are provided by the service in an applet that is downloaded into a user's browser. Furthermore, the same XML content can be formatted by combination of JSP and XSLT documents to create additional XML pages or presentation of enterprise data on Wireless devices (WML). As shown in Figure-5, this flexible model provides the developer with a broad range of choices for presenting a distributed application's user interface on the Internet.

Figure-5 Combination of JSP and XML Technologies

Intranet Clients
Both HTML page based services and HTTP content based services can be effectively used on an enterprise's Intranet as well as the Internet. In addition, the enterprise Intranet provides the extra infrastructure (high speed networks, etc.) that allows Java programs to directly access EJBs within the intranet domain.

Other Client Types & Interoperability
Enterprise services presented via standard HTTP, HTML and XML are easily accessible to all clients including Microsoft products such as Visual Basic and Office 200. One goal of Enterprise JavaBeans technology is to define CORBA standard RMI-IIOP as the required interoperability mechanism. This will make any J2EE service available to any CORBA client, ensuring more complete integration between the J2EE platform and existing enterprise information systems.

Sun Microsystems, in conjunction with J2EE, provides white papers and technology demonstrations that illustrate techniques for integrating Microsoft COM objects with EJBs using RMI-IIOP. These whitepapers cover how to access EJBs from first-tier clients such as Visual Basic and Windows 2000 via COM, as well as using EJBs in combination with middle-tier functions implemented in Microsoft Transaction Server.

Btech Consulting Inc. uses the Java 2 Enterprise Edition (J2EE) platform by Sun Microsystems on Enterprise Relationship Management engagements, which is the standard environment for running J2EE applications. The J2EE platform is composed of the following standards:

The primary element of the J2EE platform is the list of Java technology standards that all J2EE products are required to support. Since the J2EE platform is focused on the end-to-end development of enterprise solutions, it goes beyond simply requiring that each Java API be supported. It requires that each API be fully integrated with the platform. This insures that the platform delivers a consistent end-to-end environment for the deployment of J2EE applications.