この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、SCAS Service Configuration APIを使用してSCAS BBのサービス設定作業を自動的に行う方法を説明します。この章の目的は次のとおりです。
• SCAS Service Configuration APIの主な要素を紹介します。
• SCAS Service Configuration APIの使用法、サービス コンフィギュレーションの作成、編集、メンテナンス、管理、および配布機能について説明します。
• SCAS Service Configuration APIの使用法を示すコード例を示します。
• 「Service Configuration APIの概要」
サービス コンフィギュレーション は、プロバイダーのネットワーク上でService Control Application Suite for Broadbandシステムによって実施されるプロバイダーのビジネス ルールを表します。 Service Configuration API は、 サービス コンフィギュレーション のプログラミング実装を担うプログラミング エンドです。
サービス コンフィギュレーションを取り扱う作業にService Configuration APIを使用します。SCAS BB Consoleは、Service Configuration APIのプログラミング ツールで作成されています。このAPIを使用すると、GUIでは手作業で行うことになる定常的なサービス設定作業を、自動的に行うことができます。
サービス コンフィギュレーションの定義からSCEプラットフォームでコンフィギュレーションをアクティブ化するまでの、Service Configuration APIによる主なプログラミング ステップは次のとおりです。
ステップ 1 新しいサービス コンフィギュレーションを定義するか、またはSCEから既存のサービス コンフィギュレーションを取得します。
ステップ 2 サービスを定義して、サービス名を割り当てます。
ステップ 4 サービス エレメントを定義し、それらのエレメントにプロトコル、方向、およびリスト(オプション)を割り当てます。
ステップ 6 パッケージを定義して、パッケージ名を割り当てます。
ステップ 7 パッケージのサービス ルール(違反前および違反後における帯域幅の制限、サービスのイネーブル化またはディセーブル化など)を定義します。
ステップ 8 サービス コンフィギュレーションをSCEに伝播してアクティブ化します。
SCAS Service Configuration APIを使用して行う主な作業は、サービス コンフィギュレーションの作成および処理です。これには、オフラインで行うことができるサービスとルールの定義が含まれます。サービス コンフィギュレーションが完成すると、SCEプラットフォームにそのサービス コンフィギュレーションを伝播できます。
上記の各ステップについて、以下の各項で詳しく説明します。この章を『 Subscriber Management API Reference Manual 』と併せて参照することで、SCAS BBサービス コンフィギュレーションを作成、編集、管理、および配布できるようになります。
アプリケーションの作成および取り扱いに使用する、主なSCAS APIクラスを次の表に示します。
|
|
クライアント プログラムがシステムのハードウェアおよびソフトウェアに接続できるようにします。ネットワーク接続機能を実行する、エレメント管理作業の出発点です。 |
|
SCAS Javaプログラムなどのクライアント アプリケーションが、SCEプラットフォームに接続できるようにするためのSCAS API Javaクラスは、 Engage
です。
SCAS Java APIクラスを取り扱うには、Java JDKバージョン1.3以降が必要です。
次のJARファイルがJava class-pathに含まれている必要があります。
これらのファイルは、SCASクライアントのインストレーション プロセスの一環としてワークステーションにインストールされます。このインストレーションは、SCAS BB製品に付属するSCAS BB クライアント インストレーションCD-ROM を使用して行います。
SCASクライアントを C:\Program Files\Cisco\SCAS BB x.x.x\
フォルダにインストールした場合、これらのJARファイルはすべて C:\Program Files\Cisco\SCAS BB x.x.x\lib
フォルダにあります。
(注) 上記のJARファイルのバージョンは、SCAS BBソリューションの他のコンポーネントのバージョンと統一されている必要があります。ソリューションの新しいバージョンをインストールまたはアップグレードした場合には、API開発者向けJARファイルも必ずアップグレードしてください。
SCAS Java APIを使用するには、事前にSCAS Javaパッケージをインポートする必要があります。プログラムの先頭に次のコード行を追加して、インポートします。
SCEプラットフォームからサービス コンフィギュレーションを取得したり、SCEプラットフォームにサービス コンフィギュレーションを適用したりするには、プラットフォームに接続する必要があります。この接続を可能にするSCASクラスが、通信およびネットワーク アクティビティの調整を行います。
このクラスの login
メソッドは、永続的な接続を提供します。このメソッドでは、ユーザ名、パスワード、および接続するSCEのホスト名が必要です。メソッドのいずれかのパラメータが不正な場合、例外が発生します。サービス コンフィギュレーションの取得または適用が終了した時点で、接続を閉じる必要があります。
(注) 作業の終了時に、必ずlogout
メソッドをコールしてください。SCEへの接続をオープンのままにしないでください。また、取得や適用のたびに新しい接続を作成するのではなく、Connectionオブジェクトをできるだけ再利用してください。
login
メソッドは、永続的な login
接続を確立した後で行う Service Configuration APIコールのための基本的なパラメータ値を確立します。このメソッドは、 Connection
タイプのオブジェクトを返します。このオブジェクトは、 Service Configuration APIの大部分で使用されるSCEのハンドルです。
connection = Engage.login(se, user, password, Connection.SE_DEVICE); }catch (ConnectionFailedException e) |
SCEとの接続は、終了しないかぎり開いた状態が継続します。SCEとの接続を終了するには、次のように logout
メソッドを使用します。
SCAS Service Configuration APIはサービス コンフィギュレーションのさまざまな編集タスクを実行しますが、サービス コンフィギュレーションを編集している間はSCEに接続する必要はありません。つまり、サービス コンフィギュレーションはオフラインで準備することができます。サービス コンフィギュレーションの編集が完了したら、SCEに接続してサービス コンフィギュレーションを伝播できます。
前項では、SCAS APIを使用してSCEに接続(ログイン)および接続を終了(ログアウト)する方法を説明しました。そのほかに実行できる操作としては、サービス コンフィギュレーションの新規作成、サービス コンフィギュレーションの適用などがあります。適用とは、SCEプラットフォームにサービス コンフィギュレーションを伝播して、ネットワーク上でアクティブ化できるようにすることです。
Javaの PolicyAPI
クラスが、SCAS Service Configuration APIのサービスの出発点となります。
以下の各項で、パッケージ、サービス、サービス エレメント、プロトコル、リスト、およびルールに対して実行できるさまざまな操作の方法を説明し、擬似コードの例を示します。サービス コンフィギュレーションの一連のコンポーネントは、最終的にパッケージにアセンブルしてSCEに伝播します。ここで説明する内容は次のとおりです。
• サービス コンフィギュレーションのインポート、エクスポート、および作成
プロバイダーのネットワークで、サービス コンフィギュレーションに変更を加える場合には、現在使用しているサービス コンフィギュレーションを変更するのが一般的です。変更を行うには、SCEからサービス コンフィギュレーションを 取得 して、編集作業を行う必要があります。 サービス コンフィギュレーション の編集はオフラインで行い、SCEに伝播できる状態にします。 サービス コンフィギュレーション を伝播することを、サービス コンフィギュレーションの 適用 という場合もあります。これは、サービス コンフィギュレーションの元の内容を上書きして、SCEプラットフォーム上で新しいビジネス ルールをアクティブ化することを意味します。
サービス コンフィギュレーションの取得およびSCEへの適用を行うための、2つの主なサービス コンフィギュレーション メソッドである retrievePolicy
および applyPolicy
を、次のコード例で示します。
// retrieve a service configuration PolicyAPI.retrievePolicy(connection); PolicyAPI.applyPolicy (connection, myPolicy, SCAS.APPLY_FLAG_OVERWRITE); |
retrievePolicy()
メンバー関数の2番めのパラメータ SCE には、1台または複数のService Controlプラットフォームを定義できます。 SCAS.Policy
を取得したあと、サービス コンフィギュレーションの内容の検査、変更、保存など、さまざまな機能を実行できます。
SCASアプリケーションを開発するとき、いくつかの便利な機能を利用してSCAS Service Configuration APIアプリケーションを確認できます。たとえば、Javaアプリケーションでサービス コンフィギュレーションを変更する場合、 savePolicy
メソッドを使用して、サービス コンフィギュレーションの内容をファイルに保存できます。その後、SCAS Service Configuration Manager GUIアプリケーションを使用してこのファイルを開き、アプリケーションで変更したサービス コンフィギュレーション エレメントを検証できます。
SCEプラットフォームから既存のサービス コンフィギュレーションを取得するだけでなく、テキスト ファイルを通じてサービス コンフィギュレーションを取得することもできます。次に、サービス コンフィギュレーションをインポートする例を示します。
サービス コンフィギュレーションのエクスポートは、アーカイブの目的で、またはサービス コンフィギュレーションを後で編集する場合に行います。次に、サービス コンフィギュレーションをエクスポートする例を示します。
String filename = "policy.pqb"; PrintStream print = new PrintStream(new FileOutputStream(new File(filename))); ImportExportUtils.exportPolicy(policy, ImportExportUtils.XML_FORMATTER, print); |
一般的には既存のサービス コンフィギュレーションを修正して新しいサービス コンフィギュレーションを作成しますが、必要に応じてサービス コンフィギュレーションを最初から新規作成することもできます。 Policy
クラスのコンストラクタで、 new
演算子を使用してサービス コンフィギュレーションを作成します。次に、このようなサービス コンフィギュレーションの作成例を示します。
ここでは、リストの使用例を示します。有害な内容のWebサイトのリストを作成し、既存のサービス コンフィギュレーションのリスト アレイに追加します。この例で作成するリスト名は Offensiv e Content Website List であり、リスト要素を追加しています。最後にこの新しいリストを、サービス コンフィギュレーションのリスト アレイに追加します。後の段階で、このリストに含まれるホスト名に関しては HTTP Browsing Protocol でサービスをアクセスできないようにするルールを実施できます。
Hostlist
クラスのコンストラクタでは、パラメータ リスト name
およびオプションの description を指定します。リストに新しい要素を追加するには、 HostList クラスの add メソッドを使用します。次のように、 getListArray メソッドを使用して listArray を取得し、新しく作成したリスト offensiveList をリスト アレイに追加します。
getListArray メソッドにより、タイプ ListArray のリスト アレイを取得します。リスト アレイを取得したあと、リスト サイズを調べたり、リストの個々の要素を取得したりすることができます。
次の行で、 listArray の要素を反復的に取得しています。
for (int i = 0; i < listArray.getSize(); i++) |
上記のループによって、 listArray の各要素が返されます。 getSize メソッドは、 ListArray のサイズを返します。リストの個々の要素の getElementAt メソッドにより、 Object が割り当てられます。
getElementAt メソッドによって返されるオブジェクトは、 HostList クラスまたは IPRangeList クラスのインスタンスである可能性があります。 IPRangeList は、IP範囲のリストです。次に、このメソッドを使用してリストのタイプを判別する例を示します。
HostList hostlist = (HostList) o; System.out.println("Host List"); IPRangeList iplist = (IPRangeList) o; |
リストのグループの最初のリストを取得したと仮定すると、 www.cnn.com ( http://www.cnn.com )がリストに追加されます。
SCEプラットフォームは、サービスに対応付けられたネットワーク トランザクションのプロトコルに反応します。サービス コンフィギュレーションにはサービスのリストが含まれます。サービスのプロトコルを作成する方法としては、プロトコルを新しく定義する方法と、既存のプロトコルを拡張してポートを追加する方法の2通りがあります。また、プロトコルを定義するダイナミック シグニチャ スクリプトをインポートまたは削除することもできます。以下の各項では、次の事項について説明します。
プロトコルの認識は、一般的なネットワーキング慣例に基づいて行われます。たとえば、サーバがポート666でトランザクションを待ち受ける場合、ポート666はタイプDOOMのプロトコルを待ち受けるのが慣例となっています。提供するサービスに関して慣例に従うと、双方にとって便利です。
次に、 quake という名前のプロトコルを、ポート26000、トランスポート タイプTCPで定義する例を示します。
上記の例では、 myPolicy という名前のサービス コンフィギュレーションの参照が存在し、 Protocol クラスのコンストラクタのパラメータとして渡されていることを前提としています。このコンストラクタによって返される quakeProtocol の参照を使用して、プロトコルの名前を設定します。
次の行では、プロトコルのポート番号26000、トランスポート タイプTCPを指定しています。
quakeProtocol.add(new PortListItem(26000, Consts.TRANSPORT_TYPE_TCP)); |
次の行では、このプロトコルをサービス コンフィギュレーションのプロトコル リストに追加しています。
使用されていない ポート を、既存のプロトコルに 追加 できます。基本的にそのポートはそのプロトコルに対応付けられ、プロトコルの範囲が拡張されます。
次に、サービス コンフィギュレーションのプロトコル リストを取得し、HTTP Browsingという名前のシステム定義プロトコルを検索する例を示します。このプロトコルを見つけたあと、ポートを追加してプロトコル定義を拡張します。
この例では、 HTTP Browsing という名前のプロトコルが存在することを前提としています。次の行で、 Protocol クラスの getProtocol メソッドにより、プロトコル アレイを表すハンドルが返されます。
クラス Protocol の add メソッドでは、ポート番号およびトランスポート タイプを指定する必要があります。上記の例では、ポート8082をトランスポート タイプTCPで、既存のサービス HTTP Browsing に追加しています。次の行で、プロトコルにポートを追加します。
http.add(new PortListItem (8082, Consts.TRANSPORT_TYPE_TCP)); |
サービス HTTP Browsing が拡張されました。ポート8082で配信されるHTTPトランザクションをサービス ルールによって処理するには、この拡張が必要です。
次に、2つのサービス エレメントのあるサービスを作成する例を示します。この例は、1つの サービス に複数の サービス エレメント の対応付けが可能であることを示しています。
作成するサービス エレメントの1つはDoom、もう1つはQuakeというゲームです。どちらも有名なゲームで、これらを Gaming Service というサービスに追加します。
次の行で、 Service
を含むクラスをインスタンシエートしています。
Service gamingService = new Service (myPolicy); // create a service |
myPolicy
という名前の Policy
参照が、 Service
コンストラクタのパラメータとして渡されていることを前提としています。
gamingService.setName("Gaming Service"); // set service name |
gamingService.addProtocol("doom", |
このサービス エレメントは、サブスクライバ起動による doom プロトコルのすべてのネットワーク トランザクションに適用されます。ただし、特定のネットワーク アドレスに対して実行されたネットワーク トランザクションに限り、このサービス エレメントを適用するように指定することができます。それには、次のようにサーバ アドレスのリストをサービス エレメント付きで指定します。
最後のステップとして、サービス コンフィギュレーションにサービスを追加します。次の行で、サービス コンフィギュレーションに gamingService を追加しています。
(注) パッケージの定義は、ライセンスに依存します。ライセンスの容量制限により、そのライセンスで規定されているパッケージ数より多く定義することはできません。
ルールおよびパッケージの定義を始める前に、前述の手順に従って、サービスを定義し、サービス コンフィギュレーションにサービスを追加する必要があります。
次に、パッケージおよびルールを定義し、これらを使用するためのコード例を示します。1つのサービス コンフィギュレーションで、 Family Package および Bachelor Package という2つのパッケージを作成しています。
この例では、 Parental Watch List を含む Parental Watch Service を作成済みであることを前提としています。 Family Package では、 Parental Watch Service をイネーブルにします。このパッケージに加入するサブスクライバは、 Parental Watch List で定義されている検閲済みのコンテンツにアクセスできません。 Bachelor Package では、 Parental Watch Service をイネーブルにしないので、これらのサイトへのアクセスが認められます。
パッケージを作成するには、 new 演算子を使用します。次の行で、 Package を含むクラスをインスタンシエートしています。
新しいパッケージを作成したあと、次の行でパッケージに名前を付けています。
次の行で、レジデンシャルな getRule メソッドのパラメータで指定したルールの参照が返されます。
ServiceRule pw =residential.getRule("Parental Watch Service"); |
ネットワーク トランザクションに指定されている 制限 を超過すると、 違反 が発生します。サービスのルールを宣言するときに、違反を定義します。帯域幅の容量制限またはキロビット/秒(Kb/s)転送速度の制限を超過した場合や、サービスであらかじめ定義されているその他の制限を超過した場合を、違反とみなすことができます。違反を定義する目的は、このような制限に違反した場合に実行すべきアクションを指定することです。
ルールには、 違反前(pre-breach) および 違反後(post-breach) の2つのモードがあります。サービス ルールの制限に達しないときは pre-breachアクション が実行され、制限に達して超過したときには post-breachアクション が実行されます。
これらのアクションの例としては、帯域幅容量の制限、サービスの拒否、RDRレポートのトリガー、およびWebサイト リダイレクションがあります。すべてのpre-breachファンクション コール(メソッド)に、対応するpost-breachファンクション コールがあります。
違反はデフォルトの状態では非アクティブなので、違反をアクティブにしてから適用する必要があります。次の行で、 setPreBreachAccessMode メソッドのフラグをtrueに設定することにより、違反前の条件をアクティブにしています。
次に、FTPサービス用のルールを設定する例を示します。この例では、 FTP File Downloading という名前のサービスが存在することを前提としています。これらのルールにより、帯域幅は5 Kb/s、1日あたり100 MBに制限されます。どちらかの制限に達すると、サービスを禁止し、RDRをトリガーします。この例では、RDRは1日あたりの合計をレポートで使用すると指定しています。最後にサービス コンフィギュレーションを適用し、そのあとで接続を終了します。
上記の例でわかるように、総容量はサービス トランザクションで使用されたキロバイト数または使用されたネットワーク セッション数のどちらでも測定できます。どちらかの制限に達した時点で、サブスクライバの使用帯域幅レートを変更したり、レポート(RDR)を送信したり、サブスクライバをサービスから除外したりできます。
アグリゲーション 期間は、パッケージごとにグローバルで定義します。アグリゲーションは、RDRが作成されたときレポート生成に使用されます。アグリゲーションは、月、週、日、または時間ごとに測定できます。
同じサービスで、パッケージごとに異なるアグリゲーション期間を使用できます。つまり、1つのパッケージで FTP Download Service の1日あたりのトータルを指定し、同じ FTP Download Service を使用するもう1つのパッケージでは1時間あたりのトータルを指定することが可能です。このアグリゲーション(トータルでの使用状況に関する情報)は、サブスクライバ宛の項目別の請求書または取引明細書に利用できます。
次の行で、1日あたりのトータルを使用してRDRを生成することを指定しています。
residential.setAggregationPeriod (Package.AGGREGATED_PERIOD_DAILY); |
クォータの配分はパッケージごとに定義します。したがって、パッケージが2つのサービス(たとえば FTP Download Service および Video Conferencing Service )で構成される場合、アグリゲーションには両方のサービスの合計を反映させます。これはパッケージを設計する際に考慮すべき事項の1つです。
上記の例では、サービス コンフィギュレーションをオフラインで編集しているので、一連のコマンドは順不同です。したがって、変更後のサービス コンフィギュレーションをSCEのSCEプラットフォームに伝播するまで、コマンドは実行されません。
帯域幅コントローラ (別名メーター)は、特定のサービス トランザクションが使用している容量(Kbps)を測定するためのフロー ルール ベースの機能です。1フローのトランザクションでも、いくつかのフローを同時に使用するトランザクションでも測定可能です。帯域幅コントローラのルールは、フロー ベース ルール、時間ベース ルール、または両方の組み合わせにすることができます。
帯域幅コントローラには、方向性があります。帯域幅コントローラはそれぞれ、アップストリーム方向またはダウンストリーム方向のどちらかで容量を制御します。この方向はAPIで設定できます。
フロー数 (同時セッション数)およびそれらの合計の使用帯域幅レートがわかれば、プロバイダーがシステム サービスをより強力に制御して、ネットワーク リソースの利用方法に関してより影響を及ぼすことができるので便利です。たとえば、帯域幅コントローラの機能によって、サブスクライバが特定の帯域幅レートを超過しないかぎり、使用できるフロー数を無制限にするという指定が可能です。
ネットワーク トランザクションで使用されるフロー数を制御すれば、たとえばRTPSプロトコルを使用するインターネット ビデオ アプリケーションのデジタル ブロードキャストなどに役立ちます。RTSPは、ビデオ トラフィックのいくつかの同時フローを維持できます。帯域幅コントローラは、サブスクライバが特定のレート制限を超えないように指定するためのツールをプロバイダーに提供します。
次に、フロー レベルでの帯域幅コントローラ機能の使用例を示します。
// assigning BWController number 3 to the Rule in upstream direction ftpRule.getDefaultRule().setPreBreachUpstreamBWControllerIndex(3); |
違反 は、システムで指定された制限を超過した場合に発生します。違反が検出された場合に実行できるアクションは、2通りあります。それは、(a)サービスを禁止(ブロック)する、または(b)サブスクライバのトランザクションまたはサービスの配信方法に何らかの変更を加えることです。
したがって、システムには2タイプのレポート生成機能があります。それは、(a)ブロック レポート、または(b)違反レポートです。サービスで違反が発生するたびに、違反のタイプに応じてどちらかのレポートをトリガーするように、システムを設定できます。
違反が発生したときに、関数のパラメータをtrueに設定することによってRDRの作成をトリガーする例を次に示します。
ここでは、時間枠、デフォルトのルール、非デフォルトのルール、およびデフォルトのルール関数を使用する場合について説明します。
時間枠を使用すると、時間によって異なった動作を実行するルールを設定できます。時間枠の例としては、夕方の時間枠、夜間の時間枠、および週末の時間枠があります。SCASシステムでは、最大4つの時間枠を定義できます。
APIを使用して、時間枠の例外に基づいて情報を処理するアプリケーションを作成できます。たとえば、通常の曜日に基づくスケジュールでは週末料金が金曜日の午後4時54分から始まるのに対し、31日水曜日の午後3時から翌日の午後6時まで、無制限の帯域幅を使用できる週末料金のビデオ会議サービスのために時間枠を変更するアプリケーションなどです。
getDefaultRule メソッドを使用すると、そのルールはすべての時間枠に対してグローバルに適用されます。次に、 getDefaultRule メソッドを使用してグローバルな時間枠ルールを設定する例を示します。
非デフォルト ルールの例は次のとおりです。サブスクライバがサービスへのアクセスを拒否されるようにデフォルトのルールが定義されていると仮定します。さらに、2つの時間枠を作成したと仮定します。1つは平日の2200~0600であり、もう1つは金曜日の同じ時間帯です。平日の時間枠ではサービスへのアクセスを許可し、金曜日にはサービスへのアクセスを禁止するように、例外を作成できます。
次のコード例では、T1という1つの時間枠を作成しています。デフォルトのルールはすべての時間枠に適用されるので、時間枠T1を使用してその例外を設定し、定義した期間中はサービスへのアクセスを許可しています。
block-and-redirect 関数は、HTTP、RTSPなど、リダイレクトが可能なプロトコルを使用するサービスにのみ関係します。この関数を使用すると、サブスクライバがサービス パッケージに含まれていないサービスへのアクセスを試みた場合に、サブスクライバのトランザクションを別のネットワーク アドレスにリダイレクトできます。そのネットワーク アドレスまたはWebサイトで、サービスへのアクセス方法についての有益な情報を提供できます。
次の例は、ネットワーク プロバイダーがサブスクライバの内部ネットワーク内でホスティングされるゲーム アプリケーション サーバ上でサービスを設定する方法を示しています。この例では、テンプレートとしてDoomゲーム アプリケーションを使用しています。このJavaアプリケーションの機能は次のとおりです。
ステップ 1 新しいサービス コンフィギュレーションを作成します。
ステップ 2 Local Doom というサービス エレメントを定義します。
ステップ 3 Doomサービスをサブスクライバ起動にします。
ステップ 4 このJavaアプリケーションは、サービスをホスティングするサブスクライバ ネットワーク内のローカル サーバのIPアドレスのリストをマッピングします。
ステップ 5 Javaアプリケーションは、サブスクライバによるサービスへの接続時間に基づいて、課金レコードをトリガーします。