The PXE container (also known as the "service framework") provides an extensible and embeddable software container for service-oriented applications.

The most common role of the PXE container is to bind the partner links of a BPEL process to concrete communications protocols, although it is also possible to use PXE to create complex systems where multiple BPEL processes collaborate using a mixture of internal communications and bindings to concrete communications protocols.

Domains, Systems, Services, Ports, and Channels

The top-level component of the PXE container is called a domain, and its role is to host and provide services to deployment units called systems.

A system is composed of a collection of logical services that communicate with each other via channels that connect their ports. In analogy with a Java web application server, PXE systems are like web applications in that they are deployed, share a set of core system-level facilities, and operate independently within the enclosing container.

Like conventional web services, PXE services use WSDL port types to declare the operations supported by a given port. However, unlike conventional Web Services, PXE ports are binding-neutral, and have no "on the wire" representation. Also, each PXE service defines not only the inbound ports implemented by it but also the outbound ports that represent references to inbound ports implemented by other services (although technically, it is possible to cross-connect an inbound and outbound port on the same service). A service's inbound, "conventional" ports are said to be exported and are known collectively as the exports (no pun intended). The service's outbound ports are on the other hand said to be "imported" and are known collectively imports.

Instead, a channel functions as a kind of WSDL-typed "patch cord" that connects an imported port on one service to an exported port on another service, and any given port is connected to at most one channel. Channels operate asynchronously and carry stateful message exchanges corresponding to WSDL operations on the underlying ports, and thus a channel effectively decouples its endpoints.

For example, a request/response operation between two services, named A and B, would proceed in three separate transactional units of work as follows:

  1. In the first unit of work, Service A creates a message exchange for the appropriate operation, supplies the input message, and "sends" the message exchange to Service B on the channel.
  2. In the second unit of work, Service B "receives" the message exchange from the channel, processes the input message, fills-in the output message, "sends" the completed message exchange back to Service A on the channel. (This presumes normal completion of the operation, otherwise a fault would be filled-in.)
  3. In the third unit of work, Service A "receives" the completed message exchange from the channel. If, for whatever reason, Service B was unable to handle the message exchange, e.g., due to an internal language-level exception, Service A would receive a message exchange marked as failed.

Service Providers

Within the domain as a whole, a group of logical service instances is provisioned and managed by a service provider. Service providers are configured at the domain level as kmodules and cross systems, while individual services are configured at the system level. A configured service provider is bound to a user-selected URI within the domain and then referenced by that URI in the system deployment descriptor.

Provider Configuration vs. Service Configuration

PXE's BPEL process execution engine is packaged as a service provider. (See BPEL Service Provider.) At the provider level, items such as the type of persistence can be controlled, while at the service level, the specific process to be executed is specified.

Different configurations of the same service provider can be used with a single domain, so, e.g., BPEL process execution services using both persistent and non-persistent state management could be deployed within a system by using different provider configurations.

Service providers are the primary extension point for the functional capabilities of a PXE system, and common types of service providers break down into two categories.

External Communication or Invocation

This category includes most familiar network and messaging protocols, as well as "local" targets such as EJBs, POJOs, or JCA adapters. An invocation or communication-oriented service provider is responsible for providing a bridge between the internal representation of a message exchange as WSDL message parts and an external representation, e.g., as bytes on the wire or as Java objects. For example, HTTP communications support in PXE is implemented in terms of service providers (HTTP-SOAP Protocol Adapter).

Because they play distinct roles in the container, PXE distinguishes between inbound communications and outbound communications. A protocol adapter is a service provider that implements inbound communications, and a protocol connector is a service provider that implements outbound communications.

Message Transformation or Operation

This category includes the BPEL Service Provider and XSLT Service Provider and is disinguished from the invocation/communication category in that its primary function is to operate directly on message exchanges.