Diskussion:Message Oriented Middleware

zwei anmerkungen

1. STOMP ist AFAIK nicht Apache STOMP: http://en.wikipedia.org/wiki/Streaming_Text_Oriented_Messaging_Protocol
2. was sind "mangelende"? Ist vielleicht "mangelnde" gemeint?

Zum Doppeleintrag:

Zwischen Message Oriented Middleware und Message Queueing gibt es zwar Überschneidungen, es handelt sich aber um genauso zwei verschiedene Themen wie Message Oriented Middleware und XML. Message Oriented Middleware kann Message Queueing verwenden und tut dies meist auch, ein zentraler Aspekt neurerer Message Oriented Middleware ist jedoch die Anwendung portabler Datenschnittstellen, wobei sich XML-basierte Schnittstellen, unter anderem wegen der Transformationsmöglichkeit durch XSLT durchgesetzt haben. Message Queueing bezeichnet lediglich die Technik Nachrichten zwecks asynchroner Verarbeitung in Warteschlangen zu stellen, und das kommt auch innerhalb der Nachrichtensysteme von Betriebssystemen, Bibliotheken und Oberflächen vor, wo es rein garnichts mit Message Oriented Middleware zu tun hat.

Sollte keine Gegenrede zu meiner Begründung erfolgen, warum Message Oriented Middleware und Message Queueing nicht zu einem Artikel zusammengelegt werden sollten, werde ich die Doppeleintrag-Markierung aus beiden Artikeln wieder löschen.--ChristianHujer 10:41, 27. Jun 2005 (CEST)

Das prinzipiell Message Queueing eine Technik ist, die unter anderem von Message Oriented Middleware verwendet, wird, d'accor. Aber der Artikel Message Queueing in seiner jetzigen Form beschreibt das nicht. Er enthält Verweise auf MQSeries und SAP Exchange Infrastructure sowie XML, aber keine allgemeine Beschreibung des Konzepts. Daher der Doppeleintrag. Wenn jemand Message Queueing als Konzept in dem Artikel beschreiben will, dann klar, kann der umgeschriebene Artikel eingenständig bleiben. Aber in der jetzigen Form bleibt dabei maximal der erste Satz. --S.K. 19:12, 27. Jun 2005 (CEST)

Zum Link auf Publish/Subscribe: Pub/Sub in nachrichtenbasierter Kommunikation hat wenig bis nichts mit dem Oberserver-pattern aus der Software-Entwicklung zu tun (zumindestens so wie es im entsprechenen Artikel erklärt wird). Es sollte hier kein Link existieren. Stattdessen ist ein Link auf eine noch nicht existente Seite zu Publish/Subscribe sinnvoller.

- Mannmannmann

Hauptschulabschluss geschafft?

Vorteile

(und dann hingehustet)

asynchrone/synchrone Kommunikation Server/Dienst muss nicht sofort verfügbar sein Message-Warteschlangen meist schnellere Ausführung als Funktionsaufruf-basierte Programme lose Kopplung von Server/Clients mehr Toleranz für Änderungen der bestehenden Funktionen verbesserte Verfügbarkeit der Systeme parallele Verarbeitung von Nachrichten möglich

sagt mir alles was. Ich bin aber auch vom Fach. Wer für Wikipedia schreibt sollte aber schon den Anspruch haben für die Allgemeinheit zu schreiben. Sich ausdrücken zu können, über sein schmales Fachgebiet hinaus. Hast Du nicht. Kannst Du nicht.

Vorteile - Message-Warteschlangen? Nee, alles klar. Morgen zieh ich ich das ganze mal grade, wenn Du es nicht tust.

62.143.110.194 02:13, 20. Feb. 2009 (CET)

Protokollebene

Was ist ein Wirelevel-Protokoll (Abschnitt AMQP) bzw. was ist der Unterschied zwischen einem Wirelevel-Protokoll und einem Netzwerkprotokoll (Abschnitt SOAP)? -- Uli.ch 20:05, 4. Nov. 2010 (CET)