プロキシ サービスを通過するメッセージの処理を定義するパイプライン ステージまたはメッセージ フロー ノードの要素。AquaLogic Service Bus のメッセージ フローのステージやノードでサポートされるアクションの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
BEA の新しい AquaLogic サービス インフラストラクチャ製品ファミリの一部。AquaLogic Service Bus は、エンタープライズ システムでのメッセージのルーティングとトランスフォーメーションを管理します。モニタ機能と管理機能が統合されているため、1 つのソフトウェア製品でサービス指向アーキテクチャ (SOA) の実装とデプロイを行うことができます。
AquaLogic Service Bus Console
管理者が BEA AquaLogic Service Bus アプリケーションに必要なエンティティとリソースをコンフィグレーション、管理、およびモニタするための、HTML ベースのグラフィカル ユーザ インタフェース。AquaLogic Service Bus Console は、管理サーバにホストされる Web アプリケーションです。AquaLogic Service Bus をサポートするドメインを作成した後、そのドメインを使用して AquaLogic Service Bus ソリューションの管理に固有のタスクを実行します。
非同期メソッド、または同期メソッドとコールバックを非同期で使用することで、非同期の機能を提供する Web サービス。非同期 Web サービスの対話は、サーバからの応答を待つ間にクライアントが他の処理を実行することができるように設計されています。サーバは、応答が準備できた時点でクライアントに通知します。非同期アーキテクチャは、イベントを受け取るたびに受信側が処理するイベント駆動型のシナリオで便利です。
同期 Web サービス (synchronous web service) を参照。
AquaLogic Service Bus メッセージ フローで実装されない、AquaLogic Service Bus に登録済みの任意のサービス。会話定義とのインタフェースです。たとえば、トレーディング パートナは対話を希望する他のトレーディング パートナに対してビジネス サービスを提供します。プロキシ サービス (proxy service) を参照。
クラスタ化によって、BEA AquaLogic Service Bus をサーバのグループで実行でき、そのグループを単体のユニットとして管理できます。クラスタ環境では、複数のマシンが負荷を分担します。AquaLogic Service Bus にはロード バランシング機能があるので、リソース要求はすべてのマシンに均等に分散されます。AquaLogic Service Bus デプロイメントは、クラスタ化とロード バランシングを使用してノードに負荷を分散させることにより、スケーラビリティを向上できます。クラスタ化により、単一サーバよりもスケーラビリティの高いデプロイメント プラットフォームを構築できます。
新しい AquaLogic Service Bus ドメインの作成を容易にする対話型グラフィカル ユーザ インタフェース (GUI)。AquaLogic Service Bus ドメインの適切なディレクトリ構造、基本的な config.xml ファイル、およびドメイン内のサーバを起動するためのスクリプトを作成できます。
コンテキスト変数 (context variable)
AquaLogic Service Bus メッセージ コンテキストは、メッセージが AquaLogic Service Bus を介してルーティングされるときにメッセージ コンテキストとメッセージに関する情報を保持する一連のプロパティ。これらのプロパティはコンテキスト変数と呼ばれ、たとえば、サービス エンドポイントに関する情報は事前定義されたコンテキスト変数によって表されます。
統合ソリューションを正しくデプロイするために必要な役割。デプロイメント スペシャリストは、デプロイメント作業を調整します。そのため、BEA AquaLogic Service Bus 製品の機能に精通している必要があります。デプロイメント スペシャリストは、1 つまたは複数のサーバにさまざまな AquaLogic Service Bus 機能をコンフィグレーションしてきた経験を基に、専門知識を活かして、統合型ソリューションのデプロイメント トポロジを設計します。デプロイメント スペシャリストには、以下の分野の経験が要求されます。
2 つのエンティティ間で交換されるデータのセキュリティを、各エンティティの ID を検証することによって保護するためのビット文字列。特に、レコードの送信元エンティティからのデータが途中で変更されていないことを検証する場合に使用されます。デジタル署名は、エンティティの署名付きデータとプライベート キーから計算されます。デジタル署名は、確認に使用される公開鍵に信頼性がある場合のみ信頼できます。
ドキュメント定義 (document definition)
有効なドキュメントの必要条件を指定する文書型定義 (Document Type Definition : DTD) などのスキーマ。AquaLogic Service Bus のドキュメント定義は XML DTD で提供されます。各ドキュメント定義には、システム ID (DTD システム識別子) と、ドキュメント定義の場所を指定する URL という 2 つの属性があります。
eXtensible Stylesheet Language Transformations (XSLT)
XML ドキュメントを別の XML ドキュメントに変換するために設計された XML 言語。XSLT ドキュメントまたはスタイルシートは、XML ドキュメントのノードに対して実行されるデータ トランスフォーメーションを記述します。XSLT を使用して、XML ドキュメントをさまざまなテキスト フォーマット (XML、HTML、PDF など) に変換できます。
AquaLogic Service Bus メッセージ コンテキストは、メッセージが AquaLogic Service Bus を介してルーティングされるときにメッセージ コンテキストとメッセージに関する情報を保持する一連のプロパティ。これらのプロパティはコンテキスト変数と呼ばれ、たとえば、サービス エンドポイントに関する情報は事前定義されたコンテキスト変数によって表されます。AquaLogic Service Bus は、ユーザ定義のコンテキスト変数もサポートします。メッセージ コンテキストは、XML スキーマで定義されます。
BEA によって作成された XML 言語。非 XML データのネイティブ表現と階層を記述します。MFL は非 XML データの XML 記述です。MFL ドキュメントには、非 XML データのコンテンツを説明および制限するスキーマが含まれます。COBOL コピーブックや C 構造体定義のデータはその一例です (MFL ファイルは、Format Builder を使用して作成され、拡張子は .mfl になります)。
最上位のグループ構造体。階層化されず、それぞれが独立しています。1 つのプロジェクト内にすべての AquaLogic Service Bus リソース (サービス、WS-Policy、WSDL、XQuery トランスフォーメーションなど) が格納されます。膨大な数のエンティティがあるドメインの場合も、プロジェクトとフォルダで分類しておくと、参照しやすくなります。
要求を別のサーバで処理するために別のサーバに送信するサーバ。WebLogic Server では HTTPProxyServlet で HTTP 要求の仲介をサポートしています。WebLogic Server の Netscape Server Application Programming Interface (NSAPI) や Internet Server API (ISAPI) プラグインを介して、Netscape や Microsoft Internet Information Server (IIS) から WebLogic Server のインスタンスにプロキシ処理を行うことができます。プロキシ サーバを使用していることはエンド ユーザには見えません。
AquaLogic Service Bus エンティティ (ビジネス サービス、ポリシー、WSDL、MFL ファイル、プロキシ サービス、プロキシ サービス プロバイダ、スキーマ、サービス アカウント、WS-Policy、XQuery トランスフォーメーション、XSLT トランスフォーメーションなど)。
再試行回数 (retry count)
メッセージの送信が失敗した場合の、再送信の試行回数。デフォルトは 0 です。
再試行間隔 (retry interval)
メッセージ受信確認の待機中にタイムアウトが発生した後、メッセージを再送信するまでの期間。
ロールベースの認可 (role-based authorization)
特定のリソースに対して特定のアクションを実行するためのパーミッションや権限をエンティティに付与すること。ロールベースの認可の場合、リソースにアクセスする権限のあるロールがセキュリティ ポリシーで定義されます。AquaLogic Service Bus Console では、特定の管理特権とモニタ特権に関連付けられている組み込みのロールの他に、リソースへのアクセスを制御するセキュリティ ポリシーをコンフィグレーションできます。プロセス操作を呼び出すのに必要なロールを定義するポリシー、およびアプリケーション ビューのサービスを実行してイベントをサブスクライブするのに必要なロールを定義するポリシーをコンフィグレーションできます。管理者は、アクセスに必要なロールを設定したら、必要に応じてそのロールにユーザまたはグループをマップできます。
アプリケーションがある範囲の要求を満たす能力。スケーラビリティを備えたアプリケーションは、クライアントの要求が増大しても可用性とパフォーマンスの要件を満たします。WebLogic Server クラスタはロードバランシングやフェイルオーバなどの機能によって、ホストするアプリケーションのスケーラビリティを向上します。
AquaLogic Service Bus ソリューションをデプロイするときの目標の 1 つ。デプロイメントでは、コード変更ではなく、ハードウェア リソースの追加により、予期される負荷の増加に対処できなければなりません。
スキーマ (schema)
データの構造およびコンテンツの定義。たとえば、データベース スキーマはデータベース インスタンスのテーブルおよびその他の要素を定義し、XML スキーマは XML ドキュメントの構造およびコンテンツを定義します。AquaLogic Service Bus のスキーマは、有効、無効、または未解決のいずれかです。有効 (valid)、無効 (invalid)、および未解決 (unresolved) も参照。
スキーマ名 (schema name)
XML スキーマに割り当てられたユニークな名前。
スキーマ ネームスペース (schema namespace)
XML スキーマに含まれる定義を修飾するために使用されるネームスペース。
セキュリティ (security)
データの破壊や窃盗を防止するために利用可能なメカニズムのセット。
AquaLogic Service Bus ソリューションをデプロイするときの目標の 1 つ。デプロイメントでは、権限のないアクセスやデータの改ざんからデータを確実に保護できなければなりません。
AquaLogic Service Bus 環境で、ACL、プリンシパルの名前、および関連するセキュリティ サービスへのアクセスを提供する一連のセキュリティ機能のドメイン。レルムでは、セキュリティ処理と、AquaLogic Service Bus ユーザを管理するその他のセキュリティ関連情報の範囲を定義するコンテキストが提供されます。ユーザの認証方法を規定します。AquaLogic Service Bus で利用できるセキュリティ機能は、WebLogic Server で提供しているセキュリティ機能をベースにして実現されています。
セキュリティ プロバイダ (security provider)、ユーザ (user)、および WebLogic リソース (WebLogic resource) を参照。
2 つのデータ型の間のマッピングを記述したもの。AquaLogic Service Bus は、XQuery または eXtensible Stylesheet Language Transformation (XSLT) 標準のどちらかを使用したデータ マッピングに対応しています。XSLT マップは、XML から XML へのマッピングを記述するのに対して、XQuery マップでは、XML から XML、XML から非 XML、非 XML から XML へのマッピングを記述できます。
トランスフォーメーション メソッド (transformation method)
クエリを呼び出すメソッド。
転送認証またはセキュリティの種類 (transport authentication or security type)
AquaLogic Service Bus Console でのスキーマの状態。現在の WSDL に含まれているすべてのスキーマまたは WSDL の場所が指定済みで有効である場合、スキーマは有効です。ただし、ネスト スキーマまたはネスト WSDL (含まれている WSDL またはスキーマに続き設定されているスキーマまたは WSDL) についてもすべての場所が指定され、それらが有効な状態です。
– W –
Web サービス (Web service)
言語やプラットフォームに依存しない自己記述型のコード モジュール。アプリケーションは、ネットワークまたはインターネットを介して Web サービスにアクセスします。アプリケーションでは、サービスの場所をハードコード化しておくことも、UDDI (Universal Description, Discovery, and Integration) を使用してサービスを検索することもできます。Web サービスは自己記述型なので、利用するアプリケーション側で、利用可能な関数や呼び出し方法を特定できます。
Web サービス ポリシー (Web Service Policy : WS-Policy)
XML ベースの拡張フレームワーク。Web サービスのコンフィグレーションにドメイン固有のアサーションを拡張し、Web サービスの要件、期待される条件、および機能を指定します。AquaLogic Service Bus における WS-Policy の主な使用方法の 1 つとして、プロキシ サービスおよびビジネス サービスでの、セキュリティ ポリシー文によるメッセージレベル セキュリティのコンフィグレーションがあります。WS-Policy の仕様はまだ標準化されていないので、AquaLogic Service Bus では、WS-Policy 仕様に準拠した WebLogic Server 独自の形式をサポートしています。
Web Services Description Language (WSDL)
Web サービス (AquaLogic Service Bus の場合、プロキシまたは外部サービス) を形式的に記述するための XML ベース仕様のマークアップ言語。これによってさまざまなクライアントでサービスを呼び出すことができます。2 つの別々のオンライン システムで人手を介さずに通信する必要がある場合は、WSDL が必要になります。WSDL は Web サービスの内容、場所、呼び出し方法の記述に使用されます。WSDL ドキュメントではネットワーク サービスの定義に以下の要素が使用されます。
WebLogic Server は、サーブレット、JSP ページ、エンタープライズ JavaBean などの J2EE コンポーネント テクノロジを実装します。WebLogic Server アプリケーションを構築するには、必要に応じてこれらのサービス API を使用して、コンポーネントを作成し組み立てる必要があります。コンポーネントは、WebLogic Server の Web コンテナまたは EJB コンテナ内で実行されます。Web コンポーネントは、ブラウザベースの J2EE アプリケーションにプレゼンテーション ロジックを提供します。EJB コンポーネントは、ビジネスのオブジェクトやプロセスをカプセル化します。
WebLogic Server 製品の一部として BEA によって提供されるセキュリティ プロバイダ。これらのプロバイダは、セキュリティ サービス プロバイダ インタフェース (SSPI) を使用して WebLogic Server 向けに開発されています。
WebLogic Server
Java 言語および J2EE プラットフォーム (Sun Microsystems, Inc. の) を使用して、電子商取引アプリケーションを構築し実行するためのサービスを提供する、BEA の Web アプリケーション サーバ。WebLogic Server は標準に準拠して Pure Java で記述されたアプリケーション サーバで、分散 Java アプリケーションの作成、デプロイメント、管理を行うことができます。WebLogic Server はアプリケーション コンポーネントと DBMS 接続を管理して、セキュリティ、スケーラビリティ、パフォーマンス、およびトランザクションの整合性を確保します。また、エンタープライズ JavaBean (EJB)、RMI、分散 JavaBean、および JDBC など、分散コンポーネント サービスや企業内データベースへのアクセスに対するサポートも提供します。WebLogic Integration、WebLogic Portal、および WebLogic Workshop など、BEA WebLogic Platform の全コンポーネントは、WebLogic Server 上で動作します。
WebLogic Server Administration Console
管理者がブラウザから WebLogic Server をコンフィグレーションしモニタするための HTML ベースの GUI。
ドメイン内の管理サーバによってホストされる Web アプリケーション。Web ブラウザを介して管理サーバと通信できるローカル ネットワーク上の任意のマシンから、このコンソールにアクセスできます。このコンソールを使用すると、管理者は、JMX API や基底の管理アーキテクチャについて学習しなくても WebLogic Server のコンフィグレーションとモニタ タスクを実行できます。
WebLogic Server 管理者 (WebLogic Server administrators)
WebLogic Server 管理者は、組織内の WebLogic Server デプロイメントに関する技術と操作について深い知識を持っていることが要求されます。ハードウェアとプラットフォームの知識を持ち、WebLogic Server のインストール、コンフィグレーション、モニタ、セキュリティ、パフォーマンス チューニング、トラブルシューティングなど、WebLogic Server デプロイメントのすべての管理作業に関する経験が要求されます。
