wiki:Archtectural Overview Deployment

Version 5 (modified by KOBAYASHI, Shinji, 11 years ago) (diff)

--

TOC PREV NEXT?

この文書はArchtectural Overview13 Deploymentの翻訳である。正確性については保証しないので,適宜原文を参照すること

13 デプロイ

13 Deployment

13.1 5層システム・アーキテクチャー

13.1 5-tier System Architecture

前章までで、openEHR仕様のソフトウェア・アーキテクチャーについて記述した。ここで、実際のシステムを構築するためにパッケージ・アーキテクチャーがどのように適用できるのかについて記述しよう。どのようなopenEHRシステムにおいても、一般的なアーキテクチャー・アプローチは5層 (すなわち"5ティア"アーキテクチャー) として考えることができる。これらの層は以下の通りである。

Previous sections have described the software architecture of the openEHR specifications. Here we describe how the package architecture can be applied to building real systems. The general architectural approach in any openEHR system can be considered as 5 layers (i.e. a "5-tier" architecture). The tiers are as follows.

  1. パーシステンス: データの格納と抽出
  2. バックエンド・サービス: EHR、デモグラフィック、用語体系、アーキタイプ、セキュリティ、レコードのロケーション等を含む。この層では、異なるサービスの分離は透過的であり、各サービスは粒度の荒いサービス・インターフェースを持っている。
  3. 仮想EHR: この層はミドルウェアであり、関連するサービスへのアクセスを提供するさまざまなバックエンド・サービスへの一貫したAPIセットを持っている。これによりユーザーは、EHR、デモグラフィック、セキュリティ、用語体系、及びアーキタイプ・サービスを含むEHRへのアクセスが可能となる。ここにはアーキタイプ駆動及びテンプレート駆動のカーネルも含まれ、このコンポーネントはアーキタイプ駆動データの生成と処理の役割を担う。この層にでは、バックエンド・サービスの分離は隠蔽されており、機能だけが開示される。バックエンド・サービスの他の組合わせのためのAPIを含め、他の仮想クライアントも可能である。
  4. アプリケーション・ロジック: この層は、ユーザー・アプリケーションやクエリ・エンジンのような別のサービスといった、なんであれアプリケーション固有のロジックから成る。
  5. プレゼンテーション層: この層は、それが利用可能な場合に、アプリケーションのグラフィカル・インターフェースから成る。
  1. persistence: data storage and retrieval.
  2. back-end services: including EHR, demographics, terminology, archetypes, security, record location, and so on. In this layer, the separation of the different services is transparent, and each service has a coarse-grained service interface.
  3. virtual EHR: this tier is the middleware, and consists of a coherent set of APIs to the various back-end services providing access to the relevant services, thereby allowing user access to the EHR; including EHR, demographics, security, terminology, and archetype services. It also contains an archetype- and template-enabled kernel, the component responsible for creating and processing archetype-enabled data. In this tier, the separation of back-end services is hidden, only the functionality is exposed. Other virtual clients are possible, consisting of APIs for other combinations of back-end services.
  4. application logic: this tier consists of whatever logic is specific to an application, which might be a user application, or another service such as a query engine.
  5. presentation layer: this layer consists of the graphical interface of the application, where applicable.

大規模なデプロイでは、同一層を図37に示すように用いることもできるし、単純に1台の機械上で動くアプリケーションの層として用いることもできる。

The same tiers can be used in large deployments, as shown in FIGURE 37, or simply as layers in single-machine applications.

図38は、openEHRソフトウェア・アーキテクチャーの主要部分の5層スキーマへのマッピングの概略を示している。アーキテクチャーの各部が使用される際には、さまざまな実装上の選択肢に依存することは明らかである。それゆえ、ここで示したマッピングは、絶対的なものではない。ではあるが、アーキテクチャーの各部の主要な使い方は、たいていのシステムでは以下のようなものになるであろう。

  • RM and AM: 主としてアーキタイプ処理及びテンプレート処理カーネルを構築するために使用される。
  • RM common.change_control パッケージ: EHRやデモグラフィックのようなバージョン付きサービスにおけるバージョニング・ロジックを提供する。
  • SM: 各種のサービスモデル・パッケージが主要なサービスの公開インターフェースを定義する。
  • SM virtual_ehr パッケージは、仮想EHRコンポーネントのAPIを定義する。
  • アーキタイプ: アーキタイプは直接いくつかのアプリケーションになるものと想定されている。たとえば、周産期スペシャリスト・パッケージは、この専門分野のアーキタイプ系列に部分的に依拠していると想定される。
  • テンプレート: アーキタイプとテンプレートは、アプリケーションのプレゼンテーション層で使用されるであろう。GUIコードをかぶせる場合と、特定のテンプレートやアーキタイプに基づいてツールでコードを生成したり、ダイナミックにフォームを生成させる場合とがあろう。

FIGURE 38 illustrates an approximate mapping of major parts of the openEHR software architecture to the 5-tier scheme. Clearly where parts of the architecture are used will depend on various implementation choices; the mapping shown is therefore not definitive. Nevertheless, the principal use of parts of the architecture is likely to be similar in most systems, as follows:

  • RM and AM: mainly used to construct an archetype- and template-processing kernel;
  • RM common.change_control package: provides the logic for versioning in versioned services such as the EHR and demographics;
  • SM: various service model packages define the exposed interfaces of major services;
  • SM virtual_ehr package defines the API of the virtual EHR component;
  • archetypes: archetypes might be assumed directly in some applications, e.g. a specialist peri-natal package might be partly based on a family of archetypes for this specialisation;
  • templates: both archetypes and templates will be used in the presentation layer of applications. Some will base the GUI code on them, while others will have either tool-generate code, or dynamically generate forms based on particular templates and archetypes

将来的には、openEHRは、データベースの実装を支援するべく、抽象永続化APIと最適化された永続化モデル(既存のRMモデルの改変) とを発表したいと考えている。

In the future, an abstract persistence API and optimised persistence models (transformations of the existing RM models) are likely to be published by openEHR in order to help with the implementation of databases.

Attachments (2)

Download all attachments as: .zip