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 [2/6] - /ode/site/trunk/content/
Added: ode/site/trunk/content/bpel-management-api-specification.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/bpel-management-api-specification.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/bpel-management-api-specification.mdtext (added)
+++ ode/site/trunk/content/bpel-management-api-specification.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,423 @@
+Title: BPEL Management API Specification
+<a name="BPELManagementAPISpecification-BPELManagementAPISpecification"></a>
+# BPEL Management API Specification
+The BPEL Management API {excerpt} exposes management functions related to BPEL processes and their instances{excerpt}.
+
+<a name="BPELManagementAPISpecification-GeneralDesignPrinciples"></a>
+## General Design Principles
+The Process Management API is defined as a Web service interface. In doing so we can offer SOAP access to the service, and also create Java interfaces for SOAP access and JMX, depending on needs. All messages are defined as XML elements, mapping to WSDL doc/literal.
+
+Complex structures and other data fields are declared as XML elements. However, key fields are declared as XML attributes. This distinction maps to the concept of keys in several languages, e.g. constraints can be applied in XML Schema using key fields, or used as keys in a Java [HashMap](hashmap.html). Sequences of elements map to ordered collections, which may be accessed by position or key. For example, when returning a list of process instances, the collections is ordered as specified in the request, but in addition the process identifier can be used as a key into the collection.
+
+When data does not easily yield to structuring, we use a textual presentation and BNF to define the syntax. For example, a query statement like "order_id`123 and customer_id`456" is easier to process in textual form.
+
+<a name="BPELManagementAPISpecification-TheProcessDefinitionManagementInterface"></a>
+## The Process Definition Management Interface
+The process definition management interface defines six operations:
+* _list_ \- Returns information about all, or some process definitions.
+* _details_ \- Returns detailed information about the specified process definition.
+* _set-properties_ \- Changes properties associated with the process definition.
+* _activate_ \- Activates the process definition.
+* _retire_ \- Retires the process definition.
+
+<a name="BPELManagementAPISpecification-ListProcessDefinitions"></a>
+### List Process Definitions
+The _list_ operation retrieves and returns information about all, or some process definitions.
+
+The request identifies the process definitions using a filter that can select definitions with a given name, status, deployment date, etc. Without a filter, the operation returns all process definitions. The request also indicates what information to include in the response, and which key fields to use for ordering the results. The request schema has the following structure:
+
+ <list>
+ <filter> filter <filter>?
+ <include> includes </include>?
+ <order> keys </order>?
+ </list>
+
+The _filter_ element can be used to narrow down the list of process definitions by applying selection criteria. There are four filters that can be applied:
+* _name_ \- Only process definition with this local name.
+* _namespace_ \- Only process definition with this namespace URI.
+* _status_ \- Only process definition with these status code(s).
+* _deployed_ \- Only process definitions deployed relative to this date/time.
+
+The _name_ and _namespace_ filters can do full or partial name matching. Partial matching occurs if either filter ends with an asterisk (*). These filters are not case sensitive, for example\* *_name`my_* will match _MyProcess_ and _my-process_. If unspecified, the default filter is _name`\* namespace=\*_.
+
+The _status_ filter can be used to filter all process definitions based on two status codes, _activated_ and _retired_.
+
+The _deployed_ filter can be used to filter all process definitions deployed on or after a particular date or date/time instant. The value of this filter is either an ISO-8601 date or ISO-8601 date/time. For example, to find all process definitions deployed on or after September 1, 2005, use _deployed>=20050901_.
+
+The _include_ element can be used to request the operation returns additional information in the response, by specifying a space-separated list of keywords. Currently two keywords are supported:
+* _properties_ \- Returns process definition properties.
+* _instance_ \- Returns aggregate instance information.
+
+By default the response returns process definitions in no particular order. The _order_ element can be used to order the results by specifying a space-separated list of keys. Each key can be prefixed with a plus sign '+' to specify ascending order, or a '-' minus sign to specify descending order. Without a sign the default behavior is to return process definitions in ascending order. The currently supported odering keys are:
+* _name_ \- Order based on the local name of the process definition.
+* _namespace_ \- Order based on the namespace URI of the process definition.
+* _version_ \- Order based on the version number.
+* _status_ \- Order based on the status of the process definition (_activated_ followed by _retired_).
+* _deployed_ \- Order based on the deployment date/time.
+
+For exampe, the following request returns all process definitions that have a name starting with _order_ and are currently in the activated status. The response is ordered by the definition name, definitions with the same name are ordered by descending version number. Aggergate instance information is returned for each process definition that matches the filter.
+
+ <list>
+ <filter>name=order* status=activated</filter>
+ <include>instance</include>
+ <order>name -version</order>
+ </list>
+
+The response to the _list_ operation lists all process definitions that match the filters, empty if no process definition matches the filter. The response schema has the following structure:
+
+ <list.response>
+ <definition name = ncname
+ namespace = uri
+ version = integer>
+ <deployed>
+ <activated> | <retired>
+ <properties>?
+ <instances>?
+ </definition>*
+ </list.response>
+
+Each process definition is identified by its fully qualified name (_name_ and _namespace_ attributes) and version number. If there are multiple versions of the same process definition, the operation will return information about all of the versions that match the filter.
+
+The _deployed_ element specifies when the process definition was deployed and by which user. It has the following structure:
+
+ <deployed>
+ <on> date/time </on>
+ <by> token </by>
+ </deployed>
+
+If the process definition is activated, the _activated_ element specifies when it was activated and by which user. If the process was activated upon deployment, then the information provided by the _deployed_ and _activated_ elements will be identical. If the process definition is retired, the _retired_ element specifies which it was retired and by which user. All three elements use the same structure.
+
+If the operation requested process properties, the _properties_ element will appear in the response. It has the following structure:
+
+ <properties>
+ <property name = ncname
+ namespace = uri>
+ <value> mixed </value>
+ </property>*
+ </properties>
+
+Each property is identified by it's fully qualified name (the `name` and `namespace` attributes). The `value` element serves as a wrapper for the property value, which may include mixed content and use elements for different namespaces.
+
+If the operation requested instance aggregates, the _instances_ element will appear in the response. It has the following structure:
+
+ <instances>
+ <instance status = token>
+ <count> integer </count>
+ </instance>*
+ </instances>
+
+The _instance_ element returns the number of process instances that have the status specified by the _status_ attribute. The following status codes are used:
+* _active_ \- All currently active process instances.
+* _completed_ \- All successfully completed process instances.
+* _terminated_ \- All terminated process instances.
+* _failed_ \- All failed process instances.
+* _suspended_ \- All process instances that are currently suspended.
+* _error_ \- All process instances currently reporting an error.
+
+During it's execution, a process instance is in the _active_ state. It may be suspended, in which case it is counted as _suspended_ and not _active_. If an error occurs that does not cause the process to complete, but requires attention, the process is counted in _error_ instead of _active_. If a process is terminated with the _exit_ activity, or any other mechanism that applies the same semantics, it counts as _terminated_. If a fault occurs in the global scope, the process counts as _failed_. Otherwise, the process is counted as _completed_.
+
+<a name="BPELManagementAPISpecification-GetProcessDefinitionDetails"></a>
+### Get Process Definition Details
+The _details_ operation retrieves and returns detailed information about the specified process definition.
+
+The request identifies the process definition by its fully qualified name, and optionally by version number. If the version number is ommitted, information is returned about the last version of the process definition. The request schema has the following structure:
+
+ <details>
+ <definition name = ncname
+ namespace = uri
+ version? = integer>
+ </definition>
+ </details>
+
+The response uses a structure similar to the _list_ operation, with additional information not returned from _list_. The response includes the requested process definition, and will be empty if that process definition cannot be found in the system. The response schema has the following structure:
+
+ <details.response>
+ <definition name = ncname
+ namespace = uri
+ version = integer>
+ <deployed>
+ <activated> | <retired>
+ <properties>
+ <instances>
+ <documents>
+ <extension elements>*
+ </definition>?
+ </details.response>
+
+
+The response always returns information about instances of the process definition. The response also returns a list of documents associated with the process definition, for example, the BPEL process definition, WSDL service definitions, deployment descriptor, etc. Applications may need to retrieve these documents for further processing, e.g. to monitor service endpoints defined in the process, or interpret data from the process instance.
+
+The _documents_ element has the following structure:
+
+ <documents>
+ <document name = ncname?
+ namespace = uri?
+ type = uri
+ src = uri>
+ </document>*
+ </documents>
+
+The _name_ and _namespace_ attributes reference the document name and namespace of definitions in that document, respectively. For example, if the document is a BPEL process definition, the _name_ attribute specifies the process definition, and the _namespace_ attribute specifies the target namespace of the process definition. These attributes are optional, as not all documents specify that information.
+
+An implementation must return a _name_ and _namespace_ attribute for every BPEL, WSDL and XSD documents that specify a name and/or namespace for their target definitions.
+
+The _type_ attribute uses a URI to identify the document type. For BPEL, WSDL and XSD, this attribute uses the namespace URI of the relevant specification, e.g. [...WSDL namespace...](...wsdl-namespace....html) for a WSDL 1.1 document.
+
+The _src_ attribute provides a URL that can be used to access the definition.
+
+The _details_ response may return additional information not covered here using extension elements. Extension elements must use a different namespace. Applications do not need to understand or process extension elements.
+
+<a name="BPELManagementAPISpecification-SetProcessDefinitionProperties"></a>
+### Set Process Definition Properties
+The _set-properties_ allows changes to properties associated with the process definition.
+
+The request identifies the process definition by its fully qualified name and version number, and specifies the updates to perform on that process definition. The request schema has the following structure:
+
+ <set-properties>
+ <definition name = ncname
+ namespace = uri
+ version = integer>
+ <properties>
+ <property name = ncname
+ namespace = uri>
+ <value> mixed </value>?
+ </property>*
+ </properties>
+ </definition>
+ </set-properties>
+
+
+A property can be changed or added by specifying the property by name and providing a value. A property is removed if the property name is specified but the _value_ element is absent.
+
+The response uses a structure similar to the _details_ operation, returning the state of the process definition after the state change. If the process could not be found, an empty response is returned. The response schema has the following structure:
+
+ <set-properties.response>
+ <definition name = ncname
+ namespace = uri
+ version = integer>
+ <deployed>
+ <activated> | <retired>
+ <properties>
+ <instances>
+ <documents>
+ <extension elements>*
+ </definition>?
+ </set-properties.response>
+
+
+<a name="BPELManagementAPISpecification-Activate/RetireProcessDefinition"></a>
+### Activate/Retire Process Definition
+The _activate_ and _retire_ operations are used to change the process definition status to activated and retired.
+
+The request identifies the process definition by its fully qualified name and version number, and specifies the updates to perform on that process definition. The request schema has the following structure:
+
+ <activate>
+ <definition name = ncname
+ namespace = uri
+ version = integer>
+ </activate>
+
+ <retire>
+ <definition name = ncname
+ namespace = uri
+ version = integer>
+ </retire>
+
+The response uses a structure similar to the _details_ operation, returning the state of the process definition after the state change. If the process could not be found, an empty response is returned.
+
+<a name="BPELManagementAPISpecification-Faults"></a>
+### Faults
+The operations in this interface may throw onw of two faults:
+* _invalid-request_ \- The request message is missing mandatory information, contains invalid information, or contains elements/attributes that are not supported by the operation.
+* _processing-error_ \- The operation failed to process the request. The application may try the operation at a later time.
+
+By design the operations return _invalid-request_ only if the request message is invalid. If the request does not identify any deployed process definition, the operation returns a response that contains no process definition.
+
+<a name="BPELManagementAPISpecification-TheProcessInstanceManagementInterface"></a>
+## The Process Instance Management Interface
+The process instance management interface defines four operations:
+* _list_ \- Returns information about all, or some process instances.
+* _detail_ \- Returns detailed information about the specified process instance.
+* _suspend_ \- Suspends the process instance.
+* _resume_ \- Resumes the process instance.
+* _terminate_ \- Terminates the process instance.
+* _fault_ \- Faults the process instance.
+* _delete_ \- Deletes all or some completed process instances.
+
+<a name="BPELManagementAPISpecification-ListProcessInstances"></a>
+### List Process Instances
+The _list_ operation retrieves and returns information about all, or some process instances.
+
+The request identifies the process instances using a filter that can select instances with a given name, status, property values, etc. Without a filter, the operation returns all process instances up to a specified limit. The request also indicates which key fields to use for ordering the results. The request schema has the following structure:
+
+ <list>
+ <filter> filter <filter>?
+ <order> keys </order>?
+ <limit> integer </limit>
+ <properties> names </properties>
+ </list>
+
+The _filter_ element can be used to narrow down the list of process definitions by applying selection criteria. There are six filters that can be applied:
+* _name_ \- Only process instances with this local name.
+* _namespace_ \- Only process instances with this namespace URI.
+* _status_ \- Only process instances with these status code(s).
+* _started_ \- Only process instances started relative to this date/time.
+* _last-active_ \- Only process instances last active relative to this date/time.
+* _$property_ \- Only process instances with a correlation property equal to the specified value.
+
+The _name_ and _namespace_ filters can do full or partial name matching. Partial matching occurs if either filter ends with an asterisk (*). These filters are not case sensitive, for example\* *_name`my_* will match _MyProcess_ and _my-process_. If unspecified, the default filter is _name`\* namespace=\*_.
+
+The _status_ filter can be used to filter all process definitions based on six status codes:
+* _active_ \- All currently active process instances (excludes instances in any other state).
+* _suspended_ \- All process instances that have not completed, but are currently suspended.
+* _error_ \- All process instances that have not completed, but are currently indicate an error condition.
+* _completed_ \- All successfully completed process instances (excludes instances in any other state).
+* _terminated_ \- All process instances that were terminated.
+* _faulted_ \- All process instances that encountered a fault (in the global scope).
+
+The _started_ filter can be used to filter all process instances started on or after a particular date or date/time instant. The value of this filter is either an ISO-8601 date or ISO-8601 date/time. For example, to find all process instances started on or after September 1, 2005, use _started>=20050901_. Similarly, the _last-active_ filter can be used to filter all process instances based on their last active time. The last active time records when the process last completed performing work, and either completed or is now waiting to receive a message, a timeout or some other event.
+
+Each process instance has one or more properties that are set its instantiation, that can be used to distinguish it from other process instances. In this version of the specification, we only support properties instantiated as part of correlation sets defined in the global scope of the process. For example, if a process instantiates a correlation set that uses the property _order-id_, it is possible to filter that process instance based on the value of that property.
+
+The property name is identified by the prefix _$_. If the property name is an _NCName_, the filter will match all properties with that local name. If the property name is
+\{namespace}\ _local_, the filter will match all properties with the specified namespace URI and local name. For example, to retrieve a list of all active process instances with a property _order-id_ that has the value 456, use _status`active $order-id`456_.
+
+By default the response returns process instances in no particular order. The _order_ element can be used to order the results by specifying a space-separated list of keys. Each key can be prefixed with a plus sign '+' to specify ascending order, or a '-' minus sign to specify descending order. Without a sign the default behavior is to return process instances in ascending order. The currently supported odering keys are:
+* _pid_ \- Order based on the process identifier.
+* _name_ \- Order based on the local name of the process instance.
+* _namespace_ \- Order based on the namespace URI of the process instance.
+* _version_ \- Order based on the version number.
+* _status_ \- Order based on the status of the process instance.
+* _started_ \- Order based on the process instance start date/time.
+* _last-active_ \- Order based on the process instance last active date/time.
+
+The _properties_ element is used to request the value of one or more properties, for each of the returned process instances. The value of this element is a list of names, each an _NCName_. Properties specified in this element do not have to overlap with properties specified in the filter.
+
+*TBD:* describe limit.
+
+The response to the _list_ operation lists all process instances that match the filters, empty if no process instance matches the filter. The response schema has the following structure:
+
+ <list.response>
+ <instance pid = string>
+ <defintion name = ncname
+ namespace = uri
+ version = integer>
+ </definition>
+ <started> date/time </started>
+ <last-active> date/time </last-active>
+ <status> status </status>
+ <error-ts> date/time </error-ts>?
+ <properties>
+ <property name = ncname
+ namespace = uri>
+ value
+ </property>*
+ </properties>
+ <fault>
+ TBD
+ </fault>?
+ </instance>*
+ </list.response>
+
+Each process is identified by the unique process instance identifier (_pid_). In addition, the process's definition is identified by its fully qualified name and version number.
+
+The _started_ element indicates when the process instance was started, while _last-active_ indicates when the process instance was last active. If the process instance has completed (successfully or not), this element provides the actual completion date/time. The status code indicates whether the process is active, completed successfully, or any of the six states described for the filter.
+
+The _properties_ element lists one or more properties and their values. The name of the property is specified using the _name_ and _namespace_ attributes, the value is contained within the _property_ element. Note that an instance may have multiple different values for the same property, in which case the _property_ element will appear multiple times with the same name and different values.
+
+*TBD:* error-ts and fault elements.
+
+<a name="BPELManagementAPISpecification-GetProcessInstanceDetails"></a>
+### Get Process Instance Details
+The _details_ operation retrieves and returns detailed information about the specified process instance.
+
+The request identifies the process instance using the process identifier. The request schema has the following structure:
+
+ <details>
+ <instance pid = token>
+ </instance>
+ </details>
+
+The response uses a structure similar to the _list_ operation, with additional information not returned from _list_. The response includes the requested process instance, and will be empty if that process instance cannot be found in the system. The response schema has the following structure:
+
+ <details.response>
+ <instance pid = string>
+ <defintion name = ncname
+ namespace = uri
+ version = integer>
+ </definition>
+ <started> date/time </started>
+ <last-active> date/time </last-active>
+ <status> status </status>
+ <error-ts> date/time </error-ts>?
+ <properties>
+ <property name = ncname
+ namespace = uri>
+ value
+ </property>*
+ </properties>
+ <fault>
+ TBD
+ </fault>?
+ <extension elements>*
+ </instance>?
+ </details.response>
+
+*TBD:* Structure for returning state information about the process instance.
+
+The _details_ response may return additional information not covered here using extension elements. Extension elements must use a different namespace. Applications do not need to understand or process extension elements.
+
+<a name="BPELManagementAPISpecification-Suspend/Resumse/Terminate/FaultProcessInstance"></a>
+### Suspend/Resumse/Terminate/Fault Process Instance
+These operations are used to suspend/resume the process instance, or to forcefully complete the process instance, with and without recovery.
+
+The request identifies the process instance using the process identifier. The request schema has the following structure:
+
+ <suspend>
+ <instance pid = token/>+
+ </suspend>
+
+ <resume>
+ <instance pid = token/>+
+ </resume>
+
+ <terminate>
+ <instance pid = token/>+
+ </terminate>
+
+ <fault>
+ <instance pid = token>
+ </instance>
+ TBD: fault information
+ </fault>
+
+The _suspend_ operation changes the process state from active to suspended. It only affects process instances that are in the active or error states. Likewise, the _resume_ operation changes the process state from suspended to active. It only affects process instances that are in the suspended state.
+
+The _terminate_ operation causes the process instance to terminate immediately, without a chance to perform any fault handling or compensation. The process transitions to the _terminated_ state. It only affects process instances that are in the active, suspended or error states.
+
+The _fault_operation causes the process instance to complete unsuccessfully by throwing the specified fault in the global scope. The process is able to perform recovery using a fault handler in the global scope, through termination handlers in nested scopes and by invoking installed compensation handlers. The process will transition to the \_faulted_ state.
+
+The _suspend_, _resume_ and _terminate_ operations can be used with multiple process instances at the same time, by specifying a list of _instance_ elements.
+
+*TBD:* specifying which fault to throw and providing details.
+
+The response uses a structure similar to the _detail_ operation. The response includes the requested process instance, and will be empty if that process instance cannot be found in the system. The response reflects the process instance state available on return. Some state changes take significant time to process, e.g. when throwing a fault in the process, and may not be reflected in the response message.
+
+<a name="BPELManagementAPISpecification-DeleteProcessInstances"></a>
+### Delete Process Instances
+The _delete_ operation delete all, or some completed process instances.
+
+The request identifies the process instances using a filter that can select instances with a given name, status, property values, etc. Alternatively, the _instance_ element can be used to specify a particular process instance to delete. The _instance_ element can be repeated to delete multiple process instances in the same operation. At least one of these elements is required. The request schema has the following structure:
+
+ <delete>
+ <filter> filter <filter> | <instance pid = token/>+
+ </delete>
+
+This operation uses the same filters as the _list_ operation, with the exception that the only meaningful status codes are _completed_, _terminated_ and _faulted_. A process instance that is in the active, suspended or error state cannot be deleted. Similarly, specifying a process instance has no affect if that instance is not in the _completed_, _terminated_ or _faulted_ state.
+
+The operation returns a message listing all the deleted process instances:
+
+ <delete.response>
+ <instance pid = token/>*
+ </delete.response>
+
Added: ode/site/trunk/content/bpel4ws-11.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/bpel4ws-11.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/bpel4ws-11.mdtext (added)
+++ ode/site/trunk/content/bpel4ws-11.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,5 @@
+Title: BPEL4WS 1.1
+
+*BPEL4WS 1.1* --- {excerpt}the version of the BPEL [specification](http://www-128.ibm.com/developerworks/library/ws-bpel/) originally developed by a vendor consortium and then submitted to OASIS in May 2003{excerpt}.
+
+A [documented](http://www.fivesight.com/docs/schemadocs/WS-BPEL-1_1-200303.html) version of the BPEL4WS 1.1 schema is available.
Added: ode/site/trunk/content/bpelc-command.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/bpelc-command.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/bpelc-command.mdtext (added)
+++ ode/site/trunk/content/bpelc-command.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,32 @@
+Title: bpelc Command
+The `bpelc` commandline tool {excerpt}compiles [BPEL4WS 1.1](bpel4ws-1.1.html) or [WS-BPEL 2.0] processes for execution by the ODE runtime engine.{excerpt}
+
+<a name="bpelcCommand-Synopsis"></a>
+## Synopsis
+bpelc [-q](-v|-vv.html) [-o directory] [-rr rrfile] [-wsdl uri] url ... url
+
+<a name="bpelcCommand-Description"></a>
+## Description
+
+The `bpelc` commandline tool compiles BPEL processes (either 1.1 or 2.0) for execution by the PXE runtime engine. The compiler will automatically detect the version of the process and configure itself appropriately. For comparison, the [`<bpelc>` Task](bpelc-task.html) performs the same operation, and the BPEL compiler can be used directly.
+
+For more information about the BPEL compiler, see [Compiler Toolchain](compiler-toolchain.html).
+
+<a name="bpelcCommand-Options"></a>
+## Options
+
+<table>
+<tr><th>Option/Argument</th><th>Effect</th></tr>
+<tr><td>`-o directory`</td><td>the directory to write the output files to.</td></tr>
+<tr><td>`-rr rrfile`</td><td>the filename of the [ZIP resource repository](zip-resource-repository.html) to read WSDL definitions from. If this parameter is not specified, the compiler will dereference URIs directly as URLs.</td></tr>
+<tr><td>`-wsdl uri`</td><td>for [BPEL4WS 1.1](bpel4ws-1.1.html) processes, the [URI] of WSDL definitions to include from the [ZIP resource repository]. This hint is ignored for [WS-BPEL 2.0] processes in favor of the `<bpel:import>` mechanism.</td></tr>
+<tr><td>`url ... url`</td><td>the [URL](url.html)s of BPEL process definitions to be compiled.</td></tr>
+<tr><td>`-q\</td><td>v\</td><td>-vv`</td><td>adjust the verbosity of logging output. See [Configuring Commandline Launchers](configuring-commandline-launchers.html).</td></tr>
+<tr><td>`-h`</td><td>prints a synopsis to the console and exits.</td></tr>
+</table>
+
+<div class="alert alert-tip">
+ You have to use the full path for the bpel process file, like:
+ *./bpelc ./HelloWorld.bpel*, not -./bpelc HelloWorld.bpel-
+</div>
+
Added: ode/site/trunk/content/bpelc-task.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/bpelc-task.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/bpelc-task.mdtext (added)
+++ ode/site/trunk/content/bpelc-task.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,39 @@
+Title: bpelc Task
+
+
+
+The `<bpelc>` Ant task {excerpt}compiles [BPEL4WS 1.1](bpel4ws-1.1.html) and [WS-BPEL 2.0] processes for execution by PXE.{excerpt}
+
+<a name="bpelcTask-Synopsis"></a>
+## Synopsis
+
+ <bpelc [rr="rrfile"] [targetDir="directory"]>
+ <wsdl uri="uri" />?
+ <bpel url="url" />+
+ </bpelc>
+
+
+<a name="bpelcTask-Description"></a>
+## Description
+The `<bpelc>` task is used to compile one or more XML process descriptions into a form executable by the PXE engine. Zero or more nested `<wsdl>` elements specify WSDL definitions (by URI) to be imported from the specified [resource repository](resource-repository.html), and one of more `<bpel>` elements specify the process definitions (by URL) to be compiled.
+
+<div class="alert alert-tip"><h4 class="alert-heading">Naming Convention</h4>
+
+ h2. Attributes and Subelements
+ h3. {{<bpelc>}} Attributes
+ ||Attribute||Purpose||
+ |{{rr}}|the path to the [resource repository] from which to read WSDL definitions and any other imported artifacts. If not supplied, the task will construct a temporary resource repository by dereferencing URIs directly as URLs.|
+ |{{targetDir}}|the directory into which the compiled files will be written. The default, if no other value is specified, is the current working directory.|
+
+ h3. Nested {{<wsdl>}} Element and Attributes
+ A nested {{<wsdl>}} element defines a WSDL import for use by the compiler in compiling a [BPEL4WS 1.1] process. This hint is ignored for a [WS-BPEL 2.0] process in favor of the {{<import.../>}} construct.
+
+ ||Attribute||Purpose||
+ |{{uri}}|a URI (within the resource repository) that can be dereferenced to obtain the WSDL definitions.|
+
+ h3. Nested {{<bpel>}} Element and Attributes
+ A nested {{<bpel>}} element defines a [BPEL4WS 1.1] or [WS-BPEL 2.0] process definition to be compiled. At least one {{<bpel>}} element must be supplied.
+
+ ||Attribute||Purpose||
+ |{{url}}|the URL from which to load the process definition.|
+
Added: ode/site/trunk/content/building-ode.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/building-ode.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/building-ode.mdtext (added)
+++ ode/site/trunk/content/building-ode.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,75 @@
+Title: Building ODE
+Building from the source is usually for the thick skinned, we try to keep our trunk stable but it's a development environment so we can never guarantee that everything will be smooth. If you rather work with something more stable or if you don't need the latest and greatest, using the [latest official distribution](getting-ode.html) is probably a better option.
+
+<a name="BuildingODE-Gettingthesourcecode"></a>
+#### Getting the source code
+
+<a name="BuildingODE-withSubversion"></a>
+##### with Subversion
+
+First you will have to make sure that you have [Subversion](http://svn.tigris.org). If you don't know what Subversion is or don't have it installed, check [here|http://svnbook.red-bean.com]. Once installed run:
+
+Development branch:
+
+
+ $> svn checkout http://svn.apache.org/repos/asf/ode/trunk ode-trunk
+
+
+For more information or if you have any problem with Subversion (like being behind a proxy or a firewall) check the [Source Code](source-code.html) section.
+
+<a name="BuildingODE-withGit"></a>
+##### with Git
+
+The Subversion repository is mirrored by a Git repository at: http://github.com/apache/ode.
+So if you're more comfortable with Git, you can clone this repo.
+
+ $> git clone http://github.com/apache/ode
+ $> cd ode
+ $> git checkout -b 1.X --track origin/trunk
+
+
+<a name="BuildingODE-BuildingWithBuildr"></a>
+#### Building With Buildr
+
+ODE uses [Apache Buildr](http://buildr.apache.org). Buildr has a very detailed [installation guide|http://buildr.apache.org/installing.html], so refer to it to get Buildr working on your machine.
+The latest known working configuration for trunk (both for windows, linux, macos with JDK 1.5 and JDK 1.6) is buildr 1.4.4, jruby 1.5.1 (ruby 1.8.7 patchlevel 174).
+
+Building is then pretty simple.
+
+<div class="alert alert-info"><h4 class="alert-heading">Version Information</h4>
+ The trunk must be build with Buildr *1.4.4* or higher
+</div>
+
+Open a command in the source root directory and run:
+
+
+ buildr package test=no
+
+
+To try the test cases bundled with ODE:
+
+
+ buildr test
+
+
+You are very welcome to contribute by running test cases and posting spotted errors into [mailing list](http://ode.apache.org/mailing-lists.html).
+
+To generate Eclipse project files:
+
+
+ buildr eclipse
+
+
+<div class="alert alert-info">
+ You may use "buildr \_1.4.4\_ test" - like syntax to use specific buildr version.
+</div>
+
+It just works! For more information about Buildr see http://buildr.apache.org/.
+
+<a name="BuildingODE-Troubleshooting"></a>
+#### Troubleshooting
+
+* If you get a Zlib:BufError, that's because of your version of Rubygems, just upgrade RubyGems by typing:
+
+ gem update --system
+
Added: ode/site/trunk/content/commandline-tools.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/commandline-tools.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/commandline-tools.mdtext (added)
+++ ode/site/trunk/content/commandline-tools.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,11 @@
+Title: Commandline Tools
+
+
+
+PXE includes a set of commandline tools for manipulating artifacts, deploying PXE systems, and managing runtime process instances.
+
+{children:depth=1|excerpt=true}
+
+The commandline tools are all configured using a launcher script (`.sh` for Cygwin, UNIX, or variants and `.bat` for Windows) and an additional configuration file (`.cfg`). For more information about launcher configuration, see [Configuring Commandline Launchers](configuring-commandline-launchers.html).
+
+{excerpt:hidden=true}a set of commandline tools for creating and managing PXE-related artifacts.{excerpt}
Added: ode/site/trunk/content/compensate.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/compensate.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/compensate.mdtext (added)
+++ ode/site/trunk/content/compensate.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1 @@
+Title: compensate
Added: ode/site/trunk/content/contributors.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/contributors.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/contributors.mdtext (added)
+++ ode/site/trunk/content/contributors.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,25 @@
+Title: Contributors
+<a name="Contributors-Committers"></a>
+## Committers
+
+Here is the list of people who are actively working and committing on Ode.
+
+<table>
+<tr><th> Name </th><th> ID </th><th> Organization </th><th> Role </th></tr>
+<tr><td> Assaf Arkin </td><td> arkin </td><td> [Intalio](http://www.intalio.com) </td><td> Developer & PMC </td></tr>
+<tr><td> Alex Boisvert </td><td> boisvert </td><td> [Intalio](http://www.intalio.com) </td><td> Developer & PMC </td></tr>
+<tr><td> Alexis Midon </td><td> midon </td><td> [Intalio](http://www.intalio.com) </td><td> Developer & PMC </td></tr>
+<tr><td> [Tammo van Lessen](http://www.taval.de) </td><td> vanto </td><td> </td><td> Developer & PMC Chair </td></tr>
+<tr><td> Guillaume Nodet </td><td> gnodet </td><td> [Iona](http://www.iona.com) </td><td> Developer & PMC </td></tr>
+<tr><td> [Matthieu Riou](http://offthelip.org/) </td><td> mriou </td><td> [Intalio</td><td>http://www.intalio.com] </td><td> Developer & PMC </td></tr>
+<tr><td> [RafaÅ Rusin](http://rrusin.blogspot.com) </td><td> rr </td><td> [TouK</td><td>http://www.touk.pl] </td><td> Developer & PMC </td></tr>
+<tr><td> Maciej Szefler </td><td> mszefler </td><td> [Intalio](http://www.intalio.com) </td><td> Developer & PMC </td></tr>
+<tr><td> Lance Waterman </td><td> lwaterman </td><td> [Sybase](http://www.sybase.com) </td><td> Developer & PMC </td></tr>
+<tr><td> [Jeff Yu ](http://jeff.familyyu.net)</td><td>jeffyu</td><td>[JBoss</td><td>http://www.jboss.com]</td><td>Developer & PMC </td></tr>
+</table>
+
+
+<a name="Contributors-Sponsors"></a>
+## Sponsors
+
+[YourKit](http://www.yourkit.com/) has graciously provided YourKit Java Profiler licenses to support our performance and quality efforts. We've had a wonderful experience using their tool -- we were able to quickly and accurately find the cause of some issues in Ode -- and definitely recommend using it while building your own software.
Added: ode/site/trunk/content/copy-with-insert-attribute.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/copy-with-insert-attribute.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/copy-with-insert-attribute.mdtext (added)
+++ ode/site/trunk/content/copy-with-insert-attribute.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,151 @@
+Title: copy with insert attribute
+<a name="copywithinsertattribute-<bpel:copy>withinsertattribute"></a>
+## <bpel:copy> with insert attribute
+
+<div class="alert alert-warning">
+ This is a proposal for a BPEL extension (non-standard); This proposal is not yet implemented in Ode. See http://issues.apache.org/jira/browse/ODE-145 for current status information.
+</div>
+
+Consider a simple use case. A BPEL process collects quotes from a number of suppliers, to determine which one provides the best price, before submitting an order to that supplier. Typically this will be done using the <bpel:foreach> activity, collecting information from each quote into a variable, and later on extracting a specific node from that variable, e.g. using XPath predicate to select the supplier with the lowest price.
+
+BPEL does not support array variables, but we can use XML structures as collections. However, updating a collection to add a new element requires either using a different assignment mechanism ( e.g. XUpdate, not on the roadmap), or performing a copy-append-replace transformation, using XPath 2.0 or XSLT. But the later approach is complicated, obfuscated and fragile.
+
+Instead, we're opting for a simpler mechanism that allows BPEL assignments to both replace and insert content. We introduce an `insert` attribute on the <bpel:copy> element. If the attribute is absent, the assignment performs a replacement, as per the BPEL 2.0 specification.
+
+Syntax:
+
+ <bpel:assign>
+ <bpel:copy insert="..."?>
+ <bpel:from> ... </bpel:from>
+ <bpel:to> ... </bpel:to>
+ </bpel:copy>
+ </bpel:assign>
+
+
+The insert attribute can take one of four values:
+
+* `first` -- The copy/to must select an EII. The value selected by the copy/from is then inserted as the first node inside that EII.
+* `last` -- The copy/to must select an EII. The value selected by the copy/from is then inserted as the last node inside that EII.
+* `before` -- The copy/to must select an EII or TII. The value selected by the copy/from is then inserted as a node preceding that EII/TII.
+* `after` -- The copy/to must select an EII or TII. The value selected by the copy/from is then inserted as a node proceeding that EII/TII.
+
+For `first` and `last`, <bpel:to> must return an EII or throw a `selectionFailure`. For `before` and `after`, <bpel:to> must return an EII or TII or throw a `selectionFailure`. In all four cases, <bpel:from> must select some value or a node, or throw a `selectionFailure`.
+
+<a name="copywithinsertattribute-Example:Last"></a>
+### Example: Last
+
+Let $foo be a complex element with value
+
+
+ <foo>
+ <bar1/>
+ <bar2/>
+ </foo>
+
+
+Performing this assignment,
+
+
+ <bpel:copy insert="last">
+ <bpel:from>
+ <bpel:literal>
+ <bar3/>
+ </bpel:literal>
+ </bpel:from>
+ <bpel:to> $foo </bpel:to>
+ </bpel:copy>
+
+
+results in $foo
+
+
+ <foo>
+ <bar1/>
+ <bar2/>
+ <bar3/> <!-- INSERTED -->
+ </foo>
+
+
+<a name="copywithinsertattribute-Example:First"></a>
+### Example: First
+
+Continuing with the previous value of $foo,
+
+
+ <bpel:copy insert="first">
+ <bpel:from>
+ <bpel:literal>
+ <bar0/>
+ </bpel:literal>
+ </bpel:from>
+ <bpel:to> $foo </bpel:to>
+ </bpel:copy>
+
+
+results in $foo
+
+
+ <foo>
+ <bar0/> <!-- INSERTED -->
+ <bar1/>
+ <bar2/>
+ <bar3/>
+ </foo>
+
+
+<a name="copywithinsertattribute-Example:Before"></a>
+### Example: Before
+
+Continuing with the previous value of $foo,
+
+
+ <bpel:copy insert="before">
+ <bpel:from>
+ <bpel:literal>
+ <baz/>
+ </bpel:literal>
+ </bpel:from>
+ <bpel:to> $foo/bar1 </bpel:to> <!-- Insert before "bar1" -->
+ </bpel:copy>
+
+
+results in $foo
+
+
+ <foo>
+ <bar0/>
+ <baz/> <!-- INSERTED -->
+ <bar1/>
+ <bar2/>
+ <bar3/>
+ </foo>
+
+
+<a name="copywithinsertattribute-Example:After"></a>
+### Example: After
+
+Continuing with the previous value of $foo,
+
+
+ <bpel:copy insert="before">
+ <bpel:from>
+ <bpel:literal>
+ <bam/>
+ </bpel:literal>
+ </bpel:from>
+ <bpel:to> $foo/bar2 </bpel:to> <!-- Insert after "bar2" -->
+ </bpel:copy>
+
+
+results in $foo
+
+
+ <foo>
+ <bar0/>
+ <baz/>
+ <bar1/>
+ <bar2/>
+ <bam/> <!-- INSERTED -->
+ <bar3/>
+ </foo>
+
Added: ode/site/trunk/content/creating-a-process.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/creating-a-process.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/creating-a-process.mdtext (added)
+++ ode/site/trunk/content/creating-a-process.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,159 @@
+Title: Creating a Process
+ * [Deploying a Process in Ode](#CreatingaProcess-DeployingaProcessinOde)
+ * [Deployment Descriptor](#CreatingaProcess-DeploymentDescriptor)
+ * [Formal definition](#CreatingaProcess-Formaldefinition)
+ * [Examples](#CreatingaProcess-Examples)
+ * [Additional settings](#CreatingaProcess-Additionalsettings)
+ * [In memory execution](#CreatingaProcess-Inmemoryexecution)
+ * [User-defined process properties](#CreatingaProcess-User-definedprocessproperties)
+
+<a name="CreatingaProcess-DeployingaProcessinOde"></a>
+### Deploying a Process in Ode
+
+Each deployment is a directory with all relevant deployment artifacts. At the minimum it will contain the deployment descriptor, one or more process definitions (BPEL or .cbp), WSDL and XSDs (excluding those compiled into the .cbp). It may also contain other files, such as SVGs or XSLs. The deployment descriptor is a file named deploy.xml (see the next paragraoh for its description).
+
+During deployment, the process engine loads all documents from the deployment descriptor. Loading documents allow it to reference processes, service and schema definitions using fully qualified names, and import based on namespaces instead of locations.
+
+To deploy in Ode, just copy the whole directory containing your artifacts (the directory itself, not only its content) in the path %DEPLOYMENT_ROOT%/WEB-INF/processes (in Tomcat it would be %TOMCAT_HOME%/webapps/ode/WEB-INF/processes).
+
+<a name="CreatingaProcess-DeploymentDescriptor"></a>
+### Deployment Descriptor
+
+To deploy your process in Ode you will need to create a simple deployment descriptor with basic information. The deploy.xml file configures one or several processes to use specific services. For each process, deploy.xml must supply binding information for partner links to concrete WSDL services. Every partner link used with a <receive> activity must be matched with a <provide> element, and every partnerLink used in an <invoke> activity must be matched with an <invoke> element in *deploy.xml* (unless that partnerLink has initializePartnerRole="false").
+
+<a name="CreatingaProcess-Formaldefinition"></a>
+### Formal definition
+
+The XML schema describing ODE's deployment descriptor is available [here](http://svn.apache.org/viewvc/ode/trunk/bpel-schemas/src/main/xsd/dd.xsd?view=markup). The root element, deploy, contains a list of all deployed processes from the deployment directory:
+
+ <deploy>
+ <process ...>*
+ { other elements }
+ </process>
+ </deploy>
+
+Each process is identified by its qualified name and specifies bindings for provided and invoked services:
+
+ <process name = QName fileName = String? bpel11wsdlFileName = String? >
+ (<provide> | <invoke>)*
+ { other elements }
+ </process>
+
+Each process element must provide a `name` attribute with the qualified name of the process. Optionally, a `fileName` attribute can be used to specify the location of the BPEL process definition (the .bpel file). The `fileName` attribute does not need to be provided unless non-standard compilation options are used or the `bpel11wsdlFileName` attribute is used to specify a WSDL document for a BPEL 1.1 process.
+
+Each `<process>` element must enumerate the services provided by the process and bind each service to an endpoint. This is done through `<provide>` elements which associates `partnerLink`s with `endpoint`s:
+
+ <provide partnerLink=NCName>
+ <service name = QName port = NCName?>
+ </provide>
+
+Note, that only one partnerLink can be bound to any specified endpoint.
+
+The port attribute can be used to select a particular endpoint from the service definition.
+
+<a name="CreatingaProcess-Examples"></a>
+#### Examples
+
+A very simple process that would only be invoked would use a deploy.xml very similar to:
+
+
+ <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
+ xmlns:pns="http://ode/bpel/unit-test" xmlns:wns="http://ode/bpel/unit-test.wsdl">
+ <process name="pns:HelloWorld2">
+ <active>true</active>
+ <provide partnerLink="helloPartnerLink">
+ <service name="wns:HelloService" port="HelloPort"/>
+ </provide>
+ </process>
+ </deploy>
+
+
+See the complete example [here](https://svn.apache.org/repos/asf/ode/trunk/distro-axis2/src/examples/HelloWorld2/).
+
+A deployment including two processes invoking each other and whose execution would be triggered by a first message would look like:
+
+
+ <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:main="http://ode/bpel/unit-test"
+ xmlns:mws="http://ode/bpel/unit-test.wsdl" xmlns:resp="http://ode/bpel/responder">
+
+ <process name="main:MagicSessionMain">
+ <provide partnerLink="executePartnerLink">
+ <service name="mws:MSMainExecuteService" port="MSExecutePort"/>
+ </provide>
+ <provide partnerLink="responderPartnerLink">
+ <service name="mws:MSMainService" port="MSMainPort"/>
+ </provide>
+ <invoke partnerLink="responderPartnerLink">
+ <service name="mws:MSResponderService" port="MSResponderPort"/>
+ </invoke>
+ </process>
+ <process name="resp:MagicSessionResponder">
+ <type>resp:MagicSessionResponder</type>
+ <provide partnerLink="mainPartnerLink">
+ <service name="mws:MSResponderService" port="MSResponderPort"/>
+ </provide>
+ <invoke partnerLink="mainPartnerLink">
+ <service name="mws:MSMainService" port="MSMainPort"/>
+ </invoke>
+ </process>
+ </deploy>
+
+
+See the complete example [here](https://svn.apache.org/repos/asf/ode/trunk/distro-axis2/src/examples/MagicSession/).
+
+<a name="CreatingaProcess-Additionalsettings"></a>
+#### Additional settings
+
+<a name="CreatingaProcess-Inmemoryexecution"></a>
+##### In memory execution
+
+For performance purposes, you can define a process as being executed only in-memory. This greatly reduces the amount of generated queries and puts far less load on your database. Both persistent and non-persistent processes can cohabit in Ode.
+
+To declare a process as in-memory just add an in-memory element in your deploy.xml:
+
+
+ <process name="pns:HelloWorld2">
+ <in-memory>true</in-memory>
+ <provide partnerLink="helloPartnerLink">
+ <service name="wns:HelloService" port="HelloPort"/>
+ </provide>
+ </process>
+
+
+Be aware that in-memory executions introduces many restrictions on your process and what it can do. The instances of these processes can't be queried by using the [Management API](management-api.html). The process definition can only include one single receive activity (the one that will trigger the instance creation).
+
+<a name="CreatingaProcess-User-definedprocessproperties"></a>
+##### User-defined process properties
+
+User-defined process properties provide means to configure process models and their instances. They are either statically declared and set in the deployment descriptor `deploy.xml` or can be set using the process management API. All instances of a process model share the same set of process properties. If a process property changes, it changes for all instances.
+
+A process property is identified by a QName and can carry a string as value. To set a process property statically in the deployment descriptor, add the following snippet to your `deploy.xml`:
+
+
+ <process name="pns:HelloWorld2">
+ ...
+ <property xmlns:loan="urn:example" name="loan:loanThreshold">4711</property>
+ ...
+ </process>
+
+
+It is also possible to set or change a property by calling the PM API function `setProcessProperty(final QName pid, final QName propertyName, final String value)`.
+
+Once set, process properties can be used in two different ways:
+ * Using XPath in process models
+ * Using Java in ODE extensions
+
+For instance, instead of hard coding the amount of money that triggers an in-depth check in a loan approval process, you could read a process property instead. That way you can reconfigure your process without having to redeploy the process again.
+
+To read process properties in a BPEL process, you can use the non-standard XPath extension `bpws:process-property(propertyName)`, e.g. in a transition condition or in an assign activity:
+
+
+ ...
+ <assign>
+ <copy>
+ <from xmlns:loan="urn:example">bpws:process-property(loan:loanThreshold)</from>
+ <to>$threshold</to>
+ </copy>
+ </assign>
+ ...
+
Added: ode/site/trunk/content/ddvalidate-command.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/ddvalidate-command.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/ddvalidate-command.mdtext (added)
+++ ode/site/trunk/content/ddvalidate-command.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,22 @@
+Title: ddvalidate Command
+
+
+
+The `ddvalidate` command {excerpt}validates a [system deployment descriptor](system-deployment-descriptor.html) with or without supporting WSDL definitions.{excerpt}
+
+<a name="ddvalidateCommand-Synopsis"></a>
+## Synopsis
+
+ ddvalidate -h{noformat}
+
+ h2. Description
+ The {{ddvalidate}} command validates a [system deployment descriptor] contained in a local file.
+
+ {tip}The [{{sarcreate}}|sarcreate Command] command and [{{<pxe-sar>}}|pxe-sar Task] task also validate the [system deployment descriptor] when assembling an [system deployment archive], but {{ddvalidate}} is included so that the validation can be performed in a standalone fashion.{tip}
+
+ h2. Options
+ ||Option/Argument||Effect||
+ |{{ddfile}}|the filename of the [system deployment descriptor].|
+ |{{rrfile}}|the filename of a [resource repository] containing the root WSDL definitions for the system. If this argument is not supplied, the command only performs schema-level validation of the descriptor. If this argument is supplied, the command performs additional validations, e.g., that WSDL port types referenced in the descriptor are properly declared.|
+ |{{-q\|-v\|-vv}}|adjust the verbosity of logging output. See [Logging and Output from Commandline Tools].|
+ |{{-h}}|prints a synopsis to the console and exits.|
Added: ode/site/trunk/content/deployment-unit.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/deployment-unit.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/deployment-unit.mdtext (added)
+++ ode/site/trunk/content/deployment-unit.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1 @@
+Title: deployment unit
Added: ode/site/trunk/content/deployxml.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/deployxml.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/deployxml.mdtext (added)
+++ ode/site/trunk/content/deployxml.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,2 @@
+Title: deploy.xml
+The `deploy.xml` file is {excerpt} an XML deployment descriptor used to configure an ODE [deployment unit](deployment-unit.html){excerpt}.
Added: ode/site/trunk/content/developer-guide.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/developer-guide.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/developer-guide.mdtext (added)
+++ ode/site/trunk/content/developer-guide.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,16 @@
+Title: Developer Guide
+<a name="DeveloperGuide-GeneralDocumentation"></a>
+## General Documentation
+
+These documents are intended for those of you wanting an in-depth look into Ode. You'll learn a bit more about our Web Services interfaces, our internal interfaces and how the engine works.
+
+* [Architectural Overview](architectural-overview.html)
+* Ode's virtual machine: [Jacob](jacob.html)
+* Notes about using [Eclipse IDE](eclipse-ide.html) with Apache Ode
+* [Release Guidelines](release-guidelines.html)
+
+<a name="DeveloperGuide-Specifications"></a>
+## Specifications
+
+* [Stateful Exchange Protocol](stateful-exchange-protocol.html) Protocol for handling stateful interactions (aka automagic correlation).
+* [Atomic Scopes Extension for BPEL](atomic-scopes-extension-for-bpel.html)
Added: 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=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/direct-process-to-process-communication.mdtext (added)
+++ ode/site/trunk/content/direct-process-to-process-communication.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,2 @@
+Title: Direct Process-to-Process Communication
+Ode automatically optimizes all process-to-process communication such that all message exchanges happen directly inside the engine and do not go through the integration layer (e.g. Axis2, JBI, ...).
Added: ode/site/trunk/content/eclipse-ide.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/eclipse-ide.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/eclipse-ide.mdtext (added)
+++ ode/site/trunk/content/eclipse-ide.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,41 @@
+Title: Eclipse IDE
+<a name="EclipseIDE-DevelopingOdewiththeEclipseIDE"></a>
+## Developing Ode with the Eclipse IDE
+
+First, be sure to read [Building ODE](building-ode.html) to learn how to install Ruby, Rake and Buildr.
+
+
+<a name="EclipseIDE-1.BuildOde"></a>
+### 1. Build Ode
+
+At the root of the checkout, run
+
+ buildr package
+
+
+<a name="EclipseIDE-2.GeneratetheEclipseprojectfiles"></a>
+### 2. Generate the Eclipse project files
+
+Still in the root,
+
+ buildr eclipse
+
+
+<a name="EclipseIDE-3.ImportprojectsfilesintoEclipse"></a>
+### 3. Import projects files into Eclipse
+
+In Eclipse,
+
+ File -> Import -> Existing Projects into Workspace
+
+then select the root directory of your Ode checkout (e.g. ode/trunk)
+
+It's generally recommended to have a dedicated Eclipse workspace for Ode, since there's a fair amount of code and projects.
+
+<a name="EclipseIDE-RandomNotes"></a>
+### Random Notes
+
+* You must use JDK 5.0 compiler
+* You may need to exclude .svn directories to avoid duplicate resource copying.
+* You must define the M2_REPO classpath variable to point to your local Maven2 repository (Window -> Preference -> Java -> Build Path -> Classpath Variables)
+* Be ware that there are quite a few things in the Buildr-based build that are not done by the Eclipse build system. You will occasionally need to run "rake" build in order to regenerate XMLBeans schemas, OpenJPA mapping files, JACOB channel interfaces, etc...
Added: ode/site/trunk/content/endpoint-configuration.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/endpoint-configuration.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/endpoint-configuration.mdtext (added)
+++ ode/site/trunk/content/endpoint-configuration.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,209 @@
+Title: Endpoint Configuration
+<a name="EndpointConfiguration-endpointconfigurationpropertyfiles"></a>
+### 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
+
+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`
+* the process deployment directory, `ode/WEB-INF/processes/$your_process`
+
+Two rules of precedence apply:
+1. Endpoint files in a same directory are loaded in alphabetical order. Meaning that if a property is set in two different files, the value from the "greatest" file name will have precedence.
+1. Endpoint files located in the global conf directory have precedence over files in process deployment directories.
+
+<div class="alert alert-info"><h4 class="alert-heading">Version Information</h4>
+ This feature is available in ODE > 1.1. For version 1.1, a file named endpoint-configuration.properties may be dropped in process deployment unit directories. For backward compatibility, ODE > 1.1 supports this file too.
+</div>
+
+<a name="EndpointConfiguration-Dynamicrefresh"></a>
+#### Dynamic refresh
+
+Properties are dynamically loaded and refreshed at run time.
+The timing is the following:
+On every request, if the file has not been polled during the last 30 seconds then check the file for updates. If any, reload it.
+
+Consequently, if you have updated properties, you have to wait ~30 seconds and then trigger a request.
+
+
+<a name="EndpointConfiguration-Hierarchicalproperties"></a>
+#### 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:
+
+ [nsalias.servicename[.portname].ode.]property
+
+
+If service name is mentioned but port name omitted, the value will apply to all ports of the service.
+If service name and port name are omitted, the value will apply to all services.
+
+<a name="EndpointConfiguration-Namespacemanagement"></a>
+##### Namespace management
+
+A service has to be qualified. To so do you may define namespace aliases. Aliases will then prefixed the service local name.
+
+
+ alias.ode_ns=http://ode.apache.org
+
+ ode_ns.dummyservice.ode.http.request.chunk=true
+
+
+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:
+
+
+ # Next line is commented
+ # alias.ode_ns=http://ode.apache.org
+
+ ode_ns.dummyservice.ode.http.request.chunk=true
+
+
+
+<a name="EndpointConfiguration-Examples"></a>
+##### Examples
+
+For instance, considering 2 services:
+* the `foo-service`
+* and the `brel-service` which has 2 ports: `port-of-amsterdam` and `port-of-hiva-oa`
+
+and this property file:
+
+ alias.test_ns=http://test.org
+ http.protocol.max-redirects=5
+
+ test_ns.brel-service.ode.http.protocol.max-redirects=40
+ test_ns.brel-service.port-of-amsterdam.ode.http.protocol.max-redirects=100
+
+
+The `http.protocol.max-redirect` property will have the following values:
+
+* *5* for all ports of `foo-service`
+* *40* for `brel-service.port-of-hiva-oa`
+* *100* for `brel-service.port-of-amsterdam`
+
+<a name="EndpointConfiguration-Supportedproperties"></a>
+#### 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.
+
+ || Context || Property name || Accepted values || Description/Notes ||
+ | Bpel-runtime | mex.timeout | a long | the Ode Message Exchange timeout |
+ | | mex.failure.verbose | true(default)/false | mute the details of a failure that might occur during a process invocation (to avoid information disclosure for instance)|
+
+
+ | | http.request.chunk | true/false | This will enable/disable chunking support. Will not apply to http-bound services TBD |
+ | | http.protocol.version | HTTP/1.1 or HTTP/1.0 | the HTTP protocol version used |
+ | | http.request.gzip | true/false | Will not apply to http-bound services TBD |
+ | | http.accept.gzip | true/false | Append gzip to the Accept-Encoding header |
+ | | http.protocol.content-charset| a string | |
+ | | http.default-headers.\{your-header\} | | You must define one property per header, prefixed with 'http.default-headers'.
+ These values will be appended to any previous value already set for a given header. |
+ | | http.connection.timeout | an int | timeout in milliseconds until a connection is etablished |
+ | | http.socket.timeout | an int | timeout in milliseconds for waiting for data |
+ | | http.protocol.max-redirects | an int | the maximum number of redirects to be followed |
+ | | http.proxy.host=myproxy.org | | To disable proxy set the host to null |
+ | | http.proxy.port | | |
+ | | http.proxy.domain | | |
+ | | http.proxy.user | | |
+ | | http.proxy.password | | |
+ | | jms.reply.destination | a string | the reply-to destination in an outbound message |
+ | | jms.reply.timeout | an int | timeout in milliseconds for waiting for two-way reply |
+ | | ws-adddressing.headers | true(default)/false | Enable/disable the WS-Addressing headers for outgoing soap requests |
+
+<a name="EndpointConfiguration-Samplefile"></a>
+#### Sample file
+
+[^sample.endpoint.txt](^sample.endpoint.txt.html)
+
+Download, remove the '.txt' prefix, customize then enjoy...
+
+
+<a name="EndpointConfiguration-ImplementationDetailsforOutboundservices"></a>
+#### 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)
+
+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.
+
+<table>
+<tr><th> Property name </th><th> Axis2 </th><th> Description/Notes </th></tr>
+ | http.request.chunk | Options.setProperty(HTTPConstants.CHUNKED, ?) | |
+ | http.protocol.version | Options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, ?)| |
+ | http.request.gzip | Options.setProperty(HTTPConstants.MC_GZIP_REQUEST, ?) | |
+ | http.accept.gzip | Options.setProperty(HTTPConstants.MC_ACCEPT_GZIP, ?)| |
+ | http.protocol.content-charset| Options.setProperty(Constants.Configuration.CHARACTER_SET_ENCODING,?) | |
+ | http.default-headers.* | Options.setProperty(HTTPConstants.HTTP_HEADERS, ?) | |
+ | http.connection.timeout | Options.setProperty(HTTPConstants.CONNECTION_TIMEOUT, ?)| |
+ | http.socket.timeout | Options.setProperty(HTTPConstants.SO_TIMEOUT, ?)| |
+ | http.protocol.max-redirects | | not applied to Axis2 services |
+ | http.proxy.* | Options.setProperty(HTTPConstants.PROXY, ?); | |
+ | jms.reply.destination | Options.setProperty(JMSConstants.REPLY_PARAM, ?); | |
+ | jms.reply.timeout| Options.setProperty(JMSConstants.JMS_WAIT_REPLY, ?); | |
+</table>
+
+<a name="EndpointConfiguration-HTTPServices(HttpClient)"></a>
+##### 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.
+If a given property is not listed below, you are still able to set it as long as the expected value is a string. For instance ["http.protocol.cookie-policy"](http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/params/HttpMethodParams.html#COOKIE_POLICY) can be set seamlessly.
+
+ || Property name || HttpClient|| Description/Notes ||
+ | http.request.chunk | EntityEnclosingMethod.setContentChunked() | |
+ | http.protocol.version | HttpParams.setParameter(HttpMethodParams.PROTOCOL_VERSION, ?)| |
+ | http.request.gzip | | _not supported_ |
+ | http.accept.gzip | | _not supported_ |
+ | http.protocol.content-charset| HttpParams.setParameter(HttpMethodParams.HTTP_CONTENT_CHARSET,?) | |
+ | http.default-headers.* | HttpParams.setParameter(HTTPConstants.HTTP_HEADERS, ?) | |
+ | http.connection.timeout | HttpParams.setParameter(HttpConnectionParams.CONNECTION_TIMEOUT, ?)| |
+ | http.socket.timeout | HttpParams.setParameter(HttpMethodParams.SO_TIMEOUT, ?)| |
+ | http.protocol.max-redirects | HttpParams.setParameter(HttpClientParams.MAX_REDIRECTS, ?)| |
+ | http.proxy.* | | Cannot be set with simple properties. Custom code added. |
+
+
+<a name="EndpointConfiguration-AdditionalConfigurationforSOAPEndpoints"></a>
+### Additional Configuration for SOAP Endpoints
+
+If you deploy ODE in an application server, the [Axis2 Integration Layer](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\`}.
+
+
+For example, given this wsdl:
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <wsdl:definitions ...>
+ <wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">A sample Time service</wsdl:documentation>
+ ...
+ <wsdl:service name="TimeService">
+ <wsdl:port name="TimeServiceSoap" binding="tns:TimeServiceSoap">
+ <soap:address location="http://ws.intalio.com/TimeService/" />
+ </wsdl:port>
+ </wsdl:service>
+ </wsdl:definitions>
+
+
+You would place a `TimeService.axis2` file with:
+
+ <service name="TimeService" scope="application" targetNamespace="http://ws.intalio.com/TimeService/">
+ <module ref="sandesha2" />
+ <module ref="addressing" />
+ </service>
+
+This will engage Engage sandesha2 and addressing modules.
+
+On every request, if the config file has not been polled during the last 30 seconds then check the file for changes and (re)load it if any.
+
+For further details about the type of parameters that can be set, see [Axis2 Service Config](http://ws.apache.org/axis2/1_0/axis2config.html#Service_Configuration).
+
+This mechanism is available for external SOAP services -- i.e. services that processes invoke -- and for SOAP services exposed by ODE -- i.e. services exposed by BPEL processes.
+
+The `service.xml` could be quite powerful. However all options are not accessible this way. Many settings are available programmatically only using the [Options class.](-http://ws.apache.org/axis2/1_3/api/org/apache/axis2/client/options.html.html). ODE exposes these settings through an additional property file described in the previous section.
+
Added: ode/site/trunk/content/endpoint-references.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/endpoint-references.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/endpoint-references.mdtext (added)
+++ ode/site/trunk/content/endpoint-references.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,163 @@
+Title: Endpoint References
+<a name="EndpointReferences-Introduction"></a>
+### Introduction
+An endpoint reference holds information to call a service. The simplest endpoint reference is usually an URL but it can also be much more complex such as holding a message id, a reply-to address or custom properties.
+
+In BPEL, endpoint references (aka EPRs) are modeled as partner link roles. When defining a partner link, two roles maybe defined, `myRole` and `partnerRole`:
+
+
+ <partnerLink name="responderPartnerLink" partnerLinkType="test:ResponderPartnerLinkType"
+ myRole="main" partnerRole="responder" initializePartnerRole="yes"/>
+
+
+Both `partnerRole` and `myRole` represent EPRs. So when assigning partner link roles or invoking partners, you are using EPRs behind the scene.
+
+<a name="EndpointReferences-ODEandEndpointReferences"></a>
+### ODE and Endpoint References
+
+<a name="EndpointReferences-TypesofEPRs"></a>
+#### Types of EPRs
+
+The ODE runtime supports 4 types of EPRs:
+
+* A simple URL or a URL in the location attribute of the binding. See [soap:address](http://www.w3.org/TR/wsdl#_soap:address) and [http:address|http://www.w3.org/TR/wsdl#_http:address] WSDL 1.1 binding.
+* A [WS-Addressing](http://www.w3.org/TR/ws-addr-core/) [EndpointReference|http://www.w3.org/TR/ws-addr-core/#eprinfomodel].
+* A [WSDL 1.1](http://www.w3.org/TR/wsdl) [service element|http://www.w3.org/TR/wsdl#_services].
+* A [WSDL 2.0](http://www.w3.org/TR/wsdl20/) [endpoint element|http://www.w3.org/TR/wsdl20/#Endpoint].
+
+We recommend the two first solutions to interact with the engine. The first one is just the easiest and for the case where you need more robustness, WS-Addressing is the most popular second choice.
+
+To show you how these EPRs look like and how they can be assigned to partner links roles here are some examples:
+
+
+ <assign>
+
+ <!-- Simple URL, without the wrapper -->
+ <copy>
+ <from>
+ <literal>http://localhost:8080/ode/dynresponder</literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ <!-- Simple URL, wrapped in an soap:address element -->
+ <copy>
+ <from>
+ <literal>
+ <service-ref>
+ <soap:address location="http://localhost:8080/ode/dynresponder"/>
+ </service-ref>
+ </literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ <!-- WS-Addressing EPR, without the wrapper -->
+ <copy>
+ <from>
+ <literal>
+ <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
+ <wsa:To>http://localhost:8080/ode/dynresponder</wsa:To>
+ </wsa:EndpointReference>
+ </literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ <!-- WS-Addressing EPR, with the wrapper -->
+ <copy>
+ <from>
+ <literal>
+ <service-ref>
+ <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
+ <wsa:To>http://localhost:8080/ode/dynresponder</wsa:To>
+ </wsa:EndpointReference>
+ <service-ref>
+ </literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ <!-- WSDL1.1 EPR, without the wrapper -->
+ <copy>
+ <from>
+ <literal>
+ <wsdl:service xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" name="DynService" targetNamespace="http://org.apache.ode/examples/dynservice">
+ <wsdl:port name="DynPort">
+ <soap:address location="http://localhost:8080/ode/dynresponder"/>
+ </wsdl:port>
+ </wsdl:service>
+ </literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ <!-- WSDL2.0 EPR, with the wrapper -->
+ <copy>
+ <from>
+ <literal>
+ <service-ref>
+ <wsdl:service xmlns:wsdl="http://www.w3.org/2006/01/wsdl" name="DynService" targetNamespace="http://org.apache.ode/examples/dynservice">
+ <wsdl:port name="DynPort">
+ <soap:address location="http://localhost:8080/ode/dynresponder"/>
+ </wsdl:port>
+ </wsdl:service>
+ </service-ref>
+ </literal>
+ </from>
+ <to partnerLink="responderPartnerLink"/>
+ </copy>
+
+ </assign>
+
+
+Normally BPEL requires wrapping EPRs with inside a `service-ref` element, however ODE relaxes this requirement for ease of use and increased interoperability with existing services. If the `service-ref` element is absent, the EPR is automatically wrapped inside one on the fly. Moreover, ODE automatically detects the different EPR types when assigning to a partner link role. If you need to use WS-Addressing sessions (@see appropriate page), then you will have to use `wsa:EndpointReference` EPRs.
+
+You can just as well assign EPRs to/from variables to pass them around and enable more dynamic communication patterns.
+
+<a name="EndpointReferences-PassingEndpointReferences"></a>
+### Passing Endpoint References
+
+To pass endpoint references around and manipulate them, you usually need to assigne them to variables. The EPR can then be sent in a message and reassigned to another partner link. This lets you model complex scenarii where you don't know the address of your partner beforehand or where you select one partner among many others.
+
+The type of the variable that will hold your EPR defines the type of the EPR that it will contain. For example if you define a message in your WSDL document that looks like this:
+
+
+ <wsdl:message name="EndpointMessage">
+ <wsdl:part name="payload" element="xsd:string"/>
+ </wsdl:message>
+
+
+ODE will automatically put a simple URL EPR when you assign this message part:
+
+
+ <variable name="myEndpoint" messageType="resp:EndpointMessage"/>
+ ...
+ <assign>
+ <copy>
+ <from partnerLink="mainPartnerLink" endpointReference="myRole"/>
+ <to variable="myEndpoint" part="payload"/>
+ </copy>
+ </assign>
+
+
+Now if you want to manipulate a WS-Addressing EPR, the only thing you have to change in the above examples is the message part type. So your message will then look like this:
+
+<wsdl:message name="EndpointMessage">
+ <wsdl:part name="payload" element="wsa:EndpointReference"/>
+</wsdl:message>
+
+Once your EPR has been assigned to a variable and set, say, to another process, you just need to reassign it to a partner link `partnerRole` to use it:
+
+
+ <assign>
+ <copy>
+ <from variable="eprmessage" part="payload"/>
+ <to partnerLink="mainPartnerLink"/>
+ </copy>
+ </assign>
+ <invoke name="eprcall" partnerLink="mainPartnerLink"
+ portType="resp:MSMainPortType" operation="call" inputVariable="eprmessage"/>
+
+
+For a complete example check [DynPartner](http://svn.apache.org/repos/asf/ode/trunk/distro/src/examples-war/DynPartner/) in the engine examples.
Added: ode/site/trunk/content/exported-port.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/exported-port.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/exported-port.mdtext (added)
+++ ode/site/trunk/content/exported-port.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,5 @@
+Title: exported port
+
+
+
+*exported port* --- {excerpt}a [service](service.html) [port] exposing operations implemented by the service{excerpt}. A service with an exported port enacts the operation available on that port (a port is typed with a WSDL port type); a service with an [imported port] (of the same WSDL port type of course) can connect through a [channel] to invoke operations on the service with the exported port.
Added: ode/site/trunk/content/expression-languages.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/expression-languages.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/expression-languages.mdtext (added)
+++ ode/site/trunk/content/expression-languages.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1 @@
+Title: Expression Languages
Added: ode/site/trunk/content/external-variables.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/external-variables.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/external-variables.mdtext (added)
+++ ode/site/trunk/content/external-variables.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,71 @@
+Title: External Variables
+<a name="ExternalVariables-ExternalVariables"></a>
+## External Variables
+
+ * [Declaring External Variables in the Process Definition](#ExternalVariables-DeclaringExternalVariablesintheProcessDefinition)
+ * [Incomplete Keys](#ExternalVariables-IncompleteKeys)
+ * [JDBC Mapping](#ExternalVariables-JDBCMapping)
+ * [REST Mapping](#ExternalVariables-RESTMapping)
+
+<a name="ExternalVariables-DeclaringExternalVariablesintheProcessDefinition"></a>
+### Declaring External Variables in the Process Definition
+
+<div class="alert alert-warning">
+ External variables are only available on Ode 1.2+
+</div>
+
+Syntax:
+
+ <scope>
+ <variables xmlns:xvar=" http://ode.apache.org/externalVariables">
+ <variable name="ext-var-name" element="ext-var-type" xvar:id="ext-var-id">
+ <xvar:key-map key="key-id">*
+ <expression>key-expression</expression>
+ </xvar:key-map>
+ </variable>
+ </variables>
+ </scope>
+
+
+External variables are declared in the `<variables>` section of the `<scope>` element, just like normal variables. However, unlike regular variables, external variables must specify the additional `xvar:id` attribute. This attribute identifies the variable as an external variable and links the external variable's declaration to the external variable's configuration in the deployment descriptor.
+
+In addition to this attribute, an external variable may also define a set of key mappings by nesting `xvar:key-map` elements within the declaration. The key mappings are a collection of name-expression pairs that is used to create a composite key (identity) for the external variable. This composite key is used to retrieve the correct "instance" of the variable from the underlying storage. The key mappings are BPEL expressions ( i.e. XPath expressions) that are evaluated once, at the time that the scope is instantiated. Therefore, the "identity" of an external variable is determined during scope creation, and cannot be changed by the process (for qualifications see Incomplete Keys below).
+
+Finally, any external variables must be of an "element" type, with a schema conforming to the requirements of the underlying storage mechanism.
+
+Consider the following example:
+
+<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.bpel</B></DIV><DIV class="codeContent panelContent">
+ .
+ .
+ .
+ <scope>
+ <variables>
+ <variable name="customer" element="myns:CustomerElement" xvar:id="customer1" >
+ <xvar:key-map key="customer-id">
+ <expression>$order/customerid</expression>
+ </xvar:key-map>
+ </variables>
+ </scope>
+ .
+ .
+ .
+
+
+
+In the above, the "customer" variable is an external variable. The key for the external variable is derived from the value of the `customerid` element in the "order" variable. Note that the "order" variable must be declared in a scope above the scope declaring the "customer" external variable, otherwise it would not be possible to resolve the identify of the "customer" variable. In this scenario, the external variable can be "read" even if it was never assigned to in the process.
+
+<a name="ExternalVariables-IncompleteKeys"></a>
+### Incomplete Keys
+
+It is not required that the full identity of the external variable be resolved at scope creation. For example, an external variable may correspond to a database row where the identity is generated by the database during an insert operation. In such a scenario the key mapping can be omitted, and the identity of the external variable will be unknown until the variable is assigned to. Any attempt to access the variable before the first assignment will result in an uninitialized variable fault. In general it is possible to specify external variables where some portions of the identity are determined using the key mappings and some using some other (implementation-specific) mechanism. In any case, if when the variable is read, the key is incomplete an uninitialized variable fault will result.
+
+<a name="ExternalVariables-JDBCMapping"></a>
+### JDBC Mapping
+
+[External Variables - JDBC Mapping](external-variables---jdbc-mapping.html)
+
+<a name="ExternalVariables-RESTMapping"></a>
+### REST Mapping
+
+[External Variables - REST Mapping](external-variables---rest-mapping.html)
Added: ode/site/trunk/content/faq.mdtext
URL: http://svn.apache.org/viewvc/ode/site/trunk/content/faq.mdtext?rev=1408275&view=auto
==============================================================================
--- ode/site/trunk/content/faq.mdtext (added)
+++ ode/site/trunk/content/faq.mdtext Mon Nov 12 13:06:43 2012
@@ -0,0 +1,4 @@
+Title: FAQ
+
+
+{include:Frequently Asked Questions}