連載

Webと企業システムを結ぶ実践的アーキテクチャ
企業システムのeビジネス化における課題と解決法を探る


田坂光伸　日立製作所 ビジネスソリューション事業部
斎場正弘　日立製作所 ソフトウェア事業部
2001/6/1

---

Webアプリケーションサーバと呼ばれる技術カテゴリ、ミドルウェア製品が登場し、WebアプリケーションをWebとJavaを用いて構築する事例が増えています。J2EE（Java 2 Platform, Enterprise Edition）の各種機能およびアーキテクチャは、Webアプリケーションサーバシステムを構築するうえで、必要不可欠な部品とシステム構造を提供しているといえるでしょう。 ただ、一方で、統合された企業システムを実際に構築する局面においては、「J2EE」に登場する技術範囲だけではカバーできない問題点がいくつか存在します。それらは、J2EEの各種機能をどのように使えばよいのかというレベルの問題であったり、J2EE範囲外のシステム要件の問題であったりします。 本稿では、今回から数回にわたり、上記のような観点でいくつかのトピックを取り上げます。それぞれのトピックでは、Webアプリケーションサーバシステムを構築するうえで直面するだろう問題点と、それを解決するソリューションを論じます。ここで論じるソリューションは、ミドルウェア製品を積極的に活用することになりますが、本稿の目的は「おのおのの問題点をどのような考え方で解決すればよいか」ということを提示することにあります。

第１回　Webと企業システムをつなぐ現実的なアーキテクチャとは？

　第１回は、本連載で解説するWebアプリケーションサーバシステムの概観を紹介します。本稿の後半で紹介するシステムを構成する各要素について、第2回以降に詳しく解説していきます。

Webアプリケーションサーバシステムの定義

今回の内容

Webアプリケーションサーバシステムの定義 アーキテクチャの構成要素を整理する (1)J2EE (2)MVCモデル (3)画面遷移フレームワーク (4)データベースアクセスオブジェクト（DAO) (5)COBOLアダプタ (6)XMLミドル (7)ワークフローミドル (8)帳票ミドル

　本稿では、「Webアプリケーションサーバシステム」とは、Web（World Wide Web）をクライアントとサーバ間の接続手段に用いたサーバシステムのことを意味します。近年「Webアプリケーションサーバ」は、Webを用いたアプリケーションサーバを構築するためのミドルウェア製品を指す言葉語として用いられるようになってきました。一般に、サーバシステムの構成として、論理的に、Webサーバ、アプリケーションサーバ、データベースサーバの3層構成が考えられますが、「Webアプリケーションサーバ」はWebサーバおよびアプリケーションサーバの構築基盤としてのミドルウェアといえます（自明ですが、ここでの「Webサーバ」は単にHTTPサーバソフトウェアのことを指すのではなく、HTTPサーバを搭載したサーバ機を想定したものです）。一方で、「Webアプリケーションサーバシステム」は、Webアプリケーションサーバを用いて構築されたシステムのことを指すとします。

　図1は、Webアプリケーションサーバシステムの典型例を示しています。これは、ある企業の企業内システムで、複数の分散拠点がセンタサーバシステムとイントラネットで接続されたシステムを示しています。センタサーバシステムは、分散拠点からのHTTPリクエストを受け付けてHTTPレスポンスを返すWebサーバ、Webサーバから中継されたリクエストに対して業務処理を行うアプリケーションサーバ、業務処理からのデータ参照、データ更新を実施するデータベースサーバから構成されます。

図1　Webアプリケーションサーバシステムの例

　各分散拠点には、センタサーバシステムに対するクライアントが存在します。各クライアントは、センタサーバシステムに対して、申請、申請に対する承認といった業務を行います。また、クライアントは申請、承認された情報を参照するとき、業務処理において定められた帳票形式で表示したり印刷したりします。

　このような構成はいわゆるBtoCモデルを企業内システムに適用した例といえますが、インターネットを介したBtoCやBtoBのシステムでも同様の構成を適用して考えることができます。例えば、インターネットの一般顧客に対するインターネットショッピングサーバシステムでは、申請・承認という業務の代わりに、商品参照・購入という業務が実施されます。また、BtoBシステムでは、取引企業との間の発注・受注という業務が実施されることになるでしょう。

アーキテクチャの構成要素を整理する

　図2は、Webアプリケーションサーバシステムのサーバサイドのアーキテクチャを示しています。これは、論理的なソフトウェア構成を示したもので、ハードウェア構成については示していないことに留意してください。

図2　Webアプリケーションサーバシステムのアーキテクチャ

　このアーキテクチャは図1で示したサーバシステムの構成に従い、Webサーバ、アプリケーションサーバ、データベースサーバの3層から構成されています。また、Webアプリケーションサーバシステムとは別の既存システムとして「レガシシステム」が存在し、アプリケーションサーバと連携します。

　Webサーバは、HTTPサーバとHTTPサーバと連動して動作するアプリケーションコンポーネントのJSP、そしてServletから構成されます。Webサーバは、クライアントに対するプレゼンテーション層としての役目とともに、クライアントとアプリケーションサーバとの問い合わせ応答を中継する機能を有します。

　アプリケーションサーバは業務処理を実施します。業務処理の中心はアプリケーションコンポーネントEJBにより実装されます。また、アプリケーションサーバには、ワークフローミドルなど、それ以外の種々の要素が存在します。

　図2には示していませんが、クライアントの構成にもいくつかのバリエーションが考えられます。一般に、WebアプリケーションサーバのクライアントとしてはWebブラウザのみを備える構成が多く論じられていますが、WebブラウザをJava AppletやVisual Basicなどのクライアントアプリケーションプログラムと組み合わせた構成もシステム要件によっては検討すべき場合があります。後者の構成でも、クライアントアプリケーションとWebアプリケーションサーバの通信手段としてHTTPを用いることができます。この場合、HTTPサーバと連動するアプリケーションコンポーネントはServletとなり、主にアプリケーションサーバとの間の中継役に徹することになります。

　このアーキテクチャの特徴は、アプリケーションサーバの構成要素としてJ2EEのアプリケーションコンポーネントやサービスだけでなく、ほかの機能要素を組み込んでいることです。それらはワークフロー、帳票出力、XML-DB変換といった機能で業務アプリケーションの構築に必要になる各種サービスが、J2EEの範囲だけでなくほかのミドルウェアによっても提供されることを想定しています。また、アプリケーションの開発言語として、JavaだけでなくCOBOLを想定した構成になっています。

　では、図2に登場する各要素について概説しましょう。また、これらの内容のいくつかについては、その詳細を次回以降の連載で解説していきます。

(1)J2EE

　当アーキテクチャで、Webアプリケーションサーバシステムの基盤を構成するのは、もちろんJ2EEです。J2EEはServlet、JSP、EJBといったアプリケーションコンポーネントの仕様およびRMI（問い合わせ応答通信）、JNDI（ネームサービス）、JDBC（DBドライバ）、JTA（トランザクション制御）、JMS（非同期メッセージング通信）、JAXP（XMLパーサ）といったアプリケーションが用いる各種サービスの仕様を定めたものです。図2で「J2EE」は、J2EE仕様を実装したミドルウェア層を意味しています。これらの各機能について記述するのは本稿の趣旨ではありませんので省略します（「サーバサイドJavaテクノロジ 重点キーワード」、「WebアプリケーションにおけるサーバサイドJavaの効果的な利用」などを参照してください）。

　なお、J2EEにおいてはアプリケーションコンポーネントが既存のシステムやサービスと接続するための仕様「Connector」が策定されています。J2EEでは、既存のシステムやサービスをEIS（Enterprise Information System）と呼んでいます。当アーキテクチャにおいては、ワークフローミドルなどのJ2EE範囲外の各種サービスはEISに分類されるととらえており、EJBはそのようなサービスとConnectorにより接続することを想定しています。

(2) MVCモデル

　J2EEアプリケーションのアーキテクチャとしては、Sun Microsystems社自身が「Java 2 Platform, Enterprise Editionアプリケーション設計ガイド」（"J2EE Blueprints"とも呼ばれます）としてまとめているものが著名で、この中に登場するのが「MVCモデル」です。MVCはModel、View、Controllerの略で、MVCモデルは、Webアプリケーションサーバシステムを、Model（EJB)、View（JSP）、Controller（Servlet）の組み合わせで構成する考え方です。

　当アーキテクチャもMVCモデルを基本構成として採用しています。動作の概要は以下のようになります。まず、クライアントからHTTPリクエストが、Controller（Servlet）に対して送信されてきます。Controller（Servlet）は、リクエストに応じて適切な業務処理を実施するModel（EJB）を呼び、その応答に応じてView（JSP）を選択します。選択されたView（JSP）がWebページを生成して、HTTPレスポンスとして返信します。Modelは、EJBでなく、JavaBeansとして実装する構成もあり得ます。この場合は、Webサーバとアプリケーションサーバの層が分かれず、一体化される構成と考えればいいでしょう。

　さて、単純な構成ではシステムに唯一のController Servletが存在し、複数の業務ごとにModel（EJB）が存在すると考えられます。ここで、開発上の都合により複数のControllerを設ける構成にしてもよいと考えられます。また、業務ごとの画面シーケンスの各点ごとにViewを定めますが、一般に、複数のViewを条件により切り替えて生成するようなJSPを考えることもできます。

(3)画面遷移フレームワーク

　MVCモデルを用いたWebアプリケーションの実装手法は広く普及してきています。しかしMVCモデルにおいて、状況に応じたModelの選択、Viewの選択といった制御をどのように行うのかについては、明確な規則があるわけではありません。この制御モデルの1つの考え方は、MVCの振る舞いを、Controller Servletが呼ばれたHTTPリクエストの発生元画面を起点とし、最後に選択されるView JSPにより生成される画面を終点とする画面遷移ととらえることです。当アーキテクチャでは、このような概念に基づく画面遷移の制御を行う機能を「画面遷移フレームワーク」と呼びます。このトピックについては、次回以降に詳しく述べることにします。

(4)データベースアクセスオブジェクト(DAO)

　当アーキテクチャでは、アプリケーションプログラムからデータベースをアクセスするための共通層を設けることを想定しています。これをデータベースアクセスオブジェクト（DAO）と呼びます。

　J2EEアプリケーションでは、データベースの検索処理、更新処理をJDBCを用いて実装します。ここで、1つの考え方として、JDBCの詳細を隠ぺいしたデータベースアクセス層を設け、アプリケーションプログラマーには当データベースアクセス層を使わせるという手法が考えられます。

　一方、データベースのテーブルに相当するオブジェクトやそのファクトリを設け、当オブジェクトの検索、更新といったメソッドを呼ぶことにより、データベースの検索、更新の処理を実装するという手法が存在します。こういった手法は、一般に、オブジェクトリレーションマッピングと呼ばれますが、オブジェクト指向に慣れたプログラマーにとっては理解しやすい考え方といえます。

　DAOは上記の2つの考え方に沿ったもので、先のデータベースアクセス層をテーブルごとのオブジェクトを設けるようなインターフェイスにて実装する構成となります。

(5)COBOLアダプタ

　当アーキテクチャでは、業務処理の実装言語として、Javaだけでなく、COBOLを用いることも想定しています。COBOLを業務処理の実装に使い、クライアントへのプレゼンテーションにはJSP、業務処理への中継の実装にはServlet、EJBを用いるという構成です。このような構成を実現するために、図2では、JavaプログラムからCOBOLプログラムを呼び出す接続部品「COBOLアダプタ」を登場させています。

　COBOLアダプタには、以下のような狙いがあります。

• 既存COBOLプログラムの活用
  既存資産であるCOBOLプログラム部品を流用して、Webアプリケーションサーバシステムを構築できるようにします。既存システムの一部として使われていたCOBOLプログラムを、新規開発するWebアプリケーションサーバシステムの一部として使う場合に適当な考え方です。
  
  
• 新規開発におけるCOBOLの活用
  Webアプリケーションサーバシステムを新規開発したいが、業務処理はCOBOLプログラムにより実装したいという要件に適当な考え方です。背景として、Javaプログラマーが不足している場合にCOBOLプログラマーの活用を図るという狙いや、COBOL言語の特徴（メインフレームと同一精度の10進演算や、日本語による保守性の高いコーディングなど）を生かして開発を行いたいという要件が考えられます。 このトピックについては、次回以降に詳しく述べることにします。

(6)XMLミドル

　Webアプリケーションサーバシステムが受信するメッセージとして、XML形式のメッセージを用いる場合が考えられます。例えば、BtoBシステムにおいて企業間で交換される受発注データや、電子行政システムでの電子申請において申請書類がXML形式となっているような場合です。メッセージ形式としてXMLを採用する狙いには、DTDとXMLパーサによるメッセージ形式の定義・検証メカニズムがさまざまなプラットフォームで整備されておりその活用を図れること、XMLパーサや後述のXML-DB変換ミドルウェアのような変換ミドルウェアによりアプリケーションプログラムの拡張を図れることなどが挙げられます。また、種々の業務ドメインで業界標準形式がXMLにより規定されつつあるという動向も見逃せません。

　XMLをメッセージ形式として用いるWebアプリケーションサーバシステムでは、Webサーバにより中継されたメッセージがアプリケーションサーバに配送されます。アプリケーションサーバでは、受け取ったXML形式のメッセージについて、メッセージの形式検定や解析、データベースへの投入や反映、別形式のデータへの変換といった処理を行います。図2で、このような処理には、各種の「XMLミドル」を用いることができます。例えば、XML形式の検定やメッセージの解析にはXMLパーサが使えます。また、XML形式のメッセージをデータベースへ投入する処理には、XML-DB変換ミドルウェアが使えます。XML-DB変換ミドルウェアとは、XML形式のデータをタグごとにデータベースの各フィールドへ対応づけ、投入する機能を提供するものです。このトピックについては、次回以降に詳しく述べることにします。
（編集注：本稿では「ミドルウェア」を「ミドル」と省略しています）

(7)ワークフローミドル

　図1のWebアプリケーションサーバシステムの例で示したように、申請、承認といったような複数ユーザー間のワークフロー業務をWebアプリケーションとして構築する構成が考えられます。

　このようなワークフロー業務は、クライアントにおいて、ユーザーに割り当てられている案件の一覧（例えば、承認待ち案件一覧）を表示し、当ユーザーが案件一覧から処理したい案件を選択し、当案件の業務を実施するという流れで行われると考えることができます。業務処理では、ワークフローに沿って、次のユーザーに当案件が割り当てられるよう、当案件の状態を変更します。言い換えれば、Webアプリケーションサーバシステムでは、ユーザーごとに各ユーザーに割り当てられている案件一覧を管理することが必要です。図2のアーキテクチャでは、このような機能を実現するミドルウェア製品を「ワークフローミドル」と呼んでいます。

　図2のアーキテクチャでは、ユーザーへの案件一覧の表示をJSPを用いて実現することができます。ここで、案件一覧データは、アプリケーションサーバの業務処理EJBがワークフローミドルから取得します。また、選択された案件の業務処理は、アプリケーションサーバの業務処理EJBにおいて実施します。ここで、EJBは、ワークフローミドルに対して、当案件の状態遷移を指示します。 このトピックについては、次回以降に詳しく述べることにします。

(8)帳票ミドル

　図2の「帳票ミドル」は、帳票形式の定義機能と、帳票データの表示、印刷機能を持つミドルウェアです。帳票ミドルには、クライアント環境に、帳票ミドルのクライアント機能(表示・印刷機能を備えます)を備える構成をとるものもあります。また、帳票データとしてpdf形式を用いる帳票ミドルもあり、この場合、クライアントでの表示・印刷にはAcrobat Readerを用いることになります。

　このような帳票ミドルは、従来型のクライアント／サーバシステムにおいても使われていましたが、Webアプリケーションサーバが普及するに従って、WebやJavaの環境で帳票を実現するための手段として注目されています。

　帳票ミドルを用いた帳票出力方式の概要は以下のとおりです。まず、アプリケーションサーバにおいて帳票データをあるデータ形式で生成します。次に、当帳票データをクライアント環境に返し、帳票ミドルのクライアント機能に渡し、表示・印刷します。クライアント機能は、Webブラウザと連動する形態となっているのが一般的でしょう。 このトピックについては、次回以降に詳しく述べることにします。

　このように、Webアプリケーションサーバシステムを構築しようとすると、J2EEの機能だけではカバーできない範囲が存在します。Webアプリケーションサーバの実践的アーキテクチャとは、JSPやEJBといったアプリケーションを実装していくとき、そのような範囲の要件をどのような構成で実現するのかを示すものです。また、そのような範囲の機能を実現する種々のミドルウェアが存在し、JSPやEJBといったアプリケーションとそれらミドルウェアをどのように組み合わせればよいのかを示すものです。

　もちろん、J2EEを基盤とするWebアプリケーションサーバの世界は今後も発展を続けるでしょう。その中で、実際のシステム構築の局面で、本稿に登場した考え方が活用されれば幸いに思います。

連載内容
Webと企業システムを結ぶ実践的アーキテクチャ
	第１回　Webと企業システムをつなぐ現実的なアーキテクチャとは？
	第2回　最適なフロントエンド開発手法
	第3回　XML連携における具体的な手法
	第4回　Webアプリケーションにおける帳票実現
	第5回　COBOL資産を積極活用する
	第6回　ワークフロー連携

連載記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）