BSA / Integration and Extension at the Business Logic Layers

BSA

ビジネスロジック層でのインテグレーションと拡張（Integration and Extension at the Business Logic　Layers） †

要約 †

• APIを作成するなら、プラットフォーム選択、マーケットセグメント選択、パートナー選択、命名規則、セキュリティとセッションデータ、顧客が必要とするものだけを公開する、明確にオプションを理解する、ことを考慮する。
• 登録を通じた拡張では、登録モデルを定義する、イベントモデルを定義する、実行制御動作（Execution、リソース管理ポリシーを定義する、エラーを考慮する。

内容 †

図8-3インテグレーションと拡張の技術

技術とコントロールの場所 †

• 拡張のインテグレーションを行う際には、これらの機能を作成するために利用される技術と、そのコントロールの場所を区別することが重要だ。
• 技術については簡単だ。うまく設計されたサービスアーキテクチャと設計モデルは、ターゲットマーケットによって必要とされるものは何でも技術サポートすることができるはずだ。

• コントロールの場所は、よりいくらか難しい。一般的には、呼び出し元かシステムのいずれかがコントロールしている。呼び出し元がコントロールしているとき、それらは結果を生成し提供するサービスとしてアプリケーションを扱っている。その呼び出しは、ブロッキングもしくは非ブロッキングかもしれず、またステータスを提供しない場合もある。
• システムがコントロールしているときは、ほとんどの場合呼び出し元がシステムに機能のいくつかの側面を登録するか、コールバックモデルかのいずれかを使用している。そうしてシステムは事前に定義されたイベントによって、この機能を起動する。これらの2つのアプローチは、次のセクションでより詳細に説明する。

APIを介したインテグレーション †

• アプリケーション・プログラミング・インターフェース（API）は、他のシステムの開発者に1つ以上の機能を公開する。これらは、他の開発者が主要なコントロールの場所のアプリケーションを作成しているという考えに基づく。システムは、適切なものを介してアクセスされるサービスのセットになる。
• 前述の原則に従って、アプリケーションを構築しているなら、ユーザがシステムの機能にアクセスできるようにするAPIを作成するのは通常簡単だ。最も直接的なアプローチは、サービス層を露出させること。場合によっては必要な他の層を露出させることだ。これはデータベースに直接アクセスを可能にするよりビジネスロジックをバイパスしているので、はるかに優れている。

APIを作成するなら、次の事を考慮しなさい。

プラットフォーム選択 †

• C言語ベースのインターフェイスはユニバーサルな選択かもしれないが、それぞれのプラットフォームで最高の働きをするものは異なる。MS Windowsでアプリケーションを作成している場合は、ほぼ確実にCOMベースのインターフェイスを提供したいと思うだろうが、他のプラッフォームではJ2EEのアプローチやEJBを必要とするかもしれない。

マーケットセグメント選択 †

• プラットフォームによってAPIに働く圧力加え、異なるマーケットセグメントは１つあるいは別のアプローチのための選択を提示するかもしれない。あなたがイノベーターと作業している場合は、インテグレーションあるいはシステムを拡張するための最も革新的なアプローチを使用する良いチャンスだ。この本の執筆のように、これはWebサービスを提供することを意味する。他のマーケットセグメントは、異なるアプローチを要求することができる。

パートナー選択 †

• 2章では、増大する製品の作成に有力なパートナーを特定するために、コンテキスト図の重要性を議論した。あなたのパートナーは、インテグレーションのための独自の好みを持っているだろう。それらを理解することは、彼らの支持を獲得する可能性が最も高いインテグレーションと拡張アプローチを作成するのに役立つ。

命名規則 †

• もしも、あなたが馬鹿げたAPIを提供するベンダーでイライラしたことがあるなら、あなたは賢明な名称と構造化されたAPIを作成する動機のすべてを持っているに違いない。簡単にAPIを使用できることが、あなたの最善の利益であることをおぼえておこう。

セキュリティとセッションデータ †

• 多くのビジネスアプリケーションでは、ログインしてアプリケーション（セッション）に働きかけるユーザーの概念に基づいて、ステートフルなデータを管理する。セッションデータに依存するアプリケーション用のAPIを開発することは、そうでないアプリケーションの開発よりも難しい。タイムアウトやセキュリティプロトコルなどのセッション関連パラメータを規定し管理するための手段を顧客に提供する必要がある。また、関数が呼び出されるように、セッションデータを管理するための設備が必要な場合がある。

顧客が必要とするものだけを公開する †

• 全てのAPIを気前よく公開することには注意しなさい。あなたが公開するすべてのものは、維持する上での作業を増やす。公開されている関数は、顧客に同じ価値を提供することもほとんどなく、すべてが必要とされているわけでもありません。複雑なシステムでは、異なる操作は、異なるパフォーマンスプロファイルを示し、システム・リソースに対して異なる要求が作られる。一部のAPIは、実行に時間がかかる複雑な機能を呼び出すことができ、適切に訓練できている場合にだけ使用すべきかもしれない。
• ターキテクトは、マーケテクトとともに、ターゲットマーケットのための理にかなった最小のAPIセットを定義することを慎重に取り組むべきだ。なぜなら、セキュリティアクセスコントロールを通して可能な限り管理された
• 内部使用のためのものと、インテグレーション/拡張のためといった、検討して解決すべきたくさんの構成要素が存在するかもしれない。

コラム：タイミングがすべて †

• あなたのドキュメント（この章で後述）は、セッション管理が明確に顧客に提示されていることを確認する必要があります。マルチユーザーでWebベースのアプリケーションの、バグだけではない、厄介なバグの追跡を助けたのを覚えています。各ログインユーザーはセッションを表していた。セッションは貴重なサーバリソースを消費するので、そしてそれぞれが1同時ユーザーとしてカウントするので、強制的に非アクティブまたはエラーの場合にユーザーをログオフするように設定することができる、セッションタイムアウトパラメータを関連づけていた。
• アプリケーションは、システム管理者に、特定のユーザーIDでに様々なアプリケーション機能を関連付けることを許可している。したがって、「ユーザID 1」は「ユーザID 2」とは動作の異なるセットを実行することができる。私たちのAPIは、規則に従って構築された。特に、サーバによって提供される機能を使用したいアプリケーションは、ちょうど人間のユーザのようにそれにログインすることを余儀なくされた。これは、外部アプリケーションに使用を許可する機能のセットを制御することをシステム管理者に可能にした。
• 顧客非アクティブの20分後にセッションを期限切れにセッションタイムアウトパラメータを設定していたが、それで、ずっとセッションを持続することを期待してアプリケーションが記述されました！正常のと、「プログラマチック」のユーザーとが、同じトランザクション・モデルにアクセスしていたので、両方ともが同じセッション管理の制に捉えられた。そのセッションが期限切れになった場合に当面の問題を解決するために、顧客は、再度ログインするようにアプリケーションを変更した。彼らは、このソリューションに不満だったので、最終的にセッションタイムアウトをユーザーごとに設定することができるようにすることで、それらを適合させた。顧客は、彼らの外部アプリケーションを表現するユーザーIDに関連付けられたセッションタイムアウトパラメータを変更し、すべては望んだとおりに動いた。

APIは、複数のリリースを超えて安定する †

• 製品の最初のいくつかのリリースに必要なAPIを予測することは困難であり、初めてでそれを正しく得ることは稀なことだ。適切なAPIを安定化させるためにいくつかのリリースが必要な場合がある。

明確にオプションを理解する †

• アプリケーションがAPIで簡単に使用できない特定の機能を提供するかもしれない。
• APIを使用して何ができて、何ができないのかを述べることは、顧客やシステム統合コンサルタントが複雑な問題にアプローチする最良の方法を決定を簡単にさせる。

登録を通じた拡張 †

• 登録は、アプリケーションの機能がシステムにコンポーネントまたはコールバック関数を登録する開発者によって拡張されるプロセスだ。APIを介してのインテグレーションとは異なり、システムが依然としてコントロールを維持したまま、事前定義されたイベントで登録コンポーネントを呼び出す。登録はオブザーバーデザインパターンまたはメッセージ・キューイング・システムのパブリッシュ・サブスクライブ・モデルに関係しますが、同じではない。登録を使用する時、アプリケーションは実際に登録されたコンポーネントに制御を渡す。後者では、あなたのアプリケーションは、イベントの他のコンポーネントに通知はするが、コントロールを引き渡さない場合がある。登録に基づく拡張の素晴らしい例は、その機能が明確に定義されたプラグインを使って拡張することができるWebブラウザだ。正しいMIMEタイプが検出されたとき、アプリケーションの制御が適切に登録されたプラグインに転送される。登録ベースのAPIは、コールバック、リスナー、プラグイン（Webブラウザなど）そしてイベント通知メカニズムが含まれている。登録ベースのソリューションを提供する場合は、以下を考慮する。

登録モデルを定義する †

• いつどのようにこれらのコンポーネントが登録されアップデートされるのか、登録可能コンポーネントを作成するために使用することができる言語に関する詳細な技術情報を開発者に提供しなさい。一部のアプリケーションでは、プラグインが特定のディレクトリにされ、プラットフォーム固有のバイナリモデルに従うことを要求している。他のアプリケーションは、すべてのコンポーネントが設定ファイルを介して自分自身を登録している必要がある。いくつかはアプリケーション実行中に登録されたコンポーネントを変更することができる。他方は新しいまたは更新されたコンポーネントのアプリケーションを再起動する必要がある。あなたは、ちょうどあなたが選択したそれらを明確にしているするだけの、選択肢を持っている。

イベントモデルを定義する †

• 開発者が利用可能な特定のイベントは、それらが発生した場合、通知メカニズムの形式、とコールバックで提供される情報を、すべての開発者が利用できるようにする必要がある。

実行制御動作（Execution Control Semantics）を定義する †

• 実行制御動作は、ブロッキングまたはノンブロッキングコール、スレッドまたはプロセス管理、および外部コンポーネントに関連付けられているすべての重要なタイミング要件などを参照する。いくつかのアプリケーションは、同一のプロセス空間内での要求を処理するためにプラグインに制御を転送する。他のものは、別のプロセスを起動して、プラグインにコントロールを渡す。まだ他のものは、結果を待つブロックとシンプルな機能として登録コンポーネントを呼び出します。

リソース管理ポリシーを定義する †

• プロビジョニングから管理およびリカバリまでの資源管理に関するすべての決定は、定義する必要がある。アプリケーションや、そのインテグレーションの成功に必要なものは、メモリ、ファイルハンドル、処理能力、および帯域幅など制限なしに、影響を与える可能性があるすべてのリソースを考慮してください。

エラー/例外プロトコルを定義する †

• アプリケーションでのエラーと例外は、多くの場合、他のアプリケーションにAPIを介して伝播しなければならない。もしかしたら変換セマンティクスを定義する必要もあるかもしれない。つまり、何らかの「エラー」は別のアプリケーションでは「例外」であるかもしれない。

担当者のつぶやき †

みんなの突っ込み †