 |
||||||||||||||
|
||||||||||||||
| 1 2 3 次のページ | ||||||||||||||
|
||||||||||||||
| リファレンスアーキテクチャをカバーするNexaweb | ||||||||||||||
|
前回はWeb 2.0の意味について、アーキテクチャの視点か考えてみました。またEW 2.0（エンタープライズ Web 2.0）に対して、企業レベルでの課題を解決するリファレンスアーキテクチャがどのようなものなのかも説明しました。そこで今回は、リファレンスアーキテクチャのサービス利用層がどのように構成されるかについて説明します。 またあわせてEW 2.0アプリケーションのプラットフォームであるNexawebを紹介し、Nexawebがリファレンスアーキテクチャをどのようにカバーしているかを紹介しましょう。 |
||||||||||||||
| サービス利用層のサポートレベル（各レベルの責務） | ||||||||||||||
|
まず最初にサービス利用層のサポートレベルを説明します。図1は前回説明したEW 2.0リファレンスアーキテクチャです。  図1：エンタープライズWeb 2.0リファレンスアーキテクチャ （画像をクリックすると別ウィンドウに拡大図を表示します） このアーキテクチャでは、クライアント／通信／サーバサイドにおいて、それぞれ様々な開発言語や通信の方法（リクエスト／レスポンス、パブリッシュ／サブスクライブ、非同期通信、サーバプッシュなど）が利用されています。この現状を基に、サービス利用層をユニバーサルクライアントとインターネットメッセージングバス、エンタープライズマッシュアップサーバという3つのサービスレベルに統合していました。 このEW 2.0リファレンスアーキテクチャのサービス利用層における3つのサポートレベル（Client Tier、HTTP Web Tier、Service Logic）を実装するのに必要となるランタイムのインフラとは、どのようなものなのかを表1で説明します。
表1：サポートレベルを実装するために必要なもの 通信のサポートレベル(サービス配送のためのInternet Messaging Bus)の、リライアブル（信頼性のある）メッセージングを例にとると、送信を保障するメッセージングには、下記のような要素が必要となります。
表2：送信を保障するメッセージング要素
そもそもEW 2.0リファレンスアーキテクチャは、高いレベルの抽象化を提供するものです。そのため開発者はリファレンスアーキテクチャを利用することで、プラットフォームの互換性のみならず、異なる言語による実装や通信、サーバサイドの実装に関する問題から開放されることでしょう。そして、ビジネスの要求定義と設計、実装にフォーカスすることに注力できます。 このように、リファレンスアーキテクチャが提示するサービス利用層を設計に採用することで、容易にシステムを統合することが可能となるのです。つまりサービス利用層を採用したアーキテクチャでは、複数のプラットフォーム上にデプロイするためにわざわざアプリケーションを書き直したり、統合するためにプログラムを新たに作成したりする必要がなくなることを意味します。 |
||||||||||||||
|
1 2 3 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
