You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ode.apache.org by va...@apache.org on 2012/12/31 17:01:32 UTC
svn commit: r1427157 - in /ode/site/trunk/content:
controlling-odes-memory-footprint.mdtext
direct-process-to-process-communication.mdtext
endpoint-configuration.mdtext http-authentication.mdtext
using-a-jndi-datasource-under-servicemix-jbi.mdtext
Author: vanto
Date: Mon Dec 31 16:01:31 2012
New Revision: 1427157
URL: http://svn.apache.org/viewvc?rev=1427157&view=rev
Log:
formatting tweaks.
Modified:
ode/site/trunk/content/controlling-odes-memory-footprint.mdtext
ode/site/trunk/content/direct-process-to-process-communication.mdtext
ode/site/trunk/content/endpoint-configuration.mdtext
ode/site/trunk/content/http-authentication.mdtext
ode/site/trunk/content/using-a-jndi-datasource-under-servicemix-jbi.mdtext
Modified: ode/site/trunk/content/controlling-odes-memory-footprint.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/controlling-odes-memory-footprint.mdtext?rev=1427157&r1=1427156&r2=1427157&view=diff
==============================================================================
--- ode/site/trunk/content/controlling-odes-memory-footprint.mdtext (original)
+++ ode/site/trunk/content/controlling-odes-memory-footprint.mdtext Mon Dec 31 16:01:31 2012
@@ -1,51 +1,52 @@
-Title: Controlling ODE's Memory Footprint
-
-## Rational
-
-In most ODE deployments, processes are only used once in a while and the time between each solicitation can be pretty long with respect to the actual execution time. However the default behavior for the engine is to load all processes permanently in memory, including their definition. For environments where memory is scarce or where a large number of processes are deployed, this isn't suitable.
-
-ODE implements two mechanisms in order to reduce the memory footprint of the engine to the strict minimum:
-
-* Process definitions lazy-loading: processes are loaded in-memory bare, without their runtime definition (the compiled BPEL process). The definition will be loaded and associated to the in-memory process representation only when they are actually invoked. This mechanism is called hydration.
-* Process definitions reaping: process definitions can be disassociated from their in-memory representation if they haven't been used for some time of if there are already too many definitions loaded in memory. This mechanism is called dehydration. A process will automatically rehydrate itself when necessary (when it receives a message for example).
-
-## Activating Dehydration Policy
-
-In the Axis2 integration layer, activation of the policy can be done by setting the following property in the ode-axis2.properties file, which is located in the WEB-INF/conf directory of ODE's web application:
-
- :::text
- ode-axis2.process.dehydration=true
-
-The default configuration is to dehydrate processes that haven't been used for 20mn or after the maximum of 1000 process definitions in memory is reached.
-
-However, you may override the time that the process have to remain unused before they can be considered for dehydration by specifying a value, in milliseconds, for the following property in the ode-axis2.properties file:
-
- :::text
- # wait for 5 minutes instead of 20 minutes
- ode-axis2.process.dehydration.maximum.age=300000
-
-Similarly, you may override the maximum number of process definitions that may remain hydrated at any given point in time by specifying a value for the following property in the ode-axis2.properties file:
-
- :::text
- # allow not more than 500 processes to be in memory at once
- ode-axis2.process.dehydration.maximum.count=500
-
-## Dehydration Policy at IL Level
-
-If you're using your own interface layer or want to do some customization at this level, the default hydration policy is implemented in [CountLRUDehydrationPolicy](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/engine/CountLRUDehydrationPolicy.java). It should be set on [BpelServerImpl](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/engine/BpelServerImpl.java) and can been configured by setting the process max age or max count (either one will not influence the dehydration if set to 0). For example:
-
- :::java
- CountLRUDehydrationPolicy dehy = new CountLRUDehydrationPolicy();
- dehy.setProcessMaxAge(60000); // Setting process max age to one minute
- dehy.setProcessMaxCount(100); // Setting maximum hydrated processes to 100
- _server.setDehydrationPolicy(dehy);
-
-The dehydration policy is polled every 10s to see if some processes should be dehydrated so a process max age of less than 10 seconds will be effectively of 10 seconds. Alternatively a custom dehydration policy can be used by implementing the [DehydrationPolicy|http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/engine/DehydrationPolicy.java] interface.
-
-## In-Memory Processes
-
-The property `ode-axis2.mex.inmem.ttl` may be used to limit the time-to-live of in-memory instances. This setting can be useful to avoid memory leaks related to in-memory processes that may get 'stuck' during execution and never terminate.
-
- :::text
- # automatically discard any in-memory process instance after 5 minutes
- ode-axis2.mex.inmem.ttl=300000
+Title: Controlling ODE's Memory Footprint
+Category: documentation
+
+## Rational
+
+In most ODE deployments, processes are only used once in a while and the time between each solicitation can be pretty long with respect to the actual execution time. However the default behavior for the engine is to load all processes permanently in memory, including their definition. For environments where memory is scarce or where a large number of processes are deployed, this isn't suitable.
+
+ODE implements two mechanisms in order to reduce the memory footprint of the engine to the strict minimum:
+
+* Process definitions lazy-loading: processes are loaded in-memory bare, without their runtime definition (the compiled BPEL process). The definition will be loaded and associated to the in-memory process representation only when they are actually invoked. This mechanism is called hydration.
+* Process definitions reaping: process definitions can be disassociated from their in-memory representation if they haven't been used for some time of if there are already too many definitions loaded in memory. This mechanism is called dehydration. A process will automatically rehydrate itself when necessary (when it receives a message for example).
+
+## Activating Dehydration Policy
+
+In the Axis2 integration layer, activation of the policy can be done by setting the following property in the ode-axis2.properties file, which is located in the WEB-INF/conf directory of ODE's web application:
+
+ :::properties
+ ode-axis2.process.dehydration=true
+
+The default configuration is to dehydrate processes that haven't been used for 20mn or after the maximum of 1000 process definitions in memory is reached.
+
+However, you may override the time that the process have to remain unused before they can be considered for dehydration by specifying a value, in milliseconds, for the following property in the ode-axis2.properties file:
+
+ :::properties
+ # wait for 5 minutes instead of 20 minutes
+ ode-axis2.process.dehydration.maximum.age=300000
+
+Similarly, you may override the maximum number of process definitions that may remain hydrated at any given point in time by specifying a value for the following property in the ode-axis2.properties file:
+
+ :::properties
+ # allow not more than 500 processes to be in memory at once
+ ode-axis2.process.dehydration.maximum.count=500
+
+## Dehydration Policy at IL Level
+
+If you're using your own interface layer or want to do some customization at this level, the default hydration policy is implemented in [CountLRUDehydrationPolicy](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/engine/CountLRUDehydrationPolicy.java). It should be set on [BpelServerImpl](http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/engine/BpelServerImpl.java) and can been configured by setting the process max age or max count (either one will not influence the dehydration if set to 0). For example:
+
+ :::java
+ CountLRUDehydrationPolicy dehy = new CountLRUDehydrationPolicy();
+ dehy.setProcessMaxAge(60000); // Setting process max age to one minute
+ dehy.setProcessMaxCount(100); // Setting maximum hydrated processes to 100
+ _server.setDehydrationPolicy(dehy);
+
+The dehydration policy is polled every 10s to see if some processes should be dehydrated so a process max age of less than 10 seconds will be effectively of 10 seconds. Alternatively a custom dehydration policy can be used by implementing the [DehydrationPolicy|http://svn.apache.org/repos/asf/ode/trunk/bpel-runtime/src/main/java/org/apache/ode/bpel/engine/DehydrationPolicy.java] interface.
+
+## In-Memory Processes
+
+The property `ode-axis2.mex.inmem.ttl` may be used to limit the time-to-live of in-memory instances. This setting can be useful to avoid memory leaks related to in-memory processes that may get 'stuck' during execution and never terminate.
+
+ :::properties
+ # automatically discard any in-memory process instance after 5 minutes
+ ode-axis2.mex.inmem.ttl=300000
Modified: ode/site/trunk/content/direct-process-to-process-communication.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/direct-process-to-process-communication.mdtext?rev=1427157&r1=1427156&r2=1427157&view=diff
==============================================================================
--- ode/site/trunk/content/direct-process-to-process-communication.mdtext (original)
+++ ode/site/trunk/content/direct-process-to-process-communication.mdtext Mon Dec 31 16:01:31 2012
@@ -1,5 +1,5 @@
Title: Direct Process-to-Process Communication
Category: documentation
-# P2P Communication
+## P2P Communication
ODE automatically optimizes all process-to-process (P2P) communication such that all message exchanges happen directly inside the engine and do not go through the integration layer (e.g. Axis2, JBI, ...).
Modified: ode/site/trunk/content/endpoint-configuration.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/endpoint-configuration.mdtext?rev=1427157&r1=1427156&r2=1427157&view=diff
==============================================================================
--- ode/site/trunk/content/endpoint-configuration.mdtext (original)
+++ ode/site/trunk/content/endpoint-configuration.mdtext Mon Dec 31 16:01:31 2012
@@ -1,11 +1,13 @@
Title: Endpoint Configuration
+Category: documentation
+
<a name="EndpointConfiguration-endpointconfigurationpropertyfiles"></a>
-### endpoint configuration property files
+## Endpoint configuration property files
SOAP and HTTP external endpoints can be tweaked using some property files. A common set of properties are available to configure external services. At run time, ODE will translate these properties and apply them to Axis2 or HttpClient depending if the targeted service uses SOAP binding or HTTP binding.
<a name="EndpointConfiguration-Conventionsandlocations"></a>
-#### Conventions and locations
+### Conventions and locations
The extension of these property files must be `*.endpoint`. These files can be dropped in 2 different locations:
* the global configuration directory of ODE which is by default `ode/WEB-INF/conf`. This location might be customized with the system property `org.apache.ode.configDir`
@@ -20,7 +22,7 @@ Two rules of precedence apply:
</div>
<a name="EndpointConfiguration-Dynamicrefresh"></a>
-#### Dynamic refresh
+### Dynamic refresh
Properties are dynamically loaded and refreshed at run time.
The timing is the following:
@@ -30,11 +32,12 @@ Consequently, if you have updated proper
<a name="EndpointConfiguration-Hierarchicalproperties"></a>
-#### Hierarchical properties
+### Hierarchical properties
The property file is a regular property file except that service name and port name may be used to apply different default values to different services.
All properties follow this pattern:
+ :::properties
[nsalias.servicename[.portname].ode.]property
@@ -42,11 +45,11 @@ If service name is mentioned but port na
If service name and port name are omitted, the value will apply to all services.
<a name="EndpointConfiguration-Namespacemanagement"></a>
-##### Namespace management
+#### Namespace management
A service has to be qualified. To so do you may define namespace aliases. Aliases will then prefixed the service local name.
-
+ :::properties
alias.ode_ns=http://ode.apache.org
ode_ns.dummyservice.ode.http.request.chunk=true
@@ -54,7 +57,7 @@ A service has to be qualified. To so do
If your namespace does not collide with the [property syntax ](http://java.sun.com/j2se/1.4.2/docs/api/java/util/properties.html#load(java.io.inputstream).html), you dont have to define an alias. This property file is accepted:
-
+ :::properties
# Next line is commented
# alias.ode_ns=http://ode.apache.org
@@ -63,7 +66,7 @@ If your namespace does not collide with
<a name="EndpointConfiguration-Examples"></a>
-##### Examples
+#### Examples
For instance, considering 2 services:
* the `foo-service`
@@ -71,6 +74,7 @@ For instance, considering 2 services:
and this property file:
+ :::properties
alias.test_ns=http://test.org
http.protocol.max-redirects=5
@@ -85,7 +89,7 @@ The `http.protocol.max-redirect` propert
* *100* for `brel-service.port-of-amsterdam`
<a name="EndpointConfiguration-Supportedproperties"></a>
-#### Supported properties
+### Supported properties
Here the list of supported properties, and their descriptions. If the file contains some properties not listed here, they will be available in the property map nevertheless. Values will be strings.
Such unmanaged properties will also be passed to Axis2 options and HttpClient params, see below.
@@ -115,7 +119,7 @@ Such unmanaged properties will also be p
| | ws-adddressing.headers | true(default)/false | Enable/disable the WS-Addressing headers for outgoing soap requests |
<a name="EndpointConfiguration-Samplefile"></a>
-#### Sample file
+### Sample file
[sample.endpoint.txt](/resources/sample.endpoint.txt)
@@ -123,13 +127,13 @@ Download, remove the '.txt' prefix, cust
<a name="EndpointConfiguration-ImplementationDetailsforOutboundservices"></a>
-#### Implementation Details for Outbound services
+### Implementation Details for Outbound services
The properties related to Outbound services have to be applied to Axis2 (for SOAP services) or HttpClient (for HTTP services).
Tables below sum up this information.
<a name="EndpointConfiguration-SOAPServices(Axis2)"></a>
-##### SOAP Services (Axis2)
+#### SOAP Services (Axis2)
For Axis2, all properties are converted to meet the [Options#setProperty() ](http://ws.apache.org/axis2/1_3/api/org/apache/axis2/client/options.html#setproperty(java.lang.string,%20java.lang.object).html) requirements.
@@ -150,7 +154,7 @@ For Axis2, all properties are converted
</table>
<a name="EndpointConfiguration-HTTPServices(HttpClient)"></a>
-##### HTTP Services (HttpClient)
+#### HTTP Services (HttpClient)
For HttpClient, all properties are defined by: [HttpMethodParams ](http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/params/httpmethodparams.html.html), HostParams, HttpClientParams, HttpConnectionParams and HttpConnectionManagerParams.
The idea is to convert properties into the expected type and push them in a [`DefaultHttpParams` ](http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/params/defaulthttpparams.html.html). This property holder is then set as the parent of all other `HttpParams` used.
@@ -170,7 +174,7 @@ If a given property is not listed below,
<a name="EndpointConfiguration-AdditionalConfigurationforSOAPEndpoints"></a>
-### Additional Configuration for SOAP Endpoints
+## Additional Configuration for SOAP Endpoints
If you deploy ODE in an application server, the [Axis2 Integration Layer](/developerguide/architectural-overview#odeintegrationlayers.html) allows ODE to communicate via Web Service interactions. SOAP Web Services will be managed by Axis2. These web services may be configured dynamically.
For each service, you need to place a `\[serviceLocalName\](servicelocalname\.html).axis2` file at the root of the process bundle. Currently, this file can only be added on the server, under `var/processes/\{$process_dir\`}.
Modified: ode/site/trunk/content/http-authentication.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/http-authentication.mdtext?rev=1427157&r1=1427156&r2=1427157&view=diff
==============================================================================
--- ode/site/trunk/content/http-authentication.mdtext (original)
+++ ode/site/trunk/content/http-authentication.mdtext Mon Dec 31 16:01:31 2012
@@ -1,4 +1,8 @@
Title: HTTP Authentication
+Category: documentation
+
+## Overview
+
This section explains how to perform authentication against Web services requiring HTTP basic, digest or NTLM authentication mechanisms.
<div class="alert alert-warning"><h4 class="alert-heading">Non-Standard</h4>
@@ -6,23 +10,27 @@ This section explains how to perform aut
</div>
<a name="HTTPAuthentication-Authenticationelementandmessagepart"></a>
-### Authentication element and message part
+## Authentication element and message part
To perform authentication, you must pass an additional message part containing the general `authentication` element which contains the credentials (as plain-text strings)
-{code:xml|title=Authenticate Message Part Content}
-<auth:authenticate xmlns:auth="urn:ode.apache.org/authentication">
- <auth:username/>?
- <auth:password/>?
- <auth:domain/>? <!-- NTLM specific -->
- <auth:realm/>? <!-- NTLM specific -->
- <auth:token/>?
-</auth:authenticate>
+<div class="caption">Authenticate Message Part Content</div>
+
+ :::xml
+ <auth:authenticate xmlns:auth="urn:ode.apache.org/authentication">
+ <auth:username/>?
+ <auth:password/>?
+ <auth:domain/>? <!-- NTLM specific -->
+ <auth:realm/>? <!-- NTLM specific -->
+ <auth:token/>?
+ </auth:authenticate>
- This additional message part may be declared in the WSDL definition to allow tools to validate the data structure:
+This additional message part may be declared in the WSDL definition to allow tools to validate the data structure:
- {code:xml|title="MyService.wsdl"}
+<div class="caption">MyService.wsdl</div>
+
+ :::xml
<?xml version='1.0' encoding='utf-8'?>
<wsdl:definitions xmlns:tns="http://www.example.com"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
@@ -52,31 +60,33 @@ Notes:
The schema of the `authenticate` element follows:
-{code:xml|title=Authenticate.xsd}
-<?xml version="1.0" encoding="UTF-8"?>
-<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
- targetNamespace="urn:ode.apache.org/authentication"
- elementFormDefault="qualified">
-
- <xs:element name="authenticate">
- <xs:complexType>
- <xs:sequence>
- <xs:element name="username" type="xs:string" minOccurs="0" maxOccurs="1"/>
- <xs:element name="password" type="xs:string" minOccurs="0" maxOccurs="1"/>
- <xs:element name="domain" type="xs:string" minOccurs="0" maxOccurs="1"/>
- <xs:element name="realm" type="xs:string" minOccurs="0" maxOccurs="1"/>
- <xs:element name="token" minOccurs="0" maxOccurs="1">
- <xs:complexType>
- <xs:sequence>
- <xs:any minOccurs="1"/>
- </xs:sequence>
- </xs:complexType>
- </xs:element>
- </xs:sequence>
- </xs:complexType>
- </xs:element>
+<div class="caption">Authenticate.xsd</div>
+
+ :::xml
+ <?xml version="1.0" encoding="UTF-8"?>
+ <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
+ targetNamespace="urn:ode.apache.org/authentication"
+ elementFormDefault="qualified">
+
+ <xs:element name="authenticate">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:element name="username" type="xs:string" minOccurs="0" maxOccurs="1"/>
+ <xs:element name="password" type="xs:string" minOccurs="0" maxOccurs="1"/>
+ <xs:element name="domain" type="xs:string" minOccurs="0" maxOccurs="1"/>
+ <xs:element name="realm" type="xs:string" minOccurs="0" maxOccurs="1"/>
+ <xs:element name="token" minOccurs="0" maxOccurs="1">
+ <xs:complexType>
+ <xs:sequence>
+ <xs:any minOccurs="1"/>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
+ </xs:sequence>
+ </xs:complexType>
+ </xs:element>
-</xs:schema>
+ </xs:schema>
You can add this schema to your project to allow tools to display/validate the correct element structure.
Modified: ode/site/trunk/content/using-a-jndi-datasource-under-servicemix-jbi.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/using-a-jndi-datasource-under-servicemix-jbi.mdtext?rev=1427157&r1=1427156&r2=1427157&view=diff
==============================================================================
--- ode/site/trunk/content/using-a-jndi-datasource-under-servicemix-jbi.mdtext (original)
+++ ode/site/trunk/content/using-a-jndi-datasource-under-servicemix-jbi.mdtext Mon Dec 31 16:01:31 2012
@@ -1,26 +1,30 @@
Title: Using a JNDI datasource under ServiceMix JBI
+Category: documentation
+
+## Overview
+
These instructions will help you configure a JNDI DataSource for Apache ODE when running inside the ServiceMix JBI container.
-<a name="UsingaJNDIdatasourceunderServiceMixJBI-1.Edit$SERVICEMIX/conf/jndi.xml"></a>
-### 1. Edit $SERVICEMIX/conf/jndi.xml
+<a name="UsingaJNDIdatasourceunderServiceMixJBI-1.Edit-SERVICEMIX/conf/jndi.xml"></a>
+## 1. Edit $SERVICEMIX/conf/jndi.xml
Declare a managed connection factory pointing to your database:
+ :::xml
+ <bean id="odeManagedConnectionFactory" class="org.jencks.tranql.DataSourceMCF">
+ <property name="driverName" value="com.mysql.jdbc.Driver"/>
+ <property name="url" value="jdbc:mysql://hostname/databaseName"/>
+ <property name="user" value="username"/>
+ <property name="password" value="myPassword"/>
+ </bean>
- <bean id="odeManagedConnectionFactory" class="org.jencks.tranql.DataSourceMCF">
- <property name="driverName" value="com.mysql.jdbc.Driver"/>
- <property name="url" value="jdbc:mysql://hostname/databaseName"/>
- <property name="user" value="username"/>
- <property name="password" value="myPassword"/>
- </bean>
+And register the DataSource in the JNDI registry by adding an `<entry>` under the `<util:map>` element:
-And register the DataSource in the JNDI registry by adding an <entry> under the <util:map> element:
+ :::xml
+ <util:map id="jndiEntries">
-
- <util:map id="jndiEntries">
-
<!-- ODE DataSource -->
<entry key="java:comp/env/jdbc/ode">
<bean id="odeDataSource" class="org.jencks.factory.ConnectionFactoryFactoryBean">
@@ -28,19 +32,19 @@ And register the DataSource in the JNDI
<property name="connectionManager" ref="connectionManager"/>
</bean>
</entry>
-
+
<!-- ... other entries follow... -->
-
- </util:map>
+
+ </util:map>
<a name="UsingaJNDIdatasourceunderServiceMixJBI-2.Editode-jbi.properties"></a>
-### 2. Edit ode-jbi.properties
+## 2. Edit ode-jbi.properties
In ode-jbi.properties, set the following properties:
-
+ :::properties
ode-jbi.db.mode=EXTERNAL
ode-jbi.db.ext.dataSource=java:comp/env/jdbc/ode
@@ -48,25 +52,25 @@ In ode-jbi.properties, set the following
(Be sure to match the JNDI lookup name to the one defined in $SERVICEMIX/conf/jndi.xml)
<a name="UsingaJNDIdatasourceunderServiceMixJBI-3.Addjencks-2.0-alllibrary"></a>
-### 3. Add jencks-2.0-all library
+## 3. Add jencks-2.0-all library
Copy [jencks-2.0-all.jar](http://repository.codehaus.org/org/jencks/jencks/2.0/jencks-2.0-all.jar) under $SERVICEMIX/lib
<a name="UsingaJNDIdatasourceunderServiceMixJBI-4.RestartServiceMix"></a>
-### 4. Restart ServiceMix
+## 4. Restart ServiceMix
And you're done! Don't forget to redeploy your service assemblies since they need to be re-synchronized with ODE.
<a name="UsingaJNDIdatasourceunderServiceMixJBI-Extras"></a>
-### Extras
+## Extras
<a name="UsingaJNDIdatasourceunderServiceMixJBI-ConnectionPoolParameters"></a>
-#### Connection Pool Parameters
+### Connection Pool Parameters
If you want to manually configure the connection pool parameters, edit $SERVICEMIX/conf/tx.xml and update the "poolingSupport" object. For example,
-
- <jencks:poolingSupport id="poolingSupport"
+ :::xml
+ <jencks:poolingSupport id="poolingSupport"
connectionMaxIdleMinutes="5"
connectionMaxWaitMilliseconds="10000"
poolMaxSize="100"