Composite

A composite is displayed as a light blue rectangle and represents the boundary between what's inside your application and what's outside your application. A SwitchYard application consists of exactly one composite that has a name and a targetNamespace. The targetNamespace value is important as it allows names defined locally in the application (e.g. service names) to be qualified and unique within a SwitchYard runtime.

<sca:composite name="example" targetNamespace="urn:example:switchyard:1.0">
</sca:composite>

Component

A component is a modular container for application logic and consists of the following:

• 0 or 1 component service definitions

• 0 to many component reference definitions

• 1 implementation

Services and references allow a component to interact with other components, while the implementation provides the actual logic for providing and/or consuming services.

<sca:component name="Routing">
</sca:component>

Implementation

An implementation acts as the 'brain' of a service component and it is how implement your application logic. The following implementation options are available:

• Bean : allows a CDI Bean to consume or provide services using annotations.

• Camel : EIP-style routing and service composition using the XML or Java DSL in Apache Camel.

• BPMN 2 : service orchestration and human task integration expressed as BPMN 2 and executed using jBPM

• BPEL Process : web service orchestration using the OASIS Business Process Execution Language

• Rules : decision services based on Drools

Implementations are private to a component, which means external consumers and providers are not aware of the details of a component's implementation (implementation-hiding).  All interactions with other components within an application and with external services are handled through component services and references.

<sca:component name="Routing">
   <camel:implementation.camel>
      <camel:xml path="RoutingService.xml"/>
   </camel:implementation.camel>
</sca:component>

Component Service

A component service is used to expose the functionality of an implementation as a service. All component services have a contract, which can be a Java interface, WSDL portType definition, or a set of named data types (interface.esb). Component services are private to an application, which means a component service can only be invoked by other components in the same application. In order to expose a component service to consumers external to the application, a component service can be 'promoted' to a composite service. A component service can be promoted multiple times to create different composite services.

<sca:component name="Routing">
   <camel:implementation.camel>
      <camel:xml path="route.xml"/>
   </camel:implementation.camel>
   <sca:service name="ServiceA">
      <sca:interface.java interface="org.example.ServiceA"/>
   </sca:service>
</sca:component>

Composite Service

A composite service represents an application service which is visible to other applications. A composite service can only be realized by promoting a component service within the application. The name and the interface of the composite service can be different from the component service. If the interface, or contract, of the composite service is different from the component service, be aware that a transformation may be required to map between the types defined in each interface. In our example application, the component service has a Java interface while the composite service has a WSDL interface. This means we would need to declare a transformer which maps between XML and Java to resolve the data type mismatch. For more information on transformation, see the Transformers section of the Developer Guide.

<sca:composite name="example" targetNamespace="urn:example:switchyard:1.0">
   <sca:service name="ServiceA" promote="Routing/ServiceA">
      <sca:interface.wsdl interface="ServiceA.wsdl#wsdl.porttype(ServiceAPortType)"/>
   </sca:service>
</sca:composite>

Service Binding

A service binding is used to define an access method for a composite service. Composite services can have multiple bindings, which allows a single service to be accessed in different ways. In most cases, a service binding represents a protocol/transport adapter (e.g. SOAP, JMS, REST). An important exception to this rule is the SCA binding, which allows services across applications in the same runtime to be wired together in memory. Regardless of the underlying binding details, a binding must always be used to facilitate inter-application communication in SwitchYard.

<sca:composite name="example" targetNamespace="urn:example:switchyard:1.0">
   <sca:service name="ServiceA" promote="Routing/ServiceA">
      <sca:interface.wsdl interface="ServiceA.wsdl#wsdl.porttype(ServiceAPortType)"/>
      <soap:binding.soap>
        <soap:wsdl>ServiceA.wsdl</soap:wsdl>
      </soap:binding.soap>
   </sca:service>
</sca:composite>

Component Reference

A component reference allows a component to consume other services. A component reference can be wired to a service offered by another component in the same application or it can be wired to services outside the application via a composite reference. Similar to component services, all component references have a contract with allows a component to invoke services without knowing implementation or binding details. The picture below shows an example of wiring a reference on the Routing component to a service offered by the Bean component.

<sca:component name="Routing">
   <camel:implementation.camel>
      <camel:xml path="route.xml"/>
   </camel:implementation.camel>
   <sca:service name="ServiceA">
      <sca:interface.java interface="org.example.ServiceA"/>
   </sca:service>
   <sca:reference name="ServiceC">
      <sca:interface.java interface="org.example.ServiceC"/>
   </sca:reference>
</sca:component>

Composite Reference

A composite reference allows a component reference to be wired to a service outside the application. Similar to composite services, bindings are used with composite references to specify the communication method for invoking the external service.

<sca:composite name="example" targetNamespace="urn:example:switchyard:1.0">
   <sca:reference name="ReferenceB" multiplicity="0..1" promote="Routing/ServiceB">
      <sca:interface.java interface="org.example.ServiceB"/>
   </sca:reference>
</sca:composite>

Reference Bindings

A reference binding is used to define an access method for an external service via a composite reference. Unlike service bindings, there can only be one binding for each composite reference. The set of bindings available for references is identical to the set of bindings available for services, although the configuration values for a given binding may be different depending on whether it's used as a service binding or a reference binding.

<sca:composite name="example" targetNamespace="urn:example:switchyard:1.0">
   <sca:reference name="ReferenceB" multiplicity="0..1" promote="Routing/ServiceB">
      <sca:interface.java interface="org.example.ServiceB"/>
         <jms:binding.jms>
         <jms:queue>MyQueue</jms:queue>
         <jms:connectionFactory>#ConnectionFactory</jms:connectionFactory>
      </jms:binding.jms>
   </sca:reference>
</sca:composite>

Adding Transformation to Your Application

Transformation of message content is specified in the descriptor of your SwitchYard application (switchyard.xml).  The qualified name of the type being transformed from as well as the type being transformed to are defined along with the transformer implementation.  This allows transformation to be a declarative aspect of a SwitchYard application, as the runtime will automatically register and execute transfomers in the course of a message exchange.

<transforms>
   <transform.java bean="MyTransformerBean"
                   from="{urn:switchyard-quickstart-demo:orders:1.0}submitOrder"
                   to="java:org.switchyard.quickstarts.demos.orders.Order"/>
</transforms>

<definitions xmlns:tns="urn:switchyard-quickstart:bean-service:1.0">  
  <message name="submitOrder">
    <part name="parameters" element="tns:submitOrder"/>
  </message>
  <portType name="OrderService">
    <operation name="submitOrder">
      <input message="tns:submitOrder"/>
    </operation>
  </portType>
</definitions>

{urn:switchyard-quickstart:bean-service:1.0}submitOrder

package org.switchyard.example;
public interface OrderService {
    void submitOrder(Order order);
}

package org.switchyard.example;
public interface OrderService {
    @OperationTypes(in = "{urn:switchyard-quickstart:bean-service:1.0}submitOrder")
    void submitOrder(String orderXML);
}

Available Transformers

Switchyard supports several transformers that facilitate conversion from one data format to another. The list of available transformers is given below

• Java Transformer

• JAXB Transformer

• JSON Transformer

• Smooks Transformer

• XSLT Transformer

Adding Validation to Your Application

Validation of message content is specified in the descriptor of your SwitchYard application (switchyard.xml).  The qualified name of the type being validated name is defined along with the validator implementation.  This allows validation to be a declarative aspect of a SwitchYard application, as the runtime will automatically register and execute validators in the course of a message exchange.

<validates>
   <validate.xml schemaType="XML_SCHEMA"
                   name="{urn:example}MyBook">
      <schemaFiles><entry file="/xsd/orders.xsd"/></schemaFiles>
   </validate.xml>
</validates>

Available Validators

Switchyard currently offers support for the following validators

• Java Validator

• XML Validator

Environment Properties

Environment properties allow you to replace any attribute or element value in switchyard.xml with a property from the runtime environment. The syntax for a replaced token is "${varName}" where "varname" is your property name. The configuration layer in SwitchYard is configured with instances of PropertyResolver, which are used to resolve the value of a property based on its name. Property values are resolved from the following locations:

• System properties passed by -D option of Java VM like "-Dproperty.name=property.value"

• System environment variables, referenced with an "env." prefix, for example: env.PATH

• Unit test properties

• JBoss AS7 properties, including access into the SecurityVault

• Domain properties in switchyard.xml

• SCA property definitions in the composite or component

<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
    <sca:component name="InventoryService">
        <sca:service name="InventoryService">
            <sca:interface.java interface="${inventory.interface:org.switchyard.quickstarts.demos.orders.InventoryService}"/>
        </sca:service>
        <sca:property name="inventory.interface" value="org.switchyard.quickstarts.demos.orders.InventoryServiceEx"/>
    </sca:component>
    <sca:property name="inventory.interface" value="org.switchyard.quickstarts.demos.orders.InventoryServiceEx2"/>
</sca:composite>

-Dinventory.interface=org.switchyard.quickstarts.demos.orders.InventoryServiceEx3

<foo value="${prop}"/>
<bar value="$${prop}"/>

Implementation Properties

Implementation properties allow you to inject one or more property values into a service implementation. This is based on the property support in the SCA assembly spec. Since the property is injected into service implementation logic, the injection mechanism itself is unique to each implementation type. The details for each implementation type follow:

• Java : injected using @Property into a CDI bean

• Camel : wired into Camel properties component and accessible in a Camel route using Camel's own varName property notation

• BPEL : mapped into process variables via an <assign> with using resolveProperty() XPath custom function

• BPMN 2 : inserted into process variables by data input associations

• Drools : available in a global map

See each Service implementation section of the Developer Guide for more details.

Configuring Policy

There are two aspects to a Policy definition:

• What policy does the service provider require?

• What policy support does the service consumer provide?

You define the policy that a service requires by annotating the service's configuration in the SwitchYard application descriptor.  You also define how a service is consumed (e.g. through a gateway binding), which effectively determines how the policy requirements are satisfied (or provided).  The runtime will take care of determining whether the consumer satisfies the policy requirements by evaluating the configuration of the application and the runtime state of the messages exchanged between the consumer and provider.

Take the following example configuration:

<composite name="policy-transaction">
   <service name="WorkService" promote="WorkService">
      <camel:binding.camel configURI="jms://policyQSTransacted?connectionFactory=%23JmsXA&amp;transactionManager=%23jtaTransactionManager&amp;transacted=true"/>
      <camel:binding.camel configURI="jms://policyQSNonTransacted?connectionFactory=#ConnectionFactory"/>
   </service>
   <component name="WorkService">
      <implementation.bean class="org.switchyard.quickstarts.demo.policy.transaction.WorkServiceBean" requires="managedTransaction.Global"/>
      <service name="WorkService" requires="propagatesTransaction">
         <interface.java interface="org.switchyard.quickstarts.demo.policy.transaction.WorkService"/>
      </service>
      <reference name="TaskAService" requires="propagatesTransaction">
         <interface.java interface="org.switchyard.quickstarts.demo.policy.transaction.TaskAService"/>
      </reference>
   </component>
</composite>

The service has declared that it requires a global transaction by including the requires attribute with a value of "propagatesTransaction". This service is available at two distinct JMS endpoints - one is configured to provide a transaction (policyQSTransacted) and the other is not (policyQSNonTransacted). When messages are sent to the policyQSTransacted queue, the service is invoked in the context of a global transaction. When messages are sent to the policyQSNonTransacted queue, the SwitchYard runtime rejects the message because it violates the policy requirements of the service (there is no transaction).

Transaction Policy

<service name="WorkService" requires="propagatesTransaction">

<implementation.bean class="org.switchyard.quickstarts.demo.policy.transaction.WorkServiceBean" requires="managedTransaction.Global"/>

Security Policy

<sca:component name="WorkService">
    <sy:implementation.bean class="org.switchyard.quickstarts.demo.policy.security.basic.WorkServiceBean" requires="authorization"/>
    <sca:service name="WorkService" requires="confidentiality clientAuthentication" sy:security="default">
        <sca:interface.java interface="org.switchyard.quickstarts.demo.policy.security.basic.WorkService"/>
    </sca:service>
</sca:component>

The <component><service> and <component><reference> security Attribute

Component Services and Component References can specify an optional sy:security attribute (namespace prefix required, as the SCA schema is being extended).  This attribute points to a named <security> element in the domain section.  If not defined, default will be inferred.

The <securities> Element

This is an optional element.  Contains any number of <security> elements.  If not defined, a default security configuration is still used.  See the <security> element below.

The <security> Element

This is an optional element.  If not specified, the callbackHandler, name, and securityDomain attributes described below will fallback to their default values.

The callbackHandler Attribute

This is an optional attribute.  If not specified, a default value of org.switchyard.security.callback.NamePasswordCallbackHandler will be used.  See the Callback Handlers section below for details on CallbackHandlers.

The name Attribute

This is an optional attribute.  If not specified, a default value of default will be used.  Component Services and Component References point to this name.

The rolesAllowed Attribute

This is an optional attribute. If specified, and if a Service has an authorization security policy requirement, the authenticated user must be in one of the roles listed. The value is a comma-separated list of roles (whitespace gets trimmed).

The runAs Attribute

This is an optional attribute. If specified, the value of this attribute will be added as a role to the authenticated user.

The securityDomain Attribute

This is an optional attribute.  If not specified, a default value of other will be used.  The value maps to a JAAS security domain name.  See the Login Modules section below for details on LoginModules.

The <properties> and <property> Elements

A <security> element can optionally specify a <properties> element, which can optionally specify zero to many (0..*) <property> elements.  Each <property> element has two required attributes: name and value.

The list of specified name/value properties are made available to the SwitchYard Security configuration, as well as the configured callbackHandler.  Some CallbackHandlers require configuration information beyond what can be assumed in a no-argument constructor.  See the individual CallbackHandler implementations for details.

Callback Handlers

The following is a list of available CallbackHandlers, all within the org.switchyard.security.callback java package:

Login Modules

In JBoss AS7, JAAS LoginModules can be stacked underneath a single security domain, and other is available out-of-the-box.  Here is an example that could be added to jboss-as7/standalone/configuration/standalone.xml:

<server>
    <profile>
        <subsystem xmlns="urn:jboss:domain:security:1.1">
            <security-domains>
                <security-domain name="jaas-domain-name" cache-type="default">
                    <authentication>
                        <login-module code="login-module-class-name-or-shorthand-name" flag="required">
                            <module-option name="option-name" value="option-value"/>
                        </login-module>
                    </authentication>
                </security-domain>
            </security-domains>
        </subsystem>
    </profile>
</server>

JBoss AS7 bundles various PicketBox (underlying security capability) LoginModules, as well as various PicketLink (federated trust security capability) LoginModules.

Please refer to the LoginModule documentation directly for complete configuration details, however a couple will be provided as example here.

Simple users/roles properties files on the classpath:

<login-module code="UsersRoles" flag="required">
    <module-option name="usersProperties" value="users.properties"/>
    <module-option name="rolesProperties" value="roles.properties"/>
</login-module>

Security Token Service validation:

<login-module code="org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule" flag="required">
    <module-option name="configFile" value="../standalone/configuration/sts-client.properties"/>
    <module-option name="useOptionsCredentials" value="true"/>
</login-module>

Subsystem Configuration Elements

Security-specific configuration details for the SwitchYard JBoss Subsystem.

<subsystem xmlns="urn:jboss:domain:switchyard:1.0">
    <security-configs>
        <security-config identifier="org.switchyard.security.context.SecurityContext">
            <properties>
                <timeoutMillis>30000</timeoutMillis>
            </properties>
        </security-config>
    </security-configs>
</subsystem>

<subsystem xmlns="urn:jboss:domain:switchyard:1.0">
    <security-configs>
        <security-config identifier="org.switchyard.security.crypto.PrivateCrypto">
            <properties>
                <sealAlgorithm>TripleDES</sealAlgorithm>
                <sealKeySize>168</sealKeySize>
            </properties>
        </security-config>
    </security-configs>
</subsystem>

Storing Passwords

Instead of storing plain-text passwords in switchyard.xml, you can use a combination of the JBoss AS password vault and property substitution in SwitchYard to obscure the password value.  There are two steps involved with this approach:

1. Configure the AS password vault and store your password information in the vault following the instructions documented on the JBoss AS7 Securing Passwords page.  Please pay special attention to the warnings on the page which indicate the level of security protection provided by the default password vault implementation.

2. Wherever you would normally include a password value in your switchyard.xml, use the vault ID instead, e.g.

${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}

Configuring Clustering

Clustering support is light on configuration and should work out of the box.  The only real requirements are using a shared Infinispan cache for the runtime registry and indicating which services are clustered in your application config (switchyard.xml).  By default, SwitchYard uses the default cache in the "cluster" cache container which comes pre-defined in your standalone-ha.xml.  Unless you have specific requirements to use a different cache or separate cache configuration, just stick with the default.

Applications take advantage of clustering by explicitly identifying which services should be clustered in the application's descriptor (switchyard.xml).  You can control which services in your application will be published in the cluster's runtime registry and which references can be resolved by clustered services.  To enable a service to be published in the cluster's runtime registry, promote the service in your application and add a <binding.sca> with clustering enabled to it.

<sca:service name="Goodbye" promote="GoodbyeBean/Goodbye">   
   <sca:interface.java interface="com.example.Goodbye"/>
   <sca:binding.sca sy:clustered="true"/>
</sca:service>

Consuming services in a cluster follows the same configuration approach, but applies to references in your application.  To invoke a service in a cluster, promote the reference and add an SCA binding with clustering enabled.

<sca:reference name="Goodbye" multiplicity="0..1" promote="GreetingBean/Goodbye">
   <sca:interface.java interface="com.example.Goodbye"/>
   <sca:binding.sca sy:clustered="true"
</sca:reference>

For more information on clustering using <binding.sca>, check out the SCA Binding documentation in the Developer's Guide.

Using Clustering

To create a cluster of SwitchYard instances, start two or more AS 7 instances with a shared Infinispan cache.  Out-of-the-box configuration in standalone-ha.xml should be sufficient:

# start instance 1
node1> bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1
# start instance 2
node2> bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=1000

Once the instances are up, you can deploy applications independently to each instance.  A homogeneous cluster would have identical applications deployed on each node.  A heterogeneous cluster will have different applications and services deployed on each instance.  For testing purposes, it's easiest to deploy a consumer application to one instance and a provider application to another.  Thecluster demo quickstart is a great way to try kick the tires on this feature.

Eclipse

@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(mixins = CDIMixIn.class, config = SwitchYardTestCaseConfig.SWITCHYARD_XML)
public class SomeServiceTest {

    private SwitchYardTestKit testKit;
    private CDIMixIn cdiMixIn;
    @ServiceOperation("ExampleService")
    private Invoker service;

    @Test
    public void testSomeInOnlyOperation() throws Exception {
        // TODO Auto-generated method stub
        // initialize your test message
        Object message = null;
        service.operation("someInOnlyOperation").sendInOnly(message);

        // validate the results
        Assert.assertTrue("Implement me", false);
    }

    @Test
    public void testSomeInOutOperation() throws Exception {
        // TODO Auto-generated method stub
        // initialize your test message
        Object message = null;
        String result = service.operation("someInOutOperation")
                .sendInOut(message).getContent(String.class);

        // validate the results
        Assert.assertTrue("Implement me", false);
    }

}

Forge

SwitchYard integrates with JBoss Forge to provide a set of rapid application development tools for service-oriented applications.  Please consult the Getting Started guide for information on how to install Forge and the SwitchYard extensions to Forge.

switchyard$ forge
    _____                    
   |  ___|__  _ __ __ _  ___ 
   | |_ / _ \| `__/ _` |/ _ \  \\
   |  _| (_) | | | (_| |  __/  //
   |_|  \___/|_|  \__, |\___| 
                   |___/      
 
[no project] switchyard $ new-project --named syApp --topLevelPackage org.switchyard.examples.forge
 ? Use [/private/tmp/switchyard/syApp] as project directory? [Y/n] 
***SUCCESS*** Created project [syApp] in new working directory [/private/tmp/switchyard/syApp]

[syapp] syapp $ project install-facet switchyard.soap
***SUCCESS*** Installed [switchyard.soap] successfully.
Wrote /tmp/syapp/pom.xml

Administration Console

BPEL Console

The BPEL console can be deployed to SwitchYard through its installer since SwitchYard-0.4 version.

Overview

This section provides an overview of the BPEL Console. The console provides the ability to view:

• The process definitions deployed to the BPEL engine

• The process instances executing in the BPEL engine

• The execution history of a process

• The history instances query

Installation

The easiest way to install the BPEL console is to download the SwitchYard installer and then run :

ant install-bpel-console

You will then be prompted for the location of your EAP installation, and the Installer will place the necessary WAR files in EAP.HOME/standalone/deployments.  

Alternatively, you can just simply copy the switchyard-bpel-console.war folder and switchyard-bpel-console-server.war from the Tools distribution into the EAP_HOME/standalone/deployments folder. Remember that you will need to add a marker file named "switchyard-bpel-console.war.dodeploy" in the deployments folder as well to trigger the deployment.

Logging in

The BPEL console can be located using the URL: http://localhost:8080/bpel-console.

The first screen that is presented is the login screen:

The default username is admin with password admin.

The Access Control mechanism used by the admin console is configured in the $deployFolder/bpel-console/bpel-identity.sar/META-INF/jboss-service.xml. The JAAS login module is initially set to use a property file based access mechanism, but can be replaced to use any appropriate alternative implementation.

The users for the default mechanism are configured in the property file $deployFolder/bpel-console/bpel-identity.sar/bpel-users.properties. The entries in this file represent username=password.

The user roles for the default mechanism are configured in the property file $deployFolder/bpel-console/bpel-identity.sar/bpel-roles.properties. The entries in this file represent username=role. The only role of interest currently is administrator.

Deployed Process Definitions

Once logged in, the 'Manage Instances' tab shows the currently deployed BPEL processes and their versions.

Process Instances

When a process definition is selected (Open), the list of active process instances for that process definition (and version) will be displayed in the bottom panel.

Process Versions

There is only one active version at a time. If you open a process definition the active version will be chosen by default. Sometimes you need to manage instances of a retired version (i.e. to terminate running instances). In that case the button More - Change Version allows you to select a different version of that process.

Execution History

The Execution History allows you to inspect the BPAF history data associated with a process. You can specify a timespan and whether or not you'd like to see failed/terminated instances included in the chart.

The chart has various keyboard bindings to browse through the displayed execution data:

<deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
	xmlns:bpl="http://www.jboss.org/bpel/examples"
	xmlns:intf="http://www.jboss.org/bpel/examples/wsdl">

	<process name="bpl:HelloGoodbye">
		<active>true</active>
        <process-events generate="all"/>
		<provide partnerLink="helloGoodbyePartnerLink">
			<service name="intf:HelloGoodbyeService" port="HelloGoodbyePort"/>
		</provide>
	</process>
</deploy> 

Instance Data and Execution Path

When a process instance is selected, its details will be displayed in the Execution Details panel. The Instance Data button will also become enabled, allowing further detail about the process to be displayed. Likewise the Execution Path button opens the related instance execution graph.

The View tab shows the instance execution graph, while the Source tab below shows all activity events

History Instance Query

Once a process instance is finished, could be 'COMPLETED', 'FAILD' or 'TERMINATED', you could search it through the History Query tab window as following:

You need to choose the Process Definition and the Process Status from the list box. You could also input the correlation key, start time and end time as criteria to search the history instances. Below is the search result.

On the History Instances List, when you double click a specific row, it will pop up a window that shows all of execution events that happened during this process instance execution.

Retiring and Reactivating Process Definitions

When a process definition is initially deployed (i.e. the first version of the process), it automatically becomes the active process definition. If that BPEL process definition is subsequently change and redeployed, then the previous version is retired, and the new version becomes the active version.

The only difference between an active and retired process definition is that a retired process definition can no longer create new process instances. However if there are current process instances associated with the retired process definition version, then these will continue to execute.

On some occasions, the administrator may wish to change which version of a process definition is considered the <emphasis>active</emphasis> version. Or they may simply want to retire the currently active process definition, so that no more process instances can be created, only allowing the already running process instances to continue until completed.

To change the status of a process definition, the administrator should select the Runtime tab from the lefthand panel, and then select the Deployments option. This will show the process definitions, their versions and their current status (active or retired).