Author: vanto
Date: Fri Dec 28 12:30:54 2012
New Revision: 1426477

URL: http://svn.apache.org/viewvc?rev=1426477&view=rev
Log:
clean up

Removed:
    ode/site/trunk/content/ant-tasks.mdtext
    ode/site/trunk/content/bpelc-task.mdtext
    ode/site/trunk/content/commandline-tools.mdtext
    ode/site/trunk/content/ddvalidate-command.mdtext
    ode/site/trunk/content/port.mdtext
    ode/site/trunk/content/pxe-activate-command.mdtext
    ode/site/trunk/content/pxe-deactivate-command.mdtext
    ode/site/trunk/content/pxe-deploy-command.mdtext
    ode/site/trunk/content/pxe-sar-task.mdtext
    ode/site/trunk/content/pxe-status-command.mdtext
    ode/site/trunk/content/pxe-undeploy-command.mdtext
    ode/site/trunk/content/rradd-command.mdtext
    ode/site/trunk/content/rralias-command.mdtext
    ode/site/trunk/content/rrdrop-command.mdtext
    ode/site/trunk/content/rrget-command.mdtext
    ode/site/trunk/content/rrls-command.mdtext
    ode/site/trunk/content/sarcreate-command.mdtext
    ode/site/trunk/content/sarls-command.mdtext
    ode/site/trunk/content/urlalias-command.mdtext
    ode/site/trunk/content/version-command.mdtext
Modified:
    ode/site/trunk/content/faq.mdtext
    ode/site/trunk/content/restful-bpel-part-i.mdtext
    ode/site/trunk/content/wsdl-11-extensions-for-rest.mdtext

Modified: ode/site/trunk/content/faq.mdtext
URL: 
http://svn.apache.org/viewvc/ode/site/trunk/content/faq.mdtext?rev=1426477&r1=1426476&r2=1426477&view=diff
==============================================================================
--- ode/site/trunk/content/faq.mdtext (original)
+++ ode/site/trunk/content/faq.mdtext Fri Dec 28 12:30:54 2012
@@ -10,7 +10,7 @@ __Q.__ _What is ODE?_
 __A.__ ODE is a system for executing reliable long-running process described 
using the WS-BPEL 2.0 standard and the BPEL4WS 1.1 vendor specification.
 
 __Q.__ _What is the architecture of ODE?_
-__A.__ The architecture of ODE is described in the ODE [Architectural Overview]
+__A.__ The architecture of ODE is described in the ODE [Architectural 
Overview](architectural-overview.html)
 
 
 __Q.__ _In what language is ODE written?_
@@ -30,7 +30,7 @@ __Q.__ _Is the entire_ _[WS-BPEL 2.0](ws
 __A.__ Most WS-BPEL 2.0 language features (and all important features) are 
supported. For specifics see the [WS-BPEL 2.0 Specification 
Compliance](ws-bpel-20-specification-compliance.html) page.
 
 __Q.__ _Does ODE use native Java language constructs to execute BPEL, e.g., 
multiple threads for a_ _```<bpel:flow>```_ _or a_ ```while (...) {...}``` _for 
a_ ```<bpel:while>```?
-__A.__ No. ODE's BPEL implementation does not map the BPEL process into Java. 
Instead, it relies on a transactional concurrency framework 
[JaCOb](/developerguide/jacob.html) similar to the theoretical concurrency 
model known as ACTORS [Agha86].
+__A.__ No. ODE's BPEL implementation does not map the BPEL process into Java. 
Instead, it relies on a transactional concurrency framework 
[JaCOb](/developerguide/jacob.html) similar to the theoretical concurrency 
model known as ACTORS [Agha86](agha86.html).
 
 __Q.__ _Does ODE support BPEL processes developed in third-party tools?_
 __A.__ Yes. Well-formed BPEL from any source should work.
@@ -82,7 +82,7 @@ __Q.__ _Does ODE require a database? Whi
 __A.__ ODE does not depend directly on any specific database or persistence 
mechanism. Instead, ODE relies on a set of data access object ("DAO") 
interfaces that encapsulate the behaviors of a persistence layer. The ODE 
distribution includes a DAO implementation for JDBC databases built using 
[OpenJPA](http://openjpa.apache.org). This DAO implementation can support most 
common relational databases. Schemas suitable for [MySQL](http://www.mysql.com) 
and [Derby](http://db.apache.org/derby/) are provided. Relational databases 
lacking transaction or binary large object ("BLOB") capabilities are not 
supported. The DAO interfaces can readily be implemented to support alternative 
persistence mechanisms (e.g. JDO), XML datastores, or direct filesystem-based 
persistence.
 
 __Q.__ _Does ODE require a J2EE application server?_
-__A.__ The core ODE components do not require a J2EE application server. ODE 
relies on a [Integration 
API](http://svn.apache.org/repos/asf/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/)
 that allows ODE to be embedded in most any environment that can supply the 
required facilities. An [AXIS2 Integration] is provided that permits ODE to be 
installed on a J2EE application server, or in a "dumb" Servlet container via a 
WAR file. A [JBI Integration] integration is also provided that permits ODE to 
be installed in a JBI container.
+__A.__ The core ODE components do not require a J2EE application server. ODE 
relies on a [Integration 
API](http://svn.apache.org/repos/asf/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/)
 that allows ODE to be embedded in most any environment that can supply the 
required facilities. An [AXIS2 
Integration](architectural-overview.html#ODEIntegrationLayers) is provided that 
permits ODE to be installed on a J2EE application server, or in a "dumb" 
Servlet container via a WAR file. A [JBI 
Integration](architectural-overview.html#ODEIntegrationLayers) integration is 
also provided that permits ODE to be installed in a JBI container.
 
 __Q.__ _Is there a stand-alone ODE integration?_
 __A.__ No, the standard ODE distributions require either an application 
server, Servlet container, or JBI container.
@@ -104,20 +104,20 @@ __A.__ We try to use sensible sizes for 
 This section covers frequently asked questions related to integrating ODE into 
third-party products or integrating third-party products into ODE.
 
 __Q.__ _Can ODE interact directly (i.e., not over the network) with native 
Java services?_
-__A.__ This is currently supported in the [JBI Integration] via standard JBI 
mechanisms. It is currently not supported in the [AXIS2 Integration] but will 
be in the future.
+__A.__ This is currently supported in the [JBI 
Integration](architectural-overview.html#ODEIntegrationLayers) via standard JBI 
mechanisms. It is currently not supported in the [AXIS2 
Integration](architectural-overview.html#ODEIntegrationLayers) but will be in 
the future.
 
 __Q.__ _Can ODE integrate with Middleware X? Can ODE integrate with Legacy 
system Y? Can ODE integrate with Enterprise Application Z? How is this 
accomplished?_
 __A.__ The generic answer is "Yes," although it requires some work on the part 
of the integrator. The primary extension point for integrating with external 
systems is the [Integration 
API](http://ode.apache.org/javadoc/org/apache/ode/bpel/pmapi/ProcessManagement.html),
 which can be used to embed ODE in most any environment.
 
 __Q.__ _Does ODE rely on any third-party or open source libraries?_
-__A.__ ODE uses a number of liberally-licensed (i.e., non-GPL) open source 
libraries, some integral and some not. These are enumerated in the 
[reference|Required Third-Party Libraries].
+__A.__ ODE uses a number of liberally-licensed (i.e., non-GPL) open source 
libraries, some integral and some not. These are enumerated in the 
[reference](required-third-party-libraries.html).
 
 ## ODE and Web Services
 
 This section covers frequently asked questions about how ODE related to 
various web services specifications and initiatives.
 
 __Q.__ _Does ODE supply a SOAP stack?_
-__A.__ Not directly. ODE relies on the [Integration Layer|Architectural 
Overview#ODEIntegrationLayers] to supply the "physical" communication 
mechanisms. The [AXIS2 Integration Layer|Architectural 
Overview#ODEIntegrationLayers] that is part of the ODE distribution uses the 
AXIS2 SOAP stack. The [JBI Integration Layer|Architectural 
Overview#ODEIntegrationLayers] relies on external HTTP/SOAP components (e.g. 
ServiceMix's `servicemix-http` component).
+__A.__ Not directly. ODE relies on the [Integration 
Layer](architectural-overview.html#ODEIntegrationLayers) to supply the 
"physical" communication mechanisms. The [AXIS2 Integration 
Layer](architectural-overview.html#ODEIntegrationLayers) that is part of the 
ODE distribution uses the AXIS2 SOAP stack. The [JBI Integration 
Layer](architectural-overview.html#ODEIntegrationLayers) relies on external 
HTTP/SOAP components (e.g. ServiceMix's `servicemix-http` component).
 
 __Q.__ _Can ODE be integrated with third-party web services products such as 
Apache AXIS, Systinet WASP, or JAXRPC?_
 __A.__ Yes, ODE can be integrated into most any stack via the [Integration 
API](http://incubator.apache.org/ode/javadoc/bpel-api/index.html)
@@ -128,7 +128,7 @@ __Q.__ _Does ODE support web services tr
 __A.__ No, not at present.
 
 __Q.__ _Does ODE support WS-Addressing?_
-__A.__ ODE does not directly support WS-Addressing. However, the BPEL 
implementation and the core ODE infrastructure provides support for opaque 
end-point references. This allows ODE to be integrated with arbitrary 
addressing standards. The [AXIS2 Integration Layer] for ODE employs this 
mechanism to support WS-Addressing.
+__A.__ ODE does not directly support WS-Addressing. However, the BPEL 
implementation and the core ODE infrastructure provides support for opaque 
end-point references. This allows ODE to be integrated with arbitrary 
addressing standards. The [AXIS2 Integration 
Layer](architectural-overview.html#ODEIntegrationLayers) for ODE employs this 
mechanism to support WS-Addressing.
 
 ## Reliability
 

Modified: ode/site/trunk/content/restful-bpel-part-i.mdtext
URL: 
http://svn.apache.org/viewvc/ode/site/trunk/content/restful-bpel-part-i.mdtext?rev=1426477&r1=1426476&r2=1426477&view=diff
==============================================================================
--- ode/site/trunk/content/restful-bpel-part-i.mdtext (original)
+++ ode/site/trunk/content/restful-bpel-part-i.mdtext Fri Dec 28 12:30:54 2012
@@ -32,4 +32,4 @@ And to update the post:
 <a name="RESTfulBPEL,PartI-XPathfunctions"></a>
 ### XPath functions
 
-The use or URLs requires the ability to combine URLs with two new XPath 
functions: combine-url(base, relative) and compose-url(template, \[name, 
value\](name,-value\.html)*) / compose-url(template, pairs). See [xpath 
extensions|xpath extensions#combineurl(base,relative)] for details.
+The use or URLs requires the ability to combine URLs with two new XPath 
functions: combine-url(base, relative) and compose-url(template, \[name, 
value\](name,-value\.html)*) / compose-url(template, pairs). See [xpath 
extensions](xpath extensions#combineurl(base,relative)) for details.

Modified: 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=1426477&r1=1426476&r2=1426477&view=diff
==============================================================================
--- ode/site/trunk/content/wsdl-11-extensions-for-rest.mdtext (original)
+++ ode/site/trunk/content/wsdl-11-extensions-for-rest.mdtext Fri Dec 28 
12:30:54 2012
@@ -1,11 +1,14 @@
 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
@@ -14,6 +17,7 @@ and four properties:
 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
@@ -21,24 +25,27 @@ To better describe RESTful services, and
 
 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} 
+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: `http://blog.org/post/{id}` 
+
 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}
+<div class="alert alert-info"><h4 class="alert-heading">Check out unit 
tests!</h4></div>
+
+### 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.
+
+    :::xml
     <definitions ...
                       
xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
     
@@ -53,20 +60,17 @@ Let's assume that such a resource accept
             </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}
+
+### 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: 
+
+    :::xml
     <definitions ...
                       
xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
     
@@ -87,22 +91,23 @@ Let's assume that such a resource accept
             </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}
+
+
+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. 
+
+<div class="alert alert-info">Please note that curly brackets '{}' are the 
preferred argument delimiters in URI templates. So that URLs can be dynamically 
composed using <a href="restful-bpel-part-i.html#XPath functions">compose-url, 
combine-url and expand-template XPath Functions</a>.</div>
+
+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.
+
+    :::xml
     <definitions ...
                       
xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
     
@@ -127,14 +132,12 @@ Let's assume that such a resource accept
             </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}
+
+### HTTP Headers manipulation
+
+HTTP 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.
+
+    :::xml
     <definitions ...
                       
xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
     
@@ -158,10 +161,10 @@ Let's assume that such a resource accept
             </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}
+
+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:
+
+    :::xml
     <Status-Line>
        <HTTP-Version>HTTP/1.1</HTTP-Version>
        <Status-Code>200</Status-Code>
@@ -169,65 +172,65 @@ Let's assume that such a resource accept
        <!-- 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}
+
+So that you can write the following BPEL lines:
+
+    :::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>
+
+### 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|
+
+<div class="alert alert-info">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 <code>http.protocol.max-redirects</code> in the 
<a href="endpoint-configuration.html">enpoint-configuration.properties</a> of 
your process.</div>
+
+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.
+
+    :::xml
     <definitions ...
                       
xmlns:odex="http://www.apache.org/ode/type/extension/http"/>
     
@@ -254,4 +257,3 @@ Let's assume that such a resource accept
             </operation>
         </binding>
     </definitions>
-    {code}


Reply via email to