技術解説 BizTalk Server 2004の機能と構造（後編） 3．エンタープライズ・シングル・サインオン機能 デジタルアドバンテージ 2004/10/13

　前編では、情報システム連携におけるBizTalk Server 2004（以下BTS 2004）の役割と、それを実現するBTS 2004エンジンの内部構成について解説した。引き続き後編では、異なるセキュリティ・コンテキストを持つシステム連携に必要なシングル・サインオン（Single Sign-On：SSO）機能、柔軟な負荷分散を可能にするBTS 2004のスケーラビリティ、BTS 2004を業務の現場で利用する業務担当者向け機能などについて解説する。

エンタープライズ・シングル・サインオン機能

　業務をつかさどる情報システムは、何らかのセキュリティ機能によって保護されている。最も一般的なものは、ID情報（ユーザー名とパスワード）によってシステムの利用を許可したり、制限したりすることだ。問題は、IDの定義方法や管理方法が情報システムごとに異なっている点にある。異なるセキュリティ・コンテキストにある情報システムを連携し、1つのプロセスとして自動化するためには、システム間でのID情報の相互運用が不可欠である。そこでBTS 2004には、エンタープライズ・シングル・サインオン（Single Sign-On、以下SSO）と呼ばれる機能が導入された。このSSOにより、BTS 2004によるオーケストレーションにおいて、異なるセキュリティ・コンテキストにある情報システム同士をシームレスに連携できるようになる。

　BTS 2004のSSO機能では、SQL ServerベースのリポジトリでID情報（クレデンシャル＝資格情報）を集中管理し、これをメッセージ入力時と出力時にそれぞれ呼び出すことで、異なるシステム間でのID情報の相互運用を可能にする。BTS 2004のSSO機能は、次のようにアダプタ・レベルで実装されている（BTS 2004アダプタの詳細については前編を参照）。

BTS 2004 Enterprise SSO機能の構成

BTS 2004のSSO機能は、アダプタ・レベルで実装されている。入力側Receiveアダプタ、出力側Sendアダプタの双方でシングル・サインオン（SSO）サーバをアクセスし、ID情報の相互運用を実現する。

メッセージを受信したReceiveアダプタがSSOサーバにアクセスし、サインオンしたことを表す情報「SSOチケット」を要求する。取得されたSSOチケットがメッセージのプロパティとして追加される。 　 出力メッセージの送信時、Sendアダプタはメッセージ内のSSOチケットを確認する。 　 SSOサーバが資格情報データベースを検索する。 　 送信先にアクセスするためのID情報が返される。 　 取得されたID情報が付加され、送信先にメッセージが送られる。

　図は、左上にあるシステム（Windowsサーバ）と右上にあるシステム（メインフレーム）が1つのプロセスで連携している例である。このとき、WindowsサーバではWindowsユーザーIDベースのアプリケーションが稼働し、右上のメインフレーム上ではこれとは異なるセキュリティ・コンテキストでアプリケーションが稼働していると仮定する。

　まず、Windowsサーバ上のアプリケーションは、WindowsユーザーID情報を含むメッセージをBTS 2004に送る。次にこのメッセージを受信したBTS 2004のReceiveアダプタは、受信したID情報（WindowsユーザーID）をSSOサーバに渡す。するとSSOサーバは、ID情報に固有のSSOチケットを返す（）。

　SSOチケットを取得したReceiveアダプタは、これをメッセージに添付し、Receiveパイプラインを介してメッセージ・ボックスに発行する。メッセージはオーケストレーション・コンポーネントによって処理され、結果のメッセージがメッセージ・ボックスに再発行される。

　次にメッセージは、Sendパイプラインを介してSendアダプタに送られる。するとSendアダプタは、メッセージに付加されたSSOチケットと、送信先のアプリケーションの情報（この例ではメインフレーム・アプリケーションの情報）をSSOサーバに送る（）。SSOサーバは、SSOチケットとメインフレームのアプリケーション情報から、メインフレーム・アプリケーションのID情報を検索する（）。資格情報データベースには、特定のWindowsユーザーIDと、1つないし複数のアプリケーションに対する資格情報（ユーザーIDとパスワード）のマッピング情報が保存されている。

　その後SSOサーバは、データベースから検索した資格情報をSendアダプタに返す（）。Sendアダプタは、取得したID情報を添付してメインフレーム・アプリケーションにメッセージを送信する（）。

　BTS 2004のSSO機能によるプロセス連携の基本的なシナリオはこのとおりだが、アダプタ・レベルでの対応のため、SSOを利用するには、アダプタがSSOに対応している必要がある。標準アダプタであるHTTP、SOAP、FTPなどはこれに対応しているが、必ずしもすべてのアダプタが対応しているとは限らない。SSO非対応のアダプタを使わざるを得ない場合には、独自のカスタマイズが必要になるだろう。

　またBTS 2004のSSO機能は、Active Directoryなどのディレクトリ・サービスと自動的に連携するわけではない点に注意が必要だ。前述したとおり、SSOはWindowsユーザーIDと各アプリケーションの資格情報のマッピングを保持しているが、セキュリティ確保の目的で、パスワードを定期的に変更するシステムなどがある場合には、手作業での資格情報の更新が必要になる。

　なおBTS 2004は、ほかのサービス同様SSO向けのAPIも提供しており、プログラムからSSOサービスにアクセスすることが可能だ。

強化されたWebサービス対応

　初期版であるBizTalk Server 2000のときから、BTSはWebサービス（XML Webサービス）に対応しており、オーケストレーションの内部からWebサービスを呼び出すことは可能だった。しかしBTS 2000でこれを実現するには、BTS 2000とWebサービスとの仲立ちをするCOMベース・クライアント（Webサービス・プロキシ）を開発しなければならなかった。

　これに対しBTS 2004では、Webサービス・プロキシを作成しなくても、開発環境（Visual Studio .NET）でのビジネス・プロセス・デザイン時に、直接Webサービスの呼び出しを指定できるようになった。具体的には、相手先URL（ないしUDDIディレクトリ）を指定してWebサービス参照をプロジェクトに追加すれば、BTS 2004から外部へのWebサービスの呼び出しや、逆に外部からBTS 2004へのWebサービス呼び出しをオーケストレーション・デザイナーで追加できるようになる（操作の実際については、後述する「手軽な動画デモ」が参考になるだろう）。

　またBTS 2004にはWeb Service Publishingウィザードと呼ばれるものが提供されており、オーケストレーション・プロセスを外部に公開するためのASP.NET Webサービス・プロジェクトを自動生成できる。

Webサービス標準への対応

SEのためのXML Schema入門（XML＆SOA）

　BTS 2004では、新たに標準化が進むWebサービス標準への準拠が一段と進んだ。1つはXMLスキーマ記述言語のXSD（XML Schema Definition）に対応したことだ。すでに述べたとおり、BTSは受信したメッセージをXML形式に変換し、内部ではこのXMLメッセージとして処理を進める。従来のBTSでは、このXMLメッセージのスキーマにXDR（XML Data Reduced）と呼ばれる独自の言語を利用していた。しかしXSDがW3Cで標準化されたことから、BTS 2004ではXSDサポートが追加され、XSDでのXMLドキュメント作成が可能になった。

　XSDは、Webサービスを利用して外部とデータ交換しようとする際に、XMLドキュメントの構造を示す標準的なスキーマ言語になる。BTS 2004では、XSDで記述された既存のスキーマを、ファイルないしWebサービス経由でインポート可能になった。このことは、BTS 2004のWebサービス・インターフェイス利用の幅を広げるだろう。

連載 ビジネスWebサービス最新事情（XML＆SOA）

　BTS 2004は、ビジネス・プロセスを記述するための汎用フォーマットであるBPEL4WS（Business Process Execution Language for Web Services）にも対応した。これにより、BTS 2004のオーケストレーション・デザイナーで作成したビジネス・プロセスとスキーマをBPELでほかのビジネス・プロセス・デザイン・ツールにエクスポートしたり、逆にほかのツールからBTS 2004にインポートしたりできるようになった。BPEL4WSはMicrosoftとIBMが中心になって策定した仕様である。

業務担当者向けサポート

　アダプタのカスタマイズは開発者が、負荷分散のためのシステム設計などはシステム管理者がそれぞれ担当することになるだろう。しかし構築されたシステムでビジネス・プロセス処理を日々運用するのは、開発者でもシステム管理者でもない。現場の業務担当者である。これらの業務担当者は、必要に応じてビジネス・プロセス処理のパラメータ（決済金額や為替レートなど）を変更したり、トランザクション数（1日の受注量など）をモニタしたりしたいと考えるだろう。またすべてのビジネス・プロセスを自動化するのではなく、プロセスの一部を人間がモニタし、状況に応じて人間が意志決定する必要があるかもしれない（状況に応じて決済の内容を変更するなど）。BTS 2004では、これら業務担当者向けサポートも拡充された。

　業務担当者向けサポート・コンポーネントは、ビジネス・アクティビティ・サービス（Business Activity Services）とヒューマン・ワークフロー・サービス（Human Workflow Services）の2つに大別される。

■ビジネス・アクティビティ・サービス（Business Activity Services）
　業務担当者がプロセス処理の状況をモニタし、必要に応じてオーケストレーションで使われるパラメータを調整したり、社外の取引先との関係を定義したり（メッセージ交換に使用するアダプタなど）、BtoB接続を行うために相手先に求める仕様を自社のビジネス・プロセスから作成してパッケージ化し提供したりするための各種コンポーネントが提供されている。

■ヒューマン・ワークフロー・サービス（Human Workflow Services）
　BTS 2004は複数の情報システムによる自動的な連携を実現するが、ビジネス・プロセスの処理内容によっては、完全な自動化はできず、人間の判断が必要になる場合もある。例えば商品の販売価格は、取引先の規模や信用、力関係、取引時期（決算時期など）、販売ノルマの達成状況など、複数の要因を総合的に勘案して変更されることがしばしばある。こうした条件を完全にルール化するのは困難だし、無理にルール化すると現実に即した柔軟なシステム運用ができなくなってしまう。

　プロセスの一部に人間を介在させるために、BTS 2004が提供している機能がヒューマン・ワークフロー・サービス（以下HWS）である。HWSはWebサービス・インターフェイスを備えており、WordやExcel、Outlook、InfoPathなどのOfficeアプリケーションをフロントエンドとして利用できる。これにより例えば、プロセスの承認要求をOutlookメッセージとして送信し、決済担当者からの決済結果を直接BTS 2004のプロセス処理エンジンに返すなどが可能になる。

INDEX
	［技術解説］
	BizTalk Server 2004の機能と構造（前編）
	1．BTS 2004の基本機能と活用シナリオ
	2．BTS 2004エンジンのしくみ
	BizTalk Server 2004の機能と構造（後編）
	3．エンタープライズ・シングル・サインオン機能
	4．BTS 2004のスケーラビリティ

　

技術解説

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）