Entertainment & Humor

Work flow view of a distributed application

Description
Work fow view of a distributed appication by j. R. HAMSTRA Sperry Univac Rosevie, Minnesota NTRODUCTON Work Fow Management is a unified set of concepts for the definition, impementation and operation of
Published
of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
Work fow view of a distributed appication by j. R. HAMSTRA Sperry Univac Rosevie, Minnesota NTRODUCTON Work Fow Management is a unified set of concepts for the definition, impementation and operation of Appication Systems. A companion paper to this one provides a more genera treatment of the requirements motivating Work Fow Management. An Appication System is a major function of the work of a computer system as perceived by the customer. Thus Appication Systems often mirror the structure or work of the customer enterprise. n this paper we sha consider a credit card processing appication, forming a major function of the work of the hypothetica Masterkey Credit Corporation (MCC). The portion of this appication performed on the MCC distributed computer system is caed the Credit-Cards Appication System. MCC aso uses its computer system for other appications, incuding personne and payro, financia information, and the deveopment and maintenance of appications. Peope reate to an Appication System in various roes, incuding end user, systems anayst, programmer and operator/administrator. Figure iustrates these reationships. Work Fow Management attempts to faciitate communication among these various parties incuding the Appication System, by supporting high-eve descriptions expressed in the Work Fow Definition Language. Within an Appication System certain kinds of work are performed repeatedy. This is caed recurring work, as opposed to ad hoc work performed once. Recurring work, the primary concern of Work Fow Management, may be parae (e.g. charge sips are processed concurrenty in each of 0 regiona data centers, and may indeed be processed concurrenty within a singe center) or cycic (e.g., customers are bied monthy based in part on their previous statements) or both. Recurring work is more easiy described by defining the underying structure of the work, than by expicity enumerating or generating the instances. n genera, a schema (pattern, diagram, schematic) provides a structured tempate of information for generating and controing instances of compex entities, A Work Fow Schema is the description of an Appication System expressed in the Work Fow Definition Language. t describes the structure of the recurring work of an Appication System, with provision for the dynamic introduction of modifications and ad hoc work. A Work Fow Schema is compied into an interna form interpreted by the run-time system. This produces, in effect, a customized appications executive providing a compete simuated environment, incuding faciities for production work, as we as appication modification, testing and training, and auditing and recovery. Thus the Work Fow Definition Language can be cassified as a simuation anguage, abeit a specia purpose one since the casses of simuated entities are predetermined (see Figure 2). n the remainder of this paper we wi deveop the basic Work Fow concepts and show how they are represented in the Work Fow Definition Language. Being an overview, this paper must omit some components, and the descriptions of those presented are necessariy simpified. Nevertheess, it is intended to give the reader some insight into the scope, stye and power of both Work Fow Management and the Work Fow Definition Language. WORK FLOW CONCEPTS Functiona distribution As previousy suggested, the work of the Credit-Cards Appication System proceeds simutaneousy in 0 regiona data centers. These centers are ogica processing environments perceived by Work Fow Management as Appications Environments caed Regiona-Data-Centers. The portion of the work of Credit-Cards performed within each Regiona Data Center is caed a Regiona-Operations Sub Appication System. Figure 4 iustrates these reationships, using the structure notation defined in Figure 3 and the symbos for Sub-Appication System and Sub-Appications Environment shown in Figure 2. Note that the reationship between Regiona Data-Center and Regiona Operations is transient, since the ogica work of one Regiona-Operations may be moved to a different actua Regiona-Data-Center if some untoward event, such as a food, renders the first Regiona-Data-Center unavaiabe. We have considered the first-eve decomposition of the Credit-Cards Appication System. At this eve, it comprises simiar functions (Regiona-Operations) distributed among simiar processing environments (Regiona-Data-Center) in a pre-determined yet aterabe manner. Work Fow Management encourages and supports the functiona decomposition of Appication Systems and the controed distribution of the 595 5% Nationa Computer Conference, 979 End Users» 0 ' T. Appication ::s ) c+ tt 0 Systems c+ ' ' tt ' ) c+ 0 . r-t ' tt one-t.o-one one-to-n permanent temporary permanent Figure 3-Schematic structure notation. (no), 'ot' tempora7 tions. These functions are provided by an nter-regiona Operations Sub-Appication System within each Regiona Operations. Figure 5 iustrates the structure of Regiona Operations. Athough further decomposition of Credit-Cards into Sub Appication Systems is possibe, it is not essentia to this presentation and wi not be pursued. Figure -User roes and reationships. functiona components. This contrasts with the emphasis on oad-sharing or data base distribution found in many other approaches to distributed processing, athough Work Fow Management does not precude either of these. ndeed, it requires certain forms of data distribution. MCC distributes its work by dividing the United States into 0 regions and keying both credit card and merchant identification to these regions. Considering the requirements of credit card processing within a Regiona-Operations Sub-Appication System, it is reasonabe to decompose them into functions associated with the cardhoders serviced by that region, caed Cardhoder-Operations, and functions associated with the merchants serviced by that region, caed Merchant-Operations. MCC derives revenue from both Cardhoder-Operations (membership fees and interest) and Merchant-Operations (service charges and discounts). Considering that each Regiona-Operations is a separate profit center, whie cardhoders may use their cards anywhere in the country (MCC has no direct internationa operations), we concude that management wi desire, and accountants and auditors require, separate contro of inter-regiona financia transac- D (Sub)Appication System (AS). D Task o Queuing Point (QP) D (Sub)Appication Fnvironment (AE) Figure 2-Schematic entity casses. D Transaction Group (XO) Datafow nformation processing is the work of transforming and communicating data. Avaiabiity of the data is both a necessary precondition and a major stimuus for performing this work. Thus information processing systems (organic and mechanica) are argey driven either impicity or expicity by data fow. Work Fow Management reies heaviy on data fow to contro the Appication System. n the remainder of this section we consider the fow of charge information from the merchants to the cardhoder accounts. This exampe wi iustrate the key Work Fow concepts of Transaction Groups, Tasks and Queuing Points. Merchants participating in the MCC system accumuate batches of charge sips. Each sip contains merchant and cardhoder identification encoded in a suitabe optica-character-recognition (OCR) font. A merchant wi periodicay deiver these batches to his MCC Regiona-Data-Center, either directy or via his bank. The merchant is reimbursed for the tota amount of these charges, ess a computed discount. The amounts on each sip are OCR-encoded, then the batches are read into the computer system via an OCR- RDC 8 CC - Credit-Cards RDC - Regiona-Data Center RO - Regiona-Operations Figure 4--Credit Cards structure. Work Fow View of a Distributed Appication 597 RO - Regiona-Operations CO - Cardhoder-Operations MO - Merchant-Operations RO - nter-regiona-operations Figure 5-Regiona-Operations structure. reader. This is the first operation perceived by the Appication System. The interna form of a batch of charge sips is a Transaction Group caed Saes-nputs. A Transaction Group can be thought of as a bunde of transactions to be route and processed together; however, its actua interna structure is consideraby more compex than this, to satisfy the combined requirements of program data access and the Work Fow integrity/recovery architecture. A Transaction Group need not represent an externa entity such as a batch of charge sips. Transaction Groups are the units of data fow within an Appication System. Saes-nputs Transaction Groups are generated within the computer system by the operation of OCR-readers. Within a Merchant-Operations Sub-Appication System this is represented by Optica-Character-Reader Tasks. A Task is a basic instance of work within an Appication System. Tasks are the users of data, i.e., they produce, utiize and/or consume Transaction Groups. n addition to Optica-Character Reader Tasks, the fow of Saes-nputs Transaction Groups invoves two other kinds of Tasks. The first is the crediting of the merchant accounts within Merchant-Operations, caed Update-Merchant-Accounts Tasks; the second is the debiting of the cardhoder accounts within Cardhoder-Operations, caed Update-Cardhoder-Accounts Tasks. Figure 6 iustrates the compete fow of Saes-nputs Transaction Groups within the Appication System, using the schematic structure notation. n addition, the arrows on the horizonta ine show the direction of fow; more specificay they represent the sequence of transitions of the Saes nputs fow contro state. After Update-Cardhoder-Accounts the Saes-nputs Transaction Groups are no onger necessary and they cease to be active entities within the Appication System. athough they are retained as archiva entities for auditing and recovery purposes. We concude this topic by noting that a Work Fow Schema contains a compete producer/consumer mode of data fow within the Appication System. Commitment contro The foregoing treatment of the fow of charge information woud be satisfactory were cardhoders not permitted to make purchases outside their home regions. The absence of this restriction poses compications not readiy resoved even if Update-Cardhoder-Accounts has access to a goba cardhoder data base distributed among the ten Regiona Data-Centers. First, a Regiona-Data-Centers may not aways be avaiabe, a fact that shoud not hinder oca processing at other centers and one that we wish not to expose to the individua Tasks running esewhere. Second, each Regiona-Operations is a separate profit center requiring a separate reckoning of inter-regiona financia transactions, which woud be hidden in a singe distributed data base. Third, we do not wish to submit transactions to a remote region unti we have some degree of confidence in the resuts of the processing that produced them, nor do we wish to post transactions from a remote region without simiar contro. We wi now address these probems. The first part of the support for remote purchases is the introduction of Remote-Purchases Transaction Groups to effect the fow of this data among the various Regiona Operations as shown in Figure 7. Each Update-Cardhoder Accounts Task can optionay produce one Remote-Purchases Transaction Group for each of the nine Regiona Operations other than its own. This is caed data fow fanout. A new kind of Task caed Remote-Cardhoder-Updates accepts Remote-Purchases Transaction Groups from one or more other Regiona-Operations and debits the oca cardhoder accounts accordingy. This is caed data fow fan-in. Figure 7b iustrates this arrangement for three Regiona Operations. We now consider the support for inter-regiona financia accounting of Remote-Purchases Transaction Groups. This consists of two kinds of Tasks within the nter-regiona Operations Sub-Appication Systems, Outbound-Remote Baancing to post outgoing Transaction Groups and nbound-remote-baancing to post incoming Transaction Groups. Figure 7c iustrates the genera fow of Remote Purchases Transaction Groups. Our treatment has regarded data fow as essentiay par- w MO - Y.erchant-Operations CO - Cardhoder-Operations OCR - Optica-Character-Reader UX.. - Update-Merchant Accounts UCA - Update-Cardhoder-Accounts S - Saes-nputs Figure 6-Fow of Saes-nputs. 598 Nationa Computer Conference, 979 a.) Simpified Structure b.) Specific Exampe 88GB ' c.) Gcr.cr. Structure!Jr:.'. - :Ji=,c.:n tr:-cnrjbojor-tccounts :-;(Li - 2c;;.:) t,( -Cn.rdho(kr- :JJda tos 2:' - hct:0 tr.-purc..ses RC - eri ::na.-0perations OF3 - Outbyund-Remote-Baancing!FiB - nbo md-remote-baancing Figure 7-Fow of Remote-Purchases. ae and asynchronous. However, appication integrity and recovery contro require that certain phases in processing be synchronized. This requirement was first expicity appied to the fow of Remote-Purchases Transaction Groups among Regiona-Operations, but we have in fact reied on it throughout this presentation. Furthermore, the fact that work wi proceed at different rates and with different eves of actua concurrency in different parts of the system and at different times imposes additiona requirements on the synchronization of data fow. These requirements are subsumed under the genera notion of controed commitment. Commitment (consigning, binding over for use) occurs whenever data produced by one Task is made avaiabe for use by other Tasks. This may occur when data in a shared data base is unocked; however commitment in this manner is not very amenabe to higher-eve contro. being necessariy synchronized to the interna operations of the Task. Transaction Groups make the fow of data between Tasks expicit. This expicit fow can best be utiized for Appication contro if an externa agency is interposed between the reinquishing of contro of a Transaction Group by one Task and the acquisition of contro by another. This agency is a Queuing Point. Queuing Points are mai boxes for Transaction Groups. They serve as brokers to acquire and dispose of Transaction Groups for Tasks, the actua users of data. Thus they serve to decoupe individua Tasks from what, when and where other Tasks exist. The avaiabiity of data at a Queuing Point may be the stimuus for scheduing work, or the data may be hed at Queuing Points pending some other stimuus such as time or administrator action. We can satisfy the remaining requirements for contro of the fow of Remote-Purchases Transaction Groups with appropriate Queuing Points. Within the nter-regiona-operations Sub-Appication System of each Regiona-Operations Sub-Appication System we estabish one Remote-Region Queuing Point for each other Regiona-Operations. The Remote-Region Queuing Points accumuate Transaction Groups bound for the other Regiona-Operations. Upon a suitabe administrator command, Outbound-Remote-Baancing removes each Transaction Group from the seected Remote-Region Queuing Point, posts appropriate information to the nter-regiona-operations database, and forwards the Transaction Group to nter-regiona-operations within the remote Regiona-Operations. Each nter-regiona-operations accumuates incoming Transaction Groups at a singe nter-regiona-transactions Queuing Point. Upon a suitabe administrator command, nbound-remote-baancing removes each Transaction Group from the nter-regiona-transactions Queuing Point, posts appropriate information to the nter-regiona-operations data base, and forwards the Transaction Group to the appropriate pace within this Regiona-Operations. n the case of Remote-Purchases Transaction Groups, this is Remote-Cardhoder-Updates. Figure 8 iustrates the compete fow of charge information into the appropriate accounts, appying the principe that a Tasks are decouped by Queuing Points. This figure shows the power of the schematic definition concept. t shows the fow of work through the Appication System in an inherenty parae manner, yet it admits of the necessary synchronization and contro. The Queuing Points provide for the unification of a network communications mode (data fow) with a hierarchica processing mode (data transformation). The names of the entities in Figure 8 are actuay names of types of entities within the casses of entities denoted by the shapes in Figure 2. At any given time there exist mutipe occurrences of entities of each named type, e.g., mutipe Tasks of type Update-Cardhoder-Accounts and mutipe Queuing Points of type Remote-Region. Note that there might even exist mutipe Appication Systems of type Credit-Cards, e.g. for testing within MCC, or because a soft ware house has appied this appication to companies other than MCC. Much of the power of the Work Fow Definition Language derives from its abiity to define com- Work Fow View of a Distributed Appication 599 pex appication structures in terms of the underying types of entities, whie associating enough information with these named types to adequatey contro the actua occurrences. n the next section we wi show how this is done. WORK FLOW DEFNTON LANGUAGE Goba structure We have presented the structure of an Appication System as a schematic diagram, and we wi now examine its expression in the Work Fow Definition Language. The foowing prose description of the anguage is presented to expain the appendices, which are intended to convey a better understanding of the anguage. Appendix A summarizes the conceptua structure of the Work Fow Definition Language. The anguage is basicay bock-structured with recursive nesting of the higher-eve constructs, i.e., Sub-Appication Systems and Sub-Appications Environments. The representation is free-form with punctuation and indentation optiona. (Sub)-Appication Systems comprise appication-bocks deimited by termina constructs. Appication-bocks describe nested spheres of contro of work within an Appication System. Appication-bocks may contain, in addition to nested higher-eve constructs, the decarations of types of ower-eve entities of the categories interna, externa and environmenta. These wi be described further in subsequent sections. (Sub)-Appications Environments comprise environmentbocks deimited by termina constructs. Environmentbocks describe processing environments which do not directy perform any work, athough they may contain Sub Appication Systems which do perform work. Environmentbocks may contain a subset of the entities contained in appication-bocks, interna and externa entities being excuded. Appendix B is a sampe Work Fow Schema for the portion of the Credit-Cards Appication System described in the second section. Whie this schema conforms to the structure shown in Appendix A, it contains assertions more detaied than shown in Appendix A. t is the assertions appearing as rues or poicies associated with the structura entities, that, 8 E7 CC - Credit-Cards RJC Regiona-rata-Center c - RCf,iona-Operations r J - :erc;hj.nt-'::;j.!erations - CurQoder-Operations CO RQ - nter-p.a ;iona-operations OCR - Optica-Character-Reader m A, - Update-Merchant-Accounts DCA - Update-Cardhoder-Accounts RCU - Remote-Cardhoder-Updates RR - Remote-Rogion ORB - Outbound-Remote-Baancing RE - nbound-remote-baancing RT - nter-regiona-transactions S - Saes-nputs RP - Remote-Purchases Figure 8-Compete fow of charge information. 600 Nationa Computer Conference, 979 give much of the meaning to the schema. These assertions appy generajy or by defaut within the scope of the decarations containing them. Many more kinds of assertions can be made than are iustrated in the sampe schema; however, the sampe shoud iustrate the concept. nterna entities The casses of interna entity types in a Work Fow Schema are Transaction Groups, Appication Modues, Queuing Points, Cocks and Caendars. These define the work performed interna to, and under compete contro of, the Appication System. As previousy stated, Transaction Groups have extensive interna structure, athough this has been deiberatey omitted from the exampe in the interest of carity. This structure may be party described in the Work Fow Schema, but is usuajy competey defined in a data schema. An extensive repertoire of contro functions exists
Search
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks