In August 2011 the AMQP Working Group passed the reins to the newly formed OASIS AMQP Member Section. After being developed in a very pragmatic manner by a consortium of “financial service institutions, infrastructure providers, and integration, transaction and networking specialists” (sic), the AMQP protocol became a internationally recognized standard.
A few months later, the final version of the AMQP 1.0 protocol was published.
As evident by some prominent web applications PHP remains a popular choice when implementing the front-end of a web application. PHP’s lacks a bit, however, when it comes to implementing the backend of such applications. While some very nice frameworks are beginning to fill this gap, the Java ecosystem is often a better choice for implementing the backend of a PHP application.
Despite this, however,
Last month the AMQP working group, which includes big hitters such as Bank of America, Credit Suisse, JPMorgan Chase, Barclays, Goldman Sachs, Microsoft, Cisco, VMWare, Redhat, and Informatica finalised version 1.0 of the AMQP standard. It has been 5 years in the making, the market for messaging has changed a lot in that time.
Being able to publish and subscribe to event streams is a powerful enabler for business activities. As business rules change and systems evolve, the low coupling that is inherent to this integration pattern allows an IT landscape to evolve gracefully.
Imagine, for example, that you need to perform several independent actions whenever a user signs-up to your site (like: create an account, register to a marketing mailing list, warm-up caches…). A good design would be to have these different actions performed by different systems acting upon receiving their marching order from a central place where “new user sign-up” events would be published to.
Messaging systems used to be found only in big enterprises or in the financial sector. Who else needed the reliability and scalability offered by such systems? But times have changed: public web sites have grown to sizes that dwarf some of the most advanced corporate systems. And as these web sites have grown, the need for timely decoupling their subsystems in order to scale has increased to.
This lead an entirely different breed of developers to want messaging systems too.