Worklight アダプターと「Worklight: リソース・ハンドラー」パターン

Worklight アダプターは、Worklight モバイル・アプリケーション・プラットフォーム上にデプロイされ、このプラットフォームによってサービスが提供されるアプリケーションのサーバー・サイド・コードです。アダプターは Worklight Server をエンタープライズ・アプリケーション (WebSphere Message Broker で実行されるアプリケーションなど) に接続します。アダプターが、プロシージャーと呼ばれるサービスのセットを公開します。アダプターとモバイル・アプリケーションが Worklight Server にデプロイされます。

パターンの動作を示す図。

以下の手順は、モバイル・アプリケーションによって発行される HTTP/JSON 要求の標準的なデータ・フローを概説しています。

モバイル・デバイスから Worklight へ

  1. モバイル・アプリケーションが、Ajax 要求 (WL.Client.invokeProcedure) を発行して、プロシージャーを呼び出します。
  2. プロシージャーのパラメーターが、JSON 形式のデータとして渡されます。パラメーターには、アクセスするリソースの JSON 表現が含まることや、セキュリティーが有効な場合には、ユーザー ID とパスワードの base64 ストリング表現が含まれることがあります。

Worklight

  1. プロシージャーが、JSON オブジェクトに対して実行するアクションの名前などの追加情報で、このオブジェクトを拡張します。

Worklight から Message Broker へ

  1. プロシージャーが HTTP コマンドを呼び出し、HTTP 基本認証ヘッダー内にユーザー ID とパスワードを組み込みます。

Message Broker

  1. Message Broker 内の要求ハンドラーのメッセージ・フローが、HTTP 要求を処理します。
  2. 要求ハンドラーのメッセージ・フローが、LDAP サーバーに照らしてユーザー ID とパスワードを認証します。
  3. 要求ハンドラーのフローが、JSON オブジェクトから追加情報を取り出し、その情報を使用して、リソースのどのインスタンスに対してどのアクションを実行するのか判別します。
  4. 要求ハンドラーが、LDAP サーバーに照らして要求を許可します。当該リソースに対して当該アクションを実行できる正しい LDAP グループにユーザー ID が属しているかどうか、妥当性検査されます。
  5. 要求がリソースの読み取りの場合、要求ハンドラーのフローはリソース・インスタンス ID を使用して、リソースのこのインスタンスがキャッシュに入れられているかどうかを検査します。
  6. 要求ハンドラーのフローが、アクセスされるリソース・インスタンスの固有 ID をローカル環境 ($LocalEnvironmentVariables/Worklight/ID) に取り込みます。
  7. JSON ドメイン・メッセージが、正しいプロシージャー・ハンドラーのサブフローに伝搬されます。このメッセージの構造は、モバイル・アプリケーションによって WL.Client.invokeProcedure API に渡される JavaScript オブジェクトと一致します。
  8. サブフロー・ロジックが実行されます。通常、これには JSON オブジェクトをバックエンド・サービスやデータベースに対する要求に変換することが含まれます。
  9. サブフローが、応答 JSON メッセージを出力ターミナルに伝搬します。
  10. アクションが読み取りで、キャッシュが使用可能な場合は、要求ハンドラーのメッセージ・フローが JSON オブジェクトをキャッシュに書き込みます。
  11. アクションが更新か削除の場合は、要求ハンドラーのメッセージ・フローが、リソースのこのインスタンスをキャッシュから削除します。

Message Broker から Worklight へ

  1. JSON 応答が、Message Broker から Worklight アダプターへ、HTTP 応答として送り返されます。

Worklight からモバイル・デバイスへ

  1. JSON 応答が、Worklight Server から元のモバイル・アプリケーションへ、HTTP 応答として送り返されます。

「Worklight: リソース・ハンドラー」パターンの仕様に戻る