PEPt - An Architecture for Adaptable Remoting Systems

Harold Carr, Ph.D.

Service oriented architectures (SOA) are moving us closer to reusable and adaptive remoting systems since they focus on the exchange of data, not the infrastructure by which it is exchanged. SOA relies on remoting infrastructure to exchange data. That is where PEPt comes in. A SOA platform uses PEPt to implement the lower-level message exchange system. PEPt gives the SOA platform the ability to integrate with existing services (e.g., CORBA, SOAP) and to evolve as new encodings, protocols and transports come into use. This integration and evolution can happen without changing the upper orchestration and choreography layers since they are properly using a more abstract view of data and message exchange.

PEPt is an architecture for implementing "remoting" (e.g., RPC and Messaging) systems. Although remoting systems seem quite varied they actually share the same fundamental building blocks: presentation, encoding, protocol and transport (PEPt). Presentation encompasses the data types and APIs available to the programmer. Encoding is the representation of those types on the wire. Protocol frames the encoded data to denote the boundaries and intent of the message. Transport moves the encoding + protocol from one location to another. The PEPt architecture enables a remoting system to adaptively change presentations, encodings, protocols and transports.

The CORBA system in the Sun Java System Application Server 8.x uses the PEPt 1.0 architecture.
The CORBA system in Sun's J2SE 1.5 uses the PEPt 1.0 architecture.
Sun's implementation of JAX-RPC 2.0 uses the PEPt 2.0 architecture.

PEPt 2.0

Enterprise Features Enabled by PEPT

How PEPt fits into an Enterprise Service Bus (ESB) and a Service Oriented Architecture (SOA)

PEPt 1.0



Copyright 2005 by Harold Carr