Some of this material is from Enterprise Web 2.0 with EGL (MC Press, 2009; http://www.mc-store.com/5107.html).
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.
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.
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.
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 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 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.
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:
The internal data areas used by the browser are represented by an inverted 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.
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.”
The next figure illustrates the runtime relationship of a Rich UI application—that is, a Rich Internet Application written with EGL—and multiple servers.
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.
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.
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.
An EGL Rich UI application is likely to be the front end of a complex runtime environment.
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.