![]() |
Designing Synchronized Applications
|
|
Steps for Designing a Distributed SystemBefore creating the databases or writing code:
NOTE: If you can design your application so that no conflicts are possible, you may not need to perform steps 5, 6, and 7. If an update cannot cause a conflict, and if the only action you want to perform is updating the same data at target and source, you do not need to write a work unit for it.
Step 1: Defining the ApplicationThis chapter uses a very simple toy sales order scenario. There are two sales representatives, each at her own target, and two types of toys available. Each salesperson does a refresh to see how many of each toy are in stock, and to get the latest price information. The salesperson places an order for a single item, entering the name of the customer, the item she wants, and the quantity. Each salesperson has access to her own orders only. The salesperson can also send a lead to another salesperson. The central office keeps track of valid salespeople, and updates from unapproved salespeople are rejected. Please note that, for simplicity's sake, this application puts the source and target directories under the same directory on the same machine. A real deployed application would probably put the source database into a server framework. Step 2: Listing the OperationsThe two operations needed for this simple scenario are: You will write a work unit for each operation. The work unit code is shown in Work Unit Examples. Step 3: Describing the System-Wide DataThis application requires the following data about each toy: The application also needs the following data about each order: Since salespeople (and people at the central office) can send each other leads, the application uses the following data about each lead: The application needs access to a list of valid salespeople to determine whether a lead is deliverable and whether the salesperson sending an update is valid. For security purposes, it would be useful to refuse update permission to a salesperson who has been let go. Therefore, the application maintains the following information about each salesperson: The TOYS, ORDERS, LEADS, and SALESREPS tables will contain this data. They are created as follows:
CREATE TABLE toys (
CREATE TABLE orders (
CREATE TABLE leads (
CREATE TABLE salesReps ( NOTE: See Designing Universal Keys for an explanation of the BIT VARYING column used as a primary key in some of these tables. Step 4: Describing the Target DataEach target is restricted to one salesperson's orders and leads. Therefore, the publication uses parameters to restrict each target accordingly. The publication to create a target is:
CREATE PUBLICATION toySales (salesRepID INT) NOTE: The getKey method alias is shorthand for the universal key generator described in Designing Universal Keys. The getKey method alias and the two work alias definitions are shown in the section Work Unit Examples. Step 5: Listing the InputsThe parameters in the placeOrder work unit are:
The parameters to the sendLead work unit are:
Step 6: Listing the OutcomesThis application represents provisional (pre-successful-refresh) outcomes differently from durable (post-successful-refresh) ones. This gives the user a better sense of the actual status of her request. The possible outcomes of placing an order are: For simplicity, the application does not track the status of leads. Step 7: Representing the Outcomes in the DatabaseThe STATUS column of the ORDERS table represents the possible outcomes described in step 5. Since there are six possible statuses of an order, this column can have one of six values: Although in this example the values in the STATUS column represent the outcomes of only one work unit, status values typically represent the outcomes of more than one work unit. For example, if there were also a cancelOrder work unit, STATUS might also permit the values WILL CANCEL and CANCELED. Note also that there are many ways of representing status in a database. You do not necessarily need a STATUS column. You might instead have an EXPECTED_DELIVERY_DATE column that is assigned a later date if the product is backordered. Doing this would not overtly show the user whether an order is provisional or durable, but this may not be necessary in some applications. |
|
![]() Cloudscape Version 3.6 For information about Cloudscape technical support, go to: www.cloudscape.com/support/.Copyright © 1998, 1999, 2000 Informix Software, Inc. All rights reserved. |