Fetching contributors…
Cannot retrieve contributors at this time
131 lines (112 sloc) 7.31 KB

PEIP - PHP Event Integration Project

pronounced: pipe

The first Event Driven Messaging Framework (for PHP)


Let your Database speak to your Chat-App
Make your MVC concentrate on its job
Design your Workflow without any headache
Let your Mobile talk with your Blog

Let your Mailserver twitter to Facebook
Update your Offline-App on connect
Free your Controller from making choices
Let your Dependencies off the Hook

Let your CRM talk to Twitter
Make your Config Context aware
Route your Custom-Events through the Pipeline
Make your Messages easy to share

Transform your Documents to any Format

Forgett about Coupling and Vendor-Locks
On Demand build your Index and Caches
And if you want to, Change all of that!


You can find PEIP's (interim) Homepage here
You can find PEIP's GitHub-Page here
You can find PEIP's downloads here
You can find PEIP's PEAR packages here
You can find PEIP's API docs here
You can find PEIP's Examples in the Source.
You can find PEIP's Issue/Bug Tracker here
You can find PEIP's ohloh metrics here


PEIP is a pure PHP Middleware Framework to easily create and connect Messaging- and Work-Flows.
One of PEIP's goals is to provide implementations of Enterprise Integration Patterns for PHP (but with a bit different approach then usually).
PEIP can be used by scripting or configuration (recommended).
PEIP is noninvasive - it plays nicely and integrates with your favorite MVC, Library, Services or PHP Applications.
PEIP is Event Driven. This allows for easily combining it's components without a need for coupling.
PEIP's Event Objects are first class Messages and can travel through the same components as Generic Messages.
PEIP can be easily extended and integrated (by using its interfaces).
PEIP's configuration (ability) can be easily augmented by simple plugins.

PEIP's main Components are:


Messages are basically generic wrappers for PHP Objects or any other type (strings, integers, arrays, ...).
Messages contain special header fields to provide meta data/information. For example: a return address (channel).


Event Objects are special Messages which are created on certain incedents on PEIP components.
Events Objects wrap the object where the event happend and can provide further data in headers.
Since Event Objects are first class Messages, they can travell through the messaging system to allow further processing.
Event Objects are only created when there is a listener registered for the certain event-type on the object. (So no 'event-spamming')


(Message) Channels are the objects on which Messages can be send and received from
A Producer would send a Message and a Consumer would receive it.
Basically there are two types of Channels:
(Note, that in implementation there is also a difference in how the Messages are received - that is publishing vs. polling)

Point-to-Point Channels

A Point-to-Point Channel (for example a PollableChannel) let exactly one Consumer receive a certain Message

Publish-Subscribe Channels

A Publish-Subscribe Channel broadcasts any Message to all of its subscribers.


Pipes are PEIP's most powerfull components.
They are not to be mixed up with "pipes" in a "pipes-and-filters architecture" - That would be the Channels.
Instead Pipes in PEIP are pipes-and-filters combinded in one. They can act as a filter (or router, splitter, aggregator, ...),
Message-Handler and can be hooked up in any place, where actually a channel would be needed.
Hence Pipes can be chained together without the need for channels to connect them.
Pipes are the base component for any component handling, examining, manipulating or routing messages.

A special sub-type of Pipes are EventPipes:
EventPipes can be hooked up on any component implementing the Connectable (Event-Publisher) Interface and pass its
EventObjects to the Messaging System for further routing or processing.

Service Activators

ServiceActivators are Adapters to decouple your Services from the Messaging System.
Service as used in PEIP does mean any arbitrary object instance which may can be manipulated before
calling a certain method on it, hence it'd fit with any of your typically used objects (including webservices).
(In Java-land service in this case would refer to a bean, but since we are talking about PHP-land there
are no beans - you could call them Peas if you like.)


(Message) Gateways are Adapters to decouple the entry to the Messaging System.
They will take care of creating Message Objects from abritrary inputs and send them on an appropriate channel.
On the output-level a Gateway will extract data from the received messages and pass it to a caller.
Gateways can be designed to mimick the API of your existing application, framework or library.


soon to follow


soon to follow
API docs can be found here
See also exmple section in source code


PEIP needs PHP5.3 to run.
This requirement came out while developing PEIP and is mostly based on the usage of inline functions
(Lamdas/Closures), the use of SplObjectStorage and some usage of late static binding.
So the reason why there are no Namespaces used in PEIP is because the PHP5.3 dependency crept in
while developing. (This may change in future).
Also PEIP could be backported to be able to be used with lower PHP5 versions. While there is actually
no plan to do this, it would not be so hard (but worse performing), because the 5.3 dependencies are
not used in to many places.


Since PEIP is to be used with a variety of Applications, Frameworks and Services there might be special dependencies to use them with PEIP
For example the PEIP Gearman extension (PEIP_Gearman) has a dependency on PHP's Gearman extension and a Gearman server.


PEAR Install

pear channel-discover
pear install peip/peip

Install From Download

Download source from Downloads
Extract file to your include directory.

Install From Source

Change to one of your include directories.
git clone git://

See also:

PEIP Gearman Extension
Proof Of Concept: Visual Web-Editor for PEIP