Monday, July 28, 2008

some business process terminologies

In one of the sessions on evolution of SOA which I attended after joining fusion practice, I came to know about some business process terminologies like orchestration, choreography and collaboration. Some people use the terms interchangeably; some people distinguish them in terms of specificity and perspective. Will try to explain them in detail.

· Orchestration

Orchestration in business processes is a series of activities in a controlled work flow – typically involving one single swim lane. Centered on a single point-of-view, defines state full use-of-message exchanges with service providers and consumers (e.g. WS-BPEL). The description of the sequence of activities that make up a business process is called an orchestration. WS-BPEL is used to orchestrate services into composite solutions usually expressing organization-specific business process flows. With WS-BPEL, you build a business process by integrating a collection of Web services into a business process flow. A WS-BPEL business process specifies how to coordinate the interactions between an instance of that process and its partner services. Orchestration defines executable behavior and how it is to be achieved, and events are controlled centrally.

The key design attributes for Orchestration include participant and role definition, variables, properties which enable conversation, fault handlers for exception processing, compensation handlers for error recovery and event handlers to respond to concurrent events with the process itself and set of activities.

· Choreography

Choreography relates to observable public exchange of messages, rules of interaction and agreements between two or more business process end points and can address the collaboration among multiple swim lanes. Provides a global view of the exchanges (e.g. WS-CDL) The Web Services Choreography specification along with its corresponding Web Services Choreography Description Language (WS-CDL) provides another way to building SOA compositions. WS-CDL allows you to describe peer-to-peer relationships between Web services and/or other participants within or across trust boundaries. To define choreography, you create a WS-CDL choreography description document that will serve as the contract between the interacting participants. Specifically, a WS-CDL document describes the message exchanges between the collaborating participants, defining how these participants must be used together to achieve a common business goal. For Choreography, message structure, asynchronous communication, message rules, invocation, events and event handling are some of the important design factors.

· Collaboration

A business function or functions emerging from the cooperative interaction between multiple actors. This is usually pictured as a form of global business process, where business state is modeled. (e.g. Business Process Specification Schema). Business process models describe interoperable business processes that allow business partners to collaborate. Business process models for e-business must be turned into software components that collaborate on behalf of the business partners. The goal of the ebXML Specification Schema is to provide the bridge between ebusiness process modeling and specification of e-business software components.

Thursday, July 17, 2008

how to call secured webservices from bpel

to start of with refer the blog by Marc Kelderman on calling basic secured webservices

You can add these properties from partnerlink also.
Click on the partner link which invokes the secured webservice wsdl. Select the properties tab . Click on create property and add the 3 properties and corresponding values

The header value must be credentials

The sample partner link entries in bpel.xml will look like the following

<partnerLinkBinding name="HelloWorldService">
<property name="wsdlLocation">HelloWorldService.wsdl</property>
<property name="wsseHeaders">credentials</property>
<property name="wsseUsername">geo</property>
<property name="wssePassword">secret</property>

Esb process instances are not getting created

ESB systems and service groups are units for organizing the services for the Oracle Enterprise Service Bus. When you develop an esb process there is always an option to define system and service group.When an ESB system is created, an entry for the system in the form system_name.esbsys, is added to the Resources folder under the project name in the Application navigator.

Sample file- system_name.esbsys

<?xml version = '1.0' encoding = 'UTF-8'?>
<system name=" system_name" guid="xxxxx" qname="system_name" status="ENABLED">
      <parameter name="Host">host_name</parameter>
      <parameter name="Port">http_port</parameter>
<deferredQueueName numberOfListeners="1" topicConnectionFactory="topic_conn_factory">topic_name</deferredQueueName>

When you create a system for a esb process from Jdeveloper host_name will default to localhost and http_port to 8888. If the esb process is deployed in local soa server with port 8888, it will work fine. But in cases where http port and host is different the deployed process may not get initiated at the time of invocation. So before deployment the host and port values has to be set properly. If the process is already deployed you need to update these values from the esb console. In case of High availability servers the Http server ip has to be specified as the Host value and http port as the port value. So in most cases if the esb processes are not getting instantiated the issue will be because of the wrong host and port value specified @system. Some of the adapters will not work properly if the connection factory and topic specified @system are not created or existing in the application server.

Sunday, July 13, 2008

How requests are forwarded to Oc4j

In case of an Application Server the most common types of requests are HTTP based and RMI-based requests.

For HTTP based request, within the application server environment, the Oracle HTTP Server (OHS) acts as a front-end listener and OC4J as the back-end J2EE application server.

For RMI-based requests —such as EJB and JMS—clients should send their requests directly to OC4J.

A browser accesses the OHS listener for all HTTP requests. The Oracle HTTP Server is an Apache server.

The request flow between Oracle HTTP Server and OC4J is as follows:
  1. incoming HTTP request is received by the Oracle HTTP Server listener.
  2. HTTP Server passes the request to an OC4J instance through the mod_oc4j module.

The connection between Oracle HTTP Server and OC4J uses the Apache JServe Protocol (AJP) on a port number negotiated during OC4J startup.

HTTP Application Listener request flow

AJP is faster than HTTP, through the use of binary formats and efficient processing of message headers.

Thursday, July 3, 2008

more on BPELProcessHandle class

In one of my previous blogs on invoking BPEL from java using RMI I had mentioned the different classes used to connect to the BPEL process.

As you know Locator class helps you to connect to bpel domain. Once you have the Locator instance the BPELProcess instance can be accessed using the lookup service method by giving the bpel process Id.

For example I created a BPElProcess named SensorTest and deployed it.

// code on how to create a locator instance have been explained in my previous blog on RMI

IBPELProcessHandle bpelProcess = locator.lookupProcess("SensorTest");

IBPELProcessHandle is the reference which will represent the process.

To view what all sensors are associated with the particular process- in this case SensorTest

System.out.println("sensors:\n" + bpelProcess.getSensorDefinitions());

System.out.println("sensor actions:\n" + bpelProcess.getSensorActionDefinitions());

Output will look like following


<sensors xmlns="">

<sensor sensorName="sensor_recieve" classname="" kind="activity" target="receiveInput" xmlns:client="" xmlns:pc="" xmlns:tns=" SensorTest ">

<activityConfig evalTime="activation"/>


<sensor sensorName="VariableSensor_1" classname="" kind="variable" target="$outputVariable/payload/client:SensorTestProcessResponse/client:result" xmlns:client=" SensorTest " xmlns:pc="" xmlns:tns="">

<variableConfig outputDataType="string" outputNamespace=""/>



sensor actions:

<actions xmlns="">

<action name="reply_sensor" publishName="" publishType="Custom" enabled="true" filter="" publishTarget="com.geo.SensorLogger" xmlns:pc="" xmlns:tns=" SensorTest ">





To view SOAP location of the particular process-

System.out.println("SOAPLocation:\n" + bpelProcess.getSOAPLocation());

To view the list of errrors

System.out.println("errors:\n" + bpelProcess.getErrors());

Try out and see for yourself :)