ＳＯＡに求められるプログラミング・モデル WebSphere Process Server V6 SOAに求められるプログラミング・モデル Copyright IBM Japan Co.,Ltd. 2005

WebSphere Process Server V6
SOAに求められるプログラミング・モデル
ＳＯＡに求められるプログラミング・モデル
∼サービス・コンポーネント・アーキテクチャ概要∼
日本アイ・ビー・エム株式会社
ソフトウェア事業．WebSphere TS & S
樽澤広亨
Copyright IBM Japan Co.,Ltd. 2005
1
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
内容
„SOA概要
„SCA概要
„SDO概要
2
Copyright IBM Japan Co.,Ltd. 2005
2
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
Service Oriented Architecture (SOA)
概要
Copyright IBM Japan Co.,Ltd. 2005
3
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SOAとは
SOAとは、「サービス」の組み合わせによってアプリケーションを構成
するシステム構築の考え方。
• 業務処理などの単位でサービス化すること
• オープンで標準的なインターフェースでサービスを定義し、呼び出すこと
柔軟なビジネス・モデル
トランスフォーメーション
業務プロセス・アウトソーシング
合併、吸収、子会社化
業務プロセス
の組み立て
柔軟な ITアーキテクチャー
サービス指向アーキテクチャー (SOA)
サービスの
組み立て
4
SOAとは「サービス」の組み合わせによってアプリケーションを構成するシステム構築の考え方で、以下の特長を持ち
ます。
•業務処理などの単位でサービス化すること
•オープンで標準的なインターフェースでサービスを定義し、呼び出すことによりロケーションの透過性、プロ
トコルに対する非依存性を実現
SOAの狙いは、ビジネス・トランスフォーメーションや企業の吸収・合併など、ビジネス環境の変化に迅速に対応する
ためのIT基盤を作ることです。そのためには業務を熟知し、業務が最適に遂行されるべく業務プロセスを見直して組
み立てることが重要になります。また、ビジネス環境は恒常的ではなくさまざまな要因で変化します。 そのような変化
による業務プロセスの変更も迅速かつ柔軟に行われる必要があります。
一方、企業内のITシステムもまた将来のビジネスの急速な変化に対応すべく進化し、開発スピードの向上、開発・運
用コストの削減を実現していくことが重要です。 その手法の一つとして、業務の単位やプロセスを見据えながら、ある
程度意味のある大きさにアプリケーションをコンポーネント化するアプローチがあります。 こうしてコンポーネント化され
たものを「サービス」と呼びます。（「サービス」に関しては次のページで解説します）
このように業務分析の結果得られる業務プロセスの組み立てに、ITが提供するさまざまなサービスを当てはめること
により、業務の要求に近い形でITシステムを構成することが可能になります。 このサービスを環境に依存することな
く容易に呼び出したり、組み立てることを実現するためのアーキテクチャーをSOA（サービス指向アーキテクチャー）
といいます。
Copyright IBM Japan Co.,Ltd. 2005
4
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SOA におけるサービスとは
アプリケーションの処理単位を論理的に記述したもの。
– 業務処理などを可能な限り共通化し抽象化している。
– 明確に定義されて自立している。
– オープンな標準技術を使ってアクセスされる。
– サービス自身は他のサービスを取り込んで形成されることもある。
商品受注
サービス
お客様データ
サービス
在庫確認
サービス
在庫引き当て
サービス
配送手配
サービス
インボイス
発送サービス
サービス・レイヤー
• 外部から呼び出せるよう、インターフェー
スを公開（入力項目、処理内容、出力項目
が明確）
業務システム
お客様
データ
システム
在庫管理
システム
A
在庫管理
システム
B
在庫
引き当て
システム
配送
システム
インボイス
作成
システム
実績管理
システム
• アプリケーション群
• 開発言語は自由
• ラッパー / コネクターでインタフェースを
統合
在庫補充
サービス
5
SOAでいうサービスとは、業務の単位やプロセスを見据えながら、ある程度意味のある大きさにアプリケーションをコンポーネント化
したものです。ただし、サービスと呼ばれるためにはいくつかの条件を満たす必要があります：
•業務処理などを可能な限り共通化し抽象化している。
サービスを実際に活用するのは、実業務に携わる部門担当者です。
よって、実務を担当する人たちが理解できる塊でアプリケーションをとらえることが重要です。
また、共通で利用されるためには、サービスは個々の業務特有なものではなく抽象化されていることが望ま
しいと言えます。
• 明確に定義されて自立している。
サービスは業務のさまざまな局面で利用されるものです。
例えば、「在庫引き当てサービス」はWebで
のオンラインショッピングのプロセスでも、直販セールスから業務を経由して発注されるプロセスでも、ビジネ
ス・パートナーが利用するオーダリング・システムの中でも利用されるべきものです。
また、今後別のプロセスから呼び出されることもあるかもしれません。全く異なる部門の複数のプロセスから
「在庫引き当てサービス」が呼び出される可能性があるため、
サービス自身は処理する内容が明確に定
義されており、公開されている必要があります。
ただし、内部的にどのような処理がなされているかは公開する必要がないため、内部ロジックのノウハウを公
開する必要はありません。
• オープンな標準技術を使ってアクセスされる。
上記の通り、サービスは多数のプロセスから呼び出される可能性があるため、今後活用範囲が広くなるとプ
ラットフォームやプロトコルに依存せずに利用されることが求められます。
Webサービスなどのオープンな標準技術を使って作ることで、より多方面で利用されるサービスを整備するこ
とができます。
• サービス自身は他のサービスを取り込んで形成されることもある。
よくサービスの粒度に関する解釈でさまざまな見解がでることがあります。
“商品受注”をサービスの単位と見立てるのか、その中の”在庫引き当て”も単独のサービスとみたてるのか、
さらにはその中の”在庫が少なくなった際の在庫拡充処理”をサービスととらえるのか・・・、など。 ある意味、
これはどれもがサービスであるということができます。 そして、この図にあるとおり、一つのサービスの中が
複数のサービスで構成されていることもあります。
その際、このページで述べているサービスであるための条件を満たしていることが前提となります。
Copyright IBM Japan Co.,Ltd. 2005
5
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
エンタープライズSOAシステムに求められる要件
„Agility
‹テクノロジへの非依存性
‹再利用性
‹統合容易性
‹開発と運用の容易性
6
スピーディなビジネスを実現する、言い換えればビジネスのアジリティがＳＯＡの目的のひとつです。
これまでＩＴはビジネス構築に多大な貢献をしてきました。一方ＩＴの進化と共に機能が複雑化し、またベン
ダ間のアーキテクチャの相違などもあって、一般的な企業システムは異機種混合の構成となっています。
結果的に、ＩＴはビジネスのアジリティ実現の阻害要因となっているのです。言い換えれば、ＳＯＡシステム
に求められる要件としてアジリティが、ありＩＴにもアジリティの実現が求められます。
具体的に言えば、次の４つを挙げることが出来ます。
一点目として、ＳＯＡにおけるＩＴ実装は特定のテクノロジに非依存であることが求められます。固有のテク
ノロジに依存したＩＴ実装は変革を阻害することがあるためです。
二点目として、再利用性に適切なＩＴシステム設計が求められます。これは開発者に加えてエンドユー
ザーの視点からも再利用の価値が見出せるものでなければなりません。エンドユーザーの視点より再利
用が容易であることが、即ちビジネスの再利用に繋がり、最終的にアジリティを実現するのです。
ＳＯＡシステムは既存のシステムを再利用しながら、新規ビジネス・ソリューションを構築してゆく考え方で
す。よって三点目の要件として、統合が容易であることを挙げます。容易な統合を実現するためには、粗
結合の設計に基づいてＩＴシステムを実装するべきです。
最後の要件として挙げるのが、開発と運用の容易性です。アジリティを求めるためには、開発のスピード、
迅速な運用が絶対条件として必要です。担当者が変わっても素早くキャッチアップできる容易な開発・運
用テクノロジであることが重要です。
Copyright IBM Japan Co.,Ltd. 2005
6
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SOAに求められるプログラミング・モデル
„ テクノロジへの非依存性
„ 再利用性
‹ 通信プロトコルへの非依存性
‹ プログラム実装言語への非依存性
‹ データ・マッピングの柔軟性
‹ アプリケーション配置場所(エンドポイント)の透過性
„ 統合容易性
‹ リクエスタとプロバイダ間の多様なインタラクション・モデル
z
z
同期型
非同期型
„ 開発と運用の容易性
‹ ストロング・タイプのインターフェースを介したコラボレーション
‹ 関心事の分離
‹ Ease
of Development (EoD)
7
アジリティが求められるＳＯＡシステムを実装するためのプログラミング・モデルに何が求められるのでしょう。
プログラミング・モデル自身が特定のテクノロジ、つまり特定の通信プロトコル、データ・フォーマット、ＯＳ、ミドルウェア
に依存しないことが求められます。
プログラム間通信を行うに際して、お互いのプログラム実装言語が隠蔽され、かつお互いのアプリケーションの配置場
所（物理的なエンドポイントのアドレス）に透過的であるべきです。これらの要件を満たすことで再利用性が格段に向
上します。
更に、リクエスタとプロバイダ間のインタラクション・モデルとして同期型要求応答形式（ＲＰＣ）に加えて、非同期型のイ
ンタラクション・モデルが求められます。非同期型のインタラクション・モデルの実装であるＭＯＭは、通信相手のシス
テムのプラットフォームの違いを隠蔽し、また相手の稼動状況に関わらず通信を行うことが可能です。非同期型のイン
タラクションは統合容易性の重要な要素である粗結合を実現するのです。
開発と運用の容易性も必要です。この要件を満たす上で重要なのが、ストロング・タイプのインタフェースを介したイン
タラクションです。ストロング・タイプなインターフェースとは、オペレーションの名前、パラメータと戻り値の型を厳密に
規定したインターフェースです。このようなインターフェースを用いることで開発時に型に纏わるコーディング・ミスの発
生を抑えることが出来ます。またストロング・タイプのインターフェースを入手すれば、見ず知らずの開発者が実装した
サービス・プロバイダとコラボレートするサービス・リクエスタを実装することが出来ます。つまり、ストロング・タイプのイ
ンターフェースはバグの抑制に加えて、コンポーネント間の規約として機能する最も重要なエンタープライズＳＯＡシ
ステムの要素なのです。加えて、ビジネス・ロジック実装者が、その責務に集中できるように（関心事の分離）、特定の
テクノロジ固有の細々とした実装を分離、隠蔽する仕組みが必要です。実装者の負荷を軽減し開発時間を最適化す
るために、コード生成やエラー・チェックなどのツール類を中心としたＥｏＤの推進も重要です。
Copyright IBM Japan Co.,Ltd. 2005
7
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
IBM SOA プログラミング・モデル
JSP
SDO
JSF
SCA
SDO
SCA
Common
Event
Infrastructure
Portlet
エンド・ユーザ
クライアント
Business
Process
Choreographer
Servlet
ESB
SDO
Web
Services
SCA
SDO
SDO
Web
Services
Web
Services
POJO
POJO
EJB
EIS,
Mainframe
Asset
8
エンタープライズＳＯＡシステムを実装するために、ＩＢＭが提案するプログラミング・モデルには次のようなものがあり
ます。ただしこれらのプログラミング・モデルを必ず使用しなければならないわけではありません。必要に応じて、適材
適所で利用することが重要です。場合によっては競合機能を利用することが、お客様システム設計で最適な選択かも
しれません。
ポートレットは、ポータルを実現するプログラミング・モデルです。サーブレットやＪＳＰといったコンポーネントが提供す
るコンテンツを、エンドユーザーの好みに合わせて提供します。エンタープライズＳＯＡシステムにおける、サービスの
入り口にあたります。
ＳＣＡは、サービス・コンポーネントとのインタラクションを司るプログラミング・モデルです。リクエスタの呼び出しＡＰＩ、
プロバイダのモジュール化技術を提供します。
ＳＤＯは、汎用的なデータ・モデルで、引数や戻り値に使用されます。データソースに依存しないデータ・モデルであ
り、ＳＯＡのような異機種混合環境の統合に便利な技術です。
Business Process Choreographer (BPC) は、BPELの記述に基づいてサービス・コンポーネントを呼び出すワークフ
ロー機能を提供します。
Common Event Infrastructureは、多様な事象をイベントとして通知する機能です。エラーを運用管理システムに通知
する仕組みに利用することが出来ます。
Web Servicesは、インターネット・イントラネット環境における分散コンピューティング技術です。プロバイダとリクエスタ
のインタラクション方法、プロバイダのインターフェースの検索方法、データ定義、インターオペラビリティ、QoSなど
Web Servicesのカバレッジは多岐に渡ります。異機種システムを統合するのに便利です。
Copyright IBM Japan Co.,Ltd. 2005
8
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
Service Component Architecture (SCA)
概要
Copyright IBM Japan Co.,Ltd. 2005
9
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAとは何か
„ IBMが開発した、サービスのオペレーション呼び出しとサー
ビスのコンポーネント化を実現する、分散コンピューティング
技術の一つ
‹ API
‹ モジュール化技術
„ 動作環境
‹ 稼働環境：IBM
WebSphere Process Server (WPS) V6.0
‹ 開発環境：IBM WebSphere Integration Developer (WID) V6.0
„ 特徴
‹ 粗結合
‹ 関心事の分離
„ 用途
‹ サービスのコンポーネント化
‹ サービスのオペレーション呼び出し
10
Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＳＣＡ）とは、ＩＢＭが開発した、サービス・プロバイダのオペレー
ションを呼び出しとサービスのコンポーネント化を実現する、分散コンピューティング技術です。具体的に
は、ＪａｖａやＢＰＥＬなどのプログラム実装をサービス・コンポーネントに仕立てるためのモジュール化技術と、
サービス・プロバイダのオペレーション呼び出しのためのＡＰＩから成り立っています。
現在のところ、開発環境としてWID V6.0を、稼働環境としてWPS V6.0を利用します。
ＳＣＡの特徴は、粗結合と関心事の分離です。
主な用途は、サービスのオペレーション呼び出しと、ＪａｖａやＢＰＥＬなどのプログラム実装をサービス・コン
ポーネントに仕立てることです。
Copyright IBM Japan Co.,Ltd. 2005
10
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの位置づけ
BPEL とIBM独自拡張機能
ビジネス・オブジェクト
（BO;SDOベースの技術）
サービス・コンポーネント・
アーキテクチャ (SCA)
11
SCAは図のようにIBMが考えるSOA基本技術の一角をなすものとして位置づけられています。
SOA基本技術とは、サービスの組み合わせ（Composition）、呼び出し（Invocation）、データ（Data）の三つ
を柱として成り立ちます。
SCAはサービスの呼び出しを担当します。サービス・コンポーネントおよびそれらの相互インタラクションは
サービス･コンポーネントによって記載されます。SCAの中で取り扱われるデータはBusiness Objects（BO）
と呼ばれるSDOをベースとした技術で表現されることにより、標準的なデータとしての取り扱いが可能に
なっています。
SCA／BOによりサービス間の単純なインタラクションを記載することは可能ですが、「ある条件を満たした
場合にサービスAを、そうでない場合にサービスBを」といったより複雑な、ワークフロー的なサービス呼び
出しの組み合わせは、最後のBPEL（およびその拡張）により実現されます。BPELとはBusiness Process
Execution Language (for Web Services)の略でOASISに提出されたWebサービス・コレオグラフィのための
標準言語ですが、当資料ではその詳細には触れません。
Copyright IBM Japan Co.,Ltd. 2005
11
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの位置づけ
JSP
JSF
SCA
SDO
SDO
SCA
Common
Event
Infrastructure
Portlet
エンド・ユーザ
クライアント
Business
Process
Choreographer
Servlet
ESB
SDO
Web
Services
SCA
SDO
SDO
Web
Services
Web
Services
EJB
EIS,
Mainframe
Asset
POJO
POJO
12
上記イラストはＩＢＭのＳＯＡプログラミング・モデルの全体像を表しています。
ＳＣＡはサービス・プロバイダのオペレーション呼び出し方法としてリクエスタで利用します。また、ＪａｖａやＢ
ＰＥＬなどの実装をサービス・コンポーネントとして仕立て上げてサービス・プロバイダとして機能させるため
にＳＣＡを利用することも可能です。
Copyright IBM Japan Co.,Ltd. 2005
12
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
メリット 1.
透過的な分散コンポーネント・アクセスをサポート
„ 分散コンピューテイング技術を隠蔽
SCA適用後
SCA適用前
EJBクライアント
固有のコード
JMS
固有のコード
Web
サービス
EJB
RMI/
IIOP
JMS
App.
Webサービス
リクエスタ
固有のコード
SOAP
JMS
固有のコード
サービス・
プロバイダ
サービス・
リクエスタ
SCA
EJB
RMI/
IIOP
EJBクライアント
固有のコード
Web
サービス
クライアント・プログラム
Webサービス
リクエスタ
固有のコード
SOAP
クライアント・プログラム
サービス・
プロバイダ
サービス・
リクエスタ
JMS
App.
13
ＳＣＡをサービス・プロバイダのオペレーション呼び出しに使用すると、透過的な分散コンポーネント・アク
セスが可能であるというメリットを享受できます。
ＳＣＡを適用しない環境では、サービス・リクエスタは、サービス・プロバイダ固有のクライアントＡＰＩを用い
て、サービス・プロバイダにアクセスするためにコードを記述しなければなりませんでした。サービス・リクエ
スタは特定のテクノロジに依存した実装を強いられていたのです。
一方、ＳＣＡをサービス・プロバイダのオペレーション呼び出しに利用すれば、サービス・プロバイダ固有の
クライアント実装はＳＣＡ ＡＰＩによって隠蔽されます。サービス・リクエスタの開発者は、ＳＣＡのＡＰＩを用
いるだけで、Ｗｅｂサービス、ＥＪＢ、あるいはＭＯＭなどのサービス・プロバイダにアクセスするコードを記述
することが出来ます。ＳＣＡを利用することで、サービス・リクエスタは特定のテクノロジに依存しない実装を
持つことが可能になります。
Copyright IBM Japan Co.,Ltd. 2005
13
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
メリット 1.
透過的な分散コンポーネント・アクセスをサポート
„ 統合されたプログラミング・インターフェース
import com.ibm.websphere.sca.Service;
import com.ibm.websphere.sca.ServiceManager;
//中略
ServiceManager _serviceManager = new ServiceManager();
OrderService _orderService =
(OrderService) _serviceManager.locateService(“order");
_orderService.submitOrder(_orderSpec);
14
ＳＣＡのクライアント・プログラミングは、タイプ・セーフとダイナミックの２種類があります。
上記のコード断片はタイプ・セーフの例です。
ＳＣＡのクライアント・プログラミングは、単純で統合されたスタイルに洗練化されています。基本的に次の３
つのステップで、サービス・プロバイダを呼び出すことが出来ます。
１．サービス・マネージャのインスタンス化。
２．サービス・プロバイダの検索。
３．サービス・プロバイダのオペレーション呼び出し。
Copyright IBM Japan Co.,Ltd. 2005
14
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
メリット 2.
多様なサービス・アクセス・パターンをサポート
„ 同期型
要求／応答
Service
Client
‹ 要求／応答形式
„ 非同期型
order()
‹ 一方向形式
‹ 遅延応答形式
‹ コールバック形式
一方向
Service
Client
コールバック
遅延応答
orderAsync()
処理
続行
Service
Client
orderAsync()
処理
続行
orderResponse()
Service
Client
orderAsync()
処理
続行
onOrderResponse()
15
ＳＣＡは、サービス・プロバイダとサービス・リクエスタのインタラクション・モデルとして、同期型要求応答形
式に加え、非同期型の３形式をサポートします。非同期型の３形式として、一方向、遅延応答、コールバッ
クの利用が可能です。J2EE 1.4 のJAX-RPC 1.1では同期型要求応答形式のみのサポートとなっているの
で、ＳＣＡの非同期型インタラクションのサポートは、優位点の一つです。（ただしJava EE 5のJAX-WS 2.0
では、非同期型インタラクションもサポートされます。）
Copyright IBM Japan Co.,Ltd. 2005
15
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
メリット 3.
宣言型のQuality of Service (QoS) 定義のサポート
„ 宣言型でQoSを定義
„ 定義可能なQoS
‹ トランザクション
z
z
種類
トランザクション・スコープ
‹ アクティビティ・セッション
z
アクティビティ・セッションのスコープ
‹ 非同期通信の信頼性
z
z
トランジェント／パーシステント
タイマ
‹ セキュリティ
セキュリティ・アイデンティティ（ユーザー識別子）
z アクセス制御
z
16
ＱｏＳとは、サービスを一定水準に保つための非機能要件実装です。
ＳＣＡは、ＱｏＳを外部構成定義体に設定することが出来ます。ＱｏＳはプログラム内に実装するのではな
いので、サービス・プロバイダの開発者がＱｏＳに気を配る必要はありません。また、ＱｏＳの設定を変更す
るには、外部構成定義体を修正するだけで済むので、柔軟かつ容易なＱｏＳのメンテナンスが可能となり
ます。更に、ＱｏＳの設定は、ＷＩＤでサービス・コンポーネントを開発するためのビジュアル・エディタであ
るアセンブリ・エディタを利用して直感的に設定することが可能です。
設定できるＱｏＳとしては次のようなものがあります。
トランザクションの種類（グローバル、ローカル）や、ＵｏＷの範囲の制御を設定することが出来ます。
アクティビティ・セッションの範囲を制御することが可能です。
非同期通信の信頼性（永続か非永続か）や、オペレーション呼び出しのタイマを設定することが出来ます。
セキュリティとしては、ユーザー識別子の設定や、アクセス制御が可能となっています。
Copyright IBM Japan Co.,Ltd. 2005
16
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
メリット 4.
直感的な構成定義体の記述が可能
„
WebSphere Integration Developer V6.0 (WID V6.0) アセンブリ・
エディタ上でのワイヤリング
リファレンス
‹ インターフェース
‹ アドレス
‹
17
ＳＣＡのサービス・プロバイダ（サービス・コンポーネント）の開発には、ＷＩＤ Ｖ６．０のアセンブリ・エディタ
というビジュアルなエディタを利用します。このアセンブリ・エディタを利用すれば、直感的に構成定義体を
構築可能であり、サービス・コンポーネントの開発生産性に寄与します。
サービス・モジュールには、複数のサービス・コンポーネントを含めることが可能です。この時、各サービス
間の呼び出し関係（インターフェースとリファレンスの結びつき）を指定してあげる必要があります。
また、サービス・コンポーネントがサービス・モジュール外の外部のサービス・プロバイダを呼び出したり、
逆にサービス・コンポーネントがサービス・モジュール外の外部のサービス・リクエスタから呼び出されるこ
ともあります。この場合も、各サービス間の呼び出し関係（インターフェースとリファレンスの結びつき）を指
定してあげる必要があります。
ＳＣＡの低レベル実装では、これらの呼び出し関係の定義情報はＸＭＬで記述される構成定義体に格納
されています。アプリケーション開発者がＸＭＬ構成定義体をテキスト・エディタで記述するのは面倒な作
業です。ＷＩＤ Ｖ６．０のアセンブリ・エディタはこのような作業をビジュアルに行うことを可能にしています。
より詳しく説明しましょう。
インターフェースとは、サービス・プロバイダの提供するサービスの規約です。そこにはオペレーションの
名前や引数、戻り値が記述されています。一方ＳＣＡにおいて、リファレンスとはSCA APIを利用したクライ
アント・プログラムにおいて、サービス・プロバイダへの参照を表すものです。ＳＣＡの構成定義体上、コン
ポーネント・ファイル(<コンポーネント名>.component)やスタンドアロン・リファレンス(sca.references)内の
reference要素として定義されています。リファレンスは抽象的な構成要素であり、サービス・プロバイダが
配置された物理アドレスから透過的な存在となっています。このことがサービス・コンポーネントのポータビ
リティを高めているわけですが、実際に稼動させる際には物理的な配備環境に結びつける必要がありま
す。抽象的なリファレンスをサービス・プロバイダのインタフェースや物理アドレスと紐付けて具象化する作
業を、ビジュアルかつ直感的な操作で実現するのがワイヤリングというわけです。
Copyright IBM Japan Co.,Ltd. 2005
17
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
メリット 5.
SCAと既存技術の併用が可能
サービス・リクエスタ
サービス・プロバイダ
Web
サービス
EJB
RMI/IIOP
SCA
Messaging(JMS)
サービス
コンポーネント
SOAP/HTTP
SOAP/JMS
RMI/IIOP
Messaging(JMS)
JMS
App.
SCA
モジュール
プログラムと BPEL
プロセス
Java
SOAP/HTTP
SOAP/JMS
18
ＳＣＡは、大きく分けて２つの機能、つまりサービス・プロバイダのオペレーション呼び出しと、サービス・コ
ンポーネントのモジュール化技術から成っています。この両機能は常に一緒に組み合わせて使用するも
のではありません。必要に応じて、使い分けることが出来ます。
例えば、サービス・リクエスタで、不特定のサービス・プロバイダを呼び出すための統一インターフェースと
してＳＣＡを利用することができます。この時、必ずしもサービス・プロバイダはＳＣＡモジュールである必要
はありません。
また、サービス・プロバイダで、複数のコンポーネントを纏め上げて１つのサービス・モジュールに仕立て
上げるためにＳＣＡを利用することができます。
このようにＳＣＡは、必要な部分にのみ適用できる柔軟性を持ち合わせています。既存システムとの共存
を可能にする現実的なソリューションと言えるでしょう。
Copyright IBM Japan Co.,Ltd. 2005
18
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCA全体像
Web
サービス･モジュール
サービス･
コンポーネント
エクスポート
サービス･
コンポーネント
スタンドアローン
リファレンス
インポート
ワイヤ
Web
19
上記はＳＣＡの全体像です。
サービス･モジュールとは、複数のサービス･コンポーネントを配置することが出来る枠組みであり、サービ
ス･モジュールの単位で実装コード（EAR）が生成されます。
サービス･コンポーネント同士はインターフェース／リファレンスを介して相互に呼び出すことが可能です。
インターフェースとリファレンスとの関係をワイヤ、その関係付ける作業をワイヤリングと呼びます。サービ
ス･モジュール間や、サービス･モジュール外の別種モジュールを呼び出したいケースもあります。サービ
ス･モジュールではこうした場合を想定して、サービス・モジュールから外部を呼び出す際に利用する『イン
ポート』、逆に外部から当該サービス･モジュールが呼び出される際に使われる『エクスポート』などの新し
い概念が追加されています。
SOAを実現するために必要な、個別技術に依存しないITアーキテクチャーを目指したサービス･コンポー
ネントは、ロケーション非依存、分散プログラミング・モデル非依存、プロトコル非依存、メッセージ・フォー
マット非依存の実現を目指しています。したがって実装コードもこれら特性を引き継ぐ必要があります。
一方、実行時には、ロケーション、プログラミング・モデル、プロトコルなどを決定する必要があります。これ
を実現するためにサービス･モジュールで定義するのがインポートやエクスポートであり、その内部で記述
するバインディング情報です。ロケーションやプログラミング･モデル、プロトコルなど、実装時の技術依存
情報はサービス･コンポーネント自身から外部化され、独立しているためにプログラムに影響を与えること
なく変更が可能であり、環境の変化に柔軟に対応できることになります。
Copyright IBM Japan Co.,Ltd. 2005
19
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの構成要素 1.インターフェース
„ サービスの規約
サービス・モジュールの境界
Java
WSDL
Java
サービス･
コンポーネント
WSDL
サービス･
コンポーネント
スタンドアローン
リファレンス
インポート
Java
WSDL
20
インターフェースとは、サービス・プロバイダの提供するサービスの規約です。そこにはオペレーションの
名前や引数、戻り値が記述されています。
サービス・プロバイダであるサービス・コンポーネントがインターフェースを提供します。加えて、後述のイン
ポートが外部サービス・プロバイダのインターフェースを提供します。
Copyright IBM Japan Co.,Ltd. 2005
20
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの構成要素 2.リファレンス
„ サービス・コンポーネントの参照
サービス・モジュールの境界
Javaクラス
サービス･
コンポーネント
サービス･
コンポーネント
スタンドアローン
リファレンス
インポート
21
リファレンスとは、他のサービス・プロバイダのプロキシとして利用されます。
リファレンスには”インライン・リファレンス”と”スタンドアロン･リファレンス”の2種類があります。
インライン･リファレンスは、サービス･コンポーネントが他のサービス・プロバイダ（ＳＣＡサービス・コンポー
ネントを含む）を参照するために使用されるものです。インライン・リファレンスは、コンポーネント・ファイル
(<コンポーネント名>.component)内のreference要素として定義されます。
スタンドアロン・リファレンスは、非SCAコンポーネントがサービス･コンポーネントを参照する際に使用され
ます。スタンドアロン・リファレンス(sca.references)内のreference要素として定義されています。
上の図のように、リファレンスは呼び出し先のインターフェース（サービス･コンポーネントのインターフェー
スや後述するインポートのインターフェース）と関係付けられる必要があります。この関係付けを”ワイヤ”と
呼びます。ＷＩＤ ６．０のアセンブリ・エディタを利用すれば、ワイヤリングは直感的でビジュアルな操作で
処理できます。
Copyright IBM Japan Co.,Ltd. 2005
21
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの構成要素 3.ワイヤ
„ インターフェースとリファレンスの関連付け
サービス・モジュールの境界
Javaクラス
サービス･
コンポーネント
サービス･
コンポーネント
スタンドアローン
リファレンス
インポート
22
サービス・コンポーネントやスタンドアロン・リファレンスが他のサービス・プロバイダ（ＳＣＡサービス・コン
ポーネントを含む）を参照する際に、そのリファレンスと呼び出し先サービス・プロバイダのインターフェー
スの関連付けをワイヤと呼びます。ワイヤの定義は、関連構成要素の構成定義体に格納されます。
Copyright IBM Japan Co.,Ltd. 2005
22
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの構成要素 4.インプリメンテーション
„ サービス・コンポーネントの実装
Java
BPEL
ビジネス
ルール
Human
Task
Selector
インプリメンテーション・タイプ
23
サービス・コンポーネントは、インターフェースとサービス・プロバイダの実装を提供します。サービスの実
装方法(インプリメンテーション)として、Java、BPEL、ビジネス・ルール、Human Task、Selectorを選択する
ことが出来ます。サービス・コンポーネントの定義情報は、コンポーネント・ファイル(<コンポーネント名
>.component)内に格納されます。
Copyright IBM Japan Co.,Ltd. 2005
23
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの構成要素 5.インポート
„ 外部サービス・プロバイダの取り込み
サービス・モジュールの境界
インターフェースの指定
Java
WSDL
外部
サービス・プロバイダ
バインディング方法の指定
JMS
Stateless
Session Bean
サービス
コンポーネント
Web
サービス
24
インポートとは、サービス・モジュール外の外部サービス・プロバイダ（ＳＣＡサービス・コンポーネントを含
む）のプロキシとして機能する構成要素です。インポートは、外部サービス・プロバイダのインターフェース
とバインディング方法（接続プロトコルとアドレス）といった設定情報を保持します。これらの情報は、構成
定義体<インポート名>.importファイルに格納されます。
サービス・コンポーネントがサービス・モジュール外の外部サービス・プロバイダを呼び出す場合、サービ
ス・コンポーネントのリファレンスと、インポートのインターフェースをワイヤリングします。
※ 『esbBinding』はXMLのタグ名です。2005年10月現在ＷＩＤ ６．０では「Binding」と記載されています。
Copyright IBM Japan Co.,Ltd. 2005
24
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの構成要素 6.エクスポート
„ サービス・コンポーネントを外部サービス・リクエスタに公開
サービス・モジュールの境界
外部
サービス・リクエスタ
インターフェースの指定
Java
WSDL
バインディング方法の指定
Web
サービス
サービス
コンポーネント
JMS
25
サービス・コンポーネントをサービス・モジュール外の外部サービス・リクエスタに公開するために利用する
構成要素が、エクスポートです。エクスポートは、インターフェースとバインディング方法（通信に使用する
プロトコル）といった構成情報を保有しています。これらの情報は、構成定義体<エクスポート名>.export
ファイルに格納されます。
Copyright IBM Japan Co.,Ltd. 2005
25
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの構成要素 7.QoS
„ 一定のサービス品質を保証
„ 宣言型
インターフェース
インターフェース
・Join
・Jointransaction
transaction
・Join
・Joinactivity
activitysession
session
・Security
・Securitypermission
permission
リファレンス
リファレンス
・Suspend
・Suspendtransaction
transaction
・Suspend
・Suspendactivity
activitysession
session
・Asynchronous
・Asynchronousreliability
reliability
・Asynchronous
・Asynchronousinvocation
invocation
サービス
コンポーネント
インプリメンテーション
インプリメンテーション
・Transaction
・Transaction
・Activity
・Activitysession
session
・Security
・Securityidentity
identity
26
ＳＣＡは、トランザクション、アクティビティ・セッション、非同期通信の信頼性、セキュリティに関するＱｏＳを
宣言型で定義できます。
各QoS項目は、次に挙げる３つの箇所に紐付けて設定できます。
・サービスコンポーネントのインプリメンテーション
・サービス・コンポーネントとインポートが提供するインターフェース
・サービス・コンポーネントとスタンドアロン・リファレンスが提供するリファレンス
Copyright IBM Japan Co.,Ltd. 2005
26
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの構成要素 8.構成定義体
„ 抽象的な設計と具象的なIT実装の紐付けを定義
„ SCDL、WSDL(インターフェース定義)を用いて記述
インポート定義
エクスポート定義
インターフェース定義
コンポーネント定義
SCAモジュール定義
スタンドアロン・リファレンス定義
27
ＳＣＡには次の６種類の構成定義体があります。
・インポートの定義情報は、＜インポート名＞.importファイルに格納されます。
・エクスポートの定義情報は、＜エクスポート名＞.exportファイルに格納されます。
・インターフェースの定義ファイル。
・コンポーネントの定義情報は、＜コンポーネント名＞.componentファイルに格納されます。
・SCAモジュールの定義ファイル。
・スタンドアロン・リファレンスの定義ファイル。
Copyright IBM Japan Co.,Ltd. 2005
27
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAの構成要素 9.モジュール
„ サービス・コンポーネントの開発と配置単位
WID BIパースペクティブ
WID Javaパースペクティブ
28
ＳＣＡのサービス・モジュールは、１つのEARとして構成されます。ＥＡＲの中には幾つかの、Ｊ２ＥＥモ
ジュールやＪＡＲファイルが含まれています。
サービス・コンポーネントを形成する実装や構成定義が含まれているのがＷＩＤ ６．０におけるモジュー
ル・プロジェクトであり、これはＪＡＲファイルとして生成されます。
他のＪ２ＥＥモジュールやＪＡＲファイルは、ランタイム・コードの格納のためにＷＩＤ ６．０が暗黙的かつ自
動的に生成したものです。これらのＪ２ＥＥモジュールやＪＡＲファイルには手を加えないようにしてください。
Copyright IBM Japan Co.,Ltd. 2005
28
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCAクライアント・コード断片
タイプ・セーフ
ServiceManager _serviceManager = new ServiceManager();
OrderService _orderService =
(OrderService) _serviceManager.locateService(“order");
_orderService.submitOrder(_orderSpec);
ダイナミック
ServiceManager _serviceManager = new ServiceManager();
DataObject _orderSpec; // SDOを利用したパラメータ
Service _service = (Service) _serviceManager.locateService(“order");
_service.invoke(“submitOrder”, _orderSpec);
29
ＳＣＡのクライアント・プログラミング・スタイルには、タイプ・セーフとダイナミックの２種類があります。
呼び出し先のサービス・プロバイダがＪａｖａインターフェースを公開している場合は、タイプ・セーフ型のクラ
イアント・プログラミング・モデルを利用することが出来ます。
呼び出し先のサービス・プロバイダがＪａｖａインターフェースあるいはＷＳＤＬで記述されたインターフェー
スを公開している場合は、ダイナミック型のクライアント・プログラミング・モデルを利用することが出来ます。
Copyright IBM Japan Co.,Ltd. 2005
29
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SCA適用例
„
„
異機種混合環境におけるサービス・プロバイダとサービス・リクエスタ
の連携
ビジネス・プロセス・コリオグラファとサービス・プロバイダの連携
サービス・リクエスタ
サービス・プロバイダ
Web
サービス
EJB
RMI/IIOP
SCA
Messaging(JMS)
サービス
コンポーネント
SOAP/HTTP
SOAP/JMS
RMI/IIOP
Messaging(JMS)
JMS
App.
SCA
モジュール
プログラムと BPEL
プロセス
Java
SOAP/HTTP
SOAP/JMS
30
ＳＣＡの典型的な利用形態として次の２つの例を挙げることが出来ます。
１つには、異機種混合環境におけるサービス・プロバイダへの統合されたインターフェースとしてＳＣＡクラ
イアントＡＰＩを利用する形態が考えられます。様々なテクノロジを利用して実装されているサービス・プロ
バイダに対しても、単純で統一されたインターフェースでアクセスすることが出来るため、より容易で柔軟
なシステム統合を推進し、また開発しやすい環境を提供します。
２例目は、最初の利用形態の派生系となります。ＢＰＣがサービス・プロバイダを利用するインターフェース
としてＳＣＡを利用するケースです。ＷＩＤ 6.0によるＢＰＣ開発では暗黙的にＳＣＡを利用してサービス・プ
ロバイダにアクセスするワークフローを実装することが出来ます。柔軟な異機種接続を実現し開発生産性
に優れたＳＣＡの利用例といえます。
Copyright IBM Japan Co.,Ltd. 2005
30
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
Service Data Object (SDO) 概要
Copyright IBM Japan Co.,Ltd. 2005
31
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SDOとは何か
„ IBMが開発した、データソース非依存のデータ・モデル
„ V1.0はJCPにてJSR-235として策定
„ 稼働環境
‹ IBM
WebSphere Application Server (WAS) V6.0
‹ IBM WebSphere Process Server (WPS) V6.0
„ 開発環境
‹ IBM
Rational Application Developer (IRAD) V6.0
‹ IBM WebSphere Integration Developer (WID) V6.0
„ 特徴
‹ 多様なデータソースへの統一的なアクセス手段
‹ 非接続データ・アーキテクチャ
‹ データ処理履歴(Change
Summary)の保持
„ 用途
‹ オペレーションの引数または戻り値におけるデータ表現
32
Ｓｅｒｖｉｃｅ Ｄａｔａ Ｏｂｊｅｃｔ （ＳＤＯ）は、データソースに依存しないデータ・モデルです。当初はＩＢＭが独自に設計、
開発を行っていましたが、後に設計作業の場をＪＣＰに移して、ＪＳＲ−２３５としてＢＥＡ社と共に仕様策定を終えました。
この成果はＳＤＯ １．０として公開されています（ＳＤＯ ２．０は、ＪＣＰではなくＣｏｍｍｏｎＪプロジェクトとして作業が進
められています。）。
ＳＤＯの稼働環境はＷＡＳ ６．０とＷＰＳ ６．０、開発環境はＩＲＡＤ ６．０、ＷＩＤ ６．０です。
その特徴は、データソースに依存しない統合されたデータ・モデルである点です。異機種混合環境で、データソース
の種類が多岐に渡る場合、このような汎用的なデータ・モデルはデータ交換を行ううえでメリットがあります。
また、ＳＤＯは非接続データ・アーキテクチャを見据えたデータ・モデルであり、データ自身にデータ処理履歴を保持
していることも特徴的です。
非接続データ・アーキテクチャにより、コネクションなどシステム・リソースの長時間の占有を抑え、システム・リソース共
有の最適化を図ることが出来ます。
一方非接続データ・アーキテクチャを実現するために、データ・モデル自身に並行処理における楽観的ロックの導入
やデータ処理履歴を備え、粗結合環境でのオン・デマンドのデータ処理を実現しています。
ＳＯＡにおけるＳＤＯの用途は、オペレーションの引数や戻り値、またデータのキャッシュなどを挙げることができます。
Copyright IBM Japan Co.,Ltd. 2005
32
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
メリット 1.
データソースに依存しないデータ表現
サービス・リクエスタ
サービス・プロバイダ
RDB
クライアント
SDO
DataGraph
XML
データ
メディエータ
サービス
Web
サービス
JCA
33
ＳＤＯは特定のデータソースに依存しないデータ・モデルです。よって異機種混合環境での統一された
データ表現媒体として利用することが出来ます。
各種データソース固有のアクセス仕様の違いはデータ・メディエータ・サービス（ＤＭＳ）が隠蔽します。Ｄ
ＭＳはＳＤＯ仕様の範囲外であり、ベンダ固有の実装に任されています。
Copyright IBM Japan Co.,Ltd. 2005
33
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
メリット 2.
非接続アーキテクチャによるシステム資源の最適化
サービスプロバイダ
サービスリクエスタ
コネクション 1
コネクション 1’
Read
SDO
DataGraph
クライアント
コネクション 2
Update
データ
メディエータ
サービス
コネクション 2’
データソース
SDO
DataGraph
34
ＳＤＯは非接続アーキテクチャに基づいて設計されています。非接続アーキテクチャの説明の例として、リ
クエスタがデータを読み込み、加工を加え、その結果を持ってデータソースを更新するユースケースを考
えてみます。ＳＤＯとＤＭＳのアーキテクチャにおいては、１つのデータ処理ごとにコネクションの開設と切
断を実施します。つまり、データ読み込みとデータ更新の処理はそれぞれ異なるコネクション、異なるトラ
ンザクションの基で処理されるという訳です。各インタラクションが独立しており、ステートレスであること、そ
れが非接続アーキテクチャの特徴です。
このような非接続アーキテクチャを用いることで、コネクションなどシステム・リソースの使用時間を最適化
することが出来ます。
また、一旦データを取得すれば、その後プロバイダが停止しても、処理を続行できるという、粗結合ならで
はの可用性の向上にも寄与します。
Copyright IBM Japan Co.,Ltd. 2005
34
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
SDOの利用例
„ サービス・プロバイダとサービス・リクエスタ間で送受信され
るデータ表現
„ サービス・リクエスタ側でのデータ・キャッシュ
サービス・プロバイダ
サービス・リクエスタ
SDO
DataGraph
1.読み込み
2.加工
SDO
DataGraph
3.更新
SDO
DataGraph
35
ＳＤＯの適用例としては、ＳＯＡにおけるサービス・コンポーネントの引数や戻り値として利用する形態が考
えられます。特に異機種混合環境であるエンタープライズＳＯＡでのデータ表現のメリットを活かすことが
期待されます。
また、従来各お客様システム固有のソリューションとして開発プロジェクト毎に作成されてきた、データ・
キャッシュとしての活用も考えられます。一度読み込んだデータに加工を加え、必要なときにプロバイダに
アクセスして更新を加えるといった、非同期的なインタラクション・モデルが可能になります。
Copyright IBM Japan Co.,Ltd. 2005
35
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
まとめ
Copyright IBM Japan Co.,Ltd. 2005
36
WebSphere Process Server V6
SOAに求められるプログラミング・モデル
まとめ
„ ビジネスのAgilityを実現するアーキテクチャとして、エンター
プライズSOAに注目が集まっている。
„ 異機種混交のITシステムにおいて、特定のテクノロジに依存
しないSOAプログラミング・モデル像が求められている。
„ SCAは、特定のテクノロジに依存しない、サービス呼び出し
の技術である。
„ SDOは、特定のデータソースに依存しない、データ・モデル
である。
„ SCA、SDO、Webサービス、Java EEを適材適所で活用す
るアーキテクチャが、SOAシステム構築において求められる。
37
Copyright IBM Japan Co.,Ltd. 2005
37