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/11/12 14:06:58 UTC
svn commit: r1408275 [6/6] - /ode/site/trunk/content/
Added: ode/site/trunk/content/war-deployment.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/war-deployment.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/war-deployment.mdtext (added)
+++ ode/site/trunk/content/war-deployment.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,62 @@
+Title: WAR Deployment
+<a name="WARDeployment-DeployingtheWAR"></a>
+#### Deploying the WAR
+
+Unzip the [distribution](getting-ode.html) somewhere on your disk, everything needed is inside.
+
+Get the WAR file in the distribution root directory, rename it to *ode.war* and copy this file to [Tomcat](http://tomcat.apache.org)'s webapp directory. Start Tomcat and Ode should be up and running. You should get the [Axis2|http://ws.apache.org/axis2] welcome page under [http://localhost:8080/ode]. The Ode WAR includes its own embedded database ([Derby|http://db.apache.org/derby]) so you don't have to worry about configuring any external database for now.
+
+<a name="WARDeployment-Examples"></a>
+#### Examples
+
+Copy the content of the _examples_ directory in the distribution (the 3 sub-directories) to _tomcat/webapps/ode/WEB-INF/processes_, this will automatically deploy the 3 example processes. Use the sendsoap command located in the distribution _bin_ directory to send test messages. The messages to run each of the 3 examples are provided in their respective directory (testRequest.soap). For each example type something like:
+
+
+ bin/sendsoap http://localhost:8080/ode/processes/helloWorld examples/HelloWorld2/testRequest.soap
+
+
+The *sendsoap* executable can be found in the distribution _bin_ directory. The urls should be updated according to the address defined in the WSDL file for the process service.
+
+<a name="WARDeployment-ConfiguringODEinTomcatwithaMySQLdatabase"></a>
+#### Configuring ODE in Tomcat with a MySQL database
+
+The ODE war should have been copied to the _webapps_ directory of Tomcat and the server should have been started at least once before following these instructions. This ensures that the webapp is properly exploded.
+
+1. Drop the MySQL JDBC driver ([MySQL Connector/J](http://dev.mysql.com/downloads/#connector-j)) in the _common/lib_ directory of Tomcat.
+1. Add the following stanza to _conf/server.xml_ inside the <Host> element:
+
+ <Context path="/ode" docBase="ode" debug="5" reloadable="true" crossContext="true">
+ <Resource name="jdbc/ODEDB" auth="Container" type="javax.sql.DataSource"
+ maxActive="100" maxIdle="30" maxWait="10000"
+ username="root" password="" driverClassName="com.mysql.jdbc.Driver"
+ url="jdbc:mysql://localhost:3306/ode?autoReconnect=true"/>
+ </Context>
+
+1. Make sure that MySQL is started and the [ODE schema](^ode_openjpa_mysql-1.3.2.sql.html) has been loaded in a _ode_ database.
+
+ $ mysql -u root
+ mysql> create database ode;
+ mysql> exit
+ $ mysql -u root ode < ode_openjpa_mysql-1.3.2.sql
+
+1. Add a file named _ode-axis2.properties_ under _webapps/ode/WEB-INF/conf_ with the following content:
+
+ ode-axis2.db.mode=EXTERNAL
+ ode-axis2.db.ext.dataSource=java:comp/env/jdbc/ODEDB
+
+
+You're done\!
+
+<a name="WARDeployment-ConfiguringODEinJBosswithJNDIEXTERNALdatasource"></a>
+#### Configuring ODE in JBoss with JNDI EXTERNAL datasource
+
+Create ode/WEB-INF/conf/ode-axis2.properties with following content:
+
+
+ #Uncomment for using dao hibernate
+ #ode-axis2.dao.factory=org.apache.ode.daohib.bpel.BpelDAOConnectionFactoryImpl
+ ode-axis2.db.mode=EXTERNAL
+ ode-axis2.db.ext.dataSource=java:comp/env/jdbc/ode
+ ode-axis2.event.listeners=org.apache.ode.bpel.common.evt.DebugBpelEventListener
+ ode-axis2.tx.factory.class=org.apache.ode.axis2.util.JBossFactory
+
Added: ode/site/trunk/content/writing-bpel-test-cases.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/writing-bpel-test-cases.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/writing-bpel-test-cases.mdtext (added)
+++ ode/site/trunk/content/writing-bpel-test-cases.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,158 @@
+Title: Writing BPEL Test Cases
+ODE has a test framework to automatically run BPEL processes. A big part of our test harness is therefore many different BPEL processes that test specific BPEL configurations or interactions. If you run into a problem with one of your processes that seems to be a bug, the best way to get it fixed is to contribute a test case to the project. We'll run it and keep it to prevent regressions. The more test cases we have, the more robust ODE will be.
+
+This small guide will just explain you how to write and structure a test case to include it in ODE's test suite. For those who rather have examples than explanations, you can already check all [existing test cases](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/).
+
+<a name="WritingBPELTestCases-BPELConstraints"></a>
+### BPEL Constraints
+
+An automated test system has to make some assumptions about your test cases to reduce the complexity of running them. Therefore ODE's test framework can't run absolutely any process. There are a couple of limitations to be aware of:
+
+ * Your process must start with a receive and end with a matching reply. The result produced by the reply is what will be validated.
+ * Invoking external web services during the execution is not possible, test cases must be self-contained as BPEL processes. However we'll see later that a couple of predefined mocked services can be invoked.
+
+Other than that your process can do anything and can use all the WSDL, schemas and XSL stylesheets you need.
+
+<a name="WritingBPELTestCases-TestDescriptor"></a>
+### Test Descriptor
+
+So to begin with your test process must at least have a [BPEL file](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/HelloWorld2/HelloWorld2.bpel), a [WSDL file|http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/HelloWorld2/HelloWorld2.wsdl] and the standard [deploy.xml|http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/HelloWorld2/deploy.xml] deployment descriptor (links are provided for the HelloWorld test case). All of these should be included in a single directory.
+
+Then for the test framework to know what it should do you will also need to write a simple test descriptor. It's a simple properties file saying which service is implemented by the process and which messages should be sent to start it and make it continue. It should me named test?.properties with the '?' being a increasing number. Here is the descriptor for the HelloWorld example, in test1.properties:
+
+
+ namespace=http://ode/bpel/unit-test.wsdl
+ service=HelloService
+ operation=hello
+ request1=<message><TestPart>Hello</TestPart></message>
+ response1=.*Hello World.*
+
+
+The 3 first lines specify the namespace, the name and the operation to which messages will be sent. Then comes the request message. It should always be named request?, and should always be wrapped in a message element and another element named like the message part. Finally, and most importantly, comes the response test pattern. It's a regular expression that will be checked against the response produced by the process. If the expression can't be found, the test fails. In the HelloWorld example here we're just testing that our response includes 'Hello World'.
+
+A test descriptor can contain more that one request/response couple, allowing several executions of a same process, testing different input/output combinations. You just need to increase the numbers in the request and response property names. For an example see the [descriptor of the flow test](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/TestFlowActivity1/test.properties).
+
+Also if your process needs to receive several messages, you can have several test descriptors, each corresponding to a message. The files should just be named test1.properties, test2.properties, ... following the order of invocation. Here is an example with 2 descriptors used by the correlation test case:
+
+
+ test1.properties
+
+ namespace=http://ode/bpel/unit-test/testCorrelation.wsdl
+ service=testCorrelationService
+ operation=request
+ request1=<message><requestMessageData><testMessage><requestID>Start Test5.1</requestID><requestText>Event Start
+ Test5.1</requestText><requestEnd>no</requestEnd></testMessage></requestMessageData></message>
+ response1=ASYNC
+
+ test2.properties
+
+ namespace=http://ode/bpel/unit-test/testCorrelation.wsdl
+ service=testCorrelationService
+ operation=continue
+ request1=<message><requestMessageData><testMessage><requestID>Start Test5.1</requestID><requestText>Event Start
+ Test5.2.1</requestText><requestEnd>yes</requestEnd></testMessage></requestMessageData></message>
+ response1=.*Event Start Test5.1 -> loop on receive until message includes requestEnd = yes -> received
+ message -> process complete.*
+
+
+Finally a response can be marked as being ASYNC in the case no reply is expected for a given receive. This only applies to non instantiating receives:
+
+
+ response1=ASYNC
+
+
+<a name="WritingBPELTestCases-MockedServicesToolkit"></a>
+### Mocked Services Toolkit
+
+Writing isolated BPEL processes isn't something easy and for more advanced test cases you often need a bit more. The test framework therefore includes 2 mocked services to help you: the probe service and the fault service. Be aware however that the usage of these services require a bit more understanding on the BPEL that you're going to execute.
+
+<a name="WritingBPELTestCases-ProbeService"></a>
+#### Probe Service
+
+The probe service makes it easy to track the path that has been taken by a process execution by appending strings that are specific to one execution case. It basically takes a string that you pass and appends it to a global process execution string that you can test in the end. Let's see with a pseudo-code example:
+
+
+ receive(foo)
+ probe("received message " + foo.name)
+ if (foo.value > 50)
+ probe("big value")
+ else
+ probe("small value")
+ end
+ reply(probeStr)
+
+
+Once this has been executed you can check whether the probeStr produced as a reply contains both "received message" and "big value" or "received message" and "small value" using a response regular expression.
+
+Practically the probe service takes 2 parts: probeName and probeData. The probeName part should contain what you wnat to append, the probeData part will contain the appended string after the call and shouldn't be modified once it's been initialized. The probeData part will effectively contain the successive appended strings and that's what you're going to test at the end of the execution.
+
+Here is a usage example extracted from the [correlation test case](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/TestCorrelation/testCorrelation.bpel):
+
+
+ <receive name="receive1" partnerLink="request" portType="wns:testCorrelationPT"
+ operation="request" variable="request" createInstance="yes">
+ <correlations>
+ <correlation set="testCorr1" initiate="yes"/>
+ </correlations>
+ </receive>
+ <!-- Copy input variables to internal accumulators -->
+ <assign name="assign1">
+ <copy>
+ <from variable="request" property="wns:testProbeID"/>
+ <to variable="probeInput" part="probeName"/>
+ </copy>
+ <copy>
+ <from variable="request" property="wns:testProbeData"/>
+ <to variable="probeInput" part="probeData"/>
+ </copy>
+ </assign>
+ <assign>
+ <copy>
+ <from>
+ <literal><![CDATA[loop on receive until message
+ includes requestEnd = yes]]></literal>
+ </from>
+ <to variable="probeInput" part="probeName"/>
+ </copy>
+ </assign>
+ <invoke name="probe" partnerLink="probe" portType="prb:probeMessagePT" operation="probe"
+ inputVariable="probeInput" outputVariable="probeInput"/>
+
+
+The first assign initializes the probe parts with the input message. The second one places in probeName the text that should be appended. After the call to the probe service, probeData will contain both information appended. Then to return the probeData at the end of the execution:
+
+
+ <assign name="assign2">
+ <copy>
+ <from variable="probeInput" part="probeName"/>
+ <to variable="reply" part="replyID"/>
+ </copy>
+ <copy>
+ <from variable="probeInput" part="probeData"/>
+ <to variable="reply" part="replyText"/>
+ </copy>
+ </assign>
+ <reply name="reply" partnerLink="request" portType="wns:testCorrelationPT" operation="continue"
+ variable="reply"/>
+
+
+The returned data is finally tested by using a nice regular expression for the response:
+
+
+ response1=.*Event Start Test5.1 -> loop on receive until message includes requestEnd = yes ->
+ received message -> process complete.*
+
+
+A complete usage example can be found with the [correlation test case](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/TestCorrelation/).
+
+<a name="WritingBPELTestCases-FaultService"></a>
+#### Fault Service
+
+When invoked, the fault service (as the name says) will return a fault. It's mostly used to test fault handlers and compensation. To invoke the fault service just use:
+
+
+ <invoke name="throwTestFault" partnerLink="fault" portType="flt:faultMessagePT" operation="throwFault"
+ inputVariable="fault" outputVariable="faultResponse"/>
+
+
+The only types of fault that can be thrown for now are FaultMessage1, FaultMessage2 and UnknownFault in the http://ode/bpel/unit-test/FaultService.wsdl namespace. For more details see the example in the [implicit fault handler test](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/TestImplicitFaultHandler/).
Added: 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=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext (added)
+++ ode/site/trunk/content/ws-bpel-20-specification-compliance.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,134 @@
+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] we deemed necessary.
+
+<a name="WS-BPEL2.0SpecificationCompliance-StaticAnalysis"></a>
+## Static Analysis
+In this section the divergenced from the specification relating to static analysis requirements are described.
+
+<a name="WS-BPEL2.0SpecificationCompliance-Variables"></a>
+## Variables
+
+<a name="WS-BPEL2.0SpecificationCompliance-Initialization"></a>
+### Initialization
+
+The inline `from-spec` used for variable initialization (BPEL 2.0 Section 8.1) is not supported, however a patch is available (see ODE-236).
+
+<a name="WS-BPEL2.0SpecificationCompliance-ExternalVariables"></a>
+### External Variables
+
+In addition to regular variables that are managed by the engine according to the BPEL specification, Ode adds support for variables whose content is stored externally yet transparently accessible from the engine. See [External Variables](external-variables.html) for more information.
+
+<a name="WS-BPEL2.0SpecificationCompliance-Activities"></a>
+## Activities
+In this section the divergences from the specification for each standard BPEL activity are described.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[receive](receive.html)>`"></a>
+### `<[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.
+
+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"`.
+
+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
+
+ <flow>
+ <receive ... createInstance="yes" />
+ <assign ... />
+ </flow>
+
+is illegal according to the BPEL specification, but allowed by ODE.
+
+The specification defines two standard faults --- `bpel:[conflictingRequest](conflictingrequest.html)` and `bpel:[conflictingReceive]` --- to deal with two similar error conditions relating to multiple outstanding requests on a single partner-link/operation/messageExchange tuple. ODE does not distinguish between these two conditions and `conflictingReceive` is thrown whenever either of the conditions occurs. That is to say, in certain cases a `conflictingReceive` indicates a `conflictingRequest`, and `conflictingRequest` is never thrown.
+
+Finally, the `validate` attribute --- if present --- is ignored: ODE currently provides no variable validation.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[reply](reply.html)>`"></a>
+### `<[reply](reply.html)>`
+The conformance issues with the `<reply>` activity mirror those of the `<receive>` activity as described above: the `<toPart>` syntax is not supported, and `variable` attributes must reference message-typed variables.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[invoke](invoke.html)>`"></a>
+### `<[invoke](invoke.html)>`
+Again, as in the `<receive>>` and `<reply>` activities, the `<toPart>>` and `<fromPart>>` syntax are not supported. Similarly, the `inputVariable` and `outputVariable` attributes must reference message-typed variables. Here too, the `validate` attribute is ignored.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[assign](assign.html)>`"></a>
+### `<[assign](assign.html)>`
+The WS-BPEL 2.0 specification requires the `<[assign](assign.html)>` activity to be atomic. Currently in ODE, each `<copy>` is atomic.
+
+The specification also provides for validating variables at the end of an assignment using the `validate` attribute. ODE does not support this. This means that the `bpel:[invalidVariables](invalidvariables.html)` fault is never thrown by an `<[assign]>` activity.
+
+Inline assignment as part of the variable declaration isn't currently supported.
+
+Ode currently uses the `expressionLanguage` attribute to determine the language used in assignments instead of using the `queryLanguage` attribute.
+
+There are no other known divergences from the specification relating to the `<assign>` activity that would prevent the execution of valid BPEL assignments. ODE provides certain (non-standard) extensions to the `<assign>` activity that do not conform to the specification's requirements for assignment extensions. Consult the [reference page](assign.html) for the `<assign>` activity for further details regarding non-standard extensions.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[throw](throw.html)>`"></a>
+### `<[throw](throw.html)>`
+The `<throw>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[exit](exit.html)>`"></a>
+### `<[exit](exit.html)>`
+The `<exit>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[wait](wait.html)>`"></a>
+### `<[wait](wait.html)>`
+The `<wait>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[empty](empty.html)>`"></a>
+### `<[empty](empty.html)>`
+The `<empty>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[sequence](sequence.html)>`"></a>
+### `<[sequence](sequence.html)>`
+The `<sequence>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[if](if.html)>`"></a>
+### `<[if](if.html)>`
+The `<if>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[while](while.html)>`"></a>
+### `<[while](while.html)>`
+The `<while>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[repeatUntil](repeatuntil.html)>`"></a>
+### `<[repeatUntil](repeatuntil.html)>`
+The `<repeatUntil>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[forEach](foreach.html)>`"></a>
+### `<[forEach](foreach.html)>`
+The `<forEach>` activity is fully compliant with the specification. Ode supports both sequential and parallel for-each semantics.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[pick](pick.html)>`"></a>
+### `<[pick](pick.html)>`
+The `<[pick](pick.html)>` activity has the same issues as the `<[receive]>` activity.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[flow](flow.html)>`"></a>
+### `<[flow](flow.html)>`
+The `<flow>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[scope](scope.html)>`"></a>
+### `<[scope](scope.html)>`
+Isolated scopes are implemented in Ode trunk (as of September 2007) and will be released in Ode 1.2/2.0.
+
+ODE v1.0/1.1 do not support isolated scopes nor do they support "exit on standard fault" semantics. Hence, a BPEL 2.0 process will be interpreted as if any `isolated` and `exitOnStandardFault` attributes on `<scope>` elements did not exist.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[compensate](compensate.html)>`"></a>
+### `<[compensate](compensate.html)>`
+The `<compensate>` activity is not compliant with the specification. In ODE, this activity has the same effect and syntax as `<compensateScope>`. In addition, the `scope` attribute may be used in place of the `target` attribute with the same effect; and ODE expects one of these attributes must be specified.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[compensateScope](compensatescope.html)>`"></a>
+### `<[compensateScope](compensatescope.html)>`
+The `<compensateScope>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[rethrow](rethrow.html)>`"></a>
+### `<[rethrow](rethrow.html)>`
+The `<rethrow>` activity is fully compliant with the specification.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[validate](validate.html)>`"></a>
+### `<[validate](validate.html)>`
+The `<validate>` activity is _not_ implemented by ODE. Processescontaining such activities will cause a compilation failure.
+
+<a name="WS-BPEL2.0SpecificationCompliance-`<[extensionActivity](extensionactivity.html)>`"></a>
+### `<[extensionActivity](extensionactivity.html)>`
+Activity extension is not supported in ODE. There is an implementation in the ODE experimental branch.
Added: ode/site/trunk/content/ws-bpel-20.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/ws-bpel-20.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/ws-bpel-20.mdtext (added)
+++ ode/site/trunk/content/ws-bpel-20.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,18 @@
+Title: WS-BPEL 2.0
+*WS-BPEL 2.0* --- {excerpt}the first official version of the BPEL specification released by the [OASIS](http://www.oasis-open.org) [technical committee|http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel]{excerpt}.
+
+The specification has been finalized and can be found [here](http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html). To learn more about it check the webinars produced by the technical committee:
+
+http://www.oasis-open.org/events/webinars/
+
+The presentation documents are also available:
+
+[Business value part 1](http://www.oasis-open.org/committees/download.php/23070/The%20Business%20Value%20of%20WS-BPEL%20for%20Business%20Analysts%20and%20Managers%20%28Frank%20Leymann%29%20-%20Part%201.pdf)
+[Business value part 2](http://www.oasis-open.org/committees/download.php/23069/The%20Business%20Value%20of%20WS-BPEL%20for%20Business%20Analysts%20and%20Managers%20-%20Part%202%20%28Chris%20Keller%29.pdf)
+[Technical overview part 1](http://www.oasis-open.org/committees/download.php/23068/WS-BPEL%20Technical%20Overview%20for%20Developers%20and%20Architects%20-%20Part%201%20%28Frank%20Ryan%29.pdf)
+[Technical overview part 2](http://www.oasis-open.org/committees/download.php/23067/WS-BPEL%20Technical%20Overview%20for%20Developers%20and%20Architects%20-%20Part%202%20%28Dieter%20Koenig%29.pdf)
+[Technical overview part 3](http://www.oasis-open.org/committees/download.php/23066/WS-BPEL%20Technical%20Overview%20for%20Developers%20and%20Architects%20-%20Part%203%20%28Charlton%20Barreto%29.pdf)
+
+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.
Added: ode/site/trunk/content/ws-i-basic-profile-11.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/ws-i-basic-profile-11.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/ws-i-basic-profile-11.mdtext (added)
+++ ode/site/trunk/content/ws-i-basic-profile-11.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,4 @@
+Title: WS-I Basic Profile 1.1
+
+
+*WS-I Basic Profile 1.1* --- {excerpt}an interoperability [standard](http://www.ws-i.org/Profiles/BasicProfile-1.1.html) that clarifies the use of [SOAP 1.1] and [WSDL 1.1].{excerpt}
Added: ode/site/trunk/content/ws-security-in-ode.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/ws-security-in-ode.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/ws-security-in-ode.mdtext (added)
+++ ode/site/trunk/content/ws-security-in-ode.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,186 @@
+Title: WS-Security in ODE
+<a name="WS-SecurityinODE-HowtouseWS-SecurityinODE?"></a>
+# How to use WS-Security in ODE?
+
+<div class="alert alert-warning"><h4 class="alert-heading">Only in 1.3.2</h4>
+
+ ODE 1.3.2 introduces support for WS-Security: secure services can now be invoked from a process, and the process service itself might be secured. A first part will explain how to invoke a secured service, a second part how to secure the process service.
+
+ ODE has an [Integration Layer based on Axis2|Architectural Overview#ODE Integration Layers] so using Rampart, the Axis2 security modules, goes without saying. As a result this section will only focus on Rampart integration. Rampart and WS-Security specifications won't be detailed here. Please refer to their ad-hoc documentations for further details.
+
+ h2. Quick Rampart introduction
+
+ As any other Axis2 module, Rampart is configurable with [Axis2 Service configuration files|http://ws.apache.org/axis2/1_0/axis2config.html#Service_Configuration]. For instance a service.xml document, using the parameter based configuration model, might be:
+
+ {code:xml}
+ <service>
+
+ <module ref="rampart" />
+
+ <parameter name="OutflowSecurity">
+ <action>
+ <items>Timestamp Signature</items>
+ <user>client</user>
+ <signaturePropFile>TestRampartBasic/secured-services/client.properties</signaturePropFile>
+ <passwordCallbackClass>org.apache.rampart.samples.sample04.PWCBHandler</passwordCallbackClass>
+ <signatureKeyIdentifier>DirectReference</signatureKeyIdentifier>
+ </action>
+ </parameter>
+
+ <parameter name="InflowSecurity">
+ <action>
+ <items>Timestamp Signature</items>
+ <signaturePropFile>TestRampartBasic/secured-services/client.properties</signaturePropFile>
+ </action>
+ </parameter>
+
+ </service>
+ {code}
+
+ Another example using WS-Security Policy based configuration model is listed below. See the full document [here|http://svn.apache.org/viewvc/ode/branches/APACHE_ODE_1.X/axis2-war/src/test/resources/TestRampartPolicy/secured-services/process-sample04_policy_in_service.xml/sample04-policy.axis2?view=markup].
+ {code:xml}
+ <service>
+
+ <module ref="rampart"/>
+
+ <wsp:Policy wsu:Id="SecConvPolicy2" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
+ <wsp:ExactlyOne>
+ <wsp:All>
+ <sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
+ <wsp:Policy>
+ <!-- truncated, see original document ny following the link above -->
+ </wsp:Policy>
+ </sp:SymmetricBinding>
+ <sp:Wss11 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
+ <wsp:Policy>
+ <!-- truncated, see original document ny following the link above -->
+ </wsp:Policy>
+ </sp:Wss11>
+ <sp:Trust10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
+ <wsp:Policy>
+ <!-- truncated, see original document ny following the link above -->
+ </wsp:Policy>
+ </sp:Trust10>
+ <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
+ <sp:Body/>
+ </sp:EncryptedParts>
+ <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
+ <ramp:user>client</ramp:user>
+ <ramp:encryptionUser>service</ramp:encryptionUser>
+ <ramp:passwordCallbackClass>org.apache.rampart.samples.policy.sample04.PWCBHandler</ramp:passwordCallbackClass>
+
+ <ramp:signatureCrypto>
+ <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin">
+ <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type">JKS</ramp:property>
+ <ramp:property name="org.apache.ws.security.crypto.merlin.file">TestRampartPolicy/secured-services/client.jks</ramp:property>
+ <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password">apache</ramp:property>
+ </ramp:crypto>
+ </ramp:signatureCrypto>
+ <ramp:encryptionCypto>
+ <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin">
+ <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type">JKS</ramp:property>
+ <ramp:property name="org.apache.ws.security.crypto.merlin.file">TestRampartPolicy/secured-services/client.jks</ramp:property>
+ <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password">apache</ramp:property>
+ </ramp:crypto>
+ </ramp:encryptionCypto>
+
+ </ramp:RampartConfig>
+ </wsp:All>
+ </wsp:ExactlyOne>
+ </wsp:Policy>
+
+ </service>
+ {code}
+
+
+ The important thing to notice is that these documents are plain [Axis2 Service configuration files|http://ws.apache.org/axis2/1_0/axis2config.html#Service_Configuration]. And as explained in the [ODE User Guide|Endpoint Configuration#Additional Configuration for SOAP Endpoints], a mechanism to handle these files already exists. So all we have to do is reuse this mechanism, the rest is pure Rampart configuration.
+
+ Let's take an example and see the actual required steps.
+
+ h2. How to invoke a secure web service?
+
+ h3. Prepare your service document
+ Assuming your process needs to invoke the secure service \{http://sample03.policy.samples.rampart.apache.org}Sample03, the _first step_ is to prepare a service document named $\{process_bundle_dir}/Sample03.axis2 and containing your desired Rampart configuration.
+ The _second step_ is to to make sure the resources needed to invoke the services are available to Rampart through ODE webapp classpath. Typical resources are :
+ * password callback handler classes
+ * Java keystores
+ * property files containing keystore information
+
+ h3. Add resources to ODE webapp classpath
+ How you add these resources to ODE classpath might vary depending on your application server, your global architecture or other criteria. So it's up to you to figure this out. However typical locations are:
+ * ode/WEB-INF/classes
+ * ode/WEB-INF/lib
+
+ h3. An alternative for WS-Security Policies
+ If you're using the policy base configuration model, an alternative is available to you: use the [endpoint property mechanism|Endpoint Configuration] to attach the policy to the service. In that configuration, ODE will engage the Rampart module and load the policy when the service is invoked.
+ To do so:
+ # save the Policy document (not the service document) in the file of your choice. For instance mypolicy.xml
+ # create an endpoint file linking the service and the policy file. Basically with the two properties listed below. Note that if the path assigned to the "security.policy.file" property is relative it will be resolved against the process bundle directory. Of course if the path is absolute, it will be used as is.
+
+ {code}
+ alias.sample03-ns=http://sample03.policy.samples.rampart.apache.org
+ sample03-ns.sample03-policy.ode.security.policy.file=mypolicy.xml
+ {code}
+
+ h2. How to secure the web service exposed by a process?
+
+ Applying security to a process service is no different from invoking a secured service. If the process service you're exposing is \{http://mycompany.com}AbscenceRequest. All you have to do is prepare a service document named $\{process_bundle_dir}/AbscenceRequest.axis2 and containing your Rampart configuration. Once again, it's up to you to add the required resources in ODE webapp classpath.
+
+ You can also use the property 'security.policy.file' to secure the process service.
+
+ h2. Do I need to install Rampart myself?
+
+ No. ODE comes with the following Axis2 modules (and the jars they depend on): Rampart, Rahas and Addressing.
+
+ h2. Useful resources
+
+ h3. Rampart material
+ * the [list|http://wso2.org/projects/rampart/java] of Web Services Security specifications supported by Rampart
+ * [Rampart articles|http://ws.apache.org/rampart/articles.html]
+ * [Rampart samples|http://ws.apache.org/rampart/samples.html]
+ * [a Rampart tutorial|https://wiki.internet2.edu/confluence/display/GrouperWG/The+Newcastle+University+Grouper+page]
+
+ h3. ODE test cases
+
+ h4. How to run them
+
+ {code}
+ $ cd axis2-war
+ $ buildr test:Secure
+ {code}
+
+ h4. Where are the processes executed by the unit tests?
+
+ The executed processes are generated by the build, so run the tests once, then look into the following directories. Process directories are prefixed with "process-".
+ * axis2-war/target/test-classes/TestRampartPolicy/secured-services/
+ * axis2-war/target/test-classes/TestRampartPolicy/secured-processes/
+ * axis2-war/target/test-classes/TestRampartBasic/secured-services/
+ * axis2-war/target/test-classes/TestRampartBasic/secured-processes/
+
+ h4. the nitty-gritty details
+
+ The integration with Rampart described in this section is tested with a decent suite of unit tests. These unit tests are based on the [Rampart samples|http://ws.apache.org/rampart/samples.html]. The [related resources|http://svn.apache.org/repos/asf/webservices/rampart/branches/java/1_3/modules/rampart-samples/] were imported into ODE repository.
+ These tests are divided into two parts: tests using the parameter base configuration model aka "basic tests" and tests using the policy base configuration model aka "policy tests".
+ ODE test cases reuse these test cases in two different scenarii:
+ # the security configuration is applied to an "external" web service, and a ODE process invokes it.
+ # the security configuration is applied to the web service exposed by a process.
+
+ These partitions lead to four resource directories:
+ * [TestRampartBasic/secured-services|http://svn.apache.org/viewvc/ode/branches/APACHE_ODE_1.X/axis2-war/src/test/resources/TestRampartBasic/secured-services/]
+ * [TestRampartBasic/secured-processes|http://svn.apache.org/viewvc/ode/branches/APACHE_ODE_1.X/axis2-war/src/test/resources/TestRampartBasic/secured-processes/]
+
+ * [TestRampartPolicy/secured-services|http://svn.apache.org/viewvc/ode/branches/APACHE_ODE_1.X/axis2-war/src/test/resources/TestRampartPolicy/secured-services/]
+ * [TestRampartPolicy/secured-processes|http://svn.apache.org/viewvc/ode/branches/APACHE_ODE_1.X/axis2-war/src/test/resources/TestRampartPolicy/secured-processes/]
+
+ Everything describes for TestRampartBasic applies to TestRampartPolicy. So for now on we will mention only TestRampartBasic.
+
+ For the "secured-services" scenario, the "external" web services are Axis [archives|http://svn.apache.org/viewvc/ode/branches/APACHE_ODE_1.X/axis2-war/src/test/resources/TestRampartBasic/secured-services/services/] deployed in an Axis2 webapp.
+
+ The corresponding unit test classes are [SecuredServicesTest.java and SecuredProcessTest.java|http://svn.apache.org/viewvc/ode/branches/APACHE_ODE_1.X/axis2-war/src/test/java/org/apache/ode/axis2/rampart/basic/]. Each test class will start a list of processes that must succeed (as many processes as Rampart samples actually).
+ To avoid duplication these processes are generated by the build based on two process templates: [one|http://svn.apache.org/viewvc/ode/branches/APACHE_ODE_1.X/axis2-war/src/test/resources/TestRampartBasic/secured-services/process-template/] for the secured-services case, [another|http://svn.apache.org/viewvc/ode/branches/APACHE_ODE_1.X/axis2-war/src/test/resources/TestRampartBasic/secured-processes/process-template/] for the secured-processes case.
+
+ The build generates processes into:
+ * axis2-war/target/test-classes/TestRampartPolicy/secured-services/process-*
+ * axis2-war/target/test-classes/TestRampartPolicy/secured-processes/process-*
+ * axis2-war/target/test-classes/TestRampartBasic/secured-services/process-*
+ * axis2-war/target/test-classes/TestRampartBasic/secured-processes/process-*
Added: ode/site/trunk/content/wsdl-11-extensions-for-rest.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/wsdl-11-extensions-for-rest.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/wsdl-11-extensions-for-rest.mdtext (added)
+++ ode/site/trunk/content/wsdl-11-extensions-for-rest.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,257 @@
+Title: WSDL 1.1 Extensions for REST
+The [Resource-Oriented Architecture](http://en.wikipedia.org/wiki/Representational_State_Transfer) defines four concepts:
+1. Resources
+1. Their names (URIs)
+1. Their representations
+1. The link bet ween them
+
+and four properties:
+1. Addressability
+1. Statelesness
+1. Connectedness
+1. A uniform interface
+
+HTTP binding as defined in WSDL 1.1 is not well suitable to describe services implementing these concepts and properties, mainly because a port type may access 4 different locations/resources but with only one HTTP method.
+
+To better describe RESTful services, and turn a port type into a "resource type", ODE brings a set of 4 extensions:
+1. one HTTP method per operation (instead of one per binding)
+1. a unique URI Template for all operations
+1. access to HTTP headers
+1. fault support
+
+Further details below.
+
+In this page, we use an imaginary blog service as a use case to illustrate and make things more palpable. We will focus on the resources defined by the following URI template: {noformat}http://blog.org/post/{id}{noformat}
+Let's assume that such a resource accept four operations:
+* GET to retrieve a post
+* DELETE to delete it
+* PUT to update the post
+* POST to add a comment to a post
+
+<div class="alert alert-info"><h4 class="alert-heading">Check out unit tests!</h4>
+
+ h3. One verb per operation
+
+ According to the WSDL 1.1 specification, the verb describing the HTTP method has to be at [the binding level|http://www.w3.org/TR/wsdl#A4.3]. Which implies that the same HTTP method is used by all operations of a given port type. But RESTful web services leverage HTTP methods as a uniform interface to describe operation on resources. So for instance, if you want to use the following HTTP operations -- GET, POST, PUT, DELETE -- for a given resource, four different bindings would be required. And consequently four port types and four ports. Quite verbose and unusable, isn't it?
+
+ So, this extension is to push down the HTTP verb at the operation level. And if an operation does not have its own verb, then the verb defined at the binding level will be used.
+ This extension is declared in the namespace: {{http://www.apache.org/ode/type/extension/http}}
+
+ Please note that ODE supports GET, POST, PUT, DELETE only.
+ {code:xml}
+ <definitions ...
+ xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
+
+ <!-- many wsdl elements are ommited to highlight the interesting part -->
+
+ <binding name="blogBinding" type="blogPortType">
+ <operation name="GET">
+ <odex:binding verb="GET" />
+ </operation>
+ <operation name="DELETE">
+ <odex:binding verb="DELETE"/>
+ </operation>
+ </binding>
+ </definitions>
+ {code}
+
+
+
+ h3. URI Template
+
+ A RESTful service exposed a set of resources, each of them being accessible through a uniform interface: HTTP methods for a web service. So we need a way to define four operations (at most) for a single resource.
+
+ Moreover it's very likely that the resource URI actually describes a set of resources. For instance, the set of posts contained in our imaginary blog: {{http://blog.org/post/\{post_id\}}}.
+
+ HTTP binding offers the [http:operation | http://www.w3.org/TR/wsdl#_http:operation] element to set the path of an operation. While the service address is set in the [http:address|http://www.w3.org/TR/wsdl#_http:address] of the [wsdl:port|http://www.w3.org/TR/wsdl#_ports] element.
+ So one could imagine splitting the URL this way:
+
+ {code:xml}
+ <definitions ...
+ xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
+
+ <service name="blogService">
+ <port name="blogPort" binding="blogPortType">
+ <http:address location="http://blog.org"/>
+ </port>
+ </service>
+
+ <binding name="blogBinding" type="blogPortType">
+ <operation name="PUT">
+ <odex:binding verb="PUT" />
+ <http:operation location="post/(post_id)"/>
+ <input>
+ <http:urlReplacement/>
+ </input>
+ <output/>
+ </operation>
+ </binding>
+ </definitions>
+ {code}
+
+ However, here 3 issues show up:
+ # the location is not accessible from the End Point Reference. _=> ODE cannot process it before invoking the external service._
+ # [http:urlReplacement|http://www.w3.org/TR/wsdl#_http:urlReplacement] is only accepted for GET _=> what about the uniform interface?!_
+ # http:urlReplacement requires all parts of the operation input message to be mentioned in the operation location. Meaning that:
+ #* => the resource id (in the present example) must be a part of the message.
+ #* => no parts may be stored in the HTTP body. this conflicts with a PUT operation for instance. With a PUT you would like to set the id in the url and the resource data in the HTTP request body.
+
+ To solve this, ODE allows [http:operation | http://www.w3.org/TR/wsdl#_http:operation] elements to be omitted or empty, and the full resource URI to be set in a single place, the http:address element.
+
+ {note:Curly Brackets}Please note that curly brackets '\{\}' are the preferred argument delimiters in URI templates. So that URLs can be dynamically composed using [compose-url, combine-url and expand-template XPath Functions|RESTful BPEL, Part I#XPath functions].{note}
+
+ In addition, the http:urlReplacement is relaxed: all parts are *not* required in the URI template anymore. One part could go in the URI, another in the request body.
+
+ {code:xml}
+ <definitions ...
+ xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
+
+ <service name="blogService">
+ <port name="blogPort" binding="blogPortType">
+ <!-- here is the full URI template, using curly brackets -->
+ <http:address location="http://blog.org/post/{post_id}"/>
+ </port>
+ </service>
+
+ <binding name="blogBinding" type="blogPortType">
+ <operation name="PUT">
+ <odex:binding verb="PUT" />
+ <!-- location attribute intentionally blank -->
+ <http:operation location=""/>
+ <input>
+ <http:urlReplacement/>
+ <!-- an additional part can be mapped to the request body even if urlReplacement is used-->
+ <mime:content type="text/xml" part="post_content"/>
+ </input>
+ <output/>
+ </operation>
+ </binding>
+ </definitions>
+ {code}
+
+
+ h3. HTTP Headers manipulation
+
+ HHTP protocal convey a lot of information in Request/Response Headers. Caching information, Content description for instance. All this data is completely left out by WSDL 1.1 HTTP Binding. To fix this, ODE provides a header element. This element can be used to insert a part or a static value into a given HTTP request header (standard or custom). And the way around, a HTTP request header into a part. Also note that all HTTP response headers are inserted into the message headers, and thus are available from the BPEL process.
+
+ {code:xml}
+ <definitions ...
+ xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
+
+ <binding name="blogBinding" type="blogPortType">
+ <operation name="PUT">
+ <odex:binding verb="PUT" />
+ <http:operation location=""/>
+ <input>
+ <http:urlReplacement/>
+ <mime:content type="text/xml" part="post_content"/>
+ <!-- set a standard request header from a part -->
+ <odex:header name="Authorization" part="credentials_part"/>
+ <!-- set a custom request header with a static value -->
+ <odex:header name="MyCustomHeader" value="ode@apache.org" />
+ </input>
+ <output>
+ <mime:content type="text/xml" part="post_content"/>
+ <!-- set 1 response header to a part -->
+ <odex:header name="Age" part="age_part"/>
+ </output>
+ </operation>
+ </binding>
+ </definitions>
+ {code}
+
+ For every HTTP response, in addition to HTTP response headers, the [Status-Line|http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1] is passed as a message header. To save some painful XPath string manipulations, the Status-line is already parsed into the following structure:
+ {code:xml}
+ <Status-Line>
+ <HTTP-Version>HTTP/1.1</HTTP-Version>
+ <Status-Code>200</Status-Code>
+ <Reason-Phrase>OK</Reason-Phrase>
+ <!-- the original unaltered Status-Line -->
+ <original>HTTP/1.1 200 OK</original>
+ </Status-Line>
+ {code}
+
+ So that you can write the following BPEL lines:
+ {code:xml}
+ <assign>
+ <copy>
+ <from variable="postMsg" header="Status-Line"/>
+ <to>$statusLine</to>
+ </copy>
+ </assign>
+ <if>
+ <condition>number($statusLine/Status-Code) > 200 and number($statusLine/Status-Code) < 300</condition>
+ <assign>
+ <copy>
+ <from>'Request successful!!!'</from>
+ <to>$outputVar.TestPart</to>
+ </copy>
+ </assign>
+ </if>
+ {code}
+
+ h3. Fault Support
+
+ Another domain completely neglected by WSDL 1.1 HTTP Binding is Fault management. The word is not even mentioned in the [HTTP Binding section|http://www.w3.org/TR/wsdl#_http].
+ ODE allows you to bind a fault with HTTP Binding. If a [4xx or a 5xx|http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4] is returned, the following logic is applied:
+
+ A failure is thrown if the code is one of these:
+ || Status-Codes triggering a Failure ||
+ | 3xx Redirections |
+ |401_UNAUTHORIZED|
+ |408_REQUEST_TIMEOUT|
+ |503_SERVICE_UNAVAILABLE|
+ |504_GATEWAY_TIMEOUT|
+
+ {info:title=Useful Information}Note that 3xx errors should be pretty rare since by default the first hundred redirections are followed. You can tweak this value by setting the property {{http.protocol.max-redirects}} in the [enpoint-configuration.properties|Endpoint Configuration] of your process.{info}
+
+ Here what ODE does, if the status code is one of those listed in the next table (500, 501, etc):
+ # check that the operation has at least one fault in its abstract part, and one fault binding
+ # check that the Content-type header describes an xml document ('application/xml', 'application/atom+xml' etc)
+ # check that the body is not empty
+
+ If so far everything is fine, the HTTP response body is parsed into an xml document. Then the fault to be thrown is inferred from the qname of the response root element, i.e the fault having a message part matching the root element. This matching process is exactly the same as for a SOAP service.
+ If one of these steps fails, a failure is thrown.
+
+ || Status-Codes that may trigger a Fault ||if the body element matches a fault declaration||
+ |500_INTERNAL_SERVER_ERROR | 407_PROXY_AUTHENTICATION_REQUIRED |
+ |501_NOT_IMPLEMENTED | 409_CONFLICT |
+ |502_BAD_GATEWAY | 410_GONE |
+ |505_HTTP_VERSION_NOT_SUPPORTED | 412_PRECONDITION_FAILED |
+ |400_BAD_REQUEST | 413_REQUEST_TOO_LONG |
+ |402_PAYMENT_REQUIRED | 414_REQUEST_URI_TOO_LONG |
+ |403_FORBIDDEN | 415_UNSUPPORTED_MEDIA_TYPE |
+ |404_NOT_FOUND | 411_LENGTH_REQUIRED |
+ |405_METHOD_NOT_ALLOWED | 416_REQUESTED_RANGE_NOT_SATISFIABLE |
+ |406_NOT_ACCEPTABLE | 417_EXPECTATION_FAILED |
+
+ Note that you can't bind a given fault to a specific status code.
+
+ {code:xml}
+ <definitions ...
+ xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
+
+ <portType name="BlogPortType">
+ <operation name="PUT">
+ <input message="..."/>
+ <output message="..."/>
+ <fault name="UpdateFault" message="tns:UpdateFault"/>
+ </operation>
+ </portType>
+
+ <binding name="blogBinding" type="blogPortType">
+ <operation name="PUT">
+ <odex:binding verb="PUT" />
+ <http:operation location=""/>
+ <input> ... </input>
+ <output> ... </output>
+ <!-- fault binding -->
+ <fault name="UpdateException">
+ <!-- name attribute is optional if there is only one fault for this operation -->
+ <!-- <odex:fault name="UpdateFault"/> -->
+ <odex:fault/>
+ </fault>
+ </operation>
+ </binding>
+ </definitions>
+ {code}
Added: ode/site/trunk/content/wsdl-11-http-binding-support.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/wsdl-11-http-binding-support.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/wsdl-11-http-binding-support.mdtext (added)
+++ ode/site/trunk/content/wsdl-11-http-binding-support.mdtext Mon Nov 12 13:06:43 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).
+
Added: ode/site/trunk/content/wsdl-11.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/wsdl-11.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/wsdl-11.mdtext (added)
+++ ode/site/trunk/content/wsdl-11.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,4 @@
+Title: WSDL 1.1
+
+
+*WSDL 1.1* --- {excerpt}version 1.1 of the Web Services Description Language [specification](http://www.w3.org/TR/wsdl) from the [W3C|http://www.w3c.org]{excerpt}. Following the [WS-I Basic Profile 1.1], PXE uses the WSDL schema located at [http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd].
Added: ode/site/trunk/content/xpath-10-expression-language.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/xpath-10-expression-language.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/xpath-10-expression-language.mdtext (added)
+++ ode/site/trunk/content/xpath-10-expression-language.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1 @@
+Title: XPath 1.0 Expression Language
Added: ode/site/trunk/content/xpath-20-expression-language.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/xpath-20-expression-language.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/xpath-20-expression-language.mdtext (added)
+++ ode/site/trunk/content/xpath-20-expression-language.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1 @@
+Title: XPath 2.0 Expression Language
Added: ode/site/trunk/content/xpath-extensions.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/xpath-extensions.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/xpath-extensions.mdtext (added)
+++ ode/site/trunk/content/xpath-extensions.mdtext Mon Nov 12 13:06:43 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/xquery-extensions.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/xquery-extensions.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/xquery-extensions.mdtext (added)
+++ ode/site/trunk/content/xquery-extensions.mdtext Mon Nov 12 13:06:43 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.