Microsoft gaat helpen bij ontwikkeling advanced message queuing protocol

Microsoft gaat meehelpen bij de ontwikkeling van een open standaard genaamd advanced message queuing protocol. Dit softwareprotocol is bedoeld voor de interne en externe uitwisseling van complexe berichten binnen organisaties.

De messagingstandaard die ontwikkeld wordt door de Amqp-werkgroep zal platformonafhankelijk en open zijn, zodat iedere ontwikkelaar de standaard kan implementeren in zijn eigen software. De Amqp-groep bevestigt dat ze niet de eerste is die een dergelijke poging onderneemt. Een groot verschil ten opzichte van de andere protocollen is echter dat door Amqp ook eisen worden gesteld aan serversemantiek, waardoor interoperabiliteit met meerdere serverimplementaties mogelijk wordt.

Microsoft is door enkele van zijn klanten gevraagd deel te nemen aan de Amqp-werkgroep. Volgens Sam Ramji, bij Microsoft als senior director verantwoordelijk voor platformstrategie, zijn klanten op zoek naar schaalbare oplossingen in combinatie met lagere kosten die hen toestaan om hun software berichten binnen en buiten de bedrijfsinfrastructuur te laten uitwisselen. De standaard die binnen de Amqp-werkgroep ontwikkeld wordt biedt deze mogelijkheden, aldus Ramji.

Hoewel het erop lijkt alsof Microsoft 'onder dwang' deelneemt binnen de Amqp-werkgroep is dat niet het geval, schrijft Ars Technica. Het Redmondse bedrijf wil zijn software namelijk beter interoperabel maken met de producten van andere leveranciers, en in dat kader zijn bijvoorbeeld reeds specificaties van enkele Microsoft-producten en technologieën vrijgegeven. Of het bedrijf de Amqp-standaard gaat implementeren liet Microsoft in het midden. Primair gaat het erom dat Microsoft luistert en leert van de wensen die klanten voor Amqp uitspreken, aldus een woordvoerder van het bedrijf.

Reacties (29)

[Superstoned]

Interessant om dit te zien, daar de nieuwe fedora dit messenging protocol als nieuwe feature heeft... http://blog.taragana.com/...scussion-on-the-features/

[Badtothebone]

Om dit bericht goed te begrijpen moet je echt de link volgen naar Microsoft, daar is het (in het engels) goed uitgelegd waar het voor is, dat snapte ik niet in eerste instantie maar dat kan aan mij liggen

Dit gaat meer over bedrijven dan de huis tuin en keuken MSN'er. Ik denk zelf dat dit meer te maken zal hebben met hun Communicator software dan wel client dan wel server solution.

Als je nog verder gaat lezen in dit verhaal zie je bedrijven als Cisco, Novell en Red Hat ook wat ik opmerkelijk vind zie ik een aantal financieel instellingen zoals Goldman Sach's en JP Morgan Chase bank, die zullen de noodzakelijk financering / testing doen?

[latka]

Message Queueing is al meer dan 30 jaar in gebruik voornamelijk in de mainframe wereld. Het is sterk in guaranteed delivery van berichten (bijvoorbeeld comma-seperated files met betalingsgegevens). Het is een bijzonder robuuste manier van transactie verwerking gebleken tot nu toe (nee, je wilt je geld niet overmaken met WebServices en zeker niet over HTTP).
Microsoft heeft hiervoor MSMQ, IBM heeft WebSphere MQ (vroeg gewoon MQ Series). Probleem is dat alle vendors een eigen client/server protocol gebruilken. Dit wil AMQP oplossen. Dit is ook tevens een belangrijke reden voor Microsoft hieraan deel te nemen: als die grote financiele clubs die genoemd staan gebruiken allemaal IBM MQ. Als Micrsoft nu AMQP ondersteunt kan IBM tenminste de vinger gegeven worden omdat er een serieuze grote speler naast staat (Microsoft ligt historisch gezien erg slecht in het financiele backend: dus MS moet wel meeliften om hier voet aan de grond te krijgen).

[Verwijderd]

Met de juiste toepassing van Webservices over HTTP (bijvoorbeeld door toepassing van WS-Security) durf ik mijn geld wel over te maken met die techniek.
Dit is hetzelfde niveau als roepen: ik durf mijn geld niet over te maken als dat wordt gecommuniceerd via een comma-csv file. Grote kans btw dat Websphere MQ gewoon Webservices ondersteund als transportmethode.

[latka]

Hmm, je mist een aantal zaken met Webservices/HTTP/WS-Security. Zo heb je nog WS-Transaction nodig (of was het nu WS-Atomic Transaction) en WS-Addressing (om duplicate delivery ook uit te sluiten) en welke versie WS-Addressing (2004/08, 2005/08 of Core 1.0). En oh ja, welke SOAP stack gebruikt de client en welke de server? Ik maak dagelijks webservices maar als het echt bullet-proof moet (lees: als ik de kosten van iedere gemiste transactie uit eigen zak zou moeten betalen) dan ga ik er met een boog omheen.
Ik hoop dat AMQP de interoperabiliteits ellende van SOAP oplost.

Oh, inderdaad WebSphere MQ kan ook SOAP, alleen stop je dan je security/addressing/transactions in MQ en in plaats van een comma-seperated file stuur je dan een XML bestand op. Het grote voordeel ontgaat me dan echter wel (CSV parsed sneller dan XML en is kleiner). M.a.w. SOAP/MQ kan maar boeit voor geen meter.

[hiostu]

CSV kan echter geen geneste structuren aan en is dus minder geschikt voor samengestelde transacties.

Als ik bv een order door wil geven met klantgegevens, orderregels (meerdere producten), betaalgegevens, etc zal je al snel gaan naar structuren zoals XML. Tevens kun je veel sneller en makkelijker bericht validaties doen op XML met XSD en transformaties met XSLT.

Je ziet juist een grote verschuiving naar XMLachtige structuren voor transacties tussen systemen.

[latka]

Inderdaad ik zie die verschuiving ook. Overigens: het is een kwestie van afspraken hoe je geneste structuren weergeeft (kan eventueel ook in een CSV). In de praktijk merk ik wel dat XML validatie aan de hand van XSD welleens problemen oplevert (niet voor simpele validaties op veldniveau, maar samengestelde validaties die niet kunnen in XSD). En ook XSLT vereist een bepaald type programmeur die je niet op de hoek van de straat vind.

Mijn betoog tot nu toe was niet zozeer gericht tegen WebServices/XML whatever, maar meer tegen de holy grail die het zou zijn: MQ is zo slecht nog niet en Webservices zijn prachtig als je alle details onder de knie hebt. Ik ben alleen bang voor het Corba effect van WebServices (het wordt zo moeilijk dat niemand het meer effectief kan inzetten). De afgelopen 20 jaar is er eigenlijk niets nieuws gebeurt op dit gebied. Lees anders ook: http://www.xs4all.nl/~irmen/comp/CORBA_vs_SOAP.html eens.

[Badtothebone]

Heel goed uitleg, bedankt. Als ik verder gaat kijken zie ik ook RabbitMQ als een van de bedrijven die meedoet in het AMQP werkgroep. Een voorbeeld wat ik gezien heb gaat over video streaming. Zou dit in de toekomst kunnen beteken dat wij minder lees een meer gestroomlined protocol hebt om dit soort dit dingen (data streaming) te realiseren? Ik bedoel hiermee dat er minder protocolen gebruikt worden en dat het tussen al de verschillende OS'en meer compatibel zal zijn.

[latka]

Ik neem aan dat je dit allemaal wel wist gezien je iSeries/zSeries en RPG achtergrond ;-)

[Badtothebone]

Dat klopt, maar ik heb weinig handson ervaring met Message Queueing en waar het mij om ging was de verhouding van Microsoft in het hele verhaal. Onze core business bij mijn huidige werkgever heeft veel te maken met de iSeries / zSeries maar weinig te maken met de onderliggende protocollen en werking van deze. Wij doen meer op applicatie niveau hoewel dit ook aan het veranderen is an hebben wij meer te maken met Messege Queueing als onze klanten meer en meer hun Mainframe en iSeries applicaties op het web / intranet / extranet zetten,

[humbug]

Ik wil best een eind met je mee gaan, maar aangezien veel banken enkel een webservice naar externe partijen (niet banken) aanbieden, zul je wel degelijk webservices moeten gebruiken als je geld wil overmaken.

Ik heb toevallig de protocollen van een stuk of 20 banken en financiele instellingen doorgenomen de laatste weken

[latka]

Correct (hmm, wellicht doen we hetzelfde). Wat je dan ziet is dat retries overgelaten worden aan de client. M.a.w. een synchrone webserivce en als er dan niet snel genoeg geantwoord wordt dan nogmaals sturen. De andere kant doet aan duplicaat detectie op basis van de data in het bericht. Al met al verre van ideaal aangezien niet iedere applicatie programmeur even goed is in foutafhandeling...

[eghie]

Apache is ook bezig met een client hiervoor, met Apache ActiveMQ. Zie daarvoor: AMQP vs OpenWire/STOMP en AMQP

[kozue]

Alhoewel ik normaal degene ben die kritiek heeft op dingen die MS doet (omdat het meeste wat ze doen alleen in hun eigen belang is), ben ik het toch niet met je eens. Met de hele ODF vs OOXML discussie gingen er allemaal geluiden op als "waarom maken ze hun eigen formaat en gaan ze niet gewoon met ODF werken?". Zou je ze ook op zo'n manier af hebben lopen zeiken als ze wél met ODF mee hadden gedaan (en dus aan de open source kant stonden)?
Nu doen ze eindelijk The Right Thing^(tm), en helpen ze mee met het open protocol in plaats van wéér hun eigen meuk te maken en er doorheen te drukken, en is het weer niet goed? Sorry hoor, maar in dit geval juig ik MS toch echt toe, ook al heb ik zelf geen computers met windows meer.
En over de ee&e... ik zie het zo'n vaart nog niet lopen, als het allemaal begint met een goed gedefinieerde standaard. Als ze zelf mee helpen kunnen ze al aangeven wat ze in het protocol willen zien (MS's kritiek op ODF was onder andere dat het niet geschikt was voor MS Office), en als ze geintjes proberen te flikken zullen ze er hoogstwaarschijnlijk het meest zelf mee zitten, als ze straks als enige met een incompatible implementatie zitten.

[Sissors]

Zou je ook kunnen uitleggen wat microsoft had moeten doen zodat ze niet door jouw en wat andere hier worden afgezeken?

Ze doen mee met een open standaard dus wil microsoft blijkbaar een monopolie krijgen door later extra dingen toe te voegen.

Alternatief:
Ze doen niet mee met een open standaard. Moet ik nog uitleggen wat we dan voor een reacties hier krijgen?

[Sissors]

Ja daar ben ik ook blij mee. Ik vind de nieuwe ribbon interface geweldig werken. En ik ben blij dat MS het aangedurft heeft om de complete interface overhoop te gooien.

[latka]

IBM lijkt hier het monopoly te hebben, maar eigenlijk is het mainframe de monopolie: als je een IBM mainframe hebt gebruik je IBM MQ. In de mainframe wereld is men niet heel erg blij met embrace and extend en de mannen met baarden die daar meestal werken niet erg gecharmeerd MS, dus zo'n vaart loopt het voorlopig niet.

[hiostu]

MQ series is een vorm van message queuing, echter heeft Microsoft op hun eigen platform ook een message queue genaamd MSMQ. Server producten zoals Biztalk kunnen zowel MSMQ als MQSeries gebruiken voor berichtuitwisseling. Dus wellicht heeft IBM een monopolie positie op hun mainframes, maar het is niet de enige implementatie.

[Nico Klus]

Duopoly: IBM en Tibco.

"According to Gartner, IBM and Tibco between them control a whopping 93% of the MOM market, which the research firm estimates will be worth around $725 million this year (2008)."

[Roland684]

Vlak Tibco ook even niet uit, zowel met RendezVous als EMS/JMS. Dat wordt toch bij een groot aantal van de grootste bedrijven van Nederland intensief gebruikt.

En dan is er ook nog SAP-XI dat door SAP gepushed wordt om ingezet te worden overal waar SAP gebruikt wordt.