ESBが目指すこと

ネーミング・サービスとレジストリ／リポジトリ

ESBはどんな形であれネットワークを構成します。XMLを扱うネットワークアプラインスがあったり、ネットワーク・ベンダーがサービス指向を提唱したりするように、SOAもネットワークを意識していますから自然なことです。ただし、ネットワーク上のノードはサービスそのものになります。

ネットワークにはノードを識別するためのネーミング・サービスが必要になります。まったく同じ機能ではないですが、WebサービスではUDDI（Universal Description、Discovery and Integration）がこの役割を果たしますが、UDDIはディレクトリとしてターゲットとなるサービスを検索するのが本来の役割であり、CORBAではトレーダ・サービスというネーミング・サービスとは異なるサービスに相当します。

もちろん、UDDIを利用することでもいいのですが、もともと、アクセスするサービスがわかっている場合にサービスの位置情報に変換するサービスを提供するESBがあります。この位置情報管理サービスはサービスの活動状況もモニタすることで、サービスが障害となったときに冗長化したサービスのフェイルオーバを実現し、同じ機能のステートレスな複数のサービスの負荷分散を実現することも可能です。負荷の高いネットワークやミッション・クリティカルなネットワークの場合は、このような高い性能をカバーするESBのネーミング・サービスを利用することが有効です。

UDDIはサービスを検索するディレクトリに相当するものであり、レジストリと呼びます。つまり、サービスのカタログに相当します。一方、レジストリの他に集中化するデータベースとしてリポジトリがあります。レジストリはサービスの登録情報などのポインタに相当する情報ですが、リポジトリはWSDLなどのサービス利用を運用するためのメタデータやサービスレベルなどのガバナンスのための情報を格納します。

また、セキュリティのポリシーやESBの構成要素のコンフィグレーション情報なども搭載し、集中管理することになります。広範なネットワーク上の構成や設定を管理する上でレジストリとリポジトリとESBと組み合わせは、非常に重要になってきます。

 

SCA（Service Component Architecture）

2005年11月30日に米国でSCAが発表されました。また、1月23日に日本でSCAの説明会が行われました。SCAはBEA、IBM、IONA、Oracle、SAP、Sybase、ZendがSOAのためのオープンなAPIの仕様をSCAとして共同で決めることを発表したものです。

SCAはサービスを呼び出すためのAPIですが、Java言語についてはすでにWebサービスのAPIがJAX−WSとして標準化されています。しかし、Java言語以外には該当するAPIはなく、本来のSOAを推進する上でC++やCOBOL、あるいは、PHPといった言語に依存しない共通のAPIを決める必要があるとして終結したものです。さらに、BPELも対応する言語としています。

また、すでに仕様化が進んでいるSDO（Service Data Object）はデータベースやファイルなどのデータの形式に依存しないデータへアクセス方法を提供する仕様であり、SCAのサービスの呼び出しのパラメータとして利用します。

一方、Eclipse FoundationのSTP（SOA Tooling Project）では、サービスの生成やレジストリ、リポジトリの管理、サービスの状態監視、その他の運用管理などを司るツールの共通のフレームワークを開発しようとしています。このSTPの最初の目標がSCAのメタデータの仕様のサポートになります。

各ベンダーがSCAを実装することに大きな意義があります。それぞれのベンダーの実装テクノロジーが異なるはずですから、SCAは言語に依存しない、また、さらに、テクノロジーに依存しない、SOAの開発と運用環境を構築しようとするものだからです。