WO2000058873A1 - Moteur de conception du flux des travaux - Google Patents

Moteur de conception du flux des travaux Download PDF

Info

Publication number
WO2000058873A1
WO2000058873A1 PCT/US2000/007795 US0007795W WO0058873A1 WO 2000058873 A1 WO2000058873 A1 WO 2000058873A1 US 0007795 W US0007795 W US 0007795W WO 0058873 A1 WO0058873 A1 WO 0058873A1
Authority
WO
WIPO (PCT)
Prior art keywords
objects
business
data
context
workflow
Prior art date
Application number
PCT/US2000/007795
Other languages
English (en)
Inventor
Michael R. Clements
Robert L. Gryphon
Original Assignee
Octane Software, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Octane Software, Inc. filed Critical Octane Software, Inc.
Priority to AU40252/00A priority Critical patent/AU4025200A/en
Publication of WO2000058873A1 publication Critical patent/WO2000058873A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management

Definitions

  • the present invention relates generally to computer systems and, more specifically, to computer systems used to model workflows.
  • workflow modeling systems tend to be modeled either around the data that is used to represent the workflow, that is typically stored in some for of permanent storage (e.g., a database) or around the graphical user interface used to communicate with the users.
  • GUI graphical user interface
  • the system and method of the present invention allow for easy and efficient modeling of business workflows by separating the workflow modeling process from the details of both the user interface and the storage of data onto the system.
  • business analysts can concentrate on modeling the business workflow using, for example, a workflow modeling language, independently from the user interface and data storage considerations that affect prior art system.
  • the process of building and maintaining business workflow modeling systems is greatly simplified. This is accomplished by separating the workflow model from the user interface and data storage components of the system and using a synchronizer to coordinate the operation of the system.
  • business workflows can be modeled independently of the graphical user interface that is used to communicate with the users of the system. Similarly, the way data is stored in a database can be modified without necessarily requiring changes to the business workflow models.
  • Fig. 1 shows a conceptual view of a computer system architecture, in accordance with an embodiment of the invention.
  • Fig. 2 shows the components of a Workflow.
  • Fig. 3 shows a tree of related contexts in the lineage associated with a user session while the transaction server is running .
  • Fig. 4 illustrates how steps are added to the Stepstack either by a workflow or by other steps.
  • Fig. 5 shows MAPI objects represented in the CDO object model .
  • Fig. 6 is a block diagram of the E-mail system object collaboration .
  • Fig. 7 is a sequential diagram illustrating the operation of the Email Peripheral model.
  • Fig. 8 is a block diagram illustrating a three-level deep chain of bags.
  • Fig. 9 is a block diagram of the transaction server's security architecture.
  • Fig. 10 is a block diagram illustrating the physical architecture of a typical transaction server system that supports email processing.
  • Fig. 11 is a block diagram of a "one-way trust" security configuration .
  • Fig. 12 is a flow diagram of the possible outcomes of an operation, in accordance to an embodiment of the invention.
  • the computer system includes six major components: Business Workflows (BWs) , which drive the application (and frequently the user) by using Business Rules (BRs) to coordinate and sequence Operations.
  • BWs Business Workflows
  • BRs Business Rules
  • BIOs Binary Information
  • PBIO Persistent Business Information
  • Mappers which move data between persistent storage
  • Mappers use DBWires, which talk to databases, and they use TransMaps which are data organization trees. Interactors, which render applications (consisting of Workflows and Business Information objects) on various delivery channels such as Web, Email and Telephony.
  • Synchronizer which controls and sequences the operations of the entire system.
  • the Synchronizer is an event machine that enables the various independent objects in the system to collaborate anonymously.
  • Peripheral which orchestrates the cooperation of the transaction server with external devices and agents, such as CTI and Email.
  • the system architecture described herein is a "framework" design.
  • the system provides a framework in which one quickly can build robust and reusable business applications without having a lot of technical knowledge .
  • the six most fundamental entities in the system are Business Workflows, Business Information Objects, Mappers, Interactors, Synchronizer, and Peripherals.
  • the first section provides an overview of the architectural design and the following sections will describe in detail these fundamental entities.
  • Fig. 1 shows a conceptual view of a system architecture in accordance with an embodiment of the invention. Object categories are illustrated in an overview of their structural relationships and collaborations.
  • the system architecture of Fig. 1 includes three layers: process layer 110, cache layer 130 and interface layer 150.
  • Process layer 110 is responsible for modeling and controlling business workflows.
  • Cache layer 130 includes business process contexts 135n, intelligent data objects 140n and a transaction layer 145.
  • Cache layer 130 stores information received from interface layer 150 and manipulated by process layer 110 during execution of the business workflows. When processing is completed, the data stored in cache layer 130 can be stored back into external storage facilities via interface layer 150. Finally, interface layer 150 coordinates input and output of data between cache layer 130 and any external interfaces to the system.
  • the architecture consists of six fundamental abstraction layers or models:
  • the framework data model de-couples runtime dynamic data models (representational data models) from their persistent structure (relational models) .
  • the Relational/Persistence model includes the objects used to communicate with persistent storage (RDBMS) , and those used to perform the bi-directional mappings between representational and relational data models. This enables Workflows, Steps and Operations to talk only to representational data objects, which greatly simplifies the architecture by completely decoupling applications from persistent data structures .
  • This model consists primarily of Business Information
  • BIOs Objects
  • Fig. 2 shows the component parts of a
  • business process 115A starts executing within a context 135A by interacting with plug-ins 210.
  • information stored in context 135A is either modified or new information is added to the context (i.e., the context grows) .
  • Step 250A then triggers action 120A.
  • prompts and requests for responses are sent to Conversationalist GUI 220.
  • the result of this interaction is evaluated according to an enabled business rule 125A and, if the business rule returns a success code, context 135A is updated to reflect the results of the interaction.
  • step 250B triggers action 120B to initiate a interaction with Mail pump 230.
  • context 135A may again be modified.
  • Step 250C then triggers action 120C, whose results are verified by business rule 125C.
  • business process 115A reaches terminus 260, control is transferred back from business process 115A to another business process.
  • the architecture enables a business analyst to define canonical applications. That is, an application consists of a behavioral model (what it does) with the business data objects it manipulates (what it is) .
  • the way the application is presented or rendered can be mere ornamentation, not an intrinsic part of the application.
  • contact channels Some examples of contact channels are Web, Email, CTI and ATM machines. Because the Workflow' s behavior and data models are already defined, Contact Channels merely provide a means to communicate this information with the application user. Indeed, many Workflows run without ever knowing or caring about which contact channel is being used. Indeed, different instances of the same Workflow might be rendered simultaneously to different users on different contact channels.
  • the Synchronizer drives workflow and orchestrates system activities. It ensures that actions transpire in a flexible, yet orderly sequence based on Workflows designed by the business analyst, choices made by the user, error conditions encountered, and so forth. Workflows can collaborate anonymously through the Synchronizer.
  • Peripheral Model Peripherals are external devices or agents that cooperate with the transaction server. Two examples are Email and CTI.
  • peripherals can be interactive and thus also may act as
  • the peripheral model orchestrates the cooperation between transaction server and these external devices by providing basic functionality such as sending email from a Workflow or automatic filtering or responses to messages.
  • the peripheral model may forward some events to the
  • Object Classification All objects principally have a Class name and an Instance name.
  • the class name is often referred to as an object's type, though it also can be regarded as the set of interfaces the object supports.
  • the instance name is the name of a particular instance of the object. For example, three different objects may have a class name of integer but have instance names of x, y and z. Though all object oriented software systems share this concept, in the Architecture it is made explicit.
  • ICoreObject interface All objects in the Architecture implement the ICoreObject interface. This means they are derived from class ICoreObject and aggregate an instance of class CoreObject. Thus they inherit a common interface - and provide default behavior - that can be used throughout the Foundation. This permits Studio and other tools to change in a controlled and coherent manner when we introduce new objects or if we rename an object. Additionally, it confines all such changes to the pertinent objects (ICoreObject and CoreObject) , protecting the architecture from such changes (no fragile base classes) .
  • the ICoreObject interface consists primarily of the explicit Class and Instance names described above, though in the future this interface may grow.
  • Objects in the Framework can be described in several domains: a class, a class type, a class name and an instance name.
  • Classes A class refers to a specific technical category of objects described in source code, an actual C++ class.
  • CBD is a class. Classes are only meaningful to core developers who build the framework.
  • Classes are the core of the ATL/COM objects that comprise the system, are designed and coded by the core development team, and are hard coded.
  • a class type is a word or phrase that describes a class.
  • BIO is the class type for Business Information
  • Step is the class type for a Step in a Workflow.
  • a class type is a way of referring to a category of objects in the framework .
  • Class Types are designed and coded by the core development team in accordance with requirements set by the application development and business analyst teams, and they are hard coded into the framework.
  • a class name is a word or phrase that describes a class used within a specific context.
  • a class name describes a specific category of a class type. For example, Customer is the class name for a Business Information Object used to store a customer. Where class type is general, class name is specific. However, class name still identifies only a category of objects, not a specific, unique object.
  • Class Name describes a specific variation of a Class Type. Class Names are defined by business analysts and defined in meta-data; they are not hard coded. They can be designed, created, destroyed and modified in meta-data without modifying or rebuilding the framework.
  • An instance name is a word or phrase that describes a specific instance of an object. For example, either JoeBloe or
  • -73 may be the instance name for one particular Customer object.
  • Instance Names are defined arbitrarily by business analysts through Business Rules and schema requirements.
  • the class is CBD, the C++ class that implements the BIO class type.
  • the class type is PBIO, for Persistent Business Information Object.
  • the class name is PBIO .
  • Customer since it is storing a customer .
  • the instance name is JoeBloe, since it is storing that customer.
  • the persistence model is the abstraction layer that provides services for access to persistent storage. It contains two parts. One is the Database Wire (DBWire) , which is used to connect to a database and submit SQL statements. Another is the Persistent Business Information Map (PBDMap) that contains information about where the business data lives in a persistent storage; this object uses a DBWire to store data to or retrieve data from the persistent store. Note that PBDMap is not the only component that uses the DBWire.
  • DBWire Database Wire
  • PBDMap Persistent Business Information Map
  • DBWires provide an abstract interface for objects to connect to a RDBMS and store data to or retrieve data from the RDBMS.
  • the DBWire lives in the transaction server machine
  • the RDBMS lives on the database server
  • the client components using the DBWire live in the transaction server machine (in-proc with the DBWire) .
  • the current implementation of the DBWire object deploys two of the mainstream RDBMS: Microsoft SQL Server and Oracle.
  • the DBWire implementation provides a data access environment that supports multiple client connections to the RDBMS and supports heterogeneous transaction management features.
  • DBWires provide an abstract interface for objects to connect to a RDBMS and store data to or retrieve data from the
  • RDBMS RDBMS
  • BIO when a BIO is initiated, it uses the BDFactory to build its property list. The factory then uses a DBWire to read meta-data from the database to find the property list for the specific BIO class name and return this information back to the BIO.
  • All DBWire classes share the invariant methods of the IDBWire interface so that the clients of the DBWires can use them generically.
  • the implementation of a DBWire class encapsulates the particular category of RDBMS and the interfaces to access them.
  • a reasonable way to implement a DBWire class is to use the most generic industrial standard interface for a category of of RDBMS.
  • the primary implementation for architecture is ADOWire, which is based on the Microsoft ADO interfaces and can be used to access a variety of RDBMS that support ODBC or OLE DB interfaces such as Microsoft SQL Server and Oracle.
  • ADOWire is based on the Microsoft ADO interfaces and can be used to access a variety of RDBMS that support ODBC or OLE DB interfaces such as Microsoft SQL Server and Oracle.
  • ODBC OLE DB interfaces
  • the Oracle RDBMS supports the ODBC interfaces, we are not going to implement an OracleWire neither, unless there is a need to use the native Oracle interfaces, such as for performance reasons to avoid the overhead of ODBC.
  • a DBWire class can also be implemented for a particular RDBMS which does not support any standardized interface and the only way to access it is though a proprietary interface. Either way, all DBWire objects expose the canonical IDBWire interface so their clients are completely decoupled from the database technology used. For example, if the current objects were completely modified internally so that, for example, they use OLE DB instead of ODBC or ADO, clients of these objects would continue working, unaware of these implementation changes .
  • ADOWire is an implementation of the IDBWire interface. It is based on Microsoft's ADO (Active Data Objects) technology, which provides universal access to any tabular data that provides an OLE DB data query processor (OLE DB driver) .
  • ADO Active Data Objects
  • the current ADOWire object uses ADO 2.0, which requires
  • ODBC level 3 drivers for the particular database being used.
  • ADOWire is a single object that talks to every database that supports.
  • the architecture of the present invention is designed with the location transparency in mind for object components and even for RDBMS. That means we will have object components and even different RDBMS deployed in different NT Servers or
  • MTS Transaction Server
  • the ADOWire running in the MTS environment will support multiple connections to an RDBMS with the ODBC 3.0 Driver Manager maintaining a pool of ODBC connections.
  • a PBIO does not know where its data resides in a RDBMS, nor does it know how to persist its data to or retrieve its data from a RDBMS.
  • a PBDMap provides an abstract interface to map the properties of a PBIO to their locations in a RDBMS and persist its data to or retrieve its data from the RBDMS . Every
  • PBIO uses a PBDMap.
  • a PBIO is asked to persist its data to or retrieve its data from a RDBMS, it delegates the request to its PBDMap.
  • PBDMap object itself is stateless, which allows the Architecture to leverage significant scalability improvements described below.
  • a PBDMap contains a collection of the Database Property Maps (DBPropMap) for the PBIO' s properties.
  • DBPropMap provides an abstract interface to map a single property to its location in a RBDMS.
  • the PBDMapFacoty is a singleton object that caches the property maps for the PBIOs.
  • the PBDMapFactory implements the PBDMapFactory interface which has only one method: init() .
  • the PBDMap calls this method to get a bag of property maps for the PBIO. If the PBDMapFactory has the property maps in the cache, it returns the property maps to the PBDMap. Otherwise, it delegates the request to a master factory to build the property maps and caches the returned maps. The master factory in turn delegates the request to the PBDMapLoader .
  • PBIO Map Loader PBIO Map Loader
  • a PBDMapLoader is the only component that knows the metadata describing where the properties of the PBIO live in the persistent storage. It uses a DBWire (described below) access to the RDBMS and build the property maps. For the PBIO.
  • the PBDMapLoader implements the IMetaLoader interface which has only one method: getBagO which builds a bag of property maps for the PBIO.
  • BIO Representational/Business Information Model
  • a BIO is a group of related data united around a single concept. Common examples of BIOs are Customers, Employees, and Orders.
  • a BIO is a container that organizes and "cooks" or packages business data so that it can be used in a BW.
  • BIO Class is a template for a particular type of BIO.
  • BIO most often describes an instance of the BIO class (rather than the class itself) , although the two meanings are frequently used interchangeably.
  • BIO Classes are extremely flexible. They can reuse properties, and they can be properties. All BIO Classes share the invariant common methods Init, Release, Set and Get. BIOs can encapsulate other BIOs, yet the encapsulated objects can act on their own as well .
  • BIOs may be persistent.
  • a Persistent BIO (PBIO) has an extended interface that supports methods Retrieve and Persist. They implement these methods by reorganizing their information to the format of a persistent store and storing it there with a Mapper. BIOs operate within the Context, and Business Rules and Operations access them from there.
  • BIOs maintain arbitrary state information.
  • Business Analysts can use Workflows to define state models for business data; the state of such a model is stored in BIOs.
  • Business Analysts can also define state models for business process; this is described below, in the section regarding behavior.
  • BIOs control access to their methods via wrappers of Business Rules. This is a final line of defense against incorrect input or operations inappropriate for a given state of the BIO.
  • Business Rules can use the state information in BIOs as input indicating whether operations should proceed.
  • a PBIO does not know where its data resides in a RDBMS, nor does it know how to persist or retrieve its data.
  • the PBIO delegates these operations to a PBDMap.
  • the PBDMap provides an abstract interface to map the properties of a PBIO to their locations in a RDBMS and persist its data to or retrieve its data from the RBDMS.
  • a PBDMap contains a collections of the Database Property Maps (DBPropMap) for the PBIO' s properties.
  • DBPropMap provides an abstract interface to map a single property to its location in a RBDMS. It contains the Database Connection (DBConnect) , Database Table (DBTable) and DataBase Column (DBCol) for the property, which store the database, table and column information for the property.
  • a PBDMap uses a DBWire (described below) to access to the RDBMS.
  • the PBDMap contains the logic behind reorganizing the information in a PBIO; the DBWire is used to push or pull this information from a database.
  • BIO Class Most of the properties in a BIO Class are data fields originally derived from user input or from the database.
  • BIO Class The properties within a particular BIO Class originate from several different sources:
  • BIOs Some properties are part of a related BIO Class, but are also considered part of the current BIO. This occurs when the BIO has complex property types, including Matrices and other BIOs.
  • Links to other business objects are the 00 equivalent of 1-many or many-many relationships in relational theory. In 00 this translates to the concepts of usage or containment.
  • BIO relationships are simple 1-1 or 1-Many. Many-to-Many relationships are an implementation detail of relational databases - just a way a database can store relationships that, in the 00 model, are bidirectional 1-Many.
  • the 00 data model is hierarchical where persistent storage is relational.
  • PBDMap objects take care of this information transformation, decoupling the Representation and Persistence models so that each can be completely and fully optimized, obviating the need for the compromised data organizations required by legacy systems such as Siebel or Silknet - which work in both, but are optimized for neither.
  • Contexts are available to all Steps which may be linked into the relevant BW. Contexts may or may not be "temporarily persistent.” If a BW is suspended either by the user or the Process Manager, it will be stored in the Object Store until a cleanup process weeds it out .
  • a Context keeps track of its Business Information. The context maintains references to all the data objects (Properties of all kinds, including BIOs and Matrices) used by a Workflow. Steps can add new BIOs to the context.
  • a Context remembers its parent Context.
  • the latter is the parent of the former; not all Workflows have parents, since some are started by channels.
  • Workflow acts as a Step in a parent BW
  • its Context contains a reference to the Context of the parent BW (if any) .
  • Every Step in a BW can use the entire family history of Process Contexts. See the above section on Contexts under BWs for more information.
  • Contexts as temporary progress- tracking objects. As a BW moves through its Steps, it grows its Context. A Context maintains a record of the Steps that have been visited, the results of Business Rules consulted thus far in the BW, the Operations which were taken, the return codes of these Operations, and any other information that is pertinent to the BW.
  • a Context makes information available to Operations and Business Rules. Operations and Business Rules use this Context during the course of the BW. They also talk to BIOs and other data objects that "live" in the Context.
  • Some Contexts are "temporarily persistent" and are therefore saved in the Object Store for a certain period of time. In some cases users (or some other influence) may deliberately suspend a BW to be picked up later. Also, some types of BWs, such as those involving Internet interaction, are susceptible to users leaving the process with no notice, yet wishing to pick up where they left off in order to avoid duplicate input of data. In cases where a user might have to leave the system for a while, the application may offer a trigger mechanism (e.g. a button) that enables the user to suspend the BW.
  • a trigger mechanism e.g. a button
  • the User Interface Peripheral he is using must offer some way for him to automatically or manually search for his suspended Context—for example, reloading a page (with an embedded tag indicating the Context ID) in a browser, or entering a code into a telephone keypad. After a certain period, a suspended Context may expire and be deleted by a maintenance BW.
  • a channel wants to start a new workflow it usually has information that the workflow needs. For example, all interactive channels (Web, Email, CTI, etc.) usually want to identify the person at the other end of the channel so the workflow can take appropriate action. These channels need a way to stuff information into the Context so that it will be available to the Workflow when it starts. calls this "Context Preloading" . It is essential to preload the Context without exposing to the channel details about how Contexts are created and destroyed. Thus, the channel cannot itself push data into the Context. Indeed, the Context already has interfaces designed for clients that already have data objects, so the clients can direct the Context to assume or contain these data objects.
  • a channel The purpose of a channel is to orchestrate the interaction between the transaction server and a system in the real world, such as a web browser. These real world systems are unpredictable and thus inherently event-driven. Thus it is natural that the primary means of communication between the transaction server and a channel is that the channel sends Events to the Synchronizer, and the latter returns status codes indicating how it handled the Event. An Event describes "what happened, " not “what to do about it". The former is comprised of four key pieces of information:
  • Scope where the event happened. This is usually, but not always, one of a set of predefined values, including Web Contact Channel, Messaging, etc.
  • the event information is completely arbitrary, though in most cases it is a pointer to the Context under which the event was thrown.
  • Workflow Queueing on page 32 of this document contains more information describing events, event information and event processing.
  • the framework includes a class called BDBuilder that can be used to build data objects that can be preloaded into the
  • Every workflow has a context that stores the state of the workflow' s data model and its process model, and a single user session often involves many simultaneous workflows. Since these workflows must interoperate, it is useful - one might even say necessary - for each workflow to be able to access data objects that belong to the context of a different workflow.
  • a Server Global Context is a singleton context created by the transaction server Synchronizer and shared by all workflows. This context is created when the transaction server is started, destroyed when the transaction server is shut down, and can be used by any workflow. Any data placed into this
  • Control Local Context is a temporary context created when an Operation is fired, used for that operation and its children (if any) , and destroyed when the Operation is finished. When multiple consumers all use the same operation, each consumer will have its own Control Local Context.
  • a Control Local Context is also created when a script is fired from a channel handler (even when no Operations are used) . If the script fires any operations, those operations use the Control Local Context of the script (rather than getting their own) .
  • Context parentage is unidirectional - parents do not know about their children.
  • the transaction server first searches the control local context (if any) . If X is not found here, the transaction server searches the workflow' s own context. If not found, it searches the parent context. This continues iteratively until it finds X or it reaches the master context of the lineage.
  • transaction server will search the Server Global Context .
  • a lineage consists in general of several contexts connected in a unidirectional N-way tree with the master of the lineage at the root of the tree.
  • Each node in the tree is a context and it can see every other context between it and the root of the tree.
  • Two contexts, each on different branches of the tree, cannot see each other.
  • a snapshot of the lineage associated with any given user session while the transaction server is running would reveal a tree of related contexts, as shown in Fig. 3.
  • a tree of nested contexts 310 Each points to its parent, though the parents do not know about their children.
  • a context in the tree such as D
  • it is impossible to find all other contexts in the workflow for example, you cannot get to A from D because you cannot traverse downward
  • the tree cannot be enumerated or iterated.
  • the Workflow Registry stores a list of all the contexts in the lineage, ignoring their hierarchical relationships. Every lineage has exactly one Workflow Registry 320 and every context in the lineage points to the workflow registry, as shown in Fig. 3.
  • the transaction server maintains the context lineage trees and workflow registries such that they are always up-to- date .
  • BIOs are way of arranging BIOs to provide all information surrounding a key central idea, such as an
  • a Story is all the information that surrounds a central point that gives meaning to that central point over time.
  • a story takes advantage of the hierarchical arrangement of the data model and may be cyclical.
  • a Story is like a snowball, picking up different kinds of information over time as it rolls along. An Individual may start out in the system as a Prospect, then become a Customer, then become a Prospect for a different Product, then we may hire her as an Employee .
  • BIOs Even the highest level BIOs contain only the information pertinent to a BW. But the information needed to satisfy a process-centric point of view is only a fraction of what would be needed to tell the whole story. Stories exist as extensions of their core BIOs, extending the information provided in the BIO beyond what would be needed for any given process.
  • a BW that focuses on a Case object certainly would be interested in the particular steps taken toward resolving the case, and might be interested in the customer who opened the case, but the BW would not care about that customer's addresses.
  • a BW that focuses on a Customer object certainly would be interested in the customer's addresses, and might be interested in the cases that customer had pending, but it would not care about the particular steps taken toward resolving these cases .
  • the BW models the dynamic aspect of the application, describing how Business Process and Business Information interact. It includes data only to the extent that data is pertinent to the flow of the process. Stories provide a static aspect. They describe the complete Business Information model, and include process only to the extent that process has affected the current state of the data. Both models (static and dynamic) are critical for understanding and describing a Business Application.
  • a Story can be searched for by any identifying information in any of its facets, for example, "What's the story with that Individual?"
  • BIOs must be derived from a "master" BIO interface, so that they can be passed around and used generically. To make it easy for a business analyst to make new types of BIOs, we cannot require the use of a compiler to generate new BIOs. Thus particular BIOs (customer, entity, account, etc.) cannot be "cooked” into hard coded objects, as this would require compiling new COM objects to make new BIOs.
  • BIOs, Properties, Rules and their relationships can be done in myriad ways; what is the best way?
  • BIOs must be of the same actual binary class, though they may have different structure and identify themselves differently at runtime. This further implies that the structure of all BIOs must be defined in some kind of meta-data or repository. As BIOs are instantiated at run time, an object modeled as a Builder pattern constructs the particulars of the desired BIO object. This leads to the question, "If all BIOs are of the same class, what does it mean to say that a customer BIO is different from an account BIO? In other words, what can vary from one BIO to another?"
  • BIO The answer is simple but not obvious. What varies from BIO to BIO is the Property List, the Rule List and the
  • BIOs implement the same interface using the same underlying code. Even the implementation of different BIOs is the same actual code (COM object) .
  • This is a simple object that aggregates a bag of Properties, a Rule (which may be composite) , and a PBDMap object (if it is a persistent BIO) . It implements the functions in the IBD interface by delegating them to the appropriate aggregated objects. For example, get is deferred to the property list and persist is delegated to the PBDMap.
  • BIO When a BIO is instantiated it is generic, with no property list, no rule list, no persistence map and no identity (no classname) . It is unusable. After instantiation, the BIO must be initialized. During initialization, the name of the type of
  • BIO desired customer, account, etc.
  • the init method constructs the property list, the rule list and the persistence map (if appropriate) . After this, the
  • BIO has a class identity, but does not contain any data - except perhaps default values or lists for domain-constrained properties.
  • the retrieve method can be used to retrieve data from persistent storage into the BIO.
  • class names and instance names will not be "customer” and "Joe Bloe” since we need names that will be unique. But they will be human readable string based identifiers. Additionally, if we don't have any unique identifiers (a customer calls in but doesn't have his account number handy) , we can use a Matrix and populate to find a set of customers and pick one. Rule List
  • the BIO will refuse any operation that would cause its Rule to be FALSE.
  • the Rule may be a composite, may reference any property in the BIO, and has access to the Context of the current BW. Thus the Rule can see any property that every
  • Context must have, such as operator role, security level, event list, dispatcher, variables, etc. But the rules cannot see anything outside the canonical Icontext interface, which means they cannot become dependent on extended Contexts specific to a given process.
  • the BIO is in a consistent state (its Rule evaluates TRUE) , and its Rule can only reference the properties of the BIO itself, then the only operation that can invalidate the BIO is a set.
  • the set method evaluates the BIO' s Rule using the newly proposed property value; if the Rule returns FALSE, the set aborts and returns failure to its client.
  • BIO Some rules are attached to the BIO, which means they are evaluated every time set is invoked, regardless of which property is specified. Other rules are attached to the individual properties of the BIO, which means they are evaluated only when set is invoked for that property. For maximum performance and scalability, property- level rules should be used instead of BlO-level rules wherever possible.
  • a Property's value can be validated without reference to any other Property.
  • a Property Rule (rather than a BIO Rule) is the best method for validating this Property.
  • the best method for validation is a BIO Rule.
  • the BIO Rule evaluates every time set is called - regardless of which property is being set - it can guarantee consistency of X, Y, and Z. But one might not want to use a BIO Rule because it would be evaluated for every property set, even if it did not involve X, Y or Z .
  • the alternative to a BIO Rule on X only, is to attach similar rules to all three properties X, Y, and Z.
  • Operation object The only difference is that in an operation, the rule is considered an inhibitor, so the operation proceeds only if the rule returns TRUE.
  • the boolean value is reversed.
  • the operation's inhibitor rule is used as the validity checker, and operation' s action is used as the "fixer-upper" for the data. Only if both fail is the set obstructed.
  • the property list of a BIO contains its data. Every element in the list is a single property with a given name and elemental type.
  • the elemental types include:
  • any element in the property list can be another BIO, a PBIO or a Matrix.
  • Every element in the property list can be the subject of a get or set message. Getting a property that is itself a BIO, returns a reference to the BIO. Conversely, setting a BIO property replaces it with the one provided in the set method.
  • a property's type or name cannot be changed at run time.
  • properties of different types can be compared or set and the framework will attempt to perform automatically all reasonable type conversions.
  • the only way to change the value of a property is through the property's set method.
  • the property's own set method is never exposed to the client. Instead, the BIO publishes its own set method, which takes the property name and value as input parameters . Because set is the only way to change the value of a property, the BIO and property checks validation rules before allowing the set to proceed. If the set would violate any of the rules, nothing happens and the set returns failure to the client.
  • Every property has two sets of rules .
  • Style rules are defined by the transaction server and cannot be changed, removed or augmented.
  • the validation rules are rules added to a property by a business analyst to ensure the data in the property makes business sense. For example, one might require that a currency property used to store salaries must be greater than zero. One might also require that a time property used to store a "paid on date" field must be in the past.
  • the transaction server enforces but does not define validation rules; they are defined by the business analyst.
  • Setting PI may invalidate the Rule, which would block the set on PI before a subsequent set on P2 could be invoked.
  • both PI and P2 must be set as a single atomic operation.
  • the BIO supports multiple property sets in a single set method, called a multiset.
  • the set method accepts an optional number of parameters. Specifically, the syntax is: set ( [in] string propNamel, [in] VARIANT propVall, ⁇ [in] propName2, [in] VARIANT propVal2 ⁇ )
  • Identifying the complex properties of a BIO is a bit more complex because these properties have a metclass as well as a basic type.
  • a property of the basic type Iunknown might be a BIO or a Bag.
  • the BIO might be a customer, and account, or any other valid BIO defined in meta-data.
  • the property's datatype will be "BIO".
  • the optional default value will be a string of the form:
  • ClassName specifies the metaclass of the BIO the property represents, and the optional InstanceName suffix is the instance name the initial data that should be loaded into the BIO. If InstanceName is specified, the BIO must be persistent - that is, it must have a meta-data-defined mapper.
  • the property's datatype will be "bag".
  • the optional default value will be a string of the form: BaseClass .MetaClass Where BaseClass is the base class of the objects the bag will contain. This might be "BIO,” “property,” or any other valid base class. Currently, only "BIO” is supported.
  • MetaClass is the metaclass of the BaseClass. This can be any meta-data defined metaclass.
  • the property's datatype will be "Matrix".
  • the optional default value will be a string of the form:
  • ClassName [ . InstanceName] Where ClassName specifies the metaclass of the Matrix the property represents, and the optional InstanceName suffix is the instance name the initial data that should be loaded into the Matrix. If InstanceName is specified, the Matrix must be persistent - that is, it must have a meta-data-defined Content Supplier Agent (CSA) .
  • CSA Content Supplier Agent
  • Example 1 Parent BIO with a One-to-One Relationship with a Child BIO
  • BIO with a 1 - 1 relationship with a "bar” BIO.
  • BIO "foo” will have a property of type "BIO”.
  • BIO BIO and make it a property of "foo".
  • Example 2 Parent BIO with One-to-Many Relationship with a Set of Child BIOs
  • BIO with a 1 - M relationship with a set of "bar” BIOs.
  • BIO "foo” will have a property of type
  • PBIOs load them up with information gathered from the BIOs or Context variables, and immediately persist them.
  • Every PBIO has a gather method in its public interface. This method does the following for each property in the PBIO' s property list:
  • Rendering -rendering information to the channel in a coherent manner is extremely difficult when the data is not organized into BIOs .
  • PBIOs as late as possible and release them as early as possible. PBIO wrapping does this while bypassing the potential problems of the gathering approach.
  • a PBIO is just a BIO with an extended interface and a persistence map. Every PBIO object aggregates a BIO and tacks on these new items. Thus, every PBIO defined in meta-data can be instantiated as a BIO, as long as the persistence map and extended interface are ignored.
  • BIOs non-persistent basic operations
  • These objects are lightweight compared to their corresponding PBIOs, since they do not have an extended interface or a mapping layer. Later on, if the process decides to retrieve or persist data to or from the BIO, it instantiates a PBIO to do this. So far, not much different from property gathering.
  • the PBIO uses the ClassName to instantiate the appropriate mapper object • Finally, the client tells the PBIO to perform the persistence operation (retrieve, persist or delete) , then tells the PBIO to die ( ) . When the PBIO dies, it destroys its mapper, leaves the BIO intact and returns to the client a reference to the BIO. Persistence Map
  • the persistence map applies only to PBIOs. Since
  • BIOs are not persistent they don't have persistence maps.
  • PBDMap of a PBIO determines where the PBIO' s data lives in persistent storage, and describes how to push and pull the data to and from the data store and the PBIO.
  • the PBIO itself does not know how it is made persistent. All the work is delegated to the PBDMap.
  • the PBDMap can do anything it wants, from pushing and pulling data from a set of relational databases, to dumping a bunch of binary data into a disk file.
  • the PBDMap doesn't have to map all the properties in the PBIO. The only properties that will be mapped are the ones that are assigned a location by the PBIO' s map. Thus, not only does the PBIO not know how it's made persistent, it doesn't even know which of its properties are persistent .
  • persist When its persist () method is invoked, how does a PBIO know whether to perform an insert or an update? First, the PBIO knows whether it its retrieve () method was invoked. If not, any information the PBIO contains did not come directly from persistent storage; thus the PBIO contains new data and the persist () must be an insert.
  • the PBIO' s retrieve ( ) method was previously invoked, then the PBIO contains a (possibly modified) live version of data that came from persistence storage. Thus the persist 0 must be an update .
  • the only way to change any of the PBIO' s properties is to use the set method.
  • the PBIO knows which properties have been modified, hence which properties must be pushed (either inserted or updated) into persistent storage.
  • BIOs are never shared; they are inherent per-instance objects.
  • BW Business Workflow
  • a Business Workflow viewed retrospectively, is a series of Steps that occur sequentially as a result of Business Rules. Because the Steps are linked dynamically, the static definition of a BW cannot include all the steps - they aren't known until the BW is running. Rather, a BW identifies only its initial, required Steps (its Backbone) . As each Step completes execution, that Step may queue additional Steps. Whether it does depends on Business Rules in the Workflow. Some Workflows are simple, such as a single Step or a highly preconfigured set of statically linked Steps similar to a Microsoft Wizard. A simple BW might ask for seven specific pieces of information one by one from a user via a GUI, validate the data, confirm it with the user, and then store it.
  • BIO Basic Information
  • Steps are backtracked: the Context is reverted one Step at a time As a result, all affected BIO states and data will be restored as they were before
  • a typical application of a single-Step backtrack would be a Back button in a Wizard-style interface.
  • the BW should normally consider it reversible, but in fact it is either not 100% reversible, or it doesn't matter whether it is reversed. It is up to the BW to decide whether this is good enough; in most cases it will be .
  • Context object The Context and BW objects are described in detail in the Architecture Requirements document. Workflow Context
  • a BW is always started by the Synchronizer and provided a
  • the Context may or may not have information in it. If it does, it may contain information read from a Peripheral, it may be a saved Context from a previous instance of the process, or may contain other information.
  • a process does not control the lifetime of its context . It must be designed to query the context if necessary and act accordingly when it starts .
  • a Process may receive a "suspend" message at any time. When this happens, it must either finish or roll back any transactions in progress, then make its Context persistent, then terminate itself. This may happen synchronously (client calling "suspend” blocks until the process has gracefully terminated) or asynchronously (client calling "suspend” never blocks) .
  • a Process' Context stores references to the Steps the process has completed. When a previously suspended process is restarted, it can obtain from its Context the most recently completed Step, and continue where it left off - e.g. fire that
  • Step's Director to continue at the beginning of the Step that was active when the Process was suspended.
  • a Workflow can spawn a child workflow; this is called a SubProcess.
  • a Subprocess is given a Context of its own, which is destroyed when the SubProcess exits .
  • the SubProcess can still reach the parent Context by explicitly calling
  • a Subprocess can be launched in either Inline Child, Inline Asynchronous, or Parallel mode.
  • a Parallel child BW is typically used to perform an independent task, and normally uses its own Presentation viewport (such as a separate browser frame or window) .
  • Parallel BWs are neither subordinate to one another (hence the child is not automatically destroyed when the parent exits) , nor protected from one another (hence the parent can explicitly kill the child and vice versa) .
  • Parallel BWs generally limit themselves to read-only and similar non- interfering types of access to each other's resources, but they are not prevented from performing intrusive operations as well unless a particular resource (such as a Context variable) is Locked by another BW.
  • Locks represent a compromise between flexibility and safety; my personal preference is to have "global" variables like the Language setting Unlocked by default until explicitly Locked, and all other variables Locked by default until explicitly Unlocked. If a BW hits a Lock, the operation fails and normal error recovery takes over.
  • Inline child BWs are used for tasks that are an integral part of the parent BW -- they are fired as Steps in the BW. They enjoy unrestricted access privileges to the Context, Presentation viewport, and other resources of its parent. This resource sharing is made safer by the more predictable nature of the control flow: from the time an Inline child process receives control and until it exits, the parent remains stopped, waiting for it to exit.
  • Inline Asynchronous child BWs are similar to function calls, in that they receive control immediately and return when they are done. However, this functionality is sometimes insufficient. For example, during the course of the workflow we may discover (perhaps by consulting our OLAP information source) that the user is a good candidate for purchasing a particular product . This discovery may occur at various points within the workflow, and therefore should be modeled as a general business rule rather than integrated into any one step. Such a rule, however, could fire at a time when the workflow is engaged in an important task, and flashing a special offer on the customer screen is inappropriate. Normally, such rules would be fired by the Synchronizer, upon receiving notifications from running BWs. The BWs themselves would merely notify the Synchronizer periodically, neither knowing nor caring about such rules .
  • New BWs can also be queued automatically by the workflow engine.
  • Such BWs are initially registered as Interrupts by another BW, with conditions under which they must be invoked.
  • the conditions are evaluated by the engine at each step transition using global variables and variables from the context of all running processes to which the Interrupt is Relevant. Relevance is determined through a qualification scheme structurally similar to those used for security credentials. If the conditions are satisfied for a particular process' context, the interrupt step sequence is inserted as an Inline Queued child of this process.
  • the transition priority into the first step of an interrupt sequence is set at time of registration of the interrupt sequence.
  • Synchronizer which starts child workflows in response.
  • a good example of this is the Navigator, which consists of a list of buttons. Each button, when clicked, throws a different event at the Synchronizer.
  • the Synchronizer has Event Selectors that cause it to start a different child
  • the solution to this dilemma is to provide a mechanism whereby the business analyst can decide, when he needs to run a certain workflow, whether to stack a child workflow as described above, or to have the server switch to this same workflow if it is already waiting somewhere in the stack.
  • This behavior is orchestrated by the Synchronizer' s selectors.
  • the workflow merely throws events as before.
  • the style of the selector that catches the event determines whether a new workflow is always started, or whether a new workflow is started only if no workflow of the same name is not already running in this session.
  • the difference here is similar to that between gosub/return and goto.
  • a Workflow is polymorphic to a Step - in fact, a Workflow is a Step. All Workflows are Steps, but not all Steps will be fired as independent Workflows - though they could be.
  • a Workflow is normally designed as a backbone Step. That is, a
  • Step that consists of a Director and possibly a Rule, but no operation. This Step's Director queues the backbone of the BW.
  • Synchronizer and Event Machine describes how peripherals and other external objects throw events at the Synchronizer, and how the Synchronizer responds by launching workflows, running operations, evaluating rules, etc.
  • Related Objects
  • the Behavioral Model consists of several other objects which fulfill the responsibilities of Business Workflow. These objects are described below. Steps
  • a Step is a stationary point in a BW.
  • a step consists of a Rule, an Operation and a Director.
  • the Rule may block the Step from occurring, the Operation determines what the step does, and the Director determines what Step(s) come(s) next.
  • a Step references a Director that when executed, provides the next Step(s) .
  • the Director may be simple, such as identifying a static, hard-coded next Step. Or the Director may perform a highly complex analysis of the BW history to determine dynamically a sequence of following Steps - with possible interruptions or diversions . This simplifies the architecture by setting the invariant that Directors always determine the next step, while hiding the complexity of determination within the Directors.
  • Steps are reusable. Steps may be reused across BWs, and therefore a given Step is never to be considered to belong to a single BW.
  • a BW uses steps, but it does not own them.
  • Steps are the unit of dynamic control flow for Workflows.
  • Control flow of a Workflow runs as follows:
  • Control flow is managed by the Workflow' s step stack 400. Every Workflow has a start step or step sequence (e.g., step sequence 410 in Fig. 4) . This is pushed onto step stack 400 when the BW starts . After the first Step completes its operation, the Step fires its Director. The Director pushes a step or step sequence (e.g., step sequence 420) onto step stack 400. The Workflow goes to the next Step at the top of step stack 400. This control sequence is depicted in the diagram of Fig. 4.
  • backtracking There are three major types of backtracking that can be performed within a BW: (1) backtracking to a parent step, (2) backtracking to a peer step, (3) backtracking to the nth previously executed step.
  • backtracking to a parent step is the least complex.
  • a step is popped off of the step stack only after all of its children have finished executing. This guarantees that all of the parents of the currently executing step can still be found in the step stack. Furthermore, there will be at most one parent per level and, if present, the parent will always be the first element on that level. Thus, backtracking to a parent step can be implemented by popping levels off of the stack until the desired parent is found in the first position of the top level .
  • the second and third methods of backtracking are much more complex because of the incomplete history provided by the step stack.
  • the step stack is intended to provide a glimpse of where the BW is headed and, therefore, does not contain any steps that have executed to completion. Given this behavior, backtracking to a peer step and backtracking to the nth previous step can only be accomplished if supplemental information is maintained regarding the history of the BW.
  • nth previous step S p may actually be located at a deeper level in the step tree than the current step S c . Therefore, it is necessary to first backtrack to the parent from which both S p and S c were descended. Then, the step stack must be filled, by firing directors, until it reaches the state it was in when S p was initially executed.
  • a Director is a composite object (a tree) consisting of a single method, eval. This method fires the Director's topmost
  • the Director jumps down into that node of the tree, queues any Steps it finds and evaluates any Rules it finds.
  • the director itself evaluates the Rules that determine whether Steps are queued. But often times it is useful to postpone evaluating a Rule (for example, a Rule might branch based on the outcome of a Step that is only queued, not executed) . Using the Workshop, the business analyst may indicate which Directors are to be queued rather than executed.
  • the system queues that Director.
  • the queued director is reused in the tree of another Director, the entire subtree rooted at the queued director is queued.
  • eval ( ) the director checks whether it's queued. If it is, it pushes itself onto the stack. If it's not, it evaluates its Rules and (conditionally) pushes its Step(s) onto the stack. In evalNowO, a non-queued director does the same thing as it does in a normal eval ( ) . A queued director ignores its
  • the framework currently includes two kinds of Directors, and it is designed to be extended to support many more in the future. Consistent with the 00 design of the framework, new types of directors can be added to the system with no changes to existing code or meta-data tables. This includes the Director Factory, which will be able to create, cache and manage the state of any new kind of Directors added to the system - with no changes to its existing code. As of the Beta 2.0 release in February 1999, the framework includes two kinds of Directors - Step Queuers and Step Sequencers .
  • a StepQueuer consists of a Rule and a single Step. When the StepQueuer is evaluated, it fires its Rule. If the Rule returns FALSE or fails to execute, the StepQueuer does nothing and returns. If the Rule returns TRUE - or if the StepQueuer does not have a Rule, it pushes its Step onto the Step Stack. Step Sequencers
  • a StepSequencer consists of a Rule and an ordered list of
  • the StepSequencer behaves just like a Queuer - except that where the Queuer pushes a Step onto the Step Stack, the Sequencer visits each of its children, and invokes eval on each, in the proper order.
  • Each of these children can be any kind of Director - a Queuer, another Sequencer, or any new kind of Director may introduce in the future. This continues recursively; there is no arbitrary limit to the depth or complexity of a StepSequencer.
  • a Workflow is stateless and maintains a step stack in the context.
  • that Context could be handed to any other Workflow object and continued.
  • the context can be handed to any other physical thread in any other Workflow object and continued.
  • the classical model of control flow enters at the root node, walks depth first down to the leftmost, deepest node, and crawls along the leaf nodes of the tree from left to right. If it is suspended, its execution state is saved (position in the tree, node visitation history, etc.) and later restored for subsequent execution.
  • Operations provide an abstract interface to do things . All Operations provide the same interface, hiding what they actually do from the client objects that use them. Operations enable client objects to do things without knowing what will actually get done.
  • a single Operation may perform a single action. Or it might be a sequence of many other Operations, each of which is simple or itself a sequence. This hides functional complexity from client objects, breaks the dependency between clients that perform operations and the operations themselves, and it builds operations into a hierarchy of reusable, compositable objects.
  • Operations are Commands that change the state of BIOs. An Operation is an active command, a piece of work performed by the system. An Operation might request data from a Peripheral; it might send data out to a Peripheral; etc. Operations primarily get data from and put data into BIOs .
  • Operations are atomic, either succeeding or failing (and perhaps rolling back) as a unit. Though an Operation is atomic, it may consist of a hierarchy of actions. If it does, the actions are considered a single atomic unit . They therefore run in a statically defined order with no conditional control flow. Operations are sequential. Operations are performed in order during the course of each Step.
  • Operations may be synchronous or asynchronous. Most Operations wait until they are complete before letting the system move on to the next Operation, but an Operation doesn't have to pause the system if there is no reason to do so - if subsequent Operations do not depend on its results.
  • Operations are reusable. Operations may be reused across Steps, therefore a given Operation is never to be considered to belong to a single BW. Operations exist independently within the Process Manager. A Step uses Operations, but it does not own them.
  • Business Rules are designed to prevent Operations. It is the job of Business Rules to determine whether Operations should be allowed to perform their functions. When an Operation is executed, the Process Manager checks whether any Business Rules in the system should be "interested” based on the Operation and the Context . Any relevant Business Rules will be checked, with a single failure causing the Operation to fail and return an explanation.
  • An operation is a composite command pattern consisting of either a sequence or any of many possible different action objects, both of which aggregate an Operationlmp object to handle context logging.
  • An action is a single independent exploit.
  • a sequence is an ordered list of operations, each of which is itself either an action or another sequence.
  • an operation may be as simple as a single action, or a complex multiplicity of actions arranged in an ordered tree. Regardless of the particular case, it presents a simple doo, undo interface to the client.
  • Fig. 12 The results are summarized in Fig. 12.
  • an operation is first triggered in stage 1210.
  • One or more rules are then evaluated.
  • stage 1220 If all rules return a TRUE value, the operation is executed in stage 1220. Otherwise the operation fails and return a BLOCKED value in stage 1230. If the execution of the operation is successful, a SUCCESS value is returned in stage 1240.
  • stage 1250 determines whether the operation is a transaction, in which case the operation proceeds to stage
  • stage 1260 determines whether the operation can be rolled back, in which case a CLEANFAIL value is returned in stage 1280. Otherwise, a CRITICALFAIL value is returned in stage 1290.
  • Every operation is either a sequence or an action.
  • An action is a COM object that implements the IOperation interface and does a single, atomic thing.
  • action objects There are many different action objects, each identified by a meta-data ClassName that maps to the object's COM class ID. Different action objects are real COM objects, each with a different COM class ID. Thus, to store an action in meta-data, one must merely store its COM class ID.
  • a sequence is a COM object that implements the IOperation interface. But the similarity ends here, as a sequence doesn't actually do anything, in the sense that actions do things.
  • a sequence maintains a list of child operations, each of which might be an action or another sequence - the parent sequence doesn't know (or care) which.
  • When a sequence receives the doo message it delegates it to its children (in forward order) .
  • a sequence also delegates the undo message to its children - in reverse order.
  • the Workflow drives Presentation.
  • BWs determine the order in which Presentation delivers and receives information from the user, as they do with any Peripheral. Interaction between a BW and a Peripheral (such as the GUI) is very much like a conversation, hence the name Conversationalist. Presentation responds to the direction of BWs regarding the order of activities, while having influence over the flow by offering users "trigger points" such as Next, Back, Suspend and Cancel buttons which can alter the BW flow from Step to Step. In addition, like other types of Peripherals, Presentation can trigger a BW without the intervention or even the knowledge of the user.
  • the Conversationalist will be primarily web-browser-based. It will be designed to present information and sets of prompts in several styles, e.g. Wizard, Line by Line, and Visual Story (a rendition of all or part of a BIO as a story on the screen through which a user can browse) .
  • One of the critical tasks any contact channel must do is to identify the users of the system and ensure that server transactions invoked on their behalf execute at the appropriate security level .
  • Every contact channel identifies users in different ways - phone numbers for CTI, source or destination URLs or cookies for web, "to/from” addresses or embedded tags for email, etc.
  • framework in which workflows are decoupled from channels, requires a channel-independent way of identifying users.
  • the particular user involved is not important, but his origin may be.
  • a web site exposed to the internet might allow any user to hit the server and browse an on-line catalog, while automatically identifying repeat users and providing them a customized experience. Then, if the customer decides to buy something, the site would switch to a secure SHTTP protocol and verify the user's identity.
  • This example illustrates three levels of identification:
  • User ID - origin may or may not be know, but user is known and is secure - secure and customizable.
  • Others such as on-line stores, may accept and encourage such access, but limit the server transactions such users can invoke .
  • the channel may place Origin ID information into that user' s local site. This information could be used to identify and welcome the user, and customize his experience, the next time he returns to the site.
  • Origin ID is a non-secure method for casually identifying users without using the overhead and inconvenience of an explicit, secure login. This is convenient for welcoming users and providing a customized experience that does not include personal, financial or other information of a secure nature.
  • a single user might have multiple origin IDs. This would certainly be the case if the same person used the service under different roles, for example when an employee purchases something from his employer's web store. The reverse can also occur: many different users might share the same origin ID. This would happen, for example, when a husband and wife both shop from home using the same browser and computer, but each uses a different credit card when purchasing on the web.
  • User ID is secure method for identifying an individual user. Unlike other, more casual forms of identification, user
  • ID can only enter the server through a secure mechanism - for example a secure SHTTP web page, a PGP encrypted email, or an encrypted GSM digital cellular phone.
  • a secure mechanism for example a secure SHTTP web page, a PGP encrypted email, or an encrypted GSM digital cellular phone.
  • the Framework includes an Identification Resolver component which carries out these duties. Specifically, the Resolver performs the following tasks:
  • the applications will inherit the standard browser interface components such as the menus and button bars.
  • Tree The left quarter of the screen will be occupied by navigation controls.
  • the look and feel of these controls will be highly customizable but they will be designed to take one of two commonly seen forms: Tree or Menu.
  • a Menu will consist of a series of text prompts or buttons, arranged vertically.
  • a Tree will consist of a series of text items (often decorated graphically) arranged in a typical hierarchical structure. The advantage of a tree is that it shows the user where she has been and what her options are from this point on.
  • a View is a set of visual objects to be presented together. This may consist of nothing but a designation of prompts and field descriptions (GUI type, data type, length, formatting, etc.) which the Conversationalist GUI draws and arranges. Or it may be a highly detailed page or frame with a precise visual object layout.
  • the Conversationalist GUI can communicate with JavaScript and ActiveX components, and in fact a View may contain nothing but a single ActiveX editable spreadsheet control from which all the data required by the BW Step is derived.
  • BW BW terms
  • one View will ultimately exist for each BW Step in which Presentation interaction occurs.
  • a single Step should not call for multiple interactions with the same Presentation; the designer should use multiple Steps in a BW to determine the order in which the Views should be presented.
  • the presentation of Views and the user' s interaction with the Views is referred to as a Conversation.
  • View Properties Only If the designer builds a View to correspond with a given BW Step, his simplest design option is to set View properties only. This translates to setting preferences in the Context which can either operate only within the current View or which can be left in place for future Views until overridden. Properties include Prompt Set Presentation Style (either Wizard or Scrolling Script) and Background Image (an easy way to complete a Wizard-style View without resorting to HTML as below) .
  • Prompt Set Presentation Style either Wizard or Scrolling Script
  • Background Image an easy way to complete a Wizard-style View without resorting to HTML as below
  • Custom View The designer may choose to write HTML or use web page design software to lay out the View in highly specific detail.
  • the resulting page (or frame) may include ActiveX components, JavaScript, or any other constructs typical in a web page.
  • this page needs to provide responses to the prompts passed from the calling BW Step. It can do this by employing specialty tags in the same way an auto- generated View does .
  • the View can never decide what is to be displayed.
  • the driving BW Step determines what information is pertinent and the View decides merely how this information will be displayed and acquired.
  • a View can either set its Prompt Set Presentation Style or inherit (from the current Context) the one used by the last View. Styles are:
  • a Conversation is the user's interactive experience with the user interface. Because most Conversations in the Demand
  • the application's BWs tell Presentation just enough information to get by.
  • the BW sends the Conversationalist Peripheral the following information:
  • each View is free to determine its own Style or to inherit the Style from the current Context. In most cases the Views will be presented in the same Style, although this is not required.
  • a business workflow communicates with the outside world through delivery channels.
  • a BW Step (or, more precisely, an Action within an Operation within a Step) orders information transfers out of the BW Context into a delivery channel and inputs from a delivery channel into the Context .
  • An Interactor is the unit of such data transport . Interestingly, Interactors enable Workflows and delivery channels to communicate without knowing about each other. It is crucial to ensure that neither becomes polluted with details or knowledge about the other, so that each remains independent and reusable. This is how a single process can be delivered across multiple channels, and how a single Interactor can be used in many different processes.
  • An Interactor is not itself a BW, in the sense that it is not composed of Steps, Operations, and so on. However, from the point of view of control flow and data sharing the
  • Interactor is similar to a Subprocess.
  • An Inline Interactor runs as a simple function call and, when done, returns to the
  • a Tearoff, or Parallel, Interactor executes asynchronously and independently from the parent BW, but shares the parent's Context subject to the data locking mechanism.
  • a BW can spawn and maintain multiple concurrently active Interactors.
  • An Interactor cannot directly communicate to another Interactor, nor back to its parent Workflow, except to signal its own completion. Rather, an Interactor performs its task by presenting the values of specific Context variables and storing user input in Context variables.
  • the particular variable to which an Interactor binds is supplied to it by the Action at the time the Interactor is invoked. If the value of the variable is an aggregate data structure such as a Business Information Object (BIO) , the Interactor must be designed to render data aggregates of this type. In this case, the Interactor' s appearance and the binding of its elements to data elements within the aggregate is defined at tool time through a Glyph (see below) .
  • BIO Business Information Object
  • An Interactor may publish and subscribe to system events through the Synchronizer, and events may also fire from triggers linked to the Context operations the Interactor carries out .
  • Synchronizer events are the sole mechanism through which Interactors can perform extra-Context activities, and through which they may receive additional instructions from BW while in progress .
  • Control Flow and Threading Models Unlike many systems, including Microsoft Windows, the engine is not driven by its user interface. It is useful to think of the server as executing on two sets of threads:
  • BW threads Workflow threads and user interface (UI) threads.
  • UI threads are typically created by the operating system or a web server to process UI events such as button clicks .
  • BW threads are created by the Synchronizer component within the engine to run Workflows. If the task is initiated by the UI (a web hit, for example) , the UI thread handling the request notifies the UI (a web hit, for example) .
  • Synchronizer which launches a BW thread. If the task is initiated by BW, the BW thread notifies the manager for the desired Contact Channel (C2) , which causes the system to launch a UI thread.
  • C2 Contact Channel
  • the Contact Channel Manager never makes BW threads wait for UI threads.
  • the C2M returns control to the Action as soon as basic initialization is completed.
  • the C2M then uses UI threads to transmit information to the user, to manipulate Context variables in response to Presentation events, and ultimately to notify the Synchronizer that the
  • the BW thread may either block, or, in the case of a Tearoff Interactor, continue with the Workflow.
  • the engine may also be able to reuse the physical BW thread while the Workflow is idle. With care, it is even possible to design the system to begin a
  • the C2M generally does not block UI threads, either.
  • a UI thread created or allocated by the operating system to handle a UI event is used to manipulate Context variables, to formulate a response for into the channel, and for such other tasks as may be necessary to handle the event.
  • a session's first UI thread is not caused by a UI event in any Interactor, but rather is used as a vehicle to deploy the Interactors in the first place. Since the Workflow may wish to deploy multiple Interactors at once, the C2M blocks this UI thread until the Workflow gives it a go-ahead to deploy.
  • C2M will block the UI thread until another go-ahead signal is received from the Workflow.
  • Viewports typically correspond to windows or browser frames .
  • Interactor can be placed into a Viewport in Erase, Overlay, or Append mode. Erase causes the previous Interactor in the
  • Each Context object has the ultimate responsibility for maintaining its internal integrity by enforcing its validation rules.
  • an Interactor may publish a list of business rules that it guarantees to hold True at all times when it calls Context object methods. Any rule from the reusable pool of business rules may be published in this way. If a Context object must later evaluate one of these rules for validation purposes, it has the option to instead trust the Interactor and skip the rule. This feature improves system performance when the client computer is sufficiently powerful to run the
  • Interactor code Alternately, a separate and single piece of code that evaluates the rules could be used. This code could be moved from the transaction server to the client, as needed. For various reasons, including the importance of a particular business rule, the objects may choose not to trust the Interactor' s guarantees.
  • the failed method If any of the Context object methods invoked by the Interactor returns failure, the failed method generates an Exception Object (analogous to a C++ Exception object) .
  • the purpose of the Exception Object is to facilitate interactive resolution of the problem by the Interactor.
  • the Interactor may then retry the failed method with different data and/or invoke other methods on Context objects. For example, if a Set fails due to a validation rule, the Exception Object might include an error message and a list of properties constrained by the rule. The Interactor' s default behavior might be to maximize its window, report the error message, and ask the user to re-enter the properties involved.
  • the Exception Object may identify to the Interactor additional Context objects and thus enable the Interactor to access these objects. If error handling is unsuccessful, the Interactor may choose to exit with an error return code. The return code reaches the parent BW only in the case of a synchronously called Interactor.
  • the Interactor' s fail is Dirty in most cases, since it does not attempt to reverse the successful method calls it has made.
  • the Interactor' s Undo may attempt to reverse these calls, if the Interactor supports Undo. Note that Undo' s are problematic in an environment with multiple concurrent threads over the same Context, because even simple Set methods may not be reversible. In all cases, Undo would remove the Interactor from the hosting Viewport.
  • a Glyph is an atomic component of an Interactor.
  • the function of a Glyph is generally to render a single Context variable or BIO property, called Bound Variable.
  • Glyphs can be aggregated into a group, which is itself polymorphic to a Glyph.
  • Each node and each link of the Glyph tree includes a list of named attributes with string constant values . Examples of attributes might be "IvrPro pt,” "GuiWidgetType, " "Color,” “FontSize,” “LabelText,” “LabelFontSize, “ etc.
  • the value of a Glyph attribute may be a binary object (blob) .
  • Inhibit The value logically AND' s with child values. This is useful for control of visibility, enable status, etc.
  • the Glyph tree is interpreted by a contact channel specific Composer component, which constructs the output stream appropriate for the channel.
  • any response produced by the channel is directed back to the same Composer.
  • the Composer may react to these user events by writing data into the Context and by firing Synchronizer events .
  • the Composer supplies default behavior for any omitted Glyph attributes, and ignores irrelevant attributes and those it cannot recognize. In most cases, only a small fraction of all supported attributes would have to be given explicitly within the Glyph. Even without any attributes present, a reasonable rendition should be possible based on property style and other descriptive information available from the bound variable. New attributes may be added in later versions of the product to support new functionality (say, a new GUI widget) .
  • the policy determines screen positioning of child Glyphs within the parent Glyph window.
  • Standard layout policies include “Row,” “Column,” and “Tab”. (In the latter case, child Glyphs share the screen area of the parent inside a tab control.) New policies may be added if the Interactor code supports them. Since the Glyph hierarchy typically reflects semantic relationships between data items, it may also be helpful on a non-GUI channel, for example, to determine the order of input .
  • Glyphs and their attributes are created at tool time and become part of the meta-data.
  • Top level Glyphs are named, and make up a Glyph Library. The designer can construct new Glyphs at tool time that would aggregate other named Glyphs.
  • the Glyph parent-child is a many-to-many relationship, so that, say, an "Address" Glyph may be aggregated by multiple forms. This is useful when different Address Glyphs must be designed for different languages, tenants, etc.
  • each composer effectively works in a separate Glyph tree and can make changes to attribute values visible only to itself .
  • the Composer begins with a top level Glyph of that tree, and follows down its hierarchical structure to do the rendering .
  • Bound variable name of a Glyph can be thought of as a
  • Glyph attribute with a unique inheritance model Specifically, any value attached to the link always overrides that of the node, and if the value begins with an @ sign, the value from the parent node is PREFIXED, otherwise it is ignored. The name is returned as a string and is resolved against the Context by the caller (normally a Composer) .
  • the caller normally a Composer
  • a Glyph and particularly a named Glyph out of the Glyph library, can be handed a "root" property through the link by its parent and render its sub-elements according to its own design.
  • an Address Glyph can be reused on any Address BIO no matter what larger data structure that Address may be aggregated into.
  • a Glyph can also go outside the root BIO, so that one can show, for example, time of day at the corner of a form.
  • the data binding logic within a Glyph is not visible to its run-time clients. From their perspective, only terminal (i.e. childless) Glyphs bind to any data. The client can then Set and Get the value of the Property and determine its runtime Type. When doing a Set, the client must submit all the variables to a Multisetter component, which would ensure that BIO Multiple Set is used for group storage operations directed at the same BIO. The use of Multiset is imperative because validation rule interlock may occur otherwise.
  • the system can generate default Glyphs for aggregate data types, including BIOs and Bags. This functionality is available both at tool time to offer the analyst a starting point from which to fine-tune the presentation, and at run-time if a terminal Glyph binds to an aggregate data item.
  • the Property Type is of an aggregate type.
  • the value of the property is in this case an IUnknown pointer.
  • the code uses Get to obtain this pointer, and then queries the object to determine its type: If the object supports either the IBD interface or the IBag interface, the corresponding child Glyph renders it as a hyperlink (a.k.a. hotspot) .
  • the action of the hotspot is to create a new top-level Glyph below the current form to represent the linked BIO or Bag. (This behavior is known as the Story Browser.) If the object is neither BIO nor a Bag, the Glyph is left blank and rendering is up to the hard-coded Interactor implementation.
  • the default Glyph structure generated for a BIO also includes "OK” and "Cancel” buttons at the bottom of the form.
  • the default Glyph consists of a parent with one child Glyph for every item in the Bag that is either a Property, a BIO, or a Bag.
  • the combination of "Tab” and “Picklist” cause child Glyphs to appear one at a time in the left hand side of the screen, with a selector listbox on the right hand side.
  • Child Glyphs are constructed as appropriate for each item in the Bag in the same way as for BIOs.
  • the listbox is populated with whatever the Interactor code would normally use as the label for the corresponding item. (In the absence of the Label attribute, either the internationalized Property name or, if not available, the value of the first Property inside a BIO is used as a label.)
  • the default Glyph includes a "New" button that, when clicked, adds to the bag a blank copy of the object currently displayed.
  • applets Java bytecode is downloaded into the client, while for an ActiveX the binary is downloaded.
  • the same applet can run on all computer platforms, but an ActiveX only runs on the platform for which it is compiled.
  • applets are supported by both Netscape Navigator (NN) and Microsoft Internet Explorer (IE), whereas ActiveX can only run in IE.
  • N Netscape Navigator
  • IE Microsoft Internet Explorer
  • ActiveX can only run in IE.
  • the applets' downside is that while both applets and ActiveX can expose methods to the script within the hosting Web page, only ActiveX can naturally throw events. Event throwing is needed, for example, to inform the script that the user expanded a branch in a tree control, so that the script can request from the server the data to populate the branch. (Within the architecture, it is generally not possible to download the entire tree control data into the client in advance) .
  • HTTP HyperText Transfer Protocol
  • any conversation is (1) initiated by the client; (2) results in the reloading of a Web page; (3) is closed as soon as the page is reloaded; and (4) offers no natural way to preserve state information through the reload. If state information has to be preserved, one must either (a) communicate it to the server and back, or (b) store it on the client as a cookie, or (c) store it as a script variable within a separate frame that is not being reloaded.
  • Cookies are character strings stored on the client's hard drive . Although some weaker browsers may not support cookies and some may reject cookies because of (unjustified) security concerns, we can probably assume the cookie feature to be available. (Cookie-less clients will experience difficulties in any event since the ASP server uses cookies for session identification.) A more serious problem is that the browser might restrict the number and size of cookies to protect the local hard drive: the "Netscape ONE" book mentions a limit of 20 cookies per originating domain.
  • client-server communication involving Web clients operates as follows.
  • the browser screen is divided into several HTML Frames under the control of the Viewport Manager, designed to simultaneously present multiple documents (one document per frame) that may not be aware of one another.
  • Each Document is generated and maintained by its own Composer, which is alone aware of the Document's structure, data binding, and behavior.
  • a Document can contain scripts, Dynamic HTML, Java applets, and additional HTML frames (not controlled by the Viewport Manager) .
  • a separate HTML Frame called the transaction server Gateway, is reserved for system use.
  • the transaction server frame is lightweight and fast to reload, perhaps empty of visual content or containing only a reference to a browser- cached logo image.
  • the system also makes use of the master frameset file, which is never unloaded unless the user navigates out of the site.
  • the master frameset contains script API code, referred to as Client Side Framework, or CSF, that can be reached by scripts running in any frame as top. foo () .
  • CSF Client Side Framework
  • Documents should use local wrappers, described in this section, that the framework inserts for this purpose into each frame .
  • the call causes the transaction server client-side framework to post a form that invokes a server side script OtsGateway.asp and ultimately reloads the transaction server Gateway frame with the return value of the script.
  • the DocID parameter (a decimal integer) identifies the Document to the server so that the request cmd can be routed to the appropriate Composer.
  • Each Composer is initialized with a unique DocID, which it must imbed into all HTML pages it builds.
  • the Composer executes any actions to fulfil the request generated by its Document, such as storing values of bound data objects. If the Composer also needs to change visual appearance of the Document, it submits to the Viewport Manager an Updategram script .
  • the updategram can range from minor corrections using appropriate Dynamic HTML calls to a full reload by means of document .write ( ) .
  • System triggers may in some cases cause other Composers to submit Updategrams even though the request did not come from their Documents.
  • the Viewport Manager assembles all Updategrams into a single script and passes the script back to OtsGateway . asp. The combined script is then loaded into the transaction server Gateway frame for execution inside the client browser.
  • Composers are thus isolated from the asynchronous nature of the underlying HTTP protocol: that is, any command a Composer receives is guaranteed to have been generated by the latest version of the Document this Composer had posted.
  • a Document's Composer can in principle write its output into a server-side file and direct the client browser to load this file by calling location. replace ( ) from the updategram script. If the file is an HTML file (rather than ASP) , the browser can in some cases cache it on the client hard drive and save a network transfer. Nonetheless, this practice is discouraged for two reasons. First, writing a server side file slows down the server, especially if multiple clients do so. Second, the Composer would not know when the file has reached the browser, and may continue to receive commands from the previous ("ghost") versions of its Document.
  • US-defined SessionID is insufficient for transaction server session identification.
  • two browsers on the same computer represent separate sessions, both when one had been created by a script call from the other, and when the two were opened independently by the user. Any
  • BrowserlD which is assigned at the time of first hit and which the browser maintains in a page variable.
  • the page variable is lost if the user leaves the site and later navigates back, however, the session can still be identified because a request fired from the history stack, as any request, carries the BrowserlD.
  • BrowserlD is also restored if the page is pulled out of the client cache, in that case by the page's Onload handler.
  • the Composer can update HTML source, for example, by adjusting default value attributes of HTML controls, or by inserting script code to expand and populate the branches of a tree control . Nonetheless, the Viewport Manager must sometimes reload a Document whose state has changed since it last posted a request. Even if the Document were to immediately post its current state, the request might get stuck somewhere in the Internet and become outdated as the user keeps typing into the page. The user can also spontaneously navigate out of the site, in which case even the Viewport Manager receives no warning of the pending reload.
  • OtsSaveState (DocID, varName)
  • the second parameter is a string that evaluates to a fully qualified frame-scope variable name with an atomic type, for example "myForm.myField. value” .
  • the name furthermore, must be in the plain dot-separated format (i.e.,
  • CSF Once submitted to CSF through OtsSaveState, the variable is monitored for the lifetime of the Document. Specifically, CSF automatically fetches its value whenever the Document is shuttled out of the browser for any reason, and automatically restores it whenever the Document is shuttled back in. The CSF scripts would not crash if subsequent updates eliminate the variable from the Document, however, the item would remain in the master frame array. It is usually unnecessary for a
  • the optional mask parameter is a regular expression which the caller can use to narrow down the set of variables included in the output .
  • Netscape has been found to simply not call the OnUnload handler in cases when the frame hosting the Document is itself being destroyed at the time the Document is unloaded, or soon afterwards .
  • Javascript's window. open ( ) apparently allows to run the entire session in a new window without any browser toolbar, however the history list would still be available to the user through Alt/Left-arrow.
  • rumors have been circulating that it might be possible to programmatically disable or flush the browser's history list.
  • sequence numbers to identify requests fired out of the history list.
  • the Web UI involves frequent dynamic changes to frames and the frame structure, causing, despite our best efforts, frequent reloads and screen flicker, especially with an overloaded server or slow network connection.
  • the web site may not look as attractive as some Microsoft Web pages that seem to open up additional screens instantly. Microsoft achieves this elegance by downloading all data at once but initially hiding most of it using Dynamic HTML. Server/Synchronizer Model
  • the Synchronizer enables all the objects in the
  • the Synchronizer maintains a list of Workflows and Rules which have registered an interest in particular events. When an event occurs the
  • Synchronizer invokes the interested BWs and Rules.
  • the Synchronizer establishes an anonymous subject-observer
  • the synchronizer abstraction is comprised of several collaborating objects. The important ones are described below.
  • Events are flyweight objects that are used throughout the transaction server.
  • An event consists of a set of fields used to describe an incident that is of interested to the transaction server. Every event has standard fields such as category (where it originated) and ID (what it describes) , in addition to a special info field.
  • the Event info is an opaque, "black box" VARIANT field that can store anything. If the info field is of a certain format, the Synchronizer can use it; otherwise, the Synchronizer ignores the event info. Many events are used by various objects in the transaction server but never reach the Synchronizer at all. Event info
  • an Event's info field is a SAFEARRAY
  • the Synchronizer might use the event to perform interesting work such as firing Workflows or queuing Steps.
  • the Synchronizer uses the following procedure to determine whether to use the event info:
  • the SAFEARRAY must be one-dimensional with elements of type VARIANT.
  • the names may be interned BSTRs or raw BSTRs . Although interning the standard tokens is strongly recommended.
  • Synchronizer interpreted VARIANTS in the safe array must be of type BSTR with one of the following names: • ⁇ session: a pointer to the controlling IUnknown of a valid contact channel session interface.
  • the Ssession element - at a minimum - should be in the info- SAFEARRAY field. If it is not, the workflow will still be able to run, but it will not have a default session. Other entries are optional. If provided, the Synchronizer will preload the Context with variables, or it may route the incoming event to be dispatched in the session matching a station ID that the event specifies.
  • the framework includes a class, transaction serverEvent, which eases the task of creating the SAFEARRAY for the particular IEvent .
  • Workflows are started by the Synchronizer, usually in response to an Event received by a Peripheral (Web, Email, etc.).
  • the Peripherals involved merely notify the Synchronizer of significant events; they may or may not know that a Workflow will run.
  • the Event carries two kinds of information: • Identification: matched by one or more Selectors; this includes the Event scope, instance and ID.
  • the Identification portion of the Event is described elsewhere in this document.
  • IIS fires a short (usually one- liner) ASP file which invokes the Router
  • the Router prepares an Event (by creating an HTTPSession and packing an interface to the IC2Session into the Event's Data field) and sends the Event to the Synchronizer.
  • the Synchronizer runs the Event down its list of Selectors, and the Selector that matches this Event has the SEL_PROCESS style.
  • the SEL_PROCESS handler looks at the Event's Data field to get the interface to the web session, creates a Context for the Workflow, and starts the Workflow.
  • the Router is waiting for a response from the Synchronzer.
  • the BW will either end, or it will perform a Render operation, waiting for a response from the channel on which the Render occurs. In either case, the Synchronizer returns and the Peripheral that sent the message continues accordingly.
  • the data portion of the Event is a VARIANT. This data is used in different ways by different Selectors or event handlers. It can be a single data item, such as a -string or pointer, or it can be a SAFEARRAY collection of data. In order for the data to be used properly, the Event sender and the
  • Event handler must agree how to interpret it .
  • the only restriction is that COM must be able to marshal the data.
  • the information in the Event will be the Context associated with the BW that fired the Event. This will be evident in Table 5 below, which shows how some of the Synchronizer' s standard event handlers use the Event data field:
  • the peripheral prepares an Event by setting a Scope, ID and Name, and creating a SAFEARRAY of VARIANTS to stuff into the Event info field. If this were happening on the Web channel, the Scope would be Web Contact Channel, the ID would be 2 (start new session) and the Name could be anything (as long as the Synchronizer has a selector matching this name) .
  • the SAFEARRAY would contain the controlling unknown of the channel object that would handle this session. It might also contain the controlling unknown of properties that the web channel wanted to have preloaded into the context of the workflow to be executed. When the channel sends the event to Synchronizer, it (that thread) blocks, waiting for the Synchronizer to respond.
  • the Synchronizer receives this event and it matches a selector whose style is SEL_PROCESS . That selector says to run the Foo workflow, so the Synchronizer creates a context, adds any variables specified in the Event info SAFEARRAY to the context, attaches the Event info Session to the Context, and starts the workflow. Meanwhile, the thread in the channel is still waiting for a response .
  • the workflow begins running and reaches a point where it ends (unlikely) , or it encounters a blocking Render action (more likely) . So the workflow ends or suspends, which in either case returns a result code to the Synchronizer, which returns this result code to the channel.
  • the workflow If the workflow is suspending upon a blocking Render (the usual case) , it gives the channel a "handle" before it returns. The channel treats this handle as an opaque item and uses it later as described below.
  • the channel upon returning from the Synchronizer call, checks whether the workflow posted any information to be rendered (it usually will) . If so, it calls the Composer to render the information, and the user sees the initial screen of the workflow. Reentering a Running (Suspended) Workflow
  • the ID is 3 (reenter session) and the Name is not needed.
  • the channel packs into the event info field the handle that the workflow gave the channel when the workflow first called Render.
  • the Synchronizer receives the event and it matches a single common "reenter" selector.
  • the selector style is REENTER, so the Synchronizer unpacks the event info field
  • a peripheral receives an event that must be routed to a user who is already running workflows on the transaction server. This is unlike the above cases because there, the peripheral that reported the event also provided the session used to handle the event. Here, the peripheral reporting the event expects some other session to take care of it. For example, imagine a CTI system where an agent uses his web browser to log into transaction server and start working, and while he is working calls come into the CTI switch and the CTI Peripheral needs to tell the Synchronizer to push a screen pop out to a particular agent's browser.
  • the Peripheral starts by preparing an Event.
  • This Event will have a Scope of Telephony Contact Channel, an ID of 5 (delegate handler), and any Name.
  • the CTI Peripheral will use a SAFEARRAY for the Event info field.
  • this SAFEARRAY will contain a CallObject BIO (describing the incoming call) to be preloaded into the Context, a Station ID describing the station to which the event handler should be routed (currently, the Station ID is the fully qualified phone number of the agent to whom the call was routed) , and the controlling unknown of a Session the workflow can use to carry out activity on the call (forward, hold, etc.) .
  • the Synchronizer will choose that session
  • the event's info field will also have a CallContact BIO which describes the current call as well as a CallContactSegment BIO which documents the current contact segment .
  • the CTI Peripheral sends this Event to the Synchronizer and it (the CTI Peripheral's sending thread) waits for a response.
  • the threading model of the CTI Peripheral is designed so that none of these waiting threads block other call activity from happening.
  • the Synchronizer receives the Event and finds a matching Selector.
  • the Selector style is SEL_PROCESS_ROUTE . This causes the Synchronizer to grab the Station ID from the Event info SAFEARRAY and store the Selector's handler (workflow) name in the Synchronizer' s information record pertaining to this station.
  • the Synchronizer then creates a new Context and notifies the Listener object living in the browser of the agent at the given station (the listener' s address was provided to the Synchronizer when the agent logged in) .
  • This notification includes the controlling unknown of the new Context, which the Listener receives and treats as an opaque handle.
  • the Listener opens a new browser window on the agent's screen and returns to the Synchronizer.
  • the Synchronizer thread then returns to the CTI Peripheral, which has now completed its role in processing this event.
  • the new browser prepares another Event and sends it to the Synchronizer.
  • the new Event has Scope Web Contact Channel, ID 6 (delegate browser) , and the Context handle packed into the Event info field.
  • the Synchronizer receives this event and it matches another Selector whose style is SEL_PROCESS_PUSH. This Selector's handler grabs the Context handle and workflow name that it remembered from the previous Peripheral event, attaches it to the session at the given station ID, and starts the Workflow.
  • the workflow renders, it creates a screen in the newly created browser, causing a pop-up on the Agent's screen.
  • Event info SAFEARRAY of VARIANT containing: Station ID
  • CallContact PBIO ContactSegment PBIO Synchronizer matches event to a Selector:
  • Selector Scope Telephony Contact Channel Selector Name: NULL (matching event) Selector ID: 5
  • Selector Style SEL_PROCESS_ROUTE Selector Handler: Workflow name Synchronizer goes to the lineage corresponding to the station ID, gets the Listener interface. Synchronizer stores the workflow name (selector handler) with this lineage in the session list.
  • Synchronizer creates a Context for the new Workflow, builds a VARIANT handle from the Context.
  • Synchronizer adds this Context to the lineage using IWorkflowRegistry .
  • Synchronizer sends a message to the Listener, including the handle .
  • Event Scope Web Contact Channel Event Name: NULL (or anything) Event ID: 6
  • Event info SAFEARRAY of VARIANT containing: VARIANT handle (provided by Synchronizer)
  • IC2Session (of new web session) Synchronizer matches event to Selector: Selector Scope : Web Contact Channel Selector Name: NULL (matching event) Selector ID: 6
  • Synchronizer finds the lineage associated with the incoming event's VARIANT handle. Synchronizer starts the workflow whose name was stored in step 5, using the web IC2Session interface provided by the incoming event .
  • Business Rules are conditionals. They check a condition and return a status to their caller. One can think of them as read-only, or passive Operations. A Rule queries information in a BIO, optionally performs some calculation, and returns information to the client. Business Rules determine application behavior. A Business Rule is a condition used to determine the behavior of an activity within the system. Business Rules determine (indirectly, but ultimately) to which Step a BW will jump next; they validate input accepted from Peripheral sources; they determine whether a given Operation is to be taken, etc. If no Business Rules are present to determine which Step is the next Step, the BW will jump to its next "required” step. If all its required steps are complete, the BW will terminate and return to the next nesting level. Business Rules consist of three parts:
  • Qualifiers are used to determine whether a Business Rule is relevant in a particular combination of BW Step and Context. These are optimized for speed and acted on as a group for fast evaluation.
  • An example of a Qualifier would be a permission setting. In the case of a "default next step" Business Rule, the Qualifier simply identifies the step in the BW to which the rule applies .
  • Success Conditions are used to determine whether a qualified Business Rule should permit the triggering Operation to continue. If the Success Conditions end up as TRUE, the
  • Context Effects are settings the Business Rule alters in the Context on success and/or failure. One typical Context Effect would be to change the next Step for the BW.
  • a BW Step fires an Operation.
  • Business Rules are reusable. Business Rules may be reused across BWs, and therefore a given Business Rule is never to be considered to belong to a single BW. Business Rules exist independently within the Process Manager. A Process uses Rules, but it does not own them.
  • Simple business rules are those that are suitable to be cached in the interface logic on a UI . This facilitates the ability for users to have conversations in the UI while offline, but requires that the rules make their decisions based only on that portion of the Context which can easily be cached within the UI .
  • Complex business rules are those that require contact with the server. In order to maintain complete delivery channel independence, the same rule may be realized as both simple (in the UI) and normal (in the server) . For example, suppose an application must verify that a customer's address has a valid ZIP code. A web GUI might use a simple Rule to check that the ZIP code has 5 (or 9) digits, and BW might use a normal Rule to check again.
  • the framework being a meta-data driven system, uses strings extensively.
  • Object class names and instance names, and property names represent some of the key areas in which the architecture depends on efficient string management .
  • the transaction server has a singleton object
  • Translator which maintains a hash table of all the strings being used in the system.
  • the hash table stores the strings in a compressed format and provides lookups in near constant time, regardless of the size of the table.
  • Every object that uses strings either receives them already interned, or it interns them.
  • the intern process returns to the object an ID for the string.
  • the object hangs on to the ID and destroys/frees the original string it had created.
  • the mapping from IDs to strings is a "bijection," which means objects can compare string IDs (rather than strings) for equality. If the IDs match, the strings match. If the IDs do not match, the strings are different.
  • the object needs the actual string it sends the Translator a getString message and receives a copy of the string.
  • the Translator will provide the string in any format the client desires - currently either multi-byte or Unicode. This returned string is only a copy and can be freed at any time, whenever the client is done with it. At first glance one might think that copying the strings in this manner would represent a performance cost. But there is no such performance degradation - indeed, it is a performance improvement - primarily for three reasons :
  • Transaction Server provides a uniform mechanism for translating application messages
  • phrases to the language corresponding to the locale specified in each Workflow' s environment.
  • the translation mechanism does only that - translate phrases.
  • Lookup resolution processing for properties with domain value matrices
  • the message IDs or names are mapped to phrases by a dedicated singleton object in the transaction server (the Translator) .
  • This translation may run in the opposite direction - sometimes a phrase may be provided by the user and must be reverse translated into the appropriate message ID (for example, in the case of a property with a domain matrix) .
  • the Workshop enables the business analyst to define new message phrases and assign message IDs to them, and to update, insert and override translations for any message phrase.
  • phrase IDs Previously, for simplicity, we have mentioned language IDs. However, language is only one of many possible dimensions that can be used to resolve a message ID into a phrase. We might want to use different translations for different customers, tenants, or other permutations or states of business data. In general, we have multiple orthogonal dimensions upon which the resolution of a message ID to a phrase relies. Phrase translation dimensions are stored in table s_qualmeasures, which is used to store all sorts of standard naming information.
  • Translator finds the best matching phrase.
  • the translator guarantees to always provide some kind of phrase in return, even if it must return the empty phrase.
  • the translator maintains a cache table of phrases that it reads from the database when it initializes. In the database, many different phrases may be provided for a given message and scope ID, as long as they have different language IDs or precedence (precedence is used to override OTB messages without modifying them) .
  • the client is not required to specify the language ID (though it can) ; normally, the Translator chooses a language appropriate to the client's environment.
  • the client provides the Translator a phrase ID.
  • the Translator does:
  • the appropriate phrase may depend on locale, language, tenant and other conditions known only at runtime and which may or may not be specific to a given client or use server defaults .
  • Consumer objects who want application phrases will invoke methods on the Translator object to obtain the phrases. Consumers will pass in a phrase name or phrase ID, optional translation dimension information (referred to above as "language ID” for simplicity, described in detail below) , and will receive back from the Translator the appropriate phrase (in the form of a BSTR or an interned string ID) .
  • Phrase translation dimensions describe conditions for selecting the appropriate phrase for a given phrase name or ID. The simplest and most obvious way to do this is using a one- dimensional system of "language". For example, phrase 17 maps to "My name is” in English, but maps to "Je m'appelle” in French. However, this one-dimensional scheme may be insufficient for complex business applications. For example, what if the application wants to have formal and informal translations? The English version of the above phrase might not change, but the French version might change to, "Mon nom est”. Further, what if different translations are needed for different tenants using the same application under a hosting environment (say, Wells Fargo and B of A sharing a call center for hosting customer service) . Now we have at least three dimensions for translation (language, formality, tenant) .
  • the framework enables business analysts to design phrase translation dimensions with no arbitrary limits to the names or number of dimensions.
  • the Translator uses dimension Handles, which are 4 -byte integers that represent a particular, pre-validated, dimension N-tuple.
  • Each client object invokes a method on the Translator to resolve its dimension N-tuple once at runtime, to get a dimension handle. It then uses this handle in subsequent
  • a given dimension N-tuple will always have the same dimension handle for the up-time of the transaction server, but it might be different the next time the transaction server is booted. This is why clients must resolve the dimension N-tuple to a dimension handle at least once at runtime; it cannot store the handle to persistent storage and use it later with a different instance of the transaction server.
  • phrase translation dimensions are entirely optional. Clients may resolve phrase IDs or names to phrases without using translation dimensions. When clients do this, they get messages translated in accordance with the server default policy, which is set in meta-data.
  • the Translator uses a series of cross- referenced tables to maximize the speed and minimize the storage requirements of translation.
  • phrase table is a table consisting of two 4 -byte integer columns. It is implemented as an array of structures, where each structure has two 4-byte integer fields.
  • the first column of the phrase table is an index (either a phrase ID or the interned string ID of a phrase name)
  • the second column is the interned string ID of the phrase string.
  • the phrase table is built by the Translator upon startup, does not change at runtime, and is sorted along the first column. Every translation dimension handle will have two corresponding phrase tables - one for phrase ID / phrase, the other for phrase Name / phrase .
  • Translator does not accept translation dimension N-tuples in their raw form for translating phrases. Instead, it requires the caller to provide a phrase translation dimension handle.
  • the caller obtains this handle by resolving a raw N-tuple with the Translator.
  • the Translator uses a Translation Dimension
  • the translation dimension table consists of four columns:
  • strings in the array are the names of the dimensions that comprise the N-tuple .
  • the above dimension example would be represented as (3, [English, Formal, Wells Fargo], [ptr to ID table] , [ptr to name table] ) in the translation dimension table.
  • the client When a client resolves an N-tuple to a handle, the client gives the Translator an N-tuple and the Translator returns the corresponding handle.
  • the handle is the index of the row in the translation dimension table that corresponds to the client's N-tuple (though the client treats it as an opaque data type) . This index is zero-based, and zero is reserved in the translation dimension table for the server default translation dimension N-tuple.
  • the caller provides a phrase ID and a translation dimension handle.
  • the Translator uses the dimension handle as an index into the translation dimension table to find instantly the pointer to the appropriate phrase table.
  • the Translator finds the row in the phrase table corresponding to the caller-provided phrase ID (or name) and gets the interned ID of the phrase string.
  • the Translator returns this string to the caller. Lookup Resolution Processing Overview
  • the first is when we must select one element from a discrete, predefined set of values. For example, a "status" selector might be "open,” “closed” or “pending”. This is called a static lookup resolution.
  • the second is when we must select one element from a dynamic list of data. For example, a selector that enables the operator to choose a customer from a dropdown list. This is called a dynamic lookup resolution. In either case, they're called lookup resolutions because it would be (for many reasons) bad to store the selected string. At best, it is inefficient. At worst, it is ambiguous - more than one customer might be named "John Smith”. Additionally, there may be translation issues.
  • the same string may use different identifiers. For example, "open" (or
  • the Factory Control is responsible for two tasks:
  • All transaction server factories i.e. any object that implements Itransaction serverFactory
  • the Factory Control CoCreates all transaction server factories and keeps a reference to each until IFactoryControl shutdown () is called. IFactoryControl shutdown (), calls shutdown () for each transaction server factory. This causes subsequent calls to transaction server factory methods to fail . Note that clients can still CoCreate these factories but their method calls will fail with transaction server_E_NOT_FOUND .
  • Pre-loading transaction server Factory Caches Since all transaction server factories use caching to optimize creation speed, it is desirable to pre-load these caches in certain situations (e.g. making the initial start-up screen appear faster, etc.). These situations will vary between different installations so configuring factory cache pre-loading is essential.
  • the Factory Control supports configurations via tables in the Business Model Repository (see the Business Model Repository section below for more information) .
  • the first case is the usual case (especially at a customer site) , and a Server administrator can use these various configurations to experiment with different pre-loading schemes.
  • a Server administrator can use these various configurations to experiment with different pre-loading schemes.
  • having many configurations in a database is the only way to enable different Transaction Servers to pre-load differently.
  • Each transaction server has a default configuration that is specified via a registry setting. Upon initialization, the
  • Factory Control uses this registry setting to load the transaction server's configuration for pre-load.
  • This registry setting can be administered via the transaction server console application (i.e. transaction server console writes the default configuration value into the registry and transaction server
  • Factory Control reads it on bring up) . Specifying What Gets Pre-loaded
  • the Factory Control is designed to support various actions. The only action we currently use is pre-load, but we are free to add more actions in the future as needed. See the
  • Microsoft Exchange 5.0 Developers need objects that support capabilities beyond simple Messaging and into the areas of Calendaring, Collaboration, and Workflow. Such capabilities can simplify the development of heavy-duty resource-scheduling applications requiring information to be displayed through a calendar.
  • Microsoft has replaced its Active Messaging library with Collaboration Data Objects (CDO) . These CDO ' s are available in a library known as CDO 1.2, which ships with Exchange Server 5.5 and Microsoft Outlook 98.
  • CDO Collaboration Data Objects
  • CDO 1.2 is a scripting-object library that developers can use to design applications on both the client and server-side. It's an in-process self registered COM server which is language independent and can be used with many programming languages, e. g. Microsoft Visual Basic Scripting Edition (VBScript), JavaScript and many more, sometimes even C++. CDO 1.2 can be used to build solutions, which are running on client- or server-side. It supports multiple concurrent sessions (according to Microsoft -1,000 users per server) . You can build client applications or ActiveX run-time controls, which are logged-on to Microsoft Exchange Server with another account that is currently logged-on with Microsoft Outlook
  • the Microsoft developers have used the CDO 1.2 HTML Rendering Library to build the Microsoft Outlook Web Access .
  • logon authenticated or anonymously to a Microsoft Exchange Server You also have the choice to logon authenticated or anonymously to a Microsoft Exchange Server. The reason for an anonymous logon could be, to show all items of a public folder at a Web site without prompting the user for a logon.
  • CDO 's are available in a library known as CDO 1.2 (included in Microsoft Exchange Server 5.5) and CDO 1.21 (included in Microsoft Outlook 98 and Microsoft Exchange Server 5.5 Service Pack 1), which replaces the Active Messaging object library version 1.1.
  • the first version will be CDO 2.0, the follow-up version of CDONTS.
  • CDO 2.0 will be included in Windows NT 5.0 Server and Workstation.
  • CDO 2.0 is already available as a beta with the Microsoft Windows NT 5.0 Beta 2 for all members of the Windows NT 5.0 beta program and all MSDN subscribers.
  • CDO 2.0 will provide basic messaging services, such as send e-mail, post discussions/news, support for the SMTP and NNTP protocols and inbound protocol events and agents. However, it does not provide access to mailboxes.
  • the second version will be CDO 3.0, the follow-up version of CDO 1.2.
  • CDO 3.0 will be included in the next release of Microsoft Exchange Server. According to Microsoft, a first beta of CDO 3.0 will not be available before the mid of 1999 and the final release will come with the next version of Microsoft Exchange Server (code name 'Platinum'), 90 days after the release of Microsoft Windows NT 5.0.
  • CDO 3.0 will have a different object model than CDO 1.2 and will include extensions to the OLE DB and ADO programming model. It will be a superset of CDO 2.0 and will enable new functions, such as voicemail, fax and pager support. Also included will be enhanced scheduling, task and contact management and support for MIME headers (including S/MIME) and MHTML (HTML message bodies) . Also advanced features for building collaborative application development (e. g. voting buttons and message flags) will be included. Last but not least, a future release of Microsoft Outlook will also support CDO 3.0.
  • the transaction server uses Collaboration Data Object
  • CDO library to provide Mail API (MAPI) support MAPI objects representation in CDO is shown in Fig. 5
  • Fig. 5 shows MAPI objects represented in the CDO object model.
  • the top object on CDO is a Session object 510.
  • Session object 510 contains session-wide settings and options. It also contains properties that return top-level objects such as CurrentUser. It's the only object that can be created directly from application.
  • the Logon method should be invoked to initiate a session with MAPI . No other activities with CDO are permitted prior to a successful logon, even getting any other method or property of the Session object. An attempt to access any programming element prior to a successful Logon results in a CdoE_NOT_INITIALIZED error return .
  • Email Manager which is system- wide MTS-hosted FT/FTM singleton. It provides MSMQ connection/notifications, messages dispatching and startup/shutdown sequences. It also provides coordination between e-mail peripheral system and peripheral script factory.
  • Email Manager exposes itself to the system through MTS-hosted proxies, however it supports transaction serverGlobalSingleton functionality to reduce thread switching for subsequent calls. Every message is handled by another FT/FTM object EmailSession. This object combines email-client functionality similar to the standard email client like Reply, Forward, CreateNew etc as well as IC2Session interface. The instance of EmailSession object wraps every message proceeding.
  • Email Manager is notified about incoming message events by MSMQ notification mechanism.
  • Exchange Event Agent This Exchange Agent module is implementation of the Microsoft Exchange Custom Agent. It supports IExchangeEventHandler interface so Exchange server can be configured to notify this object about events. For the information about how to configure the Exchange Event Agent see the installation guide.
  • Email Manager supports thread pooling.
  • Email Manager creates fixed number of threads. This number is specified in registry and is set by transaction serverConsole program, section Server Configuration/Email Throttling.
  • transaction serverConsole program section Server Configuration/Email Throttling.
  • the idea is that significant part of email-related peripheral and workflow spend time waiting for I/O operations like mail/database access. This means system is able to proceed few messages in different threads concurrently. The only limitation is that when number of such threads grows the thread-switching redundancy should be considered. Therefore number of concurrently proceeded messages is individual per computer configuration and is determined by factors like number of CPUs, network traffic and should be set during tuning procedure.
  • Email Manager creates thread pool
  • stage 605 The pool size is then defined in registry and set by transaction server Console application (stage 610) . To change the pool size, the transaction server has to be restarted.
  • pool thread starts pumping Windows message loop waiting for the synchronization event raised by MSMQ notification object (stage 665) . By obtaining the event it checks global data pointer for transmitted data and sets another event indicating "data is accepted" which lets the MSMQ notification object to restore the notification mechanism.
  • Email Manager' s main thread also creates special thread, which provides MSMQ lookup (stage 615) .
  • the transaction server MSMQ can be found by queue GUID.
  • the transaction server email system can work against multiple Exchange servers, which means one MS queue per server. Email Manager maintains list of these queues. Per each queue there is corresponding notification object created.
  • Email Manager lookup thread performs lookup every 30 seconds looking for queues with specific attributes like GUID, name, label, etc. For each queue found, the thread creates a MSMQEvent object that provides Connection Point interface (stage 625) . Then it advises Arrived and ArrivedError methods to MSMQEvent object. This provides MSMQ notification event to notify Email Manager of the message posted to the MSMQ (stage 630) .
  • the MSMQ mechanism provides high fault-tolerance to the entire system. When the Exchange server receives a new message transaction server shouldn't be activated. MSMQ will guarantee posting message's information into MSMQ. When the transaction server email system is started, it will be notified immediately if there are messages waiting (stage 635) .
  • MSMQ notification should be restored manually.
  • the connection point procedure should call RestoreNotification method on MSMQEvent object (stage 640) . This also means the system should work in configuration many- to-many (many transaction server email systems against many Exchange servers) .
  • Email Manager For each MAMQ notification, Email Manager extracts email message information from the queue and set “Data ready” event. Then it waits for "Data ready” event which will be set by the thread that accepted “data ready” event. Such event-driven mechanism provides first available thread will peek up the message .
  • pool thread For each "data ready" event received, pool thread co- creates EmailSession object which will be dedicated to the message received (stage 645) .
  • This object implements IC2Session interface as well as IemailSession, which provides basic mail actions like Reply, Forward, Delete.
  • EmailSession object performs peripheral actions (stage 650) . This process is further described below.
  • email message might be sent to the Synchronizer (stage 655) .
  • the Synchronizer can render message on the E-mail contact channel (stage 660) . If email channel is the default channel for the workflow, the EmailSession object will be reused for rendering. If IC2Session interface wasn't provided to the workflow context or it belongs to another channel, EmailSession object will be co-created for rendering purposes.
  • the rendering mechanism is very similar to the Peripheral script processing: the difference is that context "Message" BIO is used instead peripheral script. Please refer below to Email Peripheral design and implementation.
  • EmailSession object released and pool thread restores messages loop pumping waiting for "data ready" event (stage 665) .
  • Peripheral scripts will be re-implemented to be a JScript or VBScript.
  • the current implementation is that script is just a linear sequence of text lines containing EmailSession object methods and properties.
  • table that defines script can be use for representation of any linear text line sequence, the only module, which uses these tables is the email system (Manager+EmailSession) .
  • the m_selector table contains selectors for Email Peripheral. Selectors, which belong to the ⁇ email' domain, as specified in mx_sel_seldomain table, will be loaded by EventHandlerLoader module per EmailManager request. In this case, k_handler points to the primary key k_handler in m_handler table specifying the Peripheral script (handler) name. These selectors are the same as standard Synchronizer selectors except the following:
  • Email selectors have either style STOP or style CONTINUE;
  • Email selectors contain peripheral handler index in k_handle column of m_selector table.
  • Every peripheral handler corresponds to the particular script that contains in m_handlerinfo table (cross-linked with m_handler table by mx_handler_hinfo) .
  • the sample of m_handler table is shown in Table 7.
  • the Peripheral script is defined by mx_handler_hinfo table which provided normalization for many-to-many links between m_handler and m_handlerinfo tables. As a result, the script would take the form:
  • Email Manager loads the Peripheral Selectors list using Synchronizer factory/loader (stage 705) .
  • Email Manager calls it to proceed first selector with current message (stage 710) .
  • EmailSession checks whether selector matches the message's event (scope, id, instance name) . If selector matches, the corresponding handler will be processed (stage 715) .
  • EmailManager is asked for handler (script) , so it calls EHFactory (stage 720) .
  • EHFactory checks whether script is already cached and either returns the script (as an active bag) or calls EventHandlerLoader to load the script (stage 725) EventHandlerLoader loads the specified script from m_handlerinfo using mx_handler_hinfo (stage 730) .
  • the loaded script is an Active Bag object.
  • Each of its entries is a SAFEARRAY of type VT_BSTR. The entry name is defined by first found text line which starts with "@@" prefix. Until subsequent entry starting with @@ is not found, the current active bag entry is filled with script lines. Then new active bag entry is created and filled with scripts such as the ones described below (stage 735) .
  • Email session gets the loaded script and processes it as the follows (stage 740) .
  • the name of the current Active Bag entry is interpreted as IDispatch method invocation.
  • the method "Reply” will be invoked on the EmailSession object (stage 745) .
  • processing the script EmailSession object cannot interpret the text, it invokes Idispatch (stage 750) , which provides very efficient, flexible and extendable implementation.
  • the content of the SAFEARRAY which is an active bag value, is interpreted as the set of either method parameters or text line pairs, where first element is a Property name to set, the second parameter is the property value to set. See script samples below.
  • the control is passed to the following selector (stage 755) . If the script succeeded, the control is passed to the following selector only if the current selector has "CONTINUE" style. If the current selector has "STOP" style, message processing is concluded.
  • Email manager calls next selector's handler, if any (stage 760) . If there is no more selectors to proceed, the Synchronizer is called (stage 765) . The peripheral part of email message processing is done.
  • a script containing the meta-data entry ⁇ Delete is interpreted as a call to the "Delete" method of the EmailSession object with no parameters.
  • a script containing the meta-data entry ⁇ Route Support is interpreted as a call to the "Route" method of the EmailSession object with parameter "Support”.
  • a script containing the meta-data entry ⁇ Reply ⁇ Append ⁇ ConversationID is interpreted as call to the "Reply" method of the EmailSession object.
  • the following line starts with ⁇ symbol which means property name to set.
  • the following line contains the property value to set, i.e. text ⁇ ConversationID.
  • property value starts with ⁇ symbol it means original message's property value. This means that original message ConversationID will be appended to the replied message's body.
  • Email peripheral script The general idea of email peripheral script is that it completely IDispatch-driven. EmailSession does invoke every method from this script on itself, along with the setting/getting the properties, however it does not interprets the script. The methods calling (as well as property access) is done by standard IDispatch mechanism. This will allow the EmailSession object in the future to aggregate any third-party dispatchable object to extend functionality in purely COM manner .
  • Telephony Contact Channel system For detailed information on the Telephony Contact Channel system, please refer to the document TCCS_Architecture.doc and TCCS_EventCases.doc for the architecture and the event use cases.
  • the primary purpose of TCCS is to implement peripheral level features. It makes no attempt to present the workflow to the caller via the telephony equipment .
  • the peripheral is responsible for delivering calls and providing basic telephony operations to the Agents.
  • the TCCS is exposed to the core with a startup manager:
  • CtiManager which is a proxy for the FTFTM singleton object CtiManagerIm.pl and the IC2Session implementor: CtiSessionManager .
  • the TCCS is divided into two distinct, yet cooperative sub-systems: the EventRouter and the ServiceProvider .
  • the EventRouter is divided into two distinct, yet cooperative sub-systems: the EventRouter and the ServiceProvider .
  • This system The sole responsibility of this system is to gather events from the vendor's middleware, perform first-level filtering and send them to Synchronizer. It maintains a collection of threads for each logged-in agent. Each thread is responsible for delivering asynchronous events into the corresponding agent's workstation. This allows a low-latency at the event collection module and ensures no event is lost while the thread is blocked by Synchronizer.
  • the Service Provider This is a collection of one or more service providers that are abstractions to the different CTI peripherals such as the
  • the entire framework is a data driven system of distributed objects.
  • the system itself consists of a small set of core classes, each of which differentiates at runtime into an arbitrarily large number of different objects.
  • the framework consists of a single class, BIO, but at runtime there may be hundreds of different BIOs in the system.
  • BIO basic-oxide-semiconductor
  • Step and Operation class there will be hundreds or thousands of different Steps and Operations running in a given system. This is what we mean when we say the entire framework is "data driven. "
  • a data driven system needs to have meta-data, and metadata is stored in a relational database.
  • the meta-data is a critical technological piece of the system, and was designed with no small amount of care and innovation.
  • the meta-data consists of approximately 125 tables normalized to Boyce-Codd 4 th form.
  • Loaders understand the structure of the meta-data; they generate the SQL needed to read the meta-data, then they denormalize the information into bags - normally, bags of strings.
  • Factories retrieve these de-normalized bags of strings from the Loaders and they use the information in the bags to build specific types (meta-classes) of objects. Since nearly all framework objects are stateless, most of the factories cache the objects they've created so they can be retrieved immediately in the future. In this case, the caching is particularly efficient, since because the objects are stateless, they don't even need to be copied - all clients merely receive a pointer to the one instance of the object that lives in the cache, and none of the clients knows or cares that other clients may be using the same object at the same time.
  • the client object When a client object needs a server object, the client object goes to the Factory for the server object and invokes "create”. Upon success, the Factory returns to the client object a pointer to the object requested. Otherwise, the
  • the Factory goes to the MasterFactory (a framework-wide singleton) and asks for an object of the specified type.
  • the MasterFactory will go to the appropriate Loader and get a Bag describing the requested object, then return this Bag to the Factory.
  • the Factory will unpack the
  • the Factory gives the client a reference to the object, and it adds the object to the cache.
  • the solution to this dilemma is to recognize and take advantage of the fact that the objects being created by the Factory are all data-driven variants of the same COM class object.
  • the Factory When the Factory has to create a non-cached object, it can immediately put another COM class into the cache. That way, if another thread comes along asking for this object, that thread can get a reference to the COM class in the cache, instead of having to recreate the object.
  • the client got an uninitialized COM class from the cache, if that client tries to use the object it just got from the Factory, it will not work. So we have solved one problem - Factories won't create duplicate objects - but introduced a new problem - objects must be protected so they can't be used by a client until the objects are initialized by the Factory.
  • Every such object will have an interface that includes an init method. This is used by the Factory to stuff the object with the meta-data that distinguishes it from other objects of the same COM class. Every object will have a special internal semaphore which permits "one writer, multiple reader” access, let us call this the "init lock”.
  • the object's constructor or ATL' s FinalConstruct
  • it grabs exclusive access to the init lock which locks its runtime internals from use.
  • nonexclusive access which will block and wait for any pending exclusive access to clear
  • any threads that enter the object after it is created, but before it is initialized will block until the object internally releases its own init lock.
  • the Factory is busy gathering the data needed to initialize the object.
  • the object initializes itself (while these other threads are blocked, waiting) , then the object releases the init lock, which opens the floodgates and allows all pending threads to being execution in the object.
  • the Factories are protected from multiple clients asking for the same object at the same time.
  • the users of objects created from the Factory are protected from crashes that would occur if uninitialized objects are used. And all this protection is done without wasting CPU cycles, memory, critical sections or other forced single-threading mechanisms .
  • MTS will shut down the package hosting the framework objects if that MTS package does not have at least one instance of an object created. has a service that resolves this problem.
  • This service like other services, starts at system boot. It creates an instance of the framework's key Singleton objects (Translator, Synchronizer, etc.), and holds onto them until the service is stopped. This guarantees there will always be at least one instance of these objects running, which prevents MTS from shutting down the package.
  • the first problem - objects which point to each other - can be resolved by shutting down objects in a certain order. That is, ensuring that the other objects are release before the some objects.
  • the second problem has no simple solution. Something has to break the reference cycle before the system is shut down.
  • Requirement 1 Release Objects in the Proper Order
  • the transaction server Service will shutdown certain objects in a given order.
  • the order is as follows :
  • the shutdown logic must first ensure that transaction server is in "idle” state, with all workflows terminated, all contact channel sessions closed, and so on. To this end, transaction server Service may instruct certain critical transaction server components to reject any further client requests. By the time the system reaches idle state, most transaction server objects would have been released. The system then shuts down the remaining objects as described below.
  • MasterFactory caches pointers to Loaders
  • MasterFactory must shut down before any Loaders shut down.
  • Factories cache pointers to objects, the Factories must shut down before any of the objects in the cache. For example, StepFactory must shut down before any Steps are destroyed.
  • Synchronizer since any object may use Synchronizer or Translator, and Synchronizer may use Translator, Translator must be the last object in the system to shut down, and it must be immediately preceded by the shutdown of Synchronizer.
  • the caches in which objects are stored must deinitialize their objects, but the caches do not know anything about the objects they are storing - if they did these caches would not be universally reusable. So each cache must be able to determine whether its object support de-initialization, without knowing what kind of objects they are. This is a perfect application for 00 interfaces.
  • the framework includes an interface, IShutdown, which contains the deinitO method. When a cache is destroyed, it queries each of its objects to determine whether the object supports the IShutdown method. If it does, the cache invokes deinitO on the object before releasing it. If not, the cache merely releases the object.
  • any object that holds pointers to other objects, and allows reference circles must implement the IShutdown interface - and in its implementation for the deinitO method, the object must release all of its pointers to other objects.
  • Requirement 3 Anticipate MTS Shutdown Before it happenss To address point (3) , we must know when the last MTS object has been released, so we can initiate our own shutdown before MTS kills our process. To do this, every object administered to MTS (not just hosted on MTS) will increment and decrement a global reference count. Since they all share the same counter, when it goes to zero all MTS objects have been released and package shutdown is imminent.
  • the code in the framework does not come from Rose 98 code generation. This is because the code generation features of Rose 98 are complex, difficult to use and hard to configure to produce the style of code we desire. It is easier to use the Developer Studio ATL/COM wizard to create a template COM object, then fill in the files.
  • Rose 98' s code generation capabilities are useful for generating code in one's local file system, for checking the effects and implementations of various UML semantics.
  • Rose 98 provides a system called path maps that are used when generating source code.
  • the path map for the architecture includes a variable that sets the directory into which generated source code is placed. Rose 98 will create subdirectories under this base directory matching the package structure of the model .
  • the directory structure of the source code is modeled after the package structure of the framework UML.
  • OOA/D paradigms such as dependency inversion (package A owns the interface that package B implements) , package dependency mapping and strict interface/implementation separation are designed into the model and reflected directly into the structure of the source code and build procedure.
  • the directory will also contain a project or makefile that will compile all the interfaces it owns.
  • Other packages that define implementations for these interfaces, depend on this package and import, include or reference the interface files. Since the directory structure of the source code matches the package structure of the UML, and the dependencies of the source code match the class dependencies of the UML, the order in which objects are built is straightforward and well defined. This order is reflected in the build procedure, the release cycle, and the very organization of the engineering department.
  • UML Model, Rose 98 Subunits and Logical Packages The Rose framework UML model is broken into subunits, one per package. Every package in the logical view comes from a separate subunit . Each subunit is stored as a separate Rose .cat file on the disk. The master Rose .mdl file maintains references to each of the subunit files so that the entire model can be loaded and edited seamlessly as if it came from a single monolithic file.
  • the packages represent relatively autonomous units whose dependencies are already tracked and analyzed, they embody a coherent and logical decomposition for the responsibilities of the engineers in the development organization .
  • packages are not broken down into functional areas. Rather, their partitioning is based on dependencies.
  • class A uses class B, then A depends on B .
  • the package that contains A depends on the package that contains B.
  • high level code normally invokes lower level code, this inverts the desired dependencies because we want the low level code to depend on the higher level code.
  • the lower level package is forced to implement an interface that the higher level package owns . This reinverts the dependencies to what we wanted - lower level code depending on higher level code - while keeping the desired dependency structure of the packages .
  • Interfaces are modeled as abstract classes containing no properties and consisting entirely of pure virtual functions.
  • Objects are modeled as concrete classes that implement one or more interfaces . Most of these interfaces also have a related object that provides a simple, yet complete implementation of the all the functions in the interface. This setup has two key benefits.
  • Inheritance is the means for interface reuse.
  • Aggregation is the means for behavior reuse.
  • An interface may not be derived from a concrete class, nor may it send messages, nor may it aggregate any other class.
  • An object may not be derived from other objects. Where an object extends or specializes the behavior of another object, it must aggregate that object and inherit its interface. Of course, it may inherit the interface publicly or privately.
  • Aggregation by reference must be aggregation of interface.
  • Aggregation by value must be aggregation of an object. Multiple Interfaces, One Object
  • ATL was designed mostly to simplify COM programming, it seems to be geared for a single-interface world where every object has exactly one unique interface. Thus, implementing true interface/object separation in COM using ATL becomes a deceptively subtle task.
  • the first (and simplest) case is when a single interface is to be implemented by many different objects.
  • a good, clean example of this in the framework is properties.
  • No property object has an interface of its own.
  • Each property object implements IProperty as its sole public interface. This way, a client can talk to a bunch of different properties without concern for their individual types (if the client wants to know the type of a property, it can use the getType method in IProperty) .
  • IProperty . idl There is a single IDL file, IProperty . idl, which lives in the BusinessData directory (because the BusinessData package owns the IProperty interface class) .
  • This IDL file defines only the interface. It does not define any classes or type libraries. Thus, it produces only an IID when it is compiled - no CLSID or type library. To make all this happen, the BusinessData directory has a project file called BuildlDL. dsp, which runs a makefile called BuildlDL.mk, which compiles the IDL files. This is true in general of all packages that own interfaces. Each property object lives in a subdirectory of
  • IDL file merely imports IProperty. idl for the interface definition, and adds its own class and type library.
  • IDL for each property object uses the same IID for IProperty, but builds a new type library with its own CLSID.
  • the class that implements the property object is derived from the IProperty interface, and its COM interface table includes IProperty and IDispatch.
  • Each property object has its own project file, and all this happens automatically when the property is built.
  • a single object can implement multiple interfaces in two fundamentally different ways. First, it can implement multiple independent, unrelated interfaces in parallel. Second, it can implement a single interface that itself is derived from another (or more) interface. These two cases are described separately below.
  • a good example of this is the CoreObject object. It has two interfaces, ICoreObject and ICoreObjectPrivate. These interfaces are separate and unrelated. Both of these interfaces are owned by the BusinessServer package, so the IDL files for each (ICoreObject . idl and ICoreObjectPrivate. idl) live in this directory and are compiled by the BuildlDL. dsp project. Each is a dual interface derived from IDispatch. The CoreObject object does not have its own interface. It implements these two interfaces owned by the BusinessServer package.
  • IDL file CoCoreObject .idl
  • this IDL file does not define an interface. Rather, it merely imports ICoreObject . idl and ICoreObjectPrivate . idl , and defines its own class and type library. In its IDL, it declares support for both interfaces, but picks one as the default (ICoreObject) .
  • the class that implements the CoreObject is CCoreObject. It is derived from both ICoreObject and ICoreObjectPrivate (using the IDispatchlmpl ATL macro for both) and has both interfaces in its ATL/COM interface map.
  • Interface Ic must include all the methods in Ip, as if they belonged to Ic. Thus the client can use the entire set of methods encompassed by Ic and Ip together, in the single interface Ic.
  • the object must also implement Ip directly, so a client can treat it as if it were an object of type Ip .
  • ISingleBag interface which is derived from IBag.
  • the ISingleBag interface inherits all the methods in the IBag interface, so the client can use it without needing an IBag.
  • any object that implements ISingleBag must also implement IBag, too. This way an object that supports ISingleBag can be passed around and used as if it were an IBag.
  • the top level interface in the inheritance chain (here, IBag) is derived from IDispatch. All its derived children are derived from it. For example,
  • ISingleBag is derived from IBag. Because COM does not support polymorphism, this means ISingleBag cannot also be derived from
  • IBag The fact that the ISingleBag already includes an IBag is not sufficient, because in order for the object to be fully polymorphic to an IBag it must present this interface alone to clients that don't know about ISingleBag interfaces. Of course, whether the client gets to the object through IBag or through ISingleBag is irrelevant because both interfaces hook up to the same internal functions.
  • the IDL for the SingleBag object imports ISingleBag. idl for its interface definition. It declares a coclass that supports both ISingleBag and IBag with the former as its default interface.
  • a type library is generated.
  • CSingleBag implements three interfaces: ISingleBag (its default) , IBag and IDispatch.
  • Class CSingleBag is derived from
  • ISingleBag alone, but has all three interfaces in its ATL/COM interface map.
  • C++ templates One can in C++ define a single template interface class such as
  • IBag ⁇ class T> which can a bag of anything. But in COM, you'd have to have a whole slough of separate, yet similar interfaces such as IBag ⁇ integer>, IBag ⁇ string>, etc. The question is how to manage this complexity.
  • the CBag actually only contains a void pointer, so it is very lightweight and created instantly.
  • receives its first QI request (probably though not necessarily from CoCreatelnstance) , it creates the instantiated class for the template that is appropriate to the requested interface, and keeps a reference to it with its void pointer. From that point on, it satisfies requests to the interface with the class. For example, suppose the client first QIs for an IBag_integer interface.
  • the object has morphed itself to an integer bag. If the client wants a bag of strings, it may create a new instance of CBag and QI this new bag for the IBag_string interface.
  • VARIANTS One Interface, One Object (using VARIANTS)
  • VARIANTS A third solution to the problem of COM interface inflexibility is to use VARIANTS.
  • VARIANTS Here we have a single IBag interface and a single CBag implementation. Every bag is a bag of VARIANTS.
  • Every COM interface is derived from IUnknown, we can declare that every bag is a bag of IUnknown interfaces. This leaves the client free to cast or QI the IUnknowns it gets from the bag. It also enables the client to store bags of heterogeneous objects.
  • bags and iterators - and parameterized classes in general - are implemented in COM and in the physical deployment of the Architecture as classes that operate on references to IUnknown interfaces .
  • Overloaded Functions Standard C++ enables one to provide many different versions of a function, all with the same name. As long as the functions' formal parameters are different there is no name collision. In other words, the signature of the function is its name combined with its formal parameter list. In IDL, this is not the case. A single IDL file defining a single interface cannot contain two methods of the same name, even if their formal parameter lists are different. This is an annoying headache for developers who enjoy the liberty of overloading function names to provide simpler, more intuitive interfaces.
  • IDL is not able to express polymorphism, so we would have to build a chain of inheritance where foo is derived from foo3 , which is derived from foo2 , which is derived from fool.
  • a client object uses the single interface foo which contains all three overloaded versions of bar() .
  • the client is blissfully unaware that these versions were inherited from other interfaces. Aggregation and Containment
  • Containment describes the general case of component A acting as the client to another component B. Whenever A contains B, A either contains a B (by value) or a pointer to a B (by reference) .
  • the client of object A does not normally know or care whether A contains B by value or by reference. What is more important is whether A exposes to its client the interfaces that B supports, and if so how it does this. There are a few different ways to do this .
  • A can provide a single interface to its client, and privately use object B to implement parts of that interface. In this case the client does not even know that B exists. This is a case of containment .
  • A can provide multiple interfaces to its client.
  • the client must query A for the different interfaces it wants to use. It appears to the client that A supports all these interfaces, even though A is really deferring the implementation for some of them to B.
  • A does this by intercepting calls to B' s interfaces and wrapping extra functionality around them, this is called containment.
  • containment The difference between this and the first case of single interface containment is whether the client is aware of the different interfaces. Here the client must query A to get a new interface, where in the first case the client invokes all functionality from a single interface on A.
  • Public aggregation may refer to the use of simple aggregation or the use of single interface containment. In general it means the client can access the functionality provided by the aggregated object.
  • Private aggregation refers to the use of containment. Private aggregation is often used as part of a Strategy design pattern.
  • UUIDs Interfaces, Type Libraries and Objects
  • the COM standard identifies objects with UUIDs:
  • UUIDs related to it One class UUID: Known as a CLSID, this is a UUID that identifies the COM object itself.
  • One or more Interface UUIDs Known as an IID, this is a UUID for the interface. Since every object can implement many interfaces, there may be many IIDs associated with the object.
  • One type library UUID Every object has a single type library and the type library has a UUID.
  • Every COM object implemented as an in-proc DLL has a single file named dlldatax.h, which defines the entry points standard COM requires in the DLL that hosts the COM object.
  • this file has #DEFINE protection to prevent redefinition of the symbols in the file when it is #INCLUDEed multiple times.
  • the #DEFINE protection of each dlldatax.h file has the CLSID of the COM pertinent object.
  • the framework is intended to scale at a level supporting hundreds of clients on a single transaction server. Toward this end, certain key objects are designed for instance reuse. For example, multiple different clients running the same workflow are all represented as different threads running inside the same actual instance of a single workflow object in the transaction server.
  • Objects with reusable instances must be carefully designed. For instance, the above example implies that the workflow cannot maintain a pointer to its context. This would tie an instance of the workflow to a particular context . Instead, the context must be passed to the workflow object. Thus, multiple different clients each running the same workflow can pass a different context. That way, each thread running this instance of the workflow object has its own context.
  • Objects in the framework are meta-data defined.
  • COM objects are instantiated, then initialized to become appropriate metatypes.
  • a "BIO” might be instantiated, then init() used to make the BIO a customer.
  • init() used to make the BIO a customer.
  • This object is a merely a shell or husk that can at run time become any particular metatype .
  • MTS may "hot swap" them - that is, use them interchangeably to resolve proxy objects of different clients.
  • Hot swapping the husk of an object across multiple clients does not always conserve resources. It requires the object's current state to be thrown away or at least detached from the husk of the object, and it requires the new state to be glued to the husk. Hot swapping saves memory by spending CPU cycles.
  • MTS provides immense benefits for big objects with small state. But small objects with big state are an MTS nightmare.
  • Stage 1 Raw, Stateless
  • ClassName is nondescriptive
  • the object is instantiated and initialized.
  • ClassName is specific ("BIO. customer, " "Step. GetCustName, " etc.) but InstanceName is still NULL.
  • the object has a metatype and is usable . • Stage 3: Full, Dynamic State
  • the object is instantiated, initialized and has been used. Its ClassName from stage 2 remains, and it may have an InstanceName.
  • the client has used the object in a way that gave it dynamic state - e.g. set(), etc.
  • stage 1 most objects are fairly small. The exceptions would be objects that have a large number of complex method functions. Certainly, a given object is smaller in stage 1 than it is in any other stage. Also, in stage 1, the objects are not very differentiated. In fact, any two objects of the same CLSID could be hot-swapped freely with no negative effects. Unfortunately, they are so small that the benefits of doing this would not be great .
  • the object either does not grow at all, or it grows insignificantly. But it breaks free from all other objects, as differentiation is complete and every single object is different. Hot swapping can be used only if the object's dynamic state can be detached and saved, then restored later when it's hot swapped back in.
  • Stage 1 Reuse at Stage 1, Stage 2 and Stage 3
  • Stage 1 Reuse we describe how to achieve maximum scalability through object reuse at each stage of an object's lifetime.
  • stage 1 all objects of the same CLSID are reusable (hot swappable) . Since this is the default behavior of MTS, administering the objects to MTS does this transparently. Stage 2 Reuse
  • stage 2 all objects of the same metaclass are hot swappable. Objects with the same CLSID cannot necessarily be hot swapped because their metaclasses may be different. Since MTS views the metaclass information as if it were dynamic state, MTS cannot be permitted to hot swap objects in stage 2. To get around this, we need to detach (and save) the current metaclass information just before MTS hot swaps the object, then swap in the (saved) metaclass information for the client whose context the object is getting swapped into. To get MTS to hot swap objects in stage 2, we need to do two things :
  • the framework has already named the object's metaclass information, and we already have a factory that can provide it instantly whenever we ask for it by name. In fact, since the metaclass information is now shared across all objects of a given metaclass, the factories get much simpler and the metaclass information becomes a Singleton.
  • MTS shared property groups This is a global storage area provided by MTS, where we can store any data (our metaclass name) and access it by name. Now we need to have a name we can remember after we've been hot swapped in and out . Anything in our context that is unique will work. But remember that while all the objects owned by a particular client have different contexts, they all share the same session ID. So the context's session ID won't do the job. What we can do instead is to use the address of our context as the name of the location in the shared property group where we store our metaclass name. Stage 3 Reuse Objects in Stage 3 are inherently not reusable, since their dynamic state is not sharable to any other object. Instead, what we do is save and restore their stage 3 dynamic state as needed. Since this state is much smaller than the total size of the stage 2 object, we have succeeded in taking advantage of MTS to share what can be shared - that is, to maximize scalability.
  • staged object reuse under MTS, let's look at how to accomplish it.
  • the framework's behavioral objects are designed to have no stage 3 (dynamic) state information, so the plan is quite straightforward
  • objects that are used to model state - such as BIOs, are more complicated to manage .
  • MTS manages the stage 1 object, and factory objects coordinate with MTS to provide stage 2 reuse. There is no stage 3 state, so we're done.
  • the framework makes extensive use of container objects.
  • Operations on a container may change the state of the container - e.g. addltem, dropltem, etc. - or may not - e.g. getNext, getData, etc.
  • a single container may have many different clients, some of which are adding and dropping items, others only iterating over the container. And each of the latter clients may want to iterate in different ways - some forward, some backward, etc.
  • the first step to satisfy efficiently these requirements is to implement each container as a Bag that may have many access gateways.
  • a passive bag contains items, but it does not own the items it contains; thus, it does not duplicate or destroy the items.
  • a passive bag is merely a collection of pointers to items .
  • the bag increases by one the reference count of each item it contains, and decreases the item's reference count when the item is removed from the bag. Ultimately, it is up to the item to decide when to destroy itself based on the reference counts maintained by its clients .
  • the passive bag is only one of many possible such clients.
  • To access data in a passive Bag one needs an Iterator. Several Iterators can be created for multiple clients to access the Bag' s contents independently and simultaneously.
  • An active Bag allows accessing items directly, through the Bag's interface. The capability is orthogonal to the Bag's internal implementation.
  • the bag may contain its items directly, or it may contain just pointers to the items. It is up to developer which kind of active Bag to use, depending on performance, memory and other considerations.
  • a bag consisting of pointers implies an extra level of COM indirection, while a bag consisting of data implies possible duplication of data.
  • To access data in an Active Bag one creates an Access Gateway; several gateways can exist simultaneously inside a bag, providing independent and simultaneous access to the bag' s items .
  • the active bag groups its items and provides a means to add and drop items from the group. Internally, the active bag uses SAFEARRAY to maintain the collection of items, but the client of a bag remains blissfully unaware of the implementation.
  • the client passes an item to the bag with add() , and specifies an item with drop ( ) .
  • the client can specifically addToEnd ( ) or addToStart () ; the bag adds to end by default .
  • An access gateway provides a means to visit the items in an active bag.
  • the bag creates a gateway for a client, by the bag's CreateAccess ( ) method, and drops it by DropAccess ( ) .
  • Every gateway has the HANDLE, assigned at Create time, which uniquely identifies the gateway among others in the bag.
  • the client then calls Bag's methods, referring to the gateway handle: first (), next ( ) , last(), prev ( ) , isDoneO, getFirstO, getNext (), getLast ( ) , getPrev(). While the gateway points to an existing item, the methods return transaction server_S_OK; when current gateway is driven outside the Bag's SAFEARRAY, the methods return transaction server_S_FAIL, so that visiting a Bag always SUCCEEDS. Bag provides additional functionality, such as get() , getAtlndexO .
  • gateways Although an active bag can change its contents, while some gateways are accessing the Bag, there is no arbitrary limit to the number and type of gateways that can simultaneously visit a single bag. Many different clients can all independently and simultaneously iterate over a bag in different ways without stepping on each other's toes - as long as the Bag doesn't change its contents .
  • the passive bag groups its items and provides a means to add and drop items from the group. Internally, the passive bag uses nodes to encapsulate and join the items it contains, but the client of a bag remains blissfully unaware of nodes. The client passes an item to the bag with add ( ) , and specifies an item with dropO .
  • An iterator provides a means to visit the items in a passive bag.
  • the basic iterator interface (Iiterator) is comprised essentially of first (), next ( ) , isDoneO and get ( ) .
  • first (), next ( ) isDoneO and get ( ) .
  • next actually means is up to the iterator in question, but it guarantees to visit every item in the bag before isDoneO returns TRUE.
  • Different types of iterators may provide additional functionality, such as prev ( ) , lastO, or perhaps getAtlndexO.
  • the iterators don't need to know about bags.
  • the iterator begins life glued to a node, it doesn't know the node came from a bag.
  • the bag can glue it to a node because the bag knows about nodes.
  • the bag's client cannot do this because the bag's client doesn't know about nodes. Only the bag knows what kind of iterators are pertinent .
  • a SingleBag (singly linked list) cannot produce an Arraylterator (random access, indexed iterator) .
  • every bag maintains keeps track of all the iterators it has created for its clients. It keeps track of these iterators in another bag. Thus, every bag contains another bag. This creates obvious problems when we want to create a bag. For example, suppose I create a bag of rocks. The bag of rocks creates its bag of iterators. The bag of iterators, itself being a bag, creates a bag of its iterators. This continues ad infinitum, our original request for a bag of rocks cascading into an infinite chain of bags that must be created.
  • the chain of bags is three levels deep: the main bag 810 (of rocks) , which has a child bag 820 (of rock iterators) , which has its own child bag 830 (of iterators over rock iterators) .
  • the FTArrayBag is FT/FTM, unlike standard passive bags which are apartment threaded.
  • the FTArrayBag' s contents should be static - set up once, and never changed. That is, once the bag is set up, items should not be added or removed.
  • the FTArrayBag' s iterators are apartment threaded. This ensures that they can be instantiated extremely quickly.
  • the entire behavioral model is FT/FTM, it is critical to have FT/FTM bags to use as building blocks for composite objects. Otherwise, the objects have to intern pointers to apartment threaded bags, which introduces a single- threading bottleneck as multiple clients all have to walk single file through the apartment in which the FT/FTM composite object was first initialized.
  • a LiteBag is the lightest of the container structures, based directly on the lightest COM-compatible aggregate: a Safearray.
  • a linear Safearray of Variants is used to store a set of string name — Variant value pairs, even elements holding item names and odd elements holding item values.
  • a class called CLiteBag, manages the Safearray and exposes it either as an associative array (inserting and retrieving items by name) , a regular array direct -accessed by index, or a combination of both. In the case of regular array, multiple items with the same name are permitted. Of a set of items with the same name, associative access reaches only the first one.
  • LiteBag is not intended as a recursive container. (Although a Safearray of VT_VARIANT can in principle contain another Safearray as the value of its element, managing such an arrangement through LiteBags is quite cumbersome.) LiteBag has neither Access Gateways nor Iterators: concurrency control is entirely up to the client. The Bag grows to accommodate new data, but does not automatically shrink. Consequently, all numerical indices to live items remain valid until Shrink ( ) is called.
  • LiteBag is not a COM object but a class; to transmit its data across COM boundaries, the sender should detach the underlying Safearray, and the recipient should attach the array to (its own local instance of) LiteBag.
  • LiteBag is equally suitable for all threading models.
  • the implementation is made threadsafe (even though Safearray intrinsically isn't) by critical section calls around every method. Capturing an available critical section incurs only a small overhead (2us on average) .
  • the goal of security in the transaction server is to meet the needs of the applications by using as much of the built-in capabilities provided by the Microsoft server platforms. We do not want to implement our own security system.
  • Windows NT 4.0 provides a security model that is based on security domains. Users, Groups and other resource accounts) can be added to domains. Domains can trust other domains (i.e. they trust the users logged onto those domains) .
  • the model used is a challenge-response model where passwords are never sent across the network but instead keys are generated based on the password supplied and a key obtained from the domain controller. This ensures a secure way to authenticate .
  • Server processes can impersonate their clients' security in order to access resources on behalf of the client. This provides a powerful way for application servers to integrate NT security into their own transactions without doing too much work.
  • NT security Another limitation of NT security is that an NT domain can have at most 64,000 accounts in it. So, if a customer has more than approx. 60,000 users, they will need more than one NT domain to hold all their user accounts. This can get complicated in terms of administration as trust relationships need to be made between domains. This limitation is not too serious for now because Windows 2000 promises to solve this problem - worst case, a customer will have to administer multiple NT domains .
  • IIS logs in on behalf of its client to the NT system and then after that all transactions occur in the security context of its client.
  • the security context does not appear to survive a process hop.
  • Most of transaction server therefore does NOT actually run under the browser's NT account, but under its own account that is the same for all users.
  • Username of the browser account is stored in the Context and may be used by transaction server to control access to business objects.
  • An application implements authentication as follows:
  • HttpSession returns a special code to OtsGateway.asp .
  • HttpSession retrieves the new username and passes it to ISynchronizer : : setUserClue () .
  • Username e.g. 'bslutsky'
  • Domain name is not retrieved, and neither is the password.
  • ActAuthenticate resumes and populates CharacterUser BIO based on username supplied. If Populate returns more than one row, Authenticate picks the first row. If Populate returns no rows, ActAuthenticate fails.
  • Content items can be secured in one of two ways :
  • URL references were not secure. For example, if you guessed the names of other people's email attachments, you could view these attachments by simply pointing your browser to their URLs. This is because browser credentials are verified only when constructing a URL reference, not when serving out data in response to the URL request. A little encryption can make item URLs difficult to guess, but, since URLs are always transmitted in the clear (even when using SSL) , it would not stop an adversary who can monitor network traffic.
  • the HTTP protocol has no built-in means for browser identification.
  • the identification token must be transmitted either as part of posted data, or as a cookie, or as part of the URL.
  • the URL method is not secure against impersonation by a wiretapper, who can record the URL and attach it to another data packet.
  • the cookie method withstands this attack because SSL encrypts all cookies together with the rest of the data packet, so they cannot be separated without decryption.
  • cookie method fails to distinguish a child browser window from its parent, because the two share the same cookie pool.
  • transaction server must distinguish browser windows, however, because they represent separate transaction server sessions .
  • IIS uses the cookie mechanism to identify the calling browser.
  • Transaction server uses URL identification (so-called “BrowserlD”) in combination with the IIS feature (“IIS SessionID”) .
  • URL identification so-called “BrowserlD”
  • IIS SessionID the IIS feature
  • This allows transaction server to securely distinguish browsers running on separate computers, and to insecurely distinguish parent and child browser windows. Consequently, although transaction server may attach different security roles to different browsers, or even to different workflows rendering into the same browser, a little hacking gives you all the permissions of any browser currently running on your computer.
  • the simplest way to fit secure URL references into this framework is the following.
  • Content Factory For each secure item, Content Factory produces a URL pointing to ContentGateway. asp and containing the name of the item.
  • the ASP file when invoked, calls HttpRouter with the request's IIS SessionID, the Router polls all active sessions that match this IIS SessionID, and each HttpSession object attempts to retrieve the item from the Content Factory using the Context of each pending Render as credentials. If any Render within any active session with matching SessionID has access to the Content item, the request is fulfilled. (If a Content item is public, Content Factory can save CPU cycles by constructing static URLs pointing to the file system. )
  • MTS security sits on top of NT security and introduces the concept of Roles. Users and groups can be added to MTS roles.
  • Programmatic role-based security is especially appropriate for data driven systems, since security may depend on the metaclasses of objects, which are never known until runtime.
  • SQL Server Security SQL Server has two types of security - integrated security
  • NT login i.e. uses the NT login as its login
  • standard login which requires a user ID and password to log in.
  • the latter scheme requires additional administration work and also requires a user to have two different logins - one for NT and one for SQL Server.
  • SQL Server uses Roles mapped to the NT security system's objects. Roles are created and managed at the database level. These can then be assigned to specific cubes within the database . You can use the Manage Roles dialog box to assign roles to a specific cube and manage the access privileges for that role as they apply to the cube.
  • Authentication of the user is done based on the logon information of the user. Access control can only be implemented on the NTFS file system. Permissions can be assigned to various
  • the Microsoft Site Server provides a service called Membership Services. This is functionality that manages the information on registered users and provides a way to map several users (which could run into the thousands or millions) to physical NT logins (which are limited if we want to keep the domain architecture simple) .
  • Site Server 3.0 stores the user information (Membership
  • Site server can operate in either mode - use native NT security for all user accounts or use its own membership database to authenticate users.
  • Transaction Server Security Architecture The transaction server' s security architecture is illustrated in Fig. 9.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un système et un procédé de modélisation du flux des travaux d'entreprise comprenant une couche processus (110), une couche antémémoire (130) et une couche interface (150). La couche processus (110) déplace les processus d'entreprise d'une étape à l'autre. La couche antémémoire (130) gère les données requises par des processus d'entreprise activés et comprend des contextes de processus d'entreprise (135n), des objets de données intelligents (140n) et une couche transaction (145). La couche interface (150) coordonne les E/S entre la couche antémémoire (130) et les interfaces externes.
PCT/US2000/007795 1999-03-26 2000-03-23 Moteur de conception du flux des travaux WO2000058873A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU40252/00A AU4025200A (en) 1999-03-26 2000-03-23 Workflow design engine

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12645999P 1999-03-26 1999-03-26
US60/126,459 1999-03-26

Publications (1)

Publication Number Publication Date
WO2000058873A1 true WO2000058873A1 (fr) 2000-10-05

Family

ID=22424937

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/007795 WO2000058873A1 (fr) 1999-03-26 2000-03-23 Moteur de conception du flux des travaux

Country Status (2)

Country Link
AU (1) AU4025200A (fr)
WO (1) WO2000058873A1 (fr)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7401334B2 (en) 2002-12-20 2008-07-15 International Business Machines Corporation Method, apparatus and computer program product for managing message flow in a multithreaded, message flow environment
US7543299B2 (en) 2003-04-02 2009-06-02 International Business Machines Corporation Creating web services programs from other web services programs
US8484610B2 (en) 2010-03-17 2013-07-09 Microsoft Corporation Workflow execution model
CN103425462A (zh) * 2012-05-14 2013-12-04 阿里巴巴集团控股有限公司 一种工作流数据持久化的方法和装置
US9164811B1 (en) 2014-05-16 2015-10-20 Xerox Corporation Synchronize multipart jobs through automation workflow
US9519528B2 (en) 2013-04-19 2016-12-13 National Ict Australia Limited Checking undoability of an API-controlled computing system
US10191705B2 (en) 2015-05-04 2019-01-29 Xerox Corporation Mechanisms to enable FIFO behavior for selected workflow tasks in multi-document jobs
US11126599B2 (en) 2017-01-24 2021-09-21 Accenture Global Solutions Limited Information validation method and system
US11338107B2 (en) 2016-08-24 2022-05-24 Delos Living Llc Systems, methods and articles for enhancing wellness associated with habitable environments
US11340955B2 (en) 2020-01-02 2022-05-24 International Business Machines Corporation Thread pool management for multiple applications
US11587673B2 (en) 2012-08-28 2023-02-21 Delos Living Llc Systems, methods and articles for enhancing wellness associated with habitable environments
US11649977B2 (en) 2018-09-14 2023-05-16 Delos Living Llc Systems and methods for air remediation
US11668481B2 (en) 2017-08-30 2023-06-06 Delos Living Llc Systems, methods and articles for assessing and/or improving health and well-being
US11763401B2 (en) 2014-02-28 2023-09-19 Delos Living Llc Systems, methods and articles for enhancing wellness associated with habitable environments
US11844163B2 (en) 2019-02-26 2023-12-12 Delos Living Llc Method and apparatus for lighting in an office environment
US11898898B2 (en) 2019-03-25 2024-02-13 Delos Living Llc Systems and methods for acoustic monitoring
WO2024123657A1 (fr) * 2022-12-05 2024-06-13 Seegrid Corporation Système pour modéliser un flux de processus et dupliquer des tâches dans une automatisation du flux des matières

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5734837A (en) * 1994-01-14 1998-03-31 Action Technologies, Inc. Method and apparatus for building business process applications in terms of its workflows

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5734837A (en) * 1994-01-14 1998-03-31 Action Technologies, Inc. Method and apparatus for building business process applications in terms of its workflows

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
GRUHN ET. AL.: "Workflow Management Based on Process Model Repositories", IEEE PROCEEDINGS OF THE 1998 INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, April 1998 (1998-04-01), pages 379 - 388, XP002929715 *
LANG ET. AL.: "Modeling Business Rules with Situation/activation Diagrams", IEEE PROCEEDINGS OF THE 13TH INTERNATIONAL CONFERENCE ON DATA ENGINEERING, April 1997 (1997-04-01), pages 455 - 464, XP002929714 *
LOOS ET. AL.: "Object-Orientation in Business Process Modeling through Applying Event Driven Process Chains (EPC) in UML", IEEE PROCEEDINGS OF THE SECOND INTERNATIONAL ENTERPRISE DISTRIBUTED OBJECT COMPUTING WORKSHP, November 1998 (1998-11-01), pages 102 - 112, XP002929717 *
MENDELSON: "diagramming tools", PC. MAGAZINE, vol. 15, no. 3, February 1996 (1996-02-01), pages 178 - 190, XP002929766 *
RIEMER: "A Process-Driven, Event-Based Business Object Model", IEEE PROCEEDINGS OF THE SECOND INTERNATIONAL ENTERPRISE DISTRIBUTED COMPUTING WORKSHOP, November 1998 (1998-11-01), pages 68 - 74, XP002929716 *
TAN ET. AL.: "Improving the Reusability of Program Specification through Data Flow Modeling", IEEE FIFTH INTERNATIONAL CONFERENCE ON COMPUTING AND INFORMATION, May 1993 (1993-05-01), pages 479 - 483, XP002929713 *

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7401334B2 (en) 2002-12-20 2008-07-15 International Business Machines Corporation Method, apparatus and computer program product for managing message flow in a multithreaded, message flow environment
US8108860B2 (en) 2002-12-20 2012-01-31 International Business Machines Corporation Method for managing message flow in a multithreaded, message flow environment
US7543299B2 (en) 2003-04-02 2009-06-02 International Business Machines Corporation Creating web services programs from other web services programs
US8484610B2 (en) 2010-03-17 2013-07-09 Microsoft Corporation Workflow execution model
US8707249B2 (en) 2010-03-17 2014-04-22 Microsoft Corporation Workflow execution model
CN103425462A (zh) * 2012-05-14 2013-12-04 阿里巴巴集团控股有限公司 一种工作流数据持久化的方法和装置
US11587673B2 (en) 2012-08-28 2023-02-21 Delos Living Llc Systems, methods and articles for enhancing wellness associated with habitable environments
US9519528B2 (en) 2013-04-19 2016-12-13 National Ict Australia Limited Checking undoability of an API-controlled computing system
US11763401B2 (en) 2014-02-28 2023-09-19 Delos Living Llc Systems, methods and articles for enhancing wellness associated with habitable environments
US9164811B1 (en) 2014-05-16 2015-10-20 Xerox Corporation Synchronize multipart jobs through automation workflow
US10191705B2 (en) 2015-05-04 2019-01-29 Xerox Corporation Mechanisms to enable FIFO behavior for selected workflow tasks in multi-document jobs
US11338107B2 (en) 2016-08-24 2022-05-24 Delos Living Llc Systems, methods and articles for enhancing wellness associated with habitable environments
US11126599B2 (en) 2017-01-24 2021-09-21 Accenture Global Solutions Limited Information validation method and system
US11668481B2 (en) 2017-08-30 2023-06-06 Delos Living Llc Systems, methods and articles for assessing and/or improving health and well-being
US11649977B2 (en) 2018-09-14 2023-05-16 Delos Living Llc Systems and methods for air remediation
US11844163B2 (en) 2019-02-26 2023-12-12 Delos Living Llc Method and apparatus for lighting in an office environment
US11898898B2 (en) 2019-03-25 2024-02-13 Delos Living Llc Systems and methods for acoustic monitoring
US11340955B2 (en) 2020-01-02 2022-05-24 International Business Machines Corporation Thread pool management for multiple applications
WO2024123657A1 (fr) * 2022-12-05 2024-06-13 Seegrid Corporation Système pour modéliser un flux de processus et dupliquer des tâches dans une automatisation du flux des matières

Also Published As

Publication number Publication date
AU4025200A (en) 2000-10-16

Similar Documents

Publication Publication Date Title
US11714665B2 (en) Method and apparatus for composite user interface creation
Kurniawan Java for the Web with Servlets, JSP, and EJB
Nicol et al. Object orientation in heterogeneous distributed computing systems
US7340714B2 (en) System and method for using web services with an enterprise system
US7627865B2 (en) Method and apparatus for accessing instrumentation data from within a managed code environment
US6529948B1 (en) Multi-object fetch component
US6601192B1 (en) Assertion component in environment services patterns
US6640244B1 (en) Request batcher in a transaction services patterns environment
US6601234B1 (en) Attribute dictionary in a business logic services environment
US6571282B1 (en) Block-based communication in a communication services patterns environment
US6636242B2 (en) View configurer in a presentation services patterns environment
US6332163B1 (en) Method for providing communication services over a computer network system
US6529909B1 (en) Method for translating an object attribute converter in an information services patterns environment
US6477580B1 (en) Self-described stream in a communication services patterns environment
US6438594B1 (en) Delivering service to a client via a locally addressable interface
US6434628B1 (en) Common interface for handling exception interface name with additional prefix and suffix for handling exceptions in environment services patterns
US6549949B1 (en) Fixed format stream in a communication services patterns environment
US6341314B1 (en) Web-based virtual computing machine
US8407718B2 (en) Method and apparatus for composite user interface generation
US20040167894A1 (en) Method for using a business model data interface
US20060136923A1 (en) System for distributed task execution
WO2000058873A1 (fr) Moteur de conception du flux des travaux
US7991737B2 (en) Synchronization of records of a table using bookmarks
Duthie et al. ASP. NET in a Nutshell: A Desktop Quick Reference
Fatoohi et al. Middleware for Building Distributed Applications Infrastructure

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP