Using WS-BPEL to Implement Software Fault Tolerance for Web Services
Glen Dobson
Computing Department, Lancaster University
g.dobson@https://www.doczj.com/doc/a215636932.html,
Abstract
One area of the web services architecture yet to be standardised is that of fault tolerance for services. At the same time, WS-BPEL is moving from a de facto standard to an OASIS ratified standard for combining services into processes. This paper investigates the feasibility of using WS-BPEL as an implementation technique for fault tolerant web services. The mapping of various fault tolerance patterns to WS-BPEL is presented. A prototype tool for combining service interfaces into a single fa?ade and configuring fault tolerant mechanisms on a per-operation basis is also discussed. It is found that most fault tolerance patterns readily map onto WS-BPEL concepts, particularly when using the upcoming 2.0 version of the language. Evaluating and minimising the performance overheads involved in process execution is identified as a key future direction, as is working on the functionality and usability of the configuration tool.
1. Introduction
The dependability of web services is key to their widespread uptake in mission-critical applications. Numerous standards relating to dependability of web services exist in the area of reliable messaging and security. Various proprietary clustering mechanisms also exist for implementing fault tolerance at the application server level. However, little emphasis has been placed upon fault tolerance of the service implementation itself. This paper presents a generic mechanism for combining web services with the aim of achieving software fault tolerance.
Software fault tolerance involves utilising redundancy of software components. The general notion is that if one component fails then other components are available to guarantee continuous execution. This may involve parallel execution of the components (typified by the N-version programming approach [1]), or sequential execution (typified by the recovery block approach [2]).
A system of redundant components can obviously be viewed as a composition. If we view web Services as software components then the core standards of the Web Services Architecture [3] go some way to forming a component model. The Web Service Definition Language (WSDL) [4] is the interface definition language; the eXtensible Markup Language (XML) [5], XML schema [6] and Hypertext Transfer Protocol (HTTP) [7], with the option of SOAP [8], together form an interaction standard. No widely accepted standard providing a composition model fro web services has emerged however. The Business Process Execution Language for Web Services (BPEL4WS) 1.1 [9] has emerged as a de facto standard for workflow definition, and may at the same time fill the role of a composition model. BPEL4WS forms the basis of the forthcoming WS-BPEL 2.0 OASIS standard [10]. Here, we will use the name WS-BPEL, although the implementation of the prototype tool described in Section 4 is based upon the 1.1 version of the language as the 2.0 version is still in draft status.
If one is taking WS-BPEL as a composition standard, it is natural to consider using executable WS-BPEL in order to implement software fault tolerance for web services. This technique is particularly useful for combining externally provided services, over which one has no control, into fault tolerant compositions. In other words, if there are a number of variants of a common (perhaps industry defined) service interface then the service integrator can make use of these instead of developing their own variants. Where a genuine service marketplace exists, with competing providers, this is a potentially highly advantageous technique as the process of developing one’s own service variants is expensive.
Where one has control over service implementation and provision other techniques including server clustering solutions are generally preferable. However, even in this situation, one may find that a cheap solution with the benefit of greater diversity (i.e. using
variants rather than true replicas) is to use WS-BPEL to combine one’s own services with externally provided services (e.g. in the simplest case using a third party service as a primary backup). Finally, if one is providing a service developed elsewhere – but cannot find a reliable implementation then using WS-BPEL to create a more reliable composition using multiple service implementations may be a good solution.
The objectives of the work discussed here are as follows:
1.Primarily – to demonstrate the feasibility of
WS-BPEL as an implementation technique
for service fault tolerance.
2.To develop a prototype tool enabling a non-
expert user to transform an existing service
into a more dependable composition.
3.To demonstrate that the cost in terms of
service performance is not prohibitive to
using this technique.
4.To improve upon our previous fault tolerant
containers work [11] by standards alignment,
increased flexibility, and improved handling
of stateful services.
The remainder of this paper is structured as follows: In the following section the state-of-the-art in web service dependability is discussed; this is followed in section 3 by a discussion of WS-BPEL; section 4 presents the details of our fault tolerance technique and configuration tool; the work is evaluated and concluded upon in section 5.
2. State of the Art in Web Service Dependability
A number of WS- standards relating to dependability currently exist. These apply where SOAP is employed as an XML messaging protocol (remembering that the use of SOAP is not compulsory in the Web Services Architecture).
For instance, WS-Reliability [12] is an OASIS standard dealing with dependability at the message-passing level. This standard adds dependability to the unreliable Internet channel of communication, allowing guaranteed message delivery and the elimination of duplicate messages. WS-Security [13], also an OASIS standard, specifies mechanisms to provide integrity and confidentiality of SOAP messages. These mechanisms can make use of a range of existing security models and encryption technologies.
None of the WS- standards, including the two mentioned above, occupy the same problem space as the work presented here. These, as well as vendor-specific clustering mechanisms, should be considered as orthogonal, but important aspects to ensuring web service dependability. However, a number of research efforts have approached the same problem space – namely software fault tolerance of web services.
In the Fault Tolerant Container approach [11], externally provided services are 'contained' and therefore gain added fault tolerance. This is achieved by allowing the container to be configured with a policy which specifies what kind of fault tolerance mechanisms may be applied to the services it contains. The container is essentially an active SOAP proxy. It proxies calls to the services it contains, passing them on to variants in a pattern determined by the specified policy. Weaknesses of this approach include that in its current form it does not support stateful services in any way. The work presented here aims to improve upon this technique by replacing the policy language with WS-BPEL (the container is therefore replaced by a WS-BPEL engine).
[14] correctly notes that backward error recovery techniques (including transactions) are often inappropriate for application to public web services due to the autonomy of the services involved. At the same time it points out that forward error recovery techniques such as the fault handlers in WS-BPEL are flawed. During parallel execution, in the event of a fault being signalled only one handler is called, when in fact a handler for each parallel activity should be called. The solution proposed is a forward error recovery mechanism for web services based upon the concept of Coordinated Atomic Actions. Since we are attempting standards alignment in this work we cannot make use of this research – but hope that the WS-BPEL standard evolves to take account of these shortcomings.
Other fault tolerance related work has tended to offer a single fault tolerance pattern (e.g. primary backup in [15] or N-version programming in [16]). In contrast we aim to provide a mapping for various fault tolerance patterns to WS-BPEL as well as an extensible mechanism to plug one’s own patterns into the tool allowing them to be quickly configured by non-expert users. A further advantage of using WS-BPEL is that unlike mechanisms such as [15] and [16] there are no application-server specific elements either conceptually or in the prototype implementation.
3. WS-BPEL
BPEL4WS 1.1 [9] originated as a language from IBM for the specification of business processes. It has since undergone a name change to WS-BPEL and is now under the control of the Organization for the Advancement of Structured Information Standards (OASIS). This section is intended only as an overview of what WS-BPEL is. The interested reader can refer to [9] for a detailed language description.
WS-BPEL can be used both to abstractly model a process, and to create an executable business process. In the former case, the service paradigm may be merely used as a convenience. In the latter then anything modelled as a service must be an actual web service. It is the latter usage situation which is of relevance here. In particular, the fault tolerance technique presented here is mainly applicable where third-party, publicly available, black box services are being composed together to form a more dependable whole. This is not to say that it cannot be used as a means of providing intra-organisational fault tolerant services, although more alternatives are available in this case.
Executable WS-BPEL is essentially an XML programming language. A “program” in WS-BPEL is called a process. A process consists of a set of nested activities. These fall into two main types. The first of these types is a structured activity, which basically controls the execution of other activities nested inside itself. Structured activities exist to allow sequential, parallel, conditional and looping execution (the sequence, flow, switch, pick and while activities).
The second type of activity is a basic activity. Basic activities exist to allow the invocation of an external service and to expose an interface to the process itself (to receive messages and send messages in reply), to assign values to variables, and to signal faults.
WS-BPEL has close relationships with WSDL. Interactions with services are modelled as PartnerLinks. A PartnerLink has a PartnerLinkType, which defines which WSDL PortType is used in a relationship with some partner and which PortType is used when a partner interacts with the process itself (remembering that the process is exposed as a service and therefore has its own WSDL interface). These two relationships are defined in the partnerRole and myRole attributes of the PartnerLinkType. For two way relationships both roles are specified. An important aspect of this is that the use of PortTypes means that WS-BPEL only refers to services in an abstract way and it is up to an execution engine to determine what port (and therefore binding) should be used for each PortType. Generally the bindings can be specified statically at deployment time or dynamically – either from within the process or using some engine-specific mechanism.
4. WS-BPEL for Software Fault Tolerance
Before going into the details of our own work it is worth explaining the constructs available to provide fault tolerance which already exist in WS-BPEL. The first of these are compensationHandlers, which provide backwards error recovery for some specified scope. In other words, these provide the ability to attempt some application-specific rollback or cleanup with the aim of re-attaining a state where execution can continue. A compensationHandler consists of nothing more than a nested WS-BPEL activity as described in Section 3. The second type of construct – faultHandlers - provide forwards error recovery. These consist of catch blocks for explicitly thrown faults (generally those returned by an invoke activity, but possibly thrown from inside the process itself). FaultHandlers are also attached to a scope (a group of activities). However, a scope is deemed to have terminated abnormally if a faultHandler is invoked, unlike a compensationHandler. All activities in the scope are therefore terminated.
The aim of this work is not to replace these mechanisms. In fact we aim to utilise these as appropriate in order to implement various well known fault tolerance patterns.
4.1. Mapping Fault Tolerance Patterns to WS-BPEL Processes
We use the term fault tolerance pattern for a generic fault tolerance mechanism. The patterns we consider here are the following:
?Retry
o The same invocation
o The same invocation on a different
implementation (i.e. a form of
primary backup)
?Parallel Execution
o Taking the first response.
o Voting on all responses.
Fault tolerance patterns are applied on a per-operation basis. This has the advantage that particularly unreliable or critical operations can be picked out for improvement; as well as the fact that different fault tolerance patterns can be applied to different operations as appropriate.
The outline of a WS-BPEL process for fault tolerance is essentially a
Figure 1. Control Flow in a Fault Tolerant WS-BPEL Process
4.1.1 Retry and Primary Backup Patterns
The simplest fault tolerance pattern is perhaps retry . In other words when a fault occurs just perform the same invocation again hoping that the fault was transient. Such a mechanism is arguably inapplicable in the presence of WS-Reliability which can achieve the same aim at the messaging level. In the absence of WS-Reliability however, some WS-BPEL engines have proprietary ways of enabling retry – but it is not directly supported in the WS-BPEL specification. One interesting standards-based solution is that of the Active BPEL engine [17], which uses WS-Policy Assertions [18] to enable retry for specified endpoints.
For our solution in pure WS-BPEL we make use of the WS-BPEL faultHandler , compensationHandler and scope constructs. The initial invoke constitutes an implicit scope of its own. A faultHandler (i.e. a catch or catchAll block), if triggered, invokes the compensationHandler for an enclosing (explicitly defined) scope. To achieve retrying of the call, the compensation activity is simply a copy of the same invoke activity (when WS-BPEL 2.0 becomes a standard this could be implemented as an inline sub-process [19]). Optionally, a wait activity can be included in the compensation activity to wait a set period before retrying. For retrying n times, ideally a while activity would be used to repeat the scope containing both the invoke and the compensationHandler . However in the existing 1.1 version of WS-BPEL the specification states that the compensationHandler cannot make changes to the process state, and thus a count of the number of invocations cannot be easily kept. Again, this is something which is rectified in the upcoming 2.0 version. As it stands we suggest that the best way to avoid problems with interoperability is simply to nest n explicitly defined scopes inside compensation handlers. Figure 2 depicts this. In the figure a third nested scope for retry 2 can be imagined coming off to the right, and the chain will continue up until n retries. The final faultHandler in the chain will simply rethrow any fault indicating that the retry strategy has failed). Figure 2. Retry Using Nested Scopes
The primary backup pattern can be achieved in much the same way. CompensationHandlers are nested which consist of invoking backup services rather than the same service. Where the backup services implement the same abstract WSDL (i.e. use precisely the same PortType) then some work needs to be done to ensure that the backup is called and not just the same service again. Remembering that a PartnerLink refers only to the abstract PortType, it is necessary,
within the compensation handler to update the endpoint reference of the partner link. Again, due to the limitations on altering process state within a compensation handler in the 1.1 version, this is only possible using WS-BPEL 2.0.
Where the PortTypes are not precisely the same then often some mapping between message formats needs to be done. This is a simple matter of using the assign activity on variables defined with a messageType (which refers to a WSDL message definition). All input messages received need to be transformed to a format useful to each PortType used by a backup service, and all replies received from backups need to be translated into the format used by the process’ WSDL.
4.1.2. Parallel Execution and Voting Patterns
Parallel Execution is often termed active replication when used in fault tolerance. This is because, in general, a great deal of effort needs to be directed towards maintaining state consistency across replicas. Web services are, by design, stateless. That is, clients do not have their own instance of a service, but rather all operate on the same service at the same time. To work around this, and allow for some sense of an ongoing session, a token of some sort (e.g. a session ID/customer ID) is often passed to the service with every call. Identifying these tokens and mapping calls to appropriate instances is termed message correlation in WS-BPEL. This is the only kind of statefulness supported by the fault tolerance mechanisms presented in this paper. Other forms of stateful service (e.g. as in the Web Services Resource Framework [20] are not supported).
The simplest parallel execution pattern invokes each replica service in parallel and returns the first response received. This can be achieved by using the pick activity in WS-BPEL. This awaits the occurrence of one of a set of events and then performs the activity associated with the event that occurred. This applies when awaiting the response to an asynchronous call. The trigger event will be the invocation of an operation on a call-back interface. All other call-backs will simply be ignored.
The situation is more difficult when attempting to take the first result of a set of concurrent synchronous calls. It appears that pick cannot be applied in this case. The difficulty is that, if, e.g. a flow activity is used to concurrently invoke a set of services then all slower invocations continue to block despite the fact that one has completed. We have no elegant solution to this. Instead we suggest that the flow is wrapped in a scope and that after invoking and copying the response, a fault is thrown, which will force the termination of everything within the scope. An empty faultHandler can be defined for the scope as we now know that one of the invocations has returned. The reply can therefore be sent to the caller.
In the voting pattern all invocations are expected to complete and therefore a flow activity can be used. A vote then takes place on the whole (or part) of the messages returned. In practice this proved rather cumbersome to implement – involving either a complex nest of switch activities, or preferably the definition of an XML ComplexType to hold the number of votes for each different result returned. The combination of the assign activity with XPath 1.0 [21] proves powerful enough to perform the required arithmetic and comparison however.
4.1.3. Fault Detection
The issue of fault detection is key to the effectiveness of a fault tolerance mechanism. The patterns talked about above rely upon signalled faults (i.e. SOAP faults) and will also deal with network outages or other forms of service unavailability. Where a service is found not to explicitly signal everything one wishes to regard as a fault then WS-BPEL can form a protective wrapper, throwing faults internally based upon the results from one or more invocations. Indeed, the voting pattern does just this, throwing a NoConsensus fault if services fail to agree on a certain result.
In some cases it may also be useful to have external fault detectors or monitors. We propose that these be implemented as asynchronous services and that they signal faults via a call back interface that the process exposes (separate to the interface provided to the service user).
4.2. Stock Quote Scenario
Here we present a simple usage scenario to give a more concrete explanation of some of the concepts involved. We use the example of a stock quote service – that is a service which gives live prices from the stock market for a given company code. One could imagine that the use of such a service could from a mission critical part of many financial systems. It can also easily be seen how the scenario generalises to any buying/selling situation where prices are subject to change.
It is important that, if big-money decisions are being made based upon the result of this service invocation, that the result is correct. We therefore demonstrate how to combine three services using a
voting pattern so that in the event of a single service producing incorrect results the overall system will still provide the correct result.
Each service used in the scenario provided a similar interface – but did not actually import the same PortType from an abstract WSDL description. This meant that there was no need to dynamically change the endpoint references for each PartnerLink involved.
Unfortunately, for the sake of brevity, we are unable to include the full WS-BPEL file. The following is a shorter pseudo-BPEL listing. The definition of partnerLinks and variables are not shown:
?Process
o Sequence
Receive
(translate inputs) – a series of
assigns using XPath 1.0
expressions
Flow
?Invoke all 3 Services
(translate outputs)
(count votes)
Reply
In practice we have tried this out with externally provided public services. These do not in fact give live quotes – but generally involve a twenty minute delay. However, commercial services are available that give live prices. For the purposes of demonstrating the concept this distinction is not important. We also noted that many of these services are actually reliant on a common backend (e.g. many rely on the “Get Quotes” functionality of Yahoo! Finance). In a real usage situation this would pose a serious problem as there is no true redundancy in the system. A single point of failure – the common backend – still exists. This shows another difficulty in achieving dependability when utilising black-box services. In practice the only solution is to manually verify the diversity of the services employed. Even if metadata or ontology based solutions can make these backend dependencies more explicit, there are always going to be many cases where the relevant metadata is not provided.
4.3. A Prototype Tool for Configuring Fault Tolerant WS-BPEL Processes
The configuration tool is an important part of this work, as it will present a very simple interface for service composition and the application of fault tolerance patterns. However it is a work in progress and therefore we will not say too much about it here. The screenshot in Figure 3 should give some indication of what the tool provides. At the top the user can specify a pool of service WSDL definitions. Generally one (or more) of these will contain the PortType/s that the fault tolerant WS-BPEL process should expose. The PortTypes for any service from the pool can be viewed in the panel labelled “PortTypes from existing WSDL” these can then be selected for inclusion in the WSDL for the fault tolerant process. PortTypes from different services may be used. Operations may then be hidden or renamed in the PortType. The PortType may also be renamed and PortTypes can be merged (or operations moved between them).
The right hand panel allows the application of fault tolerance patterns to particular operations (selected in the WSDL tree). A dialog will popup allowing the pattern-specific configuration to be made by the user. For instance, retry will simply allow the user to specify a wait period and the number of times to retry. A vote dialog will allow replica services to be identified providing the same operation (the service pool from the main screen will be automatically available – but the user may want to specify other services). It will also allow the XPath for the value to be voted on to be specified (on a per-service basis if each uses a different PortType) as well as any acceptable error margin.
At the bottom of the main screen the user can choose to save the WSDL and WS-BPEL to files or deploy to a specific WS-BPEL engine. These “Deployers” are plugins loaded at runtime. A “deployer” extends the abstract Deployer class from the Java API. This basically defines one abstract operation – deploy – which takes the list of WSDL files used and the BPEL file, as well as the list of replica services that can be used for each operation.
These inputs should be sufficient to deploy to most/all BPEL engines.
Pattern implementations in the tool are also pluggable elements. A Pattern extends the abstract class Pattern which defines one abstract method – applyPattern – which takes the invoke statement from BPEL to make fault tolerant as an input as well as a reference to the complete BPEL document and the WSDL that the process exposes.
5. Conclusion
This paper presented the mapping of various fault tolerance patterns to WS-BPEL and a prototype tool to configure fault tolerant services using these patterns. The main aim was to allow the integration of competing service variants from the marketplace into a
more dependable whole. With regards to assessing the dependability gain achieved using the patterns, we feel such an assessment is somewhat unnecessary since these are well known, well-used patterns. The theoretical gain in dependability is therefore well understood. Demonstrating the concept in a more realistic setting is a different issue, which might highlight emergent dependability issues.
A potential weakness which may be pointed out is that a single WS-BPEL engine acts as a single point of failure, and therefore that a fault tolerance mechanism at this level is also required. This can generally be achieved using the clustering mechanism provided by the application server on which the engine runs.
Returning to the objectives set out in the introduction, we have made some progress toward them all, except for evaluating the performance tradeoffs involved in the use of WS-BPEL. This work is however, at an early stage and there is much work to be completed towards these objectives: 1.We have demonstrated the feasibility of WS-
BPEL as an implementation technique for
service fault tolerance, however work still
needs to be done on fine-tuning certain
patterns, clearly documenting the WS-BPEL
and experimental verification. More detailed
investigation of how each pattern applies to
synchronous versus asynchronous calls is also
reuired.
2.We have started the development of a
prototype tool enabling a non-expert user to
transform an existing service into a more
dependable composition. However, it is
perhaps at too early a stage for meaningful
evaluation. The development of the configuration tool is a vitally important future
direction as it provides a simple interface for
configuration of patterns involving just a few
variables. In particular an intuitive interface
for achieving message “translation” where
PortTypes are not identical still needs to be Figure 3. Screenshot of Configuration Tool
implemented. The tool also needs to move to the use of WS-BPEL 2.0 as a number of advantages were identified to this in section 4. 3. We have not yet measured the cost in terms of
service performance of using this technique. This is therefore an important future direction. 4. The use of WS-BPEL, is, we believe an
improvement upon our previous fault tolerant containers work. We now have standards alignment, increased flexibility in combining services (i.e. they may, in theory be of different PortTypes which is not possible where SOAP messages are simply being proxied), better handling for stateful services (through the use of correlation) and the potential of transforming whole processes rather than just single services into fault tolerant versions.
6. References
[1] A. Avizienis, "The methodology of N-version
Programming," Chapter 2 of Software Fault Tolerance , M.
R. Lyu (Ed.), Wiley, pp. 23-46, 1995.
[2] B. Randell and J. Xu, “The evolution of the recovery
block concept,” in Software Fault Tolerance (ed. M. Lyu),
the Trends in Software series, John Wiley & Sons Ltd, pp.1-22, 1995.
[3] David Booth et al, “Web Services Architecture”, W3C
Working Group Note, https://www.doczj.com/doc/a215636932.html,/TR/ws-arch/, 2004
[4] Erik Christiensen et al, “Web Services Description
Language (WSDL) 1.1”, W3C Note,
https://www.doczj.com/doc/a215636932.html,/TR/wsdl, 2001
[5] Tim Bray et al, “Extensible Markup Language (XML)
1.1”, W3C Recommendation, https://www.doczj.com/doc/a215636932.html,/TR/xml11/,
2004
[6] David Peterson et al, “XML Schema”, W3C Working
Draft, https://www.doczj.com/doc/a215636932.html,/XML/Schema, 2006
[7] R. Fielding et al, “Hypertext Transfer Protocol -
HTTP/1.1”, IETF RFC 2616,
https://www.doczj.com/doc/a215636932.html,/rfc/rfc2616.txt, 1999
[8] Nilo Mitra (editor), “SOAP Version 1.2”, W3C
Recommendation, https://www.doczj.com/doc/a215636932.html,/TR/soap/, 2003
[9] TonyAndrews et al, “Business Process Execution
Language for Web Services Version 1.1”, ftp://https://www.doczj.com/doc/a215636932.html,/software/developer/library/ws-bpel.pdf, 2003
[10] Alexandre Alves et al, “Web Services Business Process Execution Language Version 2.0”, https://www.doczj.com/doc/a215636932.html,/committees/workgroup.php?wg_abbrev=wsbpel, 2006
[11] Glen Dobson, Stephen Hall, Ian Sommerville, “Dependable Service Engineering: A Fault-tolerance based Approach”, Submitted to ACM Transactions on Software
Engineering and Methodology, https://www.doczj.com/doc/a215636932.html,/papers/2005_tosem_ftc.pdf, 2005
[12] Kazunori Iwasa, “Web Services Reliable Messaging TC WS-Reliability 1.1”, OASIS Standard, https://www.doczj.com/doc/a215636932.html,/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf, 2004
[13] Anthony Nadalin et al, “Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)”, https://www.doczj.com/doc/a215636932.html,/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf, 2006 [14] F. Tartanoglu, V. Issarny, A. Romanovsky, N. Levy,
"Coordinated Forward Error Recovery for CompositeWeb
Services," srds , p. 167, 22nd International Symposium on
Reliable Distributed Systems (SRDS'03), 2003
[15] X. Zhang, D. Zagorodnov, M. Hiltunen, K. Marzullo,
and R. D. Schlichting, "Fault-tolerant Grid
Services using Primary Backup: Feasibility and
Performance," presented at Proc. Cluster 2004
[16] N. Looker and M. Munro, "WS-FTM: A Fault
Tolerance Mechanism for Web Services,"
University of Durham, Technical Report 02/05. 2005.
[17] “ActiveBPEL – The Open Source BPEL Engine”,
https://www.doczj.com/doc/a215636932.html,/
[18] Don Box et al, “Web Services Policy Assertions
Language”, https://www.doczj.com/doc/a215636932.html,/developerworks/webservices/library/specificati
on/ws-polas/, 2002
[19] Matthias Kloppmann et al, “WS-BPEL 2.0 Extensions
for Sub-Processes”, IBM/SAP whitepaper, https://www.doczj.com/doc/a215636932.html,/developerworks/webservices/library/specificati
on/ws-bpelsubproc/, 2005
[20] “The WS-Resource Framework”,
https://www.doczj.com/doc/a215636932.html,/wsrf
[21] James Clark, Steve DeRose, “XML Path Language
(XPath) Version 1.0”, W3C Recommendation,
https://www.doczj.com/doc/a215636932.html,/TR/xpath, 1999
手机微信QQ聊天记录取证方法（非常详细实用） 如今，由于互联网为交易双方提供了跨越物理空间的沟通渠道，通过网络协商订立合同条款越来越成为追求交易便捷、降低成本的商事主体的选择。 在案件当中，通过微信、QQ、电子邮件协商确定双方权利义务的情况比比皆是，也成为认定案件关键事实的主要证据。目前互联网电子数据证据成为案件主要证据的比例逐步上升，甚至部分案件中此类证据，特别是微信证据成为当事人证明自己主张的唯一证据。 为了统一司法实践中互联网电子证据认定标准，南沙法院在全省率先出台《互联网电子数据证据举证、认证规程(试行)》(以下简称《规程》)。 《规程》对互联网电子数据证据的内涵予以了界定，依据及参考已经颁布施行的《电子签名法》以及尚在审议过程中的《电子商务法》，并结合法院审判实践中出现较多的证据类型，列举了短信、电子邮件、QQ、微信、支付宝或其他具备通讯、支付功能的互联网软件所产生的，能够有形地表现所载内容并可以随时调取查用的数据信息。 针对各种证据类型，《规程》对当事人向法院提供证据方面作出指引，包括固化证据的形式、使用的介质、展示证据的程序。同时法院也在立案窗口和
应诉送达时专门放置举证指引清单，对于提交此类证据的当事人及时进行指导，减少不规范的举证行为，提高审判效率。 《规程》还对法官采信电子证据的认证过程作出指引。对于通过公证、鉴证可以解决证据真实性认证问题的，引导当事人进行公证、鉴证，而对于没有进行公证、鉴证或者公证、鉴证内容尚不足以证实证据真实性的情况，主要通过电子数据证据中当事人的身份真实性、通讯内容的完整性来对证据进行认证。 ▌关于微信相关证据《规程》这样说 当事人提交微信相关证据需注意以下三方面： 1、使用终端设备登陆本方微信账户的过程演示。用于证明其持有微信聊天记录的合法性和本人身份的真实性。 2、聊天双方的个人信息界面。借助微信号不可更改的特点，并结合个人信息界面中显示的手机号码、头像等信息固定双方当事人的真实身份。 3、完整的聊天记录。根据微信聊天记录在使用终端中只能删除不能添加的特点，根据双方各自微信客户端完整聊天信息进行对比，以验证相关信息的完整性和真实性。 法官采信微信相关证据时如何做? 1、法官在采信微信相关证据时如何确定微信使用者身份? 微信并未强制实名认证，法官在采信微信相关证据时，根据当事人提供的对方微信号、绑定的手机号码以及聊天记录中透露的相关信息内容，法官可以