Ich hatte erst vermutet, es wäre so eine Art Nachfolger vom FlashMessenger.

Klingt sehr hilfreich für mein derzeitiges Projekt, werd ich mir mal anschauen.

Messaging wird meistens da eingesetzt, wo mehrere Anwendungen oder auch mehrere physikalisch voneinander getrennte Server miteinander kommunizieren müssen. Hierzu wird ein Protokoll benötigt, das beide Server verstehen. Was das für ein Protokoll ist, hängt vom konkreten Einsatzzweck ab: Im einfachsten Fall reicht schon eine Webservice-Schnittstelle, um Nachrichten auszutauschen. Oft handelt es sich auch um dedizierte Serverprozesse auf einem eigenen Port, die Binärprotokolle verwenden, welche potenziell weniger Overhead mit sich herumschleppen. Mancherorts wird gar XMPP verwendet; das ist das gleiche XML-basierte Protokoll, auf dem auch der Instant Messaging Dienst Jabber basiert (bekanntester Vertreter: Google Talk).

Das besondere gegenüber “einfachen” Webservices ist, daß bei Messaging-Diensten i.d.R. eine Warteschlange erzeugt wird, die garantiert, daß Messages exakt in der Reihenfolge abgearbeitet werden, in der sie beim Empfänger ankommen – idealerweise sogar in der Reihenfolge, in der sie vom Absender gesendet wurden (dank variierender Nachrichtenlänge und Netzwerklatenz ist das nicht selbstverständlich). Diese Warteschlange wird als Queue bezeichnet (ausgesprochen etwa: “Kjuh”).

Wie genau das ausgestaltet ist, ist von System zu System verschieden. Die meisten Messagingdienste arbeiten nach dem Prinzip “Fire and Forget” – ist der empfangende Server nicht erreichbar, geht die Nachricht in’s Leere und es wird auch kein weiterer Sendeversuch unternommen. Andere sind da toleranter und verwalten einen lokalen Cache sowohl auf Absender- als auch Empfängerseite. Aus diesem Cache wird eine Nachricht erst gelöscht, wenn bestätigt wurde, daß diese auch angekommen ist bzw. verarbeitet wurde. Schmiert der Absender während der Übertragung ab oder der Empfänger zerlegt sich, bevor eine Message abgearbeitet werden konnte, wird beim Neustart des Prozesses der Message-Cache wieder bei der Nachricht begonnen, die als Letztes in der Mache war.

Wenn man viel mit verteilten Systemen arbeitet, kommt man um Messaging praktisch nicht herum.

Lediglich Zend_Pdf wird von mir oft eingesetzt und da stimme ich dir hinsichtlich der Unzulänglichkeiten vollkommen zu. Angeblich soll Zend_Pdf für das 2.0 Release komplett überarbeitet werden. Wir müssen uns da wohl gedulden.

Ach so und Zend_Queue, das stimmt natürlich, ist eine gute und sinnvolle Sache. Im Gegensatz zu Zend_Tool und Zend_Application aber vielleicht einen Tick weniger “spannend”. Aber nur ein Tick… ;-)

Mit den neuen Router-Plugins für ReST könnte sich eines von beiden Problemen in Luft auflösen – entweder das Performance-Problem wird damit gelöst (z.B. Durch Umgehung oder Abschaltung diverser Automatismen, die den MVC-Layer ausbremsen und die für Webservices Tinneff sind), oder es wird ermöglicht, sehr einfach ganz eigene ReST-Implementationen zu schaffen, die von den Einschränkungen von Zend_Rest_Server losgelöst sind (z.B. Verzicht auf XML-Datenformat). Genaues kann ich da aber erst sagen, wenn ich das mal wirklich im Detail angeschaut habe, das ist jetzt erstmal Spekulation.

Weniger spekulativ ist meine Freude über Zend_Feed_Reader – wenn Du schon mal versucht hast, einen wirklich generischen Feedreader für alle möglichen Feed-Formate mit dem bisherigen Zend_Feed zu bauen, wirst Du wissen, was ich meine: Das war eine Plage, und damit beschönige ich die Situation noch ;-). Die neue Komponente löst sämtliche Probleme des Vorgängers (so eine Aussage würde ich mir noch für Zend_Pdf wünschen, aber das ist ein Rant für einen anderen Tag ;-)).

Ich weiß nicht, was bei Zend_Ldap alles gemacht wurde (das Announcement hält sich ja leider recht zurück mit Detailinfos), aber bisher war diese Komponente jedenfalls nahezu unbrauchbar und kann eigentlich nur besser werden.

Final sei noch Zend_Queue erwähnt, das den flächendeckenden Einzug von Messaging in PHP-Anwendungen verspricht. Für einige gängigen Messaging-Protokolle sind auch schon Treiber drin, auf den ersten Blick vermisse ich aber eine ausfalltolerante Variante wie https://www.dropr.org/ von Sönke Ruempler und Boris Erdmann. Aber vielleicht kommt das ja noch ;-). Bedarf für Messaging ist jedenfalls definitiv vorhanden.

Alles in allem freue ich mich schon drauf, mit dem ganzen neuen Zeug mal spielen zu dürfen!