この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
6 取引機能のエンタープライズ仕様
エンタープライズ仕様の範囲は RM-ODP で定義されています3: アーキテクチャ (ITU-T Rec. X.903 | ISO/IEC 10746-3 を参照)このエンタープライズ仕様は、取引機能の活動を管理する目的とポリシー ステートメントを特定します。
取引機能の目的は、特定の特性を持つ特定のタイプのサービスのインスタンスを提供および発見する手段を提供することです。
貿易コミュニティは、貿易業者、輸出業者、輸入業者など、さまざまな役割を持つメンバーで構成されています。オブジェクトは、同じコミュニティ内で複数の役割を持つことができます。たとえば、オブジェクトはインポーターとエクスポーターの両方になることができます。
コミュニティの取引活動は、サービスの輸出とサービスの輸入です。これらの活動は、取引コミュニティの一連のポリシーによって管理されています。サービスのインポート活動は、ある取引コミュニティから別の取引コミュニティに伝播する可能性があります。このような場合、これらの 2 つのトレーダーに関連付けられたドメインは連合されます。これらのトレーダー ドメイン境界は、他のドメイン境界 (タイプ ドメインまたはセキュリティ ポリシー ドメインなど) と一致する場合があります。
ポリシーは、特定の目的を持つ一連のルールです。各ルールは、共通の目的と一致するトレーダーの行動のいくつかの側面を制限します。取引コミュニティのメンバーは、ポリシーのルールに従う義務があります。これらの規則は、コミュニティの目的を満たすための決定のガイドラインを提供します。ルールは、この仕様では規定されていません。エンタープライズ仕様は、トレーダーの特定のタイプの行動を制限する一連のポリシーを識別します。特定されたポリシーは、トレーダー オブジェクトの動作を実装または構成できるフレームワークを提供します。
6.1 コミュニティ
6.1.1
取引コミュニティ
単一の取引コミュニティ (抽象化の 1 つのレベルで) は、第 2 のより詳細な抽象化レベルで、多数の相互に作用する取引コミュニティに洗練される場合があります。コミュニティ ポリシーに従い、詳細レベルでの取引コミュニティの相互作用は、単一の抽象的なコミュニティの印象を維持することができ、1 つのサブコミュニティでトレーダー、輸入業者、または輸出業者の役割を持つオブジェクトが他のサブコミュニティのオブジェクトと相互作用できるようにします。
6.2 役割
オブジェクトは、取引コミュニティ内で次の役割を果たす場合があります。
6.2.1
トレーダー
エクスポーター オブジェクトからサービス オファーを登録し、要求に応じて、いくつかの基準に従ってインポーター オブジェクトにサービス オファーを返す役割。
6.2.2
輸出業者
サービスの提供をトレーダー オブジェクトに登録するロール。
6.2.3
輸入業者
トレーダー オブジェクトから、いくつかの基準を満たすサービス オファーを取得するロール。
6.2.4
トレーダー管理者
トレーダー オブジェクトのトレーダー ポリシーを定義、管理、施行する役割。トレーダー管理者は、トレーダー ドメイン (トレーダーとそのサービス オファーのセット) の制御オブジェクトです。
6.2.5
サービス提供
サービスの説明を維持する役割。
注記 1:この記述は、将来の契約の基礎となる可能性があります。
6.3 活動
次のアクティビティは、取引コミュニティに関連しています。
6.3.1
サービス輸出
取引業者オブジェクトが輸出業者オブジェクトのサービス提供を輸入業者オブジェクトのグループに提供することを許可されている関係を確立および終了する、輸出業者オブジェクトおよび業者オブジェクトによるアクションの連鎖。
6.3.2
サービス輸入
インポーター オブジェクトとトレーダー オブジェクトの間のアクション チェーン。インポーター オブジェクトは、いくつかの基準を満たす多数のサービス オファーを取得します。
6.4 ポリシー
トレーディング コミュニティ内のエンタープライズ オブジェクトの動作は、トレーディング コミュニティのポリシーによって管理されます。一部のポリシーは取引活動を管理し、一部のポリシーは、コミュニティの共通の目的と一致して、トレーダーの行動の他の側面や取引コミュニティにおける他の役割に制約を課します。アクティビティがオブジェクト間の相互作用を伴う場合、結果として得られるポリシーは、相互作用するオブジェクトのポリシー間の妥協になります。和解は、仲裁の形で達成されます。
注 —たとえば、トレーダー オブジェクトは、検索を 2 リンクの深さまで伝搬する義務があるようなポリシーによって管理される場合がありますが、検索を 1 リンクの深さまで伝搬した後に検索を終了することも許可されます。トレーダー オブジェクトが、検索のためにトラバースされるリンクの深さに関するインポーターの要件を満たすことが許可されている (または義務付けられている) 場合、競合するポリシー間で調停するためのいくつかのルールが必要です。
6.4.1
輸出活動方針
ポリシーには、特に次のものが含まれる場合があります。
- サービス提供を特定の方法で説明する義務。
- 特定のサービス インポート活動がサービス オファーを発見することの禁止。
- サービス インポート アクティビティの一部として評価されるルールを提供するサービス オファーの義務。
6.4.2
輸入活動方針
ポリシーには、特に次のものが含まれる場合があります。
- 活動期間を含め、リソースの使用を制限する義務。
- サービスのインポートを 1 つ以上の相互に作用する取引コミュニティに伝播する権限。
6.4.3
仲裁方針
ポリシーには、とりわけ、以下に関するトレーダー オブジェクトのルールを支持して仲裁する義務が含まれる場合があります。
- サービスのインポート中のリソースの使用。
- サービス インポート アクティビティの伝播。
6.4.4
サービス提供承諾ポリシー
トレーダーが受け入れる一連のサービス オファーを制限する一連のルール。
6.4.5
タイプ管理ポリシー
型の指定と型間の関係に関する一連の規則。
注記1方針は、これらの側面のいずれかまたは両方に関して、タイプリポジトリ機能に従うことである場合があります。
注記 2:例としては、名前の等価性を使用すること、または型の一致で署名のサブタイプを使用することが挙げられます。
6.4.6
検索ポリシー
取引システムを通じて適切なサービス オファーを検索するための一連のルール。
6.5 構造化ルール
6.5.1 コミュニティルール
トレーディング コミュニティには、トレーダーの役割を担うオブジェクト (トレーダー オブジェクト) が必要です。トレーディング コミュニティのメンバーになると、オブジェクトはインポーターまたはエクスポーターの役割でトレーダー オブジェクトと対話できます。オブジェクトは、エクスポーターの役割、インポーターの役割、またはエクスポーターとインポーターの両方の役割を引き受けることができます。
「エンタープライズ」には、複数の取引コミュニティが含まれる場合があります。オブジェクトは、複数の取引コミュニティのメンバーになることができます。あるコミュニティのトレーダー オブジェクトは、それがメンバーである別のコミュニティ内で輸入者または輸出者の役割を引き受ける場合があります。
コミュニティは、セキュリティ、タイプ、管理、報酬などに関して複数のドメインにまたがる場合があります。
各トレーダーは、一連のサービス オファーとともに、トレーダー ドメインです。したがって、取引コミュニティ内で相互運用する一連のトレーダー ドメインは、トレーダーの連合です。
注 —フェデレーテッド トレーダー ドメインは、エンジニアリングの観点から、境界にインターセプターを配置する必要があるとは限りません。
6.5.2 転送ルール
エクスポーター オブジェクトは、独自のインターフェイスで提供するサービスのオファーをエクスポートしたり、個別のサービス プロバイダー オブジェクトによって提供されるサービスのオファーをエクスポートしたりできます。
インポーター オブジェクトは、独自に使用するため、または個別のサービス ユーザー オブジェクトで使用するために、サービス オファーをインポートできます。
6.5.3 権限規則の記述
取引コミュニティの各トレーダー管理者オブジェクトは、独自のトレーダー オブジェクトを完全に制御できます。
エクスポーター オブジェクトは、そのサービス オファーの正確性に責任を負います。
トレーダーが確立されたトレーダー連合のメンバーになるには:
- あるトレーダーは、別のトレーダーによって開始された活動を実行する義務を負いません。
- 各トレーダーは、自分のトレーダー ポリシーに関して完全な自律性を持たなければなりません。
特に、各トレーダーは、相互に作用するトレーダーのグループに対して独自のトレーダー検索ポリシーを決定します。
6.5.4 サービス品質ルール
トレーダー オブジェクトは、サービス オファーに記載されているサービスの品質について責任を負いません。
トレーダー オブジェクトは、サービス オファーのタイムリーな削除を保証する義務を負う場合があります。
注 —これを達成するための 2 つの例は次のとおりです。
- 1)トレーダー サービス オファーの受諾ポリシーは、サービス オファーに有効期限を設定することを義務付ける場合があります。 trader オブジェクトは、期限切れのサービス オファーを削除することが許可されています。
- 2)トレーダー インポート ポリシーは、トレーダー オブジェクトがインポート時に期限切れになったサービス オファーを返すことを禁止する場合があります。
6.5.5 マッチングルール
サービスのインポートには、計算インターフェースの署名タイプのチェックが必要です。さらに、サブタイプまたはスーパータイプの関係、動作の互換性、および環境上の制約について、さらにレベルのチェックを行うこともできます。企業、情報、エンジニアリング、およびテクノロジーの側面に関するさらなるチェックも提供される場合があります。
6 Enterprise specification of the Trading Function
The scope of an enterprise specification is defined in RM-ODP 3: Architecture (see ITU-T Rec. X.903 | ISO/IEC 10746-3). This enterprise specification identifies the objectives and the policy statements that govern the activities of a trading function.
The objective of the trading function is to provide the means to offer and to discover instances of a particular type of service, with particular characteristics.
A trading community is comprised by members that have different roles, for example, trader, exporter and importer. An object can have several roles within the same community. For example, an object can both be an importer and an exporter.
The trading activities of the community are service exports and service imports. These activities are governed by a set of policies of the trading community. A service import activity may propagate from one trading community to another. In such a case the domains associated with these two traders are federated. These trader domain boundaries may coincide with other domain boundaries (e.g. type domain or security policy domain).
A policy is a set of rules with a particular objective. Each rule constrains some aspects of a trader’s behaviour consistent with the common objective. Members of the trading community are obliged to obey the rules of the policies. These rules provide the guidelines for decisions to satisfy the community’s objectives. The rules are not prescribed in this Specification. The enterprise specification identifies the set of policies that limit the trader in certain type of behaviour. The policies identified provide a framework within which the trader object's behaviour may be implemented or configured.
6.1 Communities
6.1.1
trading community
A single trading community (at one level of abstraction) may be refined into a number of interworking trading communities at a second, more detailed level of abstraction. Subject to community policy, the interworking of trading communities at the detailed level is able to maintain the impression of the single abstract community, allowing objects with trader, importer or exporter roles in one subcommunity to interact with objects in any other subcommunity.
6.2 Roles
Objects may play the following roles within a trading community.
6.2.1
trader
A role which registers service offers from exporter objects and returns service offers upon request to importer objects according to some criteria.
6.2.2
exporter
A role which registers service offers with the trader object.
6.2.3
importer
A role which obtains service offers, satisfying some criteria, from the trader object.
6.2.4
trader administrator
A role which defines, manages, and enforces the trader policy of the trader object. The trader administrator is the controlling object of a trader domain (the trader and its set of service offers).
6.2.5
service offer
A role which maintains a description of a service.
Note 1 to entry: The description may be the basis of a future contract.
6.3 Activities
The following activities are relevant to a trading community.
6.3.1
service export
A chain of actions by an exporter object and the trader object which establish and terminate a liaison in which the trader object is permitted to provide the exporter object's service offer to a group of importer objects.
6.3.2
service import
A chain of actions between an importer object and the trader object in which the importer object obtains a number of service offers which meet some criteria.
6.4 Policies
The behaviours of enterprise objects within a trading community are governed by the policies of the trading community. Some policies govern trading activities, and some policies place constraints on other aspects of behaviour of a trader and other roles in the trading community, consistent with the common objective of the community. Where an activity involves interactions between objects, the resulting policy will be a compromise between the policies of the interacting objects. The compromise will be reached via a form of arbitration.
NOTE — For example, a trader object may be governed by policies such that it is obliged to propagate a search to a depth of 2 links, but it is also permitted to terminate a search after propagating a search to a depth of 1 link. If the trader object is permitted (or obliged) to meet an importer’s requirement regarding depth of links to be traversed for a search, then there is a need for some rules to arbitrate between conflicting policies.
6.4.1
Export activity policy
The policy may include, amongst other things:
- an obligation for a service offer to be described in a specific way;
- a prohibition of specified service import activities from discovering the service offer;
- an obligation for a service offer providing rules to be evaluated as part of a service import activity.
6.4.2
Import activity policy
The policy may include, amongst other things:
- an obligation to limit the use of resources, including duration of activity;
- permissions to propagate the service import to one or more interworking trading communities.
6.4.3
Arbitration policy
The policy may include, amongst other things, an obligation to arbitrate in favour of the trader object’s rules on:
- use of resources during service import;
- propagating service import activities.
6.4.4
Service offer acceptance policy
A set of rules restricting the set of service offers that will be accepted by the trader.
6.4.5
Type management policy
A set of rules related to the specification of types and the relationship between types.
Note 1 to entry: The policy may be to defer to a type repository function with respect to either or both of these aspects.
Note 2 to entry: Examples would be to use name equivalence or to use signature subtyping in type matching.
6.4.6
Search policy
A set of rules guiding the search for suitable service offers through the trading system.
6.5 Structuring rules
6.5.1 Community rules
In a trading community there must be an object which assumes a trader role (a trader object). Becoming a member of a trading community enables an object to interact with the trader object in an importer or an exporter role. An object may assume the exporter role, the importer role, or both the exporter and importer roles.
An"enterprise" may include multiple trading communities. An object can be a member of multiple trading communities. The trader object of one community may assume an importer or exporter role within another community of which it is a member.
The community may span several domains with respect to security, types, management, remuneration, etc.
Each trader, along with its set of service offers, is a trader domain. Thus, a set of trader domains which interoperate within a trading community is a federation of traders.
NOTE — Federated traders domains do not always require interceptors placed at their boundary in the engineering viewpoint.
6.5.2 Transfer rules
Exporter objects can export offers for services which they provide at their own interfaces, or may export offers for services provided by a distinct service provider object.
Importer objects can import service offers for their own use, or for use by distinct service user objects.
6.5.3 Delineation of authority rules
Each trader administrator object of a trading community has complete control over its own trader object.
The exporter object is responsible for the accuracy of its service offers.
For traders to be a member of an established federation of traders:
- one trader is not obliged to perform an activity initiated by another trader;
- each trader must have complete autonomy with respect to its own trader policies.
In particular, each trader determines its own trader search policies over the group of interworking traders.
6.5.4 Quality of service rules
The trader object is neither accountable nor responsible for the quality of services described in service offers.
A trader object may be obliged to ensure the timely removal of service offers.
NOTE — Two examples for achieving this are:
- 1) A trader service offer acceptance policy may oblige service offers to have an expiry date. The trader object is permitted to remove expired service offers.
- 2) A trader import policy may prohibit the trader object from returning service offers which have expired at the time of an import.
6.5.5 Matching rules
A service import requires computational interface signature type checking. It can, in addition, involve further levels of checking for subtype or supertype relationships, behavioural compatibility and environment constraints. Further checking on enterprise, information, engineering, and technology aspects may also be provided.