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!
Downloads can be found here
PEAR packages can be found here
API docs can be found here
Examples can be found in the source.
Issue/Bug Tracker can be found here
ohloh metrics can be found here
See also:
PEIP Gearman Extension
Proof Of Concept: Visual Web-Editor for PEIP
PEIP is a pure PHP Middleware Framework to easily create 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 itself (contrary to any other Messaging Framework) 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 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) A Point-to-Point Channel (for example a PollableChannel) let exactly one Consumer receive a certain Message
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. 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 as a blog-post.
soon to follow
API docs can be found here
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. run:
pear channel-discover pear.peip-project.de
pear install peip/peip Download source from Downloads http://github.com/tidal/PEIP/downloads
Extract file to your include directory. Change to one of your include directories.
run:
git clone git://github.com/tidal/PEIP.git
- write readme
- setting up the website
- Add proper comments/doctags to every class/method
- add unit-tests for every class (code-coverage can be found here)
- writing documentation
- cleanup/write more examples
- setting up proper build and CI system
- write/publish extensions