Hoi Hans en Danny 
 
In de eerste plaats lijkt het me goed om te onderkennen dat (los van de marketing) er wel een "message bus" maar geen "service bus" bestaat. Elke relatie tussen de bus en een SOA moet dus gevonden worden doordat er kennelijk zaken om de bus heen georganiseerd zijn. Hetzij in de infrastructuur, protocols, applicaties hetzij organisatorisch/procedureel of een combinatie daarvan. Of "het web" ons dan helpt bij SOA weet ik eerlijk gezegd niet, in elk geval is dat voor intra-bedrijf communicatie niet heel handig, waarschijnlijk wel voor inter-bedrijf communicatie. Ik hanteer al lange tijd "standardize on protocols, not on tools". En vanuit dat perspectief kan ik Danny's keuze goed volgen. Maar soms moet je ook praktisch/opportunistische keuzes maken. En voor intra-bedrijf communicatie kan een ESB dan goed bruikbaar zijn. En anders maar een andere vorm van SOA middleware. Wat wezenlijk is voor een SOA is hoe je rond de beschikbare infrastructuur je SOA georganiseerd hebt. Hoe definieer je de services, welke governance is daarvoor nodig, en hoe vertaal je de services naar de beschikbare applicaties en infrastructuur. Het bijzondere daarvan is dat we zoveel mogelijk naar loosely-coupling streven en dat betekent o.a. dat weliswaar het protocol op enig moment vastligt maar dat wat elke partij voor en achter dat protocol doet los van elkaar staat. Dus ook bij het bedenken van services kan de één dat heel anders doen dan de ander. En dat maakt dat waar velen proberen eenduidigheid rond SOA te creëren, de essentie van SOA juist is dat die eenduidigheid beperkt is tot het gedefinieerde protocol. Kortom SOA middleware is weliswaar nodig en hoe breder de scope van het gebruik van je services hoe meer standaard de protocollen van de middleware zullen moeten zijn, maar veel belangrijker voor SOA is het hele concept bovenop de techniek om partijen via loosely-coupled services met elkaar te laten interageren. 
 
mvg, Jan