Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Web Development

AJAX Makes Your Applications Sizzle on WebSphere Application Server Community Edition


If developing rich Internet applications based on AJAX (asynchronous JavaScript and XML) is high on your to-do list, IBM can help you get started. IBM supports AJAX development with a lightweight middleware software stack that is based on Apache Geronimo. In this article, IBM guides you through the process of developing and installing a small footprint customer relationship management (CRM) sample application for a small department or a satellite office that can easily scale to enterprise-wide deployment.

Resources

  • Download the Sample Application for This Article


  • Download WebSphere Application Server Community Edition


  • Tutorial: Using AJAX with PHP and Sajax


  • Tutorial: The AJAX Transport Method


  • Tutorial: Build Apps Using AJAX


  • Tutorial: Using AJAX with WebSphere Commerce


  • You will learn how to create a CRM application that demonstrates how a branch office can use AJAX and IBM's WebSphere Application Server Community Edition software to facilitate business communications with its partners and suppliers, as well as a corporate office. You will also learn how to set up databases and communicate with a Web services back end. Afterwards, you will be able to reuse much of this sample code and leverage the knowledge gained to kick-start your own development of rich, scalable Web applications based on AJAX and WebSphere Application Server Community Edition open source technologies.

    Advantages of Using AJAX
    Traditional page-based, Web applications provide limited client side functionality, because most page updates require frequent communication between the browser and the server to process and complete the updates. Furthermore, most requests are made synchronously, causing page refresh delays on even the fastest networks.

    AJAX is based on open standards and is supported by many browsers and platforms. More importantly, when pages need to be updated, AJAX enables browsers to asynchronously request incremental pieces of information from the server instead of whole pages. This eliminates the page refresh problems and slow response times that currently afflict Web applications. AJAX is also browser independent and fully compatible with standard Web servers and most server languages.

    Large organizations with remote, geographically dispersed, satellite offices often host a range of applications, which may be loosely or tightly coupled to corporate headquarters, suppliers, partners, and customers. Some require real time transactions with the corporate database, while others support disconnected operations through a backbone messaging provider. Although reliability and scalability continue to be key requirements for most mission-critical applications, organizations also require agility and flexibility to maintain a competitive advantage and support changing market conditions. AJAX has emerged as one of the key technologies that can help organizations meet their objectives because AJAX enables organizations to quickly create Web applications capable of providing better user experiences with faster overall performance.

    Steps to Create a Simple CRM Application
    The following application scenario demonstrates an AJAX-driven CRM application running in an auto repair shop, which serves its local customer base and communicates with servers belonging to its partners in two or more satellite offices.

    You can adapt the same application and technology for use with other similar configurations involving corporate headquarters with branch offices. Download all of the source and binary code, and other artifacts, discussed in this article.

    The CRM application you will create from the content in this article is based on the following descriptions and use case scenario:

      Figure 1. Physical Topology
    • Auto Repair Shop Business runs a browser-based desktop system and WebSphere Application Server CE-hosted CRM application that its employees use to access customer information and create customer service orders. Employees are able to accesses other remote servers at partner sites that are running databases containing automobile repair parts and the latest marketing promotions being offered by automobile marketing partners
    • Auto Parts Supplier Remote office maintains a parts list / order inventory database that auto repair shops can access when they need to order parts
    • Regional Auto Marketing Broker Remote Office maintains a server with various marketing promotional offers from automobile manufacturers
    • Use Case Scenario: A customer drives his car to an auto repair shop for service. The customer service representative (CSR) accesses the customers information stored in the CRM application from his desktop system to complete the service order. The CSR gives the car to one of the mechanics who diagnoses the problem and determines that a necessary part needs to be ordered to complete the repair. The mechanic or parts manager logs onto the parts suppliers database system to search for the applicable automobile part number. After identifying the right part number, the parts manager places an order for the broken part and updates the customers records with the information that the part has been ordered. Meanwhile, the CSR searches for and discovers that there is a marketing promotion from one of the Regional Auto Marketing Brokers (a marketing partner of the auto repair shop) for a $20 rebate on an oil change if the customer purchases a tune-up. The CSR presents the offer to the customer.

    Physical Topology
    Figure 1 graphically illustrates the topography of the different servers and applications in this CRM application scenario and illustrates how they communicate and interact with one another. This includes:
    1. Auto repair shop desktop running a compatible browser (Microsoft Internet Explorer, Mozilla, or FireFox) used by the mechanics and parts department personnel to access the CRM applications and databases.
    2. Auto repair shop WebSphere Application Server Community Edition server hosting the CRM application with customer database that is accessed by the desktop system browser
    3. Auto parts supplier server residing at the suppliers remote office site hosting another WebSphere Application Server Community Edition containing the available parts database application to process orders for parts. Note: there can be several different supplier systems and each one has its own Web service interface.
    4. Marketing broker serverresides at regional marketing broker site containing a WebSphere Application Server Community Edition server with Web service interface to a database containing various special offers that auto shop employees can give their customers.

    Figure 2. Application Layers

    The following modules correspond to the Eclipse Foundation projects containing the source code and application context root name for the three different applications used to create the Auto Shop CRM Application scenario:

    • demoshop auto repair shop
    • demoshop-sup auto parts supplier
    • demoshop-rmb regional marketing broker

    These demoshop Eclipse projects contain EAR files that you can run (i.e., demoshopEAR, demoshop-supEAR, and demoshop-rmbEAR respectively.)

    Each of these servers is an IBM WebSphere Application Server Community Edition Java Platform 2 Enterprise Edition application. All applications can be deployed on the same or different physical machines. Each application accesses its own database, which can be either Apache Derby or MySQL application layers

    How Different Application Layers Mapped to their Components
    Figure 2 illustrates the following different application layers and their associated components used in creating this auto repair shop CRM application. Table 1 maps the application layers to each of the different components.
    Figure 3. Repair System Database
    1. Client user interface layer is HTML code that is generated by the server's Java ServerPages (JSP) engine. It is built using Java ServerFaces (JSF) tag libraries. JavaScript code is generated by JSF code and the server AJAX layer.
    2. Server AJAX layer is a servlet handling requests from the client Window Manager
    3. Server UI LayerJSF consists of JSPs with JSP tags, JSF tags, and backing beans
    4. Business logic layer is implemented as Spring beans
    5. Database Access layer is implemented as Spring beans
    6. Web Service access is implemented as Spring beans
    7. Supplier and marketing broker Web services that are implemented as Java Web services accessed through the Axis engine which is part of the WebSphere Application Server Community Edition platform
    8. Supplier and marketing business logic layersimilar to repair shop applicationsee item 4
    9. Data Access layersimilar to repair shop applicationsee item 5

    Database Design of the Auto Repair Shop System
    The SQL scripts for the creation and population of the database are available as a part of this scenarios source code and can be found under the WebContent/WEB-INF/sql directories in the demoshop, demoshop-sup, and demoshop-rmb Eclipse projects.

    Figure 4. Supplier System Database

    The database model used for the Auto Repair Shop CRM application can be found in Figure 3. In the auto repair shop CRM application, every user of the CRM system has an entry in the SYSTEM_USR table containing pertinent information and credentials. Each person is also assigned to a particular group (USER_GROUP table) and authorized to perform certain functions (SYSTEM_FUNCTION and GRP_FUNC_INTS tables).

    Although all users have the same group and functionality, this model allows different groups to have different functionality. The SYSTEM_FUNCTION table controls what level of functionality is ascribed to each user (FUNC_MENU_ITEM column).

    Each user who logs into the CRM application is assigned to a shop via the USR_SHOP_INTS table. The database schema was designed so that the SYSTEM_USR table can be reused in other scenarios unrelated to automobile service. You will note that this table does not contain industry-specific columns, allowing it to be used for any industry application such as insurance, health care, etc.

    Each user has a set of preferences contained in the WINDOW_PREFS table that contain details of the state of the window while the user is working with the system. This table is updated by a Window Manager Component when the user opens, moves, or resizes windows on screen.

    Figure 5. Regional Marketing Broker Database

    Auto Shop Customer Information Database Description
    • When a user creates a service record, it is stored in the SERVICE, SERVICE_OPERATION, and PART_ORDER tables. These tables are updated every time a service record is saved.
    • If a user adds a new service operation to the service record the information is placed into the COMMON_SRV_OPR
    • Details about customers and cars are stored in the CUSTOMER and CAR tables
    • The automobile taxonomy is represented by the MODEL, PART_SYSTEM, PART_SUBSYSTEM, and PART tables. These are used whenever a part order needs to be created.

    Download WebSphere Application Server Community Edition
    Add to the functionality of Tomcat with pre-integrated features and services such as clustering, Web services, a security framework, and messaging. WebSphere Application Server Community Edition is a free, lightweight J2EE application server built on Apache Geronimo technology. Download now!

    Parts Supplier Database Description
    The Supplier System database is a simple database containing tables for the supplier information that is required by the auto repair shop such as ordering new parts, finding part numbers, etc. The database model for the Supplier system can be found in Figure 4.

    Regional Marketing Broker Database Description
    The database model for Regional Marketing Broker system contains tables for the available marketing offers that are accessed by the repair shop personnel such as the "get $10 off" coupons, etc. The regional marketing broker database can be found in Figure 5.

    Figure 6. Customer Search Class Diagram

    How it Works
    The application is implemented using a typical customer search scenario. Relations between classes are shown in Figure 6. This is where the key components and their descriptions are listed. Use this table to follow the various interactions and gain an in depth understanding of how each component implements the various tasks in the use case scenario as well as how the rest of the application functions. The table includes the following tasks:
    • Present a form to the user and process the users form submission
    • Transfer form input parameters to the applications business logic
    • Access various backend datasources (local RDBMS or remote Web services)
    • Return results
    • Format results for the user

    Component

    Details

    customer_search.jsp details

    • Located in Figure 7
    • Line 25 is a custom tag required for the window system. It is backed by JSF component, com.ibm.jswm.jsf.WindowsManagerComp, which interacts with the global WorkspaceManager JavaScript object handling window operations, like opening new windows, storing window positions etc. It also supports drag and drop.
    • This JSP refers to customerSearchBean in several places. Specifically, command action is associated with 'customerSearchBean.doSearch' method, which is defined in 'demoshop/WebContent/WEB_INF/faces-config.xml' (see Figure 8)
    • This definition shows that CustomerSearchBean has a property 'customerManager' that points to a Spring bean definition (although JSF EL syntax is used). In order to point to Spring beans from a JSF configuration file, there's a special variable resolver defined in faces-config.xml (see Figure 9)

    CustomerSearchBean details

    • The full class name is 'com.ibm.democrm.viewbeans.cust.CustomerSearchBean'. It's part of 'demoshop' project.
    • This bean has a CustomerManager property with type 'com.ibm.democrm.managers.CustomerManager'. This is an interface and its implementation is specified in 'WebContent/WEB-INF/springAppContext.xml'. See next section for details.
    • When a form is submitted, 'doSearch()' is invoked. Source code is shown in Figure 10.
    • After invoking customerManager (line 100), CustomerSelection or CustomerSearchResults objects are created. This is done because in case only one entry found. We then show customer details immediately. Then EventManager.fireEvent is invoked.
    • EventManager is the object intended to dispatch events to registered listeners. Event can be any object and listeners are registered in faces-config.xml in the EventManager bean definitionsee Figure 11.
    • If you look at customerSearchResult bean implementation ('com.ibm.democrm.viewbeans.cust.CustomerSearchResultsBean') and customerDetailsBean bean implementation ('com.ibm.democrm.viewbeans.cust.CustomerDetailsBean')you will find handleEvent methods with parameter corresponding to event type (CustomerSearchResults and CustomerSelection). When 'EventManager.fireEvent' is called, it will call a corresponding listener's method.
    • The handleEvent method (part of CustomerDetailsBean) is shown in Figure 12:
    • This code instructs the WindowsManager to open a new window on screen. WindowsManager will store DirectiveOpenWindow and, as part of processing tag, the WindowsManager JSF component (com.ibm.jswm.jsf.WindowsManagerComp) will take all directives and add generated JavaScript to open corresponding windows on screen. That is why we need tag included in the JSP.

    CustomerManager bean details

    • CustomerManager is defined in 'WebContent/WEB-INF/springAppContext.xml' (Figure 13).
    • It contains a 'parent' property pointing to a 'transactionProxyFactory' bean. All managers have this parent defining common transaction properties and are defined in 'WebContent/WEB-INF/springDAOContext.xml' (see Figure 14).
    • The 'dataSource' property (line 33) refers to 'db.dataSource'. External properties are stored in 'config.properties' ('WebContent/WEB-INF/config.properties'), which contains all changeable properties (e.g. this demo can use derby or mySql database). Switching is performed by editing 'db.dataSource' property in config.xml.
    • CustomerManager has a property 'customerDao' of interface type 'com.ibm.democrm.dao.customer.CustomerDAO'. This is wired to 'customerDao' and its definition can be found in 'springAppContext.xml'.

    CustomerDao bean details

    • CustomerDao is also configured in 'WebContent/WEB-INF/springAppContext.xml' file (Figure 15)
    • The 'parent' property (line 15) refers to 'jdbcDao' bean, which is defined in 'springDaoContext.xml' (see Figure 16):
    • Spring JDBC is used for our persistence layer. The jdbcDao bean defines 'jdbcTemplate', which is initialized by an instance of 'org.springframework.jdbc.core.JdbcTemplate'. All our DAOs extend 'org.springframework.jdbc.core.support.JdbcDaoSupport' class provided as part of Spring framework.

    A Leg Up to Help You Get Started
    This auto repair shop CRM application shows you the benefits derived from working with AJAX and IBM WebSphere Application Server Community Edition, as well as several other open technologies including JSF and Spring. Now that you understand how easy it is to use these technologies, you should have no problem leveraging this knowledge and code to create similar AJAX-based applications for your own business requirements.


    Rikki Kirzner is a freelance writer and veteran computer industry professional with experience as an analyst and former Research Director for IDC, Gartner Group, and Meta Group and as a Senior Editor with Open Computing Magazine. Rikki covers software, development, open source, SOA, and mobile computing.




    Related Reading


    More Insights






    Currently we allow the following HTML tags in comments:

    Single tags

    These tags can be used alone and don't need an ending tag.

    <br> Defines a single line break

    <hr> Defines a horizontal line

    Matching tags

    These require an ending tag - e.g. <i>italic text</i>

    <a> Defines an anchor

    <b> Defines bold text

    <big> Defines big text

    <blockquote> Defines a long quotation

    <caption> Defines a table caption

    <cite> Defines a citation

    <code> Defines computer code text

    <em> Defines emphasized text

    <fieldset> Defines a border around elements in a form

    <h1> This is heading 1

    <h2> This is heading 2

    <h3> This is heading 3

    <h4> This is heading 4

    <h5> This is heading 5

    <h6> This is heading 6

    <i> Defines italic text

    <p> Defines a paragraph

    <pre> Defines preformatted text

    <q> Defines a short quotation

    <samp> Defines sample computer code text

    <small> Defines small text

    <span> Defines a section in a document

    <s> Defines strikethrough text

    <strike> Defines strikethrough text

    <strong> Defines strong text

    <sub> Defines subscripted text

    <sup> Defines superscripted text

    <u> Defines underlined text

    Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

     
    Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.