システム概要

システム概要

   勤怠管理システムは、技術者が勤怠入力や各種申請を行い、上司が勤怠情報や申請情報を確認し、承認・否認を実施するという、社内システムです。シス テムが利用者に提供する機能は、ごくありふれたものであり、Ajaxを使って優れた操作性を実現しているというわけでもありません。特徴的なのは、SOA の概念に基づき複数サービスが連携して、実現されているということです。

   図3は今回構築した勤怠管理システムと関連するシステムの関係を図示したものです。

図3：勤怠管理システムの概要図
（画像をクリックすると別ウィンドウに拡大図を表示します）

   勤怠管理システムは、組織管理、承認管理、営業報告、技術者情報管理という4つのシステムが連携し、構成されています。バックエンドの各システムか ら、再利用可能な機能をサービス化し、フロントエンドから、これらの複数のサービスと連携することにより、勤怠管理システムは実現されます。

   このように、機能をサービスとして構築することにより、将来構築されるシステムから比較的容易に再利用することが可能になります。これは、SOAの概念に基づき構築することで得られるメリットの1つです。

   また、システムの柔軟性や拡張性を高めるために、BPEL EngineやESBを導入しました。BPEL Engineは「ActiveBPEL Engine」、ESBはソニックソフトウェアの「SonicESB」を採用しました。これらについては、追って説明します。

既存システムとの連携

   このシステムでは、既存システムから「認証」「社員情報検索」などの機能をサービス化し、同期型の連携を実現しています。

   一昔前のシステムであれば、夜間バッチでデータをコピーする方式や、勤怠管理システムから直接データベースを参照し取得するような方式を使ったかもしれません。しかし、前者はリアルタイム性も低く、各システムに同じようなロジックが混入することになります。

   後者は、今回のシステムだけを考えれば、特に問題ないかもしれませんが、次に開発するシステムにも同じようなロジックが含まれる可能性が高いです。再利用性、メンテナンス性が低く、システムの変更に対する強度が低くなります。

   しかし、サービスとして構築しておくことで、再利用性が向上し、接続先のシステム変更に強くすることが可能になります。

   既存システムをサービス化する方法はいくつかあります。

   例えば、既存システムが分散システムで構築され、バックエンドにリモートアクセス可能なインターフェースが存在するという前提ならば、アプリケー ションの機能を抽出し、ESBを使って、サービス化する方式が考えられます。また、リモートアクセス可能なインターフェースを持たない場合は、システムの 情報を再利用し、サービス化するという方式もあります。

   弊社の既存システム連携方式は、後者を採用しており、既存システムのデータベースから情報を取得し、XML形式に変換するデータベースアダプタを実装し、サービスとして公開しています。

SonicESB導入によるメリット

   このシステムでは、多くのサービスをESB上に公開し、フロントエンドからESB経由でアクセスする方式を取っています。ESB上にサービスを公開 することにより、他システムとの連携方法をサービス利用者が意識せずに、統一された標準的なトランスポート（このシステムではSOAP over HTTP）でのアクセスが可能になります。

   また、SonicESBのESBプロセスを使用することで、複数サービス（小粒度）を組み合わせ、公開サービスの粒度（粗粒度）を調整できるという メリットがあります。ESBという中間層を持つことにより、サービス変更によるサービス利用者への影響を吸収し、システムに柔軟性と拡張性を与えることが できます。

   ESBの役割については、「柔軟性の高いシステムを目指すSOA/ESB」で詳細に解説されているので、そちらをご覧ください。

   当初、すべてのサービスをESB上に公開する予定でしたが、スケジュールおよび求める機能と製品仕様が異なるなどの理由により、いくつかのサービス は、フロントエンドから直接アクセスする方式を取っています。ソニックソフトウェアからのサポートがあり、機能拡張パッチを提供いただいたので、将来的に はすべてのサービスをESB経由でアクセスする方式に変更する予定です。