Business Process Implementation for IT Professionals phần 6 pot

12.1.4 Logical connectivity There are two basic means of obtaining logical connectivity between client and server. One is direct program-to-program procedure (or subroutine) calls as defined through the programming language being used. That requires that both client and server be defined on the same computing platform and linked in some manner. This mechanism was first used to provide program-to-program communication, but it cannot be used when client and server are on different physical platforms. The second type of communication is the message, which must be used between a client and server on different platforms and which can be used if they are on the same platform. Messages are simply a string of formatted data that identify the source and the destination address of the information being communicated, the information itself, and some check or control characters that indicate whether the message arrived intact. Because most C/S systems are defined such that they can run on different physical platforms, the use of messages to provide communications is assumed for the remainder of this discussion. 12.2 Compound C/S systems There are three basic differences between simple C/S systems and the more complex compound C/S systems. In general: § Compound C/S systems utilize an infrastructure to provi de common services to the process-specific C/S clients and servers. The infrastructure is considered in Section 12.4. § Compound C/S systems utilize a large number of intercommunicating servers, both those that are process specific and those that provide infrastructure services. § Compound C/S systems utilize multiple clients that transfer information between them. As with simple systems, each server in a compound system can provide multiple services. It is also possible for different infrastructure servers to incorporate and offer the same service. In that case, the process implementer needs to specify the server that is going to provide a specific service. The server utilized also might change under different sets of circumstances. 12.2.1 Multiple servers Several different multiple-server C/S configurations are discussed in this section: single- server types, multiple-server types, synchronous and asynchronous communications, and push and pull interactions. For systems with a single-server type, an illustration of the structure is shown in the configuration diagrams in Figure 12.4 for synchronous messaging and Figure 12.5 for asynchronous messaging. Figure 12.4: Multiple-server, synchronous communication configuration. Figure 12.5: Multiple-server, asynchronous communication configuration. The next extension permits servers to request services from other servers to complete the initial client-requested service. The extension is illustrated by the configuration diagram in Figure 12.6. The illustration assumes synchronous communication, but the concept is easily extended to the asynchronous communication format. When a server requests services from another server, the mechanism is that of a server requester, not a client. Figure 12.6: Multiple-server, requester function configuration. Figures 12.4–12.6 have all been for services performed as the result of a pull or direct request on the part of the client. In these cases, there is a pairing of the service request and response. For every request, there is an associated response. As mentioned in Section 12.1.2.1, push services also can be defined. Push services are services delivered to the client from a server but not always as a response to a direct request from the client. Usually there are several responses to one request, and those responses are asynchronous with respect to the client processing. That possibility is illustrated in Figure 12.7. In general, there is an initiating request, such as client request a to server C in the figure. There are multiple responses back to the client from server C in response to the request, also labeled a in the figure. For example, say the request is to return a specialized version of a newspaper from a newspaper server (server C) every day. Then each day the requested information would be returned (pushed) to the client from server C with no further request by the client. Figure 12.7: Multiple-server, push services configuration. Other requests and responses also could be occurring asynchronously from the original request. Extend the example by allowing server C to send, via a request, the address of the client and type of information the client is interested in to another server (server A) that contains advertising for a given manufacturer’s products. If there is a match, then server A sends an unsolicited advertisement for one or more products (response a from server A to the client). That push can be considered to be another response to the original request. Note that there is no direct response to the request from server C to server A. That also is allowed with this type of C/S system. However, there is no guarantee that the request was ever processed by server A. The client also could have requested the same product information directly from server A, as indicated by the request and the initial response labeled b. Additional responses b could be the result of the server also sending information on pending sales or special deals involving the product of interest. These systems can get arbitrarily complex and involve a large number of servers over a period of time. That is both the strength and the weakness of this type of C/S system. 12.2.2 Multiple clients The tendency is to provide a client for any significant type of automation functionality. Some of the more widely used standard clients, in addition to clients defined for specific enterprise automation functionality, are as follows: § E-mail clients; § Workflow clients; § Web browsers; § Office services clients. Multiple clients, in the context of this discussion, means that they are being utilized as the interface to the same person in the performance of some enterprise activity. Each person utilizing the C/S system would have his or her own instance of the clients. The main requirement when multiple clients are involved in an overall C/S system is the ability to transfer information from client to client in a relatively easy way. That usually is accomplished through the resident infrastructure services of the platform on which the clients reside (e.g., drag and drop from one client window to another). Another method is to design the clients so they can interact directly with each other. That requires that the appropriate standards be available. It usually is assumed that all the clients will reside on the same platform because they all must be accessible by the person with whom they are interfacing. If a client is moved to a platform where it is accessed by means of another client on a different platform, for example, a Web browser accessing a workflow client, then the workflow client loses its client identity and logically becomes a server. The functionality may remain approximately the same, but because it no longer is the direct interface to a human, it cannot remain a client. The Web browser becomes the new client. This terminology has not been universally adopted, and in many situations the original client still is referred to as the client and the Web browser retains its identity as an interface device. Readers should be aware of this confusing situation when it occurs. While some of these points may seem minor, they are the source of considerable confusion in discussions of C/S systems. It is hoped that by explicitly addressing the issues there will be an increased understanding as to how to classify and discuss the structure and components of a specific C/S system. It should be noted that a given C/S system can behave in multiple ways. For some functions, it can be a single-server, synchronous system, while for other functions it can be a multiple-server (including infrastructure), asynchronous system with push features. 12.3 Infrastructure Implementing an automation system generally involves two types of functions and entities: those that contribute directly to the problem being addressed and those that perform a support role. In general, support functions and entities are common to a large number of process-specific functions. Support components usually are grouped under the heading of infrastructure. The infrastructure provides the environment that facilitates the use of the C/S system in providing the automation functions needed for the enterprise. A simple diagram of a C/S system that explicitly incorporates the infrastructure is of use in understanding the basic relationships. Such a diagram is shown in Figure 12.8. Figure 12.8: Infrastructure relationships. The infrastructure in a C/S system consists of servers and associated services that can be used in support of process-specific clients and servers. A more familiar depiction of a C/S system using an explicit infrastructure is shown by the configuration diagram in Figure 12.9. In most cases, as shown in the figure, the client communicates directly with the infrastructure servers and only indirectly with the application servers. That occurs because of the fundamental nature of the infrastructure services as conduits and qualifiers for the application servers. Figure 12.9: Infrastructure-oriented configuration diagram. The decoupling of an automation client from the automation server through the use of infrastructure servers has some desirable side effects. The service functionality resident in the application servers can be structured in such a way that many different automation clients, which may implement different enterprise processes, can utilize the same service components without change. Means to define and implement components with functions that can facilitate component reuse are discussed in Chapter 13. Although reuse can be achieved using other approaches, the C/S structure is a definite help. The process implementation methodology also takes advantage of the C/S approach to facilitate reuse in addition to providing other advantages to conventional techniques of automation specification and use. Decoupling also can facilitate the use of legacy systems in new automation functionality. Legacy systems can be considered to be large, complex application servers. By isolating this functionality, it can be utilized in any fashion needed by a specific client. If some specialized access conditions are needed, they can be placed into an infrastructure server and possibly utilized for multiple legacy systems. That is not to minimize the considerable problems in the use of legacy system functionality. However, if the advantages of utilizing legacy system functionality outweigh the disadvantages of obtaining replacement functionality, than the C/S approach using a robust infrastructure can be of considerable value. The architecture and specification of the infrastructure and its services are a significant and separate subject. Although some later chapters briefly address specific aspects of the infrastructure, a more detailed consideration of the infrastructure is well beyond the scope of this book. 12.4 Summary Enterprise automation environments based on a C/S approach, along with a comprehensive infrastructure, can provide a flexible and powerful means of implementing business processes. With the increasing utilization of the Internet and its variations (intranet, extranet) as a communications and delivery vehicle for automation functionality, the C/S approach is a natural fit. However, the complexity of such systems demands that a systems engineering approach to their development and specification be utilized. Enterprise mission-critical C/S systems cannot be structured from the bottom up. Selected bibliography Adler, R. M., “Distributed Coordination Models for Client/Server Computing,” Computer, Vol. 28, No. 4, 1995, pp. 14–22. Baker, J., et al., “The Role of Client/Server Computing Technology in the Management of Global Enterprises,” Proc. Portland Internatl. Conf. Management and Technology, Portland, OR, 1997, July 27–31, 1997, pp. 739. Drakopoulos, E., “Design Issues in Client/Server Systems,” Proc. IEEE 14th Ann. Internatl. Phoenix Conf. Computers and Communications, Phoenix, Mar. 28–31, 1995, pp. 487–493. Graham, W. C., and S. Majumdar, “The Performance of Multithreading and Scheduling on Client-Server Systems,” IEEE Internatl. Performance, Computing, and Communications Conf. 1997, Phoenix/Tempe, Feb. 5–7, 1997, pp. 87–93. Kanitkar, V., and A. Delis, “Real-Time Client-Server Push Strategies: Specification and Evaluation,” Proc. IEEE 4th Real-Time Technology and Applications Symp.,June 3–5, 1998, pp. 179–188. Savino, S. P., and S. M. Queroli, “Impact of Client/Server Computing on the Telecommunications Industry,” Proc. Internatl. Conf. Engineering and Technology Management, Vancouver, BC, Aug. 18–20, 1996, pp. 605–610. Zhang, T., and J. R. Hayes, “Client/Server Architectures Over Wide Area Networks,” 1997 IEEE Internatl. Conf. Communications, Montreal, June 8–12, 1997, Vol. 2, pp. 580–584. Chapter 13: Dialog and action modeling Overview Sufficient modeling has now been accomplished to allow the development of two closely related automation assets: dialogs and actions. The models of those two assets provide the mechanism through which process definitions are changed into functional specifications. Because actions are used as part of the definition of a dialog, dialogs are discussed first. That order allows the most natural progression from process definition to implementation. In addition, it is not necessary to understand the detailed action model to utilize the concept as part of the dialog model specification. The construction of the dialog and action models is designed to take into account the requirements of automation development in the emerging environment: § Direct process implementation; § Rapid implementation and change; § Reusable components at several levels; § Isolation of change propagation; § Flexibility; § Explicit utilization of business rules; § Utilization of a C/S approach; § Accommodation of an information model; § Compatibility with push and pull technology; § Compatibility with Internet standards; § Compatibility with component-based architectures. The structure of the dialog and action model assumes a robust infrastructure exists that can provide the common services as discussed in this and previous chapters. 13.1 Dialog context A dialog serves as a bridge between the business requirements as embodied in the process perspective, the technical specifications needed for design, and the deployed software of the enterprise automation environment. As such, a dialog must be in a form that can be used as the basis for custom product development, COTS product selection, or the incorporation of a legacy system functionality. Dialogs provide the continuity needed to allow a smooth transition from business requirements to implementation, as illustrated in Figure 13.1. Figure 13.1: Bridging aspects of dialogs. This chapter specifically addresses the dialog model utilized by the technical specification anchor of the “bridge.” Other chapters are devoted to the other bridge anchors. However, to provide continuity in this presentation, a brief definition of a dialog in the business requirements anchor and the automation environment anchor also is presented. Although the three definitions involved will seem quite different, they each describe a different view of the same entity. From the business requirements perspective, a dialog is a portion of a process (process fragment) with activities that can be performed by a single role performer without transferring control to another role performer. Using that definition, a dialog has no specific size and can be as small as a single process step or as large as an entire process. A dialog gets its name from the fact that it also can be considered a conversation (or dialog) between the user and the process automation functionality. From the automation environment perspective, one or more related dialogs define a workflow task that is implemented using reusable components and a suitable control mechanism. From the technical specification perspective, a dialog consists of a set of self-contained atomic actions that provide the functionality specification for the dialog and a cluster store that defines and contains the dynamic data utilized by the actions. The relationship between the automation assets that make up the three perspectives of a dialog is shown in Figure 13.2. Figure 13.2: The dialog and action environment. In the following discussion, to ensure that the proper view is being addressed, the term dialog is used to imply the technical specification (design) perspective; process fragment and task imply the business and operational perspectives, respectively. 13.2 Dialog model Dialogs are the fundamental unit of process implementation. Dialogs can be implemented individually or in related groups without compromising the implementation. Multiple dialogs usually are required to implement a given process fragment. Some are derived from the business process and others because of technical and implementation- specific requirements. In addition, business processes may need associated management, administrative, and support processes. Dialogs resulting from all those sources may need to be executed as a part of the same task, as illustrated in Figure 13.3. Figure 13.3: Multiple-dialog utilization. The same dialog also can be utilized in the design of process fragments from different processes. That latter ability provides for reuse at the process level. For example, a dialog that implements a process fragment that determines a customer’s credit rating could be part of a marketing process, a late payment treatment process, and an ordering process. The assumption, as should be the case, is that all the processes use the same set of steps to perform the procedure. 13.2.1 Clusters Dialogs that are simultaneously executing on a given workstation are called a cluster, and they usually are loosely coupled through the use of a common cluster store. A specific instance of a dialog must be able to be initiated and terminated, be able to be suspended, and be able to interact with a human or automaton user. That requires that a suitable set of states that can be assumed by the dialog must be defined. Those states are defined as follows: § An active dialog is a dialog that has been initiated and not explicitly suspended or terminated. § An open dialog is an active dialog that has the current capability to output information and receives information from a human interface. § A closed dialog is an active dialog that does not have the current capability to output information and receive information from a human interface. It may, however, initiate and complete actions based on information in the cluster store that does not involve the human interface. § A suspended dialog is a dialog that currently is not performing any processing and that cannot by itself initiate processing. § A terminated dialog is a dialog that has been removed from the cluster. Any outstanding transactions are lost. The states are controlled by the cluster control interacting with the human or automaton role performer instance. The cluster control is an infrastructure function that determines the states of those dialogs that are part of the operational cluster. Many dialogs can be active, but only one can be open at any given time. A cluster is an operational entity because it is defined only at run time. As discussed in Chapter 11, the information in a cluster store is intended to be self-defining and is available to all dialogs in the cluster on an equal basis. The set of tasks that implement an entire process is controlled through workflow techniques, as discussed in Chapter 15. Examples of dialogs that could be part of a cluster in the design of one or more business process would be as follows. § Business process fragment 1 advances the process through the business process fragment implemented (e.g., order entry). § Business process fragment 2 advances the process through a different business process fragment (e.g., previous order status). All information obtained as a result of either process is available to both processes because of the common self-defining cluster store. § Management process dialog allows a supervisor or other manager to take over an interaction with a customer and have all current information available. § Support process dialog provides information to the operator about any of the available functions. § Administration dialog terminates the process for any reason (e.g., customer hangs up). All dialogs have the same framework, as illustrated in Figure 13.4. The framework consists of a set of nine interrelated action categories and a cluster store that provides the mechanism for dynamic data storage. The action categories include those needed to provide the administrative functions of the dialog as well as the business-related functions required by the specification of the business process fragment. It is expected that the majority of the actions having an administrative category are common to almost all dialogs and, therefore, are highly reusable. Figure 13.4: Dialog model framework. 13.2.2 Cluster store Actions of all dialogs in a cluster utilize a common cluster store for dynamic data. Although a cluster store is shown as part of a dialog framework and the dialog actions use the cluster store, it is not defined on a dialog basis. The cluster store has a separate definition that is tied to the existence of a continuing role performer instance. A role performer instance starts when the initial business process dialog is initiated by the role performer. It continues until the role performer terminates the original dialog and all associated dialogs that were initiated and required the same dynamic data as the first dialog. As long as the role performer instance is not terminated, no matter how many dialogs are initiated and terminated during the instance period, the cluster store stays in existence. That allows the utilization of instance information by any active dialog during the time the role performer instance exists. This aspect of the cluster store is illustrated in Figure 13.5. The up arrows indicate when a dialog is initiated and the down arrows when it is terminated. Figure 13.5: Cluster store instance. For example, assume a customer calls to place an order. A role performer instance is created to perform the activities of the task dialogs that implement, in part, the order process (dialogs 1, 4, and 5 in Figure 13.5). While the order is being taken, the customer asks the status of a previous order. That is a task (dialogs 3 and 6) in another process, but because of the circumstances, it is performed by the same role performer instance as used in the order dialog because it uses the same set of dynamic data. As shown, the two tasks are processed in parallel. Although the process and associated dialog have changed, the role performer instance has not; because of that, the cluster store remains intact. That allows the customer information obtained because of the order dialog to be immediately used for the status inquiry. Keeping the cluster store intact throughout a continuing role performer instance also makes the specification of the user interface easier. Because the same role performer instance also would necessitate some reasonable continuity in the user interface, the user interface can be defined on the basis of the cluster store rather than a dialog. Thus, no matter how many dialogs are inserted into and removed from the cluster, the user interface remains continuous as long as the cluster store is not terminated. That aspect is also illustrated in Figure 13.5. This type of operation requires the role performer to have the ability to initiate any workflows (processes) that may be needed as an adjunct to the handling of other processes. The use of scenarios is crucial to the design and specification effort. 13.2.3 Functional categoriesand phases An action is a specification for a specific type of operation to be performed during the invocation of a dialog. Each action in a dialog belongs to one of the following functional categories: § Initialization; § Instance data verification and validation; § Business process; § Instance data assembly; § Cleanup; § Termination; § Exception handling; § Control; § Help/tutorial. Regardless of which category an action is in, it will have the model framework as presented in the following section. Although the definitions of the action categories and some general usage examples are presented in the following discussion, it is not possible to provide an appreciation of the power of the categories until the methodology discussion in Part III. As will be evident from the following discussion, most of the actions in categories other than business process and help/tutorial are common to all dialogs. That is one powerful example of the reuse capabilities of this type of structure. Actions in the initialization category are utilized to place the dialog in a state suitable for execution. Such actions could include the retrieval and setting of appropriate parameters; the initialization of data in cluster store; and the updating of statistics, logging, and other administrative data. The actions do not necessarily result from the business requirements of the process steps but may be developed from the technical requirements of the dialog. Usually, a set of initialization actions common to all dialogs are developed and documented, in addition to the initialization actions specific to a given dialog. Actions in the instance data verification and validation category are utilized to ensure that data presented to the dialog via a workflow system are available and correct. Actions could include the examination of data for proper identification and to verify the availability of the needed data in the cluster store. These actions do not include any validation and verification that is associated with data retrieved from datastores. Actions in the business process category are the implementations of specific business functions. Such actions are directly dependent on the function of each dialog and therefore must be specified on a dialog-by-dialog basis. However, the number of possible actions in this category is limited to a relatively small number to facilitate their standardization and reuse in multiple dialogs. [...]... interface with multiple process implementations, thus maintaining a common look and feel This type of process implementation structure has as its focus the specification and sequencing of functionality With that type of approach, changes can be made to the components, under many circumstances, without necessitating changes in the process implementation Likewise, changes can be made to the process implementation. .. functionality, either through the utilization of the common functions needed for dialog implementation or the use of available business- oriented software components Although a large amount of information is generated in the action specification process, its regular structure makes it possible (though difficult) to handle, even without automated assistance Because of the amount of initial information... functionality of the server is always through the use of a request/response pair, the action, regardless of definition, can always be characterized as a data CRUD type of activity Although the possible complexity is arbitrary, in actual practice action complexity usually is quite small That occurs because it generally is easier to define several actions, each with limited functionality, than one action with... completes Note that for this task, action 5 did not launch because its launch criterion was never true It is not necessary for all actions in a dialog to launch In fact, in most cases, the majority of the actions in a dialog will not launch for any given task For different tasks, the actions that launch and those that do not will be different It all depends on the specific conditions present for the dialog,... server needs or produces in processing a client request can utilize any available datastore An action is closed or self-contained in the sense that it encapsulates all the support functions with the transaction itself In fact, a group of actions, with the proper platform infrastructure, constitute a reasonable segment of automation functionality without the need for any additional software By their very... specification activity is definitely a front-loaded effort That is somewhat in conflict with current approaches of building something quick and then modifying it until it works or seems to fit the requirements of the users While such an evolutionary approach certainly provides the instant gratification that seems to be a need for contemporary activity, it cannot provide the product quality level and future... independently of process implementation, a lot of amateurs are plying the trade, and they tend to utilize simplistic solutions and constructs The C/S architectural structure also helps enforce the separation of process implementation from component implementation by providing a well-defined and enforceable interface between the two entities It is not necessary at this point to delve into the details of a suitable... to initiate a transaction (launch condition); § The formulation of the request; § The validation and verification of the response; § The analysis and dissemination of the result information Those components, along with the transaction itself, constitute an action The action model framework is shown in Figure 13 .6 Actions consist of the transaction functionality along with all the support needed for. .. where they sit Of course, the same is true for the process implementations Their implementation conditions can be different or the same as that utilized by the components It simply does not matter If an enterprise develops products for different customers, each with their own independent C/S systems, then a server-based philosophy usually can be used only within a given customer’s facilities unless... approach), it usually is caused by structural problems between two or more enterprise organizations Poor communications, distrust, and arbitrary restrictions are among the many possible causes Methods of reducing unnecessary duplication of effort are an interesting topic in its general form However, for the purposes of this discussion, only the potential duplication of effort existing in process implementation . definition that is tied to the existence of a continuing role performer instance. A role performer instance starts when the initial business process dialog is initiated by the role performer. It. as follows. § Business process fragment 1 advances the process through the business process fragment implemented (e.g., order entry). § Business process fragment 2 advances the process through. Accommodation of an information model; § Compatibility with push and pull technology; § Compatibility with Internet standards; § Compatibility with component-based architectures. The structure