JP2004500619A - サービスを作成するための方法および装置 - Google Patents

Abstract

ネットワーク・サービスを作成するための方法および装置を提供する。ｗｅｂサービス全体のプログラミングまたはハード・コーディングの代わりに、本発明は、ｗｅｂサービスを作成するために利用することができるコードを生成するモジュール／メカニズム（テンプレート（１００）と呼ばれる）を容易に作成するための能力を提供する。したがって、テンプレート（１００）が形成され、利用されて、アプリケーション（１０４）またはｗｅｂサービスを生成することができるモデル（２０４）が作成される。各テンプレートは、機能のリスト（２０２）およびモデル（１０２）（ランタイム・モデルまたはＲＴＭと呼ばれる）からなる。ＲＴＭ（１０２）はＸＭＬドキュメントであり、これはｗｅｂサービス・アプリケーション（ＷＳＡ（３０４）と呼ばれる）の構造、機能性および挙動を宣言する。１つまたは複数の実施形態では、各機能が、新しいＲＴＭ（１０２）において出力されるＸＭＬエンティティを生成することを担う。各機能は、１つまたは複数のユーザの入力を得ることができ、これが利用されてＸＭＬエンティティが新しいＲＴＭにおいて構築される。さらに、各機能を順次処理することができ、これは、すでに（たとえば、他の機能によって）作成されているいかなる既存のＸＭＬエンティティも修正するための能力を有する。

Description

【０００１】
（発明の背景）
１．発明の分野
本発明は、ネットワーク・サービス作成の分野に関する。
【０００２】
本特許明細書の開示の一部は、著作権保護を受ける事項を含む。著作権の所有者は、特許商標局のファイルまたは記録において現れるような本特許明細書または本特許の開示の、いかなるものによる複写複製にも異議を申立てないが、そうでない限りはすべての著作権を留保する。
【０００３】
２．背景技術
Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂはｗｅｂサイトの集まりであり、それぞれが情報、データおよび／またはある種類または別の種類のサービスを提供する。現在のインターネットおよびＷｅｂサービスによる問題は、各サービスを静的に、かつ他のサービスから独立してプログラムしなければならないことである。さらに、ｗｅｂサービスの機能を修正あるいは変更するには、プログラマがｗｅｂサービスのコードを修正しなければならない。この問題は、ビジネスおよびそれらによるインターネットの使用を見直すことによって、よりよく理解できる。
【０００４】
多数のビジネスが、それらの機能性の一部として他のビジネスに依拠している。たとえば、製品のディストリビュータは異なる製品のメーカのすべてに依拠して、信頼性を有して製品自体を供給するだけでなく、製品の価格および可用性についての情報も供給している。メーカ自体も部分的にサプライヤに依拠して完全な製品を構築している。競争的なビジネス環境において競争するためには、会社が製品およびサービスについての迅速な応答を顧客に提供できることが必要である。これにはしばしば多数の他の会社との対話が必要となる。過去には、会社の販売員が電話をかけるか、あるいはカタログを参照して顧客の要求に回答を提供する間、顧客が快く待機している可能性があった。しかし今日は、顧客がより高速なサービス、または自分自身で情報を得る能力を要求している。他の場合、顧客は会社の販売員とまったく対話しておらず、会社のｗｅｂサイトと対話している可能性がある。この環境では、顧客はさらに高速かつ効率的なサービスを要求する。
【０００５】
会社が今日のビジネス環境において競争できる状態であり続けるための１つの方法は、サード・パーティである会社のコンピュータ・システムと対話して、自社のビジネスを運用するために必要とされる情報およびサービスを得ることができる、アプリケーション・プログラム（ソフトウェア）を開発することである。しかし、従来、これらのアプリケーションを作成することは困難であった。１つの問題は、異なる会社のしばしばメーカ独自のコンピュータ・システムとの対話における困難さである。もう１つの問題は、アプリケーションを自分で記述かつデバッギングすること、ならびに状態が変化したとき、あるいはサード・パーティの会社が自社所有のシステムを変更あるいは更新したときにこれらを更新することにおける困難さである。
【０００６】
ビジネスの風潮におけるこの変化も、部分的にはインターネットによって促進されてきた。インターネットは、多数のソースからの情報を容易に個人が入手できるようにした。加えて、インターネットは、会社が互いに対話する方法を変えた。ビジネスとビジネスとの対話は現在、しばしばインターネットを介して実施される。ビジネス間の関係（ディストリビュータとそのサプライヤの間など）はしばしば「チャネル関係」または「ビジネス・チャネル」と呼ばれる。
【０００７】
ビジネス・チャネルを管理するためのソフトウェア・アプリケーションを作成することは、従来の技術を使用すると複雑であり、柔軟性がない。ハード・コーディングされたアプリケーションが作成された場合、経時的に作成あるいは修正される新しいチャネルに応答することができない可能性がある。記録の労力を繰り返すことが必要となる可能性がある。他の場合、ある会社が別の会社と、他の会社が気付くことなくチャネル関係にある可能性がある。たとえば、Ｆｅｄｅｒａｌ　Ｅｘｐｒｅｓｓまたは他の運送業者を使用して商品を輸送する会社は、運送業者との明示的で公的な関係を有することなくそれを行う。運送業者にとっては、それを使用するあらゆる会社とのビジネス・チャネルを維持することは、不可能なタスクではない場合でも気力をくじくようなことである。
【０００８】
従来の技術は、たとえばオブジェクト指向プログラミングを介して、アプリケーションの設計においてコードの再使用における効率に焦点を置くが、アプリケーションのランタイムでの効率またはカスタマイズ可能性を提供しない。多数の会社がサービスをインターネット上で使用可能にしているので、ｗｅｂサービスの組み合わせを動的に呼び出して相互接続し、それら自体をカスタマイズされたフォーマットにおいてランタイムで構成するカスタム・アプリケーションを、効率的に作成できるようにする必要性がある。現在までのところ、従来技術は効果的なソリューションを提供していない。
【０００９】
現在、ｗｅｂが使用されて、事前定義されたｗｅｂページがユーザ／クライアントによる閲覧用に提供されている。しかし、静的なｗｅｂページを提供するよりも多くのことを行う必要性がある。ｗｅｂページを動的に修正あるいは作成し、ｗｅｂページの他の要素またはコンポーネントを考慮するメカニズム／モジュールを容易に作成することが望ましい。さらに、ユーザに様々な機能を提供するｗｅｂサービスを利用する必要性が増大しつつある。現在、ｗｅｂサービスを動的に生成あるいは修正するためのメカニズムはない。加えて、ｗｅｂサービスを、ｗｅｂサービスの既存の態様に基づいて修正するためのメカニズムはない。
【００１０】
（発明の概要）
本発明は、ネットワーク・サービスを作成するための方法および装置を提供する。ｗｅｂサービス全体のプログラミングまたはハード・コーディングの代わりに、本発明の１つまたは複数の実施形態は、ｗｅｂサービス・アプリケーションのＸＭＬ定義を提供するコード（ランタイム・モデルと呼ばれる）を生成するモジュール／メカニズム（テンプレートと呼ばれる）を容易に作成するための能力を提供する。したがって、テンプレートが形成され、利用されて、ｗｅｂサービス・アプリケーションの基礎を生成することができるモデルが作成される。
【００１１】
各テンプレートは、機能（ｆｅａｔｕｒｅｓ）のリストおよびモデル（ランタイム・モデルまたはＲＴＭと呼ばれる）を含む。ＲＴＭは、ＸＭＬドキュメントであり、これはｗｅｂサービス・アプリケーション（ＷＳＡと呼ばれる）の構造（ｓｔｒｕｃｔｕｒｅ）、機能性（ｆｕｎｃｔｉｏｎａｌｉｔｙ）および挙動（ｂｅｈａｖｏｒ） を宣言する。１つまたは複数の実施形態では、各機能が、新しいＲＴＭにおいて出力されるＸＭＬエンティティを生成することを担う。各機能は、１つまたは複数のユーザの入力を得ることができ、これが利用されてＸＭＬエンティティが新しいＲＴＭにおいて構築される。さらに、各機能を順次処理することができ、これは、すでに（たとえば、他の機能によって）ＲＴＭにおいて作成されているいかなる既存のＸＭＬエンティティも修正するための能力を有する。したがって、機能は、アプリケーションを全体として見て、それらが担うエンティティを調整かつ修正するだけでなく、変更を既存のアプリケーション全体に実施するための能力を有する。
【００１２】
本発明の１つまたは複数の実施形態では、アプリケーションに影響を与える可能性のある状態が変化したとき、テンプレートを利用してＲＴＭを再生して、新しいｗｅｂサービスまたはＸＭＬドキュメントを生成することができる。
【００１３】
（発明の詳細な説明）
以下の説明では、多数の特定の詳細を、本発明のより十分な理解を提供するために述べる。しかし、本発明を、これらの特定の詳細がなくとも実施できることは、当業者には明らかになるであろう。他の例では、よく知られた機能を詳細に記載していないが、これは本発明を不必要に不明瞭にしないためである。
【００１４】
本発明は、使用可能なｗｅｂサービスを使用するアプリケーションを作成するための方法および装置を提供する。多数のサービスがインターネットを介して、ならびに既存のＡＰＩおよび他の技術を介して使用可能にされている。インターネットでは、多数のサービスがＸＭＬサービスとして使用可能にされている。ＸＭＬ（拡張マークアップ言語、ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）は、情報を記述するため、あるいはより正確には、情報を自己記述にするために使用される言語である。従来、ｗｅｂページはＨＴＭＬを使用して構築されている。ＨＴＭＬ（ハイパーテキスト・マークアップ言語）はデータのぺージのジオメトリおよび外観を記述し、実際にはデータが挿入される穴またはスロットを作成する。しかし、ＨＴＭＬ記述におけるページ上に現れるデータの直接通信はない。ユーザには、名前、住所および電話番号など、認識可能な情報を含むページを提示することができる。しかし、ＨＴＭＬでは、データは単に表示するためのテキストである。
【００１５】
他方では、ＸＭＬは、使用中のデータのタイプを識別することができるプロトコルを提供する。ＸＭＬはこれを部分的には、事前定義された「スキーマ」を使用して行うことができ、これを使用して伝送中のデータのタイプを理解することができる。標準のスキーマが使用された場合、データはスキーマへの参照のみを含む必要があり、これがデータと共に移動する必要はない。カスタム・スキーマが使用された場合、これをデータの前または後に送信することができるか、あるいは、スキーマの位置への明示的な方向を提供することができる。
【００１６】
本発明は、ＸＭＬベースのサービスを十分に利用することができるが、通信プロトコルを確立することができるいかなるサービスとの使用にも適用可能である。
【００１７】
本発明の１つまたは複数の実施形態は、使用のために入手可能なサービスを含む、ビジネスまたは企業のためのｗｅｂサービス・ディレクトリを作成する。各サービスのためのインターフェイスが使用可能であり、これは要求および応答を、インターネットおよびバック・エンド・システム環境における使用のために適切なフォーマットに変換するためのものである。加えて、インターフェイスを利用して、コールされたサービスに渡される要求データのスキーマを定義することができ、コールされたサービスによって渡される応答データのスキーマを定義することができる。
【００１８】
ｗｅｂサービス・アーキテクチャ（「システム」と呼ばれる）がｗｅｂサービスについてのメタデータを維持し、これらはｗｅｂサービス消費者による使用のために公開されている。システムはｗｅｂサービスのアクセス・コントロール、編成（ｏｒｇａｎｉｚａｔｉｏｎ）、インターフェイス定義、管理およびオペレーションを提供する。ｗｅｂサービス・アーキテクチャは、集中化された位置としての機能を果たし、ここからｗｅｂサービス消費者が、公開されたｗｅｂサービスのセットについてのすべての情報を得ることができる。加えて、ｗｅｂサービス・アーキテクチャは中心位置を提供し、個々のｗｅｂサービスの実際の作業を実行するシステム（アプリケーション）がインターネット全体に分散されているという事実に関わらず、ここからｗｅｂサービスを動作することができる。
【００１９】
ｗｅｂサービス・アーキテクチャは、ｗｅｂサービス・ディレクトリおよびｗｅｂサービス・エンジンを含む。ｗｅｂサービス・ディレクトリはデータベースであり、ｗｅｂサービス・エンジンはｗｅｂサービス要求をハンドルするプロセッサである。
【００２０】
＜＜Ｗｅｂサービス・アプリケーションおよびランタイム・モデル＞＞

ｗｅｂサービス・エンジンが実行するもっとも著しいアクティビティの１つが、単一のセッションのコンテキストにおける多数のｗｅｂサービスの実行である。ｗｅｂサービス・アーキテクチャは、ランタイム・モデルと呼ばれるＸＭＬオブジェクトのタイプをサポートしており、これは多数のｗｅｂサービスが実行されるコンテキストを定義する。ｗｅｂサービス・エンジンが、このような指定されたランタイム・モデルによるモデル・ランナー・サービス（ｍｏｄｅｌ ｒｕｎｎｅｒ ｓｅｒｖｉｃｅ）を実行するための要求を受信したとき、システムが、ｗｅｂサービス・アプリケーションと呼ばれるものをセッションにおいて生成する。
【００２１】
ランタイム・モデルは、いくつかのｗｅｂサービスの実行を共に連鎖する方法の宣言とは著しく異なる。本発明の１つまたは複数の実施形態は、多数のアクションを宣言するランタイム・モデルを提供し、それぞれをファンクションにおいて定義された精巧な機能性の実行にバインドすることができる。加えて、ランタイム・モデルは多数のパラメータを宣言し、これらがｗｅｂサービスの入力および出力として使用される。最後に、ランタイム・モデルが、いくつかのｗｅｂサービスの使用を引き起こし、これらが特殊なユーザ・インターフェイス・ページを出力データとして構築する。これらのページの挙動は、ｗｅｂサービス・エンジンに対する後続のｗｅｂサービス要求を生成すること、および実行のために、ｗｅｂサービス・アプリケーション・セッションにおいて定義されたアクションをコールすることである。それとして、ランタイム・モデル、およびそれが生成するｗｅｂサービス・アプリケーションは、アプリケーションの複雑な新しい形式のためのレシピである。
【００２２】
ＷＳＡがないと、ｗｅｂサービス・アーキテクチャはアトミックとなり、場合により、ｗｅｂサービス・エンジンに対する要求の処理中のアクティビティが単一のｗｅｂサービスの実行のみとなることを意味する。ＷＳＡは、ｗｅｂサービス・エンジンが、多数のｗｅｂサービスを含む複雑なタスクを実行できるようにするための手段を提供する。加えて、ＷＳＡは、ｗｅｂサービス・エンジンの外側のｗｅｂサービス要求者が単一のセッション状態と、要求を通じて対話することができるようにする。
【００２３】
＜＜Ｗｅｂサービス・アプリケーションのオペレーション＞＞
ｗｅｂサービス・エンジンに対する要求がＷＳＡを呼び出したとき、システムがこの要求を処理し、応答を生成する。応答をＸＭＬ、ＨＴＭＬ、ＭＩＭＥエンコード化（たとえば、．ｇｉｆファイル）、またはインターネット・ワイヤ・プロトコルによってサポートされたいかなるフォーマットにすることもできる。１つまたは複数の実施形態では、ｗｅｂサービス要求が、ブラウザにおいて表示されるグラフィカル・ユーザ・インターフェイスの形式を取る応答を生成する。これは、要求側（ｗｅｂサービス消費者）がｗｅｂブラウザであるときの場合である。返されたユーザ・インターフェイスはしばしばそれらにおいて埋め込まれたコントロールを有し、これが後続のユーザ生成イベントに反応し、ブラウザに、ｗｅｂサービス・エンジンに返す後続のＨＴＴＰ要求を生成させる。これらの要求ではしばしば同じＷＳＡが目標とされる。ｗｅｂサービス・アーキテクチャでは、ｗｅｂサービス・エンジン上の単一のＷＳＡセッションがその状態を、異なるユーザ・インターフェイスによって生成された異なる要求とのいくつかの対話全体で維持することが可能である。たとえば、ＷＳＡがＵＩの初期ページを、初期要求に対する応答として生成することが可能である。このＵＩはボタンを含むことができる。ユーザがボタンを押したとき、ブラウザが、同じＷＳＡに対して目標とされた新しい要求を生成する。ｗｅｂサービス・エンジンがサービスを呼び出し、これにより既存のＷＳＡが要求を処理し、別のＵＩページを生成することができる。
【００２４】
ｗｅｂサービス・エンジンは、ＷＳＡのキャッシングを管理する。ｗｅｂサービス・ディレクトリは、ｗｅｂサービス、およびランタイム・モデルを構築するために使用されたテンプレートの持続的な記述を管理する。ｗｅｂサービス・エンジンはＷＳＡの呼び出しを、モデル・ランナーｗｅｂサービスの使用を介して実施する。
【００２５】
ｗｅｂサービス・アーキテクチャは、１つまたは複数のランタイム・モデルのためのｗｅｂサービスを維持する。要求側がＷＳＡを動作することを望んだとき、要求側がＨＴＴＰ要求を生成して、「モデルベース」のｗｅｂサービスと呼ばれる特殊なタイプのｗｅｂサービスを動作する。これらのｗｅｂサービスは、ＷＳＡに対応するためのランタイム・モデルを維持する責任を有する。これらのｗｅｂサービスは、モデル・ランナーと呼ばれる共通のｗｅｂサービス・ドライバも参照し、これはランタイム・モデルをサービス・パラメータとして取り、ＷＳＡを生成することを担う。
【００２６】
ｗｅｂサービス・エンジンがモデル・ランナー・ドライバのインスタンスを呼び出し、ＷＳＡを生成した後、モデル・ランナー・ドライバが、ＷＳＡにおいて定義された特殊な名前のアクション（この実施ではＯｎｌｏａｄと呼ばれる）をコールする。アクションは、ｗｅｂサービスまたはファンクション（いくつかのアクションの呼び出しを定義するもの）へのコールである。アクションは、メソッドによって実行されるオペレーションに類似している（たとえば、別のメソッド／ファンクションへのコール、または、割当てまたは連結のような単純なデータ操作を実行すること）。
【００２７】
ＯｎｌｏａｄファンクションはＷＳＡの初期状態を確立し、これは、ｗｅｂサービス要求に対する応答データを生成する作業単位を実行する。Ｏｎｌｏａｄファンクションが動作を終了したとき、モデル・ランナー・ドライバが要求側のセッションにおけるＷＳＡの状態を保存する。加えて、ランタイム・モデルを要求側のセッションにおいて保存することもできる。
【００２８】
Ｐａｇｅアクションは、応答データをインタラクティブなＵＩの形式において生成するために使用される特殊なタイプのアクションである。Ｐａｇｅアクションは応答データのパケットをＨＴＭＬまたはＸＭＬのいずれかで生成し、これはグラフィカルに提示可能な情報をユーザ・インターフェイス（ＵＩ）コントロールと共に含む。これらのコントロールの挙動を、元のＷＳＡセッションのハンドルを使用して、ｗｅｂサービス・エンジンに対する後続のｗｅｂサービス要求を生成するように設定することができる。
【００２９】
時として、ＷＳＡはＯｎｌｏａｄファンクションにおいてそのすべての作業を行い、その応答データを送信して戻し、ダウンストリーム・コンタクトを確立する後続のｗｅｂサービス要求のいかなる意図もなしに終了する。他のときは、ＷＳＡにおけるアクション（またはファンクション）が、埋め込み型ＸＭＬモデル・セッション・ハンドルを含む応答データを生成する。このデータにより、ブラウザまたは他のシステムが、ｗｅｂサービス要求を同じＷＳＡセッションに対して生成することができる。
【００３０】
＜＜Ｗｅｂサービス・アプリケーションの機能性＞＞
ＷＳＡの機能性（ｆａｎｃｔｉｏｎａｌｉｔｙ） は完全に、ランタイム・モデルにおけるＸＭＬベースの宣言、および呼び出されたｗｅｂサービスによって提供された機能性によって定義される。ＷＳＡの機能性を宣言するランタイム・モデルがモデル・ランナー・サービスによって使用されて、ＷＳＡによって呼び出された、すべての呼び出されたｗｅｂサービスがインスタンス化される。加えて、ランタイム・モデルは、ロジック（機能性）、データ構造および挙動の宣言を含む。
【００３１】
ＷＳＡの挙動は、ランタイム・モデルにおいて宣言されるイベントに対するアクションのバインディングのセットによって定義される。イベントの多数は、ランタイム・モデルにおいて定義されたＰａｇｅｓと対話するユーザによって生成されるものである。ｗｅｂサービスがＷＳＡと対話するとき、ＷＳＡがＰａｇｅｓを応答データとして生成し、これらのＰａｇｅｓが、追加のｗｅｂサービスをコールするアクションへのイベントのバインディングを定義する挙動を含む。
【００３２】
本発明の１つまたは複数の実施形態によれば、起動において、ＷＳＡがＯｎｌｏａｄ機能性を実行する。実行中に、モデル・ランナー・サービス・ドライバが追加のｗｅｂサービスに対して内部コールを行い、これはｗｅｂサービス・エンジンが追加のサービス・ドライバをエンゲージする結果となる。ｗｅｂサービスを動作するための内部要求は、ｗｅｂサービス・エンジンから、ＷＳＡセッションにおいて存在するサービス入力のセットと共に来る。しかし、外部コールはＨＴＴＰポストの形式において来るか、あるいはｗｅｂサービス・エンジンにおけるＵＲＬへ、入力データのパケットと共に到着する。
【００３３】
初期ｗｅｂサービス要求が処理され、応答データが送信され戻された後、ｗｅｂサービス・エンジンは、すでに動作中のＷＳＡのモデル・セッションが目標とされた後続のｗｅｂサービス要求をハンドルすることができる。これらのセッション固有の要求はそれぞれモデル・ハンドルＩＤを含み、これによりｗｅｂサービス・エンジンが、指定されたＷＳＡをエンゲージすることができる。これらの要求はまた、ＷＳＡにおいて実行してｗｅｂサービス要求の作業を実行するためのアクションも識別する。たとえば、ＷＳＡは最初に従業員のリストを、そのＯｎｌｏａｄアクティビティを介して得て、この情報をページにおいて、応答としてブラウザへ送信しておくことができる。加えて、このページはボタンを含むことができる。このボタンが押されたとき、ブラウザが、同じＷＳＡセッションにおいて指定されたアクションを動作するためのｗｅｂサービス要求を生成する。このとき、要求がＷＳＡセッションのＩＤを含む。結果として、ボタンが、動作中のＷＳＡにおいてアクションを動作するための要求を生成して、状態がＷＳＡにおいてすでに存在する従業員についての追加の情報を得る。
【００３４】
ＷＳＡの状態がＸＭＬパラメータのセット（ｗｅｂサービス・コール・データ出力を含む）によって表現される。パラメータはデータのためのＸＭＬコンテナであり、これらはＸＭＬスキーマを有し、これらがパラメータにおいてサポートされるデータのタイプを定義する。パラメータにおけるデータは、経時的にＷＳＡセッションにおいて変化する。ファンクションにおいて定義されたロジックによって、ＷＳＡがパラメータ値をサービス・コール入力に割り当てることができ、ならびにｗｅｂサービス・コールの出力をパラメータに向けて送ることができる。ＷＳＡは、ｗｅｂサービス・エンジンによって管理されたｗｅｂサービス・コールの内外へ情報を移動するためのブローカリング・システムとしての機能を果たす。
【００３５】
最後に、ＷＳＡは、完全にインタラクティブなユーザ・インターフェイスの生成および更新をサポートする。ユーザ・インターフェイスは、Ｐａｇｅｓと呼ばれる、動的に生成かつ更新されたＸＭＬエンティティのセットからなる。ＰａｇｅｓはＸＭＬデータのブロックであり（ＨＴＭＬはサブセットとなる）、ブラウザによる表示に適している（しかし、いかなる形でもブラウザにおける閲覧に限定されない。ＰａｇｅはＨＴＭＬを含まなくてもよい）。
【００３６】
ユーザ・インターフェイスはＷＳＡのオプションの特性である。いくつかのＷＳＡは、計算をデータ入力上で実行し、ＵＩコンポーネントを含んでいない出力データを生成する機能性を有する。これらのＷＳＡは通常、最初のｗｅｂサービス要求の実行後にシャット・ダウンする。他のＷＳＡは、ＵＩを応答データにおいて生成する起動機能性を有する。この生成されたＵＩは、タグ付けされた挙動を含むことができ、これによりブラウザが、ｗｅｂサービス・エンジンに対する後続のサービス要求を静止して、動作中のＷＳＡに接続し、追加のアクションを呼び出す。次にこれらのアクションは、サービス要求に対する応答として送信され戻される新規または更新されたページを生成する結果となる可能性がある。この対話を介して、ＷＳＡはユーザとの複雑な対話をハンドルすることができるが、同時に、インターネット全体に分散されているｗｅｂサービスをエンゲージするｗｅｂサービス・コール・アクションを実行することができる。
【００３７】
＜＜ランタイム・モデルの構造＞＞
ランタイム・モデルは、いかなるＸＭＬデータ（ＸＭＬにおいて記述されたｗｅｂサービスを含む）も表現するドキュメントのタイプである。たとえば、１つまたは複数の実施形態では、ランタイム・モデルはＸＭＬドキュメントであり、これはＷＳＡの構造、機能性および挙動を宣言する。もう１つの実施形態では、ランタイム・モデルが、たとえば、３Ｄジオメトリック・データ・エンティティまたはＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ Ｓｔｙｌｅｓｈｅｅｔ Ｌａｎｇｕａｇｅエンティティ）を表現する。１つまたは複数の実施形態では、ｗｅｂサービス・エンジンにおけるモデル・ランナー・ドライバがランタイム・モデルのコンテンツを、ＷＳＡを生成するために解釈する。しかし、他のタイプのサービスは、新しいアプリケーションのために使用されたランタイム・モデル・エンティティの解釈をハンドルすることができる。１つまたは複数の実施形態は、オープンかつ拡張可能であるスキーマに従うためのランタイム・モデルに備える。
【００３８】
ランタイム・モデルは幅広いアレイのエンティティをサポートしており、これらが異なる態様のＷＳＡを記述する。ランタイム・モデルは機能性を宣言することができ、多数のランタイム・モデルが、ランタイム実行中に協調するＷＳＡに呼び出される結果となる。これは、ランタイム・モデルにｗｅｂサービスへのコールを宣言させることによって実施され、ｗｅｂサービスは他のランタイム・モデルへの参照を作成する。
【００３９】
＜＜モデル＞＞
１つまたは複数の実施形態では、ランタイム・モデルがＭｏｄｅｌと呼ばれるルート・ノードを有することができる。Ｍｏｄｅｌエンティティはサブノードのセットを含む。この実施では、これがＰａｇｅｓ、ＳｅｒｖｉｃｅＣａｌｌｓ、Ｔｒｉｇｇｅｒｓ、ＰａｒａｍｅｔｅｒｓおよびＢｅｈａｖｉｏｒｓを含む。以下で参照するように、ＸＭＬの機能性および使用は、共通に利用されるものに基づいている。さらに、本明細書で利用されたＸＭＬ記述は、記述のためのものであり、ＸＭＬデータは空のタグからなる可能性がある。空のタグは＜タグ名／＞としてフォーマットされる。ＸＭＬデータは、満たされたタグを、＜タグ名＞他の＜タグ付けされたデータ＞さらなるデータ＜／タグ付けされたデータ＞を含むデータ＜／タグ名＞の形式で含むことができる。加えて、ＸＭＬの構造をスキーマ言語において定義することはできず、ランタイム・モデルは、いかなるＸＭＬスキーマにも従ういかなるＸＭＬデータも含むことができる。
【００４０】
たとえば、以下のＸＭＬは１つまたは複数の実施形態を記述し、これはランタイム・モデルにおいて利用することができるいくつかのエンティティを含む。
【表１】

【００４１】
Ｐａｇｅｓ
ランタイム・モデルのＰａｇｅｓエンティティは、個々のページ・エンティティのセットを含む。ランタイム・モデルはいかなる数のページを有することもできる。Ｐａｇｅｓは、ブラウザにおける表示のために適切にフォーマットされるコンテンツおよびＵＩのための媒介物としての機能を果たす。
【００４２】
モデル・ランナー・サービス・ドライバがＷＳＡを生成した後、これはＷＳＡにおいて機能性のブロックを実行し（以下のサービス・コールおよびトリガのセクションを参照）、これが最終的に応答を要求側に送信して戻す。多くの回数、応答はページの形式であり、ブラウザにおける表示に適している。
【００４３】
ページは単に、ＷＳＡセッションにおいてパラメータ化されたＸＭＬデータの別のタイプであるので、ＷＳＡはページを出力としてサービス要求に利用するか、あるいは入力として別のｗｅｂサービスに利用することができる。これは、ＷＳＡがページを入力として様々なｗｅｂサービスに送信できることを意味する。たとえば、ＷＳＡはページをｅメールのｗｅｂサービスへ、メッセージのコンテンツとして送信することができる。
【００４４】
Ｐａｇｅエンティティは、以下のエンティティを含む。
【表２】

【００４５】
ＰａｇｅにおけるＣｏｎｔｅｎｔｓエンティティは、ネストされたＸＭＬを含むいかなるタイプのＨＴＭＬも含む。ＣｏｎｔｅｎｔセクションはＸＭＬエンティティも含み、これがデータおよびコントロールのためのプレースホルダを表現する。
【００４６】
ＷＳＡにおいてコールすることができるアクションの１つが、Ｐａｇｅアクションである。このアクションはｗｅｂサービスを呼び出し、これが変換をＰａｇｅエンティティのセットに、データをサービス要求に対する応答として送信するための準備において適用する。Ｐａｇｅアクションにより、システムがパラメータ・データを、Ｐａｇｅエンティティにおいて宣言されたデータ・プレースホルダに挿入し、コールバックをＰａｇｅにおいて、そのＰａｇｅのためのランタイム・モデルにおいて定義済のいかなる宣言された挙動についても書き込む。たとえば、ＬＤＴ：Ｂｕｔｔｏｎエンティティは、ＨＴＭＬボタンの存在を宣言し、これはｗｅｂサービス要求をＷＳＡにおけるアクションに対して呼び出すクリック・アクションを有する。
【００４７】
＜＜サービス・コール＞＞
ランタイム・モデルのＳｅｒｖｉｃｅＣａｌｌｓエンティティは、個別のＳｅｒｖｉｃｅＣａｌｌエンティティのセットを含む。サービス・コールは、ｗｅｂサービス・ディレクトリにおいて定義されたｗｅｂサービスを呼び出すアクションである。１つまたは複数の実施形態では、サービス・コールが、ＷＳＡの実行を管理している同じｗｅｂサービス・ディレクトリに位置するｗｅｂサービスのみを識別することができる。１つまたは複数の追加の実施形態では、ｗｅｂサービス・エンジンがｗｅｂサービス要求を、別のｗｅｂサービス・ディレクトリに位置するｗｅｂサービスに対して、それが動作中であるＷＳＡに代って行うことができる。
【００４８】
サービス・コールは、ｗｅｂサービス・ディレクトリにおけるｗｅｂサービスをコールするアクションである。サービス・コールは、名前付きのｗｅｂサービスのための入力および出力データ・スキーマ、ならびにデータのためのプレースホルダのＷＳＡ常駐表現も提供する。最後に、サービス・コールは、ｗｅｂサービスの入力への入力値の割当ての定義を維持することができる。これらの割り当てられた値は、定数、またはランタイム・モデルにおけるパラメータにおける値への参照にすることができる。
【００４９】
ＳｅｒｖｉｃｅＣａｌｌエンティティは、以下を含む。
【表３】

【００５０】
ＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎｓエンティティは、個別のＤａｔａＤｅｆｉｎｉｔｉｏｎエンティティのセットを含む。これらのエンティティは入力への定数値の割当て、ならびにサービス・コールへの入力のためのデータのソースとしてのランタイム・モデルにおけるパラメータの割当てを含む。
【００５１】
１つまたは複数の実施形態では、効果選択条件を、ＳｅｒｖｉｃｅＩＤ情報の一部として含めることができる。１つまたは複数の実施形態では、サービス・コールがサービスをその名前によって識別する。さらに、１つまたは複数の実施形態では、ＳｅｒｖｉｃｅＩＤが一意の識別子をＬＤＡＰ識別名の代わりに利用することができる。このような実施形態では、テンプレートを容易に、あるディレクトリから別のディレクトリへ移動することができる。もう１つの実施形態では、サービス・コールが、「リリース・レベル」などの属性のための属性値を、正しいバージョンのサービスを識別する手段として識別することができる。さらに、サービス・コールは、サービスのバージョンを選択条件によって識別することができる。
【００５２】
＜＜Ｔｒｉｇｇｅｒｓ（ファンクションとしても知られる）＞＞
ランタイム・モデルのＴｒｉｇｇｅｒｓエンティティは、Ａｃｔｉｏｎエンティティのセットを含む。Ｔｒｉｇｇｅｒｓはクラスにおけるメソッド、およびスクリプトされたＨＴＭＬページにおけるファンクションに相当するものである。
【００５３】
トリガは実行ロジックのブロックであり、識別ハンドルとしての機能を果たすアクションを有する。ランタイム・モデルは、アクション・ハンドルをイベントにバインドすることができ、これは挙動の概念を構成するものである。ランタイム・モデルにおける挙動は、イベントへのアクションのバインディングとして定義される。
【００５４】
１つまたは複数の実施形態では、トリガがアクションのシーケンスとして定義される。トリガのアクションが呼び出されたとき、システムはトリガによって指定されたアクションを呼び出す。別の実施形態では、トリガが、分岐を含む多数の形式のロジック処理をサポートする。
【００５５】
Ｔｒｉｇｇｅｒエンティティは以下を含む。
【表４】

【００５６】
Ａｃｔｉｏｎｓエンティティは、Ｔｒｉｇｇｅｒが呼び出されたときに実行されるアクションのロジックおよびフローを記述する情報を含む。これを、単純なアクションのリストにすることができる。
【００５７】
Ａｃｔｉｏｎｓは、ランタイム・モデルにおいて機能的に定義されたものへのハンドルである。１つまたは複数の実施形態では、ランタイム・モデルにおいて各サービス・コール、トリガおよびページに関連付けられたアクションがある可能性がある。
【００５８】
＜＜パラメータ＞＞
Ｐａｒａｍｅｔｅｒｓエンティティは、いかなるタイプおよび数のＸＭＬエンティティを含むこともできる。これは、パラメータがいかなる形式のデータも表現できることを意味する。
【００５９】
Ｐａｒａｍｅｔｅｒはデータのためのプレース・ホルダであるが、データの構造表現のためのプレース・ホルダでもある。すなわち、各パラメータについて、システムがＸＭＬエンティティを維持し、これは許容可能なコンテンツ、およびパラメータにおけるデータのための構造（すなわち、スキーマ）を定義する。
【００６０】
パラメータの構造表現を、パラメータに関連付けられたデータが出現するよりも長く前に満たすことができる。
【００６１】
＜＜挙動＞＞
挙動（ｂｅｈａｖｉｏｒｓ） のエンティティは、アクションへのイベントのマッピングを定義する。この実施では、挙動はＰａｇｅｓにおいてのみ、コントロールを介して定義される。コントロールは、そのイベントの１つに関連付けられたアクションを識別することができる。この実施では、これらのアクションを、ｗｅｂサービス・エンジンに戻されるｗｅｂサービス要求にのみすることができる。
【００６２】
＜＜テンプレート＞＞
１つまたは複数の実施形態では、ランタイム・モデルが個別にハード・コーディングかつプログラムされる。しかし、このようなランタイム・モデルをコーディングかつ維持することは困難であり、これは関係するｗｅｂサービス（ランタイム・モデルの一部としてコールすることができるもの）の常に変化し続ける特性、および異なるユーザのためのランタイム・モデルの間で必要とされる可変性の量が高いことによる。結果として、本発明の１つまたは複数の実施形態は、ランタイム・モデルを構築するための命令を記録するシステムを提供する。これらの命令は機能と呼ばれ、これらはテンプレートと呼ばれるオブジェクトにおいて記録される。
【００６３】
テンプレートは、容易にランタイム・モデルを生成するためのメカニズムを提供し、これがＷＳＡの構造、機能性および挙動を生成あるいは宣言する。さらに、テンプレートは、単に明示的なハード・コーディングされたランタイム・モデル・ベースのサービスのためのｗｅｂサービス要求を発行するのではなく、ＷＳＡを呼び出すための強力かつ汎用のモデルを提供する。テンプレートは、ランタイム・モデルをハード・コーディングするのではなく、動的にランタイム・モデルを生成するための能力を提供する。
【００６４】
１つまたは複数の実施形態では、テンプレートが特殊なタイプのランタイム・モデル（高レベルの命令を使用して書かれたもの）であり、これが子ランタイム・モデルの動的な構成に（テンプレートによって表現されたランタイム・モデルを実行することによって）備える。上述のランタイム・モデルに類似して、子（チャイルド）ランタイム・モデルは、ＷＳＡの下にある構造を表現し、ＷＳＡに変わることができる。しかし、テンプレートおよび機能は、ランタイム・モデルとしてではなくまったく異なるフォーマットにおいて実施することができる。たとえば、１つまたは複数の実施形態では、ｗｅｂサービスがテンプレートのコンテンツを、リレーショナル・データベースからのデータのブロックとして検索することができる。したがって、テンプレートは、ランタイム・モデルを構築するための高レベル命令のセットの使用に備える中間オブジェクトである。
【００６５】
上述のように、ランタイム・モデルはパラメータを有し、これらがデータまたはデータの構造表現のためのプレース・ホルダとして利用される。テンプレートのパラメータの１つがランタイム・モデルである（子またはネストされたランタイム・モデルと呼ばれる）。そのため、テンプレートは、ＷＳＡに変換されて動作されたとき、それが実行できる別のランタイム・モデルをその内部に生成するランタイム・モデルである。
【００６６】
図１は、ＷＳＡを生成するためのテンプレートの使用を例示する。図１の実施形態では、テンプレート１００がランタイム・モデルである。しかし、テンプレート１００がランタイム・モデルではない可能性があり、この場合、ランタイム・モデル１０２はいかなるランタイム・モデルの子でもなく、単にテンプレート１００によって作成されたランタイム・モデルである。テンプレート１００によって表現されたランタイム・モデルはＷＳＡに変えられ、実行される。ＷＳＡの出力は子ランタイム・モデル１０２である。子ランタイム・モデル１０２はｗｅｂサービス・アプリケーション１０４を表現し、これを生成するために使用することができる。したがって、テンプレートはランタイム・モデルの構成を自動化する。
【００６７】
上述のように、ランタイム・モデルのパラメータ・セクションは様々なタイプのＸＭＬデータをサポートすることができる。したがって、本発明の１つまたは複数の実施形態は、子ランタイム・モデル１０２を一種の「ワーク・ベンチ」として、パラメータ・セクションの内部でネストする。さらに、ランタイム・モデルがＷＳＡの機能性および挙動を定義することができるので、本発明の１つまたは複数の実施形態はランタイム・モデル（すなわち、テンプレート１００）を使用して子ランタイム・モデル１０２を定義かつ構築し、これは、機能サービスとして知られるｗｅｂサービスへの一連のｗｅｂサービス・コールを介して行う。機能サービスは、ランタイム・モデルへの参照を入力として、他のパラメータと共に受け入れ、変換されたランタイム・モデルを出力として生成する特性を有する。別の実施形態では、子ランタイム・モデル１０２を、実際のサービスではなく「機能クリエータ」と呼ばれるコードを使用して構築することができる。機能クリエータを、たとえばサービス（たとえば、機能サービス）またはＪａｖａクラスとして実施することができる。
【００６８】
上述のように、テンプレート１００はランタイム・モデルであり、これはいくつかの特殊なタイプのデータをそのパラメータ・セクションにおいて有し、ならびにネストされたランタイム・モデル１０２を生成するいくつかのｗｅｂサービス・コールを有する。
【００６９】
テンプレートのパラメータ・セクションにおける特殊なタイプのデータは、以下のエンティティを含むことができる。
【表５】

【００７０】
図２は、テンプレート１００の構成（パラメータを含む）を例示する。ランタイム・モデル１０２は１つのパラメータである。第２のパラメータは、機能リスト２０２のものである。モデル・エンティティ／パラメータは上述のようなランタイム・モデルである。したがって、テンプレートがＷＳＡに変わったとき、ＷＳＡによって使用されたパラメータの１つがランタイム・モデルである。以下に記載するように、このランタイム・モデルはＷＳＡによって、完全な子ランタイム・モデル１０２が生成されるまで、修正される。したがって、子ランタイム・モデルは、ランタイム・モデル・パラメータを修正することによって生成される。ランタイム・モデル・パラメータは、他のパラメータ・エンティティ−機能によって提供された仕様に従って修正される。
【００７１】
図３は、テンプレートを使用したｗｅｂサービス・アプリケーションの生成を例示する。最初に、ｗｅｂサービス・エンジン３００がテンプレート・ベースのサービスのための要求を受信する。ｗｅｂサービス・エンジン３００がこの要求をモデル・ランナー３０２に送信する。モデル・ランナー３０２はランタイム・モデルをロードし、ＷＳＡを生成するように構成される。したがって、モデル・ランナー３０２はテンプレート１００をロードし、対応するＷＳＡ３０４を生成する。ＷＳＡ３０４は機能２０２を含み、これが利用されて子ランタイム・モデル１０２が修正かつ作成される。ＷＳＡ３０４は、機能２０２によって識別された機能サービスまたは機能クリエータへのコールを行い、子ランタイム・モデル１０２を生成する。次いで、モデル・ランナー３０２が利用されて、子ランタイム・モデル１０２がロードされ、これがＷＳＡ３０６に変換される。したがって、テンプレート１００が利用されてランタイム・モデル１０２が生成され、これはシステムによって利用することができるｗｅｂサービス・アプリケーションに対応する。
【００７２】
＜＜機能＞＞
テンプレート１００の機能エンティティ／パラメータは、エンティティを構築あるいは生成して子ランタイム・モデル１０２を生成するための能力を提供する。機能エンティティは機能のリストを含み、これは機能リストとして知られるものを含む。機能リストは命令セットであり、ｗｅｂサービス（再生として知られる）が子ランタイム・モデルをどのように構築するべきであるかを記述し、これは「サイド・キック」ｗｅｂサービス（機能サービスまたは機能クリエータと呼ばれる）のセットおよび入力値（機能入力パラメータと呼ばれる）のセットの使用を介して行う。
【００７３】
機能リスト２０２における機能はランタイム・モデル２０４を入力として利用し、機能がリストされる順序において実行される。各機能は、入力として使用された既存のランタイム・モデル２０４を修正あるいは変更することができる。この実行プロセスは再生と呼ばれる。標準プログラムの代替物として、再生プロセスをＷＳＡの形式（以下で詳細に記載する）にすることができる。再生プロセスは、ネストされたランタイム・モデル１０２のコンテンツを、機能リストにおいて各機能について定義される入力パラメータに基づいて生成する。図４は、本発明の１つまたは複数の実施形態による再生プロセスを例示する。再生ＷＳＡ４００が機能リスト２０２およびランタイム・モデル２０４を入力として利用して、変換されたランタイム・モデル１０２を生成する。
【００７４】
１つまたは複数の実施形態では、再生プロセスを、テンプレートの作成において即時に実行することができる。再生プロセスをこのようなときに実行することによって、ランタイム・モデルを、ｗｅｂサービスが動作するように要求されたときに生成する必要がない。しかし、このシナリオでは、完成されたランタイム・モデルを永続メモリに格納しなければならない。他の実施形態では、再生プロセスが、ｗｅｂサービスが動作するように要求されたときに、動的に実行される。再生プロセスをこのようなときに実行することによって、ユーザがより十分に、機能によって参照されるいかなるｗｅｂサービスも最新バージョンのサービスであること、および、利用されたいかなる入力／出力スキーマ・データも最新データであることを確信することができる。しかし、モデルまたはＷＳＡを動的に生成することによって、処理時間が長くなる可能性がある。
【００７５】
機能（ｆｅａｔｕｒｅ） は、２つのコンポーネント、すなわち機能ユーザ・インターフェイス・テンプレートおよび機能サービスからなる。機能ユーザ・インターフェイス・テンプレートは、入力をユーザまたは他のアプリケーションから得ること、および、機能ブロックを機能リストにおいて構築し、続いて維持することを担う。ユーザにより機能ユーザ・インターフェイス・テンプレートに供給された入力が、機能ブロックにおいて識別された機能サービスのための入力パラメータの作成において利用される。機能サービスは、ランタイム・モデル１０２において機能パラメータに基づいてエンティティを生成する作業を実行する。１つまたは複数の実施形態では、機能ユーザ・インターフェイス・テンプレートが入力をユーザから得て、次いで機能ブロックを生成する。このデータのブロックは順次機能リストに配置される。機能ブロックは、入力パラメータ、およびランタイム・モデル・エンティティを構築する作業を行う機能サービスの名前を含む。１つまたは複数の実施形態では、ユーザが機能ＵＩテンプレートに供給する入力が、ＵＩテンプレートが機能ブロックに入れるものと同じでない可能性がある。たとえば、１つの機能においては、ＵＩテンプレートがユーザからリレーショナル・データベース・テーブルの名前およびクエリーを行う列についての入力を取り、次いでこれらをＳＱＬ（構造化照会言語，ｓｔｒｕｃｔｕｒｅｄ ｑｕｅｒｙ ｌａｎｇｕａｇｅ） データ入力として機能ブロックに書く。そのため、機能ＵＩテンプレートが、入力における変換を、これらを機能ブロックに配置する前に実行することができる。ユーザが機能を修正した場合、機能ＵＩテンプレートが逆マッピングも実行して機能ブロック入力を取り、これらをＵＩへ、ユーザが修正するためにマップし戻す。
【００７６】
テンプレートにおける各機能がＸＭＬデータのブロックによって表現され、これは、機能のための入力パラメータ値のセット、および、機能入力値を使用してランタイム・モデル２０４をランタイム・モデル１０２に変換するための作業を実行する機能サービスの名前を定義する。各機能サービスが効果的にランタイム・モデル２０４をその入力の１つとして取り、変換されたランタイム・モデル１０２をその出力として生成する。図５は、変換されたランタイム・モデル１０２を作成するための機能および機能サービスの使用を例示する。機能１のための機能ユーザ・インターフェイス・テンプレートは、機能１入力パラメータ５００を得ることができる。機能サービス１は機能１入力パラメータ５００およびランタイム・モデル２０４を利用して、変換されたランタイム・モデル１０２を生成する。次いで、機能サービス２が、変換されたランタイム・モデル１０２および機能２入力パラメータ５０２を入力として利用して、新しい変換されたランタイム・モデル１０２を生成する。機能リストにおける各機能に対応する機能サービスが、変換されたランタイム・モデルを、機能入力パラメータとの組み合わせにおいて処理して、最終的な子ランタイム・モデル１０２を生成する。
【００７７】
機能サービスが順次実行されるので、各機能サービスが、変換されたランタイム・モデルを全体として望むように修正することができる。したがって、各機能は、動的に既存のランタイム・モデルを調べ、このモデルをランタイム・モデルの存在、不在または状態に基づいて修正するための能力を有する。このような能力は、プログラムがハード・コーディングされ、個別のユニットのみを既存のプログラムとは独立して修正することしかできない通常のプログラミングに勝る、著しい利点を提供する。加えて、ハード・コーディングされたプログラムは動作することしかできない。実行中に、ハード・コーディングされたプログラムは、その挙動を変更する手段として、環境に対して反応することしかできない。テンプレートでは、機能がプログラムをその動作前に構築する。したがって、プログラムは別のレベルの適合を有し、これがプログラムに、その動作の前に注入され、あるいはそれにおいて同期化される。したがって、機能は既存のランタイム・モデルのいかなる態様も修正することができ、１つの機能が、いかなる実行前の機能の効果も、望むなら反転させることができる。
【００７８】
単純な機能の一例が、インポートされたページ機能（ランタイム・モデルにおけるＰａｇｅエンティティのＨＴＭＬバックグラウンド・コンテンツを構築するもの）である。この機能は機能入力パラメータを有し、これは、インポートされたページのコンテンツのための基本または開始ポイントとして機能するページへのＵＲＬを指定するためのものである。たとえば、機能ユーザ・インターフェイス・テンプレートはＵＲＬをユーザまたは他のサービスから要求することができる。ＵＲＬが得られた後、機能ユーザ・インターフェイス・テンプレートがＵＲＬを機能サービスへ、さらなる処理のために転送することができる。別法として、機能ＵＩテンプレートが機能ブロックを書くことができ、これは、機能サービスに渡されることを再生サービスが保証するデータを含む。上述のように、指定されたＵＲＬに位置するページを、機能サービスへの入力として利用することができ、これが最終的にエンド・ユーザへの伝送用のページを生成する。この機能は、インポートされたＵＲＬコンテンツを使用するランタイム・モデルにおいて構築するべきページ数を指定するための入力も有する。その２つの入力のために供給された値に基づいて、ランタイム・モデルにおいてインポートされたページを構築する機能サービスは、正しい数のページ・エンティティをランタイム・モデルにおいて生成し、ページが、（現在の機能の前の機能によって）ランタイム・モデルにおいて構築されている他のエンティティに関して一意のＩＤを有することを保証する。
【００７９】
１つまたは複数の実施形態では、１つまたは複数の機能が静的なＨＴＭＬドキュメントを入力として（たとえば、ＵＲＬによって指定されたようなもの）有することができ、ランタイム・モデルからの出力はサービス使用可能なｗｅｂページである。サービス使用可能なｗｅｂページは、エンド・ユーザ／閲覧者がドキュメントのある部分を選択することによってサービスを呼び出すことを許可することができる。たとえば、表がｗｅｂページ上に表示された場合、ユーザは、表における項目をソートするための列を選択することができる可能性がある。このようなアクションが、選択された入力（たとえば、選択された列の値）に基づいて情報をソートする能力を有するｗｅｂサービスを呼び出すことができる。別法として、ユーザが表の特定の行を選択し、その行に関係するより詳細な情報を得ることができる可能性がある（たとえば、行が従業員および従業員の給与を表した場合、その行をクリックすることにより、その従業員に関係するより詳細な情報を生成することができる）。所望のアクションをｗｅｂサービスの一部として完了するには、あるいはｗｅｂページをサービス使用可能にするには、１つまたは複数の機能を利用する必要がある可能性がある。各機能は１つまたは複数のエンティティからなる。
【００８０】
機能エンティティは、たとえば以下のエンティティからなり得る。
【表６】

【００８１】
ＦｅａｔｕｒｅＳｅｒｖｉｃｅＩＤエンティティは、この機能のためのランタイム・エンティティを構築する作業を、再生プロセス中に実行する機能サービスの名前である。
【００８２】
ＦｅａｔｕｒｅＭｏｄｉｆｙＴｒｉｇｇｅｒエンティティは、Ｆｅａｔｕｒｅ　Ｓｅｒｖｉｃｅに供給される入力値を収集するためのＵＩを提供するテンプレートの名前である。このＵＩが呼び出されるのは、ユーザが最初に機能をテンプレートにおいて作成したとき、ならびにユーザが、機能に供給された入力値のいくつかを変更することを望んだときである。
【００８３】
ＦｅａｔｕｒｅＩｎｐｕｔｓエンティティは、機能の入力パラメータのための値割当て情報を含む。この情報を、定数値、またはランタイム・モデルにおける他のパラメータの値への参照の形式において供給することができる。
【００８４】
１つまたは複数の実施形態では、機能が単に、機能サービス、および、エンティティをランタイム・モデルにおいて構築するための機能サービスを可能にする入力パラメータのセットを識別するテンプレートにおけるメタデータのブロックである。
【００８５】
別法として、１つまたは複数の実施形態では、機能エンティティが、たとえば以下のエンティティからなり得る。
【表７】

【００８６】
ＦｅａｔｕｒｅＣｌａｓｓｎａｍｅエンティティは、この機能のためのランタイム・エンティティを構築する作業を、再生プロセス中に実行する機能クリエータの名前である。
【００８７】
ＦｅａｔｕｒｅＭｏｄｉｆｙＴｅｍｐｌａｔｅエンティティは、機能クリエータに供給される入力値を収集するためのＵＩを提供するテンプレートの名前である。このＵＩが呼び出されるのは、ユーザが最初に機能をテンプレートにおいて作成したとき、ならびにユーザが、機能に供給された入力値のいくつかを変更することを望んだときである。
【００８８】
＜＜機能選択＞＞
ユーザは、テンプレート・オーサー・アプリケーションを使用することによって作成のための機能を選択することができる。１つまたは複数の実施形態では、テンプレート・オーサー・アプリケーションは、ユーザが単に所望の機能を選択し（例えば、カーソルが所望の機能上に配置されているときにマウス・ボタンをクリックすることにより）、その機能をテンプレート内にドラッグ・アンド・ドロップすることを可能にする。そのような実装形態は、ユーザ・インターフェース機能およびドラッグ・アンド・ドロップ機能を生成するＷＳＡによって提供され得る。そのような実施形態のユーザ・インターフェースは、ユーザがそれを介して、テンプレート内に機能を入れるのに使用する機能入力パラメータを供給する機構を提供することができる。テンプレート・オーサー・アプリケーションは、入力値をとり、テンプレートの機能セクション内に機能メタデータ・ブロックを書き込む。
【００８９】
図６は、本発明の１つまたは複数の実施形態によるテンプレート内で使用する機能の選択を示している。テンプレート６０４内に配置するための機能を選択するには、ユーザは、テンプレート作成者（オーサー）アプリケーション６０２内の機能タイプのリストから機能を選択する。システムは、特定の機能に関する入力値を得るためにユーザと対話するための適切なＵＩを生成するように設計されたテンプレート・ベースのウェブ・サーバを起動する。「機能編集」ＵＩ６００として知られるこのＵＩは、ユーザから機能の入力パラメータに関する値を得ることを担う。これらの値は、ユーザによって供給された明示的値（数「１２３」または「ｈｔｔｐ：／／ｗｗｗ．ｂｏｗｓｔｒｅｅｔ．ｃｏｍ」のようなＵＲＬのような）であることが可能であり、あるいはランタイム・モデル内のエンティティに対するユーザ供給されるリファレンス（「１２３」のような数またはＵＲＬを含むパラメータ「ｐｄｑ」に対するリファレンスのような）であることが可能である。
【００９０】
リファレンスの使用の一実施例は、ボタン機能の場合である。ボタン機能に対する入力パラメータのうちの１つは、このボタンがそこに追加される一組のページである。ユーザは、特定のページを名前で参照すること、あるいは「すべて」などのキーワードを特定することができる。ボタン機能は、機能入力パラメータとして供給される値に応じて、正しい数のボタンを正しい数のページ上に構築することができる。
【００９１】
ユーザが機能編集ＵＩ６００に値を供給し終わると、機能編集ＵＩ ＷＳＡ６００は、機能ブロックと呼ばれる１つのブロックのＸＭＬデータを編集中のテンプレート６０４内に書き込む。機能編集ＵＩは、このブロックのデータを編集中のテンプレート６０４内のパラメータの機能セクション６０６内に、テンプレート６０４内に既に存在する最後の機能の後に書き込む。
【００９２】
ユーザがテンプレート・オーサーＷＳＡに新しい機能の作成プロセスを開始するように指示する仕方は、ＷＳＡ内のアクションを実行するウェブ・サービス要求を行う（テンプレート・オーサーＵＩ内の機能上でクリックする）ことによってである。このアクションは、特定の機能編集ＵＩテンプレート６００に関するテンプレート・ベースのウェブ・サービスを起動する。このテンプレート・ベースのサービスは、ユーザから入力を得るためにそれ自体のＵＩを生成し、また最終的に、機能入力値をそれに指示し、テンプレート・オーサーＷＳＡが機能メタデータ・ブロックを作成できるようにするテンプレート・オーサーＷＳＡ６０２内のアクションを呼び出す。
【００９３】
機能ＵＩテンプレートとテンプレート・オーサーＷＳＡが合同で機能ブロックを書き込んだ後、テンプレート・オーサーＷＳＡ６０２は、再生成ウェブ・サービスを起動する。おのウェブ・サービスは、テンプレート内に書き込まれたばかりの機能ブロックと関連する機能サービスを実行する。（再生成は、機能リスト６０６内の機能に対応する機能サービス６１０のすべてを実行するのを担うことを留意されたい。）機能サービス６１０は、その入力パラメータ値をランタイム・モデル６０８（機能サービスはこれを分析し、判断を下す基準として使用することができる）とともに使用して、変換されたランタイム・モデルを生成する。
【００９４】
機能は、ランタイム・モデルを変換するプロセス・ステップのうちの１つをキャプチャする。テンプレート内の一組の機能は、ウェブ・サービス・エンジンによるＷＳＡへのインスタンス化の準備が整ったランタイム・モデルに空のランタイム・モデルを変換するのに必要な一連の変換の全体を協働して定義する。
【００９５】
機能の一特性（プロパティ）は、アプリケーション開発者によって通常、手動で行われる一組のプロセス・ステップの実行をキャプチャし、自動化することである。従来のアプリケーション開発ツールは、開発者の設計意図をキャプチャすることができない明示的モデリング手法、ならびにアプリケーションを構築する際に行われるプロセス全体をサポートする。Ｊａｖａ開発製品およびＣ＋＋開発製品を含む従来のツールは、手動設計プロセスの最終結果を表すデータ（すなわち、ソース・コード）をキャプチャする。このため、従来のアプリケーションは、構築するのに時間がかかり、変更するのが困難である。開発者は、変更を行うのにコードを削除し、新しいコードを作成しなければならない。開発者は、変更が完全に伝播されるのを確実にすることを担う。従来のアプリケーション編集ツールは、アプリケーションが壊れているかを判定するのを助けることができ、アプリケーションを分解工学してその問題を診断しようと試みることができる。ただし、アプリケーションの構築がそれに従って行われた製法の記述はないので、その製法の記述からアプリケーションを再生成する簡単な手段は存在しない。
【００９６】
本発明の１つまたは複数の実施形態によれば、機能は、ランタイム・モデルだけではなく、どの型のＸＭＬもでの構築にも適用することができる。例えば、ＸＭＬベースのメッセージを構築するために、一組の機能を作成することができる。
【００９７】
機能の一特性は、モデル内のエンティティに対する参照である機能入力値を有するのが可能なことである。この特性により、機能は、モデルにエンティティを追加するだけでなく、エンティティを「過去のもの」としてマーク付けすることもできる。機能は、それが適用されるモデルに非常に深い変換をもたらすことができる。
【００９８】
＜＜機能再生成＞＞
前述のとおり、再生成プロセスは、テンプレート内に特定された機能に基づいてＷＳＡを作成する。機能再生成ウェブ・サービスは、機能リストおよびランタイム・モデルに対して動作する。完全な再生成は、ゼロからランタイム・モデルを再構築することに関わり、他方、部分的再生成は、機能のいくつかだけのためにランタイム・モデルを変更することに関わる。例えば、本発明の１つまたは複数の実施形態は、ある状況でいくつかの機能の使用を提供することができ、また別の状況では、別の一組の機能の使用を提供することができる（両組の機能は、同じテンプレート内に存在している）。
【００９９】
再生成サービスは、機能サービスを実行したとき、ランタイム・モデルをサービス内に通し、それがランタイム・モデル内のエンティティを参照できるようにする。各機能サービスは、エンティティを追加する能力を有している。１つまたは複数の実施形態は、ランタイム・モデルが単一のＸＭＬ文書に広がることができるようにする。他の実施形態では、機能サービスは、ひとまとまりＸＭＬ文書全体に広がるランタイム・モデル内のエンティティを構築する。
【０１００】
１つまたは複数の実施形態では、再生成サービスは、新しいモデルを構築する一方で、古いランタイム・モデルのコピーを維持しない。ただし、他の実施形態では、再生成プロセスが失敗した場合、再生成サービスが元のランタイム・モデルを戻せるように、古いランタイム・モデルが記憶される。さらに、ランタイム・モデルのバックアップ・コピーにより、新しいモデルが再生成される際に、それを古いモデルと比較できるようにすることが可能となり得る。
【０１０１】
１つまたは複数の実施形態では、再生成サービスは、過去の再生成と比較して、現在の再生成中にランタイム・モデルから除去されたＸＭＬエンティティの「転送アドレス」リストを維持する。機能サービスが、前回、生成したのとは異なるエンティティを再生成し、作成する場合には、新しいエンティティに対する古いエンティティのマッピングが転送アドレス・リストに追加される。除去されたエンティティを参照する可能性がある後の機能サービスは、再生成サービスによって「救助」されることが可能である。再生成サービスは、転送アドレス・リストを使用し、その参照を新しいエンティティに向けて自動的に「曲げる（ｂｅｎｄ）」ことができる。
【０１０２】
本発明の１つまたは複数の実施形態は、各エンティティを作成した機能のマッピングを維持する。これにより、いくつかのウェブ・サービスがランタイム・モデルをより効率的に扱うことができるようになる。例えば、機能リストの真中で、ユーザが機能リストを編集しようと所望するとき、システムは、編集された機能リストの後に、機能リストによって生成されたすべてのエンティティを即時に探し出すことができる。システムは、この情報を使用し、その後に作成された機能リスト内で、ユーザが参照目的でエンティティを選択するのを防止する。この参照が行われるのを防止することにより、エンティティがまだ機能リスト再生成プロセスで作成されていないために、機能リストがそのエンティティを参照できないことによって引き起こされる不必要な再生成の失敗をシステムは防止する。
【０１０３】
＜＜テーブル機能リスト＞＞
本発明の１つまたは複数の実施形態は、様々な機能リストの利用を提供する。例えば、１つまたは複数の実施形態によれば、テーブル機能リストを利用することができる。
【０１０４】
テーブル機能リストは、ページ内でＸＭＬデータを表示するテーブルを作成する。そのような機能リストにより、ユーザは、そのテーブルをページ内の名前の付いたエンティティにバインドできるようにすることが可能である。このエンティティは、空のタグ、またはグラフィカル形式設定を定義するテーブルであることが可能である。
【０１０５】
１つまたは複数の実施形態では、テーブル機能リストは、以下の入力のうちの１つまたは複数を利用する。ｗｈａｔページ、ｗｈａｔプレースホルダ（ページ内の名前付きタグ）、および表示するｗｈａｔ ＸＭＬパラメータ。
【０１０６】
機能リストは、列名としてラベルのヘッダを有する行形式のＸＭＬデータを表示するページ内のテーブルを作成する。ユーザが、このページ上で「ページ」アクションを活動化したとき、テーブル・データがテーブル内で表示することになり、これは、名前付きタグ内容内で定義されている任意の形式設定による（すなわち、＜ＴＤ＞タグおよび＜ＴＲ＞タグの形式設定）。
【０１０７】
＜＜アクティブ列機能リスト＞＞
１つまたは複数の実施形態では、「アクティブ列機能リスト」と呼ばれる機能リストを利用することができる。アクティブ列機能リストは、静的な表示列（例えば、テーブル機能リストによって作成された）をアクティブ列に変換する。したがって、列のセル内容は、ＷＳＡの制御下にある。列は、アクションを起動するボタンを含むことができ、あるいはリンク、チェックボックス、またはテキストフィールド等を表示することができる。ユーザは、制御および挙動を特定する。例えば、ユーザは、列内にボタンを入れ、サービス・コールを行うために特定のテーブル行値にアクセスするファンクションに対するコールをクリック・アクションに活動化させることができる。
【０１０８】
１つまたは複数の実施形態では、アクティブ列機能リストは、以下の入力のうちの１つまたは複数を利用する。ｗｈａｔテーブル、ｗｈａｔ列名（これは位置を特定することによる新しいものであり得る）、ｗｈａｔ列エンティティ（ボタン、クリック可能リンク、隠し、チェックボックス、テキストフィールド等）。
【０１０９】
アクティブ列機能リストは、静的列をパラメータ化され、制御された列に変換する。この機能リストは、コントロールを列内に入れ、元の内容をその名前のようなコントロールの何らかの特性にマップすることができる。また、この機能リストは、ボタンのクリック動作を定義するなどの列上の動作も構築する。
【０１１０】
＜＜可視性制御／ＵＩ制約機能リスト＞＞
１つまたは複数の実施形態は、可視性制御機能リスト（ＵＩ制約機能リストとも呼ばれる）を提供する。ＵＩ制御機能リストは、サーバ上の推論エンジンを利用するウェブ・サービスに対する１つまたは複数のサービス・コールを構築する。推論エンジンは、一組のパターンを維持し、ＵＩに対する更新を起動するようなことを、そのＵＩ内でユーザが行ったか否かを検査するプロセスを管理する。
【０１１１】
動作カテゴリ内の多くの機能リストは、推論エンジンのユーザであることになる。ＵＩコントロールの可視性からファンクションの呼出しに至るすべてを行うアクションに、モデル内の状態変化の様々な組み合わせをリンクすることができる。
【０１１２】
推論（ｉｎｆｅｒｅｎｃｅ） エンジン・ベースのウェブ・サービスに対するコールを生成する機能リストは、ユーザから入力を受け取り、再生成の一環として、モデル・ランタイム・オンロードに推論エンジン・サービス内に通される規則定義入力パラメータを構成する。また、これらの機能リストは、イベントにバインドされた更新アクションの形で、モデルに動作を追加する。このアクションは、推論エンジンに、モデルの状態に対する重要な変更を知らせる。推論エンジン・サービスは、モデルの状態を変更し、様々なアクションを呼び出すことによって応答することができる。
【０１１３】
例えば、ユーザが、５０の状態のうちの１つまたは複数を自分が選択できるようにするドロップ・ダウン・リスト・コントロールを作成したものと想定する。さらに、このユーザが、はい／いいえのオプション、および「あなたのドライバのなかにメキシコ人はいますか？」というラベルを有するチェックボックス・コントロールを構成したものと想定する。
【０１１４】
次に、ユーザは、ＵＩ制御機能リストを構成する。この機能リストは、ユーザに制約の性質に関する質問をする。ユーザは、州＝ＣＡまたはＴＸであるとき、メキシコ人ドライバ質問チェックボックスが可視でなければならず、それ以外のときは、そうではないことを示す。
【０１１５】
この機能リストは、ランタイム・モデル内に適切なエンティティを構築することによって、残りのことを処理する。この機能リストは、「推論エンジン・ロード」サービスに対するコールを構築し、そのアクションをオンロード機能に追加する。この機能リストは、新しい規則（州＝ＣＡ、ＴＸ−＞チェックボックス可視、そうでなければ、逆）の構文を書き、このサービスに対する入力にそれを付加する。次に、この機能リストは、Ｓｔａｔｅ Ｄｒｏｐｄｏｗｎ上で「Ｏｎ Ｖａｌｕｅ Ｃｈａｎｇｅ」イベントに、「推論エンジン更新」に対するコールをバインドする。次に、ユーザが状態値、およびコントロールから出るタブを変更したとき、ブラウザが、推論エンジン・サービスにその変更を知らせ、推論エンジンがチェックボックスの可視性ステータスに対する何らかの変更を行い、ページ・アクションを行うことができるようにすることになる。したがって、推論エンジンは、州の値（例えば、州が、カリフォルニアまたはテキサスからミネソタに変更されたとき）ことを知り、メキシコに関する質問を表示しないのを知ることになる。
【０１１６】
ＵＩ制約機能リストは、個々のコントロール、複数のコントロール、またはいくつものコントロールを制御するＤＩＶタグのようなものの可視性に対する制御を提供することができる。さらに、この機能リストは、許容可能な値の範囲、および値のリストに対する制御を提供することができる。
【０１１７】
＜＜ＸＭＬ変換機能リスト＞＞
本発明の１つまたは複数の実施形態は、ブロックのＸＳＬ命令を含む別のタグ付きデータ・オブジェクトを使用して、ＸＭＬタグ付きデータ・オブジェクトの変換を行うバーサタイル・サービスを提供する。このサービスは、変換されたデータを表す変換されたタグ付きデータ・オブジェクトを出力する。このサービスは、ＬｏｔｕｓＸＳＬと呼ばれるＩＢＭからのものなどの標準ＸＭＬおよびＸＳＬアクション・エンジンをラップすることになる。
【０１１８】
さらに、１つまたは複数の実施形態は、一般に、タグ付きデータ・オブジェクト・パラメータに対する参照を含む入力をユーザから受け取り、ＸＳＬのブロックを書き込み、ＸＳＬプロセッサ・サービスに対するコールを書き込む、いくつかの機能リストを構成する。
【０１１９】
一実施例として、列フィルタリング機能リストが、結果セットを選択するようにユーザに求め、次に、その結果セットの構造表現（スキーマ）からフィルタリングすべき（含める）一組の列を選択するようにこのユーザに求めることが可能である。この機能サービスは、ＸＳＬプロセッサ・サービスに対するサービス・コールを書き込み、ブロックのＸＳＬデータをパラメータの形で変換のための命令として書き込み、またＸＭＬデータを入力とし、ＸＳＬパラメータを変換ロジックとして割り当てるファンクションを書き込み、そのサービスを呼び出す。
【０１２０】
再生成で、そのような機能サービスは、ＸＭＬ変換サービスが呼び出されたとき、ランタイムで実行されるＸＳＬブロックを動的に構築する。
【０１２１】
このＸＳＬプロセッサ・サービスは、ＸＳＬブロックを書き込み、割当てを行い、またこのサービスのアクションを呼び出すいくつかの機能リストに関するワーク・ホースとして働く能力を有する。１つまたは複数の実施形態では、サービスは、２つの異なるタグ付きデータ・オブジェクトをマージしようとした機能リストによって使用されることが可能である。そのような機能リストは、２つのタグ付きデータ・オブジェクトを単一の入力ＸＭＬオブジェクトに「集中」させ、次に、データのマージング（インター・スプライシング）をＸＳＬロジックに実行させることができる。
【０１２２】
＜＜サンプル・テンプレート＞＞
以上の説明によれば、本発明の１つまたは複数の実施形態は、セルラー電話（携帯電話）カタログ・システムを提供することができる。セルラー電話機カタログ・システムは、ある製造業者から入手可能な電話機を表示するのに役立つことが可能であり、表示された電話機のうちの１つの上でクリックすることにより、選択された電話機に関する詳細な情報を提供する。例えば、ユーザには、図７Ａの表示７００が提示されることが可能である。「詳細」ボタン７０２のうちの１つを選択することにより、ユーザには、図７Ｂの表示７０４として対応する行内にその電話機の詳細な説明が提示される。本発明の１つまたは複数の実施形態は、機能性を構成し、図７Ａおよび７Ｂに示すとおりその結果を表示する能力を提供する。
【０１２３】
例示の目的で、以下の説明は、「セルカタログ」テンプレート（本発明の１つまたは複数の実施形態により利用されるテンプレート）の部分が、既に作成されているものと想定する。例えば、テンプレートは、いくつかのサービス・コールおよび入力ページ上のテーブル内でＸＭＬセル電話機カタログを提示するＵＩ制御機能リストを既に有するものと想定する。テンプレート内で提供される基本的機能性には、セル電話機ＸＭＬデータ・ソースを開き、ＸＭＬ変換サービスを使用してそのデータ・ソースをカタログに変換する能力が含まれる。さらに、機能性には、セル電話機ブランド名リストをＸＭＬデータから抽出し、その情報をドロップ・ダウン・リスト７１０内に提示して、ユーザがブランドを選択し、ブランドによってセル電話機カタログをフィルタリングできるようにする能力が含まれる。したがって、既存のテンプレートは、詳細ボタン７０２を含む製品情報列なしに、静的ＨＴＭＬページ（セルラー電話機の特定のブランドを選択して表示する能力を有する）の表示を提供する。
【０１２４】
説明した実施形態の目的は、製品仕様サービス（例えば、詳細な製品説明表示７０４を得るための）をシステムに呼び出させるテーブルにアクティブ列のボタンを追加することである。このサービスは、ウェブ・サービス・ディレクトリ内で公表されている。このサービスは、テーブル内の選択された行によって識別された製品に関する詳細な製品仕様を戻す。ユーザがテーブル行内の詳細ボタン７０２を押したとき、ＷＳＡがそのサービスを呼び出し、行特定情報をそのサービス・コールに入れ、次に、別個のページ上で出力データ７０４を提示する。
【０１２５】
１つまたは複数の実施形態によれば、既存のテンプレートを編集するため、テンプレート・オーサー・アプリケーションを使用してテンプレートを開く。図８は、テンプレート・オーサー・アプリケーションの「テンプレートを開く」スクリーン８０２からのセルカタログ・テンプレート８００の選択を示している。
【０１２６】
図９は、オープン・セルカタログ・テンプレート８００を示している。表示７００は、このテンプレートからの出力の現在のビューを示している。表示９００は、セルカタログ・テンプレート８００内の機能リストの現在のリストを示している。
【０１２７】
＜＜既存する機能リスト＞＞
テンプレート８００の既存する機能リスト（表示９００内に表示される）は、本発明の１つまたは複数の実施形態に従って構成することが可能である。第１の既存する機能リストは、「ユーザ・プロファイルを得る」サービスに対するサービス・コールである。このサービスは、そのテンプレート内の他の機能リストによって参照されることが可能なそのサービス出力内のいくつかのＸＭＬエンティティを提供する。これには、ユーザの名前ｄｓｍｌ：ｇｉｖｅｎｎａｍｅ、ｍｅｍｂｅｒｓｈｉｐ：ＭｅｍｂｅｒＬｉｓｔ／ｄｓｍｌ：ｄｎ、ｍａｉｌ ａｄｄｒｅｓｓ等に関する情報が含まれる。
【０１２８】
第２の既存する機能リストは、ランタイム・モデルが実行されたときオンロード機能性を定義するファンクションである。この機能リストは、一連のサービス・コール・アクション、および最初のページを生成する最後のページ・アクションを定義する。テンプレート内の他の機能リストは、この機能リストが参照するサービス・コール・アクションを作成することを担う。このシーケンスは、「ユーザ・プロファイルを得る」、「変換をロードする」、「カタログをロードする」、「カタログを変換する」、「ブランド選択」、「電話機選択」、および開始ページである「ページ・アクション・セル電話機データを実行する」である。
【０１２９】
第３および第４の既存する機能リストはともに、「ＸＭＬファイル・リーダ」サービスに対するサービス・コールである。第３の既存する機能リストは、ＸＭＬファイルからＸＭＬカタログをロードし、他方、第４の既存の機能リストは、ＸＳＬ文書をロードする。
【０１３０】
第５の既存の機能リストは、「ＸＳＬ変換サービス」に対するサービス・コールである。この機能リストは、第３の機能リストおよび第４の機能リストからのＸＭＬカタログおよびＸＳＬ文書のサービス出力を入力としてこのサービス・コールに割り当てる。このサービスは、入力カタログからの特定の抽出されたデータを含む新しいＸＭＬ文書を構築する。このデータのいくらかは、属性からエンティティに、またその逆に変換される。
【０１３１】
第６の既存する機能リストは、「インポートされたページ」である。この機能リストは、入力としてＵＲＬの名前をとり、インポートされたＨＴＭＬ内容を含むランタイム・モデル内でページ・エンティティを構成する。このページ内容は、再生成時にインポートされ、参照の目的で他の機能リストの利用に供される。
【０１３２】
第７の既存する機能リストは、テーブルである。この機能リストは、インポートされたページ内の名前付きエンティティに対するリファレンスをとり、ＨＴＭＬテーブルを構築する。さらに、この機能リストは、ランタイム・モデル内の別のサービスからのサービス出力をテーブルの本文となるように割り当てる。ここで行われるのは、ＸＳＬ変換サービスがデータを抽出し、それをテーブル形式で提示し、次に、別のサービスがそのテーブル・データをフィルタリングすることである。このサービス・コール（機能リスト１１）からの出力が、テーブル内に入れられるものである。この結果、抽出され変換されたセル電話機カタログ・データが、インポートされたページ上に表示される。
【０１３３】
第８の既存する機能リストは、テーブルのヘッダを表すエンティティの固定リストを含むパラメータである。この情報は、ＸＳＬ変換サービスに対するサービス・コール機能リストに対するより強力な代替案としての役割をする異なる機能リストによって自動的に作成されることが可能である。そのような機能リストは、データ抽出機能リストと呼ばれる。この機能リストは、ＸＳＬ変換サービスに対するサービス・コールを構築するだけでなく、ＸＳＬデータ、およびサービス出力パラメータのスキーマを書き込むこともする。そのような機能リストは、それがＸＳＬを書き込んでおり、したがって、そのサービスからのＸＭＬ出力データがどのような構造となるのか知っているため、これらのアクションを行うことができる。この場合、出力データの構造は、パラメータ・機能リスト内に手動で符号化されたテーブル・ヘッダ名である。
【０１３４】
第９および第１０の既存する機能リストは、インポートされたページ内のエンティティを構成するＵＩコントロールである。詳細には、それらの機能リストは、「電話機を示す」ボタンおよび「製造業者を選択する」ラベルである。
【０１３５】
第１１の既存する機能リストは、「ＸＭＬテーブル・データをフィルタリングする」サービスに対するサービス・コールである。このサービス・コールは、「電話機を選択する」という名前が付いている。このサービスは、フィールド・リストおよび試験値を使用してＸＭＬテーブルをフィルタリングする。この機能リストは、ＸＳＬ変換サービスからの出力を入力としてフィルタ・サービスに割り当てる。さらに、この機能リストは、特定のブランドに関するセル電話機を探し出すのに使用する試験値として、フィルタフィールド選択コントロール（機能リスト１４）からの値を割り当てる。
【０１３６】
第１２の既存する機能リストは、電話選択アクション（機能リスト１１）、およびセル電話データ・ページ・アクション（機能リスト６）を呼び出すファンクションである。このファンクションの意図は、２つのアクションをグループ化し、ユーザが「電話機を示す」ボタンを押したとき、それらのアクションが順に呼び出され得るようにすることである。
【０１３７】
第１３の既存する機能リストは、「ユーザ・プロファイル・データを得る」サービスによって生成されたｄｓｍｌ：ｃｎサービス出力から、その値を得ることである。ユーザ・プロファイルに依存して、このテキスト・フィールドは、ユーザの名前を示すように更新される。
【０１３８】
第１４の既存する機能リストは、選択コントロールである。この機能リストは、ＸＭＬ電話機カタログから抽出された電話機ブランドのリストを表示するインポートされたページ内でコントロールを構築する。このリスト内で選択されたアイテムは、「電話機を選択する」サービス・コール（機能リスト１１）によって使用される。
【０１３９】
第１５および第１６の既存する機能リストはそれぞれ、サービス・コールおよびパラメータである。このサービス・コールは、ＸＳＬ変換サービスに対するものである。この機能リストは、「ブランドを示す」パラメータ内で供給されるブロックのＸＳＬとともに、ＸＭＬ電話機カタログを入力として割り当てる。このサービス・コールは、そのサービス出力内で電話機ブランドのリストを生成する。この出力データは、フィルタリングすべき電話機のリストをユーザに提示するため、フィルタフィールド選択コントロールによって参照される。
【０１４０】
＜＜新しい機能リスト＞＞
ボタンの列、および詳細ボタン７０２のうちの１つの選択からもたらされる表示を使用可能にするため、本発明の１つまたは複数の実施形態が、様々なステップを介して、いくつかの機能リストの作成／選択を提供する。
【０１４１】
１．図８を参照すると、第１のステップは、前述のとおり、テンプレート・オーサー・アプリケーション内でセルカタログ・テンプレート８００を開くことである。テンプレート・オーサー・アプリケーション内で、ユーザには、ＬＤＡＰディレクトリ内に記憶された一組のテンプレート８０４、およびファイル（．ｔｐｌ）内に記憶されたテンプレート８０６が提示される。
【０１４２】
２．図９を参照すると、プレビュー・ボタン９０２を選択したとき、再生成されたランタイム・モデルが表示７００内に表示される。図９に表示された再生成されたランタイム・モデルは、結果の実行ＷＳＡによって表示されることになるものを示す。ユーザは、ドロップ・ダウン・リスト７１０から電話機ブランドを選択し、プレビュー・ペイン内で「電話機を示す」ボタン７０８を押して電話機リストをフィルタリングできることを留意されたい。
【０１４３】
３．次のステップは、そうでなければ静的なテーブルの第１の列として、アクティブ列の機能リストを追加することである。１つまたは複数の実施形態では、アクティブ列の機能リストは、機能リストパレットから「アクティブ列」を選択することによって作成される。図１０は、「アクティブ列」機能リストＵＩテンプレート１０００をそれが開かれた後の形で示している。次に、ユーザは、様々な設定に関する値を特定する。例えば、表示１０００に示されるとおり、この設定には、以下のものが含まれる可能性がある：列がテーブル名設定１００２でテーブルに入る；列の位置が、列表示位置設定１００４で列１として識別される；列の型（ボタン、チェックボックス等）が、設定１００６でボタンとして設定される；ボタンの押下したときのアクションが、設定１００８の「オンロード」である；設定１０１０のボタン名「詳細」。
【０１４４】
４．「アクティブ列」機能リストを完成した後、プレビュー・ボタン９０２を選択することによってその結果をプレビューすることができる。図７Ａは、新しい列７１２を含む結果の表示を示す。ただし、「詳細」ボタンの選択（押すことによる）は、オンロード・アクションを再び実行すること以外、まだ何もしない。どのように新しい機能リスト７１４が機能リスト内に現れるかに留意されたい。
【０１４５】
５．次のステップは、図１１に示される「製品使用を得る」と呼ばれるウェブ・サービス・ディレクトリ内のサービスに対するサービス・コール機能リストを作成することである。「製品使用を得る」サービスは、テンプレート・ベースのサービスであることを留意されたい。このサービス・コールは、現在のランタイム・モデルのコンテキスト内で意味を有するローカル名で名付けられている。図１２は、サービスの入力を特定するための機能リストＵＩテンプレートの次のページを示す。この時点で、この機能リストは、サービスの入力スキーマをルックアップし、一定値、またはランタイム・モデル内のサービス出力およびパラメータに対する参照を特定するためのＵＩのような形式を構築する。
【０１４６】
６．サービス入力特定ページ１２００上で、ユーザは、２つのストリング値をこのサービスに供給することを求められる。１つは、電話ブランド名１２０２であり、もう１つは、電話機モデル名１２０４である。ユーザは、一定値を指定することができるが、定数を特定するのではなく、テーブルの現行の行内にあるブランドおよびモデル・データ値を参照することによって入力を得ることができる。テーブル機能リストがこれらの参照可能なエンティティに対するアクセスを提供するため、ユーザは、これらの参照を選択することができる。この参照機構手段を使用することは、テーブル内で選択される行に依存して、行固有の値がサービス・コール内に送り込まれることを意味する。
【０１４７】
７．製品仕様データを得るサービス・コールを作成した後、その結果を表示することができるインポートされたページの機能リストが必要とされる。図１３は、ユーザが、形式設定情報および背景カラー等を含むＨＴＭＬページにＵＲＬ１３００を供給する、インポートされたページの機能リストの作成を示している。また、ユーザは、ＨＴＭＬファイルに加えられた可能性のあるどのような変更でも組み込むため、再生成時にシステムがページ内容を再インポートするかどうかも決める（チェック・ボックス１３０２内にチェックマークを入れることにより）こともできる。
【０１４８】
８．次のステップは、カタログ詳細出力ページ上に、「製品仕様を得る」サービスからのＸＭＬデータ出力を表示することになる機能リストを作成する。１つまたは複数の実施形態では、固定ＸＭＬテキスト機能リストを利用することができる。図１４は、固定ＸＭＬテキスト機能リストに関するＵＩを示している。機能リストの入力として、ユーザは、ページ上の名前付きプレースホルダをロケータとして選択し、「詳細を示す」サービス・コールからのサービス出力を特定することができる。１つまたは複数の実施形態（提示した実施例を含む）では、この機能リストからの出力は、ＨＴＭＬに従って形式設定されたブロックのＸＭＬデータである。
【０１４９】
９．カタログ詳細ページは、ユーザをセル電話機データ・ページに戻すボタンを必要とする。したがって、このページ・アクションを呼び出し、次に、そのファンクション・アクションをボタン機能リストにバインドするファンクション機能リストが追加される、またはパフォーマンスを犠牲にして単純化する場合、ボタンが押されたときのオンロード・アクションに対する単純なコールを利用することができる。図１５は、カタログ詳細ページ内で呼び戻されるプレースホルダに付加された「戻る」と呼ばれるボタン機能リストに関するＵＩを示している。
【０１５０】
１０．図１６は、「詳細を示す」と呼ばれるファンクション機能リストを追加する次のステップに関するＵＩを示している。このファンクションは、「詳細を示す」サービス・コールに対するコールをカタログ詳細ページ・アクションに対するコールとグループ化する。
【０１５１】
１１．次に、アクティブ列機能リストを変更して、図１７に示すとおり、選択されたファンクションを「オンロード」から「詳細を示す」に変えなければならない。
【０１５２】
１２．これで、実施例の機能作成部分は終了する。プレビュー・コマンド９０２を選択してアプリケーションを見ることができる。詳細ボタンのうちの１つが選択されたとき、その出力は、データ・テーブル内の選択された行に関係するデータを含む製品仕様ページ７０４である。
【０１５３】
以上、ネットワーク・サービスを作成するための方法および装置を１つまたは複数の実施形態との関連で説明した。本発明は、特許請求の範囲およびそれと等価なものの完全な範囲によって定義される。
【図面の簡単な説明】
【図１】
本発明の１つまたは複数の実施形態によるＷＳＡを生成するためのテンプレートの使用を例示する図である。
【図２】
本発明の１つまたは複数の実施形態によるテンプレートの構成（パラメータを含む）を例示する図である。
【図３】
本発明の１つまたは複数の実施形態によるテンプレートを使用したｗｅｂサービス・アプリケーションの生成を例示する図である。
【図４】
本発明の１つまたは複数の実施形態による再生プロセスを例示する図である。
【図５】
本発明の１つまたは複数の実施形態による、変換されたランタイム・モデルを作成するための機能および機能サービスの使用を例示する図である。
【図６】
本発明の１つまたは複数の実施形態によるテンプレートにおける使用のための機能の選択を例示する図である。
【図７Ａ】
本発明の１つまたは複数の実施形態により生成された携帯電話システムの表示を例示する図である。
【図７Ｂ】
本発明の１つまたは複数の実施形態による、図７Ａの「詳細」ボタンを押した結果として生じる表示を例示する図である。
【図８】
本発明の１つまたは複数の実施形態によるテンプレート・オーサー・アプリケーションの「テンプレートを開く」画面からのセルカタログ・テンプレートの選択を例示する図である。
【図９】
本発明の１つまたは複数の実施形態によるセルカタログを開くテンプレートを例示する図である。
【図１０】
本発明の１つまたは複数の実施形態によるアクティブ列機能ＵＩテンプレートを例示する図である。
【図１１】
本発明の１つまたは複数の実施形態によるサービスの作成を例示する図である。
【図１２】
本発明の１つまたは複数の実施形態による、サービスの入力を指定するための機能ＵＩテンプレートの次のページを例示する図である。
【図１３】
本発明の１つまたは複数の実施形態による、インポートされたページ機能の作成を例示する図である。
【図１４】
本発明の１つまたは複数の実施形態による固定ＸＭＬテキスト機能のためのＵＩを例示する図である。
【図１５】
本発明の１つまたは複数の実施形態による、「戻る」と呼ばれるボタン機能のためのＵＩを例示する図である。
【図１６】
本発明の１つまたは複数の実施形態によるファンクション機能を追加するためのＵＩを例示する図である。
【図１７】
本発明の１つまたは複数の実施形態による、図１０のアクティブ列機能の、ファンクションがＯｎＬｏａｄからＳｈｏｗ Ｄｅｔａｉｌｓへ修正中である状態を例示する図である。

Claims (24)

1. ＸＭＬモデルを作成するためのシステムであって、
   ＸＭＬモデルを備え、
   前記ＸＭＬを生成するように構成されたテンプレートを備え、前記テンプレートは１つまたは複数の機能を含み、
   前記ＸＭＬモデルにおいてエンティティを生成するように構成された１つまたは複数の前記機能を備えている
   システム。
2. １つまたは複数の前記機能が、前記ＸＭＬモデルにおいてエンティティを修正するように構成される、請求項１に記載のシステム。
3. 前記ＸＭＬモデルがランタイム・モデルである、請求項１に記載のシステム。
4. 前記ランタイム・モデルを利用してネットワーク・サービスを構築することができる、請求項３に記載のシステム。
5. 前記テンプレートがＸＭＬにおけるものである、請求項１に記載のシステム。
6. 前記テンプレートがランタイム・モデルである、請求項１に記載のシステム。
7. １つまたは複数の前記機能がランタイム・モデルを入力として利用する、請求項１に記載のシステム。
8. １つまたは複数の前記機能が入力をユーザから得るように構成される、請求項１に記載のシステム。
9. 前記１つまたは複数の各機能が、機能リストにおいてリストされている前記機能リストの順序において実行される、請求項１に記載のシステム。
10. 機能への入力が、前記ランタイム・モデルにおけるエンティティへの参照である、請求項１に記載のシステム。
11. １つまたは複数の前記機能が、機能サービスおよび機能ユーザ・インターフェイスを含む、請求項１に記載のシステム。
12. 前記ＸＭＬモデルがＸＭＬベースのメッセージを表現する、請求項１に記載のシステム。
13. ＸＭＬモデルを作成するための方法であって、
    テンプレートベースのサービスの要求を得るステップと、
    １つまたは複数の機能を含むテンプレートを得るステップと、
    １つまたは複数の前記機能を実行してＸＭＬモデルを作成するステップと
    を備えている方法。
14. 前記ＸＭＬモデルが１つまたは複数のエンティティを含み、前記１つまたは複数のエンティティが１つまたは複数の前記機能によって作成される、請求項１２に記載の方法。
15. １つまたは複数の前記機能が、前記ＸＭＬモデルにおいてエンティティを修正するように構成される、請求項１２に記載の方法。
16. 前記テンプレートがランタイム・モデルであり、前記テンプレートを得るステップが、
    テンプレートをロードすること、および
    １つまたは複数の機能を含むアプリケーションを、前記テンプレートを利用して生成することを含んでいる、
    請求項１２に記載の方法。
17. 前記ＸＭＬモデルがランタイム・モデルであり、
    前記ＸＭＬモデルをロードするステップと、
    ネットワーク・サービスを、前記ＸＭＬモデルを利用して生成するステップとをさらに含む、請求項１５に記載の方法。
18. 前記１つまたは複数の機能がランタイム・モデルを入力として利用することをさらに含む、請求項１２に記載の方法。
19. 前記１つまたは複数の機能が入力をユーザから得ることをさらに含む、請求項１２に記載の方法。
20. 前記１つまたは複数の各機能が、前記機能が機能リストにおいてリストされる順序において実行される、請求項１２に記載の方法。
21. 前記１つまたは複数の機能が、ランタイム・モデルにおけるエンティティへの参照を入力として利用することをさらに含む、請求項１２に記載の方法。
22. １つまたは複数の前記機能が、実行中に機能サービスおよび機能ユーザ・インターフェイスを利用することをさらに含む、請求項１２に記載の方法。
23. 前記ＸＭＬモデルがＸＭＬベースのメッセージを表現する、請求項１２に記載の方法。
24. ユーザが新しい機能をテンプレート・オーサーにおいて作成すること、
    ユーザが機能入力値をユーザ・インターフェイスに供給すること、および
    ユーザ・インターフェイス・テンプレートが機能ブロックを、前記機能入力値および新しい機能を利用して作成すること
    をさらに含む、請求項１２に記載の方法。

Images