(57)【要約】【課題】アプリケーションを統合する上で有用なコンポーネントを提供する。【解決手段】アプリケーションビュー（１０２）又はアプリケーションビューコンポーネントは、アプリケーション又は企業システムのようなリソースの機能性に対する自己記述型インタフェースを表すことができる。アプリケーションビューは、アプリケーションを処理する際の複雑性の多くを取り去ることができ、それによってプログラマーでない人が、そのアプリケーションのためのアダプタ（１０６）によって公開されたサービス及びイベントを維持することができる。アプリケーションビューはまた、アダプタ（１０６、１０８、及び１１０）がアクセスされる方法を簡単化することができ、アダプタによって公開された機能性をビジネスサービスとして呼び出すことを可能にすることができる。アプリケーションビューは、単一のアダプタに特有とすることができ、対応するアプリケーション上に一組の機能を形成することができる。【選択図】図１
2005506618.tif 000002
【特許請求の範囲】
【請求項１】
第１のアプリケーション内の機能性を呼び出してその機能性を公開するように構成されたリソースアダプタと、
第２のアプリケーションが前記リソースアダプタを通じて前記第１のアプリケーションにアクセスする方法を提供するように構成されたアプリケーションビューコンポーネントと、
を含むことを特徴とする、アプリケーションを統合するためのシステム。
【請求項２】
前記アプリケーションビューコンポーネントは、更に、第２のアプリケーションが前記第１のアプリケーションに関する機能的詳細を知ることなく該第１のアプリケーションにアクセスする方法を提供するように構成されていることを特徴とする請求項１に記載のシステム。
【請求項３】
前記アプリケーションビューコンポーネントは、ビジネス集中化インタフェースであることを特徴とする請求項１に記載のシステム。
【請求項４】
前記アプリケーションビューコンポーネントは、前記第１のアプリケーション内のサービス及びイベントに対する自己記述型インタフェースを提供することを特徴とする請求項１に記載のシステム。
【請求項５】
前記アプリケーションビューコンポーネントは、前記第１のアプリケーション内の機能性をビジネスサービスとして公開するように構成されていることを特徴とする請求項１に記載のシステム。
【請求項６】
前記アプリケーションビューコンポーネントは、前記リソースアダプタに特有であることを特徴とする請求項１に記載のシステム。
【請求項７】
前記アプリケーションビューコンポーネントは、前記第１のアプリケーションに対する一組のビジネス機能を形成するように構成されていることを特徴とする請求項１に記載のシステム。
【請求項８】
前記リソースアダプタは、企業システムを含む第１のアプリケーション内の機能性を呼び出すように構成されていることを特徴とする請求項１に記載のシステム。
【請求項９】
前記アプリケーションビューコンポーネントは、前記第１のアプリケーションと前記第２のアプリケーションとの間の双方向通信を可能にするように構成されていることを特徴とする請求項１に記載のシステム。
【請求項１０】
前記アプリケーションビューコンポーネントは、前記第１のアプリケーションと前記第２のアプリケーションとの間でメッセージを変換することになることを特徴とする請求項１に記載のシステム。
【請求項１１】
前記アプリケーションビューコンポーネントは、該アプリケーションビューコンポーネントを使用することができる「Ｊａｖａ」アプリケーションを有する前記第２のアプリケーションに対する「Ｊａｖａ」インタフェースを更に含むことを特徴とする請求項１に記載のシステム。
【請求項１２】
前記アプリケーションビューコンポーネントは、ステートレスセッションビーンであることを特徴とする請求項１に記載のシステム。
【請求項１３】
アプリケーションビューコンポーネントをビジネスサービスとして呼び出すことを可能にするように構成されたビジネスプロセス管理コンポーネントを更に含むことを特徴とする請求項１に記載のシステム。
【請求項１４】
前記アプリケーションビューコンポーネントと共に使用して、ウェブサービスを該アプリケーションビューコンポーネントを通じて呼び出すことを可能にするように構成されたウェブサービスインタフェースを更に含むことを特徴とする請求項１に記載のシステム。
【請求項１５】
前記アプリケーションビューコンポーネントのホストとなるように構成された統合フレームワークを更に含むことを特徴とする請求項１に記載のシステム。
【請求項１６】
前記統合フレームワークは、アプリケーションビューコンポーネントを作成するために使用することができるグラフィカル・ユーザ・インタフェースを含むことを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記アプリケーションビューコンポーネントは、前記リソースアダプタと該アダプタによって公開される機能性の利用法との間に抽象化層を提供することを特徴とする請求項１５に記載のシステム。
【請求項１８】
前記アプリケーションビューコンポーネントは、アプリケーションに関するデータに対応する統合ポイントの定義を可能にするように構成されていることを特徴とする請求項１に記載のシステム。
【請求項１９】
前記アプリケーションビューコンポーネントは、更に、前記統合ポイントがビジネスセマンティクスにより編成されることを可能にするように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記アプリケーションビューコンポーネントは、「ＸＭＬ」ベースのインタフェースであり、
前記第１のアプリケーションは、企業システムであり、
前記第２のアプリケーションは、アプリケーションサーバである、
ことを特徴とする請求項１に記載のシステム。
【請求項２１】
第３のアプリケーションが前記リソースアダプタを通じて前記第１のアプリケーションにアクセスする方法を提供するように構成された第２のアプリケーションビューコンポーネントを更に含むことを特徴とする請求項１に記載のシステム。
【請求項２２】
前記アプリケーションビューコンポーネントは、更に、前記第１のアプリケーションに対する各サービスを論理的ビジネス機能として公開するように構成されていることを特徴とする請求項１に記載のシステム。
【請求項２３】
前記アプリケーションビューコンポーネントは、更に、企業システムと対話するための手順を記述するメタデータを提供するように構成されていることを特徴とする請求項１に記載のシステム。
【請求項２４】
前記アプリケーションビューコンポーネントは、「ＸＭＬ」スキーマの形式でメタデータを提供することを特徴とする請求項２３に記載のシステム。
【請求項２５】
前記アプリケーションビューは、アウトバウンドメッセージ、メッセージを返すインバウンド要求、及び、アウトバウンドで送信するか又はインバウンドで処理することができるメッセージに対する記述のビューから成るグループから選択された機能を公開するように構成されていることを特徴とする請求項１に記載のシステム。
【請求項２６】
前記アプリケーションビューコンポーネントにアクセスするためのユーザインタフェースを提供するように構成されたアプリケーションビューコンソールを更に含むことを特徴とする請求項１に記載のシステム。
【請求項２７】
前記アプリケーションビューコンポーネントのためのコンテナー、
を更に含み、
前記コンテナーは、要求に対してサービスを提供することができる、前記アプリケーションビューコンポーネントに対して割り当てられたリソースを有する、
ことを特徴とする請求項１に記載のシステム。
【請求項２８】
前記リソースアダプタは、サービスアダプタ及びイベントアダプタから成るグループから選択されることを特徴とする請求項１に記載のシステム。
【請求項２９】
データベースの記録を更新するための「ＳＱＬ」ステートメントを包含する更新方法を呼び出す「ＸＭＬ」メッセージを受け取るために、アプリケーションビューコンポーネントを使用する段階と、
前記アプリケーションビューコンポーネントからリソースアダプタを呼び出して、前記「ＳＱＬ」ステートメントを前記リソースアダプタに通す段階と、
前記リソースアダプタを使用して企業システム内の企業データにアクセスし、その結果を前記アプリケーションビューコンポーネントに戻す段階と、
前記結果を応答「ＸＭＬ」メッセージとして前記アプリケーションビューコンポーネントから戻す段階と、
を含むことを特徴とする、データベースの記録を更新する方法。
【請求項３０】
企業システムのためのリソースアダプタを創出する段階と、
アプリケーションビューコンポーネントによってサポートされるプロセスを判断する段階と、
ビジネスアナリストからいくつかのビジネスプロセスで使用されるアプリケーションのビジネス要件に関する情報を集めることにより、前記アプリケーションビューコンポーネントに含まれるサービス及びイベントの種類を判断する段階と、
を含み、
必要なプロセスが判断された状態で、適切なサービス及びイベントを形成して試験することができる、
ことを特徴とする、アプリケーションビューコンポーネントを形成する方法。
【請求項３１】
第１のアプリケーション内の機能性を呼び出すための手段と、
その機能性をビジネスサービスとして第２のアプリケーションに公開するための手段と、
を含むことを特徴とする、アプリケーションを統合するためのシステム。
【請求項３２】
アプリケーション内の機能性を公開するためのリソースアダプタを設ける段階と、
前記公開された機能性をビジネスサービスとして呼び出すために、前記リソースアダプタに対するインタフェースを設ける段階と、
を含むことを特徴とする、アプリケーションを統合する方法。
【請求項３３】
根底のアプリケーション内の複雑性を取り去るための手段と、
前記根底のアプリケーション内の機能性へのアクセスを提供する手段と、
を含むことを特徴とする、アプリケーションを統合するためのシステム。
【請求項３４】
第１のアプリケーション内の機能性を呼び出すための手段と、
その機能性をビジネスサービスとして第２のアプリケーションに公開するための手段と、
を含むことを特徴とするコンピュータ可読メディア。
【請求項３５】
アプリケーションを統合するためにサーバコンピュータによって実行されるコンピュータプログラム製品であって、
第１のアプリケーション内の機能性を呼び出すためのコンピュータコードと、
その機能性をビジネスサービスとして第２のアプリケーションに公開するためのコンピュータコードと、
を含むことを特徴とする製品。
【請求項３６】
第１のアプリケーション内の機能性を呼び出すための手段と、
その機能性をビジネスサービスとして第２のアプリケーションに公開するための手段と、
を含むことを特徴とする、アプリケーションを統合するためのシステム。
【請求項３７】
プロセッサと、
前記プロセッサによって実行されるオブジェクトコードと、
を含み、
前記オブジェクトコードは、
第１のアプリケーション内の機能性を呼び出し、
その機能性をビジネスサービスとして第２のアプリケーションに公開する、
ように設定される、
ことを特徴とするコンピュータシステム。
【請求項３８】
伝送メディアに組み込まれたコンピュータデータ信号であって、
第１のアプリケーション内の機能性を呼び出す命令を含むコードセグメントと、
その機能性をビジネスサービスとして第２のアプリケーションに公開する命令を含むコードセグメントと、
を含むことを特徴とする信号。
【発明の詳細な説明】
【技術分野】
【０００１】
優先権主張
本出願は、本明細書においてそれぞれ引用により組み込まれる下記の出願に対して優先権を主張する。
「アプリケーションビュー」という名称の米国特許仮出願第６０／３４７，９１９号、２００１年１０月１８日出願。
「イベントアダプタ」という名称の米国特許仮出願第６０／３４７，９０１号、２００１年１０月１８日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「システム統合のためのアプリケーションビューコンポーネント」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「ワークフローのためのビジネス機能性を呼び出すシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「イベントアダプタを実施するためのシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーション統合のためのコネクター方式を使用するシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーション統合におけるスキーマオブジェクトモデルを実施するためのシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「文書を照会するためにインタフェースコンポーネントを利用するシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーション統合のために非同期メッセージングを使用するシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「サービスアダプタを実施するためのシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
著作権表示
本特許文書の開示部分は、著作権保護を受ける内容を含む。著作権所有者は、特許開示内容の特許文書を「特許商標局」の特許ファイル又は記録に現れている形で誰でもファクシミリ複製することに異議はないが、それ以外は一切の著作権の権利を受けるものである。
引用事例
以下の出願は、相互参照されて本明細書において引用により組み込まれる。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーションビューコンポーネントに対して「Ｊａｖａ（登録商標）」インタフェースを提供するためのシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「ワークフローのためのビジネス機能性を呼び出すためのシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「エンタープライズシステムと共にウェブサービスを使用するためのシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「イベントアダプタを実施するためのシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーション統合のためのコネクター方式を使用するシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーション統合におけるスキーマオブジェクトモデルを実施するためのシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「文書を照会するためにインタフェースコンポーネントを利用するシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーション統合のために非同期メッセージングを使用するシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「統合アダプタセキュリティのためのシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「サービスアダプタを実施するためのシステム及び方法」という名称の米国特許出願第（  ）号、２００２年１０月１５日出願。
本発明は、全体的に、アプリケーションを統合する上で有用なコンポーネントに関する。
【背景技術】
【０００２】
電子商取引は、新しい経済における主要な推進要素になってきた。長期的に成功するために、電子商取引には多くの会社が企業間協力に参加することが必要になる。企業間の統合を実現するために、会社は、第１に会社内部のアプリケーションを統合すべきである。既存の技術とツールを使用すると、アプリケーションの統合は、費用の掛かる事柄になる可能性がある。使用が簡単で、費用が手頃で、業界基準に準拠する統合ソリューションは存在しない。また、業界基準のインフラストラクチャーに準拠し、一般的な接続性があり、大幅な拡張性の機能があり、アクセス可能なビジネスプロセスツールを有するソリューションも存在しない。
【０００３】
この点に関してアプリケーションの統合は非常に内向的であった。既存の多くの統合システムは、企業間のアプリケーション統合に着目してこなかった。統合ソリューションが企業間の統合に使用されたとしても、そのソリューションはまだ焦点が狭く、垂直市場を目標にしていた。この内向的な性質は、収益を生んでコストを低減するために「インターネット」を使用することができるアプリケーションのような外部のビジネス対消費者及びビジネス対ビジネスのアプリケーションを会社が展開するのにほとんど役に立たなかった。「インターネット」使用可能アプリケーションに対する必要性は、アプリケーションサーバ市場の台頭をもたらした。現在まで、アプリケーションサーバは、主に顧客及び取引相手を目標にした外部アプリケーションのホストとなるために使用されてきた。アプリケーションサーバは、それ自体がパッケージ化されたアプリケーションであり、特定の問題を解決するのではなく、垂直的ソリューションのホストとなる汎用プラットフォームである。
【０００４】
アプリケーション統合における最初の試みは、主として、データのフォーマット、マシン間のバイトの順序付け、及び文字の符号化のような低レベルの実施の詳細に着目された。アプリケーション統合ソリューションの第１世代においては、複数の垂直アプリケーションに亘って使用し得るデータ符号化に対する広く採用された基準がなかったので、低レベルのデータフォーマットに着目することが必要であった。
従来的な手法は、実質的にシステムを互いに配線するために個々のシステムを接続することが必要であった。別々のシステムの接続には複数のシステムの独占的技術の詳しく低レベルの知識が必要なので、この手法は複雑になる可能性がある。
【０００５】
【特許文献１】
米国特許仮出願第６０／３４７，９１９号
【特許文献２】
米国特許仮出願第６０／３４７，９０１号
【特許文献３】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「システム統合のためのアプリケーションビューコンポーネント」）
【特許文献４】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「ワークフローのためのビジネス機能性を呼び出すシステム及び方法」）
【特許文献５】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「イベントアダプタを実施するためのシステム及び方法」）
【特許文献６】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーション統合のためのコネクター方式を使用するシステム及び方法」）
【特許文献７】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーション統合におけるスキーマオブジェクトモデルを実施するためのシステム及び方法」）
【特許文献８】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「文書を照会するためにインタフェースコンポーネントを利用するシステム及び方法」）
【特許文献９】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーション統合のために非同期メッセージングを使用するシステム及び方法」）
【特許文献１０】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「サービスアダプタを実施するためのシステム及び方法」）
【特許文献１１】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「アプリケーションビューコンポーネントに対して「Ｊａｖａ」インタフェースを提供するためのシステム及び方法」）
【特許文献１２】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「エンタープライズシステムと共にウェブサービスを使用するためのシステム及び方法」）
【特許文献１３】
米国特許出願第（  ）号（２００２年１０月１５日出願、Ｍｉｔｃｈ  Ｕｐｔｏｎに付与された「統合アダプタセキュリティのためのシステム及び方法」）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
システムを互いに「配線する」ことをやめた現在の統合システムは、依然として基準の欠如に苦しんでいる。各統合ベンダーは、一般的に、アプリケーション統合、メッセージ変換、メッセージフォーマット、メッセージ搬送、及び経路指定に関して独占的ソリューションを提供する。現在に至るまで、これらのシステムの１つ足りとも、その技術が事実上の基準になるのを可能にするような大幅なマーケットシェアを達成していない。この基準の欠如は、パッケージ化アプリケーションベンダーに対して、これらのシステムを彼らのアプリケーションと統合させるインセンティブをほとんど与えなかった。更に、これらの統合システム又はサーバの各々は、独自の専用「ＡＰＩ」を有しており、そのために、パッケージ化アプリケーションベンダーは、単一統合サーバを超えてその発展を利用することができない。統合マーケットのこの断片化は、第三者に対して財務的インセンティブをほとんどもたらさなかった。
【課題を解決するための手段】
【０００７】
本発明によるシステム及び方法は、アプリケーションビュー、アプリケーションビューコンポーネント、及び／又は、アプリケーションビューオブジェクトを利用することによって、アプリケーション統合を提供することができる。第１のアプリケーションにおいて、リソースアダプタを使用して機能性を呼び出し、その機能性を公開することができる。アプリケーションビューコンポーネントを使用して、リソースアダプタを通じて第１のアプリケーション及び／又は呼び出された機能性にアクセスする方法を第２のアプリケーションに対して提供することができる。アプリケーションビューコンポーネントは、第２のアプリケーションが第１のアプリケーションに関する機能性の詳細を知ることなく、第２のアプリケーションの第１のアプリケーションへのアクセスを可能にすることができる。また、アプリケーションビューコンポーネントは、第１のアプリケーションと第２のアプリケーションとの間の双方向通信を可能にすることができ、アプリケーション間でメッセージを変換することができる。
本発明の他の特徴、態様、及び目的は、明細書、図面、及び特許請求の範囲を吟味することによって得ることができる。
【発明を実施するための最良の形態】
【０００８】
アプリケーション統合コンポーネントは、「企業情報システム（ＥＩＳ）」のような様々なアプリケーション及びシステムを統合するのに使用することができる。情報技術（ＩＴ）機構は、通常、いくつかの高度に特化されたアプリケーションを使用する。これらのアプリケーションは、アプリケーションレベルの統合を容易にする共通の統合プラットフォームがなければ、広範囲の高度に特化された開発努力なしには統合することはできない。
アプリケーション統合は、アダプタを利用して、現在又は将来の任意のアプリケーションのための全企業的な結合フレームワークを確立することができる。アダプタは、各アプリケーションが他の全てのアプリケーションと統合されるのを要求する代わりに、各アプリケーションをアプリケーションサーバと統合させることによって統合の労力を簡素化する。
【０００９】
米国カリフォルニア州サンタクララ所在のサン・マイクロシステムズ・インコーポレーテッドの「Ｊａｖａ２プラットフォーム、企業版（Ｊ２ＥＥ）」、及び、「拡張可能マークアップ言語（ＸＭＬ）」のような基準の開発及びその幅広い承認は、これらのアダプタの開発に対する基準化された手法のための基盤を築いてきた。これらの基準でアプリケーション統合のために最も顕著なものは、恐らく「Ｊ２ＥＥコネクター」方式である。「Ｊ２ＥＥコネクター」方式は、ＩＢＭの「ＣＩＣＳ」のような従来のメインフレームアプリケーションから「ＰｅｏｐｌｅＳｏｆｔ」、「Ｓｉｅｂｅｌ」、及び「ＳＡＰ」のようなパッケージ化されたアプリケーションに至るまでの全ての種類のアプリケーションに対するアダプタの開発の基準化された手法を提供する。そのような基準の採用は、会社が例えば任意の「Ｊ２ＥＥ」準拠アプリケーションサーバ上で作動するアダプタを開発することを可能にする。
【００１０】
統合方式
アプリケーション統合は、「Ｊ２ＥＥコネクター」方式ベースのアダプタのホストとなる基準ベースの方式を提供することにより、アプリケーション統合フレームワーク内のこの基準化された手法の上に構築することができる。開発者は、「Ｊ２ＥＥコネクター」方式準拠アダプタを構築し、これらのアダプタを統合フレームワーク内にデプロイ（配置）して企業アプリケーションをアプリケーションサーバに接続することができる。
【００１１】
これらのアダプタを用いて、本明細書でそれぞれのアダプタの「アプリケーションビュー」と呼ぶビジネス集中化インタフェースを「ＥＩＳ」に対して形成することができる。アプリケーションビューは、簡単で自己記述型の整合性を有するインタフェースをアプリケーション内のサービス及びイベントに提供することができる。アプリケーションビューは、「ＥＩＳ」のためのアダプタを利用することができ、既存の情報システムをビジネスサービスとして公開することを可能にする。しかし、アダプタと違って、アプリケーションビューでは、ユーザが「ＥＩＳ」又はその「ＥＩＳ」に対するクライアントインタフェースに関する深い知識を有する必要がなく、そのためにプログラマーでない人や技術アナリストでもアプリケーションビューを使用することができる。アプリケーションビューは、ビジネスアナリストがアダプタ内に定義されたプログラマチックな詳細を心配せずに企業データにアクセスするビジネス志向の方法を提供することができる。そうでなければ、これらの同じユーザは、「ＥＩＳ」を熟知していないのでアダプタを直接使用することが不可能であろう。
【００１２】
企業アプリケーション統合で指定されたアプリケーション統合コンポーネントは、いくつかの重要な態様を有することができる。「ＰｅｏｐｌｅＳｏｆｔ」システム又は「ＳＡＰ」システムのような「ＥＩＳ」の機能性が呼び出される場合、「Ｊ２ＥＥコネクター方式」の実施を使用することができる。「ＥＩＳ」システム内部でトリガが始まるなどの何かが起きる場合、イベントを発生させることができる。いくつかの実施形態では、このイベントを外部アプリケーションと通信する必要があるであろう。アプリケーション統合コンポーネント内のイベント方式は、この通信を処理することができる。
【００１３】
アプリケーションビュー
アプリケーションビューは、アプリケーション統合コンポーネントに対して大きな価値を提供することができる。アプリケーションビューは、バックエンド「ＥＩＳ」システムのようなアプリケーションを処理する際の複雑性の大部分を取り去ることができる。アプリケーションビューはまた、アダプタがアクセスされる方法を単純化することができる。アプリケーションビューは、例えば、アダプタとそのアダプタによって公開された「ＥＩＳ」機能性との間に抽象化の層を提供することができる。直接プログラムすることによって「ＥＩＳ」にアクセスする代わりに、ユーザは、単にアダプタのアプリケーションビューを編集し、新しいアプリケーションビューを作成するか、又は古い任意のアプリケーションビューを削除することができる。アプリケーションビューによって形成された抽象化層は、プログラマーでない人がアダプタによって公開されたサービス及びイベントを維持するための手助けになることができる。各アプリケーションビューは、単一のアダプタに専用とすることができ、そのアダプタの「ＥＩＳ」上に一組のビジネス機能を形成することができる。アダプタが作成された後は、アダプタのためのウェブベースのインタフェースを使用してアプリケーションビューを形成することができる。
【００１４】
アプリケーションビューがアダプタのための主要なユーザインタフェースとして使用される場合、既存の企業アプリケーション統合技術では通常見出せないいくつかの特徴を含ませることができる。例えば、アプリケーションビューは、アプリケーション間の共通言語として「ＸＭＬ」を使用することができる。サービス及びイベントの定義を用いて、アプリケーションの機能性を公開することができる。「ＸＭＬ」スキーマを用いて、サービス及びイベントのためのデータを形成することができる。双方向通信はまた、アダプタ内でもサポートすることができる。
【００１５】
アプリケーションビューは、インタフェースのオブジェクトとして使用される場合は、統合フレームワークの一体部分とすることができる。アプリケーションビューは、ユーザによって特定の必要性に応じるようにカスタム化することができるアダプタによって公開されたアプリケーションの機能性の表示を提供することができる。ユーザは、アプリケーションビューを例えば特定のビジネス目的のために調整することができる。その結果、アプリケーションビューは、多くのアプリケーションがクライアントインタフェースの設計に対して提供する「１つのサイズが全てに適合する」手法の有効な代替手法を提供することができる。アプリケーションビューは、特定の目的に適用可能なビジネス又は他の機能専用として形成することができる。これらの機能は、命名、記述、及びデータ要件の形成などによってカスタム化することができる。
【００１６】
図１に示す一例においては、クライアントアプリケーション１００がアプリケーションビュー１０２を使用して「企業情報システム」１０４と通信することを可能にするアダプタ１０６、１０８、及び１１０を創出することができる。開発者は、企業データにアクセスする企業アプリケーション内の機能性を公開するアダプタをコード化することから開始することができる。アダプタが公開する機能性は、例えば、データベース内の記録を「ＳＱＬ」ステートメントを使用して更新することができ、又は、「ＳＡＰ」システムからその「ＢＡＰＩ」又は「ＩＤＯＣ」インタフェースを使用して情報を要求することができるであろう。次に、開発者と協働するビジネスアナリストは、アプリケーションビューのインタフェースを使用してアダプタのアプリケーションビューを形成することができる。
【００１７】
アプリケーションビューは、一実施形態においては、ステートレスセッション「ＪａｖａＢｅａｎ」として実行されるオブジェクトである。クライアントアプリケーションのためのアプリケーションビューに対して、「Ｊａｖａ」インタフェースが存在することができる。「Ｊａｖａ」アプリケーションは、「ＸＭＬ」を中に通して「ＸＭＬ」を再度受け取ることにより、そのオブジェクトを使用するようにカスタムコード化することができる。それに加えて、ビジネスプロセスマネージメントコンポーネントを含むことができ、それによって、プロセスエンジニアは、ワークフローを形成することが可能になり、アプリケーションビューをビジネスサービスとして呼び出すことが可能になる。ワークフローにおいては、顧客の信用記録のような情報を取得するために「ＥＩＳ」に対してコールアウトを実行することができる。アプリケーションビューが「Ｊａｖａ」オブジェクト又は企業「ＪａｖａＢｅａｎ」であるという事実は、プロセス及び設計者から隠すことができる。
【００１８】
ウェブサービスインタフェースはまた、アプリケーションビューと共に使用することができる。ウェブサービスを呼び出すために、「ＳＯＡＰ」のようなプロトコルを使用することができる。使用することができる別のプロトコルは、プラットフォームに依存せず、サービスを記述するためのオープンフレームワークであり、ビジネスを見つけ出し、「インターネット」を利用してビジネスサービスを統合する「ＵＤＤＩ」を含む。ネットワークサービスを記述するための「ＸＭＬ」フォーマットである「ＷＳＤＬ」プロトコルも使用することができる。ウェブサービスとして任意のアプリケーションビューを呼び出すことができるように、アプリケーションビューの上にウェブサービス層を設けることができる。
【００１９】
アプリケーション統合においては、ウェブベースのインタフェースを通じて既存の「ＥＩＳ」に対して新しいアプリケーションビューをホットデプロイすることができる。アプリケーションビューは、システム実行中にデプロイされる場合は、宛先サーバを再起動させることなくホットデプロイされる。例えば「ＳＡＰ」のための新しい顧客管理ツールも、ウェブブラウザを通じて形成することができる。ユーザはまた、アプリケーションビューが継続してデプロイされるべきか否かを決めることができる。継続デプロイとは、アプリケーションサーバが再起動される時はいつでもアプリケーションビューを再デプロイすることができることを意味する。
【００２０】
統合フレームワーク
アプリケーション統合は、アプリケーションビューのホストとなるための体系化された基準ベースの方式を提供することが可能な統合フレームワークを利用することができる。そのようなフレームワークの特徴には、アプリケーションビューを作り出すために使用することができるウェブベースインタフェースのようなアプリケーション機能及び設計時グラフィカル・ユーザ・インタフェース（ＧＵＩ）を公開するためのアプリケーションビューを含むことができる。統合フレームワークは、互いに企業システムを「配線する」代わりにアダプタを利用する。アダプタが「ＥＩＳ」に対してデプロイされた状態で、他のコンポーネント及びアプリケーションは、「ＥＩＳ」上のデータにアクセスするためにそのアダプタを使用することができる。
【００２１】
本発明の一実施形態によるフレームワークは、メッセージのための標準フォーマットとしての「ＸＭＬ」に依存する。「ＸＭＬ」は、「ＸＭＬ」文書を他の「ＸＭＬ」文書に変換するための基準である「ＸＳＬＴ」を含む。「ＸＳＬＴ」は、「ＸＭＬ」のスタイルシート言語である「ＸＳＬ」の一部として使用するために設計される。「ＸＳＬＴ」においては、「ＸＭＬ」文書を用いて、その文書の構造及びコンテントを変換するために「ＸＭＬ」文書のクラス上で実行する演算を特定する。「ＸＳＬＴ」変換は、「Ｊａｖａ」プログラミング言語に構築された任意の演算を利用することができ、又は、「Ｊａｖａ」又はネイティブコードで書かれたカスタム演算を利用することができる。統合フレームワークにより、「ＸＭＬ」メッセージを変換するためにビジネスプロセスが「ＸＳＬＴ」エンジンを呼び出すことが可能になる。
【００２２】
統合フレームワークはまた、「Ｊａｖａメッセージサービス（ＪＭＳ）」及び「ＨＴＴＰＳ」のようなメッセージ搬送のための基準に依存することができる。「ＪＭＳ」は、メッセージ搬送システムとインタフェースで接続するための標準的「ＡＰＩ」である。「ＪＭＳ」を使用して、フレームワークは、「ＪＭＳ」インタフェースを提供する任意のメッセージ搬送機構を利用することができる。「Ｊ２ＥＥコネクター」方式の基準は、メッセージ搬送機構を特定しないが、アプリケーション統合フレームワークは、そのような搬送機構を特定することができる。
【００２３】
統合フレームワークは、「Ｊ２ＥＥ」、「ＪＭＳ」、及び「Ｊ２ＥＥコネクター」方式をサポートするアプリケーションサーバのような既存の標準的インフラストラクチャーに基づくことができる。そのような標準的インフラストラクチャーの使用はまた、クラスタリング及びリソースプーリングによるなどして高い利用可能性と拡張性を提供する。このフレームワークは、既存のパッケージ化された任意のアプリケーションと接続することができる「ＸＭＬ」ベースのアプリケーションアダプタの構成を使用可能にすることにより、汎用性のある接続性を提供することができる。アダプタ開発キットを使用して、顧客、システム統合者、パッケージアプリケーションベンダーのようなユーザが、「Ｊ２ＥＥコネクター」方式に準拠して統合フレームワークをベースとするアダプタを迅速に開発することを可能にすることができる。フレームワークは、「ＸＭＬ」を利用することができ、これは、多くの電子商取引システムが標準的メッセージングフォーマットとして「ＸＭＬ」を使用するので、企業統合内部及び企業統合間の両方のために同じデータフォーマットを使用することができることを意味する。
【００２４】
統合フレームワークはまた、ビジネスプロセスエンジンを利用して、プログラマーでない人がビジネスプロセスをグラフィカルに構築して維持することを可能にすることができる。統合フレームワークは、ビジネスレベルの概念に着目した「Ｊ２ＥＥコネクター」方式の上に共通のモデルを実施することができる。このモデルは、「ＸＭＬ」で符号化されたイベント及びサービスから成り、アダプタとその目標とするアプリケーションとの間に要求されるインタフェースに関係なく、整合性のある統合環境の管理を可能にする。ビジネスプロセスは、アプリケーションによって生成されたイベントに反応することができ、それらは、アプリケーションアダプタによって公開されるサービスを通じてアプリケーションの機能性を呼び出すことができる。
【００２５】
抽象化
上述の通り、アプリケーションビューは、アプリケーションに対する基準化された自己記述型インタフェースとすることができるので、アダプタの技術的な実施とアダプタによって公開された機能性の使用との間に抽象化層を提供することができる。
一例において、アプリケーションの機能のビジネスレベル表示は、プログラマーとビジネスアナリストとの論理的分離を提供することができる。例えば、この抽象化は、ビジネスアナリストが、「ＳＱＬ」ステートメントのようなデータベースを記録するステートメントを知る必要なく、データベースに記録を作り出すことを可能にする。
【００２６】
例えば、「ＳＱＬ」ステートメントを使用してデータベースの記録を更新するために、ビジネスアナリストは、「ＵｐｄａｔｅＲｅｃｏｒｄｓ」というアプリケーションビューを形成することができる。プログラマーは、データベースの記録を更新する「ＳＱＬ」ステートメントを供給し、これらのステートメントを「ＵｐｄａｔｅＲｅｃｏｒｄｓ」の定義に含むことができる。実行時に、「ＵｐｄａｔｅＲｅｃｏｒｄｓ」は、「ＸＭＬ」メッセージによって例えばビジネスプロセスから呼び出すことができる。次に、アプリケーションビューは、アダプタを呼び出し、「ＳＱＬ」ステートメントをアダプタに渡すことができる。アダプタは、企業データにアクセスし、結果を「ＵｐｄａｔｅＲｅｃｏｒｄｓ」アプリケーションビューに返すことができ、それは、別の「ＸＭＬ」メッセージで結果を返すことができる。
【００２７】
アプリケーションビューの形成
ユーザは、ある場合にはアプリケーションビューを形成し、別の場合にはカスタムコードを書き込む必要があるであろう。アダプタの設計時「ＧＵＩ」の使用が「ＥＩＳ」の機能性を公開する唯一の方法ではないが、いくつかの状況では最も便利な方法とすることができる。サービスの呼び出し及びイベントをサポートするために、アプリケーションビューを形成するか又はカスタムコードを書き込んで特定の機能性が達成することができる。多くの場合、アプリケーションビューは、アプリケーション機能を公開するために各アダプタに対して形成することができる。他の状況において、又は、更なる制御を要求するユーザに対して、アダプタのリソースにアクセスするためにカスタムコードを書き込むことができる。企業に対しては、両方を組み合わせた方法を使用することができる。
【００２８】
一般に、アプリケーションビューは、企業に１つよりも多い「ＥＩＳ」システムが存在し、特に、全てのシステムについて詳細で完璧な知識を持った開発者がいない状況に対して形成することができる。アプリケーションビューはまた、例えば、ビジネスプロセスを構築して管理するために統合スタジオが使用される時、又は、アダプタのパラメータ又はそのプロセスの１つの更新が必要になる場合に形成することができる。
【００２９】
アプリケーションビューは、ユーザが、特定アプリケーションに関するフィールドとデータを閲覧することによって統合ポイントを形成することを可能にすることができる。アプリケーションビューを形成することにより、ユーザは、顧客管理システム、販売、注文管理システム、又は購買発注管理システムに対するような統合の終点を形成することができる。ユーザは、各ビジネス用途のためのアプリケーションビューを作成することができ、統合フレームワークコンポーネントを使用してこれらのアプリケーションビューをデプロイ及び管理することができる。
【００３０】
アプリケーションビューを形成することを試みる前に、いくつかの前提条件を満足する必要があると考えられる。第１に、例えば「ＡＤＫ」を使用することによって適切なアダプタが開発されていなければならない。いくつかのアプリケーションビューは、既存のアダプタに対してのみ作成及び構成することができる。また、構成されるアプリケーションビューによってどのプロセスをサポートする必要があるかも判断されるべきである。要求された任意のプロセスが、アプリケーションビューに組み込まれるサービス及びイベントの種類を決めることができる。これは、例えば、いくつかのビジネスプロセスと共に使用されるビジネスアナリストからのアプリケーションのビジネス要件に関する情報の収集を要求することができる。必要なプロセスが判断された状態で、適切なサービス及びイベントを形成して試験することができる。
【００３１】
アプリケーションビューを形成する時、アプリケーションサーバと企業内の特定「ＥＩＳ」アプリケーションとの間に「ＸＭＬ」ベースのインタフェースのようなインタフェースを作成することができる。アプリケーションビューが作成された状態で、ビジネスアナリストは、それを使用して例えばアプリケーションを使用するビジネスプロセスを作成することができる。アダプタに対しては、各々が任意数のサービス及びイベントを伴う任意数のアプリケーションビューを作成することができる。
【００３２】
図２は、本発明の一実施形態によりアプリケーションビューを形成する方法の概略を示す。アプリケーションビューコンソールを使用して本方法が説明されるが、データ及び／又はオプションの入力及び／又は選択を可能にする他の任意の適切なユーザインタフェースを使用することができることを理解すべきである。ユーザは、第１に、アプリケーションビューコンソール２００にログオンする。適切なアダプタに対するアプリケーションビューを作成するために、ユーザは、コンソールを通じてアプリケーションビューを追加又は作成するようにオプションを選択することができる。この新しいアプリケーションビューは、このアダプタの目標とする「ＥＩＳ」アプリケーションのために一組のビジネスプロセスを使用可能にすることになる。ユーザは、アダプタ、「ＥＩＳ」、及び／又はビジネスプロセス２０２に必要なようにアプリケーションビューを形成することができる。ユーザは、アプリケーション接続パラメータ２０４を入力して構成することができる。情報は、コンソールによって確認することができ、指定のシステムに接続するようにアプリケーションビューを構成することができる。ユーザは、イベント２０８又はサービス２０６を追加することができ、このアプリケーションビューのために適切なイベント及びサービスを形成することができる。次に、アプリケーションビューが、アプリケーションサーバ上にデプロイされ（２１０）、従って、少なくとも任意のセキュリティの設定により、他のエンティティは、このアプリケーションビューと対話することができる。サービスを試験することができ（２１２）、かつ、イベントを試験することができ（２１４）、それらが目標とする「ＥＩＳ」アプリケーションと適正に対話することを確実にする。サービス及びイベントが試験されて機能する状態で、アプリケーションビューは、ワークフローにおいて使用することができる。接続パラメータを再設定するか、又は、サービス及びイベントを追加するために、アプリケーションビューは、必要に応じてアンデプロイすることができる（２１６）。
【００３３】
簡単に「ＤＢＭＳ」と呼ばれる仮定のデータベース「ＥＩＳ」のための「ＥＩＳ」アダプタの例を使用して、アプリケーションビューを形成して維持する１つの手法を示すことができる。アプリケーションビューが企業のために作成されると、アプリケーションビューの画面は、別の企業の画面と違って見える場合がある。アプリケーションビューのアダプタは、各アプリケーションビューのページに必要な情報を判断することができ、各企業は、独自の専用アダプタを有することができる。
【００３４】
この新しいアプリケーションビューを作成する第１の段階は、アプリケーションビューの「コンソール」ページにログオンすることである。「コンソール」は、アプリケーション統合環境内の全てのアプリケーションビューを恐らくフォルダに編成するようにして表示することができる。「コンソール」にログオンするために、ユーザは、適切なアプリケーションビュー「コンソール」に対する「ＵＲＬ」を使用してウェブブラウザのウインドウを開くことができる。「コンソール」にログオンしてフォルダまでナビゲートするか、又は新しいフォルダを作成した後に、ユーザは、クリックしてアプリケーションビューを追加及び／又は形成することができる。次に、「定義」ページを表示することができる。いくつかの実施形態においては、アプリケーションビューは、一度形成されると別のフォルダに移動できない。
【００３５】
「定義」ページは、ユーザが例えばアプリケーションによって実行された機能の組を記述する名前のようなアプリケーションビューのための名前を入力することができるフィールドとすることができる。各アプリケーションビューの名前は、そのアダプタに対して独特のものであり、文字と数字の両方を含むことができる。記述フィールドには、ユーザは、任意の関連する注釈を入力することができる。これらの注釈は、ユーザがこのアプリケーションビューをビジネスプロセス管理（ＢＰＭ）を使用するワークフローのようなワークフローで使用する時にユーザによって閲覧することができる。関連するアダプタのリストから、ユーザは、このアプリケーションビューを生成するために使用するアダプタを選択することができる。
次に、ユーザは、適切な接続パラメータの設定ができるページにナビゲートすることができる。ここで、ユーザは、目標とする「ＥＩＳ」と対話するためのアプリケーションビューにとって必要なネットワーク関連情報を形成することができる。この情報は、アプリケーションビュー毎に一度入力することができる。
【００３６】
アプリケーションビューの作成及び設定の後に、ユーザは、アプリケーションの機能性をサポートするサービスを追加することができる。アプリケーションビューが開いている間、ユーザは、「管理」ページにナビゲートすることができる。ここで、ユーザは、サービスを追加することができ、このサービスによって実行することができる機能を記述する名前をサービスに付ける。各サービス名は、そのアプリケーションビューにとって独特のものとすることができる。ユーザは、任意の関連する注釈を記述又は同様のフィールドに入力することができる。これらの注釈は、ユーザが「ＢＰＭ」を使用してワークフロー内でこのアプリケーションビューのサービスを使用する時に閲覧することができる。完了すると、ユーザは、サービスを追加するのと同様の以下の段階により、アプリケーションビューにイベントを追加することができる。
【００３７】
イベント及びサービス
アプリケーションビューは、下にあるアダプタを通じてアプリケーションのイベント及びサービスをサポートすることができる。これらのイベント及びサービスは、特定のビジネスプロセス向けのような特定用途に対して確立することができる。一例においては、「イベント」により、アプリケーションによって生成されたメッセージは、以下の発行／購読モデルで管理することができる。このモデルにおいて、ユーザは、アプリケーションによって「発行」されたメッセージを受け取るために「購読」することができる。各メッセージは、発行イベント呼ぶことができる。そのようなモデルは、例えばマルチキャスティングを通じて実施することができる。
【００３８】
「サービス」は、ユーザによって呼び出し可能なビジネス機能の役割を果たすことができる。サービスの呼び出しにより、以下の要求／応答モデルに従ってアプリケーションへのメッセージの送信を引き起すことができる。このモデルは、メッセージがユーザによって要求された時にだけ送られるという点で、発行／購読モデルとは異なることができる。これは、例えば２地点間メッセージングシステムを使用して実施することができる。イベント及びサービスは、両方とも「ＸＭＬ」文書としてシステムを通過することができる。
【００３９】
サービスは、アプリケーションビューが再使用のために公開するアプリケーション内のビジネス論理を構成することができる。アプリケーションビューが、ビジネスサービスを呼び出す要求を含む「ＸＭＬ」文書を受け取ると、アプリケーションビューは、その目標アプリケーション内でその機能性を呼び出し、その結果を記述する「ＸＭＬ」文書を返すことができる。アプリケーションビュー上の各サービスは、目標アプリケーション内で単一の論理的ビジネス機能のような単一機能を表すことができる。サービスは、「ＸＭＬ」文書の形式などで要求データを取り、同じく「ＸＭＬ」文書の形式を取ることができる応答データを返すことができる。サービスは、アプリケーションビューのクライアントと目標アプリケーションとの間の双方向通信を表すことができる。サービスは、アプリケーション間の同期又は非同期通信を考慮することができる。
【００４０】
メタデータ
一実施形態によるアプリケーションビューの１つの重要な特性は、「ＥＩＳ」システムと対話するための手順を記述するメタデータを提供する能力である。アプリケーションビューは、利用することができる全ての利用可能なサービスをクライアントアプリケーションに通知することができる。顧客管理の例の場合には、これらは、「ＧｅｔＣｕｓｔｏｍｅｒＤｅｔａｉｌ」又は「ＣｈｅｃｋＯｒｄｅｒＳｔａｔｕｓ」のようなサービスであろう。アプリケーションビューは、例えば「ＸＭＬ」スキーマ形式で、それ自体に関するメタデータを提供することができる。
アプリケーションビューはまた、自己記述型メタデータを含むことができる。イベント、サービス要求、及び応答に関する「ＸＭＬ」情報を記述するために、アプリケーションビューは、メタデータとして「ＸＭＬ」スキーマを使用することができる。このメタデータは、ユーザが、関心のあるイベント又はサービスのデータ要件を理解するのを助けることができる。
【００４１】
アプリケーションビューの機能性をメタデータとして表現することができるので、アプリケーションビューは、１つのシステム上で作成されて別のシステム上にデプロイすることができる。アプリケーションビューは、例えばプログラマーとビジネスアナリストとの論理的分離を提供することができる。ビジネスアナリストは、「ＳＱＬ」を知る必要なくデータベース内に記録を作成することができ、又は、「ＳＡＰ」に関する技術的な理解が無くても「ＳＡＰ」から情報を要求することができる。アプリケーションビューは、整合性のあるデータ表現を、アダプタによって使用されるその根底の実施に関係なく提供することができる。例えば、各「ＥＩＳ」は、「ＸＭＬ」インタフェースを有するであろう。クライアントが利用可能な全ての対話に対して、その対話に関する有効な「ＸＭＬ」文書の判断基準を記述する対応する「ＸＭＬ」スキーマが存在する可能性がある。アプリケーションビューは、「顧客管理」、「注文処理」、及び「在庫管理」のようなビジネスセマンティクスによって企業の統合ポイントが編成されるのを可能にすることができる。
【００４２】
いくつかの状況下では、アプリケーションビューのクライアントに対して、アウトバウンドメッセージと、メッセージを返すインバウンド要求と、アウトバウンドで送られるか又はインバウンドで処理することができる任意のメッセージの記述を閲覧する方法とを含む少なくとも３つの特徴を公開することができることに注意すべきである。アダプタに対する可能な接続が公開された状態で、アプリケーションビューは、技術的な詳細をビジネスアナリストから隠すことができる。アダプタは、「ＥＩＳ」専用の接続からアプリケーションビューが使用することができる方法までの移行を行う役割を担うことができる。
【００４３】
共通プロトコル
アプリケーションビューは、共通プロトコルを利用することができる。各アプリケーションは、他の全てのアプリケーションとではなく共通プロトコルとだけ統合されればよいので、共通プロトコルは、アプリケーション統合を可能にするのを助けることができる。共通プロトコルにより、アプリケーションは、「ＸＭＬ」のような標準的言語を使用して通信することができる。そのような１つの共通プロトコルは、「ＸＭＬ」文書によって表現されたイベント及びサービスに基づくことができる。アダプタは、アプリケーションビューを通じて、アプリケーションの機能性及びデータフォーマットを「ＸＭＬ」フォーマットのイベント及びサービスとして公開することができ、従って、そのイベント及びサービスは、統合サービスの全てのクライアントによって使用される。
【００４４】
共通プロトコルなしでは、互いの間で変換する必要があるいくつかの異なる言語が存在するであろう。図３（ａ）及び３（ｂ）は、共通プロトコルを有するアプリケーション統合及び共通プロトコルなしのアプリケーション統合を対比して示す。図３（ａ）には、共通プロトコルなしで通信している４つのコンピュータシステム３００、３０２、３０４、及び３０６が示されている。この状況においては、中央ハブ３２０は、コンピュータ３００のためにプロトコル３０８を処理し、同様にコンピュータ３０２、３０４、及び３０６のためにプロトコル３１０、３１２、及び３１４をそれぞれ処理する必要がある。ハブ３２０はまた、全てのバイトフォーマット、文字の符号化、及びプロトコル３０８、３１０、３１２、及び３１４の各々に対する型キャストを処理する必要がある。
【００４５】
図３（ｂ）においては、統合フレームワークは、「Ｊ２ＥＥコネクター」方式の上にアプリケーション統合のための共通プロトコル３１８を提供する。このプロトコル３１８は、アプリケーションビュー３１６を通じてサポートされ、「ＸＭＬ」文書として符号化されたイベント及びサービスから成ることができる。アプリケーションビュー３１６を通じて、各コンピュータシステム３００、３０２、３０４、及び３０６は、共通プロトコル又は正規プロトコルを使用して、他のプロトコルを理解しなくてもコンピュータシステムと通信することができる。更に、中央ハブは、複数のプロトコル３０８、３１０、３１２、及び３１４を処理する必要がなく、共通プロトコル３１８だけを処理することができる。アプリケーションビュー３１６の各々は、整合性のあるデータフォーマットと、統合フレームワーク内の整合性のある挙動とを強化することができる。
【００４６】
アプリケーションビューに対する要求は、たとえ目標アプリケーションに為された要求が「ＳＱＬ」又は直接「ＡＰＩ」呼び出しを使用することができるとしても、「ＸＭＬ」で行うことができる。例えば、図４に示すように、クライアント４００は、２つの別々のアプリケーションビューコンポーネント４０２及び４０４を通じて、３つの別々のアプリケーション４０６、４０８、及び４１０を呼び出すことができる。アプリケーションビュー４０２及び４０４の１つに対する要求には、いかなるログイン情報もあてる必要がない。呼び出しＡ及び呼び出しＢにおいて、「東海岸」アプリケーションビュー４０２に対する呼び出しＡが、「西海岸」アプリケーションビュー４０４に対する呼び出しＢと同じように顧客情報を取得しようと試みる時、両方の呼び出しは、同じ情報が要求している。しかし、実際のデータは、「ＰｅｏｐｌｅＳｏｆｔ」４０６及び「ＳＡＰ」４０８からそれぞれ検索される。呼び出しを開始するクライアント４００は、どのアプリケーションが各要求を実際に処理しているかに気付いていない。呼び出しＢ及びＣにおいては、両方の呼び出しは、同じアプリケーションビュー４０４に付随するが、各要求は、顧客情報を取得する呼び出しＢが「ＳＡＰ」４０８から情報を入手し、顧客履歴を取得する呼び出しＣがレガシーシステム４１０から情報を入手するように、別々に処理される。これにより、単一アプリケーションビュー４０４によって情報の論理的グループ分けを処理することができる。クライアント４００又はユーザは、目標アプリケーションから利用可能な機能性の部分集合を見ることができ、機能性は、更に有用な形に分類することができる。
【００４７】
アプリケーションビューは、「ＸＭＬ」メッセージを「ＥＩＳ」によって要求される必要なインタフェースに変換し、またその逆を行う仲介者とすることができる。更に、アプリケーションビューは、内向的特徴を提供することができ、従って、アプリケーションビューの使用に関心のあるクライアントは、どの機能が利用可能か、及び、各機能が受け入れて返すことになる「ＸＭＬ」文書のタイプを判断することができる。
【００４８】
アプリケーションビューには、整合性のある対話が存在することができる。出力メッセージは、イベントによって生成され、入力メッセージは、サービスによって処理することができる。アプリケーションビューは、動的に実施され、メタデータによって設定することができる。コードの発生は必要ないであろう。この手法は、ビジネスイベント及び変更に対する滑らかな適応を考慮する。コンパイラは必要なく、「Ｊａｖａ」の新バージョンなどとの互換性についても心配する必要はないであろう。
【００４９】
グラフィカル・ユーザ・インタフェース（ＧＵＩ）
統合フレームワークは、各アダプタのための設計時「ＧＵＩ」を提供する開発者のための方法を提供することができる。設計時「ＧＵＩ」は、アプリケーションビューを作成し、アプリケーションビューにサービス及びイベントを追加し、アプリケーションビューをデプロイ、試験、及び編集する方法を提供することができる。アプリケーションビューコンソールを「ＧＵＩ」に含み、企業内の全てのアプリケーションビューへのユーザアクセス、編成、及び編集を助けることができる。アプリケーションビューコンソールは、新しいフォルダを作成し、フォルダに新しいアプリケーションビューを追加するために使用することができる。これらの新しいフォルダは、アプリケーションビューによって使用されているアダプタに関係なく、ユーザが特定のナビゲーションスキームによってアプリケーションビューを編成することを可能にする。
【００５０】
アプリケーションビューは、それが古くなった時やアプリケーションが製造中止になった時は除去することができる。いくつかの実施形態では、特定の条件が真である時だけアプリケーションビューを除去することができる。そのような条件の１つは、ユーザがそのアプリケーションビューをアンデプロイした時である。別の条件は、ユーザが適切な書込みの特典を有するアプリケーションサーバにログオンした時である。フォルダを除去するためには、ユーザは、第１にフォルダのアプリケーションビュー及びサブフォルダを全て除去すべきである。ユーザは、次に「コンソール」内のフォルダにナビゲートしてフォルダを除去又は削除することができる。
【００５１】
アプリケーション統合設定データは、ビジネスプロセス管理（ＢＰＭ）に対するデータと同じリポジトリーに保存することができる。従って、「ＢＰＭ」データを移動させる時にアプリケーション統合を移動させるのに同じツールを使用することができる。しかし、アプリケーション統合データを移動させて、移動されたデータを目標とする環境にデプロイする場合、いくつかの特に考慮すべきことがある可能性がある。インスタンスが変わらない時は、アプリケーション統合データの移動は、アプリケーションサーバのドメイン及び「ＥＩＳ」間で簡単であるとすることができる。しかし、「ＥＩＳ」のインスタンスが変わる場合は、目標とする環境内で機能するソリューションを保障するために特別な手順に従う必要があるであろう。
【００５２】
ある場合においては、関連する「ＥＩＳ」のインスタンスが変わらない場合、アプリケーションサーバのドメイン間でアプリケーション統合データを移動することが望ましいであろう。この種の移動の例は、アプリケーション統合の異なるドメインに対するリポジトリー間でアプリケーションビューの定義を移動する段階を伴う。この場合、アプリケーション統合のドメインだけが変わり、アプリケーションビュー内で参照された対象「ＥＩＳ」のインスタンスは同じままである。ここで、移動データを簡単にするために、インポート／エクスポートユーティリティーを使用することができる。「ＢＰＭ」に対しては、これは、ソースドメイン内の「ＢＰＭ」からパッケージをエクスポートする段階と、目標とするドメインの「ＢＰＭ」内へそのパッケージをインポートする段階とを伴う可能性がある。
【００５３】
ＸＭＬ
「拡張可能マークアップ言語（ＸＭＬ）」は、データを符号化するために使用される自己記述型で拡張可能なテキストベースのフォーマットに対する工業規格である。「ＸＭＬ」は、任意の垂直アプリケーションによる使用に対して拡張することができる汎用データフォーマットを提供する。「ＸＭＬ」は特にウェブ用途に開発されたので、企業間のデータ交換用言語として急速に採用されている。「ＸＭＬ」は汎用であるから、内部及び外部企業統合の両方に対して、ネイティブ言語が異なる２つ又はそれ以上のグループ間の通信用言語として使用することには意味がある。「ＸＭＬ」の使用により、企業は、内部及び外部データの両方に対して企業間統合を容易にするために使用することができる共通フォーマットを有することができる。アプリケーション統合の第１波には、データ及びメタデータに対する共通表現が欠けていた。「ＸＭＬ」はその両方を提供する。
【００５４】
アプリケーションビューは、「ＸＭＬ」文書を受け取って「ＸＭＬ」文書をサービスのために返すことができ、イベントを「ＸＭＬ」文書として公開することができる。この機能は、大抵の「ＥＩＳ」システムが「ＸＭＬ」を理解しないか、又はそれをネイティブデータフォーマットとして使用するとしても、「ＥＩＳ」の複雑さを取り去る上で有用とすることができる。「ＸＭＬ」は、統合のシナリオで使用するのにより簡単なフォーマットである。アプリケーションビュー及びアダプタは、協働して「ＥＩＳ」の「ＸＭＬ」インタフェースを呈することができる。
【００５５】
統合環境においては、全てのメッセージは、実質的に全ての「ＸＭＬ」文書として送ることができる。各サービスに対して、アプリケーションビューは、「ＸＭＬ」要求メッセージを要求し、「ＸＭＬ」応答メッセージを提供することができる。イベントが生成されると、登録されたイベントリスナーは、イベント情報を「ＸＭＬ」として受け取ることができる。アプリケーションビューは、「ＥＩＳ」特有フォーマットを「ＸＭＬ」に又は「ＸＭＬ」から変換するのにそのアダプタに頼ることができる。
【００５６】
アプリケーションビューの使用は、「ＸＭＬ」データを入力として受け取り「ＸＭＬ」データを出力として返すビジネスサービスとして、既存の企業アプリケーションを公開することを可能にすることができる。「ＸＭＬ」を企業データを表現するための共通フォーマットとして使用することは、異なるシステムを同様の方法で処理することを可能にする。ビジネスアナリストの観点からは、「ＳＡＰ」システムとの統合と「Ｓｉｅｂｅｌ」システムとの統合との間の１つの根本的な違いは、「ＸＭＬ」メッセージのコンテントである。統合されているシステムの技術的な詳細をガラス張りにすることができ、ビジネスアナリストが、呼び出されているビジネスサービスに集中してビジネスの問題を解決することを可能にする。
【００５７】
「ＸＭＬ」スキーマ
各アプリケーションビューは、イベント、サービス要求、及びサービス応答に対する「ＸＭＬ」データを記述するためのメタデータとして「ＸＭＬ」スキーマを使用することができる。このメタデータは、ユーザが任意のアプリケーションビューのイベント又はサービスのデータ要件を理解するのを助けることができる。アプリケーションビューは、アプリケーションビューが公開するサービスのデータ要件を記述する「ＸＭＬ」スキーマをクライアントに提供することができる。
【００５８】
「Ｊ２ＥＥ」コネクター方式
アプリケーション統合市場内で広く採用されている基準の欠如は、「Ｊ２ＥＥコネクター」方式及び「Ｊａｖａメッセージングサービス（ＪＭＳ）」のような基準の導入によって対処されている。「ＪＭＳ」は、メッセージ搬送機構に対して標準的なプログラミングインタフェースを提供する。「Ｊ２ＥＥコネクター」方式は、アプリケーションアダプタに対する基準を提供する。「Ｊ２ＥＥコネクター」方式アダプタは、「Ｊ２ＥＥコネクター」方式基準をサポートする任意の統合サーバ内で作動することができる。
【００５９】
「Ｊ２ＥＥコネクター」方式のような基準の採用は、パッケージアプリケーションベンダーが、任意の規格対応サーバ内で機能するアプリケーションアダプタを構成することを可能にする。しかし、この方式は、低レベルの統合問題だけに対処する新しい基準である。例えば、コネクター方式は、単一方向であり、統合サーバから外部アプリケーションへの同期通信が可能である。しかし、コネクター方式は、外部アプリケーションがデータを統合サーバに非同期送信することができる方法を指定しない。それはまた、アプリケーションアダプタに対していかなる共通又は要求インタフェースも提供しないし、アダプタ及びアプリケーション間を通過したデータが符号化される方法も指定しない。
【００６０】
イベント、「ＸＭＬ」の受信、「ＸＭＬ」の返信、及び自己記述型の利用可能なサービス／イベントのような基本サービスは、「Ｊ２ＥＥコネクター」方式内で対処されない。これは、本発明の一実施形態によるアプリケーションビューを使用する利点とすることができる。
「Ｊ２ＥＥコネクター」方式はまた、ビジネスレベルでのアプリケーション統合にうまく対処しない。本発明によるアプリケーションフレームワークは、ビジネスプロセスレベルの統合と、フレームワーク統合サーバ及び外部アプリケーション間の双方向データフローとをサポートすることにより、コネクター方式に価値を付加する。ビジネスレベルのビューは、イベント及びサービスから成るコネクター方式の上で実施することができる。イベントは、アプリケーションアダプタによるなどして、アプリケーションから「ＪＭＳ」を通じてフレームワークサーバに同期的に配信されたメッセージとすることができる。サービスは、アプリケーションのアダプタを通じて任意のビジネスプロセスを呼び出すことができるアプリケーションによって提供された機能とすることができる。
【００６１】
ビジネスプロセス管理（ＢＰＭ）
企業のビジネスプロセス内のアプリケーションビューを使用する１つの方法は、「ＢＰＭ」内でワークフローを設計することである。「ＢＰＭ」は、ビジネスプロセスワークフローを設計するための「ＧＵＩ」ベースの環境を提供することができる。これらのワークフローは、アプリケーション統合を使用して形成されたアプリケーションビューのサービス及びイベントを含むことができる。
「ＢＰＭ」を使用してワークフロー内でアプリケーションビューを使用する少なくとも４つの方法がある。第１のシナリオにおいては、タスクノードが設定されてアプリケーションビューサービスを呼び出す。第２のシナリオにおいては、イベントノードが設定されて非同期アプリケーションビューサービスからの応答を待つ。第３のシナリオにおいては、アプリケーションビューイベントによって開始されるワークフローが作成される。第４のシナリオにおいては、イベントノードが設定されてアプリケーションビューイベントを待つ。「ＢＰＭ」が使用されない場合、企業内のアプリケーションビューを使用する代替方法は、カスタム「Ｊａｖａ」コードを書き込んでビジネスプロセスを実施することである。
実施される各ビジネスプロセスに対して、実施方法を決めることが必要になる。「ＢＰＭ」を使用して任意のビジネスプロセスをワークフローとして実施することができるが、ビジネスプロセスは、それが単純、及び／又は特化されている場合は、カスタム符号化だけされるべきである。
【００６２】
一般に、「ＢＰＭ」は、ある一定の状況でビジネスプロセスを実施するために使用されるべきである。「ＢＰＭ」を使用してビジネスプロセスを実施するのに有効な１つの状況は、実施に複雑なエラーの管理、持続性プロセス、及び高度の条件分岐が要求されると考えられる場合に発生する。例えば、ビジネスプロセスがイベントを受け取り、イベントの部分集合だけを選択し、複雑な分岐アクションを実行し、次に多くの複雑なメッセージを生成してメッセージを様々なアプリケーションサーバクライアントに送る場合、ビジネスプロセスの実施に「ＢＰＭ」を使用するのが有利であるとすることができる。
「ＢＰＭ」はまた、ビジネスプロセスに時々の変更のみが必要な時に使用することができる。「ＢＰＭ」は、編集／試験／デバッグサイクルの回数を少なくすることができる。「ＢＰＭ」はまた、大抵の組織でそうであるが、開発者が貴重で不足している時に使用することができる。
【００６３】
ユーザがアプリケーションビューサービスを呼び出すか、又は「ＢＰＭ」にアプリケーションビューイベントを受け取る前に、ある一定の前提条件を満足させることができる。第１に、ユーザは、既にアプリケーションビューを作成し、アプリケーションビューに対するサービス及びイベントを形成していることができる。また、アプリケーションビュー及びそのアダプタは、機能的で保存されているとすることができる。ユーザがアプリケーションビューのサービス及びイベントを実行中のワークフローから呼び出すつもりである場合、そのアプリケーションビューは、同じくデプロイされるべきである。「ＢＰＭ」及びアプリケーション統合は、両方とも実行されているべきであり、アプリケーション統合プラグインが読み込まれるべきである。ユーザは、形成されているワークフローに関するいかなる要求されたビジネス論理に関する情報も有するべきである。この情報は、例えばビジネスアナリストから提供することができる。また、ワークフローのテンプレートの定義を開くことができる。
【００６４】
企業に必要なアプリケーションビューサービス及びイベントを作成した後で、ユーザは、ビジネスプロセスを実行するためにそれらのアプリケーションビューを使用することができる。「ＢＰＭ」は、アプリケーションビューサービス及びイベントを使用するビジネスプロセスワークフローを設計するために使用することができる。「ＢＰＭ」は、ビジネスプロセスワークフローを設計するために「ＧＵＩ」ベースの環境を提供することができる。これらのワークフローは、アプリケーション統合を使用して形成されたアプリケーションビューサービス及びイベントを含むことができる。
【００６５】
「ＢＰＭ」内でアプリケーションビューサービス及びイベントを使用するために、少なくとも４つの主要な方法がある。１つの方法は、タスクノードを設定してアプリケーションビューサービスを呼び出すことである。別の方法は、イベントノードを設定して非同期アプリケーションビューサービスからの応答を待つことである。別の方法は、アプリケーションビューイベントによって開始されたワークフローを作成する段階を伴う。最後に、イベントモードを設定してアプリケーションビューイベントを待つことができる。これらのシナリオを互いに組み合わせて使用し、個人向けワークフローを作成することができる。
【００６６】
イベントルータ
アプリケーションプログラミングインタフェース（ＡＰＩ）を使用して、「ＸＭＬ」文書に基本的データを設定するなど、「ＸＭＬ」文書と対話することができる。「ＥＩＳ」システムに新しい顧客がいる場合、顧客の名前やアドレスのようなその顧客に関連する情報があるとすることができる。イベントの作成者は、イベントをイベントルータに記入する「ポスト」イベントを行うことができる。イベントルータは、イベントをイベント作成者からアプリケーション統合サーバまで転送することができるので、アプリケーション統合サーバは、そのイベントに対して登録したリスナーに通知することができる。イベントルータは、アプリケーション統合サーバと通信する方法を知ることができる。
【００６７】
イベントルータは、メインサーバ又はアプリケーションサーバ以外の別のサーバ上にデプロイすることができる。「ＳＡＰ」システムに密接に連結されるものは、メインサーバ上ではなく「ＳＡＰ」システムの近くに保つことができるので、これは、一般的なシナリオであろう。
イベントルータは、「イベントメッセージ」の「公開」呼び出しにより、アプリケーション統合サーバに対してイベントメッセージを公開することができる。これは、次に、アプリケーションビューのトピックに対して公開することができる。トピックがイベントを受信した状態で、それは、登録されたイベントリスナーにクライアントを通知することができる。これは、少なくとも部分的には、全て「ＪＭＳ／ＸＭＬ」規格に基づくことが可能である。
【００６８】
アプリケーションビューのライフサイクル
図５は、本発明の一実施形態によるアプリケーションビューのライフサイクルを示す図である。最初に、アプリケーションビューを作成する必要がある（５００）。ユーザは、親ネームスペース内にアプリケーションビューを作成し、新しいアプリケーションビューに名前を与えることができる。アプリケーションビューが存在する状態で、それは、作成されてリポジトリーに保存される必要がある編集を有することができる（５０２）。メモリ内オブジェクトの状態は、まだリポジトリー内のオブジェクトの持続性状態と適合できないであろう。ここから、ユーザは、アプリケーションビューを保存することができ（５０４）、及び／又は、アプリケーションビューをデプロイすることができ（５０６）、これは、自動的に保存することができる。代替的に、ユーザは、アプリケーションビューの削除を要求することができ（５０８）、その要求を確認することができる。ユーザは、既存のアプリケーションビューを、例えばネームスペースブラウザから１つ選択してアプリケーションビューが編集されることを表示することによって編集することができる。ユーザがアプリケーションビューの編集を要求すると移行が発生する可能性があり、その場合、ユーザが促されて確認した後に、アプリケーションビューはアンデプロイされる。
【００６９】
アプリケーションビューは、実行時クライアントの使用に対して利用可能にすることができる。アプリケーションビューは、アプリケーションビューに対する要求にサービスを提供することができるアプリケーションビュー用に割り当てられたリソースを備えたコンテナーを有することができる。実行時クライアントは、アプリケーションビューのコンテナーからこのアプリケーションビューのインスタンスを取得し、そのサービスを呼び出してそのイベントを聴取することができる。アプリケーションビューのライフサイクル内の他の段階は、アプリケーションビューを形成する段階と、アプリケーションビューを使用する段階とを含む。アプリケーションビューを形成する時、サービス及び／又はイベントが追加される前に通信パラメータを設定することができる。アプリケーションビューのサービス及びイベントは、アプリケーションの特定の機能性を公開することができる。アプリケーションビューの通信パラメータは、アプリケーションビューが目標「ＥＩＳ」と接続される方法を支配することができる。
【００７０】
アプリケーションビューの形成は、アプリケーションビューに対する固有の名前の入力、及びアプリケーションビューとアプリケーション自体との間でネットワーク接続を確立するパラメータの設定のようなタスクを含むことができる。他のタスクは、アプリケーションビューとアプリケーションとの間でネットワーク接続を確立するパラメータの設定、及び、アプリケーションに固有のパラメータ、アプリケーションビューによって負荷平準化のために使用されるパラメータ、及びアプリケーションビューに利用可能な接続プールを管理するために使用されるパラメータの設定を含むことができる。別のタスクは、アプリケーションビューのユーザのためのセキュリティ特典を形成する段階を伴うことができる。
【００７１】
アプリケーションビューを形成した後で、それは、アプリケーションサーバ上にデプロイすることができる。デプロイされたアプリケーションビューは、ビジネスプロセスワークフロー内で企業のビジネスプロセスを実施するために使用することができる。ビジネスプロセスワークフロー内でアプリケーションビューを使用した後、その最終結果は、その企業のビジネスプロセスのデプロイされた電子表示である。ワークフローは、ビジネスプロセスを達成するためにアプリケーションが互いに対話する方法を指定することができる。アプリケーションビューは、トランザクション自体を実行することができる。
【００７２】
アダプタに対してアプリケーションビューを形成すると、アプリケーションビューのホストとなるアプリケーションサーバと特定「ＥＩＳ」アプリケーションとの間に「ＸＭＬ」ベースのインタフェースを作成することができる。アプリケーションビューの形成は、アプリケーションビューのネーミング段階と接続パラメータの設定段階とを含む少なくとも少数の基本的段階を伴うことができる。他の段階は、アプリケーションビューにサービス及びイベントを追加する段階と、サービス及びイベントを試験する段階とを含むことができる。
【００７３】
アプリケーションビューの編集
既存のアプリケーションビューは、定義エラー、不完全な定義、ビジネス目的の変更、又は根底のアプリケーション接続性の変化に対処するために修正することができる。得られるアプリケーションビューは、ビジネスデータ要件を満足することができ、アプリケーションと適切に対話することができる。アプリケーションビューを編集するために、第１に、アプリケーションビューを特定し、それが存在することを確認する必要がある。技術アナリストは、本題に関する専門家の助けを得て、アプリケーションの専門技術を提供することにより、及び、恐らくはアプリケーションビューの必要性に適合するようにアプリケーション又はそのメタデータを修正することにより、アプリケーションビューを形成するのを補助することができる。いくつかの実施形態においては、技術アナリストによって選択されたアプリケーションのためのアダプタがインストールされており、適切な「ＪＳＰ」ベースの設計時「ＧＵＩ」がインストールされていることが必要である。アダプタのホストとなるサーバ及び設計時インタフェースもまた作動していなければならない。
【００７４】
基本的フロー及び代替フローは、ビジネスアナリスト、技術アナリスト、及び本題に関する専門家が全てアプリケーションビューの作成／形成中に対話していると仮定することができる。これは事実でない場合が多い。各ユーザがアプリケーションビューの現在状態を調査する順番になった場合、イベントのフローは、イベントのフローを通る複数のパスの形式を取ることができ、各パスは、単一ユーザの対話だけを表示する。
【００７５】
アプリケーションビューに対するサービス及びイベントを編集するために、技術アナリストは、アプリケーションのメタデータのツリーを走査し、イベント又はサービスを表示するために適切なメタデータを特定することができる。次に、技術アナリストは、アダプタとその設計時インタフェース機能とに特定のイベント又はサービスを作成することができる。イベント又はサービスの定義は、作成されてアプリケーションビューに追加することができる。定義が包含するものは、アダプタに特有とすることができるが、定義は、イベントアダプタが実行時に要求された種類のイベントを適正に作成するのに十分な情報を包含することができる。
【００７６】
システム例
図６の簡単な例は、上述のいくつかの特徴の相互関係を示す。この図は、本来「Ｓｉｅｂｅｌ」システム又はインスタンス６００で本来作成された顧客を「ＳＡＰ」インスタンス６１６に追加する段階を含むと考えられる起こり得る例示的状況を示す。この例においては、新しい顧客６０２が、「Ｓｉｅｂｅｌ」６００で作成される。「ＳｉｅｂｅｌＣｏｄｅ」を通して「Ｓｉｅｂｅｌ」特有イベントアダプタ６０４に通知され、顧客情報が通される。イベントアダプタは、顧客情報を含む「ＸＭＬ」ベースのオブジェクトを作成し、イベントを「Ｓｉｅｂｅｌ」アプリケーションビュー６０８に通知する。「Ｓｉｅｂｅｌ」アプリケーションビュー６０８は、次に、イベントをビジネスプロセス６１２に通す。ビジネスプロセス６１２は、顧客情報を「ＳＡＰ」システム６１６に複製する必要があると判断することができる。ビジネスプロセス６１２は、顧客の「Ｓｉｅｂｅｌ」の「ＸＭＬ」表示を「ＳＡＰ」の「ＸＭＬ」表示に変換する。ビジネスプロセスは、次に、「Ｓｉｅｂｅｌ」アプリケーションビュー６０８と同じ統合フレームワーク６０６の一部とすることができる「ＳＡＰ」アプリケーションビュー６１０によって提供されるサービスを呼び出す。「ＳＡＰ」アプリケーションビュー６１０は、次に、「ＳＡＰ」サービスアダプタ６１４を呼び出し、今や「ＳＡＰ」アダプタ６１４が理解することができるフォーマットの「ＸＭＬ」メッセージを通す。「ＳＡＰ」アダプタ６１４は、「ＸＭＬ」メッセージを特定の「ＢＡＰＩ」（ビジネスアプリケーションプログラミングインタフェース）に変換することができ、「ＳＡＰ」インタフェース６１６を呼び出すことができる。「ＳＡＰ」６１６は、要求を処理し、顧客６１８を挿入し、「ＳＡＰ」６１６によって割り当てられた顧客番号を返すことができる。
【００７７】
アプリケーションビューオブジェクトは、そのビジネス目的を反映する名前と共に、ビジネスの組織的構造内の場所を記述するそのネームスペース内で作成することができる。得られるアプリケーションビューは、ビジネスデータ要件を満足させることができ、アプリケーションと共に適切な対話を実施することができる。アプリケーションビューのユーザは、ビジネスアナリスト、技術アナリスト、及び本題に関する専門家を含む。ビジネスアナリストは、何がアプリケーションビューの目的になるかを決めることができる。技術アナリストは、どのアプリケーションがアプリケーションビューの目的に最も適するかを決めることができる。技術アナリストは、本題（本アプリケーション）に関する専門家の助けを得て、アプリケーション専門技術を提供することにより、及び、恐らくはアプリケーションビューの必要性に適合するようにアプリケーション又はそのメタデータを修正することにより、アプリケーションビューの形成を支援することができる。技術アナリストによって選択されたアプリケーションのためのアダプタは、既にインストールされているべきであり、適切な「ＪＳＰ」ベースの設計時「ＧＵＩ」も同様である。アダプタのホストとなるサーバ及び設計時インタフェースもまた、新しいアプリケーションビューを作成する前に作動しているべきである。
【００７８】
基本的フローにおいては、技術アナリストは、ウェブブラウザを開き、アダプタの設計時インタフェースの「ＵＲＬ」を指す。技術アナリスト及びビジネスアナリストは、どのビジネス組織にアプリケーションビューが属するかを決め、適切なアプリケーションビューのネームスペースが存在することを確認する。これは、アダプタ設計時インタフェースのホームページ上のネームスペースのブラウザツリーを使用して行うことができる。適切なネームスペースが存在しない場合、それは、ネームスペースブラウザを使用して作成することができる。
【００７９】
技術アナリスト及びビジネスアナリストは、アプリケーションビューに対する名前に合意する。この名前は、アプリケーションビューのビジネスの目的を反映することができる。技術アナリストは、特定されたネームスペース内に新しいアプリケーションビューを作成し、それに合意に基づく名前を付けることができる。ビジネスアナリストは、アプリケーションビューのビジネスの目的を簡単に記述し、技術アナリストは、新しいアプリケーションビューの記述フィールドにそれを入力する。アプリケーションビューのイベント及びサービスの組は、必要があれば見直されて編集される。技術アナリストは、次に、新しいアプリケーションビューを保存することができる。この時点で、アプリケーションビューは、後で使用するために保存し、試験し、又は、実行時アプリケーションビューエンジン内にデプロイすることができる。
【００８０】
アダプタ
上述の通り、アダプタは、サービス又はイベントアダプタとして開発することができる。サービスアダプタは、それが接続されている企業システム内の特定機能を呼び出すことができる。イベントアダプタは、企業システムからの情報を統合環境に伝達することができる。各アプリケーションビューに対して、ビジネスは、アプリケーションビューの定義に任意数のサービス及びイベントを追加し、アプリケーションサーバと目標企業システムとの間の特定の種類のトランザクションをサポートすることができる。アダプタは、「ＸＭＬ」を使用してアプリケーションのデータフォーマットを変換することができるので、ビジネスアナリストは、フォーマットを理解する必要がない。ビジネスアナリストがアダプタの使用を欲する場合は、アプリケーションビューを形成して使用する方法を知る必要があるだけである。最も良いことは、アプリケーションビューを形成するのに全てのアダプタが同じウェブベースのインタフェースを使用することができるので、現在及び将来のアダプタの使用方法を覚えるのが容易である可能性があることである。「ＸＭＬ」は、開発者とビジネスアナリストの両者のためにアプリケーション統合を平滑にすることができる。
【００８１】
「Ｊ２ＥＥ」仕様は、今のところ、アプリケーションサーバ又はクライアントとの通信を開始するための「ＥＩＳ」に対するガイドラインを提供しない。アプリケーション統合は、イベントアダプタのユーザを通じてこの機能を提供することができる。アプリケーションビューの別の重要な特徴は、双方向通信をサポートする機能である。「Ｊ２ＥＥ」仕様は、今のところ、アプリケーションサーバ又はクライアントとの通信を開始するための「ＥＩＳ」に対するガイドラインを提供しない。この機能は、イベントアダプタによって提供することができる。アプリケーションビューに追加される時、各イベントは、特定の企業アプリケーション状態に応答する。特定イベントがトリガされると、アプリケーションビューは、イベントに関するデータを企業システムから抽出し、そのデータを統合環境に「ＸＭＬ」文書で伝達することができる。
同様に、アプリケーションビューに追加される時、各サービスは、企業システム内の特定機能を表すことができる。アプリケーションビューは、特定サーバにマップする「ＸＭＬ」文書を受け取ると、サービスアダプタを使用して企業システム内の対応する機能を呼び出す。いくつかの実施形態においては、企業システムは、サービスに応答を送信することができる。
【００８２】
ビジネス手法
ビジネスアナリスト又は技術アナリストがアダプタを使用してアプリケーションビューを形成する場合、アプリケーションビューは、特定のビジネス目的に対してカスタム化することができる。ビジネス目的は、ビジネスアナリストによって定義することができる。例えば、「顧客関係管理（ＣＲＭ）」システムに対するアダプタ上で「顧客管理」アプリケーションビューを形成する場合、顧客管理に関連するサービス及びイベントだけを追加することができる。アプリケーションビューは、必要なだけ包括的に作成することができる。アプリケーションビューは、特定のビジネス目的にカスタム化することができるので、アプリケーションビューは、他の多くの企業アプリケーション統合システムで使用される「１つのサイズが全てに適合する」手法よりも遥かに良く機能することができる。
アプリケーションの機能のビジネスレベルのビューは、プログラマー及び技術アナリスト間の論理的分離を提供することができる。例えば、この抽象化は、技術アナリストが「ＳＱＬ」を知る必要なくデータベースに記録を作成することを可能にすることができる。
【００８３】
アプリケーションビューのデプロイ
アプリケーションビューは、それに少なくとも１つのイベント又はサービスが追加された時にデプロイすることができる。アプリケーションビューは、そのサービス及びイベントを試験することができる前、及び、同じくアプリケーションビューがアプリケーションサーバ環境で使用される前にデプロイされる必要がある場合がある。アプリケーションビューデプロイは、そのサービス及びイベントに関する関連メタデータを実行時メタデータリポジトリーにデプロイすることができる。デプロイは、アプリケーションビューを他のアプリケーションサーバクライアントに利用可能にする。ビジネスプロセスは、次に、アプリケーションビューと対話することができる。
【００８４】
アプリケーションビューをデプロイするために、ユーザは、アプリケーションビューコンソールを開いて、アプリケーションビュー管理ページから「デプロイ」オプションを選択することができる。「ＢＰＭ」又は他の認定クライアントがこのアプリケーションビューの任意の既存のサービスを非同期に呼び出すことを可能にするために、ユーザは、非同期サービス呼び出しを使用可能にすることができる。アプリケーションビューサービスを非同期に呼び出すエンティティは、サービスからの応答を待たないでそのプロセスを継続することができる。このアプリケーションビューがイベントを有する場合、ユーザは、アダプタのイベントルータの「ＵＲＬ」を入力することができる。ユーザはまた、このアプリケーションビューによって使用される接続プールの最小数、例えば「１」を入力することができる。同様に、ユーザは、接続プールの最大数を入力することができる。「最大プールサイズの目標比率」又は同様のフィールドには、ユーザは、例えば０から１まで測ることができるような理想的プールサイズを入力することができる。例えば、値「０．７」を入力することができるであろう。最大プールサイズが１０で目標比率が０．７の場合、アダプタが、接続プールサイズをこの場合７つの接続を意味する最大値の７０％に維持するように試みるために負荷平準化を実行することになることを意味する。未使用の接続を自動的に削除するために、ユーザは、プールを縮小させることになるオプションを選択することができる。
【００８５】
「コンソール」の「ログ設定」エリアにおいて、ユーザは、エラー及び監査メッセージの記録、警告、エラー、及び監査メッセージの記録、通知、警告、エラー、及び監査メッセージの記録、及び全てのメッセージの記録のようなロギング設定に従ってオプションを選択することができる。必要に応じて、ユーザは、「Ｊ２ＥＥ」又は他の適切なセキュリティを使用してアクセスを制限することができる。アプリケーションビューに対するユーザ又はグループの読取り及び書込みアクセスを許可又は取り消すために使用することができるアプリケーションビューの「セキュリティ」ページを「コンソール」に含めることができる。許可の設定が終わると、ユーザは、変更を加えるように選択することができる。ユーザはまた、任意の変更の後でアプリケーションビューをデプロイするように選択することができる。
【００８６】
アプリケーションビューは、例えば、ユーザがその接続パラメータを編集したい時、サービス及びイベントを追加したい時、又は、アプリケーションビューの使用に関してクライアントを使用不可にしたい時にアンデプロイすることができる。ユーザは、アプリケーションビューの「要約」ページを表示するように選択することができる。アプリケーションサーバからアプリケーションビューをアンデプロイするために、ユーザは、「アンデプロイ」オプションを選択することができる。
【００８７】
アプリケーションビューを形成する時に、ユーザは、その接続パラメータを設定することができる。サービス及びイベントを追加して試験した後に、ユーザは、接続パラメータを再設定するか、又は、サービス及びイベントを除去するように望む場合がある。既存のアプリケーションビューを編集するために、ユーザは、アプリケーションビューを開いて「要約」オプションをクリックするか、又は単にアプリケーションビューの「管理」ページを表示することができる。ここから、ユーザは、アプリケーションビューの接続パラメータを再設定するか、又はサービス及びイベントを追加することができる。
【００８８】
同期的手法
アプリケーションビューを同期的に呼び出すために、ユーザは、適切なアプリケーションビューコンソールから「同期」オプションを選択することができる。サービスを同期的に呼び出すノードは、サービスがワークフローを継続することができる前に応答文書を返すのを待機するように設定することができる。仮にノードが非同期的にサービスを呼び出すのであれば、ワークフローは継続することができるであろう。応答の保存が必要な同期サービスに対しては、ユーザは、「応答文書変数リスト」などから所定の「ＸＭＬ」変数を選択することができる。「ＢＰＭ」がアプリケーションビューサービスから応答を受け取ると、応答文書変数は、応答を保存することができる。ユーザが応答データに関心がない場合は、ユーザは、このフィールドを空白のままに残すことができる。
適切な「ＸＭＬ」変数が無い場合、ユーザは、新しい「ＸＭＬ」変数を作成するオプションを選択することができる。応答文書の「ＸＭＬ」スキーマを調査する必要がある場合、ユーザは、応答の定義を閲覧することができる。
【００８９】
非同期的手法
例えば、要求ＩＤの保存が必要な場合があるような非同期サービスに対しては、所定のストリング変数をアプリケーションビュー「コンソール」から選択することができる。適切なストリング変数がない場合、「変数特性」ダイアログボックスを開くことができ、そこで新しいストリング変数を作成することができる。非同期アプリケーションビューサービスを呼び出すためにタスクノードが設定される時、その結果は「ＢＰＭ」に返すことができる。ワークフローは、選択された要求ＩＤ変数を使用してこの応答を特定することができる。イベントノードを応答を受け取るように設定するためには、そのイベントノードに対して同じ要求ＩＤ変数を使用すべきである。
【００９０】
ユーザは、非同期アプリケーションビューサービスからの応答を待機するようにイベントノードを設定することを希望する場合がある。ワークフローにおいては、アクションがアプリケーションビューサービスを非同期的に呼び出す度に、アプリケーションビューサービスは応答を返すことになる。一般に、ユーザが応答について知りたい時、ユーザは、応答を待機するための対応する非同期イベントノードの設定を欲するであろう。非同期アプリケーションビューサービスからの応答を待機する非同期イベントノードを設定するために、「非同期応答」タイプのイベントのようなイベントを待機するように設定されるイベントノードを作成することができる。
【００９１】
この実施形態の非同期サービス応答を受け取るようにイベントノードを設定するのに使用することができる少なくとも２つの基本的な方法がある。第１の方法においては、ユーザは、「応答文書」オプションを選択することができる。本方法を使用すると、ユーザは、要求ＩＤ変数及び応答文書変数を選択することにより、非同期サービス応答を受け取ることができる。要求ＩＤ変数は、ストリングであり、応答文書変数は、「ＸＭＬ」タイプである。第２の方法は、「非同期変数」オプションを使用する。本方法を使用すると、非同期サービス応答は、要求ＩＤ変数及び非同期サービス応答変数を選択することによって受け取ることができる。要求ＩＤ変数は、ストリングであり、非同期サービス応答変数は、「ＡｓｙｎｃＳｅｒｖｉｃｅＲｅｓｐｏｎｓｅ」のようなタイプとすることができる。好ましい方法は、非同期及び同期応答の両方を受け取る一般的な手段を提供することができるので、応答文書法であろう。応答文書法を使用すると、応答が非同期又は同期に関係なく「ＸＭＬ」文書を受け取ることができ、非同期サービス応答変数の値を問い合わせる必要もないことになる。
【００９２】
応答文書変数を使用して、可能な時にいつでも非同期サービス応答を受け取ることができる。「イベント特性」ダイアログボックスが非同期応答タイプのイベントを待機するように設定される度に、ユーザは、非同期変数を使用して応答を受け取るように選択することができる。非同期サービス応答変数を使用して応答を受け取るように予め設定された非同期応答イベントノードが編集される場合、イベント特性ダイアログボックスに２つのオプション、すなわち、非同期変数オプションと応答文書オプションを表示することができる。この場合、ユーザは、サービス応答を受け取るために２つの方法から１つを選択することができる。
【００９３】
非同期サービス応答変数を使用しない既存の非同期応答イベントノードが編集されるか、又は新しい非同期イベントノードが作成される場合、イベント特性ダイアログボックスは、ユーザが応答文書をサービス応答を受け取るように設定することを可能にすることになるダイアログボックスを表示することができる。
このシナリオは、アプリケーションビューのサービス応答で返されるエラーを処理しないが、ユーザは、特定ユーザのワークフロー内でエラーを処理することを欲する場合がある。例えば「ＡｓｙｎｃＳｅｒｖｉｃｅＲｅｓｐｏｎｓｅ」変数を使用することができるこれらのワークフロー内で非同期サービス応答エラーを処理するために、ユーザは、アプリケーション統合プラグインに含まれた機能を使用することができる。本発明の一実施形態によるアプリケーション統合プラグインは、「ＡｓｙｎｃＳｅｒｖｉｃｅＲｅｓｐｏｎｓｅ」のような変数タイプと、「ＡｌＨａｓＥｒｒｏｒ（）」、「ＡｌＧｅｔＥｒｒｏｒＭｓｇ（）」、及び「ＡｌＧｅｔＲｅｓｐｏｎｓｅＤｏｃｕｍｅｎｔ（）」のような関数とを含むことができる。
【００９４】
非同期アプリケーションビューサービスからの応答を待機するように非同期イベントノードを設定するために、イベントノードを作成して、「Ａｌ  Ａｓｙｎｃ  Ｒｅｓｐｏｎｓｅ」のようなタイプのイベントを待機するように設定することができる。「ＸＭＬ」変数を使用して非同期サービス応答を受け取るようにイベントノードを設定する段階は、第１に、ワークフローテンプレート定義を開く段階を含むことができる。ユーザは、イベントノードがまだ無い場合は、それを作成することができ、それは、指定されたアプリケーションビューサービスからの非同期応答を待機することになる。ユーザは、既に形成されたストリング変数を選択することができ、「ＢＰＭ」は、この変数に符合するＩＤを有する非同期応答に聞き入ることになる。
イベントノードは、先にワークフロー内で非同期的に呼び出されたアプリケーションビューサービスに対する呼び出しのようなアクションに対する応答を待つことができる。「呼び出しアプリケーションビューサービス」アクションは、要求ＩＤ変数を設定することができる。アクションとこのイベントノードとを協働させるために、それらは、両方とも同じ要求ＩＤ変数を使用することができる。
【００９５】
応答の保存を必要とする非同期サービスに対して、ユーザは、応答文書変数リストなどから所定の「ＸＭＬ」変数を選択することができる。「ＢＰＭ」がアプリケーションビューサービスから応答を受け取ると、応答文書変数を使用して応答を保存することができる。適切な「ＸＭＬ」変数が存在しない場合、ユーザは、新しい変数を作成することができる。非同期サービス応答を受け取る好ましい方法は、「ＸＭＬ」タイプの応答文書変数を使用することであろう。しかし、既存のワークフローが、非同期アプリケーションビューサービスからの応答を待機するために「ＡｓｙｎｃＳｅｒｖｉｃｅＲｅｓｐｏｎｓｅ」を使用するように予め設定された非同期イベントノードを含む場合は、ユーザは、イベントノードを修正することができる。
イベントモードが非同期サービス応答を受け取るために「ＡｓｙｎｃＳｅｒｖｉｃｅＲｅｓｐｏｎｓｅ」変数を使用する場合、イベントモードを修正する１つの手法は以下の段階を使用する。ワークフローテンプレート定義が開かれ、非同期変数のタイプが選択される。ユーザは、既に定義されたストリング変数を選択し、「ＢＰＭ」は、この変数と符合するＩＤを有する非同期応答に聞き入る。
【００９６】
コールバックリスナー
クライアントは、サービスが長期間実行されるサービスの場合は、それを非同期的に呼び出すように選択することができる。例えば、いくつかの「ＳＡＰ」要求は、処理するのに約２又は３分掛かる可能性がある。要求の処理は、通常はクライアントにはガラス張りで起きる。ユーザがウェブページに留まっている場合、２分間何もしないで単に「停止する」のはそのページにとって望ましくない。何らかの種類の応答を出し、次に、「ＳＡＰ」からの新しいメッセージのような適正な応答を受け取った状態で、ウェブページを更新するのが好ましいであろう。これが、非同期応答に対してコールバックリスナーを使用する１つの理由である。このようにして、クライアントは、応答を待たなければならないことを欲しないが、その代わりに、応答がコールバックリスナーによって受け取られた時に通知されることになる。
【００９７】
聴取及び受け取りイベントは、「Ｊ２ＥＥコネクター」方式において対応されないので、聴取及び受け取りイベントは、本発明によるいくつかの実施形態の別の貴重な部分である。「ＥＩＳ」においてトリガが起こる可能性があり、外部アプリケーションは、トリガの開始について知る必要がある場合がある。換言すれば、いくつかのアプリケーションに伝達される必要があるイベントが起きる。全ての登録リスナーも同様に通知される必要があるであろう。
【００９８】
上述の場合と同様に、クライアントは、アプリケーションビューを作成することができ、イベントリスナーを追加することができる。アプリケーションビューからイベントを受け取った状態で何をするかを知っているハンドラが作成される。一実施形態におけるアプリケーションビューは、「ＪＭＳ」トピックに加入し、リスナーをそのトピック上に登録する。「ＪＭＳ」トピックは、受信箱と同じように「ＪＭＳ」メッセージを送ることができる「ＪＭＳ」機能である。
【００９９】
「イベント生成プログラム」と呼ばれるオブジェクト又はアプリケーション統合コンポーネントを形成することができる。イベント生成プログラムの１つの仕事は、イベントがいつ起きるかを判断するために「ＥＩＳ」を監視してそれと通信することである。「ＤＢＭＳ」アダプタに対しては、これは、ステージング表に関する問い合わせを伴う可能性がある。ユーザは、「ｓｅｌｅｃｔ  *  ｆｒｏｍ  ｅｖｅｎｔ」のように要求することができる。そのイベント表のいかなる記録も「ＤＢＭＳ」内の新しいイベントの記録になる。イベント生成プログラムは、新しいイベントに関して定期的に「ＥＩＳ」に注意を向けている。
【０１００】
例えば、注文処理システムが在庫のある品目に関して品不足になっている場合、イベントは、結果的に、システムに特定の製品を補充する必要があるという通知をトリガさせることができる。このイベントは、例えば「ＥＩＳ」で発生する可能性がある。トリガは、「ＤＢＭＳ」に対して使用することができる。ある表で挿入が発生した状態で、トリガを開始して「Ｉｎｓｅｒｔ  ｉｎｔｏ  ｅｖｅｎｔ  ．．．」ステートメントを使用するなどして新しいデータに関する情報をイベント表内にデプロイすることができる。次に、新しいイベントが発生した状態で、イベント生成プログラムは、そのイベントを引き抜くことができる。
【０１０１】
セキュリティ
ユーザは、ユーザ又はグループの名前を適切な形式で指定することにより、ユーザのアクセスの特典を認可又は取り消すことができる。各アプリケーションビューは、読取りアクセス及び書込みアクセスのような少なくとも２種類のアクセスを有することができる。読取りアクセスにより、ユーザは、サービスを実行してイベントを購読することができる。書込みアクセスにより、ユーザは、アプリケーションビューをデプロイ／編集／アンデプロイすることができる。
【０１０２】
必要に応じて、アプリケーションビュー上にサービスが呼び出される前にセキュリティレベルを設定することを可能にする方法をアプリケーションビュー上に呼び出すことができる。「ｓｅｔＣｏｎｎｅｃｔｉｏｎＳｐｅｃ（）」及び「ｇｅｔＣｏｎｎｅｃｔｉｏｎＳｐｅｃ（）」のような方法を使用して、「ＥＩＳ」に対するクリデンシャルを「ＣｏｎｎｅｃｔｉｏｎＳｐｅｃ」オブジェクトを使用して設定することができる。「ＣｏｎｎｅｃｔｉｏｎＳｐｅｃ」オブジェクトをインスタンス化するために、「ＡＤＫ」などに「ＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔＩｎｆｏＭａｐ」のようなクラスを設けることができる。ユーザはまた、そのユーザによって作成されたクラスを実施することができる。ユーザが独特のクラスを作成する場合、ユーザは、「ＣｏｎｎｅｃｔｉｏｎＳｐｅｃ」インタフェース（「ＪＣＡ」クラス）、「ＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔＩｎｆｏ」インタフェース（「ＪＣＡ」クラス）、「Ｍａｐ」インタフェース（「ＳＤＫ」クラス）、及び「Ｓｅｒｉａｌｉｚａｂｌｅ」インタフェース（「ＳＤＫ」クラス）のような、ある一定のインタフェースを含む必要があるであろう。
【０１０３】
「ＣｏｎｎｅｃｔｉｏｎＳｐｅｃ」クラスを実施して「ＣｏｎｎｅｃｔｉｏｎＳｐｅｃ」オブジェクトをインスタンス化した後で、ユーザは、「ｓｅｔＣｏｎｎｅｃｔｉｏｎＳｐｅｃ（）」及び「ｇｅｔＣｏｎｎｅｃｔｉｏｎＳｐｅｃ（）」方法と共に「ＣｏｎｎｅｃｔｉｏｎＳｐｅｃ」を使用することができる。「ＣｏｎｎｅｃｔｉｏｎＳｐｅｃ」を設定するために、ユーザは、適正に初期化された「ＣｏｎｎｅｃｔｉｏｎＳｐｅｃ」オブジェクトを通すことができる。「ＣｏｎｎｅｃｔｉｏｎＳｐｅｃ」をクリアするために、ユーザは、ヌル値を有する「ＣｏｎｎｅｃｔｉｏｎＳｐｅｃ」オブジェクトを通すことができる。
【０１０４】
データ移動
１つの「ＥＩＳ」インスタンスに対して形成されたアプリケーションビューは、識別子とその「ＥＩＳ」インスタンスに固有のデータとを含むので、アプリケーションサーバのドメイン間及び「ＥＩＳ」の異なるインスタンス間でデータを移動する時には特別の注意を払うことが必要な場合がある。これはまた、アプリケーションビューによって使用されるコネクションファクトリーでも真とすることができる。ユーザは、アプリケーションビュー又はコネクションファクトリー内の「ＥＩＳ」インスタンス特有データをマニュアルで変更することができない場合がある。しかし、これらの変更は、目標とするアプリケーションビューにナビゲートしてそのアプリケーションビューを編集することにより、アプリケーションビューコンソールから行うことができる。ユーザは、アプリケーションビュー内の全ての「ＥＩＳ」特有データ、及び、任意のイベント、サービス、及び関連するコネクションファクトリーを識別して更新することができる。
【０１０５】
任意の「ＥＩＳ」インスタンス特有レファレンスは、目標環境内の新しい「ＥＩＳ」インスタンスに対するリファレンスと置換することができる。特に、ユーザは、アプリケーションビュー及びコネクションファクトリー定義を編集することができる。アプリケーションビュー定義は、例えば、アプリケーションビューの「デプロイ」スクリーンを通してアクセスできるように、「ＥｖｅｎｔＲｏｕｔｅｒＵＲＬ」又は同様のパラメータの変更が必要な場合がある。このパラメータは、目標環境内のイベントルータを参照するために使用することができる。サービス定義のパラメータも変更する必要がある場合がある。これらは、「ＥＩＳ」インスタンス特有データを参照するアダプタ特有データとすることができる。編集機能を使用して、サービスのための任意の「ＥＩＳ」インスタンス特有パラメータを変更することができる。「ＥＩＳ」インスタンス特有データを参照するアダプタ特有データを含むイベント定義パラメータも変更する必要がある場合がある。各アダプタは、サービス及びイベント内に異なる特性をデプロイすることができる。
【０１０６】
イベント及びサービスアダプタに加えて、「ＡＤＫ」設計時フレームワークは、アダプタのユーザが自分のアプリケーションビューを形成、デプロイ、及び試験する必要があるウェブベース「ＧＵＩ」を構築するのに必要なツールを提供することができる。各アダプタが「ＥＩＳ」特有の機能性を有することができるが、全てのアダプタは、アプリケーションビューをデプロイするために「ＧＵＩ」を必要とする。このフレームワークは、これらのインタフェースを作成してデプロイするために必要な労力を最小にすることができる。この最小化は、２つの主要なコンポーネントを使用することにより少なくとも部分的に達成することができる。これらのコンポーネントの１つは、ユーザが例えば「Ｊａｖａサーバページ（ＪＳＰ）」を使用して「ＨＴＭＬ」ベース「ＧＵＩ」を構築することを可能にするウェブアプリケーションコンポーネントである。このコンポーネントは、「ＪＳＰ」テンプレート、タグ・ライブラリ、及び「ＪａｖａＳｃｒｉｐｔ」ライブラリのようなツールによって増強することができる。第２のコンポーネントは、アプリケーションサーバ上のアプリケーションビューをデプロイ、アンデプロイ、及び編集するための簡単な「ＡＰＩ」を提供することができるデプロイヘルパーコンポーネント又は要求処理プログラムである。
【０１０７】
アプリケーションビューは、アプリケーションの特定の機能に対するビジネスレベルのインタフェースを表すことができるが、アダプタは、アプリケーションの全ての機能に対するシステムレベルのインタフェースを表すことができる。アプリケーションビューは、単一のビジネス目的に対して構成することができ、そのビジネス目的に関連するサービスを含むことができる。これらのサービスは、要求文書で指定されるビジネス関連データだけを要求し、応答文書内のビジネス関連データだけを返すことができる。アプリケーションデータは、このビジネス関連データをアダプタに必要な保存されたメタデータと組み合わせることができる。アダプタは、ビジネス関連データと保存メタデータの両方を取り、アプリケーション上でシステムレベル機能を実行することができる。
【０１０８】
アプリケーションビューは、ビジネス目的をサポートするイベント及びサービスの両方を表すことができる。これにより、ビジネスユーザは、アプリケーションとの全ての通信においてアプリケーションビューと対話することができる。この双方向通信は、イベントアダプタ及びサービスアダプタによってサポートすることができる。アプリケーションビューは、この事実をユーザから取り去って、アプリケーションに対する統合ビジネスインタフェースをユーザに呈示することができる。
【０１０９】
イベントは、「ＥＩＳ」内で関心のあるイベントが発生した時にアプリケーションビューによって公開される「ＸＭＬ」文書とすることができる。イベントを通知して欲しいクライアントは、アプリケーションビューに自分たちの関心を登録することができる。アプリケーションビューは、目標アプリケーションとクライアントとの間の仲介者として作用する。クライアントがアプリケーションによって公開されたイベントに加入していた時は、アプリケーションビューは、目標アプリケーション内で関心のあるイベントが発生する度にクライアントに通知する。関心のあるイベントが発生したことがイベント加入者に通知される時、それは、イベントを記述する「ＸＭＬ」文書に通される。イベントを公開するアプリケーションビューはまた、公開可能なイベントに対する「ＸＭＬ」スキーマをクライアントに提供することができる。アプリケーションビューは、アプリケーション内の特定の機能性に対するビジネスレベルのインタフェースを表す。
【０１１０】
サービスは、アプリケーションビューによって公開される、アプリケーション内のビジネスオペレーションとすることができる。サービスは、要求／応答機構として存在することができる。アプリケーションがビジネスサービスを呼び出すための要求を受け取ると、アプリケーションビューは、その目標アプリケーション内のその機能性を呼び出し、結果を記述する「ＸＭＬ」文書を返すか、又はそれを用いて応答することができる。
サービスを定義するために、ユーザは、入力要件、出力予想、及び対話仕様のコンテントを判断して形成することが必要な場合がある。
【０１１１】
アプリケーションビューがデプロイされる時、それは、関連する「Ｊ２ＥＥコネクタ方式」の「ＣＣＩ」コネクションファクトリーデプロイを有することができる。例えば、ユーザが「ａｂｃ．ｘｙｚ」アプリケーションビューをデプロイする場合、アプリケーション統合は、新しい「ＣｏｎｎｅｃｔｉｏｎＦａｃｔｏｒｙ」をデプロイし、それを「ＪＮＤＩ」位置の「ｃｏｎｎｅｃｔｉｏｎＦａｃｔｏｒｙＩｎｓｔａｎｃｅ」に結合させることができる。効率化のために、新しいコネクションファクトリーデプロイは、「ｗｅｂｌｏｇｉｃ−ｒａ．ｘｍｌ」デプロイ記述子内の＜ｒａ−ｌｉｎｋ−ｒｅｆ＞設定を使用することができる。
【０１１２】
＜ｒａ−ｌｉｎｋ−ｒｅｆ＞要素は、複数のデプロイコネクションファクトリーと単一のデプロイアダプタとの論理的統合を考慮することができる。別々にデプロイされたコネクションファクトリーを識別する値を有する任意選択の＜ｒａ−ｌｉｎｋ−ｒｅｆ＞要素の仕様は、この新しくデプロイされたコネクションファクトリーが、参照されたコネクションファクトリーと共にデプロイされていたアダプタを共有するという結果を提供することができる。それに加えて、参照されたコネクションファクトリーのデプロイに定義された任意の値は、特に指定がない限り、この新しくデプロイされたコネクションファクトリーに継承することができる。アダプタの論理的名称は、＜ｒａ−ｌｉｎｋ−ｒｅｆ＞要素に対する値として使用することができる。
【０１１３】
設計時の機能
設計時の開発は、実行時のアダプタ開発に付随するものとは異なる可能性があるその独自の特徴を有することができる。例えば、設計時「ＧＵＩ」は、例えば１０個の「Ｊａｖａサーバページ（ＪＰＳ）」の組から構成することができる。「ＪＰＳ」は、トランザクションを呼び出すために「Ｊａｖａ」サーブレットを呼び出す「ＨＴＭＬ」ページである。ユーザに対しては、「ＪＳＰ」は、任意の他のウェブページのように見える。設計時「ＧＵＩ」を構成する「ＪＳＰ」は、例えば以下のものを含むことができる。
ｄｉｓｐｌａｙ．ｊｓｐ：「アダプタホームページ」とも呼ばれる表示ページ。このページは、アプリケーションビューのルック・アンド・フィールを作り出すために必要な「ＨＴＭＬ」を含むことができる。
ｌｏｇｉｎ．ｊｓｐ：「アダプタ設計時ログイン」ページ。
ｃｏｎｆｃｏｎｎ．ｊｓｐ：「接続確認」ページ。このページは、「ＥＩＳ」に対する接続パラメータを指定するためのユーザ用書式を提供することができる。
ａｐｐｖｗａｄｍｉｎ．ｊｓｐ：「アプリケーションビュー管理」ページ。このページは、アンデプロイされたアプリケーションビューの要約を提供することができる。
ａｄｄｅｖｅｎｔ．ｊｓｐ：「イベント追加」ページ。このページは、ユーザがアプリケーションビューに新しいイベントを追加することを可能にすることができる。
ａｄｄｓｅｒｖｃ．ｊｓｐ：「サービス追加」ページ。このページは、ユーザがアプリケーションビューに新しいサービスを追加することを可能にすることができる。
ｅｄｔｅｖｅｎｔ．ｊｓｐ：「イベント編集」ページは、ユーザがイベントを編集することを可能にすることができる任意選択のページである。
ｅｄｔｓｅｒｖｃ．ｊｓｐ：「サービス編集」ページは、ユーザがサービスを編集することを可能にすることができる任意選択のページである。
ｄｅｐａｐｐｖｗ．ｊｓｐ：「アプリケーションビューデプロイ」ページ。このページは、ユーザがデプロイ特性を指定することを可能にすることができる。
ａｐｐｖｗｓｕｍ．ｊｓｐ：「要約」ページ。このページは、デプロイ／アンデプロイされた状態と、接続判断基準と、プール構成、ログレベル、及びセキュリティのようなデプロイ情報と、イベントのリストと、サービスのリストとを含むアプリケーションビューに関する情報を表示することができる。
【０１１４】
「ＪＳＰ」テンプレート
設計時フレームワークは、アダプタのための新しいアプリケーションを形成、デプロイ、及び試験するウェブアプリケーションを迅速に組み立てるための一組の「ＪＳＰ」テンプレートを提供することができる。テンプレートは、「ＨＴＴＰ」要求にもたらされたパラメータに基づいて「Ｊａｖａサーブレット」によって動的に作成された「ＨＴＭＬ」ページである。テンプレートを使用して、ウェブアプリケーションに必要なカスタムページ及びカスタム「ＨＴＭＬ」の数を最小にすることができる。テンプレートは、アプリケーションビューのデプロイに必要な大部分の「ＨＴＭＬ」書式を提供することができる。多くの場合、カスタム書式だけが「ＥＩＳ」特有接続パラメータを収集するための書式を含むことができ、第２の書式は、イベントを追加するために必要な「ＥＩＳ」特有情報を収集するためのものであり、第３の書式は、サービスを追加するために必要な「ＥＩＳ」特有情報を収集するためのものである。それに加えて、「ＥＩＳ」に対するメタデータカタログを閲覧するために、カスタム「ＪＳＰ」を供給することができる。
テンプレートはまた、「Ｊａｖａ」プラットフォームの国際化及び地域化機能を利用することができる。ウェブアプリケーションのどのページのコンテントも、メッセージバンドル内に保存される。その結果、アダプタに対するウェブインタフェースは、迅速に国際化することができる。テンプレートはまた、ルック・アンド・フィールを１つの場所に集中させることができる。
【０１１５】
ネーミング規定の使用
ネーミング規定は、設計時ウェブアプリケーション及びコネクタデプロイのために使用することができる。統合システム内に「．ｅａｒ」ファイルをデプロイする時、このファイルは、ファイル名としてアダプタの論理的名称を使用して「ｃｏｎｆｉｇ．ｘｍｌ」のような構成ファイルとして識別することができる。これは、例えば、以下のように行うことができる。
2005506618.tif 000003
代替的に、「ｗｅｂｃｏｎｔｅｘｔ．ｔｘｔ」と名付けられたテキストファイルを「．ｅａｒ」ファイルのルートに含めることができる。「ｗｅｂｃｏｎｔｅｘｔ．ｔｘｔ」のようなファイルを使用して、アダプタに対する設計時ウェブアプリケーションに関するコンテキストを包含することができる。このファイルは、「ＵＴＦ−８」フォーマットに符号化することができる。
【０１１６】
上述の本発明の好ましい実施形態の説明は、例証と説明の目的で提供された。網羅的又は開示された正確な形態に制約するように意図してはいない。多くの修正及び変形が当業者には明白であろう。実施形態は、本発明の原理と実際の応用を最も良く説明するために選択して説明したものであり、それによって他の当業者が、様々な実施形態に対してかつ想定される特定用途に適する様々な変更を用いて本発明を理解することを可能にする。本発明の範囲は、特許請求の範囲とその均等物よって規定されるものとする。
【図面の簡単な説明】
【０１１７】
【図１】本発明の一実施形態に従って使用することができる統合システムの図である。
【図２】図１のシステムに使用することができるアプリケーションビューを作成してデプロイする方法を示す流れ図である。
【図３（ａ）】共通プロトコル無しで通信するコンピュータシステムを示す図である。
【図３（ｂ）】共通プロトコルを有して通信するコンピュータシステムを示す図である。
【図４】様々なシステムに要求するためにアプリケーションビューを使用する顧客を示す図である。
【図５】図１のシステムに使用することができるアプリケーションビューコンポーネントのライフサイクルを示す流れ図である。
【図６】本発明の一実施形態に従って「「Ｓｉｅｂｅｌ」」システムと「ＳＡＰ」システムとを統合するためのシステムを示す図である。
【符号の説明】
【０１１８】
１００  クライアントアプリケーション
１０２  アプリケーションビュー
１０４  企業情報システム
１０６、１０８、１１０  アダプタ
【図１】
2005506618.tif 000004
【図２】
2005506618.tif 000005
【図４】
2005506618.tif 000006
【図５】
2005506618.tif 000007
【図６】
2005506618.tif 000008
【国際公開パンフレット】
2005506618.tif 000009
2005506618.tif 000010
2005506618.tif 000011
2005506618.tif 000012
2005506618.tif 000013
2005506618.tif 000014
2005506618.tif 000015
2005506618.tif 000016
2005506618.tif 000017
2005506618.tif 000018
2005506618.tif 000019
2005506618.tif 000020
2005506618.tif 000021
2005506618.tif 000022
2005506618.tif 000023
2005506618.tif 000024
2005506618.tif 000025
2005506618.tif 000026
2005506618.tif 000027
2005506618.tif 000028
2005506618.tif 000029
2005506618.tif 000030
2005506618.tif 000031
2005506618.tif 000032
2005506618.tif 000033
2005506618.tif 000034
2005506618.tif 000035
2005506618.tif 000036
2005506618.tif 000037
2005506618.tif 000038
2005506618.tif 000039
2005506618.tif 000040
2005506618.tif 000041
2005506618.tif 000042
2005506618.tif 000043
2005506618.tif 000044
2005506618.tif 000045
2005506618.tif 000046
2005506618.tif 000047
2005506618.tif 000048
2005506618.tif 000049
2005506618.tif 000050
2005506618.tif 000051
2005506618.tif 000052
2005506618.tif 000053
2005506618.tif 000054
2005506618.tif 000055
2005506618.tif 000056
2005506618.tif 000057
2005506618.tif 000058
2005506618.tif 000059
2005506618.tif 000060
2005506618.tif 000061
2005506618.tif 000062
2005506618.tif 000063
2005506618.tif 000064
2005506618.tif 000065
2005506618.tif 000066
2005506618.tif 000067
2005506618.tif 000068
2005506618.tif 000069
2005506618.tif 000070
2005506618.tif 000071
2005506618.tif 000072
2005506618.tif 000073
2005506618.tif 000074
2005506618.tif 000075
2005506618.tif 000076
2005506618.tif 000077
2005506618.tif 000078
【国際調査報告】
2005506618.tif 000079
2005506618.tif 000080