Abstract

The Business Process Execution Language (BPEL) is a language for describing business processes. It is an orchestration language, which means that it actively describes the ways in which individual services can be composed to implement a more complex service. BPEL can integrate external services (partner links) as well as human interactions, so that typical business processes can be easily mapped to BPEL descriptions. In most cases, users have a tool for designing and validating business processes, and another one for executing these processes.

BPEL is Orchestration

• BPEL processes are executed rather than observed
  • they can be started by external actions
  • they can be started by some internal process (within the BPEL context)
• BPEL processes can be long-running transactions
  • if human interaction is required, processes may take weeks or months
  • BPEL engines store process state persistently to preserve the state information
• BPEL processes are described like flow charts
  • BPEL defines a small number of basic building blocks
  • special controls are used for branching, joining, and exceptions
  • BPEL execution is the process of transporting data through the chart

BPEL Example

Separation of Concerns

• Basic services should be available as Web Services
  • they can be implemented in any programming language
  • BPEL code can be used to compose more complex services
• Basic services can be replaced without any side-effects
  • the new implementation must implement the same interface
  • simple interface problems may be solved with mapping components
• Separating the basic services and the logic has other benefits
  • the business logic can be easily visualized and adapted
  • if required, the business logic can be executed with another BPEL engine

What is an Application Server?

• Application servers are specialized execution environments
  • they provide services beyond the usual operating system services
  • they serve as a commodity for running applications
  • ideally, application servers can be switched without problems
• Application are built to run on a specific application server
  • Java 2 Enterprise Edition (J2EE) is a popular Java application server (multi-platform, one language)
  • .NET is another runtime environment with similar services (multi-language, one platform)

Middleware Infrastructure

• Middleware is delivered as pre-packaged software
• After a period of de-centralization, centralization is en vogue again
  • mainframes were centralized computers with dumb terminals
  • workstations and PCs were used to deliver better applications
  • maintenance of hard- and software became a big issue
  • now we have Web-based applications with dumb browsers
  • differences are the Internet, open standards, and service-orientation
• Companies try to consolidate their IT infrastructure

Java 2 Enterprise Edition (J2EE)

• Java 2 Enterprise Edition (J2EE) defines a Java runtime environment
  • J2EE is not a product, it is a specification
  • in theory, applications should be portable among different J2EE implementations
  • in practice, some work often is required (depending on the code)
• J2EE is implemented in a number of products
  • Sun's Java System Application Server
  • Red Hat's JBoss
  • IBM's WebSphere
  • Oracle's Application Server
  • BEA's WebLogic
• J2EE contains a large number of APIs
  • EJB, JNDI, JDBC, JTA, JAXP, JMS, JSP/JSF

Three-Tier Architecture

Deployment

• Applications need additional run-times and data
  • when composing a application, it is packaged for deployment
• Deploying applications should be portable among application servers
  • in theory, this works well because the middleware platform is well-defined
  • in practice, many application have problems with path names or similar issues