技術解説 BizTalk Server 2004の機能と構造（前編） 2．BTS 2004エンジンのしくみ デジタルアドバンテージ 2004/07/15

　これまで見てきたように、BTS 2004の目標は、社内／社外を問わず、異なる複数の情報システム連携を実現するためのプラットフォームを提供することだ。このためにBTS 2004内部がどのようなしくみになっているのかを見てみよう。

　BTS 2004の内部構成を図にすると以下のようになる。

BTS 2004の内部構成

BTS 2004の内部は、まずBizTalk Serverエンジンとビジネス・ルール・エンジンの2つに分かれる。このうちBizTalk Serverエンジンは、ほかの情報システムとの入出力をつかさどるSend／Receiveアダプタ、入出力データのXMLドキュメントへの変換やXML文法チェックなどを行うパイプライン、入出力メッセージと上位オーケストレーション・コンポーネントへのメッセージの履歴管理などを行うメッセージ・ボックス、ビジネス・プロセスを実装したオーケストレーション・コンポーネントから構成される。

　図のとおり、BTS 2004の内部は、「ビジネス・ルール・エンジン」と「BizTalk Serverエンジン」の2つに別れている。BTS 2004のエンジンは、従来版（BizTalk Server 2002）から比較して大部分がC#で記述し直され、.NET FrameworkのCLR（共通言語ランタイム）上で実行されるように改良された。

BTS 2004の構成要素：ビジネス・ルール・エンジン

　ビジネス・ルール・エンジンは、BTS 2004から実装された新機能で、オーケストレーション・コンポーネント全体を再構築することなく、業務担当者がビジネス・ルールの一部を作成したり、変更したりできるようにする。ここでいうビジネス・ルールとは、ビジネス・プロセス中の条件判断部分を意味している。例えば資材購入のビジネス・プロセスなら、決済可能金額の条件判断などだ。ビジネス・プロセス全体がガラっと変わることはそうないが、決済金額の変更などは頻繁に変更される可能性が高い（例えば決済金額が為替レートの変動を受けるなど）。

　BTS 2004のビジネス・ルール・エンジンは、ビジネス・プロセスにおいて変動する可能性が高い条件判断部分をオーケストレーション・コンポーネントから分離・外部化し、オーケストレーション全体を再構築しなくてもルールを変更できるようにする。オーケストレーションを再構築するには、既存オーケストレーションの停止とVisual Studio（開発環境、以下VS）でのオーケストレーションの変更と再コンパイル、編集済みオーケストレーションの再起動が必要になる。しかしビジネス・ルール・エンジンを利用したルールの変更は、オーケストレーションの停止・再起動も、VSによる変更・再コンパイルも必要がない。

BTS 2004の構成要素：Send／Receiveアダプタ

　Send／Receiveアダプタは、互換性のない複数のシステムとBTS 2004が通信するためのプロトコル・アダプタ群である。具体的なアダプタとしては、ファイル（ファイルを経由したデータの送受信）、FTPやHTTPなどのインターネット・プロトコル、Webサービス、SQL Serverなど向けのアダプタなどがある。BTS 2004は、通信する相手に応じて、適当なアダプタを選択して通信を行う。

　BTS 2004では、カスタム・アダプタを開発するためのフレームワーク（アダプタ・フレームワーク）が新たに提供され、この共通フレームワークを利用して独自のアダプタを開発できるようになった。これによりアダプタ開発の工数が削減されるとともに、標準のビルトイン・アダプタとカスタム・アダプタの双方を共通の管理ツールで管理できるようになる。ただしアダプタ向けフレームワークはBTS 2004で一新されたため、従来のBizTalk Server向けに開発されたアダプタはBTS 2004とは互換性がない。

BTS 2004の構成要素：Send／Receiveパイプライン

　BTS 2004は、受信したデータを使用したアダプタや送信元システムに依存しない「メッセージ」と呼ばれるXMLベースのデータ形式に変換して内部的な処理を行う。この変換処理を行うのがSend／Receiveパイプラインである。パイプラインの内部では、送受信データとXMLデータの変換処理、XMLドキュメントの検証、メッセージのデジタル署名処理など、いくつかの処理を行う。各パイプラインの処理内容は以下のとおり。

■Receiveパイプライン
　外部の情報システムから受信したデータ（メッセージ）をBTS 2004のネイティブ・データ形式であるXMLメッセージに変換するのがReceiveパイプラインの役割である。Receiveパイプラインの内部では、入力データに対して、4つのステージの処理が順次実行される。各ステージの実際の処理を担うのは、.NETベースまたはCOMベースのコンポーネントである。BTS 2004は、典型的な処理に対する標準コンポーネントを提供しているが、必要なら独自のカスタム・コンポーネントを作成することも可能だ（Receive／Sendパイプラインいずれも可能）。

Receiveパイプラインの処理

Receiveパイプラインでは、入力データのデコード（復号化）、XMLデータへの変換（ディスアセンブル）、データ検証（バリデート）、メッセージ送信者IDの決定（Resolve Party）を行う。図の右側にある角丸矩形がBTS 2004が提供する標準コンポーネントである。

　Receiveパイプライン向け標準コンポーネントの機能は次のとおり。

コンポーネント	機能
MIME／SMIMEデコーダ	MIMEまたはS/MIME形式のメッセージからデータを読み出す。
XMLディスアセンブラ	すでにXMLで記述されている入力メッセージの文法チェックを行う
フラット・ファイル・ディスアセンブラ	フラット・ファイルをXMLデータに変換する
BizTalk Frameworkディスアセンブラ	BizTalkフレームワークで定義されたメッセージを送信する
XMLバリデータ	ディスアセンブル・ステージが生成したXMLドキュメントを検証する
Party Resolution	メッセージ送信者の識別子を決定する。BTS 2004のSSO（Single Sign On）処理を支援するコンポーネント
Receiveパイプラインの標準コンポーネント

■Sendパイプライン
　前出のReceiveパイプラインとは逆に、XML形式のメッセージを下位のアダプタに渡すメッセージに変換するのがSendパイプラインの機能である。

Sendパイプラインの処理

Sendパイプラインは3つのステージで構成される。Receiveパイプラインとは逆に、BTS 2004ネイティブのXMLメッセージをエンコードして、下位のアダプタに渡す。なおプリアセンブル・ステージ向けの標準コンポーネントは提供されない。

　Sendパイプライン向け標準コンポーネントの機能は次のとおり。

コンポーネント	機能
XMLアセンブラ	エンベロープの追加など
フラット・ファイル・アセンブラ	XMLメッセージを固定長または区切り文字で区切られたフラット・ファイルに変換する
BizTalk Frameworkアセンブラ	BizTalkフレームワークの機能を使用し、メッセージの信頼性を向上させる（ほとんど使われない）
MIME／SMIMEエンコーダ	出力メッセージをMIMEないしS/MIME形式にパッケージ化する
Sendパイプラインの標準コンポーネント

BTS 2004の構成要素：メッセージ・ボックス

　Receiveパイプラインで変換されたXMLメッセージは、メッセージ・ボックスと呼ばれるSQL Serverベースのメッセージ・ストアに送信される。XMLメッセージは、次にそのメッセージを処理するオーケストレーション・コンポーネントに送信され、オーケストレーション・インスタンス（オーケストレーション処理の実行単位）によってビジネス・ロジックの処理が行われる。この際のオーケストレーション・インスタンスの実行状態（ステート）やトランザクションの履歴もメッセージ・ストアに保存される。

　BTS 2004で大幅に強化された点の1つがこのメッセージ・ボックスである。従来のBizTalkでは、オーケストレーション・インスタンスのステートをメモリに保存していたため、メモリに対する負荷が大きかった。またステートがメモリに展開されるため、オーケストレーション・インスタンスとそれを開始した物理システムが結合されてしまい、負荷分散が行えないという問題があった。これに対しBTS 2004では、オーケストレーション・インスタンスのステート管理がSQL Serverデータベースとして独立されたため、アダプタとパイプラインの処理、オーケストレーションの処理などを必要に応じて複数システムに柔軟に分散できるようになった。

　XMLメッセージのうち、どのメッセージをどのオーケストレーション・コンポーネントに送るかを保存しているのがSubscriptionsである。オーケストレーション・コンポーネントは、特定のメッセージを購読（Subscribe）している。当該メッセージが発生すると、BTS 2004はそのメッセージを購読しているオーケストレーション・コンポーネントにメッセージを送信する。

BTS 2004の構成要素：オーケストレーション・コンポーネント

　BTS 2004において、ビジネス・プロセスを記述したものがオーケストレーション・コンポーネントである。いま述べたとおり、メッセージの受信をきっかけとして、それを購読しているオーケストレーションがインスタンスとして起動される。

　従来のBizTalk Serverでは、インタープリタ型で実行時に順次解釈され処理されるスクリプトでオーケストレーションを記述する必要があった。これに対しBTS 2004では、C#やVB.NETなどの.NET Framework対応言語でオーケストレーションを記述し、マネージ・コードとしてコンパイルできるようにした。これによりオーケストレーションの処理性能が格段に向上している。

　ただしオーケストレーションのデザインでC#やVB.NETでのプログラミングが不可欠かといえばそうではない。オーケストレーション・デザインのためにBTS 2004は複数のGUIツールを提供しており、マウスによるドラッグ＆ドロップなどのオペレーションによりビジネス・プロセスを記述できるようにしている。具体的には、オーケストレーション用のXMLスキーマをデザインするためのBizTalkエディタ、スキーマ変換を定義するためのBizTalkマッパー、ビジネス・プロセス・フローを設定するためのオーケストレーション・デザイナが利用できる。これらのツールは、いずれもVisual Studio 2003と統合されている。これらのツールを使えば、プログラマでなくてもビジネス・プロセスを設計することができる。

BTS 2004のオーケストレーション・デザイナ

BTS 2004では、ビジネス・プロセスのGUIデザイン・ツールが開発環境のVisual Studio 2003と統合されている。画面はVS 2003の中からサンプル・ソリューションを開き、オーケストレーション・デザイナを起動したところ。画面左にあるのはツール・ボックスで、メッセージの送受信や条件分岐、ループ処理、ドキュメント変換などのコンポーネントをマウスでドラッグ＆ドロップし、それらの関係を図として構成していくことで、ビジネス・プロセスをデザインできる。

　　

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

　

技術解説

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