Service Orientation est moins sur la technologie et plus sur la conception. Je suis cetain vous pouvez utiliser ces technologies dans une SOA sans aucune question, mais ils sont juste cela, les choix de mise en œuvre. De la même manière Java, .NET peut être un choix d'implémentation pour les applications. De retour à votre question, MongoDB est un magasin de persistance, donc dans une SOA il serait assis derrière une couche de service qui protégerait les utilisateurs en amont de ce fait, vous pourriez le faire plus tard avec le prochain le plus utile, populaire, magasin de persistance et les utilisateurs ne seraient pas les plus sages. Même chose pour OpenESB, ESB est un modèle que vous pouvez utiliser pour implémenter certains aspects de l'orientation de service, à savoir le routage, pub/sub, la transformation des messages, etc. Votre choix d'implémentation est simplement OpenESB, faites la même chose, bouclier le choix d'implémentation derrière une interface stable. La meilleure façon de mettre en œuvre ces interfaces est de créer des interfaces axées sur les capacités, c'est-à-dire axées sur le quoi et non sur le comment.
Voici quelques exemples pratiques de la création d'une architecture SOA à l'aide de WCF. Je réalise que .Net n'est peut-être pas votre choix d'implémentation, mais les principes sont valables en tant que principes SOA. Je suggère que vous lisiez des articles de Thomas Erl et Roger Sessions, cela vous donnera une idée précise de ce qu'est la SOA.
Building a SOA
SOA Design Pattern
Achieving integrity in a SOA
Why your SOA should be like a VW Beetle
SOA explained for your boss
WCF Service Performance