1.3. Use Cases

1.3.1. Major Widgets Use Case

1.3.1.1. Major Widgets Introduction

Major Widgets Overview

Major Widgets is a single-store auto-parts company that recently decided to purchase three more auto part supply stores and are currently needing to integrate the systems located in all four stores.

Major Widgets Business Model

Major Widgets, and each of the three stores it bought, routinely supply a number of auto repair shops that are located near them. Each store delivers parts to customers free-of-charge, as long as the customer is located within twenty-five miles of the store. Each store has its own database for storing auto repair customer accounts, store inventory, and part suppliers.

Business was done over the phone, but now Major Widgets wants to implement an online order service to enable their auto repair customers to order parts more quickly and efficiently. The Web-based service will coordinate orders and deliveries, bill customers, track and update each store's inventory, and order parts from suppliers. Customers can use it to check the status of their orders.

All four stores also sell parts over-the-counter to walk-in customers, for whom they do not typically establish customer accounts. Each of the in-store ordering systems will also tie into its store's central order processing system.

1.3.1.2. Major Widgets Integration Plan

Figure 1.1, “Major Widgets Integration Plan” shows a high-level view of how Red Hat JBoss Fuse will provide an integration solution to implement Major Widgets' new business model.

Figure 1.1. Major Widgets Integration Plan

This plan creates:

a single order entry point into the order processing system that can be accessed via the Web and by the in-store terminals
an intelligent order entry system that routes Web-based orders to the store closest to the delivery destination
an order processing system (instances running locally at each store) that receives and processes orders, maintains customer accounts, and tracks and maintains inventory
a master/slave broker cluster that provides a highly available, reliable messaging backbone for the integration solution

This plan allows each store to retain their existing internal systems, but enables them to function as a single unit.

1.3.1.3. Major Widgets Implementation

Figure 1.2, “Major Widgets Implementation Diagram” shows how a Major Widgets integration plan might be implemented.

Figure 1.2. Major Widgets Implementation Diagram

Major Widgets Components

The Red Hat JBoss Fuse kernel provides a runtime environment that provides enterprise support (management, logging, provisioning, security) for the main store (Store A), where most of the integration applications run. Its embedded services provide the frameworks for implementing these components of the solution:

RESTful service—for creating a JAX-RS application that runs on each auto repair shop terminal (1), enabling customers to input part orders, via an order entry form, over the internet.
Web service—for creating a JAX-WS front end to implement the order entry functionality on each of the in-store terminals, which receive orders from walk-in customers (2) who purchase parts over-the-counter.
camel-cxf component—a routing and integration service component that creates an entry endpoint (3) that exposes Major Widgets routing logic to the outside world as a web service or a RESTful service.
Routing and integration service—for creating routes (4, 6) that direct orders received from the web/RESTful service entry point through the appropriate store's order processing back end.
Messaging service—for creating a persistent, fault-tolerant clustered messaging system (5, 5a), which ensures that no order is ever lost due to failure of the system, the message broker, or the connections between the message broker and its various clients—the front end content-based router (4) and the back end dynamic router (6).

Major Widgets Integration Flow

At Major Widgets main store (Store A), the order entry front end (routing and messaging agents running inside Red Hat JBoss Fuse) is running on that store's main computer system. At each of the four stores (Stores A-D), an instance of the order entry back end (routing agent and back end processing running in JBoss Fuse) is running on the local computer system.

When the front end web service (3) receives an online order, the routing agent passes it to a content-based router (4) to determine which store to route the part order for further processing. Normally, the order then enters the target store's queue (5), where it waits until the target store retrieves it (6). (With fault tolerance built into the system, if the master broker (5) fails, the system can continue to function with no loss of orders.)

In the case of auto repair shops (1), the content-based router routes order requests to the store nearest the customer, based on the submitted zip code. In the case of walk-in customers (2), the auto supply store submits its own zip code to the front end, so the order is always routed to the local store.

When the back end receives the submitted part order, the application employs a dynamic router (6) to look up the parts in the store's database to see if they are in stock. Results depend on whether the customer is an auto repair shop or a walk-in:

Auto repair show customers
If the parts are available, the order is submitted to the store's back end processing software (8), which informs and bills the customer (1), schedules delivery, updates inventory, and reorders parts accordingly.
If the parts are unavailable, the order is submitted to a processor that generates an error message, which is emailed (9) to the customer (1).
Walk-in customers
If the parts are available, the order is submitted to the store's back end processing software (8), which informs the store clerk (2), updates inventory, and orders parts accordingly. The store clerk retrieves the parts from stock and sells them to the customer over-the-counter.
If the parts are unavailable, the order is submitted to a processor that generates an error message, which is emailed (9) to the local store's email account (2). The store clerk informs the customer, who can then decide whether he wants the store clerk to search the other stores for his parts.

1.3.2. Loans Consolidated Use Case

1.3.2.1. Loans Consolidated Introduction

Loans Consolidated Overview

Loans Consolidated is a new company that focuses on consolidating other vendors' home and customer information and compare this with local schools to allow customers and vendors to view a variety of homes and compare them.

Loans Consolidated Business Model

Loans Consolidated will take in customer data and home information from several home loan vendors; these vendors will regularly provide information concerning new homes and customers along with updated information for existing entries.

Customers will be able to view a home's appraisal online, and this appraisal will be calculated by Loans Consolidated based on the home's information along with the number of surrounding schools.

The home loans vendors have requested that a service be provided that returns all of the data with the updated appraisal value back to them.

1.3.2.2. Loans Consolidated Integration Plan

A high-level plan utilizing Red Hat JBoss Fuse will provide an integration solution to implement Loans Consolidated's new business model; this solution creates:

a single entry point into the order processing system where files are deposited either via a FTP server or a batch job overnight.
an intelligent system that routes the XML files and, for house files, appraises the value of the house before sending it to a messaging broker.
a system that retrieves information from the surrounding area to provide a better appraisal.
the ability to provide the results of the appraisal back to the vendors.

1.3.2.3. Loans Consolidated Implementation

Figure 1.3, “Loans Consolidated Implementation Diagram” shows how a Loans Consolidated plan might be implemented.

Figure 1.3. Loans Consolidated Implementation Diagram

Loans Consolidated Components

The Red Hat JBoss Fuse kernel provides a runtime environment that provides enterprise support (management, logging, provisioning, security), and its embedded services provide the framework for implementing these components:

Routing and integration service-for creating routes that dynamically examine the contents of the deposited XML files to determine the appropriate destination.
Integration with the Google App Engine to pull the number of surrounding schools that will be used to update each home's appraised value.
RESTful service-for providing all of the data with the updated appraisal back to the vendors.

Loans Consolidated Integration Flow

Multiple vendors will be placing their XML files (1) into a directory either via a FTP server or a batch process overnight. These files will be read into a content-based router (2) which will separate the files based on if they contain Customer or House information.

Once separated the files containing Customer information will be placed into an in-memory queue (3) before being passed into a backend database for persistence (6).

The files containing House information will be placed into a separate queue (4) before having their value estimated (5). As part of this calculation the location is provided to the Google App Engine (7) which will look up nearby schools to determine an appraised value. The appraised value is then stored in the backend database (6).

A RESTful Web Service (8) is used to relay the information from the database in a JSon format, so vendors may easily query it.