Web technology for developers

To learn about Web applications and their relationship with services and databases, see the following sections:

Some of this material is from Enterprise Web 2.0 with EGL (MC Press, 2009; http://www.mc-store.com/5107.html).

Web sites and applications

The World Wide Web is an Internet subsystem that provides access to Web pages and to software services that offer various kinds of data and functionality. For details on services, see "Service-oriented architecture (SOA)."

A Web site is a collection of pages that a browser can retrieve from an Internet domain—for example, www.ibm.com—or is a defined subset of such pages—for example, the EGL Café (www.ibm.com/rational/eglcafe). The pages are served—that is, transmitted—from a Web server, which is specialized software that, in most cases, runs on a machine remote from the user.

Serving a Web page

A Web site can make available a Web application, which is logic that fulfills a business purpose and that uses the facilities of the World Wide Web. In most cases, people navigate from one Web page to the next by clicking an on-screen widget, which is a button or other on-screen control.

Rich Internet Applications (RIAs)

A Rich Internet Application (RIA) is a Web application that runs in a browser. The RIA provides the visual and interactive characteristics of a desktop application.

Client-side processing

An RIA allows for a user experience that goes beyond simply receiving a page and submitting a form. For example, after someone clicks a radio button, the code might respond by changing the content of a text box.

The change occurs quickly because the logic runs locally. This client-side processing is in contrast to server-side processing, which involves forming a page on the Web server and transmitting that page to the browser.

Server-side processing

Server-side processing often involves the download of multiple pages. The client-side approach lessens the load on the server-side machine and reduces the need for hardware.

The RIA technology in IBM® Rational® EGL Community Edition uses the following technologies:
  • JavaScript™ is the source language for the client-side logic. You do not code in JavaScript; instead, the workbench transforms your EGL code into the JavaScript that is processed at run time.
  • Asynchronous JavaScript and XML (AJAX) is a capability that ties the client and server after the Web page is served. While logic runs in the browser, AJAX permits three actions: first, the client invokes code on the server; second, in response to the invocation, the client accepts data that is transferred from the server; and third, the client uses the transferred data to redraw either a Web page or a section of the page. For example, after someone selects a purchase order from a list, the RIA might request transmission of order-item details from the remote Web server and then place those details in a table displayed to the user.
    Use of AJAX in a Rich Internet Application

The invocation of server-side logic is asynchronous, which means that after the client requests data from the server, the client-side processing continues rather than stopping to wait for a response. The user can continue working on the page. Another aspect of AJAX is that the user might not even notice that time elapsed between specifying a detail—in this case, an order number—and receiving a response.

When you use EGL, the technology for developing RIAs is named EGL Rich UI, and the RIAs are named Rich UI applications.

The DOM tree

This section describes how browsers handle an EGL Rich UI application at run time. You might need this information for two reasons:
  • To learn the Rich UI technology faster, as is possible if you understand the runtime effect of what you code at development time
  • To more quickly learn how to do advanced tasks

When someone enters a Web address into a browser, the browser transmits a request to a Web server, which is typically on a second machine. The address identifies a specific server and indicates what content returns to the browser. For example, if you enter http://www.ibm.com, a server replies with a message that the browser uses to display the IBM home page. The question that is of interest now is, how does the browser use the message?

The browser brings portions of the message into an internal set of data areas. The browser then uses the values in those data areas to display on-screen controls, which are commonly called widgets. Examples widgets are buttons and text fields.

Consider the following Web page:

Example Web page

Seven widgets are displayed:
  • The enclosing box is myBox
  • The upper box within myBox is myBox02 and includes the text field myHelloField
  • The lower box within myBox is myBox03 and includes the text field myInTextField, the button myButton, and the textField myOutTextField

The internal data areas used by the browser are represented by an inverted tree:

Example DOM tree

The tree is composed of a root, named Document, and a set of elements, which are units of information. The topmost element that is available to you is named Body. The elements that are subordinate to Body are specific to your application.

A set of rules describes both the tree and how to access the data that the tree represents. That set of rules is called the Document Object Model (DOM). The tree is the DOM tree, and the relationships among the DOM elements are identified by using terms of family relationships:
  • myBox03 and myInTextField are parent and child
  • myBox and myButton are ancestor and descendant
  • myInTextField, myButton, and myOutTextField are siblings
In the simplest case, a widget reflects the information in a single DOM element. In other cases, a widget reflects the information in a subtree of several elements. In all cases, the spatial relationship among the displayed widgets reflects the DOM-tree organization, at least to some extent. The following rules describe the default behavior:
  • A widget that reflects a child element is displayed within the widget that reflects the parent element
  • A widget that reflects a sibling element is displayed below or to the right of the widget that represents the immediately previous sibling element

You might use a technical shorthand that communicates the main idea without distinguishing between the displayed widgets and the DOM elements. Instead of the previous list, you might say, “A widget is contained in its parent, and a sibling is displayed below or to the right of an earlier sibling.”

The DOM tree organization does not completely describe how the widgets are arranged. A parent element might include detail that causes the child widgets to be arranged in one of two ways: one sibling below the next or one sibling to the right of the next. The display also may be affected by the specifics of a given browser; by example, by the browser window size. Last, the display may be affected by settings in one or more cascading style sheets, which are files that set display characteristics for an individual widget or for all widgets of a given type.

For details about creating a DOM tree, see “Developing Web applications by using EGL Rich UI.”

Rich UI applications and the EGL proxy

The next figure illustrates the runtime relationship of a Rich UI application—that is, a Rich Internet Application written with EGL—and multiple servers.

Rich UI application and the EGL proxy

The Rich UI application is deployed on a server machine, and the server responds to a browser request by transmitting a file—specifically, a Hypertext Markup Language (HTML) file—that includes the application. By this point, the application is in JavaScript format, not EGL source format. The browser runs the application, which can access one or more Web services.

To access a Web service, the application contacts the EGL Rich UI proxy, which is logic that is deployed on the server machine that transmitted the file. In most cases, the Web service is on another machine. The Rich UI proxy handles the transfer of data to and from all Web services.

Web servers and application servers

A Web server is software that receives browser requests and that transmits Web pages and other content in response. In most enterprise computing, the Web server is a front end for the more complex processing that is available from an application server. The Web server is an intermediary, receiving the user's request and passing it to software, such as the EGL Rich UI proxy, which runs directly in the application server.

When you use EGL, an application server supports Java™ Enterprise Edition (JEE), which is a Java Runtime that provides special handling for security, database access, and other areas of enterprise processing. Some server-side products—such as IBM WebSphere® Application Server—are fully compliant with JEE; and some—such as Apache Tomcat—are partially compliant. For purposes of this introduction, both kinds of products are JEE-compliant application servers. In contrast, some server-side products—such as Apache HTTP Server—have no JEE support and might not even be written in Java. That kind of product is a simple Web server.

An EGL Rich UI application must be installed on a JEE-compliant application server. The server is said to be the container of the applications deployed to it.

Deployment files

When you deploy a Rich UI application to a server, you provide a variety of files. Always present is an HTML file that includes JavaScript. You might also provide supplementary files with additional content:
  • CSS definitions
  • Multimedia content (graphics, video, and music)
  • Runtime messages (and user-interface content) for users who speak one or another language.

You deploy the application files in a Web Archive (WAR) file, which is a compressed file that is similar to a .zip file.

When you deploy a Rich UI application or a service to Apache Tomcat, you provide only a WAR file. The WAR file includes the Web deployment descriptor (web.xml), which establishes the characteristics of the runtime environment. In particular, the Web deployment descriptor includes resource identifiers; these identifiers refer to external resources such as databases.

When you deploy a Rich UI application or a service to a fully JEE-compliant Web server, such as WebSphere Application Server, you also provide an Enterprise Archive (EAR) file, which is another compressed file. The EAR file includes WAR files and other deployable logic; for example, Java Archive (JAR) files. The EAR file includes the EAR deployment descriptor application.xml, which associates resource identifiers—as specified in the WAR file—with runtime locations.

Application servers such as Apache Tomcat do not use EAR files. On those application servers, the association of resource identifiers and runtime locations is in the WAR file, in the compressed file context.xml.

You can use EGL to package the output of your work into WAR files and (in some cases) EAR files, as appropriate to the target deployment environment. As necessary, EGL deployment also creates context.xml.

Simple Web servers use neither WAR files nor EAR files.

Rich UI applications in an enterprise

An EGL Rich UI application is likely to be the front end of a complex runtime environment.

Rich UI application at run time

This example includes four logical tiers:
  • Tier 1 is a Web browser where the Rich UI application runs
  • Tier 2 is a Web server that transmits the Rich UI application and handles the subsequent access of services by the code
  • Tier 3 is the software that runs a service-oriented application, as described in “Service-oriented architecture (SOA)”
  • Tier 4 is the software that supports database access

A tier is logical in the sense that some or all of the tiers can be on the same machine. For example, as you write a Rich UI application, at least tiers 1 and 2 are on the machine used for development, and you can use a simulated proxy to access tier 3.


Feedback