文档库 最新最全的文档下载
当前位置:文档库 › RobustBPEL2 Transparent Autonomization in Business Processes through Dynamic Proxies

RobustBPEL2 Transparent Autonomization in Business Processes through Dynamic Proxies

RobustBPEL2 Transparent Autonomization in Business Processes through Dynamic Proxies
RobustBPEL2 Transparent Autonomization in Business Processes through Dynamic Proxies

RobustBPEL2: Transparent Autonomization in Business Processes through Dynamic Proxies
Onyeka Ezenwoye and S. Masoud Sadjadi Autonomic Computing Research Laboratory School of Computing and Information Sciences Florida International University 11200 SW 8th Street Miami, FL 33199 {oezen001,sadjadi}@cs.?https://www.wendangku.net/doc/0811121232.html, Abstract
Web services paradigm is allowing applications to interact with one another over the Internet. BPEL facilitates this interaction by providing a platform through which Web services can be integrated. However, the autonomous and distributed nature of the integrated services presents unique challenges to the reliability of composed services. The focus of our ongoing research is to transparently introduce autonomic behavior to BPEL processes in order to make them more resilient to the failure of partner services. In this work, we present an approach where BPEL processes are adapted by redirecting their interactions with partner services to a dynamic proxy. We describe the generative adaptation process and the architecture of the adaptive BPEL processes and their corresponding proxies. Finally, we use case studies to demonstrate how generated dynamic proxies are used to support self-healing and self-optimization in instrumented BPEL processes.
1 Introduction
Web services are facilitating the uptake of ServiceOriented Architecture (SOA) [3], allowing business organizations to electronically interact with one another over the Internet. In this architecture, reusable, self-contained and remotely accessible application components, which are exposed as Web services, can be integrated to create more course-grained aggregate services (e.g., a ?ight reservation service). For this, high-level work?ow languages such as BPEL [7] can be used to de?ne aggregate services (business processes) that constitute a number of related services (business functions). Unfortunately, these types of business processes are known to be very fragile, about 80 percent
of the total amount of time used in developing business processes is spent in exception management. The integration of multiple services, which might have been developed and hosted on heterogeneous environments, introduces new levels of complexity in management. Also, services interacting with aggregate services are often geographically scattered and communicate via the Internet. Given the unreliability of such communication channels, the unbounded communication delays, and the autonomy of the interacting services, it is dif?cult for developers of business processes to anticipate and account for all the dynamics of such interactions. In addition, the high-availability nature of some business processes requires them to work in the face of failure of their constituent parts [2]. It is then important to make aggregate services more resilient to the failure of their partner services. Autonomic computing [10] promises to solve the management problem by embedding the management of complex systems inside the systems themselves, freeing the users from potentially overwhelming details. A Web service is said to be autonomic if it encapsulates some autonomic attributes [9]. Autonomic attributes include self-con?guration, self-optimization, self-healing, and selfprotection. The focus of this work is to encapsulate selfhealing and self-optimizing behavior in business processes in order to make them more resilient to failure. We recently introduced RobustBPEL [8], a framework that provides a systematic approach to making existing aggregate Web services more tolerant to the failure. Using RobustBPEL, we demonstrated how an aggregate Web service, de?ned as a BPEL process, can be instrumented automatically to monitor its partner Web services at runtime. To achieve this, events such as faults and timeouts are monitored from within the adapted process. We showed how our adapted process is augmented with a static proxy that

replaces failed services with prede?ned alternatives. While in the previous work the proxy is statically bound to a limited number of alternative Web services, in this paper we extend the RobustBPEL framework to generate a proxy that dynamically discovers and binds to existing services. Because more appropriate services may become available after the composition and deployment of the BPEL process and its corresponding static proxy, it makes sense that upon failure or delay of any of the partner services of the BPEL process, an equivalent service can be discovered dynamically (at run-time) to serve as a substitute. In doing this, we improve the fault tolerance and performance of BPEL processes by transparently adapting their behavior. By transparent we mean that the adaptation preserves the original behavior of the business process and does not tangle the code that provides autonomic behavior with that of the business process [11]. This transparency is achieved by using a dynamic proxy that encapsulates the autonomic behavior (adaptive code). The rest of this paper is is structured as follows. Section 2 provides a background on some related technologies and gives a brief introduction to the RobustBPEL framework. Section 3 describes the dynamic proxy and how it is generated. In section 4 we use two examples as case studies to demonstrate the feasibility and usefulness of our approach. Section 5 contains some related work. Finally, some concluding remarks and a discussion on further research directions are provided in Section 6.
Web services. These services then become reusable components that can be the building blocks for more complex aggregate services. Currently search engines like Google, Yahoo! and MSN are being exposed as Web services and provide functions that range from simple queries, to generation of maps and driving directions. A business process that can be derived from the aggregation of such services would be one that, for instance, generates driving directions. As illustrated by Figure 1, the process could work by integrating two service: (1) a service that retrieves the addresses of nearby businesses; and (2) a service that gets the driving directions to a given address. This business process can then be used from the on-board computer of a car to generate driving directions to the nearest gas station, hotel, etc.
Figure 1. A Business Process that integrates remote components to create a new application that gets driving directions.
2 Background
In this section, we provide some background information for Web services, BPEL, Transparent Shaping and RobustBPEL. You can safely skip this section if you are familiar with all the above technologies.
2.1
Web Services & BPEL
To facilitate the creation of business processes, a highlevel work?ow language, such as Business Process Execution Language (BPEL) [7], is often used. BPEL provides many constructs for the management of a process including loops, conditional branching, fault handling and event handling (such as timeout). To make a BPEL process fault tolerant, BPEL fault handling activities (e.g., catch and catchAll constructs) can be used. We aim to separate the task of making a BPEL process more robust from the task of composing the business logic of the process.
A Web service is a software component that can be accessed over the Internet. The goal of the Web service architecture [3] is to simplify application-to-application integration. The technologies in Web services are speci?cally designed to address the problems faced by traditional middleware technologies in the ?exible integration of heterogeneous applications over the Internet. Its lightweight model has neither the object model nor programming language restrictions imposed by other traditional middleware systems (e.g., DCOM and CORBA). The interface to the functionality provided by a Web service is described in Web services Description Language (WSDL). To make a call on these functions, a messaging protocol such as SOAP can be used. Applications that provide speci?c business functions (e.g., price quotation) are increasingly being exposed as
2.2
Transparent Shaping & RobustBPEL
Transparent Shaping is a new programming model that provides dynamic adaptation in existing applications. The goal is to respond to the dynamic changes in their nonfunctional requirements (e.g., changes request by end users) and/or environments (e.g., changes in the executing environment) [11]. In transparent shaping, an application is augmented with hooks that intercept and redirect interaction to adaptive code. The adaptation is transparent because it preserves the original functional behavior and does not tangle the code that provides the new behavior (adaptive code) with the application code. By adapting existing applications, transparent shaping aims to achieve a separation of concerns [5]. That is, enabling the separate development

of the functional requirements (the business logic) from the non-functional requirements of an application.
(a) Sequence of interactions in a typical aggregate Web service.
this adapt-ready process and provides the same port types as those of the monitored Web services (i.e., pti and ptj ). The static proxy in its turn forwards the request to an equivalent Web service, which is “hardwired” into the code of this proxy at the time it was generated. This means that the number of choices for equivalent services are limited to those known at the time the static proxy was generated. In this work, we make the following assumptions: (1) two services are equivalent, if they implement the same port type; (2) Web service partners are stateless and idempotent. A port type is similar to an interface in the Java programming language. It is possible for two applications to be functionally equivalent without necessarily having the exact same interface. When this occurs, a wrapper interface/service can be used to harmonize the differences in their interfaces. We show as example of this scenario in our case studies.
2.3
(b) Sequence of interactions in the adapt-ready aggregate Web service.
Why Dynamic Proxies?
Figure 2. Architectural diagrams showing the difference between the sequence of interactions among the components in a typical aggregate Web service and its generated adaptready version.
RobustBPEL [8] is a framework that we developed previously as part of the transparent shaping programming model. Using RobustBPEL, we can automatically generate an adapt-ready version of an existing BPEL process. We note that in our previous study, we only focused on adding self-healing (fault-tolerant) behavior to existing BPEL processes. Figure 2 shows the differences between the sequence of interactions among the components in a typical aggregate Web service and its corresponding generated adapt-ready version. In a typical aggregate Web service (Figure 2(a)), ?rst a request is sent by the client program, then the aggregate Web service interacts with its partner Web services (i.e., W S1 to W Sn ) and responds to the client. If one of the partner services fails, then the whole process is subject to failure. To avoid such situations, adapt-ready process monitors the behavior of it partners and tries to tolerate their failure. The developer can select a set of Web service partners to be monitored. For example, in Figure 2(b) W Si and W Sj have been selected for monitoring. The adapt-ready process monitors these two partner Web services and in the presence of faults it will forward the corresponding request to the static proxy. The static proxy is generated speci?cally for
Given the rapid uptake of the service oriented programming model, we expect the emergence of numerous services that are functionally equivalent and thus can be substituted. For instance, in our driving-direction example (Figure 1), if the default map generation service provided by Google fails, it should be possible to substitute this service with that of MSN, Yahoo! or Mapquest. In this paper, we extend RobustBPEL in two directions: (1) by replacing static proxies with dynamic proxies that can ?nd equivalent services at run time (described in Section 3); and (2) by adding self-optimizing behavior in existing BPEL processes, which is demonstrated using the case studies in Section 4.
3
Dynamic Proxies
In our approach, a dynamic proxy is a Web service that corresponds to a speci?c adapt-ready BPEL process and its job is to discover and bind equivalent Web services. In this section, we ?rst provide an architecture that shows the high-level functionality of a dynamic proxy and its interactions with other services in the architecture. Next, we explain how the adapt-ready BPEL process is instrumented and how it interacts with the dynamic proxy. Finally, we show a high-level view of the RobustBPEL2 Generator.
3.1
High-Level Architecture
Figure 3 illustrates the architectural diagram of an application using an adapt-ready BPEL process augmented with its corresponding dynamic proxy. This ?gures shows the steps of interactions among the components of a typical

adapt-ready BPEL process. Similar to a static proxy, the interface for the generated dynamic proxy is exactly the same as that of the monitored Web service. Thus, the operations and input/output variables of the proxy are the same as that of the monitored invocation. When more than one service is monitored within a BPEL process, the interface for the speci?c proxy is an aggregation of all the interfaces of the monitored Web services. For example, the dynamic proxy in Figure 3 has pti and ptj , which are the port types of the two monitored Web services (namely, W Si and W Sj ). At runtime, if a monitored service fails (or an invocation timeout occurs), the input message for that service is used as input message for the proxy. The proxy invokes the equivalent service with that same input message. A reply from the substitute service is sent back to the adapted BPEL process via the proxy.
the program at which adaptive code can be introduced at run time. Key to identifying joinpoints is knowing where in the BPEL process sensing and actuating are required and inserting appropriate code (hooks) to do so. Because a BPEL process is an aggregation of services, the most appropriate place to insert interception hooks is at the interaction joinpoints (i.e., the invoke instructions) [11]. The monitoring code we insert is in the form of standard BPEL constructs to ensure the portability of the modi?ed process. We adapt the BPEL process by identifying points in the process at which external Web services are invoked and then wrapping each of those invocations with a BPEL scope that contains the desired fault and event handlers. A fault can be a programmatic error generated by a Web service partner of the BPEL process or unexpected errors from the Web service infrastructure. The following snippet BPEL code (Figure 4) is an example of a service invocation in BPEL. Lines 3 and 4 identify the interface (portType) of the partner and what method (operation) the invocation wishes to call.
1. 7.
Figure 4. An unmonitored invocation. The invocation showed in Figure 4 is identi?ed and wrapped with monitoring code. The code in Figure 5 shows what the invocation looks like after the monitoring code is wrapped around it. The unmonitored invocation is ?rst wrapped in a scope container which contains fault and event handlers (lines 5-14 and 15-19 respectively in Figure 5). A catchAll fault handler is added (lines 6-13) to the faultHandlers to handle any faults generated as a result of the invocation of the partner Web service. The faulthandling activity is de?ned in lines 7-12, which basically forwards the request to the dynamic proxy. When a fault is generated by the partner service invocation, this fault is caught by the catchAll and the proxy service is invoked to substitute for the unavailable or failed service. For the event handler, an onAlarm event handler (lines 16-18) is used to specify a timeout. An onAlarm clause is used to specify a timeout “event” in BPEL. A timeout can be used, for instance, to limit the amount of time that a process can wait for a reply from an invoked Web service. A throw activity is inserted inside the onAlarm event handler (line 17) as the action that is carried out upon the timeout. If the partner service fails to reply within the time stipulated in the timeout event, the throw activity generates a standard BPEL forcedTermination fault. This fault
Figure 3. Architectural diagram showing the sequence of interactions among the components in an adapt-ready BPEL process augmented with its corresponding dynamic proxy. Although the adapt-ready BPEL process remains a functional Web service and the proxy is an autonomic Web service (encapsulates autonomic attributes), functional Web services can behave in an autonomic manner by using autonomic Web services [9]. By replacing failed and delayed services with substitutes, the proxy service provides self-healing and self-optimization behavior to the BPEL process, thereby making the BPEL process autonomic.
3.2
Incorporating Generic Hooks inside the Adapt-Ready BPEL Processes
Following the Transparent Shaping programming model [11], we ?rst need to incorporate some generic hooks at sensitive joinpoints in the original BPEL process. These joinpoints are certain points in the execution path of

1. 2. 5. 6. 7. 13. 14. 15. 16. 17. 18. 19. 20. 26.
tions, in other words, mapping WSDL to UDDI. Information about the WSDL service and port are stored under components of the UDDI data model. Data registered from the WSDL includes the URL for each service port. The dynamic proxy makes queries to the UDDI registry via the API provided by JUDDI, which is an open source Java implementation of the UDDI speci?cation. The query term is ?xed since with the port types of the monitored services is known during adaptation. At this stage of our work, no selection criteria is used when multiple services are discovered, although some selection policies can be easily incorporated into the proxy to introduce some added quality-ofservice.
3.4
The Generation Process in RobustBPEL2
part of
Figure 5. A monitored invocation. forces the monitored invocation to terminate. The generated forcedTermination fault is then caught by the fault handler and the proxy service is invoked (lines 7-12) as a substitute.
3.3
Interaction of Dynamic Proxy with the Registry Service
When the dynamic proxy is invoked upon failure of a monitored service, the proxy makes queries against the registry service to ?nd equivalent services. At runtime, any service provider can publish new equivalent services with the registry, which can potentially substitute a failed service in the future. The registry technology used in the RobustBPEL2 framework is the Universal Description, Discovery and Integration protocol (UDDI), which is a speci?cation for the publication and discovery of Web services. UDDI speci?es a set of data structures, messages and API for creating and maintaining information about Web services in distributed registries. The registry allows for three categories of information to be published: (1) white pages that contain contact information such as the name, address and telephone number of a given business; (2) yellow pages that contain information that categorizes businesses based on some existing taxonomies; and (3) green pages that contain technical information about the Web services provided by the published businesses (this can include the URL of the service and its WSDL). In order to adequately categorize services in a UDDI registry, certain conventions have to be adhered to. The method of classi?cation we use focuses on registering services based on the information in their WSDL descrip-
RobustBPEL2, we developed the that automatically generates the adapt-ready version of a given BPEL process and its associated dynamic proxy. The input to this generator is a con?guration ?le. Figure 6 shows the contents of a con?guration ?le that has all the required information: lines 2-10 specify the input needed for the generation of the adapt-ready BPEL process, while lines 11-36 specify that for the generation of the proxy. As illustrated in Figure 7, ?rst, the Parser separates the information needed for generating adapt-ready BPEL process and for generating the dynamic proxy and sends them to the corresponding compilers. Next, each of these two generators uses the information provided by the parser and retrieves the required ?les from the local disk and starts its compilation process. The Adapt-Ready BPEL Compiler retrieves the original BPEL process using the location of the original BPEL ?le, which is stated in line 5. It then uses the element (lines 7-9) to ?nd out the names of the invocations to be monitored. An element (line 8) with a “*” as the value of the name attribute declares that all invocations should be monitored. With all this information, the Adapt-Ready BPEL Generator is ready to starts its compilation process. The Dynamic Proxy Compiler gets the location of the proxy template is on line 12 and the necessary information about every monitored service type (classi?ed by portType) from the tags (lines 19-34). The information needed to generate the proxy code to ?nd and bind to services that implement the portType pti is listed within the elements of lines 20-30 and the operations of every monitored invocation of the portType are listed within the operations element. Next, the The Dynamic Proxy Generator ?nds out about the location of the binding stubs for services of the portType are in line 29 (this stub package is associated with the proxy as a Java
RobustBPEL2 Generator
As

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 18. 19. 20. 23. 24. 26. 27. 29. 30. 31. 34. 35. 36. 37.
Figure 7. Inputs and outputs of the dynamic proxy generator.
Figure 6. Con?guration ?le for the generator import statement). It then gets the information needed to query the registry for services that implement the portType from the tag (lines 27-28). Finally, it gets the the package for the proxy class from Line 35 (the broker binding stubs are part of this package) and compiles the dynamic proxy.
words corrected (the phrase is unchanged if the spellings are correct). The reply from the Google service is used to create keyword search of the Amazon bookstore via the Amazon Web service. From this original Google-Amazon process, we used the generator to generate the adapt-ready process. For this adaptation we have selected to have the generator only adapt the invocation of the Google spell-checker. We then found another publicly available Spell-checker Web service from Cydne to act a substitute for the Google service. There is a slight difference between the interfaces of the Google and Cydne spell-checkers. We used a wrapper Web service for the Cydne service in order to harmonize the interfaces. 4.1.1 The Experiment As illustrated in Figure 8, client requests are made to the BPEL process (labeled 1), which results in the invocations to the Google Web services (labeled 2). To simulate the unavailability of the Google service, we changed the URL of the service from within the Google-Amazon process, to point to a non-existent address. Thus upon the imminent failure of the invocation for the Google service, the adaptready BPEL process invokes the dynamic proxy (labeled 3). The dynamic proxy ?rst queries the JUDDI registry for substitute services (labeled 4). As a result of the query, it ?nds the wrapper Web service for the Cydne spell-checker. The proxy then binds to the wrapper service, which in turn binds to the Cydne spell-checker with the input keywords (labeled 5 and 6, respectively). The result of this invocation is sent back to the adapt-ready Google-Amazon process and then used as input to query the Amazon store service. For example, we used “Computer Algorthms” as input keyword to the process, Google (or the wrapper) corrected it to “Computer Algorithms”, and Amazon found this book: “Bruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition”.
4 Case Studies
In this section, we use two case studies to demonstrate the self-healing and self-optimization behavior of the generated BPEL processes and their respective dynamic proxies. For each case study, we start by describing the application, then we present the con?guration of the experiment environment. Finally, we show the results of the experiment.
4.1
The Google-Amazon Process
The Google-Amazon business process integrates the Google Web service for spelling suggestions with the Amazon E-Commerce Web service for querying its store catalog. The business process takes as input a phrase (keywords) which is sent to the Google spell-checker for corrections. If any word in the input phrase is misspelled, the Google spellchecker sends back as reply the phrase with the misspelled

4.2.2 Self-Healing and Self-Optimization. In order to demonstrate the autonomic behavior of the generated BPEL process and its corresponding dynamic proxy, we have programmatically altered the Loan Approver Web service to generate faults and a delay of two seconds after a certain number of successive invocations. The successive invocations to the Loan Approver Web service are the results of requests to the BPEL process made by the client application. These requests are mapped on the X axis of the chart shown in Figure 10. As the plot for the original BPEL shows, for the successive invocations 11 to 20, the Loan Approver Web service generates a fault for those invocations, and for the invocations 31 to 40, the Loan Approver Web service is made to delay for 2 seconds before sending back a reply to the BPEL process. We set the timeout duration for the Loan Approval BPEL process to 1 second.
Figure 8. The sequence of interactions among the components in the GoogleAmazon case study.
4.2
The Loan Approval Process
The Loan-Approval process is a commonly used sample BPEL process. The Loan-Approval BPEL process is an aggregate Web service composed of two other Web services: a low-risk assessor service (LoanAssessor) and a high-risk assessor service (LoanApprover). The LoanApproval process implements a business process that uses its two partner services to decide whether a given individual quali?es for a given loan amount. Both the business process and the risk assessment services are deployed locally. 4.2.1 The Experiment As illustrated in Figure 9, client requests are made to the BPEL process (labeled 1), which results in the invocations to the partner Web services (labeled 2). Upon failure of these partner services or an invocation timeout, the adaptready BPEL process invokes the dynamic proxy (labeled 3). The dynamic proxy ?rst queries the JUDDI registry for substitute services (labeled 4). The result of the query is used to bind the substitute service and forward the requests to this service (labeled 5).
Figure 10. This chart shows the comparison between the request completion time for the original and the robust BPEL processes.
Figure 9. The sequence of interactions among the components in the Loan Approval case study.
Figure 10 plots the request completion time for the two sets of experiments. According to the experiment setup, the ?rst 10 request are completed normally and the average completion time for both the original and the robust sets of experiments are almost the same (about 47 milliseconds). This result indicates that in normal operation, the overhead added by the robust BPEL process is negligible. Right after the completion of the ?rst 10 requests, the Loan Approver Web service starts throwing exceptions for the next 10 requests. Although Figure 10 shows that the completion time for the original BPEL stays as before, all the requests are returned with exception. The robust BPEL process, however, catches all such exceptions. The plot for robust BPEL in Figure 10 shows an increase in the completion time, which is about 127 milliseconds. For the requests 31 to 40, the Loan Approver Web service responds to the requests after 2 seconds of delay. As

the time out in the robust BPEL process is set to 1 second, the robust BPEL process withdraws its invocations to the original Web services and uses the substitute Web service. In this way, the robust BPEL process completes the request in almost half the time as that of the original BPEL process.
5 Related Work
Baresi’s approach [1] to monitoring involves the use of annotations that are stated as comments in the source BPEL program and then translated to generate a target monitored BPEL program. This approach requires modifying the original BPEL processes manually and the annotated code is scattered all over the original code. The manual modi?cation of BPEL code is not only dif?cult and error prone, but also hinders maintainability. Char? et al [4] use an aspect-based container to provide middleware support for BPEL. The process container is the runtime environment for the BPEL process. All interactions go through the container which plugs in support for non-functional requirements. Aspects specify what and how SOAP messages can be modi?ed to add, for instance, security information to the header. This framework is different form our because it requires a purpose built BPEL engine. Also, the adaptation is done at a much lower level (the messaging layer). Erradi et al. [6] provide reliability through a policy driven middleware called Web Services Message Bus (wsBus), which is used to transparently enact recovery actions. The wsBus intercepts the execution of composite services and transparently provides recovery services based on an extensible set of recovery policies. The wsBus also enforces SLA agreements. This approach is modular and separates the business logic of the process from the QoS requirements, however, adaptation is done at a much lower messaging layer. The works mentioned above, although are able to provide some means of monitoring for singular or aggregate Web services, they do not dynamically replace the delinquent services once failure or extensive delay has been detected.
In our future work, we plan to address the following issues. First, substituting service implementations at runtime may lead to failures on the client-side. Thus it is important to be able to detect and resolve potential integration problems from discovered equivalent services. Also, discovered services may fail so we aim to augment the proxy with a mechanism to deal with such problems. Finally, rather than the current speci?c proxies, a generic proxy that has a standard interface and works for all monitored services would make life much simpler for developers.
References
[1] L. Baresi, C. Ghezzi, and S. Guinea. Smart monitors for composed services. In ICSOC ’04: Proceedings of the 2nd international conference on Service oriented computing, pages 193–202. ACM Press, 2004. [2] K. P. Birman, R. van Renesse, and W. Vogels. Adding high availability and autonomic behavior to web services. In Proceedings of the 26th International Conference on Software Engineering (ICSE 2004), pages 17–26, Edinburgh, United Kingdom, May 2004. IEEE Computer Society. [3] D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, and D. Orchard. Web Services Architecture. W3C, 2004. [4] A. Char? and M. Mezini. An aspect based process container for BPEL. In Proceedings of The First Workshop on AspectOriented Middleware Developement, Genoble, France, November 2005. [5] E. W. Dijkstra. Structured programming. Software Engineering Techniques, edited by Buxton and Randell (available from NATO, Brussels), pages 84–87, 1970. [6] A. Erradi and P. Maheshwari. wsBus: QoS-aware middleware for relaible web services interaction. In IEEE International Conference on e-Technology, e-Commerce and eService, Hong Kong, China, 2005. [7] O. Ezenwoye and S. M. Sadjadi. Composing aggregate web services in BPEL. In Proceedings of The 44th ACM Southeast Conference, Melbourne, Florida, March 2006. [8] O. Ezenwoye and S. M. Sadjadi. Enabling robustness in existing BPEL processes. In Proceedings of the 8th International Conference on Enterprise Information Systems (ICEIS-06), May 2006. [9] S. Gurguis and A. Zeid. Towards autonomic web services: Achieving self-healing using web services. In Proceedings of DEAS’05, Missouri, USA, May 2005. [10] J. O. Kephart and D. M. Chess. The vision of autonomic computing. IEEE Computer, 36(1):41–50, 2003. [11] S. Masoud Sadjadi and P. K. McKinley. Using transparent shaping and web services to support self-management of composite systems. In Proceedings of the International Conference on Autonomic Computing (ICAC’05), Seattle, Washington, June 2005.
6 Conclusion and Future Work
We presented an approach to transparently adapting BPEL processes to tolerate run-time and unexpected faults and to improve the performance of overly loaded Web services. We have introduced the dynamic proxy and demonstrated how it is used to encapsulate autonomic behavior. With the use of case studies, we demonstrated the self-healing and self-optimization behavior of the dynamic proxy.

透明模式Transparent Mode

Transparent Mode 在安全或者路由产品上,由于接口都是三层接口所以配置时候需要IP地址。当然有些情况,指的是有些情况,当IP地址不够用,或者其他某些蛋疼的原因没有IP地址时候。怎么办?接口运行在透明模式,也就是运行在2层中。 那么运行2层有毛好处呢? 透明模式的防火墙就好像是一台网桥(非透明的防火墙好像一台路由器),网络设备(包括主机、路由器、工作站等)和所有计算机的设置(包括IP地址和网关)无须改变,同时解析所有通过它的数据包,既增加了网络的安全性,又降低了用户管理的复杂程度。就是不配IP地址,直接接上就用,但是安全策略还有效。这不是很帅么。 当然再帅也有遗憾,就想SRX 也有些feature 在透明模式下不支持一样: Note: Transparent mode is supported only for IPv4 traffic. 首先透明模式只支持IPv4 Note: Not all security features are supported in transparent mode: ?NAT is not supported. ?IPsec VPN is not supported. ?For ALGs, only DNS, FTP, RTSP, and TFTP ALGs are supported. Other ALGs are not supported. 另外透明模式不支持NAT IPSEc vpn 等。 尽管2层桥能力真心不错,在SRX上也能用。类似于MX上的桥工恩呢该。但是有些MX支持的功能在SRX上是不支持的。毕竟他是安全产品么。 ?Layer 2 control protocols—These protocols are used on MX Series routers for Rapid Spanning Tree Protocol (RSTP) or Multiple Spanning Tree Protocol (MSTP) in customer edge interfaces of a VPLS routing instance. ?Virtual switch routing instance—The virtual switching routing instance is used on MX Series routers to group one or more bridge domains. ?Virtual private LAN services (VPLS) routing instance—The VPLS routing instance is used on MX Series routers for point-to-multipoint LAN implementations between a set of sites in a VPN. In addition, the SRX Series devices do not support the following Layer 2 features:

完全版英语词汇学名词解释

第一章word 1.Word --- A word is a minimal free form of a language that has a given sound and meaning and syntactic funtion. 第三章formation 1 1. Morpheme --- A morpheme is the smallest functioning unit in the composition of words. 2. Allomorph --- Some morphemes are realized by more than one morph according to their position in a word. Such alternative morphs are know as allomorphs. 3. Free morphemes (Free root) --- They are morphemes which are independent of other morphemes. 4. Bound Morphemes--- They are morphemes which cannot occur as separate words. 5. Bound root --- A bound root is that part of the word that carries the fundamental meaning just like a free root. Unlike a free root, it is a bound form and has to combine with other morphemes to make words. 6. Affixes --- Affixes are forms that are attached to words or word elements to modify meaning or function. 7. Inflectional affixes --- Affixes attaches to the end of words to indicate grammatical relationships are known as inflectional morphemes. 8. Derivational affixes --- Derivational affixes are affixes added to other morphemes to create new words. 9. Prefixes --- Prefixes are affixes that come before the word. 10. Suffixes --- suffixes are affixes that come after the word. 11. Roo t --- A root is the basic form of a word which cannot be further analysed without total loss of identity. 12. Stem--- a stem can be defined as a form to which affixes of any kind can be added. 第四章formation 2 1. Affixation --- affixation is generally defined as the formation of words by adding word-forming or derivational affixes to stems. 2. Prefixation --- is the formation of new words by adding prefixes to stems. Suffixation--- is the formation of new words by adding suffixes to stems. 3. Compounding(Compositon)-- is the formation of new words by joining two or more stems. 4. Conversion-- is the formation of new words by converting words of one class to another class. 5. Blending-- is the formation of new words by combined by parts of two words or a word plus a plus a part of another word. 6. Clipping- is the formation of new words by shortening a longer word by cutting a

高中英语单词天天记transparent素材

· transparent · adj. [tr?ns'p?r?nt] · · 双解释义 · 透明的pass through so that objects behind can be clearly seen · 含意清楚的,显而易见的easy to understand; clear; there is no double · 词汇搭配 ? ?transparent lid 透明的盖子 ?transparent lie 明显的谎言 ?transparent air 透明的空气 ?transparent honesty〔sincerity〕绝对诚实〔忠诚〕 ? ?transparent to 透得过 · 句型例句 ? 用作定语 ▲~+n. She dressed a transparent silk blouse.她穿了一件薄得透明的丝绸衬衣。 It's a transparent lie.这是不折不扣的谎言。 用作表语 ▲S+be+~ The window glass is transparent.窗玻璃是透明的。 The meaning of this passage seems quiet transparent.这一段的意思看来是相当清楚的。 ▲S+be+~+that-clause The water is so transparent that we can see the fishes swimming.水清澈

透明,可以看到鱼儿游来游去。 ▲It is/was+~+that-clause It was transparent that she was irritated.显然她是生气了。 ? · 词语辨异 ? transparent, clear 这两个词都可表示“透明的”。transparent不强调清晰,只表示能看得见; clear 指视线不受阻挡,强调清楚,不模糊。 ? · 补充资料 ? [同义词] apparent, clear, direct, frank, open [反义词] ambiguous, unclear [词源]<中古拉丁语transparens(透明的) ?

韩国HJT胶带对照表

Date : May 30, 2011 Product No Thickness (mm)Adhesive Carrier Liner Color Adhesion (g/inch)Heat Resistant (℃)Characters Application Match Grade Size #6150.12Acrylic Non-Woven Paper White 1300100Developed for PP injection with Foam,Rubber Electronic, Home, Miscellaneous products 1,000mm(W)*100mt #6550.06Acrylic Non-Woven Paper White 700120Thin thickness, Strong adhesion, Easy stick Packaging of electrical appliances, digital products 1,000mm(W)*100mt #6700.07Acrylic Non-Woven Paper White 800120Thin thickness, Strong adhesion, Easy stick Packaging of electrical appliances, digital products 3M 90751,000mm(W)*100mt #61000.10Acrylic Non-Woven Paper White 1100120Packaging of electrical appliances, digital products tesa 609751,000mm(W)*100mt #6130 0.13 Acrylic Non-Woven Paper White 1200 120 Packaging of electrical appliances, digital products tesa 60976 , 3M 64081,000mm(W)*100mt #61500.15Acrylic Non-Woven Paper White 1400120Packaging of electrical appliances, digital products tesa : 60980 , 49403M : 9448 , 9786 , 9070 , 9080 1,000mm(W)*100mt #6126N 0.13Acrylic Non-Woven Paper Ivory 1600120FR type of #6126 1,000mm(W)*100mt #6126F 0.14Acrylic Non-Woven Paper White 16001203M 90801,000mm(W)*100mt #6126P 0.12Acrylic Non-Woven Paper White 1600120Suitable for the metal, injection & plastic product 3M 90701,200mm(W)*100mt #8500.06Acrylic Pet Film Paper Clear 950100tesa 49723M : 9009 , 9868 1,000mm(W)*100mt #8700.07Acrylic Pet Film Paper Clear 1000100tesa 49803M 936 1,000mm(W)*100mt #81000.10Acrylic Pet Film Paper Clear 1300100tesa 49823M : 9828 , 98691,000mm(W)*100mt tesa 4928 3M : 9495MP , 9690Thin thickness, Excellent cohesion &heat resistance Sealing & insulation of Cell phone, Digital products Strong adhesion, Easy stick, Good holding power Double side adhesive Tape of Hyonjin Chemical Co., Ltd. Strong adhesion, Easy stick, Good holding power For Marking and Labeling, Mounting of plastics, name plate. Apply to huge numbers of products Superior tensile strength, Strong adhesion, Good holding power Suitable for foam, CR, EPDM, PU & rough surface materials #81300.13Acrylic Pet Film Paper Clear 13001001,000mm(W)*100mt #81500.15Acrylic Pet Film Paper Clear 1300120tesa 49673M 9495LE 1,000mm(W)*100mt #82000.20Acrylic Pet Film Paper Clear 1600120tesa 4965 3M : 9088 , 9887 , 9071 1,000mm(W)*100mt #911 1.00Acrylic IXPE Foam Paper Black&White 250080Accessories & micellaneous goods 1,000mm(W)*100mt #911PET 1.00Acrylic IXPE Foam Paper Black&White 250080Accessories & micellaneous goods 1,000mm(W)*100mt #5306W 0.60Acrylic Acrylic Foam PE Film Black&White 3000120900mm(W)*33mt #5308GG 0.80Acrylic Acrylic Foam PE Film Black&White 3200120900mm(W)*33mt #5308GGD 0.80Acrylic Acrylic Foam PE Film Black&White 4000120900mm(W)*33mt #5308GGN 0.80Acrylic Acrylic Foam PE Film Black&White 6000120900mm(W)*33mt #5311WN 1.10Acrylic Acrylic Foam Paper White 5000120900mm(W)*33mt #5311WD 1.10Acrylic Acrylic Foam Paper Black&White 3400120900mm(W)*33mt #5311GN 1.10Acrylic Acrylic Foam Paper Black&White 6000120900mm(W)*33mt #5304GN 0.40Acrylic Acrylic Foam Paper Black&White 4000120900mm(W)*33mt #5311TP 1.10Acrylic Acrylic Foam PE Film Transparent 5000120900mm(W)*33mt #5305TP 0.50 Acrylic Acrylic Foam PE Film Transparent 3000 120 900mm(W)*33mt Superior holding power, Heat resistance, Strong adhesion Excellent adhesion & Strong Heat resistance, Good holding power,Emblems, Accessories, Side molding, Mount panel

德国表面镀层缩写

H e r a u s g e b e r N o r m A u s f üh r u n g s -a r t / A b k ür z u n g S c h i c h t d i c k e i n μm M e t a l l P a s s i v i e r u n g / B e m e r k u n g V e r s i e g e l u n g D I N 50961 B e z e i c h n u n g = K o t s c h -B e z e i c h n u n g C h r o m -6- I n f o r m a t i o n N67F 821 01>5Zink transparent passiviert (Gestell)ohne Fe/Zn5/B cr(VI)-frei N67F 821 02>5Zink transparent passiviert (Trommel)ohne Fe/Zn5/B cr(VI)-frei N67F 822 01>5Zink dickschicht passiviert (Gestell)ohne Fe/Zn5/A cr(VI)-frei N67F 822 02>5Zink dickschicht passiviert (Trommel)ohne Fe/Zn5/A cr(VI)-frei N67F 822 05>8Zink dickschicht passiviert (Gestell)ohne Fe/Zn8/A cr(VI)-frei N67F 822 06 >8Zink dickschicht passiviert (Trommel) ohne Fe/Zn8/A cr(VI)-frei GN V AR.01107.31 8-25Zink-Nickel transparent passiviert ohne Fe/ZnNi8-25/A cr(VI)-frei GN V AR.01107.32 8-25Zink-Nickel transparent passiviert vorgeschrieben Fe/ZnNi8-25/A/T2cr(VI)-frei A5>5Zink nicht passiviert Fe/Zn5cr(VI)-frei ZNT >5Zink dickschicht passiviert Fe/Zn5/A cr(VI)-frei ZNFE SW >5Zink-Eisen schwarz passiviert vorgeschrieben Fe/ZnFe5/F/T2cr(VI)-frei ZNFE SI >5Zink-Eisen dickschicht passiviert vorgeschrieben Fe/ZnFe5/A/T2cr(VI)-frei ZNNI SI >6Zink-Nickel transparent passiviert Fe/ZnNi6/A cr(VI)-frei ZNNIV SI >6Zink-Nickel transparent passiviert vorgeschrieben Fe/ZnNi6/A/T2cr(VI)-frei SN >8Zinn - Fe/Sn8cr(VI)-frei CUG >12Kupfer - Fe/Cu12 cr(VI)-frei DBL 8451.1110-12Zink gelb chromatiert vorgeschrieben Fe/Zn10-12/C enth?lt cr(VI)DBL 8451.1210-12Zink blau passiviert Fe/Zn10-12/B cr(VI)-frei DBL 8451.1510-12Zink transparent passiviert Fe/Zn10-12/A cr(VI)-frei DBL 8451.166-8Zink transparent passiviert Fe/Zn6-8/A cr(VI)-frei DBL 8451.1720-24Zink gelb chromatiert Fe/Zn20-24/C enth?lt cr(VI)DBL 8451.1810-12Zink gelb chromatiert vorgeschrieben Fe/Zn10-12/C/T2enth?lt cr(VI)DBL 8451.216-8Zink gelb chromatiert Fe/Zn6-8/C enth?lt cr(VI)DBL 8451.226-8Zink blau passiviert Fe/Zn6-8/B cr(VI)-frei DBL 8451.28>8Zink gelb chromatiert vorgeschrieben Fe/Zn8/C/T2enth?lt cr(VI)DBL 8451.6210-12Zink-Nickel transparent passiviert Fe/ZnNi10-12/A cr(VI)-frei DBL 8451.6510-12Zink-Nickel transparent passiviert vorgeschrieben Fe/ZnNi10-12/A/T2cr(VI)-frei DBL 8451.66 10-12 Zink-Nickel transparent passiviert vorgeschrieben Fe/ZnNi10-12/A/T2 cr(VI)-frei N67F DBL 8451 GS 90010 GN V AR.01107 Daimler-Benz BEHR BMW Bosch

英语词汇学名词解释

英语词汇学笔记之“名词解释篇” 1.Word --- A word is a minimal free form of a language that has a given sound and meaning and syntactic funtion. 2. Morpheme --- A morpheme is the minimal significant element in the composition of words. 3. Free morphemes or Content morphemes (Free root)--- They are morphemes that may constitute words by themselves : cat, walk. 4. Bound Morphemes or Grammatical morphemes--- They are morphemes that must appear with at least one other morpheme, either bound or free : Catts, walk+ing. 5. Bound root --- A bound root is that part of the word that carries the fundamental meaning just like a free root. Unlike a free root, it is a bound form and has to combine with other morphemes to make words. Take -dict- for example: it conveys the meaning of "say or speak" as a Latin root, but not as a word. With the prefix pre-(=before) we obtain the verb predict meaning "tell beforehand". 6. Affixes --- Affixes are forms that are attached to words or word elements to modify meaning or funtion. 7. Inflectional morphemes or Inflectional affixes --- Affixes attaches to the end of words to indicate grammatical relationships are inflectional ,thus known as inflectional morphemes. There is the regular plural suffix -s(-es) which is added to nouns such as machines, desks. 8. Derivational morphemes or Derivational affixes--- Derivational affixes are affixes added to other morphemes to create new words. 9. Prefixes --- Prefixes are affixes that come before the word, such as, pre+war. 10. Suffixes --- suffixes are affixes that come after the word, for instance, blood+y. Derivational morphemes/ derivational affixes --- A process of forming new words by the addition of a word element. Such as prefix, suffix, combing form to an already existing word. Prefixation ---- is the formation of new words by adding prefix or combing form to the base. (It modify the lexical meaning of the base) Suffixation--- is the formation of a new word by adding a suffix or combing form to the base and usually changing the word-class of the base. Such as boy. Boyish (noun- adjective) 11. Roo t --- A root is the basic form of a word which cannot be further analysed without total loss of identity. 12.Opaque Words--Words that are formed by one content morpheme only and cannot be analysed into parts are called opaque words, such as axe, glove. 13. Transparent Words--Words that consist of more than one morphemes and can be segmented into parts are called transparent words: workable(work+able), door-man(door+man).

自考英语词汇学名词解释

词汇学名词解释 1. Word --- A word is a minimal free form of a language that has a given sound and meaning and syntactic funtion. 2. Morpheme --- A morpheme is the minimal significant element in the composition of words. 3. Free morphemes or Content morphemes (Free root) --- They are morphemes that may constitute words by themselves : cat, walk. 4. Bound Morphemes or Grammatical morphemes --- They are morphemes that must appear with at least one other morpheme, either bound or free : Catts, walk+ing. 5. Bound root --- A bound root is that part of the word that carries the fundamental meaning just like a free root. Unlike a free root, it is a bound form and has to combine with other morphemes to make words. Take -dict- for example: it conveys the meaning of "say or speak" as a Latin root, but not as a word. With the prefix pre-(=before) we obtain the verb predict meaning "tell beforehand". 6. Affixes --- Affixes are forms that are attached to words or word elements to modify meaning or funtion. 7. Inflectional morphemes or Inflectional affixes --- Affixes attaches to the end of words to indicate grammatical relationships are inflectional ,thus known as inflectional morphemes. There is the regular plural suffix -s(-es) which is added to nouns such as machines, desks. 8. Derivational morphemes or Derivational affixes --- Derivational affixes are affixes added to other morphemes to create new words. 9. Prefixes --- Prefixes are affixes that come before the word, such as, pre+war. 10. Suffixes --- suffixes are affixes that come after the word, for instance, blood+y. Derivational morphemes/ derivational affixes --- A process of forming new words by the addition of a word element. Such as prefix, suffix, combing form to an already existing word. Prefixation ---- is the formation of new words by adding prefix or combing form to the base. (It modify the lexical meaning of the base) Suffixation--- is the formation of a new word by adding a suffix or combing form to the base and usually changing the word-class of the base. Such as boy. Boyish (noun- adjective) 11. Root --- A root is the basic form of a word which cannot be further analysed without total loss of identity. 12. Opaque Words--Words that are formed by one content morpheme only and cannot be analysed into parts are called opaque words, such as axe, glove. 13. Transparent Words--Words that consist of more than one morphemes and can be segmented into parts are called transparent words: workable(work+able), door-man(door+man).

完全版英语词汇学名词解释

第一章 word 令狐采学 1.Word A word is a minimal free form of a language that has a given sound and meaning and syntactic funtion. 第三章 formation 1 1. Morpheme A morpheme is the smallest functioning unit in the composition of words. 2. Allomorph Some morphemes are realized by more than one morph according to their position in a word. Such alternative morphs are know as allomorphs. 3. Free morphemes (Free root) They are morphemes which are independent of other morphemes. 4. Bound Morphemes They are morphemes which cannot occur as separate words.

5. Bound root A bound root is that part of the word that carries the fundamental meaning just like a free root. Unlike a free root, it is a bound form and has to combine with other morphemes to make words. 6. Affixes Affixes are forms that are attached to words or word elements to modify meaning or function. 7. Inflectional affixes Affixes attaches to the end of words to indicate grammatical relationships are known as inflectional morphemes. 8. Derivational affixes Derivational affixes are affixes added to other morphemes to create new words. 9. Prefixes Prefixes are affixes that come before the word. 10. Suffixes suffixes are affixes that come after the word. 11. Root A root is the basic form of a word which cannot be further analysed without total loss of identity. 12. Stem a stem can be defined as a form to which affixes of any kind can be added.

MSDS-Pattex transparent-C__ (2008-01-01) version 2

汉高粘合剂 化学品安全数据表(根据91/155/EEC - ISO 11014-1) 第 1 页共 4 页 安全数据表编号:FP0003百得透明万能胶 版本: 2 生效日期:2008-01-01 1. 产品及企业标识 产品中文名称:百得透明万能胶 产品俗名或商品名:万能胶 产品英文名称:Pattex Transparent Contact Adhesive 企业中文名称:汉高粘合剂有限公司 企业英文名称:Henkel Adhesives Company Limited 地址:中国广东省汕头市东厦北路下蓬工业区 邮编:515065 传真号码:(86)754-8347511 应急电话:(86)532-83889090 技术说明书编码:FP0003 生效日期:2008年1月1日 2. 成份/组成信息 主要成分:聚氨酯和混合有机溶剂(丙酮和乙酸乙酯)的混合溶液。 有害成分浓度范围 CAS No. 乙酸乙酯 40 ~ 60% 141-78-6 丙酮 20 ~ 30% 67-64-1 3.危险性概述 危险性类别:第3.2 类中闪点易燃液体 侵入途径:吸入食入皮肤接触 健康危害:持续吸入本产品的蒸汽可引起头晕、倦睡和其他一些麻醉症状。怀孕妇女应该避免皮肤接触和吸入其蒸汽。 环境危害:本产品对环境有危害,应特别注意对水体的污染。 燃爆危险:易燃,产品蒸汽与空气可形成爆炸性混合物,遇明火、高热有燃烧爆炸危险。 4. 急救措施 皮肤接触:脱去污染的衣服,先用沾湿汽油的棉花仔细小心清洗沾到胶的皮肤,再用肥皂和水洗净。 眼睛接触:立即翻开上下眼睑,马上用大量的水冲洗眼睛大约10分钟,用无菌纱布包扎,尽快就诊。 吸入:迅速脱离现场至空气新鲜处。保持呼吸道通畅。呼吸困难时给输氧。如呼吸及心跳停止,立即进行人工呼吸和心脏按摩术。就医。

幕墙术语(中英)

幕墙术语(中英) 一、基本术语 建筑幕墙curtain wall 幕墙 由面板与支承结构体系组成,具有规定的承载能力、变形能力和适应主体结构位移能力,不分担主体结构所受作用的建筑外围护墙体结构或装饰性结构。 层间幕墙inter-floor curtain wall 安装在楼板之间或楼板和屋顶之间分层锚固支承的建筑幕墙。 窗式幕墙window type glass curtain wall 窗墙window wall 安装在楼板之间或楼板和屋顶之间的金属框架支承玻璃幕墙');callServer('玻璃幕墙')"玻璃幕墙,是层间玻璃幕墙的常用形式。 注:窗式幕墙与带形窗的区别在于:窗式幕墙是自身构造具有横向连续性的框支承玻璃幕墙;带形窗是自身构造不具有横向连绩性的单体窗,通过拼樘构件连接而成的横向组合窗。 斜幕墙inclined curtain wall 与水平方向夹角大于等于75°且小于90°的幕墙。 围护型幕墙enclosing curtain wall;warm curtain wall 全功能幕墙

分隔室内、外空间,具有外围护墙体结构完整功能的幕墙。 装饰型幕墙curtain wall cladding;cold curtain wall 安装于其他墙体或结构上,按幕墙形式建造的装饰性结构。 透光幕墙daylighting curtain wall 可见光能直接透射入室内的建筑幕墙。 透明幕墙transparent curtain wall 可透视幕墙 人眼可直接透视的透光幕墙。 非透明幕墙non-transparent curtain wall;translucent curtain wall 不可透视幕墙 人眼不可直接透视的透光幕墙。 注:人眼不可直接透视,即人眼不能直接看清楚幕墙另一面后的物体。 非透光幕墙opaque curtain wall 可见光不能直接透射入室内的幕墙。 光伏幕墙photovoltaic curtain wall 含有光伏构件并具有太阳能光电转换功能的幕墙。 光热幕墙solarthermal curtain wall 含有光热构件并具有太阳能光热转换功能的幕墙。 光伏光热一体化幕墙hybrid photovoltaic/solarthermal curtain wall

相关文档
相关文档 最新文档