This section collections frequently asked questions about PXE, BPEL, and related topics.
Q. What is PXE?
A. PXE is a system for supporting reliable long-running process execution. PXE Container — an extensible software container for hosting long-running services — sits at the core of PXE. A number of [PXE Service Provider]s extend the container to support various types of services.
Q. How does BPEL fit into PXE?
A. BPEL execution is provided through a [PXE Service Provider] implementation, which allows BPEL "services" to be deployed in the PXE Container.
Q. What is the overall architecture of PXE?
A. The architecture of PXE is described in the [PXE Architecture] section.
This section covers frequently-asked questions about PXE's support for the OASIS WS-BPEL language.
Q. Which version or versions of BPEL does PXE currently support?
A. PXE aims to provide full compliance to the OASIS WS-BPEL 2.0 standard as well as backward compatibility for BPEL4WS 1.1 processes. At present, PXE supports the syntax of a recent WS-BPEL 2.0 draft.
Q. Is the entire BPEL specification supported?
A. Because the standard is still evolving, all language features are not yet supported. FiveSight plans to provide full support for the OASIS WS-BPEL specification concurrent with its approval as a standard. Currently all BPEL activities are supported. However, certain BPEL 2.0 language constructs are not supported, and certain constructs may not be fully supported.
Q. Does PXE use native Java language constructs to execute BPEL, e.g., multiple threads for a <bpel:flow> or a while (...) {...} for a <bpel:while>?
A. No. PXE's BPEL implementation does not "map" the BPEL process into Java. Instead, it relies on a transactional concurrency framework very similar in theory to ACTORS Agha86.
Q. Does PXE support BPEL processes developed in third-party tools?
A. Yes. Well-formed BPEL from any source should work.
Q. Can PXE support extensions or alternatives to standard BPEL syntax and semantics?
A. Yes. PXE's BPEL compiler can be customized to support non-standard BPEL syntax and semantics.
Q. Does PXE support custom XPath extension functions in a BPEL process? What are the limitations?
A. Yes. XPath extension functions are supported; however, to ensure correct process execution in the presence of system failures, extension functions must be side-effect free.
Q. Does PXE support custom expression / query languages?
A. Yes. The expression / query language is fully pluggable.
Q. Does PXE support BPELJ or JSR-207?
A. No.
Q. Can multiple BPEL activities be grouped into a single transaction?
A. No. There is nothing in standard BPEL that would warrant such a "feature". The implementation manages all transactions to ensure correct process execution: the process author need not worry about such low-level issues.
Q. How does PXE support the long-running nature of BPEL processes?
A. PXE's BPEL implementation is based on a persistent concurrency framework that is transactionally coupled to the PXE service framework's event model. The framework transparently maintains process state in a reliable data store.
This section covers frequently-asked questions about the runtime management of the engine and process instances.
Q. Does PXE support process versioning?
A. No, it is currently not possible to modify the definition of a deployed process, nor is it possible to change the process defintion of an existing process instance. However, the ability designate a new process definition for new process instances is currently under development. The ability to modify the definition of an existing process instance may be available in future versions.
Q. Does PXE provide debugging facilities?
A. Yes, BPEL processes can be debugged "in-container" using the
BPEL Management API.
Q. What kind of eventing or audit information is available from PXE's BPEL engine?
A. PXE includes a rich eventing API that exposes information about the start and completion time of activities and scopes, variable manipulations, and other information. Event listeners can extract as much or as little of this information as desired.
This section covers frequently-asked questions about the runtime requirements for PXE and supported thirdparty products.
Q. Which Java virtual machines and runtime environments does PXE support?
A. Building PXE from source requires JDK 5.0, as PXE sources make some use of generics. JDK 5.0 should be used to run PXE (see Running PXE on 1.4 for additional information regarding JDK 1.4 deployment).
Q. Which operating systems does PXE support?
A. PXE is written entirely in Java and can run on any operating system supporting the required Java environment. PXE has been tested and is known to run on Windows 2000, Windows XP, Linux, MacOS X, Solaris, and AIX.
Q. Does PXE require a database? Which databases and versions does PXE support?
A. PXE does not depend directly on any specific database or persistence mechanism. Instead, PXE relies on a set of data access object ("DAO") interfaces that encapsulate the behaviors of a persistence layer. The PXE distribution includes a DAO implementation for JDBC databases built using Hibernate
. This DAO implementation can support most common relational databases. Schemas suitable for MySQL and HypersonicSQL. Relational databases lacking transaction or binary large object ("BLOB") capabilities are not supported. The DAO interfaces can readily be implemented to support alternative persistence mechanisms (e.g. JDO), XML datastores, or direct filesystem-based persistence. For addition information see the Databases reference section.
Q. Does PXE require a J2EE application server?
A. Although PXE depends on common J2EE interfaces, it does not require a J2EE application server. PXE relies on a Binding API that allows PXE to be embedded in most any environment that can supply JTA facilities.
Q. Is there a stand-alone PXE binding?
A. Yes, a complete stand-alone server employing the JoTM transaction manager and Jetty Web Container is provided and may be started using the pxe Command.
Q. Can PXE be deployed within an application server or web container?
A. Yes, PXE can be deployed into most common application servers. However, it is important to note that PXE is not an enterprise application in the J2EE sense: PXE manages its own transactions and threads. Consequently, if PXE is deployed using a WAR or EAR file, it will be in violation of a number of J2EE contracts.
Q. Does PXE require JMS?
A. No, however future versions of PXE will require a transactional transport to support clustering.
Q. Is PXE internationalized? If so, which languages are supported?
A. PXE messages intended for user consumption are internationalized using the Java resource bundle mechanism. American english messages are provided.
This section covers frequently asked questions related to integrating PXE into third-party products or integrating third-party products into PXE.
Q. Can PXE interact directly (i.e., not over the network) with native Java services?
A. This can be supported via a simple service provider implementation.
Q. Can PXE integrate with Middleware X? Can PXE integrate with Legacy system Y? Can PXE integrate with Enterprise Application Z? How is this accomplished?
A. The generic answer is "Yes," although it requires some work on the part of the integrator. The primary extension point for integrating with external systems is a service provider interface in the PXE service framework, and the various open source examples included with PXE provide starting points.
Q. Does PXE rely on any third-party or open source libraries?
A. PXE uses a number of liberally-licensed (i.e., non-GPL) open source libraries, some integral and some not. These are enumerated in the reference.
This section covers frequently asked questions about how PXE related to various web services specifications and initiatives.
Q. Does PXE supply a SOAP stack?
A. No (perhaps just a little). The HTTP-SOAP Service Provider included in the PXE distribution contains a BP1.1-compliant SOAP processor. However, this processor is not a full-featured SOAP stack: lower-level communication services, SOAP-header processing, and the like are expected to be supplied by an external SOAP stack. However, PXE's stand-alone server does provide a trivial SOAP stack for demonstration purposes.
Q. Can PXE be integrated with third-party web services products such as Apache AXIS, Systinet WASP, or JAXRPC?
A. Yes, PXE can be integrated into any stack the can supply it with WS-I Basic Profile 1.1 SOAP messages.
Q. Does PXE support web services transaction specifications, e.g., WS-Transaction, WS-Coordination, WS-Business Activity, OASIS BTP, or Composite Application Framework (WS-CAF)?
A. No, not at present.
Q. Does PXE support WS-Addressing?
A. PXE does not directly support WS-Addressing. However, the PXE BPEL implementation and the core PXE infrastructure provides support for opaque end-point references. This allows PXE to be integrated with arbitrary addressing standards.
This section covers frequently asked questions about the reliability of PXE.
Q. Can PXE recover in the event of system failure?
A. Yes, PXE uses JTA transaction management and relies on transactional data stores to ensure data consistency in the event of failure.
Q. How does PXE's BPEL Service Provider recover in the event of system failure?
A. The BPEL Service Provider is largely unaffected by system failures. Because it stores all critical information in a transactional data store and divides its work into atomic tasks coupled to PXE's transactional event-handling framework, any in-progress tasks are simply rolled-back in the event of failure and retried once the system restarts.
Q. What happens to outbound invocations bound to transaction protocols (such as SOAP-over-JMS) in the event of system failure?
A. Becasue transactional protocol adapters couple PXE event-handling and protocol communication to the same transaction, system failure does not affect their operation. Any PXE events that were being processed during a system failure are rolled-back and retried once the system restarts.
Q. What happens to outbound invocations bound to non-transactional protocols (such as HTTP) in the event of system failure?
A. In the event of system failure, a non-transactional protocol adapter will typically mark an outbound in-progress message exchange as "failed"; such failures are reported back to the client (typically a BPEL process) using PXE's framework. A protocol adapter may also be implemented so as to re-try the original request or employ any other suitable recovery mechanism.
This section covers frequently asked questions about PXE's clustering support.
Q. Can PXE be deployed in clustered or other configurations intended to provide fault tolerance and increased performance?
A. Clustering support is currently under development. Clustering support will require a transaction inter-node transport (such as JMS) as well as a transactional data store that can be accessed concurrently by all nodes in the cluster (i.e. a modern RDBMS).
Q. How will cluster nodes configured?
A. PXE will use zero-configuration nodes; that is, each node in a domain is exactly the same as every other node.
