Table of Contents


  1. Preface
  2. Part 1: Using Process Developer
  3. Part 2: Creating and Modifying Processes
  4. Part 3: Functions, Events, Errors, and Correlation
  5. Part 4: Testing and Deployment
  6. Part 5: Process Central and Process Server (On-Premises)

Process Developer

Process Developer

SOAP and Policy-Driven Bindings

SOAP and Policy-Driven Bindings

When you create a Process Deployment Descriptor (PDD), you can select one of the standard bindings for a My Role service. These selections are:
  • SOAP Bindings
  • Policy-Driven Bindings
  • Unpublished

SOAP Bindings

The simplest way to deploy a service endpoint as a Web Service is to select one of the standard SOAP bindings:
  • Document Literal
  • RPC Literal
  • RPC Encoded
You only need to select the binding style and a service name. The SOAP binding elements for the selected style are generated based on the Port Type and Policies associated with the
element in the PDD.
After deployment, Process Server handles the receipt and reply of messages designated for the service endpoint. The messages are formatted and processed by Process Server based on the binding.
Services are deployed to the engine's internal web service provider. Web services are supported by the Metro SOAP stack. (Metro was developed by Sun as a core component of the Glassfish project.)
Both SOAP 1.1 and SOAP 1.2 endpoints are deployed for JAX-WS compliant services (Document Literal and RPC Literal). Legacy bindings such as RPC Encoded are deployed as SOAP 1.1 only.
When a request is received, the URL determines the target service and SOAP version. The last segment of the path corresponds to the service name specified in the PDD:
  • For SOAP 1.1 the URL is:
  • For SOAP 1.2 the URL is:
The WSDL for a deployed web service endpoint is accessible at:
A listing of all deployed web services hosted within the Process Server engine is found at the following URL:
In the Process Console, select the Service Definitions link.
The WSDL that is published for the service includes standard WS-Policy attachments for policy assertions including WS-Addressing and WS-Security.

Policy-Driven Bindings

A policy-driven binding defines how a service is exposed using a policy assertion defined on the
There are many policy assertions, but only the following three can be used as a binding:
  • Referenced WSDL Binding
    : As an alternative to letting the engine generate a SOAP binding based on a given style, you can reference a specific SOAP binding in WSDL by using a Referenced WSDL Binding policy assertion in the PDD. Use this feature to deploy services with message parts mapped as SOAP headers or specify non-empty soapAction attributes.
  • WS-Reliable Messaging
    : The presence of WSRM policy dictates that the service is deployed as a Web service with support for the WS-Reliable Messaging protocol.
  • REST
    : If REST policy is used, a REST-ful service endpoint is exposed using a URL to HTTP clients.
For details about policy assertions, see Endpoint References and WS-Policy.

Unpublished Binding Style

When Unpublished is selected as the binding, the endpoint is not published to the SOAP stack and is only accessible to internal clients using process invokes or through custom java clients. For details, see
Invoking a Process from Java


We’d like to hear from you!