Error "Unable to create this part due to an internal error. Reason for the failure: assertion failed: " in the Eclipse

I've met a bad errror in Eclipse 3.2: Unable to create this part due to an internal error. Reason for the failure: assertion failed:
But at last I've solved this problem,it might be caused by the synchronization of the updates, for example if you make a the latest update to Eclipse 3.2, but at the same time perhaps you can not use the plugin that you've installed successfully and then the error above may appear,another reason that i surmise is that two same files(such as *.java) in the build path that belongs to one workbench.

Two suggested way to resolve it:
1.make your eclipse and plugin update synchronous
2.save your project in another directory and delete it in your workbench, restart the eclipse and rebuild again, if it doesn't work, try method 1.

This is my simple implementation of BP algorithm for MLP classification.(seems not so exhaustive :D)
(InputUnits:alternative hiddenUnits:alternative outputUnit:1,)

package bpSolve;

import java.util.Random;
import java.io.*;

public class BackPropagaion {

/**
* BP Algorithm Para:InputLayerNo,HiddenLayerNo
*
*
* @Jay
*/
private static int OutputNo = 1;

public static void main(String[] args) throws Throwable, IOException {
// get the HiddenUnits Number
String s1 = "1.Please Input the Number of HiddenLayerUnits:";
String s2 = "2.Please Input the Learning-Rate:";
int inputNo = 2;// by default
int hiddenNo = 0;
double rate = 0;
hiddenNo = Integer.parseInt(readIn(s1));
rate = Double.parseDouble(readIn(s2));

// get the SampleDatas from given file
String s3 = "Please input the SampleData Path:";
String Path = null;
Path = readIn(s3);

// get the sample and Targe
int Groups = 10; // the number of smaple groups
int Dimension = 2; // the number of Dimension
int i = 0;
double[][] sample = new double[Groups][Dimension];
double[] target = new double[Groups];
String Content = null;
FileReader fr = new FileReader(Path);
BufferedReader buffer = new BufferedReader(fr);
while ((Content = buffer.readLine()) != null) {
String[] str = Content.split(",");
int L = str.length;
for (int d = 0; d < L - 1; d++) {
sample[i][d] = Double.parseDouble(str[d]);
}
target[i] = Double.parseDouble(str[L - 1]);
i += 1;
}

// firstly to scale all the sample data

for (int k = 0; k < Dimension; k++) {
double[] array = new double[Groups];
for (int m = 0; m < Groups; m++) {
array[m] = sample[m][k];
}
double[] scale_array = scale(array);
for (int c = 0; c < Groups; c++) {
sample[c][k] = scale_array[c];
}
}

// begin the BackPropagation
BackPropagation(sample, target, rate, inputNo, OutputNo, hiddenNo);
}

// To do backpropagation
public static void BackPropagation(double[][] sample, double[] target,
double rate, int inputNo, int outputNo, int hiddenNo) {
// set the deault error to 0
double Error = 0;
// here we set a value to control the error scope, if the network error
// is larger than it,then run the circle again until it's lower than it.
double E = 0.01;
Error = E + 1;

// ----------------initialization of the weights-------------

// weights of InputLayer
double[] w_input = intial(inputNo);
// weights of HiddenLayer to InputLayer
double[][] w_hidden = intial(inputNo, hiddenNo);
// weights between OutputLayer and HiddenLayer
double[] w_output = intial(hiddenNo);

// network initialization
double[] input_hiddenlayer = new double[hiddenNo];
double[] input_inputlayer = new double[inputNo];
double input_outputlayer;

while (Error > E) {

int K = sample.length;
Error = 0;
// there are together K SampleVectors
for (int p = 0; p < K; p++) {
// p is the Pth Vector

/*-------------------Procedure of ForwardPropagation------------------*/

// calculation of input of the inputlayerUnits
for (int i = 0; i < inputNo; i++) {
input_inputlayer[i] = w_input[i] * sample[p][i];
}

// calculation of input of the hiddenlayerUnits
for (int i = 0; i < hiddenNo; i++) {
double temp = 0;
for (int j = 0; j < inputNo; j++) {
temp = temp + sigmoid(input_inputlayer[j])
* w_hidden[i][j];
}
input_hiddenlayer[i] = temp;
}

// calculation of input of the outputlayerUnits
double sum_hidden = 0;
for (int i = 0; i < hiddenNo; i++) {
sum_hidden = sum_hidden + w_output[i]
* sigmoid(input_hiddenlayer[i]);
}
input_outputlayer = sum_hidden;

/*-------------------Procedure of BackPropagation------------------*/

// calculate the delta of outputlayerUnits
double delta_output;

delta_output = target[p] - sgn(input_outputlayer);

// calculate the error of the networkoutput
double error_K = 0.5 * delta_output * delta_output;
Error = Error + error_K;

// calculate the delta of hiddenlayerUnits
double[] delta_hidden = new double[hiddenNo];
for (int i = 0; i < hiddenNo; i++) {
double derivative_hidden = sigmoid(input_hiddenlayer[i])
* (1 - sigmoid(input_hiddenlayer[i]));
delta_hidden[i] = w_output[i] * delta_output
* derivative_hidden;
}

// calculate the delta of inputlayerUnits
double[] delta_input = new double[inputNo];
for (int i = 0; i < inputNo; i++) {
double temp = 0;
for (int j = 0; j < hiddenNo; j++) {
temp = temp + w_hidden[j][i] * delta_hidden[j];
}
delta_input[i] = sigmoid(input_inputlayer[i])
* (1 - sigmoid(input_inputlayer[i])) * temp;
}

/*-------------------Regulation of the Weights------------------*/

// WeightRegulation of outputlayer
for (int i = 0; i < hiddenNo; i++) {
w_output[i] = w_output[i] + rate * delta_output
* sigmoid(input_hiddenlayer[i]);

}

// WeightRegulation of hiddenlayer
for (int i = 0; i < hiddenNo; i++) {
for (int j = 0; j < inputNo; j++) {
w_hidden[i][j] = w_hidden[i][j] + rate
* delta_hidden[i]
* sigmoid(input_inputlayer[j]);
}
}

// WeightRegulation of inputlayer
for (int i = 0; i < inputNo; i++) {
w_input[i] = w_input[i] + rate * delta_input[i]
* sample[p][i];
}
}
System.out.println(Error);
}
}

// to read Input on the monitor
public static String readIn(String display) throws IOException {
System.out.println(display);
BufferedReader buffer = new BufferedReader(new InputStreamReader(
System.in));
String string = buffer.readLine();
return string;
}

// outputlayer model function
public static double sgn(double x) {
if (x > 0)
return 1;
else
return -1;
}

// hiddenlayer model function
public static double sigmoid(double x) {
double g;
g = 1 / (1 + Math.exp(-x));
return (double) g;
}

// To generate the weights of inputlayer and outputlayer
public static double[] intial(int M) {
Random r = new Random();
double weight[] = new double[M];
for (int i = 0; i < M; i++) {
weight[i] = r.nextDouble() - 0.5;
}
return weight;
}

// to generate the random weights of hiddenlayer between[-0.5,0.5],
// N: number of forwardlayer units, M: number of backwardlayer units.
public static double[][] intial(int M, int N) {
Random r = new Random();
double weight[][] = new double[N][M];
for (int i = 0; i < N; i++) {
for (int j = 0; j < M; j++) {
weight[i][j] = r.nextDouble() - 0.5;
}
}
return weight;
}

// to get the scaled array between [0.1]
public static double[] scale(double[] original) {
int length = original.length;
double[] scale = new double[length];
for (int i = 0; i < length; i++) {
scale[i] = (original[i] - min(original)
/ (max(original) - min(original)));
}
return scale;
}

// to generate the maximum of the array
private static double max(double[] array) {
double max = array[0];
for (int i = 0; i < array.length - 1; i++) {
if (max <= array[i + 1])
max = array[i + 1];
}
return max;
}

// to generate the minimum of the array
private static double min(double[] array) {
double min = array[0];
for (int i = 0; i < array.length - 1; i++) {
if (min >= array[i + 1])
min = array[i + 1];
}
return min;
}
}


the parameters must be correctly set and the sampledata format must also be right, such as
1.6032,3.2925,-1
2.5699,1.2673,-1
2.156,3.0256,-1
0.72343,2.6734,-1
1.2626,0.66255,1
2.2493,3.0249,-1
3.2421,1.0224,-1
3.2475,1.1921,-1
2.0848,3.6309,-1
1.1158,0.94013,1

[Source:WWW.Javawolrd.com]Build an SOA application from exisiting services

Build an SOA application from exisiting services

Put heterogeneous services together with the Petals ESB

By Adrien Louis, 10/11/06

Due
to global networks, heterogeneous information systems, and the need for agility,
conventional architectures have evolved. The tasks of building entirely new applications,
making specific adaptors for legacy systems, or rewriting existing applications
are now obsolete. Largely promoted by Web services connectivity, the service-oriented
architecture (SOA) is now considered the preferred approach to designing an information
system.

SOA proposes to provide existing functions of an information system as
"services" that can be accessed in a loosely coupled way, independently from the
technical platform. An application is seen as an orchestration of requests for those
services. That is why an SOA generally comes with workflow or orchestration concepts.

An enterprise service bus (ESB) is an implementation of an SOA. It is
middleware for connecting heterogeneous services and orchestrating them. Related
to these concepts, the Java Business Integration specification (JBI, Java Specification
Request 208) defines a standard framework for integration.

In this article, I use the Petals ESB, an open
source JBI container, to illustrate how to connect existing heterogeneous services
and put together an online travel agency Web application.

Java Business Integration

The Java Business Integration specification defines a standard means for
assembling integration components. The goal is to create integration solutions that
enable an SOA in an enterprise information system. These components are plugged
into a JBI environment and can provide or consume services through it in a loosely
coupled way. The JBI environment then routes the exchanges between those components.

Two kinds of components can be plugged into a JBI environment:

• Service engines provide logic in the environment, such as XSL (Extensible
  Stylesheet Language) transformations or BPEL orchestration (Business Process
  Execution Language).


• Binding components are "connectors" to external services or applications.
  They allow communication with various protocols, such as SOAP, Java Message
  Service (JMS), remote method invocation (RMI), or ebXML.

These configurable components enable communication between heterogeneous
services. The JBI specification introduces the service assembly, which
defines the configuration of these components and the links between them. The goal
of the components (bindings or engines) is to expose external and internal services.
Each service exposed in the JBI environment can be accessed through the service
endpoint, the address of the service.

The messages exchanged between components are called message exchanges.
The exchange pattern between the components is a send-accept message pattern.

An online travel agency application with JBI

This article's travel agency Website allows users to book flights and
accommodations, and sends an email to users to confirm these reservations. To deliver
this functionality, the Website sends to the workflow engine all the information
provided by the user in XML. This workflow engine then connects to the airline to
book the flight, then to the hotel chain to book the room. It sends a confirmation
email to the user via the mail engine.

Even if the data exchanged during the process is XML, the XML schemas
requested or provided by the various services differ. Thus, an XSLT (Extensible
Stylesheet Language Transformation) engine is used to process transformations from
XML to another format.

I discuss the business process later in this article. Let's first look at Figure
1, which shows how this application is built with the Petals ESB.

Figure 1. Application architecture. Click on thumbnail to view full-sized
image.

Now let's define the different parts that are key to this architecture.

Service assembly

A service assembly is a descriptor that configures a JBI component for
integration with applications. A service assembly is deployed on the JBI container
as a simple ZIP archive. The container analyzes all the content in this archive
and configures the affected components. The configuration for a component is called
a service unit. When we configure a component with a service unit, we say
that we deploy an artifact on it. Note that the content of a service unit is opaque
to the container and is just provided to the component.

If the service assembly contains link definitions between services (also
called connections), the container creates them. Connections can be seen as aliases
to real service endpoints.

The service assembly is a ZIP archive containing an XML descriptor file
that defines to which component a service unit is provided and the connections between
services. The service assembly also contains each service unit to deploy to components.
These service units are also ZIP archives.

Figure 2. A service assembly. Click on thumbnail to view full-sized image.

To recap, the role of a service assembly is to define the glue between
a set of services to create an application in an SOA way. As multiple service assemblies
are deployed on the container, multiple applications can run on and share the same
services.

Service unit

A service unit is a set of elements deployed to a JBI component. A service
unit contains an XML descriptor that the component can read and any artifacts that
the component can require. For instance, a service unit for an XSLT engine contains
an XSL stylesheet, and the descriptor file tells the component that this stylesheet
must be used when a message is received on a particular service endpoint.

Figure 3. A service unit. Click on thumbnail to view full-sized image.

The ESB explodes the service unit archive in a directory, calls the component's
service unit manager (part of a JBI component) to inform it that a new service unit
is available, and indicates the directory where the service unit has exploded. The
component's service unit manager registers this new service in the JBI environment
and configures the component to use the related artifact with the registered service
endpoint.

Figure 4. Deploy a service unit on a component. Click on thumbnail to view
full-sized image.

When the component receives a message for a particular service endpoint, it knows
which artifact to use.

Figure 5. Use artifact for particular service endpoint. Click on thumbnail
to view full-sized image.

Connection

A connection is defined in a service assembly's descriptor. It can be
viewed as an alias for a real service endpoint. For example, a component can specify
"I want to send a message to the service endpoint called My Endpoint,"
and a connection specifies that My Endpoint is in fact My Real Endpoint.
Thus, when the component sends the message to My Endpoint, it is sent to
My Real Endpoint.

The interest of using such a mechanism is to dynamically reconfigure the
links between components. For instance, a component, such as the travel agency workflow
engine, is configured to call a service where the service endpoint name is "airline
service endpoint." Then, depending on the travel agency's partnership with the airline,
the connection will link the airline service endpoint with, for instance,
MyLowCostAirlineCompanyEndpoint or AnotherAirlineCompanyEndpoint.
The service's consumer needs no change to connect to the right service. By deploying
various service assemblies containing different connections, the application will
dynamically change the services used.

Figure 6. Resolve a connection. Click on thumbnail to view full-sized image.

The travel agency application

The global process for our travel agency application proceeds as follows:

1. The Website sends the user's reservation requests through a SOAP request
   to the SOAP binding component. This information is called Website XML content.
   Note that this communication is external to JBI.


2. Now, we enter the JBI environment. The SOAP binding component is configured
   to send the Website XML content via a message exchange to the endpoint
BookingWorkflowEndPoint (hosted by the BPEL engine).


3. The BPEL engine sends the Website XML content to the XSLT_1_Endpoint
   (hosted by the XSLT engine).


4. The XSLT engine transforms the Website XML content to a format recognized
   by the airline service and returns it as the flight-request XML.
   


5. The BPEL engine sends the Website XML content to the XSLT_2_Endpoint
   (hosted by the XSLT engine).


6. The XSLT engine transforms the Website XML content to a format recognizable
   by the hotel service and returns it as the hotel-request XML.


7. The BPEL engine sends the flight-request XML to the AirLineEndpoint,
   resolved as MyAirLineCompanyEndpoint (hosted by the SOAP binding
   component).


8. The SOAP binding component is configured to send the fight-request XML through
   a SOAP request to the MyAirLineCompany Web service (external to JBI). The result
   is the confirmed flight-response XML and is returned to the BPEL engine.
   


9. The BPEL engine sends the hotel-request XML to the HotelEndpoint,
   resolved as MyHotelEndpoint (hosted by the RMI binding component).
   


10. The RMI binding component is configured to send the hotel-request XML through
    an RMI call to the MyHotel RMI server (external to JBI). The result is the confirmed
    hotel-response XML and is returned to the BPEL engine.


11. As the result of the two reservations, the BPEL engine concatenates the
    flight-response XML and hotel-response XML to flight-and-hotel-response XML.
    Then it sends this XML to the XSLT_3_Endpoint (hosted by the XSLT
    engine).


12. The XSLT engine transforms the flight-and-hotel-response XML to text that
    summarizes the reservations. This email XML returns to the travel agency workflow
    engine.


13. The BPEL engine sends the email XML to the EmailEndpoint (hosted
    by the email binding component).


14. The email binding component sends an email with the email XML to the user
    (external to JBI). The process is now complete.

The components

The JBI components needed for the application are the SOAP binding component
(communication with the Website and the airline Web service), the JMS binding component
(communication with the hotel JMS service), the XSLT engine (XML transformation),
the email engine (send confirmation email to the user), and the BPEL engine. These
JBI components are distributed with the Petals JBI container.

To create our application, we just install those components in the JBI container.
(See Resources for more about JBI component installation.)

At this point, the architecture looks like this:

Figure 7. After component installation. Click on thumbnail to view full-sized
image.

Note that the mail engine natively exposes its single service endpoint
to the JBI environment, as it requires no configuration and always performs the
same task (which is, in fact, to send email).

When the components are installed, we must configure them. Thus, we need
to create the service assembly that links these elements together. The service units
described below make up this service assembly.

Website service unit

A service unit is created to be deployed on the SOAP binding component
(SOAP BC). This service unit defines an http://travel.com/workflowService Web service
that will map to the internal service endpoint WorkflowEndpoint.

With this service unit, the SOAP BC consumes the WorkflowEndpoint
service endpoint:

　

<jbi version="1.0" xmlns='http://java.sun.com/xml/ns/jbi' ...>
<services binding-component="true">
  <consumes service-name  =" BookingWorkflowService "
            endpoint-name =" BookingWorkflowEndpoint " />
  <petals:address> http://travel.com/workflowService </petals:address>
</services>
</jbi>

When the service unit deploys, the SOAP BC exposes a new Web service,
called http://travel.com/workflowService. When an external call to this Web service
is performed (from the Website, for instance), the SOAP BC transfers it to the
BookingWorkflowEndpoint service endpoint, that is, the application
workflow engine.

Booking process service unit

A service unit is created for deployment on the BPEL engine. This service
unit contains a BPEL definition of the booking process. This definition lists the
different service endpoints that must be called by the workflow engine. This process
definition maps to the internal service endpoint, the BookingWorkflowEndpoint:

　

<jbi version="1.0" xmlns='http://java.sun.com/xml/ns/jbi' ...>
<services binding-component="false">
  <provides service-name  =" BookingWorkflowService "
            endpoint-name =" BookingWorkflowEndpoint " />
  <petals:address> file://travel-booking.bpel </petals:address>
</services>
</jbi>

The travel-booking.bpel file is contained in this service unit and describes
the process.

Service unit for the airline Web service

Another service unit is created for deployment on the SOAP BC. This service unit
defines a MyAirlineCompanyEndpoint that will map to the external Web
service http://myairline.com/flightBookingService.

With this service unit, the SOAP BC provides the MyAirlineCompanyEndpoint
service endpoint:

　

<jbi version="1.0" xmlns='http://java.sun.com/xml/ns/jbi' …>
<services binding-component="true">
  <provides service-name  =" MyAirLineCompanyService "
            endpoint-name =" MyAirLineCompanyEndpoint " />
  <petals:address> http://myairline.com/flightBookingService </petals:address>
</services>
</jbi>

When the service unit deploys, the SOAP BC activates in the JBI environment
the MyAirlineCompanyEndpoint service endpoint. When a JBI component
sends a message to this service endpoint, the SOAP BC transfers it to the external
http://myairline.com/flightBookingService Web service, that is, the airline booking
Web service.

Hotel JMS service unit

The hotel JMS service unit looks like the airline service unit. The JMS BC provides
a MyHotelEndpoint service endpoint that maps to JMS message exchanges
with the hotel JMS server.

XSLT service unit

The XSLT engine is used for three transformations:

• The initial XML from the Website to the flight-request XML


• The initial XML to the hotel-request XML


• The flight-and-hotel-response XML to the email XML

So three service units must be provided, each one containing an XSL stylesheet
for the correct transformation. The XSLT engine will provide three services through
three service endpoints.

Airline and hotel connections

As seen before, we can use connections to independently link the application
workflow engine to the airline and hotel services, and dynamically reconfigure this
link by deploying a new service assembly.

For instance, the connection to the My Low Cost Airline Company looks like this:

　

<jbi version="1.0" xmlns…>
<service-assembly>
...
  <connections>
    <connection>
      <consumer service-name  ="AirLineService"
                endpoint-name ="AirLineServiceEndpoint"/>
      <provider service-name  ="MyLowCostAirLineCompany"
                endpoint-name ="MyLowCostAirLineCompanyEndpoint"/>
    </connection>
  </connections>
</service-assembly>
</jbi>

This code shows that when a service consumer (the application workflow engine)
consumes the AirlineService service, the MyLowCostAirLine
service is really consumed.

The global service assembly

All of these service units are packaged in one service assembly. The service
assembly's descriptor file contains the connections.

Figure 8. The application service assembly. Click on thumbnail to view full-sized
image.

This service assembly is deployed in the Petals JBI container, and all the service
units are delivered to their components.

　

Figure 9. Deploy the application service assembly. Click on thumbnail to
view full-sized image.

The components register their related service endpoints, the container sets the
connections, and the application is now ready to run.

Figure 10. The configured container. Click on thumbnail to view full-sized
image.

Conclusion

The JBI specification leverages the best concepts of SOA and standardizes
an approach for composing applications from existing services. JBI basically standardizes
the ESB concept.

Building an SOA application with the Petals JBI container is quite simple:
use some standard JBI binding or engine components, write a few XML descriptions
to explain how to connect to your services, and deploy them in the Petals JBI container.

With such a container, the challenge becomes writing or using relevant services
with good granularity, not assembling them.

Author Bio

Adrien Louis works as chief architect at
EBM WebSourcing, and has six years
of experience working with Java EE technologies. Currently, he is working on enterprise
integration solution problems. Louis is the project manager of the
Petals open source project. The goal
of the Petals project is to provide a distributed JBI container packaged in various
integration solutions like B2B integration or business-process-based integration.

From www.JavaWorld.com,

Commet:Good lecture about SOA building!

[转载]BPEL: Service composition for SOA

BPEL: Service composition for SOA

Get started developing business processes based on the Business Process Execution Language

By Matjaz B. Juric, 07/10/06

BPEL (Business Process Execution Language) has become one of the most important technologies of SOA (service-oriented architecture) and enables easy and flexible composition of services into business processes. BPEL is particularly important because it introduces a new concept into application development—programming-in-the-large. This concept enables us to develop processes quickly by defining the order in which services will be invoked. This way, applications (and information systems) become more flexible and can better adapt to the changes in business processes.

Business processes are usually of dynamic nature. Companies have to improve and modify, act in an agile manner, optimize, and adapt processes to improve the responsiveness of the whole company. Every change and improvement in a business process has to reflect in applications that provide support for them. Although this requirement may not sound very difficult to fulfill, the real-world situation shows us a different picture. Changing and modifying applications is often a difficult job, which requires time. Therefore applications cannot react instantly to changes in business processes—rather, they require some time to implement, test, and deploy the modifications.

Making information systems more flexible and adaptable to changes, and better aligned with business processes is the major promise of SOA. In this article, I show why BPEL is so important and demonstrate how to develop a BPEL process.

Service-oriented approach

The SOA approach for efficient automation of business processes requires:

• Standardized way to expose and access the functionality of applications as services
• Enterprise bus infrastructure for communication and management of services, including message interception, routing, transformation, etc.
• Specialized language for composition of exposed functionalities of applications into business processes

The first requirement is fulfilled by the latest distributed architecture—Web services. The second requirement is fulfilled by the ESB (enterprise service bus), which provides support for centralized, declarative, and well-coordinated management of services and their communications. The third requirement, composition of services into processes, is fulfilled by BPEL, the commonly accepted specialized language for business process definition and execution.

A business process, as seen by BPEL, is a collection of coordinated service invocations and related activities that produce a result, either within a single organization or across several. For example, a business process for planning business travels will invoke several services. In an oversimplified scenario, the business process will require us to specify the employee name, destination, dates, and other travel details. Then the process will invoke a Web service to check the employee status. Based on the employee status, it will select the appropriate travel class. Then it will invoke Web services of several airline companies (such as American Airlines, Delta Airlines, etc.) to check the airfare price and buy the one with the lowest price.

Page 2 of 4

For the clients, the BPEL process will expose its functionality in the same way as any other Web service. From the client perspective, it will look exactly like any other Web service. This is important and useful, as it allows us to compose services into simple processes, simple processes into more complex processes, and so on. This also means that each BPEL process will be described with a WSDL (Web Services Description Language) description.

Core concepts

BPEL is an XML-based language. A BPEL process consists of steps. Each step is called an activity. BPEL supports primitive and structure activities. Primitive activities represent basic constructs and are used for common tasks, such as those listed below:

• Invoking Web services, using
• Waiting for the request, using
• Manipulating data variables, using
• Indicating faults and exceptions, using , etc.

We can then combine these activities into more complex algorithms that specify the steps of a business process. To combine primitive activities, BPEL supports several structure activities. The most important are:

• Sequence () for defining a set of activities that will be invoked in an ordered sequence
• Flow () for defining a set of activities that will be invoked in parallel
• Case-switch construct () for implementing branches
• While () for defining loops, etc.

As we will see, BPEL is not that different from programming languages, such as Java. But we will see that BPEL differs from Java and supports the characteristics of business processes. BPEL also provides fault and compensation handlers, event handlers, and correlation sets. It provides means to express complex parallel flows. It also makes it relatively easy to call asynchronous operations and wait for callbacks.

BPEL processes require a runtime environment—a BPEL server, which gives us good control over their execution. Typically, BPEL servers provide control over process instances that are executing and those that have finished. They support long-running processes and can dehydrate process state to save resources. Some servers provide control over process activities and allow their monitoring. Finally, using a BPEL server, all our processes are deployed centrally, which simplifies maintenance. All this makes the BPEL server the preferred environment for running and managing processes.

Choosing the right BPEL server can be quite difficult, however, as there are several choices. Some of the most popular BPEL servers that are based on Java EE (Sun's new name for J2EE) include Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration, and AquaLogic. There are also at least four open source BPEL servers available: ActiveBPEL Engine, FiveSight PXE, bexee, and Apache Agila.

Example process

Let us now look at an example BPEL process for business travels that we have described above. We will develop an asynchronous process that will use a synchronous call to check the employee travel status and two asynchronous calls to acquire the plane ticket prices. The figure below shows the overall structure of our process. On the left, we see the client that invokes the process. The process first calls the employee travel status Web service. Then it invokes both airlines' Web services concurrently and asynchronously. This means that the process will have to implement the callback operation (and a port type), through which the airlines will return the flight ticket confirmation. Finally, the process returns the best airline ticket offer to the client. In this example, to maintain simplicity, we will not implement any fault handling, which is crucial in real-world scenarios.

Page 3 of 4

Let us now write the BPEL code. We start with the process declaration—the root element, where we define the process name and the namespaces

 
  targetNamespace="http://packtpub.com/bpel/travel/"
  xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
  xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
  xmlns:trv="http://packtpub.com/bpel/travel/"
  xmlns:emp="http://packtpub.com/service/employee/"
  xmlns:aln="http://packtpub.com/service/airline/" > 

Next, we have to define the partner links. Partner links define different parties that interact with the BPEL process. This includes all Web services that will be invoked and the client of the process. Each partner link specifies up to two attributes: myRole that indicates the role of the business process itself and partnerRole that indicates the role of the partner. In our example, we define four partner links:

 
  partnerLinkType="trv:travelLT"
  myRole="travelService"
  partnerRole="travelServiceCustomer"/>
  partnerLinkType="emp:employeeLT"
  partnerRole="employeeTravelStatusService"/>
  partnerLinkType="aln:flightLT"
  myRole="airlineCustomer"
  partnerRole="airlineService"/>
  partnerLinkType="aln:flightLT"
  myRole="airlineCustomer"
  partnerRole="airlineService"/>

To store messages and to reformat and transform them, we need variables. Usually we use a variable for every message sent to the Web services and received from them. In our example, we will need a few variables. For each variable, we have to specify the type. We can use a WSDL message type, an XML Schema simple type, or an XML Schema element. In our example, we use WSDL message types for all variables:

Now we are ready to write the main process body. It contains only one top-level activity. Usually, this is a that allows us to define several activities that will be performed sequentially. Within the sequence, we first specify the input message that starts the business process. We do this with the construct, which waits for the matching message. In our case, this is the TravelRequest message. Within the construct, we do not specify the message directly. Rather, we specify the partner link, the port type, the operation name, and, optionally, the variable that holds the received message for consequent operations. We link the message reception with the client partner and wait for the TravelApproval operation to be invoked on port type TravelApprovalPT. We store the received message in the TravelRequest variable:

 

  portType="trv:TravelApprovalPT"
  operation="TravelApproval"
  variable="TravelRequest"
  createInstance="yes" /> 

Next, we need to invoke the Employee Travel Status Web service. Before this, we have to prepare the input for this Web service. We can construct such a message by copying the employee part of the message that the client sent. Now we can invoke the Employee Travel Status Web service. We make a synchronous invocation, for which we use the activity. We use the employeeTravelStatus partner link and invoke the EmployeeTravelStatus operation on the EmployeeTravelStatusPT port type. We have prepared the input message in the EmployeeTravelStatusRequest variable. Because it is a synchronous invocation, the call waits for the reply and stores it in the EmployeeTravelStatusResponse variable:

 

  
     
     
  




  portType="emp:EmployeeTravelStatusPT"
  operation="EmployeeTravelStatus"
  inputVariable="EmployeeTravelStatusRequest"
  outputVariable="EmployeeTravelStatusResponse" />

The next step is to invoke both airline Web services. Again, we first prepare the required input message (which is equal for both Web services). We will make concurrent asynchronous invocations. To express concurrency, BPEL provides the activity. The invocation to each Web service will consist of two steps:

Page 4 of 4

1. The activity is used for the asynchronous invocation
2. The activity is used to wait for the callback

We use to group both activities. The two invocations differ only in the partner link name. We use AmericanAirlines for one and DeltaAirlines for the other:

 





  
     


             portType="aln:FlightAvailabilityPT"
        operation="FlightAvailability"
        inputVariable="FlightDetails" />


             portType="aln:FlightCallbackPT"
        operation="FlightTicketCallback"
        variable="FlightResponseAA" />


  
...

In this stage of the process, we have two ticket offers. In the next step, we have to select one. For this, we use the activity:

 


     


         ...
...
     


     
        
...
     
  
  

We have come to the final step of the BPEL business process—to return a reply to the client using the callback to the client:

 
             portType="trv:ClientCallbackPT"
        operation="ClientCallback"
        inputVariable="TravelResponse" />
  

Conclusion

We have seen that BPEL is one of the most important cornerstones of SOA. It differs from common programming languages, such as Java, and is relatively easy to learn and use. Because BPEL has been designed specifically for definition of business processes, it provides good support for various specifics of business processes, such as support for long running transactions, compensation, event management, correlation, etc. BPEL is well suited for use with the Java EE platform, and many BPEL servers build on top of it. Java developers, particularly those who are involved in the development of enterprise applications and SOA, should therefore take a closer look at BPEL and start using the benefits it provides.

Author Bio

Dr Matjaz B. Juric is a professor at the University of Maribor. He is coauthor of the book Business Process Execution Language for Web Services, 2nd Edition, and the coauthor of the BPEL Cookbook, both published by Packt Publishing, and several other books, articles, and conference presentations. He is also the author of courses offered by BPELmentor.com, a training, mentoring, and consulting company.

---From www.Javaworld.com

Comment: A nice introduction about BPEL!