JP2004046810A

JP2004046810A - クライアント／サーバ環境におけるアプリケーションステップのディスパッチ方法及びサービスポータルシステム

Info

Publication number: JP2004046810A
Application number: JP2003137807A
Authority: JP
Inventors: Amen Hamdan; ハムダン、アメン; Fritz Hohl; ホール、フリッツ
Original assignee: Sony International Europe GmbH
Current assignee: Sony Deutschland GmbH
Priority date: 2002-05-15
Filing date: 2003-05-15
Publication date: 2004-02-12
Also published as: EP1363187A1; US20030217104A1; US7398527B2

Abstract

【課題】アプリケーションステップをディスパッチするシステムを提供する。
【解決手段】対話は、インターネット又は任意の共同的なネットワーク或いはその両方を経由して、アプリケーションの主要部が実行されるアプリケーションサーバ１０２ｃに送信され、アプリケーションは可能性のあるユーザ対話の次のセットを含んでいるアウトプットを作成する。そこで、アプリケーションは、アウトプットがユーザに転送されるサイクルとユーザ対話を待っているサイクルとを実行するプログラムとして定義される。それは、「ステップ」１１０ａ−１０９ｂと呼ばれる他のパーツを用いるか又は直接的に単一のユーザ対話を取り扱うことを可能にする、異なるパーツに分割される。
【選択図】　　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、広くクライアント／サーバアーキテクチャと分散処理システムの分野に関する。本発明は、例えば、携帯型サービスポータル、アプリケーションサーバ、及び、これらのアプリケーションが採用された異質の遠距離通信ネットワーク間におけるトランザクションシステムに関する。
【０００２】
本明細書において、発明は、ユーザ対話エレメントを、それらのターミナル上でクライアントプログラムの支援のもとで選択することにより、ユーザが離れたアプリケーションサーバ上で稼動しているアプリケーションと間接的に対話することを可能にする、クライアント／サーバアーキテクチャに特に関連する、研究と開発の課題を対象にしている。これらの対話は、次に、インターネット又は任意の企業内ネットワーク或いはその両方を経由して、アプリケーションの主要部が実行されるアプリケーションサーバに送信され、アプリケーションは、起こりうるユーザ対話の次のセットを含むアウトプットを作成する。
【０００３】
そこで、アプリケーションは、アウトプットがユーザに転送されるサイクルとユーザ対話を待っているサイクルとを実行するプログラムとして定義される。それは、「ステップ」と呼ばれる他のパーツを用いて又は直接的に単一のユーザ対話を取り扱うことを可能にする、異なるパーツに分割される。
【０００４】
【従来の技術】
分散型コンピュータシステムは、この数年間急激に普及してきた。分散型コンピュータシステムは、産業や科学的な領域だけでなく、日常生活でも益々重要になってきている。インターネットとその機能は人々が世界の全ての人とコミュニケーションし協力し合うことを可能にする一方、高性能な並列式コンピュータ又はワークステーションにおけるネットワークは、科学上や商業上の問題を今までより速く解決することを可能にする。分散型コンピュータ環境は、新しくて興味あるアプリケーションの広い可能性を示唆している。マルチメディアは、エンターテインメント、情報検索やビジネスシステムのような広範囲のアプリケーション領域に関係し、エンドシステムの大きさに合わせて運用できる可能性をもっている。したがって、マルチメディアをサポートする問題は基本的なひとつである。分散環境で、マルチメディアドキュメントの構造的な資料は、メディアオブジェクトコンテンツと別に保存できる。
【０００５】
従来の分散型アプリケーションは、高速ディスクトップコンピュータから、携帯型ラップトップやハンドヘルドパーソナルデジタルアシスタント（ＰＤＡ）にいたるまで、桁違いに広がっている処理や保存や通信の可能性を対象とする、広範囲のプラットフォームで実行されるように特に設計されている。それらは、（携帯型）クライアントに常駐し、離れたサーバから情報をアクセス又は更新して、有線又は無線或いはその両方の通信ネットワークを用いている。
【０００６】
しかしながら、開発と運用には、分散型アプリケーションの大きな問題が以前としてある。なぜならば、これらのアプリケーションは、それらの複雑で異質なアーキテクチャと通信メカニズムとに起因する種々の予測不能な状況を、しばしばさらけだす。開発や運用プロセスを単純化する試みとして、一方ではミドルウェアプラットフォームの活用、他方ではオンラインツールの一体化が挙げられる。この点に於いて、ミドルウェア環境は、分散型システムの異質性を隠し、分散型コンポーネント間の通信を可能にするプラットフォームを提供することを意図している。オンラインツールは、対照的に、稼動しているアプリケーションの分析又は制御をサポートすることにより、分散型環境の開発者とユーザとを支援することを意図している。それらを効果的に用いると、デバッグのような開発業務から、稼動中のアプリケーション管理のような後の運用業務にいたる、分散型アプリケーションの全ての「オンラインライフサイクル」をサポートできる。
【０００７】
演算と通信のパワーが増えるにつれて、複数の分散型ワークステーションを接続するネットワークは、古い並列式コンピュータにもともとあった問題を解決する上で興味のあるものである。分散型コンピュータシステムの別の長所は、情報に対する恒久的でロケーション透過性のアクセスであり、ユーザが世界中のどこででも協力し情報を共有することを可能にする。構造的な観点から、分散型コンピュータシステムを編成する幾つかの方式がある。しばしば用いられる事例は、クライアント／サーバの原理であり、関係するコンピュータの１つを、所定のサービスをそのクライアントに提供するサーバとするものである。更に最近の手法にあっては、システム全体の信頼性と活用性とを低下させる障害の中心にサーバがなってしまうので、クライアント／サーバの原理をあきらめる。代わりに、任意の関係するホストを識別しないピアトゥピアコンピュータシステムは、分散型コンピュータ環境の開発に適した新しい傾向を代表している。更に、分散型コンピューティングの新しい側面では、ワイヤレス通信を介してネットワークにダイナミックに接続する携帯型機器の活用を挙げることができる。技術の進歩にかかわらず、更に分散型システムのアーキテクチャと関係無く、ソフトウェアの開発は、スタンドアロンシステムのソフトウェア開発と比べると、複雑化している。
一方で、この複雑さは、分散型システムの構造に用いるコンポーネントの多様性によるものであり、他方で、紛らわしさは適用コンポーネントに固有の構成から生じる。これに関して重要なことは、使用可能な資源の管理、使用可能な機能の局部化、分散コンポーネント間のコミュニケーション、及び故障の際の取扱いである。急速な技術の進展と分散型アプリケーションとに対する絶え間のない要求のために、アプリケーションの効率的で信頼性のある構築に適したメカニズムを開発しなければならない。ミドルウェアプラットフォームの活用が、開発にかかわる労力の低減に大きく貢献する。これらのプラットフォームは、コンピュータインフラから引き出され、アプリケーションのコンポーネント間で多かれ少なかれ透過性の対話を可能にする、適切なメカニズムを提供する。ミドルウェアプラットフォームの長所にもかかわらず、更なる支援が、分散型アプリケーションを速く効率的に開発して運用するために要求される。例えば、ソフトウェア開発中に、コンポーネント間の通信を、デバッグ又は性能分析のために追跡する必要がある。そのうえ、その後のソフトウェア運用中に、分散型アプリケーションを管理する必要があり、障害状態も検出しなければならない。
【０００８】
クライアント／サーバアーキテクチャと分散型コンピュータシステムの分野では、本発明の課題と密接に関係する複数の方法と技術とが開発されてきた。本発明の主な理念を理解するために、分散型処理の主な見解と原理と遠隔手順コールの概念とを簡単に説明する必要がある。
【０００９】
分散型処理は、性能と使用可能性と資源の共有とに関して複数の長所をもたらす。しかしながら、分散型環境の管理アプリケーションは複雑なタスクであり、統合化性能管理装備の不備が、大規模な運用の妨げになっている。開放分散型処理基準モデル（ＲＭ−ＯＤＰ）は、国際標準化機構（ＩＳＯ）と国際電気通信連合（ＩＴＵ）との協同的な標準化によるものであって、開放システムの発展の基本となるものである。ＲＭ−ＯＤＰは、一般的な標準の集合で、分散型システムの指定に利用できる。このモデルは、アーキテクチャ設計者や標準化担当者や販売者組合を対象にしており、ソフトウェアのアーキテクチャの設計に際し彼らの手助けするものである。ＲＭ−ＯＤＰの目的は、異質な環境下で、多重系構成の領域のもとで活用できる、分散型情報処理システムの標準を開発することにある。公開され標準化されたインタフェースを用いる規定に加えて、分散型処理システムは、
−　ソフトウェアの携帯性と互換性とを提供するために、
−　種々のシステムと異なるアーキテクチャ及び資源とを高価な特別な方式を用いずにひとつに統合することをサポートするために、
−　システムの発展と稼働時間の変更とを実現するため、
−　自動的に運営される又は技術的に異なる領域をまとめるために、
−　サービス品質（ＱｏＳ）コントロールを故障検出メカニズムに組み込むために、
−　セキュリティサービスを含めるために、及び
−　選択自在の分散型透過サービスを提供するために要求される。
【００１０】
分散型処理において、採用したオブジェクトモデルは、オブジェクト指向プログラミング言語、オブジェクト指向設計方式、分散型オブジェクト管理システムのために示したオブジェクトモデルと異なっている。主な違いとして、下記がある。
【００１１】
−　構成の詳細部から要約ビジネスモデルの検討にいたる、種々の要約化に適したオブジェクト概念の柔軟な使用、
−　マルチプルインタフェースの使用、
−　オブジェクトが通信するインタフェースのクライアント側とサーバ側の分離、
−　システムにオブジェクトを導入するための多種多様なメカニズム、
−　インタフェースを介する通信の安全性に関連した概念、及び
−　オブジェクト間の対話は制約されない。それらは、非同期型、同期型、又は等時性であり、大きなもの、又は小さなものにもなりうる。
【００１２】
分散型処理オブジェクト間の通信モデルは、選択的な分散透明性を導入することで、プログラマに提示される通信の基本を改善する。通信モデルは、オブジェクトの結合モデルから実現できる。分散型処理の基準モデルの特徴は、集団や領域や連体に関する構造的概念の使用にある。これらの概念は、設計時に活用できる静的概念、又は作動時に活用できる動的概念のいずれかに考えることができる。順応的なステートメントが標準化作業で主として要求され、更に、標準化は適切な順応的試験方法を要求する。しかしながら、基準ポイントを区分けすることは、全構成の決定が暴露されないように、順応的な試験の領域を制限することになる。
【００１３】
次章では、複数の現代における分散型システムのアーキテクチャが期待する２つの基本的な手法が、簡単に紹介される。すなわち、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）標準ＲＦＣ１８３１に準じて標準化された遠隔手順コール（ＲＰＣ）の概念と、分散型コンピュータ環境の概念である。
【００１４】
遠隔手順コールの概念はローカル手順コールのシンタックスに準じている。その独自のコールのメカニズムとは別に、遠隔手順コールの主な長所は、コンパイル時の静的タイプチェックを許容する、純粋なソケット通信では与えられないその簡単なパラメータの取扱いにある。遠隔手順コールの欠点は、しかしながら、ローカル手順コールによるシンタックスの識別にもかかわらず、意味が同じでないことにある。意味が異なる理由は、異なるアドレス空間、稼働時間環境、通信プロセスの潜在的に異なる生存期間にある。例えば、別々のアドレス空間のためにローカルＣ手順コールのようにポインタをパラメータとして渡すことができない。遠隔手順コールの実施は、遠隔手順コール言語によるインタフェースの記述に準じていて、そこから、クライアント側とサーバ側の両者に対するスタブとスケルトンとが、遠隔手順コールのコンパイラを用いて生成され、これは、両者のパラメータのセットの配置と再配置、及び送信制御プロトコル（ＴＣＰ）やインターネットプロトコル（ＩＰ）又はユーザデータグラムプロトコル（ＵＤＰ）に依存する通信に対する配慮となる。遠隔手順コールにより、ある程度のアクセスとロケーションの透明性が可能になる。
【００１５】
分散型コンピュータ環境（ＤＣＥ）は、オープングループの最近の開発によるものである。その目的は、クライアント／サーバアプリケーションに適した分散プラットフォームを提供することにある。したがって、ＤＣＥは、ローカルのオペレーティングシステムの最上部に置かれるアプリケーションのアーキテクチャモデルを定める。それは、階層的に構造化されたサービスのセットを定めるので、高レベルのサービスでは低レベルサービスも使用できる。ローカルのオペレーティングシステム上の最低レベルのサービスは、いわゆる「スレッドサービス」である。それは、ＰＯＳＩＸスタンダード１００３．１ｃに準じており、軽量プロセスに適したアプリケーションプログラミングインタフェース（ＡＰＩ）を定めている。このＡＰＩは、スレッドを作成し処理し同期し削除する機能を含んでいて、非同期通信の基礎として作動する。スレッドサービスの上に置かれる基本通信サービスが、前章で述べた遠隔手順コールである。前述の遠隔手順コールの上には、タイムサービス、ディレクトリサービス、セキュリティサービス、分散型ファイルサービスのように、幾つかの高レベルのサービスが用意されている。
これらのサービスは、大半の分散型アプリケーションが要求する異なる種類の汎用タスクに適した機能を提供する。分散型コンピュータ環境そのものは、任意の構成でユーザやマシン又はアプリケーションを搭載する管理ユニットを表す、いわゆるセルに分割されている。分散型コンピュータ環境の主な欠点は、唯一の通信メカニズムとして遠隔手順コールにそれらが依存していることであり、かつ、その非オブジェクト指向設計にある（分散型コンピュータ環境にオブジェクト指向が拡張されてはいるが）。それにもかかわらず、分散型コンピュータ環境の大きな貢献は、ミドルウェア機能を種々の使用可能なサービスに分割するという、それらの概念である。更に、組織的なセルを構築するという離散型の増減自在の手法が、後の開発に重要になる。
【００１６】
別の重要な、しかし非常に異なる形態のミドルウェアは、高性能なコンピューティングとネットワーキング（ＨＰＣＮ）に用いる並列式プログラミング環境である。これらのプラットフォームの主な目標は、並列処理間の通信を効率的にすることにあり、一方、透明性と使いやすさが基本的に二次的な役割を果たしている。並列式プログラミング環境の第一の実施にあっては、メッセージパスの方式、すなわち、全ての通信がメッセージの交換に準じているという手法による。唯一の基本的な通信動作は、メッセージの送信及び受信である。後のシステムで、分散型環境内で共有メモリの手品を提供する、分散型共有メモリ（ＤＳＭ）の方式を取り上げる。ＤＳＭシステムは、ロケーション透明性が改善された長所を提供するので、容易にプログラム可能であるが、メッセージパスシステムの効率化を実現する際の問題をかかえている。
【００１７】
メッセージパスとＤＳＭの両システムの主な目的は、協同作動性と携帯性とを維持しながら、異質なハードウェア上での実行と通信とを効率的にすることにある。したがって、並列式プログラミング環境は、分散型コンポーネントの対話に関して低い透明性を提供する、低レベルミドルウェアとして区分けできる。これは、メッセージ伝送システムを特に正規な状態に維持する。しかしながら、ＤＳＭシステムの場合、透明性は、むしろ低レベルのメモリアクセスでしか達成されない。例えば、分散型コンポーネントを動的に調べる高レベルのサービスがなくなる。
【００１８】
対照的に、メタコンピューティングの基本構造では、並列式高性能コンピューティング方式を地理学的に分散した資源に拡大している。これは、ローカル資源がハードの問題を解決する上で十分でないときに、又は資源の配分が、例えば、総合的協調環境で固有であるときに必要になる。最終的な基本構造は、しばしばグリッドと呼ばれ、これは、高いレイテンシーと狭い帯域幅の広域相互接続とを示している。メタコンピュータシステムの目的は、並列式コンピュータを置き換えることでなく、並列式プログラミングモデルを地理学的分散環境内の使用に拡大することにある。これを達成するために、それらは、例えば、資源管理、セキュリティプロトコル、情報サービス、欠陥許容メカニズム、又は通信サービスを含めて、メタコンピューティングの特殊な要求を支えるサービスを提供する。これらのサービスは、分散型資源使用に共通する問題として取り上げられ、それらは、異なる管理領域に起因する認証と認可の問題、大きな環境での資源管理と割当の問題、又はグリッド内で異なるレイテンシーと帯域幅と信頼性とに起因する通信の問題とを含んでいる。したがって、メタコンピューティングの基本構造では、地理学的に分散したシステムにサービスを加えることにより、並列式で高性能コンピューティングを高レベルの抽象概念にまで高めている。
【００１９】
次に、アプリケーションサーバとそのシステム環境との間で遠隔手順コールを処理してデータを交換するために用いられる、従来技術に基づく、多くの共通して用いられるプロトコルとツールとプログラミング言語とについて説明する。
【００２０】
ウェブサーバ上の共通ゲートウェイインタフェース（ＣＧＩ）スクリプト
ＣＧＩは、サーバがローカルのアプリケーションと通信する際の規定である。
いま、多くのウェブサーバは、ＣＧＩスクリプトをサポートしており、それらは、ウェブサーバがウェブドキュメントを戻すときに、しかし、個々のユニバーサルリソースロケータ（ＵＲＬ）がドキュメントでなくプログラムを指定しているときにコールされる。したがって、ゲートウェイは、情報要求を扱い、適切なドキュメントを戻すか又はドキュメントを急いで生成する。戻されたウェブページは、そのＣＧＩスクリプトで生成されたアウトプットである。データベースのように、クライアントが読み取りできない情報を表示できるサーバは、クライアントの個々のネットワークブラウザが表示できるアウトプットを作成する「メディエイタ」として動作する。ＣＧＩスクリプトを書くために、ＣＧＩスクリプトに渡される照会文字列を分解して解明する単純なインタフェースを提供する、ＣＧＩライブラリの集合が使用できる。しかしながら、それらは、フィルアウトフォームを作成する機能の豊富なセットも提供する。
【００２１】
サーブレット
サーブレットは、動的なウェブページを作成して、ＣＧＩスクリプトと類似する機能を提供するために、ウェブサーバがコールできるジャバプログラムである。ジャバサーバページ（ＪＳＰ）は、ジャバサーバサイドプログラムをハイパーテキストマークアップ言語（ＨＴＭＬ）又は拡張自在のマークアップ言語（ＸＭＬ）と組み合わせるジャバサーブレットテクノロジーの拡張版であり、ウェブ開発者と設計者が、従来のビジネスシステムを補強する、情報が豊富で動的なウェブページを速く開発して容易に保守することを可能にする。ジャバファミリーの一部として、ＪＳＰテクノロジーは、プラットフォームに依存しないウェブベースアプリケーションの短時間での開発を可能にする。ウェブページのコンテンツを生成するロジックをカプセル化するために、ＪＳＰテクノロジーは、ジャバプログラミング言語で書かれたスクリプトレットとタグとを用いる。そのうえ、アプリケーションロジックは、前述のタグとスクリプトレットの支援のもとでウェブページでアクセスしたサーバのベース資源（例えば、ジャバビーンコンポーネントアーキテクチャ）に常駐できる。各フォーマットタグ（ＨＴＭＬ又はＸＭＬ）は、対応するページに直接渡されて戻される。ページロジックをそのデザインと表示から分離して、再利用可能なコンポーネントベースデザインをサポートすることにより、ＪＳＰテクノロジーは、ウェブベースのアプリケーションの構築を今までより高速で容易にする。最小限のオーバーヘッドとメンテナンスとサポートとをもつウェブサーバの機能を拡大するために効果的に運用できるジャバサーブレットと一体化され、ＪＳＰテクノロジーは、ネットスケープやサーバサイドジャバスクリプト（ＳＳＪＳ）又はマイクロソフトアクティブサーバページ（ＡＳＰ）のように、動的なウェブスクリプトテクノロジーの他のタイプに対する魅力的な代替方式を提供する。それは、プラットフォームの非依存性、高められた性能、異なる表示タイプからのロジックの分離、容易な管理、事業化への拡張性、簡単な使用性とを提供する。更に、ＪＳＰは、特定のベンダー又は特定のウェブサーバの独占技術でない。
【００２２】
パーソナルホームページハイパーテキストプロセッサ（ＰＨＰ）
ＰＨＰは、オープンソースのサーバサイドスクリプト言語であり、そのコードをＨＴＭＬ内に埋め込むことができる。それは、ユーザ対話に基づいてウェブページをダイナミックに作成することを可能にする。ＰＨＰの全体的な機能は、サーブレットに匹敵する。その言語スタイルは、Ｃとジャバに似ている。ＰＨＰと比較される他の人気のあるサーバサイドスクリプト言語は、例えば、アクティブサーバページ（ＡＳＰ）、パール、ＣｏｌｄＦｕｓｉｏｎ、ツールコマンド言語（ＴＣＬ）、Ｐｙｔｈｏｎ、ＪＳＰである。
【００２３】
アクションとアクションイベント（Ｊａｋａｒｔａ・ＴｕｒｂｉｎｅとＳｔｒｕｔｓ）
ソフトウェアツールのＳｔｒｕｔｓは、そのオフィシャルウェブサイトがｈｔｔｐ：ｊａｋａｒｔａ．ａｐａｃｈｅ．ｏｒｇ／ｓｔｒｕｔｓで検索され、Ａｐａｃｈｅソフトウェア協会が後援するＪａｋａｒｕｔａプロジェクトの一部である。Ｓｔｒｕｔｓでは、アクションは、ユーザ対話がクライアントで生成したＨＴＴＰ　ＵＲＬに結果としてなるときにコールされる特殊なクラスとして定義される。したがって、前述のアクションが他のアクションをコールできる。このプロジェクトの目的は、ジャバサーブレットやジャバビーンやジャバサーバページ（ＪＳＰ）のような従来のテクノロジーと組み合わせることができるウェブアプリケーションを構築する、オープンソースフレームワークを提供することにある。Ｓｔｒｕｔｓは、モデル−ビューコントローラ（ＭＶＣ）設計方式に準じるアプリケーションアーキテクチャを促進する。それは、それ自体のコントローラのコンポーネントを提供するなどして、他のテクノロジーと組み合わせることができる。更に、Ｓｔｒｕｔｓは、任意の標準的なデータアクセステクノロジーと、例えば、ジャバデータベースコネクテイビティ（ＪＤＢＣ）と対応できて、ＪＳＰ、Ｖｅｌｏｃｉｔｙ・Ｔｅｍｐｌａｔｅｓ、拡張自在のスタイルシート言語変換（ＸＳＬＴ）や他の表現システムと巧みに連動する。Ｓｔｒｕｔｓの枠組みは、公開済みのスタンダードと立証済みのデザインパターンとに準じてアプリケーションに適した拡張自在の開発環境をサポートすることにより、全てのプロフェッショナルなウェブアプリケーションが生き残るために必要な目に見えない土台を提供する。対照的に、Ｔｕｒｂｉｎｅは、経験豊かなジャバ開発者が速く信頼できるウェブアプリケーションを構築することを可能にする。それは、オープンに直接参加できる環境で開発され、Ａｐａｃｈｅソフトウェアライセンスのもとでリリースされる。そのオフィシャルウェブサイトは、ｈｔｔｐ：ｊａｋａｒｔａ．ａｐａｃｈｅ．ｏｒｇ／ｔｕｒｂｉｎｅで見いだすことができる。Ｔｕｒｂｉｎｅのパーツも、そのウェブ部分と無関係に使用できる。したがって、いわゆるアクションイベントは、単一の方法をコールすると、その可能性を拡張するので、異なるコードのパーツを１つのクラスに束ねることができる。
【００２４】
【発明が解決しようとする課題】
前述のようなそれらの長所にもかかわらず、従来技術に基づく従来のスクリプト言語とソフトウェアツールとが解決できない幾つかの問題がある。例えば、記号を用いるステップ又は方法コールのようなメカニズムを用いて、次に予想されるステップをコールする場合に生じる問題がある。次に、これらの問題とそれらの結果について詳細に説明する。
【００２５】
ユーザが２つのステップ間で別のアプリケーションを開始することを決めるという問題の可能性と、そのステップにステートがないという事実にもかかわらず、アプリケーションプログラマは、アプリケーションが、他のアプリケーションがあるステップをコールすることを許可する可能性があるまま、方法コールを継続する場合に始まると思われる次のステップのコールを望んでいる。これは、従来技術のステップをプログラミングする解決法を用いるときに、ある問題を露呈する。これらの問題は、パラメータの受け渡しに関するコールのようなメカニズムに準じて、結果の戻しとネスティングステップコールに分類できる。
【００２６】
例えば、あるステップに続く、多くの予想されるステップがあるかもしれない。一部のステップは、プログラムのサブルーチンとして、あるステップで直接コールされる（直接コール）。他のステップは特定のユーザ対話に依存するので、あるステップのプログラマは、どのステップがどのユーザ対話のケースでコールすべきかについて指定する（間接コール）。コールステップは、従来技術に準じる従来のソフトウェアツール、従来のプログラミング言語を用いる直接コール、ＣＧＩプログラム、サーブレットなどを用いる間接コールによって実行できる。
【００２７】
直接及び間接コールについて、コールするステップは、コントロールを戻し、可能性のある戻り値をコールされたステップの終了後に受け取りを期待する（コールされたステップからコールするステップに戻ることが期待されていない「ｇｏｔｏ」と対照的に、「ｇｏｓｕｂ」と呼ばれる）。ステップに記述がないので、これは、サブルーチンコールのプログラミング言語を用いる透明方式では生じない、しかしながら、コールステップは、コールステップが、この事実を提示するとともに、コールステップを適正なステートにしてそのタスクを続け且つコールされたステップの可能性のある戻り値を届ける、あるデータを用いることを終了した後に、再びコールされなければならない。例えば、「メッセージ作成」ステップは、アドレスブックステップでメッセージの受信者を入手することを要求する。アドレスブックステップは、そのタスクを完遂するために、別のステップのコールも選定する場合があり、これは、ネストされたコール通路を招く。
【００２８】
「ｇｏｓｕｂ」コールに対して、このネスティングは、同じアプリケーションを個々のユーザが用いている場合にだけ起きる。アプリケーションが用いられているセッション中に、ユーザが別のアプリケーションに切り替えることを選ぶと、古いアプリケーションのステップコールのネスティングが廃棄され、新たにネストした通路が構築される。しかしながら、「ｇｏｓｕｂ」コールのネスティングは、従来技術における従来の解決法を採用しているときにはありえない。
【００２９】
直接コールに対して、コールステップのプログラマは、パラメータのセットの指定、及び「ｇｏｓｕｂ」コールのケースでは、コールされたステップの結果の処理を望む。従来技術での従来の解決法では、パラメータは、共通セッションのデータスペースを用いて処理できる。したがって、従来の技術は、パラメータのパスと、直接コールの結果を戻すこととを可能にする。
【００３０】
予想される次のステップの各々について、あるステップのプログラマは、パラメータのセットの指定、及びあるケースでは、これらのステップをコールした結果の処理を望む。従来技術に準じる従来の解決法では、ステップパラメータは、クライアントドキュメント内でエンコードされ（例えば、ＨＴＴＰ　ＧＥＴ又はＰＯＳＴパラメータとして）、次にクライアントにより戻され、共通セッションのデータスペースにシステムによって互いに置かれる。これらのデータがコールされたステップで次に検索できるパーツは、ステップが、直接コールすると思われる別のステップでパスされたデータを検索するパーツと異なる。したがって、従来の技術は、パラメータのパスと間接コールの結果を戻すこととを可能にする。
【００３１】
しかしながら、ここでの問題は、ステップパラメータがクライアントドキュメント内でエンコードされているので、次に示す数多くの問題を招く。
【００３２】
第一に、パラメータとステップ名称用のメモリスペースは、ＨＴＴＰ　ＧＥＴメカニズムが用いられる場合に制限され、例えば、２５５文字という最大長に、しばしばなることである。
【００３３】
制約が少ないので、ＰＯＳＴメカニズムを用いると、ジャバスクリプト又は類似言語の使用が、複数の隣接ステップをコールできる場合に要求される。したがって、ジャバスクリプト又は類似言語は、それらを実行できるクライアントを要求することになり、幾つかのセキュリティの問題を露呈する。
【００３４】
更に、文字列で表現できるパラメータだけ、ＧＥＴやＰＯＳＴパラメータに使用できる。
【００３５】
最後に、これらのメカニズムは、ウェブブラウザ又はワイヤレスアクセスプロトコル（ＷＡＰ）ブラウザにプラスしてネットワークサイドＷＡＰゲートウェイのように、サーバ向けのＨＴＴＰメッセージを生成できる、ターミナルを要求する。
【００３６】
時々、ステップパラメータは、まだ知らないが、システムの使用履歴又は今のアプリケーション仕様条件のようなものに依存する、次のステップを指定する。
このようなケースは、下記を含むと考えられる。
【００３７】
最後に実行されたステップ（「バック」）、
コールステップ（「親ステップ」）、
ポータルの開始ステップ（「メインメニュー」）、又は
アプリケーションの開始ステップ（「アプリケーションのメインメニュー」）。
【００３８】
例えば、Ｓｔｒｕｔｓは、ステップの直接コールに適した記号によるステップを提供するが、間接コールや、コールされたステップにパラメータを渡す可能性がない。「ｇｏｓｕｂ」コールをネストする可能性がないので、コールのネスティングに依存する、記号によるステップを使用する手段もない。
【００３９】
図７に示す表は、従来技術による従来の解決法が前述の問題を取り上げていないことを示す。
【００４０】
【課題を解決するための手段】
前述の説明を鑑みて、本発明は、アプリケーションステップを同様に再び使用する課題を解決する技術を提案することにある。更に、本発明は、これらのステップを、ユーザ対話に基づいて、ＨＴＴＰに依存せずに自動的にコールする課題、又は前述のステップのネストされた使用を可能にする課題、或いはその両方を取り扱っている。
【００４１】
これらは、独立請求項の特徴によって達成される。優れた特徴が、独立請求項に定められている。本発明の更なる目的と長所は、次の詳細な説明から明らかになる。
【００４２】
本発明は、多重化されネストされた同期状態で同時発生した遠隔手順コールを処理できる分散型コンピュータ環境において、クライアント／サーバアーキテクチャと分散型処理システムとをサポートする考えを基本的に意図している。特に、それは、これらのアプリケーション環境が採用されている異質の遠隔通信ネットワークにおいて、携帯型サービスポータルとアプリケーションサーバとトランザクションシステムとに関している。
【００４３】
独立請求項１と請求項２〜８は、サービスポータルのアプリケーションサーバ上で稼動する少なくとも１つのアプリケーションのステップを、前述のサービスポータルに接続されたクライアントターミナルからアクセスできる分散型コンピュータ環境のクライアント／サーバシステムにおいてディスパッチする方法であって、ユーザは、ユーザ対話エレメントをそれらのクライアントターミナル上でクライアントプログラムの支援のもとで選択することにより、遠隔のアプリケーションサーバ上で稼動しているアプリケーションと対話し、対話は、前述のアプリケーションの主要部が実行されているアプリケーションサーバに次に送信され、アプリケーションは、可能性のあるユーザ対話の次のセットを含んでいるアウトプットを作成する。そこで、次のステップが実施される。すなわち、コールアプリケーションステップ内でコールされたサブルーチンとして作用する別のアプリケーションステップのコールに用いられるプログラミングコマンドを任意にネストし、値をコールアプリケーションステップに戻し、ユーザが別のアプリケーションに切り替わる場合に、コールされたアプリケーションステップのネスティング通路を放棄する。
【００４４】
次に、独立請求項９は、請求項１〜８のいずれかに記載の方法を具体化するために構成された分散型コンピュータ環境におけるクライアント／サーバアーキテクチャのサービスポータルシステムを意図している。
【００４５】
【発明の実施の形態】
次に、本発明の好ましい実施例を図１〜６に示して詳細に説明する。本明細書で用いられる用語の一部は図９の表に示した。
【００４６】
提案された手法による本発明は、アプリケーション２０２ａ／ｂ／ｃを多くの再利用自在のパーツに分割できる（ステップ１０９ａ−１）システムを意味している。例えば、メッセージ送信アプリケーションは「メッセージ作成」ステップ６０８と「メッセージ送信」ステップとに分解される。したがって、前述のシステムは、パーツをアプリケーションの境界を越えて再利用できる。他のアプリケーションは、これらのパーツを、それら自体の全体的なアプリケーションの流れに任意の時に自由に含めることができる。
【００４７】
解決法の形式的な図を図１に示す。ここで、ユーザ対話の実施前に、どのパラメータによるどのステップ１０９ａ−ｉが、異なるユーザ対話の場合にコールしなければならないかについて記す、ルールセット１０８ａ／ｂが存在することを想定している。このルールセット１０８ａ／ｂはシステムに明瞭に存在するか、又は、それはクライアントドキュメントにエンコードされている（例えば、ＨＴＭＬドキュメント又は特殊なクライアントプログラム又は両者の組み合わせの場合（図８の表を参照））。図１に示すように、あるステップｉのルールセット１０８ａは、前のステップｉ−１で作成又は少なくとも変更されている。ルールセット１０８ａが存在しないと、デフォルトのルールセット１０８ａが用いられる。あるルールに付随するアクションが静的でなく、個々のクライアントの関係又はサーバの関係に準じて変わることに注目すべきである。例えば、エントリ「ｉｄ＝５」は、ユーザがあるロケーションを有する場合に「パラメータａ＝１、ｂ＝３」と等しくなると考えられ、状況が異なる場合に、それが変わると思われる。
【００４８】
クライアントターミナル１０２ａ上で、ユーザは、対話エレメントを（例えば、ボタンを押して）選択する。ユーザ対話に付随するメッセージが、ここでサーバ上のクライアントゲートウェイ１０４に送られる。メッセージは、クライアント指定フォーマットで現れ、要求ディスパッチャ１０６が用いるクライアントに依存しないフォーマットに解釈される。第一のケースで、このクライアント指定メッセージは、ステップ名称とパラメータとを既に含んでいる。第２のケースで、クライアント指定メッセージは、ステップ名称と識別名称（ｉｄ）とを既に含んでいる。クライアントゲートウェイ１０４は、このｉｄを対応するパラメータと置き換える。第３のケースで、クライアントゲートウェイ１０４は、この識別番号を対応するステップ名称とパラメータとに置き換える。
【００４９】
その後、解釈した要求メッセージが、要求ディスパッチャ１０６に送られる。
メッセージは、いまペア（ステップ名称とパラメータ）で構成される。そのようにして生成したペアが、ＰＡＲＥＮＴＳＴＥＰ、　ＭＡＩＮ　ＭＥＮＵなどのような記号のステップを含んでいる場合、要求ディスパッチャ１０６は、ペアの記号のステップ名称にステップスタック１１０ａ／ｂから置き換える。ＭＡＩＮ　ＭＥＮＵがシステムのトップ−レベルのステップを示す場合、完了したスタックが空になり、第一のステップ名称が用いられる。
【００５０】
ここで、ディスパッチャ１０６は、ステップ名称とあるパラメータとを知る。
それは、対応するパラメータを用いて、対応するステップ１０９ｂをコールする。このステップは、ここで開始する。ステップが終了する前に、それは、次のクライアントドキュメントのパーツと次のルールセット１０８ｂとを作成できる（しかしながら、その必要はない、下記を参照）。そこで、システムは、次のユーザ対話を取り扱う方式を知る。そのうえ、それは、ステップスタック１１０ａにアクセス（すなわち、読取又は書込或いはその両方）できるので、次のステップスタックステート１１０ｂを作成する。
【００５１】
終了前に、ステップ１０９ｂは（他のステップも回帰的にコールできる）他のステップ１０９ｃもコールできる。これらのステップは、クライアントドキュメントのパーツと次のルールセット１０８ｂも作成できる。コールすべきステップは、それらに名称を付けるか、又は、再びＰＡＲＥＮＴＳＴＥＰ又はＭＡＩＮ　ＭＥＮＵのような記号によるステップ名称を指定することにより、基準になることができる。
【００５２】
普通、ステップをコールするタイプに２つある。第一のタイプ「ｇｏｔｏ」は、コールされたステップにコントロールを渡して、コールステップの実行を終了する。第２のタイプ「ｇｏｓｕｂ」は、次のステップをコールするが、コールされたステップの終了後、コントロールを戻す。このケースで、コールステップは、コールされたステップが戻す可能性のある結果も評価する。「ｇｏｓｕｂ」コールのケースで、コールステップは、あるパラメータについて求められ、ステップ名称とそのパラメータがスタックに送られる。
【００５３】
「ｇｏｓｕｂ」コールでコールされたステップが終了すると、それは、必要に応じて、記号のステップ名称ＰＡＲＥＮＴＳＴＥＰを指定する。このケースで、スタックの第一のエレメントは、スタックから取り出されて、実行のために用いられる（したがって、終了すべステップを「ｇｏｓｕｂ」コールするときに、このステップで指定したパラメータを用いる）。
【００５４】
始動要求に対する応答が、クライアントターミナル１０２ａに届けられる。最後に、全体的なプロセスが、ユーザが対話エレメントを選択した後に再開する。
【００５５】
このメカニズムを用いて、アプリケーションワークフローを実現する２つの方式がある。アプリケーションワークフローは、アプリケーション２０２ａがあるステップにあるとともにユーザが指定の対話エレメントを選択するという見解のもとで、あるアプリケーション２０２ａのステップ１０９ａ／ｂ／ｃが、どのように関連するかについて決定する制御スキームである。
【００５６】
第一の方式は、図２に示すような分散型アプリケーションワークフロースキーム２００を採用することであり、各ステップが、今のステップから到達できる次のステップを決定する部分的なワークフローを含んでいる。このスキームで、ステップは、マルチプルアプリケーション２０２ａ／ｂ／ｃで用いられる場合に、マルチプルアプリケーション２０２ａ／ｂ／ｃのワークフローのパーツを含んでいなければならない。
【００５７】
第２の方式は、図３に示すようなセントラルのアプリケーションワークフロースキーム３００を用いることであり、ワークフローが特別のステップ内に保たれている。このスキームでは、あるアプリケーション２０２ａ中に、この特殊ステップで常に、アプリケーションコントローラ３０２ａ／ｂ／ｃが要求ディスパッチャ１０６によってコールされる。アプリケーションコントローラ３０２ａ／ｂ／ｃは、適切なステップを直接コールする。このスキームで、ステップは、前述のステップが異なるアプリケーション２０２ａ／ｂ／ｃにおいてコールされる場合に変更する必要がない。
【００５８】
次章で、本発明を実現するために効果的に応用できる多くの方法が提案される。そこで、前章で既に紹介したステップ−ベースのシステムの事例が提示される。このシステムは、図２に示す純粋なディスパッチャ１０６又はステップ構造を用いるが、他の更なるアプリケーションコントローラ３０２ａ／ｂ／ｃを用いていない。アプリケーション２０２ａ／ｂ／ｃは、このコントローラを、それを必要とする場合に自由に採用できる。
【００５９】
そこで、アプリケーション２０２ａ／ｂ／ｃは、ステップを他のアプリケーションに提供する。インタフェースが任意のユーザ対話なしの方法コールの集合なので、ステップはユーザ対話を含む更に複雑な機能を具体化できる。一例として、関係するサービスから一部の関係する情報を検索することは、インタフェースでカバーされるが、メッセージ送信サービスによるメッセージの送信は、ユーザ対話を伴うのでステップとして実行される。
【００６０】
図４は、全ての必要なコンポーネントを示す。一部の相互接続又はサポートコンポーネント或いはその両方は、説明を単純にするために省略されている。全てのパーツと任意の他のパーツとのその関連性について次に示す。
【００６１】
クライアントターミナル
クライアントターミナル１０２ａは、システム向けの通信手段とユーザ対話に使用できるある出力手段とを有する任意の装置になることができる。任意の指定の適応性がシステムで自動的に対応できるので、このコンポーネントに対する他の要求事項はない。
【００６２】
解釈変換コンポーネント
適用された解釈変換コンポーネント４０６は、ある変更をステップのアウトプットに適用して、それらをクライアントの出力手段に表現可能にする。例えば、クライアントターミナル１０２ａがＨＴＭＬとＪＰＥＧフォーマットのイメージとをサポートするだけである場合、解釈変換コンポーネント４０６は、アプリケーション２０２ａ／ｂ／ｃの出力を変更するか、又はこの要求事項に適合するようにする。この関係で、変更がクライアントターミナル１０２ａから来る情報に対しても実施された場合、これは、この段階でも行われることに注目すべきである。
【００６３】
クライアントゲートウェイ
解釈変換コンポーネント４０６は出力適応性を扱うだけなので、低レベル装置適応用の更なる手段も表示しなければならない。クライアントゲートウェイ１０４は、したがって、出力と適応用のプロトコルを更に整備して、クライアントターミナル１０２ａに出入する通信を可能にする。
【００６４】
セッション管理ユニット
アプリケーションステップ１０９ａ／ｂがあるユニットとまだ対話しているかどうか、この対話が別の既に過去の対話に付随するかどうか判定可能にするために、セッションを定めて追跡する手段が必要になる。そこで、この機能を実施するセッション管理ユニット１０８が提供される。全てのセッションに、セッションコンテキストが付随している。このセッションコンテキストは、情報を記憶する手段を提供し、セッション自体の存在期間の全体にわたって持続する状態で保たれる。基本的なアプリケーション内部データの一部は、ここで記憶される。
【００６５】
要求ディスパッチャ
要求ディスパッチャ１０６は、クライアントターミナル１０２ａからの要求を、それらがクライアントゲートウェイ１０４と解釈変換段階とを通過後に受け取る。したがって、入力される要求は、理解可能で処理可能なフォーマットである。要求ディスパッチャ１０６は、クライアントターミナル１０２ａに対する今のセッションのステートについて記憶されているある情報に基づいて次のステップ（ステップスタック１１０ａ／ｂ、更なるステップパラメータセット１１４ａ／ｂとルールセット１０８ａ／ｂ）と呼び出すべき次のステップを決定するために要求そのものとを選ぶ。その後、適切なアプリケーションステップ１０９ａ／ｂがコールされ、その応答がクライアントターミナル１０２ａに渡されて戻る。もちろん、ステップは、自由に他のステップをコールしたり又はサービス方法をコールして、あるタスクを実施できる。全体的なプロセスが、図５に概略的に図示されている。
【００６６】
アプリケーションステップ
アプリケーションステップ１０９ａ−ｉは、アプリケーション２０２ａ／ｂ／ｃのなかで目に見えるパーツに関する基本的な構築ブロック（すなわち、図面）である。そこで、数多くの意味的に近いステップ１０９ａ／ｂ／ｃは、関係するサービスを伴って、アプリケーション２０２ａを構築する。ステップが他のステップから指示できるので、ソフトウェアコンポーネントが簡単に再利用できる。ステップの特徴の詳細について次章で述べる。
【００６７】
あるステップがあるタスクを完了するために他のステップを呼び出すと考えられるので、「ｇｏｓｕｂ」コールを適用するケースの完了後にコール段階に戻ることを可能にする、メッセージが必要になる。例えば、コミュニティ／メッセージ送信アプリケーションが「メッセージ送信」ステップと「メッセージ編成」ステップ６０８とを呼び出すかもしれない。メッセージ送信後、アプリケーションの流れは、コミュニティ／メッセージ送信アプリケーションに戻る。そのために、要求ディスパッチャ１０６は、ステップ呼び出しトレース、又は要するに「ステップスタック１１０ａ／ｂ」を維持する。新しいステップが呼び出されると、必ず、それはスタックの最上部に置かれる。ステップが親ステップを参照する必要がある場合、それは、レファレンス１１６ｂのために確保されているキーワードを用いて、それを行う。この場合、要求ディスパッチャ１０６は、キーワードを探して、トップエレメントをスタックからポップし、対応するステップを呼び出す。
【００６８】
各ステップは、アウトプットエレメントを生成して、ユーザと対話すると思われる。しかしながら、アウトプットはクライアントターミナル１０２ａに相応して適応され、図４に概略的に示す処理チェーンによりシステムに再び戻るので、次のことを考慮して、ユーザとの具体的な対話を要約する。
【００６９】
前述のコミュニティ／メッセージ送信アプリケーション対話用のステップスタック１１０ａ／ｂを図６に示す。ここで、ある数のコミュニティを選択するステップは、今選択されているユーザにメッセージを送信する手段の使用を望んでいる。それは、したがって、コミュニティ／メッセージ送信アプリケーションからステップを引用する。この瞬間、「コミュニティ選択ユーザ」ステップ６０２がステップスタック１１０ａ／ｂのトップエレメントになるので、今実行されているものになる（図６Ａ）。ユーザ対話がメッセージ送信ステップの分岐になる場合、要求ディスパッチャ１０６は、メッセージ送信ステップをステップスタック１１０ａ／ｂのトップエレメントにし、それに伴ってステップスタック１１０ａ／ｂを適応するので、実行しなければならないものになる（図６Ｂ）。一度このコミュニティ／メッセージ送信アプリケーションが実行を終えて、コール段階に戻りたい場合、それは親ステップを参照する。このステップは、呼び出されたステップに関する任意の知識を有していないので、それは、親ステップの名称そのものを用いずに、要求ディスパッチャ１０６が認識し解明した確保済みのキーワードから、親ステップを参照する。この場合、親ステップ名称のレファレンス１１６ｂは、要求ディスパッチャ１０６がスタックのトップエレメントを除去する結果になり、コミュニティ／メッセージ送信アプリケーションからの「コミュニティ選択ユーザ」ステップ６０２が再びトップエレメントになるので、実行されるものになる（図６Ｃ）。このときに、コミュニティ／メッセージ送信アプリケーションは、メッセージ送信ステップの戻り値をチェックして、ステップの実行が成功したかどうか決定する。
【００７０】
エラーが発生すると、適切なアウトプットが、要求ディスパッチャ１０６又は故障したステップのいずれかで生成される。要求ディスパッチャ１０６は、次に、スタックのトップのステップを除去又は再実行するかを選定できる。低レベルのアプリケーションに固有でない指定エラー（例えば、空のステップスタック１１０ａ／ｂ）の場合、要求ディスパッチャ１０６は、デフォルトステート、例えば、メインメニューのステップに戻る。
【００７１】
ステップは、本発明の本実施例ではステートのない状態と想定されているので、任意の内部記憶領域に情報を記憶できない。この欠点を解消するために、ステップコンテキストが導入される。ステップコンテキストは、ステップがステップスタック１１０ａ／ｂ内で使用可能である限り、一定に保たれる記憶領域である。更に、専用のステップコンテキストは、あるステップで目視できるだけである。ステップが、実行を終了しステップスタック１１０ａ／ｂから除去された後に、一度放棄されると、対応するステップコンテキストも放棄される。
【００７２】
ステップ指定ステップコンテキストとは別に、ステートの無いステップの生存期間を越えて情報を記憶できるアプリケーションコンテキストもある。アプリケーションコンテキストは、あるステップのものより通常は長い、アプリケーション２０２ａの存在期間にも利用できる。
【００７３】
次章では、提案したステップ構成の技術的な詳細事項、異なるステップ名称を解明して値をステップから渡して戻す手順、本発明で提案した実施例に基づくステップの「ｇｏｔｏ」と「ｇｏｓｕｂ」コールとについて詳細に説明する。
【００７４】
各ステップは、独自の記号による名称で参照される。入力要求ごとに、要求ディスパッチャ１０６は、要求文字列を対応するクラスに分解して、そこにある専用方法を呼び出す。そこで、各ステップは、ステートの無い定義ごとになり、要求ごとに作成され、後で捨てられることを意味している。これは、実施をある程度単純にするが、任意の他のシステムでは別の状態で解明できる。
【００７５】
要求ディスパッチャ１０６は、マッピングを記号によるステップ名称から、それらの実際の構成に保持する。そのうえ、ステップ構成に直接マップされないが、今のアプリケーションのステートに準じて別のステップに割り当てられる、ある記号によるステップ名称がある（例えば、「ＰＡＲＥＮＴＳＴＥＰ」）。個々の構成に準じて、親ステップをコールすることは、アプリケーションの流れにおけるバック機能と等しい。例えば、システムが全ステップを任意のケースでステップスタック１１０ａ／ｂのトップに置くと、親ステップは前の（バック）ステップを呼び出すことと等価になる。「コミュニティステップ」６０４が「メッセージ編成」ステップ６０８をコールすると、「メッセージ編成」ステップ６０８は、コール段階に戻ることを望む場合に「ＰＡＲＥＮＴＳＴＥＰ」で「コミュニティステップ」６０４を参照する。要求ディスパッチャ１０６は、ステップスタック１１０ａ／ｂから前のエレメントを単純に取り出して、構成マッピングにステップを問い合わせずに親ステップのステップ構成にこれを分解する。
【００７６】
ある場合に、パラメータを渡して、戻り値をステップから検索することが要求される。例えば、「メッセージ編成」ステップ６０８に対して、デフォルトメッセージを予めセットして、メッセージ配送が成功したかどうか示すステータスフラグを戻すことが効果的である。そのために、システムは、ステート内部方法を介して間接的にそれをセットして又は「ｇｏｓｕｂ」又は「ｇｏｔｏ」コールで直接ステップを呼び出すときに直接パラメータを渡すことを許可する。要求ディスパッチャ１０６は、パラメータが次のステップに渡されるようにする。同じことが、戻り値にもいえる。それらは、「ｇｏｓｕｂ」又は「ｇｏｔｏ」コールの場合にコール段階に直接戻されるか又はステップ内部方法を介してアクセスできる。後者の場合、それらは、それに伴って、後のアクセスを許可するために、要求ディスパッチャ１０６がセットしなければならない。
【００７７】
ここまでは、他のステップをコールすることは、あるユーザ対話に付随していた。ある場合に、ステップをステップ内部から直接コールして、あるユーザインタフェースエレメントを含めるか、又は実行を継続すべき別のステップにコントロールを渡すことが効果的になるかもしれない。
【００７８】
したがって、システムは、あるステップ内から他のステップを呼び出す２つの方式、「ｇｏｔｏ」と「ｇｏｓｕｂ」コールを可能にする。ステップが「ｇｏｓｕｂ」コールを用いて別のステップを含めるときに、コールされたステップが呼び出され、コントロールの流れはコール段階に後で戻される。別のステップの「ｇｏｔｏ」コールの場合、コントロールの流れが、コールされたステップに完全に渡される、例えば、コールされたステップがステップスタック１１０ａ／ｂのトップエレメントになり、呼び出しステップが、そこから除去される。
【００７９】
本発明に基づいて提案された技術は、要求−応答スキームをサポートする任意のシステムで実施できるので、プロセス全体に関与する付加的な可能性を秘めている。しかしながら、ある既存のプラットフォームは、他のものより更に適しているように見える。次に、これらの技術の一部について紹介し、システムを構成するうえで、それらを活用する長所について概略的に説明する。
【００８０】
ジャバ
ジャバは、サンが開発したプラットフォームに依存しないプログラミング言語であるとともにアプリケーションフレームワークである。数多くの異なるプラットフォームがサポートされるという事実から、それは、容易な統合と他に可能性のある外部ステップとを可能にする。
【００８１】
Ｊａｋａｒｕｔａ・Ｔｏｍｃａｔ
サーブレットは、一体化されたウェブ−ベースのアプリケーション開発環境を可能にする、ジャバ−ベースのフレームワークである。サーブレットコンテナの基準的な実施は、ＪａｋａｒｕｔａプロジェクトのＴｏｍｃａｔエンジンである。Ｔｏｍｃａｔは、セッション管理と要求処理とを既に導入しているので、本発明に基づくディスパッチャ１０６／ステップのアーキテクチャを実施するための基本メカニズムとなりうる。
【００８２】
【発明の効果】
ここで本発明に基づいて提案した手法と従来技術に準じる従来の解決法との間の主な優れた違いについて、下記のように要約できる。
【００８３】
まず、本発明は、ステップの「ｇｏｓｕｂ」コールをネストして、値をコールステップに戻し、ユーザが別のアプリケーション２０２ｂに切り替わる場合にコールされたステップのネスティングのパスを放棄することを可能にする。
【００８４】
更に、システムにユーザ対話指定識別番号を戻す、任意のクライアントターミナル１０２ａからステップを間接的にコールするときに、数多くの２進パラメータを渡すことを可能にする。
【００８５】
最後に、ステッププログラマが、記号から推定される次のステップを指定することを可能にする。
【図面の簡単な説明】
【図１】本発明に基づいてクライアント／サーバシステムでアプリケーションステップをディスパッチする全体的なメカニズムを示す概略図である。
【図２】３つのアプリケーションの分散型アプリケーションワークフロースキームを示す図であり、アプリケーションの各ステップが、このステップから到達できる次のステップを決定する部分的なワークフローを含んでいる。
【図３】３つのアプリケーションの中心アプリケーションワークフロースキームを示す図であり、ワークフローは特別ステップの内部に保たれている。
【図４】本発明に基づいて要求されたシステムコンポーネントを示す単純なブロック図である。
【図５】本発明に基づいて要求されたディスパッチャ動作原理の全体的なプロセスを示すブロック図である。
【図６】いわゆるコミュニティ／メッセージ送信アプリケーション対話用の３つのステップスタックの具体例を示す図であり、「コミュニティ選択ユーザ」は、最初に実行すべき前述のスタックのトップエレメントであり、（図６Ａ）、「メッセージ編成」ステップは、最初に実行すべき前述のスタックのトップエレメントであり、（図６Ｂ）、「コミュニティ選択ユーザ」は、最初に実行すべき要求ディスパッチャによる「メッセージ編成」ステップの除去後に前述のスタックのトップエレメントに再びなる（図６Ｃ）。
【図７】従来技術による従来の解決法の表を示す。
【図８】ルールセットとクライアントドキュメントの組み合わせに於ける異なったケースの表を示す。
【図９】本明細書で使われている用語の解説表を示す。
【符号の説明】
１０１　ユーザ／クライアント要求、１０２ａ　クライアントターミナル、１０２ｂ　（携帯型）サービスポータル、１０２ｃ　アプリケーションサーバ、１０４　クライアントゲートウェイ、１０６　要求ディスパッチャ、１０８　ステップルールセット、１０９　アプリケーションステップ、１１０　ステップスタック、１１２　ターミナルドキュメント、１１４　ステップパラメータセット、１１６　レファレンス

Claims

サービスポータルのアプリケーションサーバ上で稼動する少なくとも１つのアプリケーションのステップを、前記サービスポータルに接続されたクライアントターミナルからアクセスできる分散型コンピュータ環境のクライアント／サーバシステムにおいてディスパッチする方法であって、
ユーザ対話エレメントが、それらのクライアントターミナル上でクライアントプログラムの支援のもとで選択されることにより、遠隔アプリケーションサーバ上で稼動しているアプリケーションと対話し、
その対話は、アプリケーションの主要部を実行するアプリケーションサーバに次に送信され、
アプリケーションは、可能性のあるユーザ対話の次のセットを含んでいるアウトプットを作成し、さらにそこで
アプリケーションステップは、他のアプリケーションステップで、前記アプリケーションステップの処理に必要なソフトウェアコンポーネントを再利用するために、アドレス指定されて呼び出されることができるものであって、
コールアプリケーションステップ内でコールされたサブルーチンとして作用する、別のアプリケーションステップのコールに用いられるプログラミングコマンドを任意にネストし、
値をコールアプリケーションステップに戻し、
別のアプリケーションに切り替わる場合に、コールされたアプリケーションステップのネスティングパスを切り捨てるディスパッチ方法。
パラメータは、前記第２のアプリケーションステップが直接呼び出されるときに、第２のアプリケーションステップに直接渡されて、前記第２のアプリケーションステップをコールすることを特徴とする請求項１に記載のディスパッチ方法。
パラメータは、アプリケーションステップが呼び出されるときに、ステップ内部方法を介して間接的にセットされ、
要求ディスパッチャは、前記パラメータが次のアプリケーションステップに渡すように手助けをすることを特徴とする請求項１に記載のディスパッチ方法。
戻り値は、コールアプリケーションステップに直接戻されて、サブルーチンとして作用するネストされたアプリケーションステップをコールすることを特徴とする請求項３に記載のディスパッチ方法。
戻り値は、ステップ内部方法を介してアクセスされ、
要求ディスパッチャは、前記戻り値が、後のアクセスを可能にするように、それに伴ってセットされるように手助けすることを特徴とする請求項３に記載のディスパッチ方法。
サービスポータルのアプリケーションサーバ上で稼動する少なくとも１つのアプリケーションのステップを、前記サービスポータルに接続されたクライアントターミナルからアクセスできる分散型コンピュータ環境のクライアント／サーバシステムにおいてディスパッチする方法であって、
ユーザ対話エレメントが、それらのクライアントターミナル上でクライアントプログラムの支援のもとで選択されることにより、遠隔アプリケーションサーバ上で稼動しているアプリケーションと対話し、
その対話は、アプリケーションの主要部を実行するアプリケーションサーバに遠隔通信ネットワーク上で次に送信され、
アプリケーションは、可能性のあるユーザ対話の次のセットを含んでいるアウトプットを作成するものにおいて、
システムにユーザ対話指定識別番号を戻す、任意のクライアントターミナルからアプリケーションステップを間接的にコールするときに、２進パラメータのデータを渡すディスパッチ方法。
サービスポータルのアプリケーションサーバ上で稼動する少なくとも１つのアプリケーションのステップを、前記サービスポータルに接続されたクライアントターミナルからアクセスできる分散型コンピュータ環境のクライアント／サーバシステムにおいてディスパッチ方法であって、
ユーザは、ユーザ対話エレメントを、それらのクライアントターミナル上でクライアントプログラムの支援のもとで選択することにより、遠隔のアプリケーションサーバ上で稼動しているアプリケーションと対話し、
対話は、アプリケーションの主要部が実行されているアプリケーションサーバに遠隔通信ネットワーク上で次に送信され、
アプリケーションは、可能性のあるユーザ対話の次のセットを含んでいるアウトプットを作成するものにおいて、
ステップパラメータが推定された次のアプリケーションステップを記号方式で指定することを可能にするディスパッチ方法。
分散型コンピュータ環境のクライアント／サーバアーキテクチャのためのサービスポータルシステムであって、前記サービスポータルにユーザ要求を送るクライアントターミナルが遠隔通信ネットワーク上で前記アプリケーションサーバに接続するものにおいて、
ステップのアウトプットに所定の変更を実施して、それらの表示をクライアントターミナル上でクライアントターミナルのデータフォーマット規定に基づいて可能にするために用いられる、少なくとも１つの解釈変換コンポーネントと、
アプリケーションステップがあるユーザとまだ対話しているかどうか、この対話が別の既に過去の対話に付随しているかどうかについて判定する、少なくとも１つのセッション管理ユニットと、
受信されたユーザ要求のクライアント指定フォーマットをクライアントに依存しないフォーマットに解釈するために用いられる、少なくとも１つの要求ディスパッチャとを備えるサービスポータルシステム。
前記要求ディスパッチャは、
どの次のステップを呼び出すかについて決定するために、サービスポータル内のデータベースに記憶されている、クライアント又はユーザ及び要求自体に対する今のセッションのステートに関する情報に基づいて、次のアプリケーションステップを選定し、
適切なアプリケーションステップをコールし、
応答をクライアントターミナルに渡して戻すステップを実行するように設計されていることを特徴とする請求項８に記載のサービスポータルシステム。