EJB、SOA、マイクロサービスへと至る大規模システム向けアーキテクチャの変遷：15周年記念特別企画（2/3 ページ）

EJBという発想

　モノリシックなアーキテクチャにおける課題と反省から、「情報システムを小規模なサブシステムに分割する」という発想は自然に生まれる。前述のように、当初は知恵（チューニング）と力技（スケールアップ）によって課題解決を図っていても、それが本質的な解決策ではないことは自明であり、いずれはパラダイムシフトの必要性に迫られるからだ。

　EJB（Enterprise Java Beans）はJavaの誕生（1995年）から程なくして実装されており、本来であれば比較的こなれた技術であるはずだが、現在は当初の発想から大きく異なる実装がなされている。

　EJBは「JavaBeans」と呼ばれる、首尾一貫したクラスの発展形であり、ネットワーク上で再利用可能なコンポーネントとして位置付けられる。従って、セキュリティや状態管理、RDBへの永続化などを備えており、ネットワーク上で稼働するアプリケーションコンポーネント（オブジェクト指向、エージェント指向）の理想型を体現している。

EJBの構造

　EJBを構成する要素（Enterprise Bean）は以下の通り定義されている。

• セッションBean
  ビジネスロジックを実行するEnterprise Bean。「ステートフルセッションBean」と「ステートレスセッションBean」が定義されている（その違いについては、「Java Solution FAQ：EJBの種類を教えてください」を参照）
• エンティティBean
  データの永続化を目的としたEnterprise Bean。データベースのレコードと関連付けられ、データの保存と読み込みが自動化される
• メッセージドリブンBean
  JMSなどを利用したメッセージによって非同期に実行されるEnterprise Bean。呼び出し元に依存したデータ、状態は持たない

　その他、ネットワーク経由でのアクセスインターフェースが定義されており、適切なセキュリティ設定を施すことによって不正アクセスを防ぐ仕組みが実装されている。

EJBのアーキテクチャ

EJBは、なぜ普及しなかったのか

　「ビジネスアプリケーションを再利用可能なビジネスロジックコンポーネントに分割し、品質と汎用性を高める」という発想は特に新しい概念でもなく、極めて自然であり、また、プログラム設計上は必須の思想である。

　一方で、上記以外にもさまざまなルールや仕組みが存在したために、設計が複雑で、理解が非常に難しいものであった。開発者としては「重い」というのが正直な印象であろう。当時のサーバースペック、ネットワークのスループット、Javaプラットフォームのパフォーマンスなどの限界にも影響を受け、適用が非常に少なかったと推察される。少なくとも筆者の耳に入ってくる成功事例は（筆者の勉強不足もあるかもしれないが）ほとんどなかったと記憶している。

　また、ビジネスにおける汎用的なレイヤー設計／クラス設計は難易度が高いため、EJBの理想を実現するためのハードルが非常に高かったことも、普及に歯止めがかかった一因と考えられる。

　次章のSOAにおいても類似の議論が存在するが、設計時に緻密に、ビジネス側とシステム側の要求のバランスを取り、将来性を考えてコンポーネント分割を進めていくのは、エンタープライズアーキテクトの存在を必要とするだけではなく、管理・統合された開発体制を必要とする。高い理想の実現には、それ相応のコストが掛かるということである。

EJBの現在

　そんな中、Spring Framework、Struts、Seasarなど、軽量かつ比較的平易なフレームワークが登場した。決してEJBと二律背反のものではないものの、コンポーネント化に一定の目処が立ったことで、少なくとも世の中のほとんどを占める小規模システムの実装に対するソリューションが出たことになる。

　こういった流れを汲み、EJB 3.0においてはDI（依存性の注入）が実装され、POJOでの実装、アノテーションによるEJB宣言など、大幅な改良が加えられている。今後は自然に、または知らないうちにEJBを使っているといったシーンが増えてくることが想定される。要素技術としては優れたものを持っていることもあり、その行く先には注目したい。

SOAの考え方

　SOA（Service Oriented Architecture）は、2004年頃から広く認識されるようになったが、概念自体は決して新しいものではない。従来、WebサービスやRPC、前述のEJBなどのキーワードを用いたシステム間連携の概念は存在していたが、SOAにおいてはビジネスロジックの外部公開を考え方の中心に据えたところが、当時の状況としては新しいといえる。

　一方、ESB（Enterprise Service Bus）やHTTP-SOAPなど、SOAを実現するための要素技術の文脈で語られる向きも強い。本質的にはシステム全体、まさにアーキテクチャを設計する際の考え方であることをあらためて強調したい。

サービスとは（「レイヤー」の概念など）

　アプリケーションの構築において、三層構造で設計する考え方が定着して久しい。このレイヤーの考え方がアプリケーション構築において有効なものであることについて、賛否はあると思うが、利便性などについては容易に理解されるものとして話を進めよう。

• データ層

　データ層は、ビジネスのある断面を永続化したものであり、ビジネスの状態を構造的に表現するものとして重要視される。ハードウエアの急速な進化によって、RDBに業務構造を直接的に保存することが一般的となり、そのことが三層構造の理解を促進する一つの要因にもなっていると思われる。

• ビジネスロジック層

　ビジネスロジック層は、さらにサービス層とロジック層に分けるのが一般的である。サービス層はI/F（インターフェース）層から直接アクセスするための、ビジネスにおいて表出する機能を実装したものである。再利用性を高めるために、粒度やセキュリティなどを考慮して設計する必要がある。SOAにおいて「サービス」と表現しているのは、この層へのアクセス手段、およびそこで実装されている機能のことであると考えて、おおむね間違いはない。

　ロジック層は、サービス層を構成する要素ロジックを表す。サービス層よりも粒度は細かく、再利用性は高いが、単独ではビジネス機能を提供できないことが多い。

　例えば「在庫照会」機能を実装する場合、下記の手順をたどる。

• 全販売拠点の拠点コードをマスターから取得
• 各販売拠点に対して確定受注量を取得
• 全物流センタのセンタコードをマスターから取得
• 各物流センタに対して在庫量を取得
• 合計在庫量から合計確定受注量を差し引き、結果を返す

　5つの処理がロジックに相当し、「在庫照会」機能がサービスに相当すると考えてよい。

• I/F層

　I/F層は、画面またはバッチ処理の起動部分であり、外部からの入力を受け、入力データを情報システムに引き継ぐための変換を行う。ある程度の入力チェックなどをこのレイヤーで実施することにより、後続のビジネスロジック層においては本質的な処理の実装に専念できる。

　前述の通り、「サービス」の概念はビジネスで表出する再利用可能なものであり、それらをWebサービスの形で公開することによって、情報システム構築の自由度を向上させられることが直感的に理解できるが、これらの効果を含め、期待効果や難易度については整理して後述する。

サービスの組み合わせで業務プロセスを構築する考え方

　SOAが登場した背景の一つに、従来、業務単位でサイロ化された情報システム構築が行われてきたという点がある。各業務内で最適化されながらも、業務プロセス全体を俯瞰した場合、自由度の低い仕様に固まってしまっていること、業務改善の際に検討する事項が膨大になることから、企業活動の柔軟性を欠いた構造になってしまっていた。

　各業務システムのビジネスロジック層を適切な粒度で設計し、公開することで、すでに存在している業務システムの再利用性を向上させ、業務改善を促進する狙いがあった。

　業務プロセスは、さまざまな要因で変化が発生する。コスト削減や顧客満足度向上を目的とした業務改善や、組織変更、新たな顧客に対応するためのカスタマイズ、新規サービスの構築など、個々の業務内容を変えずとも、関わる組織や人員数、求められるスピード、実施のタイミングなどを変更することが求められることがある。

　本質的な業務内容に変化が少ない場合においては、業務を適切な粒度で「サービス」として設計し、I/Fと切り離して実装することで、I/Fの変更のみで業務の再構築が行える。あらかじめ必要なサービスが実装されていれば、あくまで論理的にではあるが、すでに所有している経営資源のみで新規事業の構築などが可能となる。

　また、EJBが「細かな設計思想を盛り込む」ことにより、やや行き過ぎた概念であることと比較すると、SOAは「アプリケーション設計の自由度を残した概念」とも言える。

SOAへの期待

　ここまでのSOAの紹介においては、メリットや実装後の期待を中心的な話題としてきたが、それらを含め、フラットな視座からあらためてSOAを評価してみたい。

　SOAに基づいた実装において、業務や顧客サービスのPDCAサイクルが早まることが強く期待され、それに伴って情報システムの設計も洗練されていくと考えられる。組織の構築においても、ビジネスレイヤーではビジネス戦略とUI／UXを統合して考えることができ、それ以下のレイヤーはIT部門を機能（サービス）別に組織化し、それぞれの組織で各機能のレベルを向上させることが期待される。

　一方で、「サービス」を中心に考えることによって、市場ではESB製品やBPMS製品が溢れてきていたことからも、それぞれのレイヤーを統合する動きが強くなり、「APIをいかに設計するか」（粒度や命名規約などの実装方式）にフォーカスされがちになる。つまり、今まではアプリケーションの内部に閉じていたために、多少のブレが許されてきた方式設計にメスが入り、きれいに整理することが求められる。結果的に、EJBに対する動きと同様のことが起こってくると想像される。

SOAを実現する難易度

　人間の発想としては、ビジネスや顧客サービスに対して個々の要件を個別に考えるのが自然である。個別に考えた上で、やや短期的かつ限定された範囲で最適化しようとすることが非常に多い。

　初期開発においては、長期的な視点が必要なことに間違いはないが、強い汎用性を求められるSOAの適用はスピードや柔軟性を損ねるため、回避した方が良いことが多い。一方で、ビジネスが順調に立ち上がり、組織が安定してからSOAの適用に移行する場合を考えると、担当者は垂直統合の概念が強く、パラダイムシフトが起こしづらくなっている。

　いずれの場合においても、サービスの汎用性を追求するに当たっては、スピード感、体制、設計者の能力などの観点から、非常に難易度の高い問題が多く存在することになる。

　また、現実的にも既存のAPI群に新たなAPIを追加することになり、「当初の方式設計からのブレをいかに吸収するか」が大きな課題として持ち上がってくる。方式設計チームのレベルを高く維持しない限り、整理されたサービス群になりづらく、I/F側で考慮しなければならない事項が徐々に増えていく。

　SOAの概念では、ロジック層以下の実装については何も言及していない。当然、自由に設計すれば良いのだが、ITの構築においては、業界のベストプラクティスや標準的な手法をベンチマークにすることが多いことを考えると、非常に困難な作業になることが容易に想像される。

　SOAは規模の大きな情報システムを対象に議論されることが多く、大半の情報システムにとってベンチマークとなる成功事例は皆無と言っていい。結果的にEJBの登場によって否定された複雑な考え方を再び求めてしまうことになる。その状態での設計には、エンタープライズアーキテクトと呼ばれる人材を必要とするほど難易度が高く、従って簡単にSOAの適用に踏み切れないのが現実であると考えられる。