Capability Passing Processes

The traditional view of network protocol stacks is somewhat at odds with the reality of the internet today. Rather than a flat network address space defined by IP addresses, the internet is partitioned into distinct enterprise zones by mechanisms such as network address translators, firewalls and load balancers:


Rather than, as now, relying on a bloated transport layer, or a bloated protocol stack that uses multiple layers to mask the true nature of the network, the argument has been made for an end-to-end connection layer above the transport, that manages the establishment and maintenance of end-to-end connections that cross enterprise boundaries as delineated by firewalls etc. This architecture is reflected for example in the specification of message-passing formats for Web services. For example, SOAP message headers are explicitly designed to support application-level routing, among other services.


Our interest is in the interaction of such application-level routing and intermediation on other application services, such as transactions. Consider for example distributed transactions, which are an integral part of providing reliability for distributed applications. Transaction processing monitors are considered the most successful part of modern middleware, provided as part of the runtime of the system.


Consider an example distributed transaction that performs a transfer from one bank acount to another:

Lock home bank account
Log: Withdraw $100 from home bank
Log: Commit changes if ATM bank commits
Release lock

Lock ATM bank account
Log: Deposit $100 into ATM bank
Log: Commit changes if home bank commits
Release lock

For this transaction to complete, TPMs use the two-phase commit protocol to synchronize changes to the participant databases. Support for 2PC in databases is standardized by the XA protocol from the X/Open group.

The issue from our perspective is the necessity for the TPM to communicate with the participant databases to run the 2PC protocol (among other reasons). However in a layered architecture, this requires that the transaction system avail of the services of the connection system that navigates the discrete address space of the modern internet. This is at odds with the idea of the TPM being part of the middleware runtime, with network navigation now part of the application (e.g., for specific inter-enterprise applications). For this among other reasons, the use of 2PC is discouraged for SOA applications.


The approach of capability-passing processes is to decouple the transactional system from the communication system, and rely on application-level protocols, perhaps in a connection layer, to exchange the messages required for transactional protocols. To do this, we make logs avaiable as an explicit programming abstraction for reliable distributed applications. Operations on logs include query and log append. Log queries provide evidence for local log state. Log append operations are defined on application-specific basis, where the addition of certain log operations may require evidence of the state of nonlocal logs. This evidence is obtained by log queries at those remote sites, and communicated via application-level or connection-level protocols.


We formalize this appraoch using two calculi: the lqp-calculus, a design calculus with the ability to perform querying remote log state; and the lqcp-calculus, an implementation calculus that requires evidence of state at remote logs. Our approach allows safety properties from programs in the design calculus to be carried over to programs in the implementation calculus, demonstrating how an application-level protocol can be decoupled from the details of communication in modern SOA applications.