Tim Jones’ anticipated pleasure with his new CD was quickly dampened. While ordering it online, he sat in front of his computer and waited for several minutes as he entered his address, delivery, and billing information page by page into his browser – yet again.
Countless Internet users have had a similar experience. But users don’t have to accept endless waits. They can be avoided with the help of rich Internet applications (RIAs), which are application dialogs triggered by the Web server. They run in a Web browser within a simple HTML Web page. The basic idea behind RIAs is for the browser to completely control application process event-handling. The server back end merely supplies data. Web services can generate the interface between the back and front ends, which means a Web service offers or stores application data in the back-end system. In the meantime, the RIA continues to run on the front end. The application displays the transmitted data, requests new information from the back-end servers, or transmits new data to the back-end system, which then stores it. As long as the RIA is running, no new layout information must be reloaded from the back-end system.
For example, in a purchasing system based upon RIAs, dragging the picture of a product onto the shopping cart icon triggers an event within the RIA. The shopping cart icon in the RIA applet records the new product internally in its list. The user’s action does not yet require any connection between the Web browser and the Web server. But as soon as the user drags the shopping cart to the checkout object, setting up a connection to a server-side payment service is absolutely required to store the shopping cart on the server and reload the user’s payment information for the next dialog page. Communication occurs only when data must be loaded or stored to perform a transaction. Meanwhile, the client regulates display and event-handling independently of the Web server.
The technology behind RIAs
Unlike a traditional HTML page, a RIA is not limited to running in a Web browser on the Internet or on an intranet. For example, a dialog template created with Microsoft Excel or Access can access the Web services of an SAP Web Application Server (SAP Web AS) application and use the same data sources as a RIA Web application with Flash or Java. Office applications, Web pages, UMTS pages, WAP pages, Java applets, and Flash applications are simply differing displays of the same data.
A Web site is only one special type of possible RIA dialog. The ability to select front-end applications offers several practical advantages. For example, data sourced from a Web service can be displayed as a chart in Microsoft Excel or as a graphical chart in an HTML page with the help of an embedded Flash element. In either case, users work with the interface that best meets their needs. Web services guarantee that the application uses the same data sources and displays identical values.
No more central HMTL server
Another important aspect of RIA architecture is that the application interface no longer needs to run on a central Web server; it can simultaneously access data from various systems. The data can then be displayed on a common interface. For example, data from the product catalog of an SQL database and master data from the SAP material master can be linked into the user interface without either server knowing about the other. Access to data in the application interface appears as a homogenous unit to the user. Realization of this feature simply requires access to the system over Web services. Interface tools, such as Java, Flash, or .NET, are controlled by a comprehensive authorization system that calls the data sources. The RIA interface therefore acts as a uniform display portal for the user’s information.
Realization of a RIA with SAP Web AS
A RIA consists of two components. First, the data must be available on SAP Web Application Server (SAP Web AS) as Web services, which can be accomplished with function modules. Second, the Web application itself is realized as an independent RIA applet that can contact the server when needed. Users can create an RIA applet with Java, Flash, Microsoft .NET, ActiveX, or a Microsoft Office application. All the function modules of an SAP system can be transformed into remote-enabled function modules by selecting the appropriate option. The existing business functionality of SAP solutions can also be made available to RIAs with a simple mouse click.
Symbiosis between RIAs and Business Server Pages
The use of RIAs does not exclude the use of HTML – quite the contrary. Because every RIA applet is embedded in an HTML page with just a few lines of code, RIA applications can be mixed with Business Server Page (BSP) tags at any time. Users can choose to embed more functionality into an HTML page, a BSP, or a RIA applet. The functions of SAP BSPs are best suited for static displays, such as reports, lists, or tables. BSPs usually need only a couple lines of code to display information. RIAs offer advantages with interactive catalogs, dynamic charts, product images, or product configurators – especially because of better graphical development tools, the display components available, the dynamism of the pages, and integrated event-handling.
The back-end system goes open source
Basically, every product that gets its information from a Web service data source represents a RIA interface. More and more manufacturers, such as SAP, Oracle, or IBM use the standards offered by the W3C Consortium in back-end systems; J2EE, JRun, Tomcat, or Apache servers are typically the foundation of combined products. With SAP Web AS 6.30, SAP offers a J2EE engine as an installation option. That means that SAP customers can use familiar SAP tools or manufacturer-independent Java standards to create their applications.
From their front-end systems, users can now access the compatible Web services of an IBM, SAP, or other Web server. This development represents a giant step toward uniform user interfaces and portals.