No abstract

No abstract

No abstract

No abstract

Abstract-An increasing number of popular SOAP web services exhibit a stateful behavior, where a successful interaction is determined as much by the correct format of messages as by the sequence in which they are exchanged with a client. The set of such constraints forms a "message contract" that needs to be enforced on both sides of the transaction; it often includes constraints referring to actual data elements inside messages. We present an algorithm for the runtime monitoring of such message contracts with data parameterization. Their properties are expressed in LTL-FO þ , an extension of Linear Temporal Logic that allows first-order quantification over the data inside a trace of XML messages. An implementation of this algorithm can transparently enforce an LTL-FO þ specification using a small and invisible Java applet. Violations of the specification are reported on-the-fly and prevent erroneous or out-of-sequence XML messages from being exchanged. Experiments on commercial web services from Amazon.com and Google indicate that LTL-FO þ is an appropriate language for expressing their message contracts, and that its processing overhead on sample traces is acceptable both for client-side and server-side enforcement architectures.

We present an algorithm for the runtime monitoring of business process properties with data parameterization. The properties are expressed in LTL-FO + , an extension to traditional Linear Temporal Logic that includes full firstorder quantification over the data inside a trace of XML messages. The algorithm works "on-the-fly": it keeps in memory only the states that are necessary at each step. Initial results indicate that LTL-FO + is an appropriate language for expressing data dependencies on message traces and that its processing overhead on sample traces is acceptable.

Introduction Hyperthermia during exercise induces central and peripheral fatigue and impairs physical performance. To facilitate heat loss and optimize performance, athletes can hasten body cooling prior (pre‐cooling) or during (per‐cooling) exercise. However, it is unclear whether per‐cooling effect is the same on ‘aerobic’ and ‘anaerobic’ types of exercise (duration <75 and >76 seconds, respectively, according to Gastin [Sports Med 2001;31:725‐741]) and whether the body area that is cooled makes a difference. Methods A literature search led to the identification of 1582 potential studies. Included studies had to include physical exercise with sufficient details on the type, duration, intensity, and provide valid performance measures and a cooling intervention administered during exercise with sufficient details on the type and site of application. Results Forty‐five studies were included. Per‐cooling provides a performance benefit during ‘aerobic’ (standardized mean difference (SMD) of 0.60, P < .001) and ‘anaerobic’ exercises (SMD = 0.27, P < .02). The effects were greater during aerobic compared to anaerobic exercises (P < .01). Internal cooling (cold fluid ingestion such as cold water and ice slurry/menthol beverage) and external cooling (face, neck, and torso) provide the greatest performance benefit for ‘aerobic’ performance with a moderate to large effect (0.46 < SMD < 1.24). For ‘anaerobic’ exercises, wearing a whole‐body cooling garment is the best way to enhance exercise performance (SMD = 0.39, P < .01). Conclusion Per‐cooling improves ‘aerobic’ and ‘anaerobic’ exercise performance with a greater benefit for ‘aerobic’ exercise. The magnitude of the effect depends on the type and site of the cooling application.

Web applications are required to follow an interface contract that specifies their expected behaviour when they communicate with a web service. Using the Amazon E-Commerce Service as an example, we show how we can automatically test an implementation for conformance as well as monitor at runtime that each partner fulfils its part of the contract. T He term Asynchronous JavaScript and XML (Ajax)refers to a collection of technologies used to develop rich and interactive web applications. A typical Ajax client runs locally in the user's web browser and refreshes its interface on-the-fly in response to user input. Popular Ajax applications, such as Google Maps and Facebook, communicate in the background with a server: entering information in the Facebook portal sends it to its remote database; dragging Google's map triggers the retrieval of new portions of the image from their server.In many cases, the server's functionality is made publicly available as an instance of a web service and can be freely accessed by any third-party Ajax application. However, this appealing modularity is also the source of one major issue: how can one ensure the interaction between each application and each service proceeds as was intended by their respective providers? Whether for specifying interoperability constraints, business policies or legal guidelines, a good web service has to have a well defined and enforceable interface contract [1].