Enterprise service computing from concept_3 docx

30 311 0
Enterprise service computing from concept_3 docx

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

42 Zhao, Jeng, An, Cao, Bryant, Hauser, & Tao Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. Figure 9. The business-process model of a supply chain Aligning Business Processes with Enterprise Service Computing Infrastructure 43 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Figure 10. The SDM of the business-process model of Figure 9 Figure 11. The causality tree for ShippingRate 44 Zhao, Jeng, An, Cao, Bryant, Hauser, & Tao Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. gular boxes) and each has its own in- and outows. We omitted the part of handling payment for simplicity. The stock “Order Backlog” in Figure 10 corresponds to the data repository “Order Backlog” in Figure 9. The activity “Place Order” by the customer will have the effect of increasing the stock “Order Backlog” and chang- ing the inow “Demand Rate”. Similarly, the activity “Shipping out Products” after the storage would have the effect of decreasing the stock and changing the outow “Fulllment Rate.” The stock “Finished Product” is the result of the activity “Make Product” and will be reduced by the activity “Shipping out Products.” The stock “Part WIP” is increased by “Order Parts” and is reduced by “Receive Parts”, and the stock “Part Inventory” will be increased due to the effect of “Receive Parts” and reduced by the activity “Make Product.” It is less clear how the activities in a business-process model affect in- and outow rates for each stock. In the business-process model, dependencies can be expressed graphically only through data streams. Any additional dependencies could be buried in the input criterion and output criterion of the data stream for each task. It is pos- sible to use built-in expressions or plugged-in programming languages to express the input and output criteria. On the other hand, the dependencies in an SDM can be expressed graphically with the notion of polarity, wherein the positive polarity (denoted by a plus sign) represents reinforcement feedback loops and the negative polarity (denoted by a minus sign) represents those feedback loops that can reach equilibrium. The inuence map can be created by connecting direction links. Based on the visual inuence map, low-level metrics can be synthesized by capturing the causal relationships in the form of mathematical formulas. The key to bridging the gap between the business operations and the IT systems is to establish the dynamic causal relationships between IT-level and business-level performance metrics in the mathematical formulas. Figure 11 gives an example causality tree for “Ship- pingRate.” The business-level variables are shown in yellow rectangular boxes; the IT-level variables are shown in green rectangular boxes. This causality tree corresponds to the business activities between “Check Order and Product Status” and “Shipping out Product” shown in Figure 9. We discuss this causality tree in a bottom-up order. Let us assume the above inventory system is monitored and controlled by a main process wherein inventory processes can handle client requests through network connections one at a time (this example is adjusted from Diao, Hellerstein, Parekh, & Bigus, 2003). Therefore, the number of inventory processes is constrained by the maximum number of connections, say “MaxClientConnections,” provided by the system. The controller monitors connections and manages their life cycles. If the connection has been idle over a certain amount of time, say “ConnectionLife- UpperBound,” the connection is terminated or returned to the connection pool. A higher “MaxClientConnections” value allows the system to process more inventory Aligning Business Processes with Enterprise Service Computing Infrastructure 45 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. requests and increases both CPU (central processing unit) and memory utilization. Decreasing the value of “ConnectionLifeUpperBound” potentially allows inventory processes to be more active, leading to higher CPU and memory utilization. The above description can be formulated as follows (Diao et al.): CPU k+1 = A 1,1 * CPU k + A 1,2 * MEM k + B 1,1 * MaxClientConnections k + B 1,2 * Con- nectionLifeUpperBound k and MEM k+1 = A 2,1 * CPU k + A 2,2 * MEM k + B 2,1 * MaxClientConnections k + B 2,2 * Con- nectionLifeUpperBound k , where CPU k and MEM k represent the values of CPU and memory utilization at the kth time interval. The metrics MaxClientConnections k and ConnectionLifeUpperBound k represent the values of “MaxClientConnections” and “ConnectionLifeUpperBound” at the kth time interval. The entries A i,j and B i,j represent modeling parameters at the IT level that can be obtained using statistical methods. In every time period, the controller has to decide how much of the available resources (CPU, memory) to allocate to each inventory process. How to realize this control strategy is beyond the scope of this chapter. Here, we only show how the business-level and IT-level metrics can be linked using the causality relationships of an SDM. The metrics “MinimalProcessTime” at the business level depends on the metrics at the IT level such as CPU and memory utilization. Good “MinimalProcessTime” is ensured by reserving sufcient capability to handle workload spikes. A particular IT-system conguration by tuning parameters such as “MaxClientConnections” and “ConnectionLifeUpperBound” gives a particular “MinimalProcessTime.” “DesiredShippingTime” can be assigned a proper value based on the average values of real processing time. The “DesiredShippingRate” is determined by “OrderBack- log” and “DesiredShippingTime”: . ppingTime DesiredShi og OrderBackl ppingRat eDesiredShi = The “MaximalShippingRate” is determined by “FinishedProduct” and “Minimal- ProcessingTime”: 46 Zhao, Jeng, An, Cao, Bryant, Hauser, & Tao Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. . ecessingTimMi nimalPro oduc t FinishedPr ppingRateMa ximalShi = Finally, the “ShippingRate” is determined by “DesiredShippingRate” and “Maxi- malShippingRate”: ( ) .,min ppingRateMaximalShippingRateDesiredShiteShippingRa = An SDM tends to represent a deterministic model and is used to study the overall behavior in a certain given timescale. Compared to the business-process model, the SDM aims to cover the detailed product-shipping activities by mimicking real-world events on a smaller scale. The assigned values in an SDM can be obtained from the simulation results of the business-process model or the average of the real data that are identied in the business artifacts of the business-process model. We give a few more examples of how to synthesize low-level metrics to meet overall service requirements. The stock “Finished Product” is increased through the activity “Make Product” by using “Product Demand” that comes from “Forecast Demand” and “Adjust Product Based on Finished Product.” The forecast model we have here is the exponential smoothing of historical data: ) , ( orSm oothFact Dem andRate Sm ooth m andRate Sm oothed De = , where the function smooth is one of the built-in functions in the SDM tool. The adjustment from “Finished Product” introduces a negative feedback loop to rebal- ance the amount of products we should assemble: . * imedjustmentTInventoryA odu ctFinish ed Prory du ctInventDesire dP ro mandRateSmoothedDeeemblingRatDesiredAss rageentoryCoveProductInvmandRatesmoothedDeoryductInventDesiredPro − += = The real assembling rate could be delayed: .),( DelayTimeeemblingRatDesiredAssDelayFixedRateAssembling = The part usage rate is transformed from “Assembling Rate” using “Bill of Mate- rial”: Aligning Business Processes with Enterprise Service Computing Infrastructure 47 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. ( ) .),( ][*],[][ orSmoothFactatePartUsingRSmoothteedDemandRaPartSmooth jRateAssemblingjirialBillOfMateiatePartUsingR j = = ∑ The part demand, determining how much to order from suppliers, can be adjusted based on “Part Inventory” (another negative feedback loop): . * entTimeoryAdjustmPartInvent oryPartInvent dInventory PartDesire teedDemandRaPartSmoothatedDeliveryRPartDesire eoryCoveragPartInventteedDemandRaPartSmoothdInventoryPartDesire − += = In an SDM, the dynamics of a business process is captured through stock ow dia- grams with dependency graphs and mathematical formulations (systems of ordinary differential equations). A simulation of this system would expose its dynamic behavior in the time dimension. Because of the complexity of the system with nonlinearity and time delay, we may not be able to solve the system analytically. Based on avail- able numerical methods for ordinary differential equations, like Euler’s rst-order nite difference and the Runge-Kutta second- and fourth-order nite-difference methods, the system can be solved numerically. Both Matlab (2005) and Vensim (2005) provide such equation solvers. Furthermore, the tool provided by Vensim helps modelers to determine visually what kind of action should be taken, such as changing system settings. Dynamic Adaption Background We live in a dynamic and fast-changing environment. The agility of an enterprise not only depends on the sensibility of the management, but also on the responsiveness of its IT infrastructure in line with the changes in the business environment. This is the challenge to realize the so-called on-demand business (IBM, 2005c). Primarily, there are two types of changes of business-level decisions that require the IT infrastructure to respond quickly: functional and nonfunctional. As the result of functional changes, the business-process model will change as well, for example, acquiring an additional arc, an additional node, or a modied attribute value. Any small adjustments to the business-process model potentially can change the proper- 48 Zhao, Jeng, An, Cao, Bryant, Hauser, & Tao Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. ties of the model as a whole. For instance, one more arc in the model could change a reducible process model to an irreducible one. Thereafter, the generated BPEL code should be updated accordingly. In general, it is not a good idea to regenerate the whole business model upon any changes, especially for large-scale process models. An algorithm is presented in the chapter that can scope and localize the changes so that only the subprocess in the scope will be regenerated. A nonfunctional alteration of the business-process model does not change the properties of the process model, but reestablishes the linkage with the IT service that implements the same functionality while offering a better QoS (quality of service) value such as a higher response time and availability. We shall notice that our criterion of categorizing functional and nonfunctional adaptation is mechanical rather than semantic. To semantically verify whether the functionality of the process model is changed is not computable or at least fuzzy if we use the techniques to verify the process model against some formal functionality specication. Hence, a revision of the structure of a process model in order to achieve a higher overall QoS value, but with the same functionality, is categorized as a functional change according to our criterion. Both functional and nonfunctional adaptation can be performed statically or dynami- cally. Static adaptation requires, in addition to a break in service availability, the regeneration of executable code from the process model, reloading, redeployment, Figure 12. An example ow graph from Aho et al. (2006) 1 2 3 a b c 4 d e 5 6 f g 7 i j h 8 k 10 9 n m q o p Aligning Business Processes with Enterprise Service Computing Infrastructure 49 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. and a relinking with remote IT services. In some mission-critical scenarios such as nance and military applications, there is a need for a continuous guarantee of service availability. Dynamic adaptation manipulates a business process in its IT- infrastructure run-time environment while maintaining the availability of services. Later, we discuss our experiment by using a technique that enables the dynamic adaptation of business processes running in the Microsoft .NET ® (Microsoft, 2005) Web-service environment. Localize the Changes The main theory used to achieve change localization in a process model is the concept of a two-terminal region from control ow-graph analysis (Allen, 1970) in compiler theory. We start by introducing several relevant denitions. Denition 2. Given a ow graph G with initial node N 0 and a node N of G, the interval with header N, denoted I(N), is dened as follows (Aho et al., 2007): 1. N is in I(N), 2. if all the predecessors of some node M≠N 0 are in I(N), then M is in I(N), and 3. nothing else is in I(N). The corresponding REL for this graph is ( (a c + b) (d( (f i + g j) (k [p n] mq)* h ) * (p + e ) )* n o ) *. Based on Denition 2, we can obtain a set of intervals for Figure 12 as follows: I(1) = {1, 2} I(3) ={3} I(4) ={4, 5, 6} I(7) ={7, 8, 9, 10}. One distinguished property of intervals is that all the intervals in one ow graph are disjoint. A two-terminal region was originally dened as follows. Denition 3. A two-terminal region is an interval with one exit node (Allen, 1970). 50 Zhao, Jeng, An, Cao, Bryant, Hauser, & Tao Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis- sion of Idea Group Inc. is prohibited. Intuitively, our goal of localizing the changes in a process model is to locate some regions within which changes do not affect other regions. Denition 3 does not satisfy our needs as a lot of regions are excluded from it; for example, I(1) and I(4) are not two-terminal regions. We thus adopted and modied the denition of two-terminal regions from Koehler, Hauser, Sendall, and Wahler (2005), in which two-terminal regions are used to partition the process model into subgraphs so that different subgraphs can be analyzed and transformed using different algorithms based on their specic properties. In fact, the denition of a two-terminal region in Koehler et al. results in different sets from that of Allen (1970); the denition we give in this chapter yields different sets from both Allen and Koehler et al. It is not our intention to compare the detailed differences in this chapter. Therefore, we straightly give our denition. Denition 4. Node N dominates (or predominates) node M if every path from the initial node of the ow graph to M goes through N (Aho et al., 2007). Denition 5. Node N postdominates node M if every path from M to the exit node goes through N (Allen, 1970). Denition 6. A two-terminal region is a subgraph TTR(N,M) between N and M such that: 1. N predominates all nodes in the region, and 2. M postdominates all nodes in the region. Based on Denition 6, we can obtain a set of two-terminal regions of Figure 12 as follows: TTR(1, 3) ={1, 2, 3} Figure 13. The correspondence of REL constructs and two-terminal regions ( ( a c + b ) ( d ( ( f i + g j ) ( k [p n] m q )* h )* ( p + e ) )* n o ) * TTR(1,3) TTR(3,4) TTR(7,8) TTR(4,7) TTR(4,8) TTR(3,8) TTR(1,9) Aligning Business Processes with Enterprise Service Computing Infrastructure 51 Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. TTR(3, 4) ={3, 4} TTR(4, 7) ={4, 5, 6, 7} TTR(7, 8) ={7, 8, 10} TTR(4, 8) = TTR(4,7) ∪ TTR(7,8) TTR(3, 8) =TTR(3,4) ∪ TTR(4,8) TTR(1, 9) =TTR(1,3) ∪ TTR(3, 8) ∪ {9}. Different from intervals, two-terminal regions can be nested within each other or overlap with their entry or exit nodes. Now we are ready to dene change localiza- tion. Proposition 1. Changes can be localized into the closest enclosing two-terminal region if and only if the changes only affect the nodes (other than the entry or exit nodes) of this region. Intuitively, a two-terminal region is a subgraph where everything coming from the outside of the region into the region goes through the entry node, and everything going from the inside of the region to the outside goes through the exit node. In REL (and hence in BPEL), a two-terminal region thus corresponds to a single construct. Shown in Figure 13, TTR(1, 3) corresponds to an “or” construct in REL and hence Figure 14. The overview of the dynamic updating approach Event CLR BPEL BizTalk server .Net a pp lication CIL Native code Execution unit Control unit Inference en g ine Profiler Hook AAR Weave Chan g e Install Check Initialize Inject advice [...]... Idea Group Inc is prohibited Aligning Business Processes with Enterprise Service Computing Infrastructure 55 BPMI (2005) Retrieved from http://www.bpmi.org/ BPMN specification (2004) Retrieved from http://www.bpmn.org/Documents/ BPMN%20V1-0%20May%203%202004.pdf Business process execution language for Web services, version 1.1 (2003) Retrieved from ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf... configurations of services in the measurement system that are applicable from different service providers with various conditions in pricing and service levels This gives ground for decisions on sourcing strategies and thereby facilitates the finding of the most adequate mix of services for an enterprise In this chapter, design principles of an appropriate measurement system for the financial performance of service. .. along with the decision about a service- oriented architecture on the process level Further examinations have to be undertaken regarding the selection of services that are combined in a company’s service portfolio Payments Related to Services Apart from evaluating monetary consequences of a service- oriented architecture, the decision about the sourcing structure of a service portfolio has to be made... optimising the service portfolio By evaluating each service entirely regarding its relevant out- and in-payments, various alternative compositions of a service portfolio can be calculated Payments for the evaluation of services can also be distinguished between the phases of development, operation, adaptation, and disintegration Quality of Services When choosing appropriate services for the company’s service. .. Figure 5 Service- portfolio measurement on the process level assessing services Elements of the Series of Payments of a Service Point in Time 0 Phase of Development Out-Payments - for building up relations to services provider for implementing the interface for integrating - the service Phase of Operation Out-Payments - for production of a service (if in-sourcing only) - for co-ordination of service. .. for performance measurement of a company’s service portfolio are required (Kaplan & Norton, 1992) In this chapter, these methods are referred to as service- portfolio measurement (SPM) In service- portfolio measurement, multiple perspectives of the profitability of service- oriented information systems have to be taken into account This can, for example, be seen from the work of Kaplan and Norton (1992,... be found in studies assessing the quality of service (QoS) in service- oriented enterprises (Cardoso, Sheth, Miller, Arnold, & Kochut, 2004; Wang, Chen, Wang, Fung, & Uczekaj, 2004) These contributions can well be used for operational service discovery and process control However, they do not provide decision support for finding the most profitable mix of services within the company’s portfolio For this... forms without written permission of Idea Group Inc is prohibited Aligning Business Processes with Enterprise Service Computing Infrastructure 57 Microsoft (2005) Net Retrieved from http://www.microsoft.com/net Nainani, B (2004) Closed loop BPM using standards based tools (Tech Rep.) Oracle Corp Retrieved from http://www.oracle.com/technology/products/ias/ bpel/pdf/bpm.closedloop.pdf Nigam, A., & Caswell,... by a certain service portfolio that a company is running on the basis of the architecture Each service available for a company within a certain process has to be evaluated and specified within the decision-support system The evaluation is based on payments, taking into account various pricing models of services This also comprises the operational availability of the service due to various service- level... (ERCIS), University of Münster, Germany Abstract This chapter addresses service- oriented information systems from a management perspective It is evident that running a service- oriented enterprise brings up new challenges for mana­ge­ment Given the technological opportunities, the challenge lies essentially in choosing the right mix of services on the basis of an appropriate architecture For this purpose, . prohibited. TTR (3, 4) = {3, 4} TTR(4, 7) ={4, 5, 6, 7} TTR(7, 8) ={7, 8, 10} TTR(4, 8) = TTR(4,7) ∪ TTR(7,8) TTR (3, 8) =TTR (3, 4) ∪ TTR(4,8) TTR(1, 9) =TTR(1 ,3) ∪ TTR (3, 8) ∪ {9}. Different from intervals,. Computer Programming, 34 (1), 1-54. Bitpipe. (2005). Retrieved from http://www.bitpipe.com/tlist/SLA-Management- Services.html Aligning Business Processes with Enterprise Service Computing Infrastructure. follows: TTR(1, 3) ={1, 2, 3} Figure 13. The correspondence of REL constructs and two-terminal regions ( ( a c + b ) ( d ( ( f i + g j ) ( k [p n] m q )* h )* ( p + e ) )* n o ) * TTR(1 ,3) TTR (3, 4)

Ngày đăng: 21/06/2014, 06:20

Từ khóa liên quan

Mục lục

  • Title Page

  • Copyright Page

  • Table of Contents

  • Preface

  • Acknowledgments

  • Section I: Business Aspects of Enterprise Service Computing

  • Ch I: Information Technology as a Service

  • Ch II: Aligning Business Processes with Enterprise Service Computing Infrastructure

  • Ch III: Service Portfolio Measurement (SPM): Assessing Financial Performance of Service-Oriented Information Systems

  • Section II: Enterprise Service Computing: Requirements

  • Ch IV: Requirements Engineering for Integrating the Enterprise

  • Ch V: Mobile Workforce Management in a Service-Oriented Enterprise: Capturing Concepts and Requirements in an Multi-Agent Infrastructure

  • Section III: Enterprise Service Computing: Modeling

  • Ch VI: Designing Enterprise Applications Using Model-Driven Service-Oriented Architectures

  • Ch VII: A Composite Application Model for Building Enterprise Information Systems in a Connected World

  • Ch VIII: Three-Point Service-Oriented Design and Modeling Methodology for Web Services Composition

  • Section IV: Enterprise Service Computing: Technologies

  • Ch IX: Data Replication Strategies in Wide-Area Distributed Systems

  • Ch X: Web Services vs. ebXML: An Evaluation of Web Services and ebXML for E-Business Applications

  • Ch XI: Leveraging Pervasive and Ubiquitous Service Computing

Tài liệu cùng người dùng

Tài liệu liên quan