BPEL Process Features

BPEL Process Features
With BPEL, you can define business processes that make use of services, and business processes that expose their functionality as services. When defining an executable business process in BPEL, you actually define a new service that is a composition of existing services.

• You can define both simple and complex business processes with BPEL. BPEL provides constructs such as loops, branches, variables, assignments, and so on, which allow you to define business processes in an algorithmic manner. The most important BPEL constructs are related to the invocation of services.
• With BPEL, you can invoke operations of services either synchronously or asynchronously, and manage callbacks that occur later.
• BPEL supports long-running process and compensation, which allows undoing partially failed work done by a process.
• You can schedule activities based on the execution time and define their order of execution.
• You can also invoke operations either in sequence or in parallel.
• BPEL provides fault handling, which is very important, because robust business processes need to react to failures in a smart way. BPEL can also capture events published external to the BPEL process instance and process them in a meaningful way.

You can also read: What is BPEL?

What Is BPEL?

What Is BPEL?

Business Process Execution Language (BPEL) is:

A markup language for orchestrating services into an end-to-end process flow

BPEL is a specialized language focused on the definition of business processes. BPEL Process components are instances of BPEL implementations that execute in the BPEL Process Manager service engine.

A BPEL Process receives messages and orchestrates, through different invocation patterns, one or more services that contribute to completing a business process flow.

Built on top of XML-related specifications

BPEL uses an XML-based vocabulary to describe business processes, and is based on WSDL, XSD, and XPath specifications.

Executed by a BPEL engine that can process the BPEL XML source

Oracle SOA Suite 12c provides a runtime environment for executing composite applications developed in BPEL.

You can also read BPEL Process Features

SOA, Web Services, and REST

SOA is an architectural approach to composition and integration.

SOAP-based web services is the most common way to implement SOA. They:
Address the low-level interactions between services
Help up to a certain level of complexity in the infrastructure

REST architecture provides an alternative medium by which SOA can be implemented.
REST tries to establish application architecture that emulates the World Wide Web.

SOAP and REST

Web services are of two kinds:

•                  Simple Object Access Protocol (SOAP) and 
•                   Representational State Transfer (REST).

SOAP-Based Web Services

SOAP-based web services is an important technology used to implement many services, but there are alternative service implementation technologies, such as REST. Web services are based on a core set of communication standards:
SOAP (to communicate) defines an XML-based structure for passing information, such as messages and data, between web services and applications.
WSDL (to describe) is an XML-based language for modeling web services. A WSDL document describes the service interface, message format, and the service instance location.
UDDI (to advertise and syndicate) allows organizations to register their web services in a uniform manner within a directory, so clients can locate their web services and learn how to access them.
The benefit of using web services artifacts such as WSDL and XSD is that they are “accepted standards.” These XML document structures are easily exchanged using the standard Internet (web services) protocols such as Hypertext Transfer Protocol (HTTP) among others.
SOAP, WSDL, and UDDI are standards at the core of web services, and they are followed by many additional specifications that define reliability, security, metadata management, transactions to meet requirements for enterprise features, and qualities of service. These specifications are collectively referred to as the WS-*.
Note that using a service-oriented design approach does not require SOAP web services; however, web services is the most common way to implement SOA. 

Representational State Transfer (REST) Web Services

REST-based services are based on a very different model than SOAP-based services. The model is based on resources. The idea is that you send a request for a resource, the resource that is returned shows you the options for the next step. This model is very flexible and does not require that the client know in advance what services and service calls are available.
REST services rely on a stateless, client-server, cacheable communications protocol—and in virtually all cases, the HTTP protocol. HTTP methods such as GET, PUT, POST, and DELETE are used to represent CRUD type operations (Create, Read, Update, Delete).
RESTful services do not impose constraints on the data format exchanged. Data can be formatted as XML, HTML, JavaScript Object Notation (JSON), and so on.