スイスのPaudex(プデ)に本社を置くNestlés Nespresso SA(SAはフランス語で株式会社の意)が近ごろ発表したところによると、自社用SOA基盤「NesOA」を導入する最初のフェーズをたった6ヶ月で完了したという。このNepresso Open Aruchitecture、略してNesOAと呼ばれる新しいミドルウェアアーキテクチャの設計と実装においてはOptaros社(マサチューセッツに本社のあるオープンソースを得意とするITコンサルティング会社でスイスにも支社がある)(リンク)とMuleSource社(オープンソースのSOAソリューションMuleのプロバイダ)(リンク)によるサポートがあった。
プレスリリース(リンク)および公開されたケーススタディ(リンク)によると、
Nestlés Nespresso SAは50以上の国でお客様に製品を直接販売し、世界中の主要都市で117もの高級ブティックを開いています。(中略)オンラインのチャネル利用を大きく広げるために、そして既存のチャネルは規模を拡大できるように、Nespressoは新しいアーキテクチャやシステム連携の方法を探していました。 NespressoではNespresso Open Architecture、略してNesOAと呼ぶ新しいミドルウェアアーキテクチャの設計と実装において自社のアーキテクチャチームを支援してもらうためにOptaros社およびMuleSource社と契約をおこないました。
InfoQはNespressoのエンタープライズアーキテクトであるJoel Schmitt氏と会う機会を得、このSOA基盤についていくつかの質問をした。
InfoQ: プレスリリースにはNespressoのエンタープライズアーキテクトJoel Schmitt氏、つまりあなたの言葉として「私たちはMuleSourceのMule ESBを始めとするオープンソースを使ったアプローチに熱心に取り組んでいます。なぜならオープンスタンダードに準拠することは、将来の拡張性と成長の鍵になるからです。」とありますね。
この言葉からすると、オープンソースとオープンスタンダードとでは得られるメリットに微妙な違いがあり、いずれもメリットはあるものの両者が必ずしも相互補完的なものではないというニュアンスがあるように思えます。御社がしようとしているような多くのチャネルの統合というのを考えると、ESBが最新のウェブサービス標準をサポートしていること、あるいはRESTfulなエンドポイントであればWS-* (ウェブサービス標準を総称する用語)をサポートしていることは相互運用性という面で重要なことですね。今回のシステムが可能にしている相互運用性の水準はどれくらいなのでしょうか。また転送についてはどのようになっていて、どんなメッセージ転送がサポートされているのでしょうか。
JOEL: オープンスタンダードを最初に取り入れるのは大抵オープンソースですが、完全にカバーする・カバーされるということがないのも事実です。たとえばMule ESBはJBI(Java Business Integration:JavaでESBを実現するための仕様)に準拠しているわけではありません。それでも私たちはMule ESBを使っています。オープンソースとオープンスタンダードは、どちらもベンダ依存せず、さまざまなシステムとの連携や異なる連携を簡潔におこなえるようにするための対策の一環なのです。エンドポイントという点について言えば、私たちはWS-*とRESTfulなエンドポイントの両方をサポートしたいと考えていて、今それができるのはMuleとJBossです。システム連携に必要なものはいろいろで、サービスに関するものであったり、リソースに関するものであったり、メッセージに関するものであったりします。私たちはその全てを解決したいと思っています。
InfoQ: この基盤上で多様なチャネルを利用可能にするためにされていることは何でしょうか。「Nestlés Nespresso SAは50以上の国でお客様に製品を直接販売し、世界中の主要都市で117もの高級ブティックを開いています。」という説明にあるような多くのチャネルをきちんと提供できるようにしている対策は何でしょうか。
JOEL:標準の統合プラットフォームがあるということは中央集中的システムであるというわけではありませんし、いろいろなデプロイのやり方に対して私たちは門戸を開いています(Mule ESBによって完璧に分散モデルを実現できます)。またサービスをベースにした社内標準とそれに対するファサードを作ることができる(限界はありますが)ESBを使えば、連携するのにかかる関係者の労力も最低限ですみます。
InfoQ: よく「このESBを使って我々のアプリを統合しよう」という話は聞きますが、この基盤が他のと違う特徴はありますか?たとえば、ビジネスプロセスの分析・抜本的再構築によって効率化を実行するのにかかる労力がどれくらいかということや、今おっしゃったサービスの再利用はどれくらいまでを検討しているのか、再利用されることになるはずのサービスについて多方面のチームが取り組むのに(もしそうしていれば)どのような方法を採っているのでしょうか。
JOEL: レガシーアプリケーションは、各方面ごとに新しい社内サービスを作ることを念頭に統合されていて、可能であれば次のプロジェクトでそれらのサービスを利用するつもりです。NesOAはNespressoのミドルウェアプラットフォームを再構築する試みであり、それにはビジネス分析/モデリングと実装の両方が含まれているのです。
InfoQ: そういったサービスの定義、設計、開発、デプロイ、管理といったことにはどのような方法論を採られているのでしょうか。何か定型的なプロセスがあるのでしょうか?実装について方策はあるのでしょうか?実装の完了はどの時点を指すのでしょうか?
JOEL: NesOA プロジェクトは2年前にいくつかの試験的プロジェクトを立ち上げたところからスタートしました。確かにこれはビッグバン方式ではありませんが、ミドルウェア基盤を再構築して進化させるものです。そしてそれはプロジェクトのポートフォリオをベースにしたビジネス主導の方法です。各プロジェクトからは機能的・非機能的な要求・条件・変更について情報がもたらされます。
InfoQ: 最近「SOAは死んだ」とも言われますが、あなたが経験から学び、同じような試みをしている他の企業でも用いることができる、あるいは用いるべき成功へのキーは何でしょうか。
JOEL: NesOA はSOA関して「オープンアーキテクチャ」であること以外なにものでもありません。私たちはSOAのソフトウェアや技術を利用していますが、SOAを改革しようとしているわけではありません。それに「SOAは死んだ」と言ったとしても、それはエンタープライズアーキテクチャや分散システム、サービス指向、アプリケーション統合がなくなったことを意味するわけではありません。それらは大企業のITのまさに今ある現実ですし、そもそもそれらは現実についてのことでしかありません。なくなるとすれば、サービス指向自体のためだけに大規模な設計変更を導入してサービス指向を実現しようとすることでしょう。
近ごろの景気を考れば、死んだと言おうが生きていると言おうが、SOAが企業においてコスト節約やビジネスの効率化の手立てとなるかが重要だ。サービス指向とアーキテクチャの適切な配合法を知る上で、NesOAはその手がかりとなるのではないだろうか。
原文はこちらです:http://www.infoq.com/news/2009/01/optaros-nestle-mulesource-soa