You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ode.apache.org by va...@apache.org on 2012/12/28 14:13:33 UTC
svn commit: r1426497 [2/2] - in /ode/site/trunk: content/
content/extensions/ content/userguide/ templates/
Added: ode/site/trunk/content/extensions/xpath-extensions.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/extensions/xpath-extensions.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/extensions/xpath-extensions.mdtext (added)
+++ ode/site/trunk/content/extensions/xpath-extensions.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,336 @@
+Title: XPath Extensions
+Apache ODE extends the default XPath coverage provided by the [WS-BPEL](-ws-bpel-20.html) specification mostly by adding support for [XPath 2.0](http://www.w3.org/TR/xpath20/) and by offering a few utility extension functions to make some assignments easier.
+
+<a name="XPathExtensions-XPath2.0"></a>
+### XPath 2.0
+
+To use XPath 2.0 in your processes just use the following _queryLanguage_ and _expressionLanguage_ attributes:
+
+
+ queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"
+ expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"
+
+
+If you want support at the process just add these attributes to your root _process_ element. If you want to stick with XPath 1.0 but want XPath 2.0 support for a specific assignment you can also define these attributes on an _assign_ element.
+
+<a name="XPathExtensions-ExtensionFunctions"></a>
+### Extension Functions
+
+All extension functions are defined in the ODE extension namespace: http://www.apache.org/ode/type/extension. This namespace will be associated with the _ode_ prefix in the following examples.
+
+<a name="XPathExtensions-insert-before"></a>
+#### insert-before
+
+This is a function that allows you to insert one or more siblings (specified by the $siblings argument in the signature below) before the first node of children (specified by the $children argument), all of whose nodes must have the same parent (specified by the $context argument).
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Insert Before</B></DIV><DIV class="codeContent panelContent">
+ ode:insert-before($context as node(), $children as node()*, $siblings as node()*) as node()
+
+
+By design, this function is non-updating in that it preserves the identity and properties of its arguments (i.e., they don't try to change the XML in-place). Instead, a modified copy of the context node is created, essentially giving it a new identity. Further, it returns a single R-value item, as opposed to a sequence. The example below illustrates how it may be used in the context of an assign activity:
+
+
+ <assign>
+ <copy>
+ <from>ode:insert-before($parent, $parent/child::node[position()=last()], $siblings)</from>
+ <to variable="parent"/>
+ </copy>
+ </assign>
+
+
+For those familiar with the [XQuery Update Facility](http://www.w3.org/TR/2008/CR-xquery-update-10-20080801/), the above example is semantically equivalent to the expression shown below:
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>XQuery Equivalent</B></DIV><DIV class="codeContent panelContent">
+ insert nodes $siblings before $parent/child::node[position()=last()]
+
+
+<a name="XPathExtensions-insert-after"></a>
+#### insert-after
+
+This is a function that allows you to insert one or more siblings (specified by the $siblings argument in the signature below) after the last node of children (specified by the $children argument), all of whose nodes must have the same parent (specified by the $context argument).
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Insert After</B></DIV><DIV class="codeContent panelContent">
+ ode:insert-after($context as node(), $children as node()*, $siblings as node()*) as node()
+
+
+By design, this function is non-updating in that it preserves the identity and properties of its arguments (i.e., they don't try to change the XML in-place). Instead, a modified copy of the context node is created, essentially giving it a new identity. Further, it returns a single R-value item, as opposed to a sequence. The example below illustrates how it may be used in the context of an assign activity:
+
+
+ <assign>
+ <copy>
+ <from>ode:insert-after($parent, $parent/child::node(), $siblings)</from>
+ <to variable="parent"/>
+ </copy>
+ </assign>
+
+
+For those familiar with the [XQuery Update Facility](http://www.w3.org/TR/2008/CR-xquery-update-10-20080801/), the above example is semantically equivalent to the expression shown below:
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>XQuery Equivalent</B></DIV><DIV class="codeContent panelContent">
+ insert nodes $siblings after $parent/child::node()
+
+
+
+<a name="XPathExtensions-insert-as-first-into"></a>
+#### insert-as-first-into
+
+This is a function that allows you to insert the node(s) (specified by the $children argument in the signature below) as the first child(ren) of a given context node (specified by the $context argument).
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Insert As First Into</B></DIV><DIV class="codeContent panelContent">
+ ode:insert-as-first-into($context as node(), $children as node()*) as node()
+
+
+By design, this function is non-updating in that it preserves the identity and properties of its arguments (i.e., they don't try to change the XML in-place). Instead, a modified copy of the context node is created, essentially giving it a new identity. Further, it returns a single R-value item, as opposed to a sequence. The example below illustrates how it may be used in the context of an assign activity:
+
+
+ <assign>
+ <copy>
+ <from>ode:insert-as-first-into($parent, $children)</from>
+ <to variable="parent"/>
+ </copy>
+ </assign>
+
+
+For those familiar with the [XQuery Update Facility](http://www.w3.org/TR/2008/CR-xquery-update-10-20080801/), the above example is semantically equivalent to the expression shown below:
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>XQuery Equivalent</B></DIV><DIV class="codeContent panelContent">
+ insert nodes $children as first into $parent
+
+
+<a name="XPathExtensions-insert-as-last-into"></a>
+#### insert-as-last-into
+
+This is a function that allows you to insert the node(s) (specified by the $children argument in the signature below) as the last child(ren) of a given context node (specified by the $context argument).
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Insert As Last Into</B></DIV><DIV class="codeContent panelContent">
+ ode:insert-as-last-into($context as node(), $children as node()*) as node()
+
+
+By design, this function is non-updating in that it preserves the identity and properties of its arguments (i.e., they don't try to change the XML in-place). Instead, a modified copy of the context node is created, essentially giving it a new identity. Further, it returns a single R-value item, as opposed to a sequence. The example below illustrates how it may be used in the context of an assign activity:
+
+
+ <assign>
+ <copy>
+ <from>ode:insert-as-last-into($parent, $children)</from>
+ <to variable="parent"/>
+ </copy>
+ </assign>
+
+
+For those familiar with the [XQuery Update Facility](http://www.w3.org/TR/2008/CR-xquery-update-10-20080801/), the above example is semantically equivalent to the expression shown below:
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>XQuery Equivalent</B></DIV><DIV class="codeContent panelContent">
+ insert nodes $children as last into $parent
+
+
+
+<a name="XPathExtensions-delete"></a>
+#### delete
+
+This is a function that allows you to delete one or more node(s) (specified by the $children argument in the signature below) from its parent (specified by the $context argument).
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Delete</B></DIV><DIV class="codeContent panelContent">
+ ode:delete($context as node(), $children as node()*) as node()
+
+
+By design, this function is non-updating in that it preserves the identity and properties of its arguments (i.e., they don't try to change the XML in-place). Instead, a modified copy of the context node is created, essentially giving it a new identity. Further, it returns a single R-value item, as opposed to a sequence. The example below illustrates how it may be used in the context of an assign activity:
+
+
+ <assign>
+ <copy>
+ <from>ode:delete($parent, $children)</from>
+ <to variable="parent"/>
+ </copy>
+ </assign>
+
+
+For those familiar with the [XQuery Update Facility](http://www.w3.org/TR/2008/CR-xquery-update-10-20080801/), the above example is semantically equivalent to the expression shown below:
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>XQuery Equivalent</B></DIV><DIV class="codeContent panelContent">
+ delete nodes $children
+
+
+<a name="XPathExtensions-rename"></a>
+#### rename
+
+This is a function that allows you to rename the context node (specified by the $context argument in the signature below) as per the given name (specified by $item, which is either a QName, Element or String).
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Rename</B></DIV><DIV class="codeContent panelContent">
+ ode:rename($context as node(), $name as item()) as node()
+
+
+By design, this function is non-updating in that it preserves the identity and properties of its arguments (i.e., they don't try to change the XML in-place). Instead, a modified copy of the context node is created, essentially giving it a new identity. Further, it returns a single R-value item, as opposed to a sequence. The example below illustrates how it may be used in the context of an assign activity:
+
+
+ <assign>
+ <copy>
+ <from>ode:rename($person, fn:QName("http://www.example.com/example", "manager"))</from>
+ <to variable="person"/>
+ </copy>
+ </assign>
+
+
+For those familiar with the [XQuery Update Facility](http://www.w3.org/TR/2008/CR-xquery-update-10-20080801/), the above example is semantically equivalent to the expression shown below:
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>XQuery Equivalent</B></DIV><DIV class="codeContent panelContent">
+ rename $person as fn:QName("http://www.example.com/example", "manager")
+
+
+<div class="alert alert-warning"><h4 class="alert-heading">Assign Assumptions</h4>
+ The WS-BPEL requires that "for a copy operation to be valid, the data referred to by the from-spec and the to-spec MUST be of compatible types." Hence, make sure that when you rename an element, the new name refers to a type that is compatible with the target variable. In other words, it should be of a substitutable (essentially stronger) complex type.
+</div>
+
+<a name="XPathExtensions-split-to-elements"></a>
+#### split-to-elements
+
+It's impossible to split a given string into a sequence of elements using assignments. The only possible alternative is XSL which is a lot of complexity for a very simple usage pattern. The _ode:splitToElements_ function splits a given string (that can be a variable reference) into several elements by using a specific separators. Here is an example:
+
+
+ <assign>
+ <from>ode:split-to-elements($authorizeMessage.credential/userList, ',', 'user')</from>
+ <to>$authorizedUsers</to>
+ </assign>
+
+
+If the source element contains a list like "joe, paul, fred" the target variable will be assigned the sequence of elements:
+
+
+ <user>joe</user>
+ <user>paul</user>
+ <user>fred</user>
+
+
+Alternatively this function can take a fourth parameter that would be the namespace of the elements used to wrap the split strings:
+
+ ode:split-to-elements(stringToSplit, separator, targetElement, targetNamespace)
+
+
+<div class="alert alert-info"><h4 class="alert-heading">Deprecated Name</h4>
+ This function was formerly known as splitToElements, which may still be used, but is deprecated.
+</div>
+
+<a name="XPathExtensions-combine-url(base,relative)"></a>
+#### combine-url(base, relative)
+
+Takes the relative URL and combines it with the base URL to return a new absolute URL. If the relative parameter is an absolute URL, returns it instead.
+This function is similar to [func-resolve-uri](http://www.w3.org/TR/2004/WD-xpath-functions-20040723/#func-resolve-uri). However the latter is available in XPath 2.0 only.
+
+<a name="XPathExtensions-compose-url(template,\[name,value\](name,value\.html)*)"></a>
+#### compose-url(template, \[name, value\]*)
+<a name="XPathExtensions-compose-url(template,pairs)"></a>
+#### compose-url(template, pairs)
+
+Expands the template URL by substituting place holders in the template, for example, ('/order/\{id\}', 'id', 5) returns '/order/5'. Substitute values are either name/value pairs passed as separate parameters, or a node-set returning elements with name mapping to value. The functions applies proper encoding to the mapped values. Undefined variables are replaced with an empty string. This function returns an URL.
+See also the [URI Template spec](http://bitworking.org/projects/URI-Templates/spec/draft-gregorio-uritemplate-03.html).
+
+<a name="XPathExtensions-expand-template(template,\[name,value\](name,value\.html)*)"></a>
+#### expand-template(template, \[name, value\]*)
+<a name="XPathExtensions-expand-template(template,pairs)"></a>
+#### expand-template(template, pairs)
+
+Similar to `composeURL` but undefined variables are *_not_* replaced with an empty string. They are ignored. As a result with incomplete mapping may return a new URL template.
+
+<a name="XPathExtensions-dom-to-string"></a>
+#### dom-to-string
+
+This is a function that serializes a DOM node (specified by the $node argument in the signature below) into a string.
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Dom To String</B></DIV><DIV class="codeContent panelContent">
+ ode:dom-to-string($node as node()) as xs:string
+
+
+<a name="XPathExtensions-process-property"></a>
+#### process-property
+
+This is a function that allows you to retrieve the value of a property, defined in deploy.xml for the current process, with the given name (specified by the $name argument in the signature below, which is either a QName, String, Element or Single-Valued List).
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Process Property</B></DIV><DIV class="codeContent panelContent">
+ ode:process-property($name as item()) as node()
+
+
+Basically, this method gives you a way to reference properties, defined in deploy.xml for a given process, directly in the BPEL code for that process. The $name argument refers to any schema item that resolves to a QName. The return value is the child node of the property element with the given name.
+
+The example below illustrates how it may be used in the context of an assign activity:
+
+
+ <assign>
+ <copy>
+ <from>ode:process-property("auctionEpr")</from>
+ <to partnerLink="partnerLink"/>
+ </copy>
+ </assign>
+
+
+where, the property called "epr" is defined in the corresponding deploy.xml as follows:
+
+
+ <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
+ xmlns:tns="http://ode/bpel/process">
+ <process name="tns:negotiate">
+ <property name="auctionEpr">
+ <sref:service-ref
+ xmlns:sref=" http://docs.oasis-open.org/wsbpel/2.0/serviceref"
+ xmlns:addr="http://example.com/addressing"
+ xmlns:as="http://example.com/auction/wsdl/auctionService/">
+ <addr:EndpointReference>
+ <addr:Address>http://example.com/auction/RegistrationService</addr:Address>
+ <addr:ServiceName>as:RegistrationService</addr:ServiceName>
+ </addr:EndpointReference>
+ </sref:service-ref>
+ </property>...
+ </process>
+ </deploy>
+
+
+<div class="alert alert-info"><h4 class="alert-heading">Release Information</h4>
+ This function will be available in the 1.3 or higher version of ODE.
+</div>
+
+<a name="XPathExtensions-PredefinedProcessProperties"></a>
+#### Predefined Process Properties
+
+<a name="XPathExtensions-Localhostinfo(nameandIPaddress)"></a>
+##### Localhost info (name and IP address)
+
+
+ <bpws:assign>
+ <bpws:copy>
+ <bpws:from>ode:process-property('ode.localhost.name')</bpws:from>
+ <bpws:to>$output.payload</bpws:to>
+ </bpws:copy>
+ </bpws:assign>
+
+ <bpws:assign>
+ <bpws:copy>
+ <bpws:from>ode:process-property('ode.localhost.address')</bpws:from>
+ <bpws:to>$output.payload</bpws:to>
+ </bpws:copy>
+ </bpws:assign>
+
+
+<a name="XPathExtensions-ExtensionVariables"></a>
+### Extension Variables
+
+<a name="XPathExtensions-InstanceId"></a>
+#### Instance Id
+
+ $ode:pid
+
+
+<a name="XPathExtensions-ProcessQName"></a>
+#### Process QName
+
+ $ode:processQName
+
+
+<a name="XPathExtensions-CurrentEventDateTime"></a>
+#### CurrentEventDateTime
+This is equivalent to current-dateTime() XPath function, which works with instance replayer.
+
+ $ode:currentEventDateTime
+
+
+<div class="alert alert-info"><h4 class="alert-heading">Release Information</h4>
+ 1.3.4 or higher
+</div>
+
Added: ode/site/trunk/content/extensions/xquery-extensions.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/extensions/xquery-extensions.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/extensions/xquery-extensions.mdtext (added)
+++ ode/site/trunk/content/extensions/xquery-extensions.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,86 @@
+Title: XQuery Extensions
+<div class="alert alert-warning">
+ XQuery is available only in ODE 1.3 or later
+</div>
+
+Apache ODE goes above and beyond the [WS-BPEL](-ws-bpel-20.html) specification by allowing the use of [XQuery 1.0](http://www.w3.org/TR/xquery/) in queries and expressions.
+
+Unless specified otherwise, WS-BPEL considers XPath 1.0 to be the query/expression language, which is denoted by the default value of the "queryLanguage" and "expressionLanguage" attributes, viz. "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0". In addition, we have out-of-the-box support for XPath 2.0.
+
+<a name="XQueryExtensions-XQuery1.0"></a>
+### XQuery 1.0
+
+To use XQuery 1.0 in your processes just use the following _queryLanguage_ and _expressionLanguage_ attributes:
+
+ queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xquery1.0"
+ expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xquery1.0"
+
+If you want support at the process just add these attributes to your root _process_ element. If you want to stick with XPath 1.0 but want XQuery 1.0 support for a specific assignment you can also define these attributes on an _assign_ element.
+
+For your convenience, all of the functions and variables, standard or otherwise, that are available in XPath 2.0 have been exposed in XQuery 1.0 as well.
+
+<a name="XQueryExtensions-Examples"></a>
+#### Examples
+
+The following snippet illustrates how to use XQuery 1.0 in _assign_ activities. Needless to say, you may use XQuery 1.0 anywhere an expression is permitted, such as in a _while_, _if_, _repeatUntil_ or _forEach_ activity.
+
+
+ <process name="HelloXQueryWorld"
+ targetNamespace="http://ode/bpel/unit-test"
+ xmlns:bpws="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
+ xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
+ xmlns:tns="http://ode/bpel/unit-test"
+ xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+ xmlns:types="http://ode/bpel/types"
+ xmlns:test="http://ode/bpel/unit-test.wsdl"
+ xmlns:ode="http://www.apache.org/ode/type/extension"
+ queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xquery1.0"
+ expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xquery1.0">
+
+ ...
+ <assign name="assign1">
+ <copy>
+ <from variable="myVar" part="TestPart"/>
+ <to variable="otherVar"/>
+ </copy>
+ <copy>
+ <from><![CDATA[<test:content>Hello</test:content>]]></from>
+ <to variable="tempVar"/>
+ </copy>
+ <copy>
+ <from>
+ typeswitch ($myVar.TestPart)
+ case $a as xs:string return "test"
+ default return "default"
+ </from>
+ <to variable="otherVar"/>
+ </copy>
+ <copy>
+ <from><![CDATA[
+ typeswitch ($myVar.TestPart)
+ case $a as text() return <test:content/>
+ default return <test:content/>
+ ]]>
+ </from>
+ <to variable="otherVar"/>
+ </copy>
+ <copy>
+ <from>
+ for $loopOnce in (1)
+ return
+ concat(bpws:getVariableProperty("myVar", "test:content"), "XQuery World")
+ </from>
+ <to variable="myVar" part="TestPart"/>
+ </copy>
+ </assign>
+ ...
+ </sequence>
+ </process>
+
+
+<a name="XQueryExtensions-KnownLimitations"></a>
+#### Known Limitations
+
+Currently, we do not support:
+* The use of modules in XQuery.
+* The use of update expressions in XQuery.
Modified: ode/site/trunk/content/index.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/index.mdtext?rev=1426497&r1=1426496&r2=1426497&view=diff
==============================================================================
--- ode/site/trunk/content/index.mdtext (original)
+++ ode/site/trunk/content/index.mdtext Fri Dec 28 13:13:31 2012
@@ -28,8 +28,8 @@ WS-BPEL (Business Process Execution Lang
<div class="span6">
<h2>Features</h2>
<ul class="unstyled">
- <li><i class="icon-check"></i> Side-by-side support for both the <a href="ws-bpel-2.0.html">WS-BPEL 2.0</a> OASIS standard and the legacy BPEL4WS 1.1 vendor specification.</li>
- <li><i class="icon-check"></i> Supports 2 communication layers: one based on Axis2 (Web Services http transport) and another one based on the <a href="http://jcp.org/en/jsr/detail?id=208">JBI standard</a> (using <a href="servicemix.apache.org">ServiceMix</a>).</li>
+ <li><i class="icon-check"></i> Side-by-side support for both the <a href="ws-bpel-20.html">WS-BPEL 2.0</a> OASIS standard and the legacy BPEL4WS 1.1 vendor specification.</li>
+ <li><i class="icon-check"></i> Supports 2 communication layers: one based on Axis2 (Web Services http transport) and another one based on the <a href="http://jcp.org/en/jsr/detail?id=208">JBI standard</a> (using <a href="http://servicemix.apache.org">ServiceMix</a>).</li>
<li><i class="icon-check"></i> Support for the HTTP WSDL binding, allowing invocation of REST-style web services.</li>
<li><i class="icon-check"></i> Possibility to map process variables <a href="external-variables.html">externally</a> to a database table of your choice.</li>
<li><i class="icon-check"></i> High level API to the engine that allows you to integrate the core with virtually any communication layer.</li>
Added: ode/site/trunk/content/userguide/activity-failure-and-recovery.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/activity-failure-and-recovery.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/userguide/activity-failure-and-recovery.mdtext (added)
+++ ode/site/trunk/content/userguide/activity-failure-and-recovery.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,103 @@
+Title: Activity Failure and Recovery
+There are several types of error conditions. In this document we introduce a class of error condition called _failures_, distinct from _faults_, and describe how failures are caught and handled by the process engine.
+
+A service returns a fault in response to a request it cannot process. A process may also raise a fault internally when it encounters a terminal error condition, e.g. a faulty expression or false join condition. In addition, processes may raise faults in order to terminate normal processing.
+
+In contrast, failures are non-terminal error conditions that do not affect the normal flow of the process. We keep the process definition simple and straightforward by delegating failure handling to the process engine and administrator.
+
+For example, when the process is unable to perform DNS resolution to determine the service endpoint, it generates a failure. An administrator can fix the DNS server and tell the process engine to retry the activity. Had the DNS error been reported as a fault, the process would either terminate or require complex fault handling and recovery logic to proceed past this point of failure.
+
+In short, failures shields the process from common, non-terminal error conditions while retaining simple and straightforward process definitions that do not need to account for these error conditions.
+
+<a name="ActivityFailureandRecovery-FromFailuretoRecovery"></a>
+### From Failure to Recovery
+Currently, the _Invoke_ activity is the only activity that supports failure handling and recovery. The mechanism is identical for all other activities that may support failure handling and recovery in the future.
+
+In case of the _Invoke_ activity, a failure condition is triggered by the integration layer, in lieu of a response or fault message. The _Invoke_ activity consults its failure handling policy (specified here) and decides how to respond.
+
+Set _faultOnFailure_ to _yes_, if you want the activity to throw a fault on failure. All other failure handling settings are ignored. The activity will throw the _activityFailure_ fault.
+
+The _activityFailure_ fault is a standard fault, so you can use the _exitOnStandardFault_ attribute to control whether the process exits immediately, or throws a fault in the enclosing scope.
+
+Set _retryFor_ to a positive integer if you want the activity to attempt self-recovery and retry up to that number of times. Set _retryDelay_ to a reasonable time delay (specified in seconds) between retries. For example, if you set _retryFor=2, retryDelay=30_, the activity will retry after 30 and 60 seconds, for a total of three attempts, before entering activity recovery mode.
+
+If the activity retries and succeeds, it will complete successfully as if no failure occurred. Of course, the activity may retry and fault, e.g. if the invoked service returns a fault. If the activity has exhausted all retry attempts, it enters activity recovery mode. By default _retryFor_ is zero, and the activity enters recovery mode after the first failure.
+
+When in recovery mode, you can recover the activity in one of three ways:
+* *Retry* \-\- Retry the activity manually. You can repeat this any number of times until the activity completes or faults.
+* *Fault* \-\- Causes the activity to throw the _activityFailure_ fault.
+* *Cancel* \-\- Cancels the activity. The activity completes unsuccessfully: without changing the state of variables, by setting the status of all its source links to false, and without installing a compensation handler.
+Activity recovery is performed individually for each activity instance, and does not affect other activities executing in the same process. While the activity is in the _FAILURE_ state, the process instance remains in the _ACTIVE_ state and may execute other activities from parallel flows and event handlers.
+
+<a name="ActivityFailureandRecovery-SpecifyingFailureBehavior"></a>
+### Specifying Failure Behavior
+Use the _failureHandling_ extensibility element defined in the namespace `http://ode.apache.org/activityRecovery`. The structure of the _failureHandling_ element is:
+
+
+ <ext:failureHandling xmlns:ext="http://ode.apache.org/activityRecovery">
+ <ext:faultOnFailure> _boolean_ </ext:faultOnFailure>
+ <ext:retryFor> _integer_ </ext:retryFor>
+ <ext:retryDelay> _integer_ </ext:retryDelay>
+ </ext:failureHandling>
+
+
+The _faultOnFailure_, _retryFor_ and _retryDelay_ elements are optional. The default values are false for _faultOnFailure_, and zero for _retryFor_ and _retryDelay_.
+
+An activity that does not specify failure handling using this extensibility element, inherits the failure handling policy of its parent activity, recursively up to the top-level activity of the process. You can useinheritence to specify the failure handling policy of a set of activities, or all activities in the process, using a single _failureHandling_ extensibility element.
+
+Note that due to this behavior, if activity _S_ specifies failure handling with the values _retryFor=2, retryDelay=60_, and has a child activity _R_ that specifies failure handling with the values _retryFor=3_, the _retryDelay_ value for the child activity _R_ is 0, and not 60. Using the _failureHandling_ element without specifying one of its value elements will apply the default value for that element.
+
+<a name="ActivityFailureandRecovery-Examples"></a>
+### Examples
+
+A simple invoke with the `ext:failureHandling` extension:
+
+
+ <bpel:invoke inputVariable="myRequest"
+ operation="foo" outputVariable="aResponse"
+ partnerLink="myPartner" portType="spt:SomePortType">
+
+ <ext:failureHandling xmlns:ext="http://ode.apache.org/activityRecovery">
+ <ext:faultOnFailure>false</ext:faultOnFailure>
+ <ext:retryFor>2</ext:retryFor>
+ <ext:retryDelay>60</ext:retryDelay>
+ </ext:failureHandling>
+
+ </bpel:invoke>
+
+
+And a sequence activity that converts failures into faults:
+
+
+ <bpel:sequence>
+
+ <ext:failureHandling xmlns:ext="http://ode.apache.org/activityRecovery">
+ <ext:faultOnFailure>true</ext:faultOnFailure>
+ </ext:failureHandling>
+
+ ...
+
+ <bpel:invoke inputVariable="myRequest"
+ operation="foo" outputVariable="aResponse"
+ partnerLink="myPartner" portType="spt:SomePortType">
+
+ <bpel:catchAll>
+ ...
+ </bpel:catchAll>
+
+ </bpel:invoke>
+
+ </bpel:sequence>
+
+
+
+<a name="ActivityFailureandRecovery-ProcessInstanceManagement"></a>
+### Process Instance Management
+The process instance management provides the following information:
+* Process instance summary includes a _failures_ element with a count of the total number of process instances that have one or more activities in recovery mode, and the date/time of the last activity to enter recovery mode. The element exists if at least one activity is in recovery mode.
+* Process instance information includes a _failures_ element with a count of the number of activities in recovery mode, and the date/time of the last activity to enter recovery mode. The element exists if at least one activity is in recovery mode.
+* Activity instance information includes a _failure_ element that specifies the date/time of the failure, the reason for the failure, number of retries, and list of available recovery actions. The element exists if the activity is in the state _FAILURE_.
+
+Use the _recoverActivity_ operation to perform a recovery action on an activity in recovery mode. The operation requires the process instance ID, the activity instance ID and the recovery action to perform (one of retry, fault or cancel).
+
+You can also determine when failure or recovery occurred for a given activity instance from the execution log.
Added: ode/site/trunk/content/userguide/creating-a-process.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/creating-a-process.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/userguide/creating-a-process.mdtext (added)
+++ ode/site/trunk/content/userguide/creating-a-process.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,152 @@
+Title: Creating a Process
+[TOC]
+
+<a name="CreatingaProcess-DeployingaProcessinOde"></a>
+### Deploying a Process in ODE
+
+Each deployment is a directory with all relevant deployment artifacts. At the minimum it will contain the deployment descriptor, one or more process definitions (BPEL or .cbp), WSDL and XSDs (excluding those compiled into the .cbp). It may also contain other files, such as SVGs or XSLs. The deployment descriptor is a file named deploy.xml (see the next paragraoh for its description).
+
+During deployment, the process engine loads all documents from the deployment descriptor. Loading documents allow it to reference processes, service and schema definitions using fully qualified names, and import based on namespaces instead of locations.
+
+To deploy in ODE, just copy the whole directory containing your artifacts (the directory itself, not only its content) in the path %DEPLOYMENT_ROOT%/WEB-INF/processes (in Tomcat it would be %TOMCAT_HOME%/webapps/ode/WEB-INF/processes).
+
+<a name="CreatingaProcess-DeploymentDescriptor"></a>
+### Deployment Descriptor
+
+To deploy your process in ODE you will need to create a simple deployment descriptor with basic information. The deploy.xml file configures one or several processes to use specific services. For each process, deploy.xml must supply binding information for partner links to concrete WSDL services. Every partner link used with a <receive> activity must be matched with a <provide> element, and every partnerLink used in an <invoke> activity must be matched with an <invoke> element in *deploy.xml* (unless that partnerLink has initializePartnerRole="false").
+
+<a name="CreatingaProcess-Formaldefinition"></a>
+### Formal definition
+
+The XML schema describing ODE's deployment descriptor is available [here](http://svn.apache.org/viewvc/ode/trunk/bpel-schemas/src/main/xsd/dd.xsd?view=markup). The root element, deploy, contains a list of all deployed processes from the deployment directory:
+
+ <deploy>
+ <process ...>*
+ { other elements }
+ </process>
+ </deploy>
+
+Each process is identified by its qualified name and specifies bindings for provided and invoked services:
+
+ <process name = QName fileName = String? bpel11wsdlFileName = String? >
+ (<provide> | <invoke>)*
+ { other elements }
+ </process>
+
+Each process element must provide a `name` attribute with the qualified name of the process. Optionally, a `fileName` attribute can be used to specify the location of the BPEL process definition (the .bpel file). The `fileName` attribute does not need to be provided unless non-standard compilation options are used or the `bpel11wsdlFileName` attribute is used to specify a WSDL document for a BPEL 1.1 process.
+
+Each `<process>` element must enumerate the services provided by the process and bind each service to an endpoint. This is done through `<provide>` elements which associates `partnerLink`s with `endpoint`s:
+
+ <provide partnerLink=NCName>
+ <service name = QName port = NCName?>
+ </provide>
+
+Note, that only one partnerLink can be bound to any specified endpoint.
+
+The port attribute can be used to select a particular endpoint from the service definition.
+
+<a name="CreatingaProcess-Examples"></a>
+#### Examples
+
+A very simple process that would only be invoked would use a deploy.xml very similar to:
+
+
+ <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
+ xmlns:pns="http://ode/bpel/unit-test" xmlns:wns="http://ode/bpel/unit-test.wsdl">
+ <process name="pns:HelloWorld2">
+ <active>true</active>
+ <provide partnerLink="helloPartnerLink">
+ <service name="wns:HelloService" port="HelloPort"/>
+ </provide>
+ </process>
+ </deploy>
+
+
+See the complete example [here](https://svn.apache.org/repos/asf/ode/trunk/distro-axis2/src/examples/HelloWorld2/).
+
+A deployment including two processes invoking each other and whose execution would be triggered by a first message would look like:
+
+
+ <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:main="http://ode/bpel/unit-test"
+ xmlns:mws="http://ode/bpel/unit-test.wsdl" xmlns:resp="http://ode/bpel/responder">
+
+ <process name="main:MagicSessionMain">
+ <provide partnerLink="executePartnerLink">
+ <service name="mws:MSMainExecuteService" port="MSExecutePort"/>
+ </provide>
+ <provide partnerLink="responderPartnerLink">
+ <service name="mws:MSMainService" port="MSMainPort"/>
+ </provide>
+ <invoke partnerLink="responderPartnerLink">
+ <service name="mws:MSResponderService" port="MSResponderPort"/>
+ </invoke>
+ </process>
+ <process name="resp:MagicSessionResponder">
+ <type>resp:MagicSessionResponder</type>
+ <provide partnerLink="mainPartnerLink">
+ <service name="mws:MSResponderService" port="MSResponderPort"/>
+ </provide>
+ <invoke partnerLink="mainPartnerLink">
+ <service name="mws:MSMainService" port="MSMainPort"/>
+ </invoke>
+ </process>
+ </deploy>
+
+
+See the complete example [here](https://svn.apache.org/repos/asf/ode/trunk/distro-axis2/src/examples/MagicSession/).
+
+<a name="CreatingaProcess-Additionalsettings"></a>
+#### Additional settings
+
+<a name="CreatingaProcess-Inmemoryexecution"></a>
+##### In memory execution
+
+For performance purposes, you can define a process as being executed only in-memory. This greatly reduces the amount of generated queries and puts far less load on your database. Both persistent and non-persistent processes can cohabit in ODE.
+
+To declare a process as in-memory just add an in-memory element in your deploy.xml:
+
+
+ <process name="pns:HelloWorld2">
+ <in-memory>true</in-memory>
+ <provide partnerLink="helloPartnerLink">
+ <service name="wns:HelloService" port="HelloPort"/>
+ </provide>
+ </process>
+
+
+Be aware that in-memory executions introduces many restrictions on your process and what it can do. The instances of these processes can't be queried by using the [Management API](management-api.html). The process definition can only include one single receive activity (the one that will trigger the instance creation).
+
+<a name="CreatingaProcess-User-definedprocessproperties"></a>
+##### User-defined process properties
+
+User-defined process properties provide means to configure process models and their instances. They are either statically declared and set in the deployment descriptor `deploy.xml` or can be set using the process management API. All instances of a process model share the same set of process properties. If a process property changes, it changes for all instances.
+
+A process property is identified by a QName and can carry a string as value. To set a process property statically in the deployment descriptor, add the following snippet to your `deploy.xml`:
+
+
+ <process name="pns:HelloWorld2">
+ ...
+ <property xmlns:loan="urn:example" name="loan:loanThreshold">4711</property>
+ ...
+ </process>
+
+
+It is also possible to set or change a property by calling the PM API function `setProcessProperty(final QName pid, final QName propertyName, final String value)`.
+
+Once set, process properties can be used in two different ways:
+ * Using XPath in process models
+ * Using Java in ODE extensions
+
+For instance, instead of hard coding the amount of money that triggers an in-depth check in a loan approval process, you could read a process property instead. That way you can reconfigure your process without having to redeploy the process again.
+
+To read process properties in a BPEL process, you can use the non-standard XPath extension `bpws:process-property(propertyName)`, e.g. in a transition condition or in an assign activity:
+
+
+ ...
+ <assign>
+ <copy>
+ <from xmlns:loan="urn:example">bpws:process-property(loan:loanThreshold)</from>
+ <to>$threshold</to>
+ </copy>
+ </assign>
+ ...
Added: ode/site/trunk/content/userguide/direct-process-to-process-communication.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/direct-process-to-process-communication.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/userguide/direct-process-to-process-communication.mdtext (added)
+++ ode/site/trunk/content/userguide/direct-process-to-process-communication.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,2 @@
+Title: Direct Process-to-Process Communication
+ODE automatically optimizes all process-to-process communication such that all message exchanges happen directly inside the engine and do not go through the integration layer (e.g. Axis2, JBI, ...).
Added: ode/site/trunk/content/userguide/endpoint-references.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/endpoint-references.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/userguide/endpoint-references.mdtext (added)
+++ ode/site/trunk/content/userguide/endpoint-references.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,163 @@
+Title: Endpoint References
+<a name="EndpointReferences-Introduction"></a>
+### Introduction
+An endpoint reference holds information to call a service. The simplest endpoint reference is usually an URL but it can also be much more complex such as holding a message id, a reply-to address or custom properties.
+
+In BPEL, endpoint references (aka EPRs) are modeled as partner link roles. When defining a partner link, two roles maybe defined, `myRole` and `partnerRole`:
+
+
+ <partnerLink name="responderPartnerLink" partnerLinkType="test:ResponderPartnerLinkType"
+ myRole="main" partnerRole="responder" initializePartnerRole="yes"/>
+
+
+Both `partnerRole` and `myRole` represent EPRs. So when assigning partner link roles or invoking partners, you are using EPRs behind the scene.
+
+<a name="EndpointReferences-ODEandEndpointReferences"></a>
+### ODE and Endpoint References
+
+<a name="EndpointReferences-TypesofEPRs"></a>
+#### Types of EPRs
+
+The ODE runtime supports 4 types of EPRs:
+
+* A simple URL or a URL in the location attribute of the binding. See [soap:address](http://www.w3.org/TR/wsdl#_soap:address) and [http:address](http://www.w3.org/TR/wsdl#_http:address) WSDL 1.1 binding.
+* A [WS-Addressing](http://www.w3.org/TR/ws-addr-core/) [EndpointReference](http://www.w3.org/TR/ws-addr-core/#eprinfomodel).
+* A [WSDL 1.1](http://www.w3.org/TR/wsdl) [service element](http://www.w3.org/TR/wsdl#_services).
+* A [WSDL 2.0](http://www.w3.org/TR/wsdl20/) [endpoint element](http://www.w3.org/TR/wsdl20/#Endpoint).
+
+We recommend the two first solutions to interact with the engine. The first one is just the easiest and for the case where you need more robustness, WS-Addressing is the most popular second choice.
+
+To show you how these EPRs look like and how they can be assigned to partner links roles here are some examples:
+
+
+ <assign>
+
+ <!-- Simple URL, without the wrapper -->
+ <copy>
+ <from>
+ <literal>http://localhost:8080/ode/dynresponder</literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ <!-- Simple URL, wrapped in an soap:address element -->
+ <copy>
+ <from>
+ <literal>
+ <service-ref>
+ <soap:address location="http://localhost:8080/ode/dynresponder"/>
+ </service-ref>
+ </literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ <!-- WS-Addressing EPR, without the wrapper -->
+ <copy>
+ <from>
+ <literal>
+ <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
+ <wsa:To>http://localhost:8080/ode/dynresponder</wsa:To>
+ </wsa:EndpointReference>
+ </literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ <!-- WS-Addressing EPR, with the wrapper -->
+ <copy>
+ <from>
+ <literal>
+ <service-ref>
+ <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
+ <wsa:To>http://localhost:8080/ode/dynresponder</wsa:To>
+ </wsa:EndpointReference>
+ <service-ref>
+ </literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ <!-- WSDL1.1 EPR, without the wrapper -->
+ <copy>
+ <from>
+ <literal>
+ <wsdl:service xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" name="DynService" targetNamespace="http://org.apache.ode/examples/dynservice">
+ <wsdl:port name="DynPort">
+ <soap:address location="http://localhost:8080/ode/dynresponder"/>
+ </wsdl:port>
+ </wsdl:service>
+ </literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ <!-- WSDL2.0 EPR, with the wrapper -->
+ <copy>
+ <from>
+ <literal>
+ <service-ref>
+ <wsdl:service xmlns:wsdl="http://www.w3.org/2006/01/wsdl" name="DynService" targetNamespace="http://org.apache.ode/examples/dynservice">
+ <wsdl:port name="DynPort">
+ <soap:address location="http://localhost:8080/ode/dynresponder"/>
+ </wsdl:port>
+ </wsdl:service>
+ </service-ref>
+ </literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ </assign>
+
+
+Normally BPEL requires wrapping EPRs with inside a `service-ref` element, however ODE relaxes this requirement for ease of use and increased interoperability with existing services. If the `service-ref` element is absent, the EPR is automatically wrapped inside one on the fly. Moreover, ODE automatically detects the different EPR types when assigning to a partner link role. If you need to use WS-Addressing sessions (@see appropriate page), then you will have to use `wsa:EndpointReference` EPRs.
+
+You can just as well assign EPRs to/from variables to pass them around and enable more dynamic communication patterns.
+
+<a name="EndpointReferences-PassingEndpointReferences"></a>
+### Passing Endpoint References
+
+To pass endpoint references around and manipulate them, you usually need to assigne them to variables. The EPR can then be sent in a message and reassigned to another partner link. This lets you model complex scenarii where you don't know the address of your partner beforehand or where you select one partner among many others.
+
+The type of the variable that will hold your EPR defines the type of the EPR that it will contain. For example if you define a message in your WSDL document that looks like this:
+
+
+ <wsdl:message name="EndpointMessage">
+ <wsdl:part name="payload" element="xsd:string"/>
+ </wsdl:message>
+
+
+ODE will automatically put a simple URL EPR when you assign this message part:
+
+
+ <variable name="myEndpoint" messageType="resp:EndpointMessage"/>
+ ...
+ <assign>
+ <copy>
+ <from partnerLink="mainPartnerLink" endpointReference="myRole"/>
+ <to variable="myEndpoint" part="payload"/>
+ </copy>
+ </assign>
+
+
+Now if you want to manipulate a WS-Addressing EPR, the only thing you have to change in the above examples is the message part type. So your message will then look like this:
+
+<wsdl:message name="EndpointMessage">
+ <wsdl:part name="payload" element="wsa:EndpointReference"/>
+</wsdl:message>
+
+Once your EPR has been assigned to a variable and set, say, to another process, you just need to reassign it to a partner link `partnerRole` to use it:
+
+
+ <assign>
+ <copy>
+ <from variable="eprmessage" part="payload"/>
+ <to partnerLink="mainPartnerLink"/>
+ </copy>
+ </assign>
+ <invoke name="eprcall" partnerLink="mainPartnerLink"
+ portType="resp:MSMainPortType" operation="call" inputVariable="eprmessage"/>
+
+
+For a complete example check [DynPartner](http://svn.apache.org/repos/asf/ode/trunk/distro/src/examples-war/DynPartner/) in the engine examples.
Modified: ode/site/trunk/content/userguide/index.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/index.mdtext?rev=1426497&r1=1426496&r2=1426497&view=diff
==============================================================================
--- ode/site/trunk/content/userguide/index.mdtext (original)
+++ ode/site/trunk/content/userguide/index.mdtext Fri Dec 28 13:13:31 2012
@@ -31,7 +31,7 @@ ODE can be deployed in three different e
1. [Endpoint References](endpoint-references.html)
1. [WSDL 1.1 HTTP Binding Support](wsdl-1.1-http-binding-support.html)
1. [WSDL 1.1 Extensions for REST](wsdl-1.1-extensions-for-rest.html)
-1. [BPEL Extensions](bpel-extensions.html)
+1. [BPEL Extensions](/extensions/)
1. [Instance Data Cleanup](instance-data-cleanup.html)
1. [Direct Process-to-Process Communication](direct-process-to-process-communication.html)
1. [Stateful Exchange Protocol](stateful-exchange-protocol.html)
Added: ode/site/trunk/content/userguide/instance-data-cleanup.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/instance-data-cleanup.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/userguide/instance-data-cleanup.mdtext (added)
+++ ode/site/trunk/content/userguide/instance-data-cleanup.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,145 @@
+Title: Instance Data Cleanup
+<a name="InstanceDataCleanup-Rational"></a>
+## Rational
+
+
+During its execution, a process instance can accumulate a significant amount of data. The running process itself isn't that much of an issue, when the instance is done there's nothing left to execute. But the process data can be rather big, mostly because of the messages it received and sent and its own variables. All of these are XML documents and in some cases, sizable ones.
+
+<a name="InstanceDataCleanup-Levelsofcleanup"></a>
+## Levels of cleanup
+
+<a name="InstanceDataCleanup-Cleanuponcompletion"></a>
+### Cleanup on completion
+
+{panel}
+This feature is only available in ODE 1.3 or later
+{panel}
+
+The easiest approach to get started is simply to wait until the instance execution is finished and then cleanup everything that's related to it. That would include the instance state with its variables, scopes and correlation, but also all the messages it has received and sent. Execution events should also be disposed of. So this description defines 5 different categories: instance, messages and events. We should be able to turn on and off each level separately.
+
+* instance: ODE_PROCESS_INSTANCE, EXECUTION_STATE
+* variables: ODE_SCOPE, ODE_XML_DATA, ODE_PARTNER_LINK
+* messages: ODE_MESSAGE, ODE_MESSAGE_ROUTE, ODE_MEX_PROPS, ODE_MESSAGE_EXCHANGE
+* correlations: ODE_CORRELATION_SET, ODE_CORSET_PROP
+* events: ODE_EVENTS
+
+<a name="InstanceDataCleanup-dtd"></a>
+#### dtd
+
+ <xs:element name="cleanup" minOccurs="0" maxOccurs="3" type="dd:tCleanup" />
+
+ <xs:complexType name="tCleanup">
+ <xs:sequence>
+ <xs:element name="category" default="all" minOccurs="0" maxOccurs="unbounded">
+ <xs:simpleType>
+ <xs:restriction base="xs:string">
+ <xs:enumeration value="instance" />
+ <xs:enumeration value="variables" />
+ <xs:enumeration value="messages" />
+ <xs:enumeration value="correlations" />
+ <xs:enumeration value="events" />
+ <xs:enumeration value="all" />
+ </xs:restriction>
+ </xs:simpleType>
+ </xs:element>
+ </xs:sequence>
+ <xs:attribute name="on" use="required">
+ <xs:simpleType>
+ <xs:restriction base="xs:string">
+ <xs:enumeration value="success" />
+ <xs:enumeration value="failure" />
+ <xs:enumeration value="always" />
+ </xs:restriction>
+ </xs:simpleType>
+ </xs:attribute>
+ </xs:complexType>
+
+
+<a name="InstanceDataCleanup-examples"></a>
+#### examples
+1. no instance data cleanup
+
+
+ <process name="pns:HelloWorld2">
+ <active>true</active>
+ <provide partnerLink="helloPartnerLink">
+ <service name="wns:HelloService" port="HelloPort"/>
+ </provide>
+ </process>
+
+
+2. cleaning up all data on either successful or faulty completions of instances
+
+
+ <process name="pns:HelloWorld2">
+ <active>true</active>
+ <provide partnerLink="helloPartnerLink">
+ <service name="wns:HelloService" port="HelloPort"/>
+ </provide>
+ <cleanup on="always" />
+ </process>
+
+
+3. cleaning up all data on successful completions of instances and no data cleanup on faulty completions
+
+
+ <process name="pns:HelloWorld2">
+ <active>true</active>
+ <provide partnerLink="helloPartnerLink">
+ <service name="wns:HelloService" port="HelloPort"/>
+ </provide>
+ <cleanup on="success" >
+ <category>instance</category>
+ <category>variables</category>
+ <category>messages</category>
+ <category>correlations</category>
+ <category>events</category>
+ </cleanup>
+ </process>
+
+
+4. cleaning up all data on successful completions of instances and only messages and correlations on faulty completions
+
+
+ <process name="pns:HelloWorld2">
+ <active>true</active>
+ <provide partnerLink="helloPartnerLink">
+ <service name="wns:HelloService" port="HelloPort"/>
+ </provide>
+
+ <cleanup on="success" >
+ <category>all</category>
+ </cleanup>
+ <cleanup on="failure">
+ <category>messages</category>
+ <category>correlations</category>
+ </cleanup>
+ </process>
+
+
+5. an +invalid+ configuration; the instance category should accompany the variable and correlations categories
+
+
+ <process name="pns:HelloWorld2">
+ <active>true</active>
+ <provide partnerLink="helloPartnerLink">
+ <service name="wns:HelloService" port="HelloPort"/>
+ </provide>
+ <cleanup on="success" >
+ <category>all</category>
+ </cleanup>
+ <cleanup on="failure">
+ <category>instance</category>
+ </cleanup>
+ </process>
+
+
+<a name="InstanceDataCleanup-FutureDevelopments"></a>
+### Future Developments
+
+WS-BPEL makes heavy use of scopes, those could be another hook in the execution lifecycle for the cleanup to take place. So instead of waiting until the instance is finished and clean up the whole state, we could proceed by smaller increments and delete the state scope by scope. For short running processes (say less than a few days) the advantages of this approach are minimal but for long running processes (say months), there's potentially a lot of unused state that's just sitting there and will never be used anymore.
+
+<a name="InstanceDataCleanup-Finalnotes"></a>
+## Final notes
+
+When we continue along the lines of refining further when the cleanup should occur and what exactly should be cleaned up, we quickly start getting close to the transaction boundaries. Down the road, ideally, we shouldn't persist anything unnecessarily, so that no cleanup is needed when a given piece of data will never be reused. It's often the case for message variables for example, where a process will receive a message, assign some values from it and never use that message variable anymore. So this should never get written, minimizing the writes and deletes.
Added: ode/site/trunk/content/userguide/instance-replayer.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/instance-replayer.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/userguide/instance-replayer.mdtext (added)
+++ ode/site/trunk/content/userguide/instance-replayer.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,124 @@
+Title: Instance Replayer
+<a name="InstanceReplayer-Introduction"></a>
+## Introduction
+
+With instance replayer, you are able to upgrade long running process instance to the newest version.
+
+There's an ongoing discussion on apache.org in a feature request:
+
+
+[https://issues.apache.org/jira/browse/ODE-483](https://issues.apache.org/jira/browse/ODE-483).
+
+<a name="InstanceReplayer-Example"></a>
+## Example
+
+Attached are example service assembly [^replayer-example-sa.zip](^replayer-example-sa.zip.html) and SoapUI project [^replayer-example-soapui-project.xml].
+
+<a name="InstanceReplayer-Usage"></a>
+## Usage
+
+The basic use cases for replayer are:
+
+1. migrate existing log running instances to newest process version given their communication (incoming and outgoing requests)
+1. reproduce error scenarios between two instances of ODE (eg. production and development)
+
+Replayer extends management api by 2 operations: replay and getCommunication (see pmapi.wsdl from ODE distribution).
+
+In order to do 1, you invoke:
+
+ <pmap:replay xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/">
+ <replay>
+ <ns:upgradeInstance>1234</ns:upgradeInstance>
+ </replay>
+ </pmap:replay>
+
+To do 2, you need to retrieve exchanges from instance (or instances) by:
+
+ <pmap:getCommunication xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/">
+ <getCommunication>
+ <ns:iid>1234</ns:iid>
+ </getCommunication>
+ </pmap:getCommunication>
+
+
+ <ns:restoreInstance>
+ <ns:processType xmlns:p="http://sample.bpel.org/bpel/sample">p:OnEventCorrelation</ns:processType>
+ <exchange xmlns="http://www.apache.org/ode/pmapi/types/2006/08/02/">
+ <type>M</type>
+ <createTime>2009-04-01T16:41:29.873+02:00</createTime>
+ <service xmlns:sam="http://sample.bpel.org/bpel/sample">sam:OnEventCorrelationInit</service>
+ <operation>initiate</operation>
+ <in>
+ <initiate xmlns:sam="http://sample.bpel.org/bpel/sample" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="">
+ <payload>abc7</payload>
+ <payload2>abc8</payload2>
+ </initiate>
+ </in>
+ <out>
+ <message xmlns="">
+ <payload>test1</payload>
+ <payload2/>
+ </message>
+ </out>
+ </exchange>
+
+ <exchange xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/" xmlns="http://www.apache.org/ode/pmapi/types/2006/08/02/">
+ <type>P</type>
+ <createTime>2009-04-01T16:41:32.998+02:00</createTime>
+ <service xmlns:sam="http://sample.bpel.org/bpel/sample">sam:OnEventCorrelation</service>
+ <operation>initiate</operation>
+ <in>
+ <initiate xmlns:sam="http://sample.bpel.org/bpel/sample" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="">
+ <payload>abc7</payload>
+ <payload2>abc8</payload2>
+ </initiate>
+ </in>
+ <out>
+ <message xmlns="">
+ <payload>test5</payload>
+ <payload2/>
+ </message>
+ </out>
+ </exchange>
+ </ns:restoreInstance>
+
+
+
+Then, you execute replay on the other ODE installation to replicate instance:
+
+
+ <pmap:replay xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/">
+ <replay>
+ <ns:restoreInstance>
+ <ns:processType xmlns:p="http://sample.bpel.org/bpel/sample">p:OnEventCorrelation</ns:processType>
+ ... exchanges
+ </ns:restoreInstance>
+ </replay>
+ </pmap:replay>
+
+
+
+<a name="InstanceReplayer-TimecontrolinBPEL"></a>
+## Time control in BPEL
+
+
+To have control over time in bpel process, there is a new variable introduced, $ode:currentEventDateTime.
+It's equivalent to $fn:current-dateTime() during live session and it's set to corresponding time in past during replaying.
+
+
+<a name="InstanceReplayer-Implementationnotes"></a>
+## Implementation notes
+
+* Replaying works in one transaction.
+You can migrate a few instances at once and get an error, which will roll back all work if an error occurrs in some case.
+* Replayer extends BpelRuntimeContextImpl by ReplayerBpelRuntimeContextImpl class, which overrides methods like invoke and registerTimer to mock up communication.
+* It implements ReplayerScheduler, which executes actions from past in time sorted order (exchanges given to replayer have createTime field, which is used for sorting)
+* jobs from past are processed in ReplayerScheduler and jobs in future are registered in engine's scheduler
+* In order to make integrity constraints, replaying returns error if:
+** a first incoming request is routed to an existing instance instead of creating a new one
+** next incoming request is routed to other instance or creates a new instance
+** there is some unprocessed communication while finishing replaying (for example if there is some outgoing exchange for service, which did not have INVOKE from replayed instance)
+* It extends bpel-compiler and xpath evaluation by $ode:currentEventDateTime variable
+* It adds currentEventDateTime property to BpelRuntimeContext
+* It adds replayer package to bpel engine in bpel-runtime module
+* It changes visibility of some fields and methods in bpel engine from private to protected and from optional to public.
Added: ode/site/trunk/content/userguide/management-api.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/management-api.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/userguide/management-api.mdtext (added)
+++ ode/site/trunk/content/userguide/management-api.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,24 @@
+Title: Management API
+
+## Overview
+ODE has a complete management API to check which processes are deployed, running and completed instances, variables values and more. To see which methods are available, have a look at the [ProcessManagement](http://ode.apache.org/javadoc/org/apache/ode/bpel/pmapi/ProcessManagement.html) and [InstanceManagement](http://ode.apache.org/javadoc/org/apache/ode/bpel/pmapi/InstanceManagement.html) interfaces, the javadoc is pretty comprehensive.
+
+These two interfaces are available as web services on the Axis2-based distribution. The corresponding WSDL can be found [here](http://svn.apache.org/repos/asf/ode/trunk/axis2/src/main/wsdl/pmapi.wsdl).
+
+To invoke these two services, any web service client should work (in a perfect interoperable world). To ease the invocation when using an Axis2 client, a helper class is bundled in ode-axis2.jar: [ServiceClientUtil](http://ode.apache.org/javadoc/axis2/org/apache/ode/axis2/service/ServiceClientUtil.html). Usage examples are also available in test classes [InstanceManagementTest](http://svn.apache.org/repos/asf/ode/trunk/axis2/src/test/java/org/apache/ode/axis2/management/InstanceManagementTest.java) and [ProcessManagementTest](http://svn.apache.org/repos/asf/ode/trunk/axis2/src/test/java/org/apache/ode/axis2/management/ProcessManagementTest.java). Here is a short example demonstrating the invocation of the _listAllProcesses_ operation:
+ :::java
+ ServiceClientUtil client = new ServiceClientUtil();
+ OMElement root = client.buildMessage("listAllProcesses", new String[](.html) {}, new String[] {});
+ OMElement result = client.send(msg, "http://localhost:8080/ode/processes/ProcessManagement");
+
+We're using [XMLBeans](http://xmlbeans.apache.org/) to serialize and deserialize the returned values from/to XML so in the previous example. So if you'd like to have objects instead of an [Axiom](http://ws.apache.org/commons/axiom/index.html) structure in the previous example, just add the following lines of code:
+
+ :::java
+ ScopeInfoDocument scopeIndoDoc = ScopeInfoDocument.Factory.parse(result.getXMLStreamReader());
+
+You will need to include ode-bpel-api.jar in your classpath.
+
+<a name="ManagementAPI-Specification"></a>
+## Specification
+
+More details are available in the [Process Management API specification](bpel-management-api-specification.html)
Added: ode/site/trunk/content/userguide/ode-execution-events.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/ode-execution-events.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/userguide/ode-execution-events.mdtext (added)
+++ ode/site/trunk/content/userguide/ode-execution-events.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,118 @@
+Title: ODE Execution Events
+ODE generates events to let you track what is exactly happening in the engine and produces detailed information about process executions. These events are persisted in ODE's database and can be queried using the [Management API](management-api.html). The default behavior for the engine is to always generate all events for every executed action. However from a performance standpoint it's a good idea to deactivate some of the events you're not interested in (or even all of them). Inserting all these events generates a non-negligeable overhead.
+
+<a name="ODEExecutionEvents-Eventtypes"></a>
+### Event types
+
+The following table details each event possibly generated by ODE:
+
+<table>
+<tr><th>Event Name</th><th>Process/Scope</th><th>Description</th><th>Type</th></tr>
+<tr><td>ActivityEnabledEvent </td><td> Scope </td><td> An activity is enabled (just before it's started) </td><td> activityLifecycle
+</tr>
+<tr><td>ActivityDisabledEvent </td><td> Scope </td><td> An activity is disabled (due to dead path elimination) </td><td> activityLifecycle
+</tr>
+<tr><td>ActivityExecStartEvent </td><td> Scope </td><td> An activity starts its execution </td><td> activityLifecycle
+</tr>
+<tr><td>ActivityExecEndEvent </td><td> Scope </td><td> An activity execution terminates </td><td> activityLifecycle
+</tr>
+<tr><td>ActivityFailureEvent </td><td> Scope </td><td> An activity failed </td><td> activityLifecycle
+</tr>
+<tr><td>CompensationHandlerRegistered </td><td> Scope </td><td> A compensation handler gets registered on a scope </td><td> scopeHandling
+</tr>
+<tr><td>CorrelationMatchEvent </td><td> Process </td><td> A matching correlation has been found upon reception of a message </td><td> correlation
+</tr>
+<tr><td>CorrelationNoMatchEvent </td><td> Process </td><td> No matching correlation has been found upon reception of a message </td><td> correlation
+</tr>
+<tr><td>CorrelationSetWriteEvent </td><td> Scope </td><td> A correlation set value has been initialized </td><td> dataHandling
+</tr>
+<tr><td>ExpressionEvaluationFailedEvent </td><td> Scope </td><td> The evaluation of an expression failed </td><td> dataHandling
+</tr>
+<tr><td>ExpressionEvaluationSuccessEvent </td><td> Scope </td><td> The evaluation of an expression succeeded </td><td> dataHandling
+</tr>
+<tr><td>NewProcessInstanceEvent </td><td> Process </td><td> A new process instance is created </td><td> instanceLifecycle
+</tr>
+<tr><td>PartnerLinkModificationEvent </td><td> Scope </td><td> A partner link has been modified (a new value has been assigned to it) </td><td> dataHandling
+</tr>
+<tr><td>ProcessCompletionEvent </td><td> Process </td><td> A process instance completes </td><td> instanceLifecycle
+</tr>
+<tr><td>ProcessInstanceStartedEvent </td><td> Process </td><td> A process instance starts </td><td> instanceLifecycle
+</tr>
+<tr><td>ProcessInstanceStateChangeEvent </td><td> Process </td><td> The state of a process instance has changed </td><td> instanceLifecycle
+</tr>
+<tr><td>ProcessMessageExchangeEvent </td><td> Process </td><td> A process instance has received a message </td><td> instanceLifecycle
+</tr>
+<tr><td>ProcessTerminationEvent </td><td> Process </td><td> A process instance terminates </td><td> instanceLifecycle
+</tr>
+<tr><td>ScopeCompletionEvent </td><td> Scope </td><td> A scope completes </td><td> scopeHandling
+</tr>
+<tr><td>ScopeFaultEvent </td><td> Scope </td><td> A fault has been produced in a scope </td><td> scopeHandling
+</tr>
+<tr><td>ScopeStartEvent </td><td> Scope </td><td> A scope started </td><td> scopeHandling
+</tr>
+<tr><td>VariableModificationEvent </td><td> Scope </td><td> The value of a variable has been modified </td><td> dataHandling
+</tr>
+<tr><td>VariableReadEvent </td><td> Scope </td><td> The value of a variable has been read </td><td> dataHandling
+</tr>
+</table>
+
+The second column specifies wether an event is associated with the process itself or with one of its scopes. The event type is used for filtering events.
+
+<a name="ODEExecutionEvents-Filteringevents"></a>
+### Filtering events
+
+<a name="ODEExecutionEvents-Filteringattheprocesslevel"></a>
+#### Filtering at the process level
+
+Using ODE's deployment descriptor, it's possible to tweak events generation to filtrate which ones get created. First, events can be filtered at the process level using one of the following stanza:
+
+
+ <dd:process-events generate="all"/> <!-- Default configuration -->
+
+ <dd:process-events generate="none"/>
+
+ <dd:process-events>
+ <dd:enable-event>dataHandling</dd:enable-event>
+ <dd:enable-event>activityLifecycle</dd:enable-event>
+ </dd:process-events>
+
+
+The first form just duplicates the default behaviour, when nothing is specified in the deployment descriptor, all events are generated. The third form lets you define which type of event is generated, possible types are: `instanceLifecycle`, `activityLifecycle`, `dataHandling`, `scopeHandling`, `correlation`.
+
+<a name="ODEExecutionEvents-Filteringatthescopelevel"></a>
+#### Filtering at the scope level
+
+It's also possible to define filtering for each scope of your process. This overrides the settings defined on the process. In order to define event filtering on a scope, the scope activity MUST have a name in your process definition. Scopes are referenced by name in the deployment descriptor:
+
+
+ <dd:deploy xmlns:dd="http://www.apache.org/ode/schemas/dd/2007/03">
+ ...
+ <dd:process-events generate="none">
+ <dd:scope-events name="aScope">
+ <dd:enable-event>dataHandling</bpel:enable-event>
+ <dd:enable-event>scopeHandling</bpel:enable-event>
+ </dd:scope-events>
+ <dd:scope-events name="anotherScope">
+ <dd:enable-event>activityLifecycle</bpel:enable-event>
+ </dd:scope-events>
+ </dd:process-events>
+ ...
+ </dd:deploy>
+
+
+Note that it's useless to enable an event associated with the process itself when filtering events on scopes.
+
+The filter defined on a scope is automatically inherited by its inner scopes. So if no filter is defined on a scope, it will use the settings of its closest parent scope having event filters (up to the process). Note that what gets inherited is the full list of selected events, not each event definition individually.
+
+<a name="ODEExecutionEvents-Eventlisteners"></a>
+### Event listeners
+
+ODE lets you register your own event listeners to analyze all produced events and do whatever you want to do with them. To create a listener you just need to implement the [org.apache.ode.bpel.iapi.BpelEventListener](https://svn.apache.org/repos/asf/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/BpelEventListener.java) interface.
+
+Then add your implementation in the server's classpath and add a property in ode-axis2.properties giving your fully qualified implementation class name. Something like:
+
+
+ ode-axis2.event.listeners=com.compamy.product.MyOdeEventListener
+
+
+Start your server and you're done!
Added: ode/site/trunk/content/userguide/process-versioning.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/process-versioning.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/userguide/process-versioning.mdtext (added)
+++ ode/site/trunk/content/userguide/process-versioning.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,67 @@
+Title: Process Versioning
+ * [Introduction](#ProcessVersioning-Introduction)
+ * [How Versioning Works](#ProcessVersioning-HowVersioningWorks)
+ * [Process Versioning in ODE](#ProcessVersioning-ProcessVersioninginOde)
+ * [Remote Deployment vs. Hand-Made Deployment](#ProcessVersioning-RemoteDeploymentvs.Hand-MadeDeployment)
+
+<a name="ProcessVersioning-Introduction"></a>
+### Introduction
+
+Before starting on what process versioning exactly does, let's see what the world (or at least ODE) would be without versioning. It will be much more easier for you to understand the solution after fully seeing the problem.
+
+So you're starting using ODE and you've just designed you first business process. It's all nice and dandy and works perfectly. It works so well that you let your users start using it. It's not really production but you know, release early, release often, so let's see what users think of it. After a couple of days you realize that a couple of steps are missing, you add them in your process and once again, it executes smoothly. So let's see what our users think of the improvement! Next thing you know, your phone starts ringing and the user on the other side is most likely pretty upset. What happened?
+
+So when you start using a process, executions for it are created, running processes if you like (also called process instances). Depending on the type of your business these could take a variable amount of time to execute but they're usually not instantaneous. So you have all these running processes sometimes doing things, sometimes just waiting there and all of a sudden, a brand new process definition replaces the original one all these executions have been using so far. What is a process engine to do with all these executions? Well, the most logic thing on earth: just nuke them all.
+
+At this time there's no simple automated way to migrate a running process that has been executing using one definition to another new one. Computing the differences between the 2 definitions can be very complex and chances are that they're not even compatible! When you think of all these little tasks that are arranged just so to guarantee a perfect execution using the right data types, even minor alterations can get really tricky to apply on instances without blowing them all.
+
+So here is the crude and sad truth: without having some versioning goodness in it, a process engine will always delete all the running instances when a new process definition is deployed.
+
+<a name="ProcessVersioning-HowVersioningWorks"></a>
+### How Versioning Works
+
+So if existing executions can't be migrated, what are you going to do with them? Well, just let them be. Versioning is based on the fact that, instead of directly updating the original process definition (leaving its instances to their dreadful fate), another new version of this definition is created. The older one is declared retired so no new executions can be started on that one, the new process is the one to be used now on. But running instances can still finish their job peacefully as the process they've been using to execute so far is still available and unchanged.
+
+However ODE also has the concept of deployment bundles and supports 2 modes of deployment (remotely or manually directly on the filsesystem). Let's see how we get versioning to work under those conditions.
+
+<a name="ProcessVersioning-ProcessVersioninginOde"></a>
+#### Process Versioning in ODE
+
+In ODE, processes are deployed in what we call a deployment bundle. When you come down to it, it's just a zip file or a directory containing ODE's deployment descriptor ([deploy.xml](creating-a-process#deployment-descriptor.html)), the processes BPEL and all the other goodies necessary for your BPEL to run (WSDLs, schemas, xsl stylesheets, you name it). And what ODE is using to know you're redeploying the same thing is the deployment bundle name.
+
+So when you're redeploying a deployment bundle in ODE, here is what happens:
+
+1. A new version is attributed to the bundle by incrementing the version number of the last deployment.
+1. ODE checks whether the same bundle has been deployed before, _all_ processes in those older bundles are retired.
+1. The processes in the bundle are deployed in the engine using the same version number as the bundle itself.
+1. New executions of all newly deployed processes are ready to be started.
+
+There are a couple of additional remarks to make. The first is that the version is a single, sequentially incremented (which is to say that 3 comes after 2 and 2 comes after 1) number. _All_ deployed bundles share the same sequence. The second thing to be aware of is that all processes in a bundle share the same version number and it's the number of their bundle.
+
+Let's use the notation Foo-x(Bar-x, Baz-x) to represent the deployment of the Foo bundle in version x with processes Bar and Baz (sharing the same version number as just explained). The following illustrates a valid deployment sequence:
+
+1. Coconut-1(Pineapple-1, Mango-1)
+1. Orange-2(Tangerine-2)
+1. Orange-3(Tangerine-3) => retires Orange-2(Tangerine-2)
+1. Coconut-4(Pineapple-4, Mango-4) => retires Coconut-1(Pineapple-1, Mango-1)
+1. Banana-5(Kiwi-5)
+
+That's both tasty and healthy!
+
+There's still a last question left unsolved: what happens if you take your bundle and deploy it under a different name with the same content. If you know a bit about source version control (like CVS or Subversion), that's very close to branching, only you might be executing two branches at the same time. As ODE can't find another bundle with the same, the processes will simply be deployed _without_ retiring anything. You will effectively have twice the same process deployed under different versions. In that scenario you're supposed to know what you're doing.
+
+If two identical process definitions are deployed at the same time, the behavior of the engine is unspecified. Which one of the two process will pick up the message? Who knows!? But this can be a very useful feature in specific cases when you want to deploy the same process twice (by same understand same name and same namespace) but the 2 definitions are actually different and enable different endpoints. This allows the parallel deployment of two different version of the same process provided that they don't overlap in their endpoint implementation.
+
+<a name="ProcessVersioning-RemoteDeploymentvs.Hand-MadeDeployment"></a>
+#### Remote Deployment vs. Hand-Made Deployment
+
+ODE supports 2 different ways of deploying bundles:
+
+* using the deployment web service or JBI deployment.
+* dropping bundles as directories under WEB-INF/processes.
+
+The first way works just as described previously. Under the hood, your process bundle is a zip and it gets unzipped in a directory named bundlename-version. The version number is automatically generated by the engine. So you only need to provide the zip itself and a consistent bundle name.
+
+For the second way, it's a bit more tricky. Because you're directly interacting with the deployment directory, you're allowed to create a bundle directory with any name you like (even not numbered at all). In that case ODE will still create a version number, it just won't be shown on the filesystem. However as it won't be able to find the previous bundle to retire, it will just deploy the new bundle along with all other processes, even if you already had some conflicting deployments. Basically, if you don't number your directories properly, every new deployment will be a new branch. In short, you don't really want to do that.
+
+Another thing you're allowed to do with the file system is simply to replace (or remove and copy) all the files in the deployment bundle directory and remove the .deployed marker file to trigger redeployment. In that case ODE will simply consider you've undeployed and deployed the whole thing. So we get back to the situation where we don't have any versioning. Which can be very useful when you're in development mode because you usually don't care much about the running instances and you usually don't want to pile up versions of process definitions.
Added: ode/site/trunk/content/userguide/wsdl-11-http-binding-support.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/userguide/wsdl-11-http-binding-support.mdtext?rev=1426497&view=auto
==============================================================================
--- ode/site/trunk/content/userguide/wsdl-11-http-binding-support.mdtext (added)
+++ ode/site/trunk/content/userguide/wsdl-11-http-binding-support.mdtext Fri Dec 28 13:13:31 2012
@@ -0,0 +1,11 @@
+Title: WSDL 1.1 HTTP Binding Support
+Since version [1.2](getting-ode.html), ODE supports [HTTP Binding](http://www.w3.org/TR/wsdl#_http). ODE is almost fully compliant with the WSDL 1.1 spec. The few limitations are related to MIME types.
+Actually only the following [MIME types](http://www.iana.org/assignments/media-types/) are supported:
+1. Media types that represent [XML MIME entities](http://www.rfc-editor.org/rfc/rfc3023.txt). Basically any types matching `"text/xml"`, `"application/xml"` and `"\*+xml"`.
+1. Non-XML types will be processed as Text, thus Text Media Types comes de facto but they may have a very limited set of usages.
+
+[mime:multipartRelated](http://www.w3.org/TR/wsdl#_mime:multipartRelated), [mime:soap:body](http://www.w3.org/TR/wsdl#_mime:soap:body) and [mime:mimeXml](http://www.w3.org/TR/wsdl#_mime:mimeXml) are not supported.
+
+Considering how unsuitable WSDL 1.1 HTTP Binding is for a large majority of services -- especially RESTful services -- a set of extensions is available.
+All the details you want to know are [here](wsdl-1.1-extensions-for-rest.html).
+
Modified: ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext?rev=1426497&r1=1426496&r2=1426497&view=diff
==============================================================================
--- ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext (original)
+++ ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext Fri Dec 28 13:13:31 2012
@@ -1,5 +1,5 @@
Title: WS-BPEL 2.0 Specification Compliance
-This page provides information on ODE's compliance to the final [WS-BPEL 2.0](ws-bpel-2.0.html) specification released by OASIS. ODE also implements [a few extensions](bpel-extensions.html) we deemed necessary.
+This page provides information on ODE's compliance to the final [WS-BPEL 2.0](ws-bpel-20.html) specification released by OASIS. ODE also implements [a few extensions](/extensions/) we deemed necessary.
<a name="WS-BPEL2.0SpecificationCompliance-StaticAnalysis"></a>
## Static Analysis
@@ -26,11 +26,11 @@ In this section the divergences from the
### <[receive](receive.html)>
There are several major issues with support for the `<receive>` activity.
-ODE does not yet support the `<fromPart>` syntax. Therefore, the `variable` attribute must be used. Furthermore, only message variables can be referenced with the `variable` attribute, whereas the [specification](ws-bpel-2.0.html) permits referencing of an element-typed variable if the WSDL for the request message contains a single element-typed part.
+ODE does not yet support the `<fromPart>` syntax. Therefore, the `variable` attribute must be used. Furthermore, only message variables can be referenced with the `variable` attribute, whereas the [specification](ws-bpel-20.html) permits referencing of an element-typed variable if the WSDL for the request message contains a single element-typed part.
-Multiple start activities as described in section 10.4, and 15.4 of the [specification](ws-bpel-2.0.html)) are not officially supported. This precludes the use of `initiate="join"`.
+Multiple start activities as described in section 10.4, and 15.4 of the [specification](ws-bpel-20.html)) are not officially supported. This precludes the use of `initiate="join"`.
-ODE does not provide the ordering guarantees described in section 10.4 of the [specification](ws-bpel-2.0.html). Also, it does not enforce the ordering requirements described in the same section. Hence, the BPEL code
+ODE does not provide the ordering guarantees described in section 10.4 of the [specification](ws-bpel-20.html). Also, it does not enforce the ordering requirements described in the same section. Hence, the BPEL code
<flow>
<receive ... createInstance="yes" />
Modified: ode/site/trunk/content/ws-bpel-20.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/ws-bpel-20.mdtext?rev=1426497&r1=1426496&r2=1426497&view=diff
==============================================================================
--- ode/site/trunk/content/ws-bpel-20.mdtext (original)
+++ ode/site/trunk/content/ws-bpel-20.mdtext Fri Dec 28 13:13:31 2012
@@ -15,4 +15,4 @@ The presentation documents are also avai
ODE's support of the specification is outlined on the [WS-BPEL 2.0 Specification Compliance](ws-bpel-2.0-specification-compliance.html) page.
-ODE also supports [a few extensions](bpel-extensions.html) to WS-BPEL in the areas we thought necessary.
+ODE also supports [a few extensions](/extensions/) to WS-BPEL in the areas we thought necessary.
Modified: ode/site/trunk/templates/skeleton.html
URL: http://svn.apache.org/viewvc/ode/site/trunk/templates/skeleton.html?rev=1426497&r1=1426496&r2=1426497&view=diff
==============================================================================
--- ode/site/trunk/templates/skeleton.html (original)
+++ ode/site/trunk/templates/skeleton.html Fri Dec 28 13:13:31 2012
@@ -37,7 +37,7 @@
<li><a href="/userguide/">User Guide</a></li>
<li><a href="/developerguide/">Developer Guide</a></li>
<li><a href="/ws-bpel-20-specification-compliance.html">WS-BPEL Compliance</a></li>
- <li><a href="/bpel-extensions.html">WS-BPEL Extensions</a></li>
+ <li><a href="/extensions/">WS-BPEL Extensions</a></li>
<li><a href="/faq.html">FAQ</a></li>
<li><a href="/roadmap.html">Roadmap</a></li>
<li><a href="/resource-services.html">Resources & Services</a></li>