Essence is Real

ThinkITには、時々、記事を書かせていただいているのですが、アイオナが中心となってObjectWebでホストされているCeltixのバージョン1.0についての紹介記事を3回に分けて掲載していただいています。オープンソースのESBにどの程度の関心がおありになるのかは、正直、よく理解していませんが、ソフトウェアベンダーのほぼすべてがSOAを標榜している中で、ESBはSOAの基盤として必須のものであると考えると関心があってもいいのではないかと思います。いかがでしょうか。

Celtixは、サンプルを23個バンドルしているので、それを中心に記事を書こうと持ったのですが、23個のサンプルを確認しながらREADMEを翻訳するという作業の結構時間がかかってしまいました。また、CeltixがヨーロッパのObjectWebからApacheに移行することが決まっており、CodehausのXfireと合併して、ApacheのインキュベートであるCeltiXfireが開始しているので、サンプルの記載は、まだ、遅れています。

江川

テレコム業界向けのシステムは、OSS（Operation Support System）と呼ばれる電話やブロードバンドなどのテレコムの各種サービスを提供するためにネットワークを運営するのに必要なシステムやBSS（Business Support System）と呼ばれるビジネス寄りの受注や課金といった機能のシステムで構成されています。

また、テレコムのネットワークは物理的なネットワークを構成するNE（Network Element）と呼ばれる交換機や伝送装置とそれらを管理するEMS（Element Management System）と呼ばれるレイヤー、さらに、その上位で回線などのエンドとエンドを構成するNMS（Network Management System）のレイヤーがあります。また、IP電話やビデオ、ブロードバンドによるデータサービスなどのサービスを管理するためにSMS（Service Management System）のレイヤーがあります。つまり、物理的なネットワークから上位レイヤーへ向けて抽象化度を上げながらシステムを構成し、マーケットへテレコムのサービスを提供していくのが、全体の構図です。

NEについても、いろいろなベンダーがいろいろな装置を提供しますし、その上で作られるEMSやNMSも各社が独自に開発すればそれぞれがまったく異なる考え方に基づいていたりします。さらに、パッケージ製品として、たとえば、NEをベースとするネットワーク上のリソースを管理するインベントリ・システム（ネットワーク要素の在庫管理）やネットワーク上の障害の情報を収集して分析する障害監視システムなどの機能をもつ製品は、それぞれに独自のデータベース構造で設計されています。

これらの異機種混合の複雑なシステムをインテグレーションしなければ効率の高いサービスは構築することができません。さらに、このインテグレーションした基盤の上に、新しいサービスを提供するための機能を迅速に開発し、運用しなければなりません。これは、まさに、SOAが目指すシステムの在り様です。しかし、これだけ、多くのソリューション・プロバイダーが密接に絡む場合には標準化が絶対的に必要です。テレコムではNEをはじめ、古くから標準化が進められており、OSSのインテグレーションでもCORBAを大々的に利用していきました。

システム・インテグレーションの標準ひとつがTMF（Telemanagement Forum）が規定して、最近、ITU-TへサブミットされたMTNM（Multi-Technology Network Management）と呼ばれるTMF814ドキュメントを中心としたインタフェースです。このインタフェースは、NMSのレイヤーで適用されるCORBAベースのインタフェースになります。一方、商用パッケージ製品のように、すでに、システムと完成しているOS（Operations System）を連携するには、MTNMはFine Grainすぎます。より抽象化された疎結合のインタフェースが必要となります。これに対して登場するのがMTOSI（Multi-Technology Operations System Interface）です。MTOSIはWebサービス（SOAP）をベースとしたインタフェースを規定しています。

MTOSIは、その考え方と実装ともにSOAに基づいていると言えます。インタフェースとしてサービスを規定し、Webサービスの疎結合のインタフェースで実装することで、従来は難しいとされたOS間の連携を現在から将来へかけて効率化していくものとなります。

アイオナでは、TMFのCatalystの活動の中でMTOSIへの適用を実証しており、商用でも、適用事例があります。また、アイオナのArtixはCORBAをネイティブに連携しますので、テレコムのシステムの中でもっとも広まっていると言われているMTNMを完全にサポートし、さらに、MTOSIによるインテグレーションにシームレスに展開することができます。さらに、これらのインテグレーションを実践するデモシステムとして、MTOSI Tool KitとIONA Microsoft Telecom Tool Kitを公開しています。

江川

Burton GroupのResearch DirectorのAnne Thomas Manes氏のブログにApacheのSOAPスタックであるAxisとAxis2の簡単な比較がありました。Axis2はApacheの次世代のSOAPスタックと言われており、2007年の実用のリリースを目標として、SOAPとRESTの機能を提供します。Axis2のバージョン1.0は2006年4月にリリースされています。

Axis（2ではない）は、現在はメンテナンス状態のようですが、製品に取り込まれたりして、多く使われてきました。確かに性能の面では、多少、難点はあると感じましたが、J2EE系に対するオープンソースのSOAPスタックとしては健闘したのではないでしょうか。ブログの中では次のような簡単な歴史が示されています。

世代1：Apache SOAP
IBMのSOAP4Jをベースとして、2000年から2002年まで提供されていたDOM（Document Object Model）ベースのSOAPメッセージ処理をサポートしていました。

世代2：Apache Axis
完全に再設計されたSOAPスタックであり、WSDL、JAX-RPC、SAAJ（SOAP with Attachments API for Java）をサポートします。2002年に1.0がリリースされて、2006年4月に1.4がリリースされています。メッセージ処理はSAX（simple API for XML）ベースです。

世代3：Apache Axis2
SOAP1.2、WSDL2.0やWS-*の標準のいくつかをApacheの別のプロジェクトから取り込んでサポートします。独自のAxiom（Axis Object Model）によってXMLを管理し、SAXやDOMに変わるStAX（Streaming APIs for XML：JSR173）によるXMLの解析をサポートします。

Axis2は、まだ、実用の段階ではないので、Axisに対して、先のブログのコメントにあるように、codehausのXFireがSOAPスタックの対抗としてあり、性能の面で高い評価を受けています。しかし、今、現在、XFireはCeltixと合併して、CeltiXfireとなって、Apacheのインキュベートを開始しています。この合併の前のことではありますが、XFireのサイトの中で、Axis、Axis2、CeltixなどのSOAPスタックの比較表が示されています。Axis2はJAX-WSに対応するようなので、この比較表もメンテしなければならないでしょう。

単純なSOAPスタックということではなく、それぞれの方向性によって違いが出てくるのではないかと思います。単純なSOAPスタックでは、早晩、淘汰されてコモディティになるだけですので。

江川

eWeekのApplication Developmentの中の製品レビューのコーナーでアイオナのArtix 4.0を含むESB製品の評価が掲載されています。元来、製品を単純に比べて比較することにどれくらい意味があるのかは疑問ではありますが、eWeekの記事は非常に簡単で大雑把なので、その点では、大まかな比較としてのご参考にはなるかと思います。

現時点で比較対象となっているのが、アイオナのArtix4.0、Cape Clear Software Cape Clear ESB 6.6
、Sonic Software Sonic ESB 7.0です。比較項目毎の評価は次のとおりです。

よく機能を比較して、○×△で評価する場合がありますが、実際には、どんな機能が必要であり、どのようなアーキテクチャがベストであるかを検討されるべきです。その点では、ArtixについてはSCALABILITYはEXCELLENTにしてほしいところです。WebコンテナもEJBコンテナも必要ないし、ブローカも必須ではないですからアーキテクチャ上、SCALABILITYにボトルネックはありません。

もう、一点の着目点は初期費用ですが、これについては詳しくは記事をご覧ください。ただし、記事はUSでの内容ですので日本での費用は異なります。

江川

Open SOA（OSOA）のサイトはご存知でしょうか？

2005年11月30日にIBM、BEA、IONA、Oracle、SAP、SYBASEなどが共同で発表したSCA（Service Component Architecture）と、その以前から活動のあったSDO（Service Data Objects）のコミュニティのサイトが、OSOAです。当初はバージョン0.9の仕様が公開されましたが、現在は、バージョン0.95へアップデートされています。おそらく、今年の末くらいまでには、バージョン1.0となり、標準化団体への標準化の提案をすることになると思います。

同じくOSOAは、2006年7月に、SUN、TIBCO、Progress Software（ソニックソフトウェア）、RedHat、CapeClearなどが参加して、合計で17社が参加するコミュニティとなりました。日本でも、2005年11月の発表を受けて、コラボレーション・チームというのを作っています。今年の8月に勉強会を開催した以外は特に活動はしていませんが、本家の方の活動でイベントがあれば日本でも対応するかもしれません。

このOSOAでサポーター・プログラムが発表されています。SCAの仕様検討は、Assembly Model、Policy＆Binding、Client Implementationの3つのワーキンググループで進んでいますが、このような仕様検討には参加せずに、サポーターは、OSAOのメンバーサイトにアクセスでき、メイリングリストに参加し、詳細な情報を入手できる立場となります。その換わりに、仕様に対する市場からのフィードバックをコミュニティへ返して欲しいというものです。

サポータープログラムには、こちらからメイルを送信していただき、ロゴやURLを登録することが必要なようです。特に負担はないと思いますので、日本の国産ベンダーさんにも参加していただければと考えております。

江川

2006年9月24日の日経新聞に「航空機市場の拡大」という記事が載っていました。ここで、CORBAがボーイング社のシステムで使われているということをお話したいわけではありません。中小型機の売り上げが伸びているという話題です。

航空機の大手2社（米ボーイング社と欧州エアバス社）の2005年の受注数は、2004年の3倍となっています。その中で、中小型機で、たとえば、ボーイングのB787やB737の受注が伸びており、一方、大型機の需要が伸び悩んでいます。この状況のひとつ目の理由は、格安航空会社の伸びです。コストを削減するために小型の同一機種を大量に運行させること、需要に柔軟に対応できるからです。二つ目の理由を引用すると次のようになります。

航空会社のニーズの変化があります。従来は大規模な空港を拠点（ハブ）とし、ハブ空港を経由して他の都市に向かう「ハブ・アンド・スポーク」の運航が中心でした。しかし、最近利便性を求める顧客の声を受けて、できるだけ多くの都市間を直行便で結ぼうとする動きが広がっています。
経済発展に伴って途上国間を移動する旅客数が急速に増大していますが、これまでのように先進国のハブ空港経由では時間がかかりすぎ、客を逃してしまいます。特にインドと中国で旅客需要が急増していまっす。こうしたことが中型機B787の人気を高める要因となっています。

インテグレーションの需要は、トップダウンで発生するものではなく、ボトムアップでエンドポイントから発生します。つまり、ハブではインテグレーションの市場を制御することはできないということです。エンドポイントの重要性を再認識し、いかに、エンドポイント同士を有効に連携するかを決めるのが、ESB（Enterprise Service Bus）のアーキテクチャです。

江川

アイオナの嶋田さんが開発したEclipseのプラグイン－ORB Studio 7－をオープンソースとして公開しています。ORB Studio 7は、Eclipse環境でCOBRAのサーバとクライアントを効率的に開発することができるように次の機能を提供します。

詳しくはOrbZoneにポストされておりますのでご参照ください。ダウンロードもOrbZoneから可能です。なお、もとのサイトはこちらです。

江川

少し以前（2006年7月10日付け）のSearchWebService.comの記事ですが、原題は、

Analysts see Java EE dying in an SOA world

すべてを、そのまま受け取ることもできないのですが、私の意見としては、ひとつは、JavaEEはアプリケーションを開発するためのプラットフォームであり、エンタープライズ全体のインフラを支える基盤としては重過ぎるということと二つ目は、SOAは抽象化度を上げていくのが、アーキテクチャの目標となるべき課題であり、抽象化度を上げるためにはLayered構造になっていることが必然であるとするとMVCモデルのようなTiered構造ではアプローチとして無理があるということです。ただし、SCA（Service Component Architecture）などの動向を見極める必要はあります。

江川

日経ITproの記事で、ユーザーがSIerやITベンダーに過度に依存せずに自らITを理解して、ITプロフェショナルとして、情報システムを進化させていかなければならないのではないかという内容です。結論はユーザーがITプロフェショナルであるべきであるというものですが、詳しい内容はITproを参照してみてください。

この記事の中では、経営とITの融合、ビジネスとITの融合とユーザーという言葉は使っていませんが、ユーザー側がいかにITと意味のある関係を作るかということでは、ユーザーがITプロフェショナルであるべきかという課題と同じ筋の問題だと思います。経営とITの融合では、KIU研究会（経営のKとITのIと融合のU）という集まりがあり、ITメディアのアジャイル・エンタープライズというサイトで、結構、いろいろなところから人を集めてBPM（ビジネス・プロセス・マネージメント）について議論をしています。このKIU研究会に関連する団体として、日本BPM協会があります。

ここではBPMを媒体としたユーザー側とITの融合ということではなく、もっと、本質的なユーザーがITにどれくらい関心をもち、そのような戦略で投資するかという問題です。記事の中で欧米のユーザー企業は数千人のIT要員を抱えているということが記載されています。それとは直接関係はありませんが、あるヨーロッパの企業の情報システム関係の要素は次のようになります。

要員とはEmployeeという表現ですので従業員のことになります。ITが要となる業種ですので力の入り具合が違うということはありますが、自らの懐の中にこれだけの要員を抱える必要性があると思っているわけです。

世の中には多様なユーザーの要件があり、それらを、そのまま、すべて、ITの力でカバーすることはできません。その結果としてユーザーは常にITの結果に満足することができすに欲求不満のままとなります。経営とITの融合でも、ツールやインタフェースの進歩が必要ですが、本質的には経営（ユーザー）がITを理解して歩み寄らないとうまく行かないと思います。

江川