Installation Guide
|
 |
 |
|
 |
 |
This is a brief overview of the Avitek Sample Retail Application (RTLApp) that is included with a complete BEA AquaLogic Data Services Platform (DSP) installation. This chapter describes the data sources and other application components used to develop the RTLApp.
Avitek is an imaginary retailer that has grown through acquisitions. The company started out selling apparel but recently merged with an electronic retailer to expand business and consolidate cost centers such as accounting and web development. Because of this acquisition the company now has two very different order management systems (OMS), one each for electronics and apparel orders. Avitek also has a customer relationship management (CRM) system to manage customer profile information. Finally, Avitek has a Customer Service system to manage the support cases for Electronic products.
General immediate and mid-range goals for the newly consolidated IT department include:
An early "low-hanging fruit" project is to build a customer self-service web site which can also be used by support representatives. This web site needs to provide an easy solution to integrating different back-end resources and to providing two-way communication (read/update). It will also need to provide an abstraction layer to hide the complexities in the different systems.
The front-end architecture of the web site will provide a Java-based Customer Self-Service portal where customers can update their profile information and review or modify their orders. The back-end architecture will access the following five different sources of data (as shown in Figure 6-1):
The project also needs a code name. RTLApp is selected.
Figure 6-1 RTLApp Front and Back End Architecture
Make sure that both the RTLApp development environment and Web application are available. To start the RTLApp in the IDE, follow the instructions outline in Verifying the Installation, including starting your BEA WebLogic Server.
The steps involved in running RTLApp from inside WebLogic Workshop are similar to starting the IDE. (If you have already build and deployed RTLApp in Workshop you can skip to step 4.)
Start—> All Programs—> BEA WebLogic Platform 8.1—> BEA AquaLogic Data Services Platform 2.1—> Examples—> RTL Demo—> Launch RTL Demo Sample Server
Note: You can go on to Step 2 while starting the sample domain server.
RTLApp.work file located in the following directory:<WL_HOME>/samples/liquiddata/RTLApp/RTLApp.work
Right-click on RTLApp (top node in the Application pane), and choose Build Application from the context-sensitive menu. WebLogic Workshop displays the status of the build. Confirm that the build was successful, as indicated by the build status messages.
demoPageFlowController.jpf. It is located in the following folder:RTLSelfService\Pages
Debug—> Start
Log in using one of the names shown in the dialog box. Simply move your mouse over the login name of your choice to automatically fill-in the name and password (Figure 6-2).
The sample retail application illustrates in simplified form the kinds of data integration challenges often encountered by Information Technology (IT) managers and staff. Issues include:
Other questions may occur. Is the data-rich solution scalable? Is it reusable throughout the enterprise? Are the original data sources transparent to the application — or do they become an issue each time you want to make a minor adjustment? When changes to underlying data inevitably occur, how difficult will it be to propagate those changes to the application layer?
A survey commissioned by Avitek Marketing found customers to be dissatisfied with the call-in wait time required to track orders or update customer information. In a focus group the idea of a self-service web site resonated. Customer Service agreed; they have been requesting such a site for years, but the internal costs were always above budget. But now that Marketing is on board ...
Site requirements seem simple. Fulfillment identifies that customers will need to be able to:
Bottom line: If customers can perform this level of self-service the company will save a lot of money.
A cross-sectional team of marketing and customer service develop maintenance requirements for the web application:
An application/UI designer begins "specing out" the required JSPs. Pages are the easy part. Data is needed so he shoots off an email to the consolidated IT department.
When an IT data architect analyzes the requirements she turns up a problem. In surveying the information needed by the application -- customer data for one data source, order data from two very separate divisions of the company (two more data sources), and customer support data (a fourth data source) — the architect realizes that integrating data from these diverse data sources will be complicated and time consuming with additional maintenance problems down the road. Challenges included:
Perhaps most frustrating: little of the specialized code needed by the application can be reused.
So much for low-hanging fruit.
Developing a unified view into distributed data is one of the most persistent challenges faced by IT departments. Just when you get all the available data sources normalized, new sources appear that must be dealt with, but which also make yesterday's data integration solution obsolete.
This problem is so pervasive that each year thousands of arguably critically-needed applications go unwritten, are delayed, or are delivered in highly-compromised form because of the data integration challenges faced by even the most sophisticated enterprises.
Compared to the above, the RTLApp team preferred a solution that:
When Avitek looked at Data Services Platform, they found a product that addressed the underlying challenges posed by the apparently simple RTLApp:
Specifically, the features that the team found most appealing included:
Data Access. DSP allows the application to access information from anywhere in the company — or beyond — through an easily-created virtual data access layer. Once accessed, data can easily be aggregated through a combination of reusable queries and views that are maintained in the DSP server.
Query Development. Then, once the data is collected under a single point of access, it is not difficult to create query functions that consolidate data from these disparate sources and present a common, reusable view ready for more specialized queries.
The declarative form of DSP artifacts (query functions in data services) makes them very readable.
Query Deployment. Once developed, queries are easily integrated into a client application thorough a variety of access methods such as the DSP Mediator API, a data service control, JDBC, or SQL.
Integration. Business logic for the RTLApp is provided by the NetUI and page flow features of Workshop. However, DSP query functions could have as easily been integrated and maintained within the business logic of any J2EE application.
The RTLApp is designed to illustrate how DSP-generated queries can aggregate data from potentially highly disparate data sources, allowing access to that data through a single point of access that itself is easily integrated with the application.
Note: To simplify the running of the RTLApp, the multiple data sources described in this document are simulated using the PointBase RDBMS which is shipped with DSP. In the original implementation, these databases were represented by major vendor RDBMS systems.
The RTLApp is located in the following directory:
<WL_HOME>/samples/domains/liquiddata/RTLApp
RTLApp controls, pages, processes, and resources used to create the SampleApp can be found at:
<WL_HOME>/samples/domains/liquiddata/RTLSelfService
Some of the schemas used in the RTLApp are in the following directory:
<WL_HOME>/samples/domains/liquiddata/schemas
Others are located in their respective data service.
The Workshop .work file for the SampleApp is located at:
<WL_HOME>/samples/domains/liquiddata/RTLApp/RTLApp.work
When you install DSP with the WebLogic Platform, the source code for the RTLApp can be accessed from Workshop. For instructions, see Viewing RTLApp Source.
For additional information and references, see:
Several BEA technologies are exercised by the RTLApp.
Although the RTLApp is very simple, the underlying data acquisition is challenging because date comes from four heterogeneous data sources. These are:
The following section describes work done by some of the RTLApp data services.
There physical data services correspond with the physical data sources needed by the application.
In RTLApp physical data services typically have a read function and, often, one or several navigation functions that correlate to the primary key/foreign key relationship between relational sources.
Logical data services (services based on physical data services or other logical data services) are located in a folder called RTLServices. It is in these logical data services that read and navigation functions drawing on multiple data sources are developed and maintained.
Table 6-1 shows the relationship between the data sources, major data elements (for RDBMS systems: tables and columns), sample application JSPs, and the RTLApp web pages.
RTLApp Primary Pages and Their Data Sources, Primary Data Elements, and Associated JSPs
If you have not already done so, use Quick Start Instructions for the Avitek Sample Application (RTLApp) to start Retail Sample Application. You can choose from users Steve, Jack, Tim, Homer, or Jerry. Each uses the password weblogic.
Once a customer logs in, she or he sees their MyProfile screen. From there he or she can navigate to information on open orders, order history, support, search, and logout. Customers can edit open orders (see Figure 6-4) and get details on completed orders. Search allows the user to supply product description information, start or end date, or order amount brackets.
The application also demonstrates some DSP facilities including the ability to:
The My Profile page illustrates DSP's ability to perform automatic read/write on distributed data.
My Profile page consolidates Customer and Credit Card information. Users can change their personal profile information, address information, and credit card information. Changes are initially reflected on their MyProfile page. If satisfied, the user can click Submit All Changes to persist changes to the respective data sources.
The page is based on ProfileView.jsp and the ProfileView data service (ProfileView.ds).
The RTLApp Open Order page consolidates a customer's electronics and apparel open orders.
Figure 6-4 RTLApp Open Order Page
From the user's perspective, changing data is simply a matter of select and type. However, the underlying update mechanisms for electronic orders (which are maintained as a web service) and apparel orders are quite different.
Electronic orders are derived from a web service. In this case, updating a electronic order demonstrates web service custom update capabilities.
Apparel orders are derived from a relational database and updates are automatic.
The Enable Cache option turns on caching for the function underlying the Open Orders page. You can use the Refresh button to verify that the execution time when cache is enabled is significantly faster than when it is not.
Click the Make Electronics Source Unavailable button to disable the web service. This action also refreshes your Open Orders page. Notice that you can still retrieve partial results (apparel orders) when a data source becomes unavailable.
The Show SQL Report button illustrates accessing data through JDBC. This demonstrates the integration of DSP query functions with reporting and business intelligence tools such as Crystal Reports.
The Open Order page is controlled by a JSP named defaultView.jsp. Call-outs in Figure 6-4 show underlying data sources. The page derives its font and other look-and-feel characteristics from a cascading stylesheet.
The RTLApp Order History page displays historical order information for electronic and apparel orders.
Figure 6-5 RTLApp Order History Page
Users have several options associated with viewing their previous orders:
An Apply button is provided to control page refresh.
DSP security can be demonstrated when the number of orders is set to All. Then when the Restrict Access option is selected, data is automatically redacted to show only orders where order amounts are less than $500.00.
The Order History page is controlled by a orderHistory.jsp.
The Support page provides information on any open support cases for the currently logged-in customer.
Figure 6-6 RTLApp Customer Support Page
The underlying JSP is CaseView.jsp.
Users can search for specific orders based on order dates, items, or amounts. The underlying code executes ad hoc DSP query functions.
Users can search on any combination of search field criteria including product description, start or end data, and a range of order amounts.
The JSP for this page initiates a small Java program that incorporates customer input and generates an XQuery based on the selected parameters.
The data services, functions, JSP pages, and connection logic for the RTLApp were created in Workshop. You can view the source for the RTLApp in Workshop as well.
To open the RTLApp application, open the RTLApp.work file in Workshop. The full path is:
<WL_HOME>/samples/domains/liquiddata/RTLApp/RTLApp.work
Note: If you are already running WebLogic Workshop or have previously run it with a different server setting, you may need to change your application server properties settings. If necessary, select the following from the WebLogic Workshop menu:
When opening the RTLApp in WebLogic Workshop, you initially see the application components and the work area.
Figure 6-8 Initial Retail Sample Application Initial Project View
WebLogic Workshop allows you to work with the application you have under development as components or files. Web pages can be displayed and run, page flows and application logic can be developed and tested.
Note: Getting Started with WebLogic Workshop fully describes the IDE and how it can be used to build enterprise applications. The on-line document includes numerous examples and tutorials.
<WL_HOME>/samples/workshop/SamplesApp/SamplesApp.work
Like all WebLogic Workshop applications, components of the RTLApp are arranged in folders. This section briefly describes some of these folders and their contents.
The Data Services folder contains both physical and logical data services.
Figure 6-9 Major Components of the RTLApp DataServices Folder
Physical data services, which are based on physical data sources, include apparel orders (ApparelDB), electronic orders (ElectronicsWS), credit card information (BillingDB), and customer service information (ServiceDB). Logical data services are all grouped in the RTLServices folder.
Model diagrams based on both physical and logical data services are contained in the MODELS folder. Of particular interest is the EnterpriseDataModel, which models all the physical data services in the application. Logical model diagrams include the RTLApp model, which summarizes the data service relationships that make up the RTLApp.
Note: The DataServices/Demo directory contains simple examples of delimited file data, XML file data, and Java functions being used as the basis for data services.
The ElecWS folder contains the web service that serves as the basis for the electronics orders data service used by RTLApp.
Many of the building blocks of the Retail Sample Application are available from the RTLSelfService folder.
Figure 6-10 Major Components of the RTLApp RTLSelfService Folder
The following components are of special interest:
RTLControl.jcx file. This is a file generated by the data service control that contains methods for each query function used in the DSP application. In Design View each function is listed. Clicking on a name switches you to Source View where you can see details about the function including:For additional information on the RTLControl see Controls.
demoPageFlowController.jpf, that make up the RTLApp web application.For additional information on the pages see Application Pages.
The RTLApp/Schemas folder contains schemas developed for logical data services and associated XML Bean classes.
The RTLControl.jcx contains automatically-generated methods based on a set of stored queries selected by the developer of the data service controls. For information on accessing DSP queries in WebLogic Workshop see the section "Select Data Service Functions to Add to a Control" in Accessing Data Services from Workshop Applications in the Application Developer's Guide.
Figure 6-11 Design View of RTLControl Design View
A portion of the Source View of the RTLOrderSummary method of the RTLControl JCX file is shown in Figure 6-12. Note that the name of the target schema for the query appears in comments.
Figure 6-12 Data Service Control Source View
Each method in the data service control corresponds to a query function. Each method returns an XMLBean type. The XMLBeans are generated when the control is created, and are stored in the Libraries directory of the WebLogic Workshop application.
In the RTLSelfService/Pages folder you can find the Java Server Pages (JSPs) that make up the RTLApp. These were constructed in WebLogic Workshop using queries RTLControl and NetUI graphical elements.
Figure 6-13 JSP Pages in the RTLApp
The RTLApp is composed of java server pages (JSPs) that are managed by a WebLogic Workshop PageFlowController. The PageFlowController is named demoPageFlowController.jpf.
From an application logic perspective, whenever a user releases control of a page by selecting an option such as Next, Previous, Ok, Cancel, and so forth, application logic returns to the PageFlowController. Once that logic is processed, the user sees the appropriate web page.
Using WebLogic Workshop you can inspect, change and extend page flow programmatically or graphically. There are three views of page flow: Flow View, Action View, and Source View.
The Workshop page flow schematic (Figure 6-14) illustrates graphically the relationship between JSPs, including has modeless page flow is determined by user actions.
When you click on a particular page name, the page opens in the WebLogic Workshop development browser.
Figure 6-14 Retail Sample Application Page Flow
The three primary elements found in Page Flow View are:
The Action View tab helps in finding the location of page flow actions associated with the RTLApp.
Figure 6-15 RTLApp Action View
Clicking on an action items opens demoPageFlowController to the relevant section of code.
The PageFlowController file contains several parts:
@jpf:forward calls within comments that associate user actions with appropriate target JSPs.
In summary, the RTLApp provides:
Here are some additional resources for learning more about Data Services Platform and WebLogic Workshop:
|
|
|