サービス情報の交換に関するペイロード制約は、SOA (Service-Oriented Architecture：サービス指向アーキテクチャー) 環境におけるビジネス・ツー・ビジネス (B2B) 通信にとって2つの課題をもたらします。

• ビジネスは、情報交換に関する垂直的な業界標準を使用する場合でも、固有の制約を規定する必要があります。
• 制約を包括的に宣言し、実際のサービス・ロジックにディスパッチされる前に実行時に情報をチェックするには、一般に複数の制約技術が必要です。

Business Information Conformance Stetement (BICS) は、これら両方の課題に対して拡張性のあるソリューションを提供するシンプルな仕様です。垂直的な業界標準団体からのフィードバックに基づいて、元の仕様から進化したものです。

BICS 2：更新された仕様

Business Information Conformance Statement (BICS) 2仕様は、2004年初めにIBMによって発行されたBusiness Integration － Information Conformance Statement (BI-ICS) 1.0仕様に代わる更新版です。(名称も、元のBI-ICSからシンプルなBICS 2に変更されました。)

BICS 2は、BI-ICS仕様を単純化したものであり、よりパワフルでわかりやすくなりました。以前のバージョンとの最も重要な違いは、次のとおりです。

• モジュール性が強まりました。元の単一の仕様が複数の仕様に分割されました。
• 現在と将来を見据えたXMLフレームワークとなり、既存の情報制約メカニズムと、将来の情報制約メカニズムに対する拡張性のセットで構成されています。独自のカスタム制約メカニズムを定義することもできます。

上に戻る

業界からのフィードバック

2004年から2005年にかけて、プレゼンテーション、チュートリアル、およびディスカッションを通じて、さまざまな業界標準団体とそのメンバーからこの仕様に対するフィードバックがありました。こうした貴重なフィードバックをいただき、XML.gov, MedBiquitous.org, Association for Cooperative Operations Research and Development (ACORD), Open Applications Group (OAGIS)、およびOrganization for the Advancement of Structured Information Standards (OASIS)のメンバーに感謝したいと思います。BICS 2の単純化とXMLフレームワーク設計の実現は、こうしたフィードバックの成果によるところが大です。

上に戻る

BICS 2の概要

前のバージョンをよく知らない方のために、BICSとは何か、何をするものかを簡単に紹介します。簡単に言うと、BICSは制約文書です。すなわち、一連の情報制限を含んだXMLドキュメントです。コンピューター科学の見地からすると、BICSは2つのパワフルなツールを採用しています。それは、抽象化と非方向性です。BICSドキュメントは、情報の制約に関するステートメント、すなわち宣言を行います。

BICSフレームワーク仕様の核となるものは制約処理モデルです。処理対象の情報が制約条件に適合しているかを判断する際には、適当な条件のタイプがあらかじめ一連の制約に対して定義されている必要がありますが、この制約処理モデルはこうした条件のタイプを規定するものです。制約メカニズムは、XMLスキーマ、型方式、またはカスタム・プログラミング・コードのいずれでもかまいません。そのコア・フレームワークの中で、BICSは、具象制約メカニズムを定義するための特殊型である抽象InformationConstraintMechanismTypeを提供しています。コアBICSフレームワークとともに、次の3つの具象制約メカニズム仕様が公開されています (これらの仕様へのリンクについては、「BICS 2 summary page」を参照してください) 。

• W3C XMLスキーマ制約メカニズム (W3C XML Schema Constraint Mechanism：WXSCM)
• Schematronスキーマ制約メカニズム (Schematron Schema Constraint Mechanism：SSCM)
• MIME制約メカニズム (MIME Constraint Mechanism：MCM)

BICS 2は、この先出現するであろういかなる制約テクノロジーにも対応する準備ができています。スキーマや型方式など、他のテクノロジーを制約メカニズムとして定義することも、独自のカスタム制約ソリューションを定義することもできます。BICSインスタンス・ドキュメントには一連の制約構造が含まれ、これらの制約構造は具象制約メカニズムに従って型が定義されます。BICSドキュメントには、複数のスキーマやSchematronアサーション・スキーマなど、さまざまな種類の制約があります。BICSの処理系は、BICSドキュメントを読み取り、いくつかの情報の抜粋に制約を適用して、適合性をチェックすることができます。

このフレームワークの制約処理モデルには、BICSドキュメント内の制約セットに対する処理条件のタイプを規定するインジケータが含まれます。制約処理モデルには、「シーケンシャル (sequential) 」条件、「任意 (any) 」条件、および「すべて (all) 」条件が含まれ、それぞれ、制約の処理方法が異なります。

BICSの本質的な価値のひとつは、SOAで交換されるB2B情報の制約および検証チェックに使用されることにあります。つまり、サービス・ロジックでの制約チェックを回避できるということです。

BICSドキュメントに対して実際にチェックされる情報に特定の範囲はない点に注目する必要があります。どのような形式でもよく (テキストでも、バイナリでも) 、どのような種類の情報を含んでいてもかまいません。

上に戻る

サービスは一般に複数の制約メカニズムを必要とする

W3C XMLスキーマのパワフルな情報モデリング能力を業界標準団体内部で広範囲に使用する場合、当然ながらその能力は制限されます。たとえば、インスタンス要素の値に基づいての検証チェックは指定できないということは、よく知られています。このような制限があるため、企業にとっては、付随的な制約テクノロジーを使用してサービス全体に対して包括的な制約チェックを行うか、あるいは独自のプログラミング・ロジックを使用することが重要になってきます。典型的なSOAシナリオでは、W3C XMLスキーマ検証を使用し、その後XSLベースの検証 (Schematronアサーションなど) を使用し、サービスで交換される情報をビジネス・ロジックがハンドオフするという流れになるでしょう。多くの場合、特定の制約メカニズムの制限に対処するには、カスタム・コードも含めた複数の制約メカニズムが必要になります。また、SOA情報交換にはバイナリ情報が必要であり、これらもMIMEなどの特定の型方式に対してチェックできます。

現在、この処理モデルを宣言して自動化を実現するような正式または標準的な方法はありません。BICSドキュメントを使用して、サービスに対してこのモデルを宣言することになります。BICS抽象InformationConstraintMechanismTypeは、W3C XML SchemaやSchematronなどの特定のメカニズムの制約処理モデルにとって、一貫性のある拡張ポイントを提供します。チェック対象である交換情報がサービスに適合しているとみなされるためには、XML SchemaとSchematronアサーションが順に実行されなければならないことをリスト1のBICSドキュメントの抜粋は指定しています。BICSドキュメントは、この例のように、URL (おそらくスキーマの場所) を使用する制約を参照することができます。制約そのものをBICSドキュメントに含めることもできます。詳しくは、BICS仕様を参照してください。

<InformationConformanceStatement> 
 <InformationConstraintProcessingModel
  modelType="sequence">
  <InformationConstraint
    xsi:type=
    "W3CXMLSchemaInformationConstraintMechanismType">
   <ProcessableConstraintURL>
   http://members.org/member.xsd
   </ProcessableConstraintURL>
     </InformationConstraint>
  <InformationConstraint
    xsi:type=
    "sch:SchematronInformationConstraintMechanismType">
   <ProcessableConstraintURL>
   http://Address.org/MyAddressLineSchematron.xml
   </ProcessableConstraintURL>
  </InformationConstraint>
 </InformationConstraintProcessingModel>
</InformationConformanceStatement>

通常、どの制約メカニズムにも制限があり、あらゆる情報形式に最適な単一の制約テクノロジーというものはありません。ビジネス・パートナー間で交換されるデータ形式は多岐に渡るため、確実な制約宣言と実行時チェック・ソリューションを実現するためには、複数の制約テクノロジーをSOA環境に導入する必要があります。XMLスキーマは、バイナリ情報の交換には適していません。InformationConstraintMechanismTypeのBICS抽象ポイントを型方式 (MIMEなど) と組み合わせて使用して、情報がバイナリ・データ形式タイプによって制約されることを宣言することもできます。たとえば、複数のバイナリ情報タイプにまたがる処理モデルを宣言することができます。リスト2のBICSドキュメントの抜粋は、任意 (any) 処理モデル内の2種類のMIME imageタイプを指定しています。これは、展開されているサービスにとって、いずれかの画像形式が受け入れ可能な情報であることを示しています。

<InformationConformanceStatement> 
 <InformationConstraintProcessingModel
  modelType="any">
  <InformationConstraint 
    xsi:type="MIMEInformationConstraintMechanismType">
    <MIMEType>image/.jpg</MIMEType>  
  </InformationConstraint>
  <InformationConstraint 
     xsi:type="MIMEInformationConstraintMechanismType">
     <MIMEType>image/.gif</MIMEType>  
  </InformationConstraint>
 </InformationConstraintProcessingModel>
</InformationConformanceStatement>

上に戻る

ビジネスには垂直的な業界標準を超えた具体的な制約が必要である

業界レベルの多くのXML標準は、定義が緩やかです。このことは一般に、濃度 (カーディナリティー) が最小限しか定義されていないことを意味します。結果的に、より高いレベルの相互運用性をサポートするために制約の厳しい標準が求められるのは当然ですが、垂直的な業界標準においてこれを実現するのは依然として困難です。現実世界のビジネス要件は柔軟性の少ない厳格な業界固有の標準に当てはまらないことが多く、結果として、すべてのユーザーが柔軟に使用できる標準というものは存在しません。

インフラ・レベルの標準では、状況が異なります。このレベルではビジネスの価値が差別化されることは少ないため、ビジネスは共通のインフラを利用する可能性が高くなります。業界固有の標準とは対照的に、インフラ標準は一般に、ビジネスの価値を一意に定義するような機能を妨げることはありません。このため、あらゆるビジネスがカスタマイズなしにそのまま使えるような厳格な業界固有の標準を標準団体が規定することは困難ですが、インフラ・レベルの標準であれば、こうした標準を確立することははるかに容易です。

定義が緩やかな標準を垂直的な業界グループにおいて定義することは、垂直的な標準に対処するための実用的で自然なアプローチですが、このことは同時に、特定のビジネスの要件に合わせるにはB2B標準の制約の変更 (一般には厳格化) を規定する必要があるということも表しています。これを実現する正式な言語は、サービス用にプロファイルされた制約の公示を容易にすると同時に、ビジネスが独自の価値提案を維持することも可能にします。現時点では、このための正式な、または標準のメカニズムは存在しません。

SOAには、ビジネス・ロジックに至る、より高い処理層でオープン・スタンダードが採用されるにつれて、情報制約の変更を容易にする制約設計が含まれています。BICSなどの制約ドキュメントは、オープンな業界標準スキーマを第一の制約として正式に宣言する機能によって、この分野でのソリューションを提供します。また、サービスに応じて変化する制約として、追加のビジネス固有のスキーマ制約 (またはその他の何らかのメカニズム) も提供します。この点で、BICSは正式なサービス・プロファイリング言語と考えることができます。

動的なSOA環境の重要な特徴として、BICSはXMLドキュメントであるため、SOA環境内のBICS対応のWebスパイダーおよびクローラーは、Webページ上またはレジストリー内の発行済みBICSドキュメントに問い合わせて、特定の業界標準スキーマに対するサポートを判断できます。これにより、動的なB2Bの発見が容易になります。BICSドキュメントに問い合わせることによって、特定のスキーマやその他のメカニズムが情報制約として宣言されているかどうかを調べることができます。

上に戻る

発行済みの具象制約メカニズムについて

すでに述べたように、コアBICSフレームワークは、具象制約メカニズムを定義するための特殊型である抽象InformationConstraintMechanismTypeを提供しています。W3C XML Schema、Schematron、およびMIME型方式では、評価の高い制約メカニズムが発行されています。基底抽象型は、名前や説明など、いくつかの典型的な要素のほか、BICSドキュメントに含まれていない制約の場所をサポートする要素も定義します。これらの要素はすべてのタイプの具象メカニズムに継承され、BICSインスタンス・ドキュメントに一貫性を与え、自動処理を可能にします。

具象制約メカニズムは、特定のタイプで意味のある拡張制約を定めることもできます。一例として、W3C XML Schema Constraint Mechanism仕様は、名前空間と場所のペアを定義するオプションを提供しています。これを使用して、特定の名前空間に対する特定の場所 (URI) のスキーマを使用するように検証処理に命じることができます。これは、垂直的な業界標準を超えた、厳しい制限を含む制約を2次スキーマとして指定するのに特に便利です。すなわち、チェック対象であるXMLインスタンス・ドキュメント内に存在する任意のxsi;schemaLocation属性をオーバーライドするのに便利です。典型的な例としては、現在のデータベースがすでにビジネス内で実用化されていて、特定のビジネスによって特定のフィールド長が必要になる場合などです。詳しくは、W3C XML Schema Constraint Mechanism仕様を参照してください。

BICSフレームワークを使用して、独自の制約メカニズムを定義することもできます。

上に戻る

IBM alphaWorksでのBICSの概念実証

IBM alphaWorksは、Business Information Conformance Statements for Java (BICS4J)をホストしています。これは、BICS 2 仕様をサポートする概念実証ツールキットです。具体的には、このキットには、特定の情報の抜粋をBICSドキュメントに照らして評価する制約エンジンが含まれ、サービス・ビジネス・ロジックのハンドオフの前に、サービス呼び出しチェーンとハンドラーに挿入することができます。この実装はJavaコードで書かれていて、制約エンジンは入力をファイル名、JavaのInpuｔStreams、またはEclipse EMF EObjects形式のサービス・データ・オブジェクトとして受け入れます。

このalphaWorks実装は、Axis 2要求フローでインストールできるApache Axis 2メッセージ・ハンドラーを提供することによって、Webサービス統合もサポートします。受信したSOAP本体の内容の適合性を、メッセージング方式のWebサービスに関連する展開済みのBICSドキュメントに照らしてチェックするために、BICS Webサービス・メッセージ・ハンドラーはBICS制約エンジンを実行します。詳しくは、alphaWorksのBICS4Jページを参照してください。

上に戻る

BICSはどこへ向かうのか

この分野での標準となることが、BICSの主要なモチベーションとなっています。2004年前半の最初のバージョン以来、このテクノロジーは業界団体で議論され、肯定的なフィードバックと関心を集めてきました。BICS4Jは、Webサービスと容易に統合できるBICS 2の概念実証実装を提供します。業界は、次のような環境で、BICSのようにSOAと整合性のある包括的な制約ドキュメントから恩恵を受けることができます。

• 合意可能な内容としてSOA契約に含める。
• Webサービスと同様、インターフェース定義によって参照し、包括的な情報制約を定義する。
• 情報制約を発行するためのSOAレジストリーまたはWebサイトで公示する。
• 上位レベルのサービス・ビジネス・ロジックへハンドオフする前の適合性チェックとして、インフラ・ランタイムで使用する。
• 特定の業界スキーマに対するサポートを検索する際、BICS対応のWebスパイダーおよびクローラーで使用する。

BICS仕様が有効な方向としては、いくつか考えられます。十分な数の支援者が集まれば、BICSが標準策定団体に提出されるかもしれません。IBM alphaWorksのBICS4Jテクノロジーに基づくオープン・ソース実装の可能性も、十分な支援が得られるかどうかにかかっています。BICSが業界標準になるのは有益であると考え、その方向で支援したいと思う場合は、著者に連絡して、ディスカッション・グループに参加してください。

BICS仕様は、評価の高い制約メカニズムを含み、オンラインで入手可能です。「参考文献」のリンクを参照してください。

参考文献

学ぶために

• developerWorksのXMLゾーンとSOA and web servicesゾーンには、この記事で解説した技術を含めて、様々な情報が用意されています。
  
  
• Service Oriented Architecture (SOA) from IBMから、今日のオンデマンド・ビジネス環境で必要なビジネス・プロセスのモデル化や組み立て、展開、管理のための、この柔軟で堅牢なインフラについて学んでください。
  
  

製品や技術を入手するために

• Business Information Conformance Statements for Java (BICS4J) から、IBMのalphaWorks実装をダウンロードしてください。
  
  

議論するために

• BICS Forumで、BICSとその方向性に関して議論してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• BICS 2：更新された仕様
• 業界からのフィードバック
• BICS 2の概要
• サービスは一般に複数の制約メカニズムを必要とする
• ビジネスには垂直的な業界標準を超えた具体的な制約が必要である
• 発行済みの具象制約メカニズムについて
• IBM alphaWorksでのBICSの概念実証
• BICSはどこへ向かうのか
• 参考文献
• 著者について
• コメント