ページの先頭です。
サイト内の現在位置を表示しています。
  1. ホーム
  2. ソリューション・サービス
  3. SOA
  4. SOA関連製品・サービス
  5. バックエンドサービス開発方法論
ここから本文です。

SystemDirector Enterpriseのバックエンドサービス開発方法論(WebOTX版)のご紹介

1.はじめに

企業の事業環境の変化が激しさを増すなか、企業情報システムは、業務の効率化や作業の自動化などのコスト削減に加えて、より戦略的な情報システム投資に対する関心が高まっています。

このような背景から、サービスという考え方によりシステムをビジネス的にも意味のあるまとまりに構成し、その変化を柔軟に対応しようとする考え方(SOA)が発展してきました。さらに、昨今サービスはフロントエンドサービス(プレゼンテーションレイヤ)とバックエンドサービス(アプリケーションレイヤ)で整備されるようになっています。

NECの開発標準であるSystemDirector Enterprise(SDE)はこれらの状況に合わせてシステム開発を行うための開発方法論を整備しています。SOA開発方法論の概要についてはこちらの記事(SystemDirector EnterpriseのSOAシステム開発方法論のご紹介)を参照してください。

SDEでは、SOAのシステム開発プロセスを、大きく分けて5つの設計タスクで定義しています。「1.サービスを抽出する」タスク~「4.サービスを設計する」タスクは使用する製品に依存しない部分になります。
今回は、「5.サービスを実装する」タスクについて、サービス実行基盤としてWebOTXを使用する場合の実装手順の概要をご紹介します。

SDEのSOAシステム開発プロセス

2.SDEのSOAシステムレイヤとサービス実行基盤WebOTXの関係

SOAのシステムレイヤとWebOTXのサービスインテグレーション製品群の関係を示します。

SOAシステムレイヤとサービス実行基盤

典型的なSOAシステムレイヤは従来の3層構造アーキテクチャに対してプロセス層とサービス層およびHUB製品という階層を新たに設けた構造をしています。
プロセス層により、変化するプロセスをアプリケーションより外出しすることで、ビジネスの変化に合わせて短期間に変更可能なビジネスプロセスを定義することが可能となります。
サービス層およびHUB製品により、サービスインタフェースが標準化されシステム連携が容易になります。HUB製品はESB(Enterprise Service Bus)製品等が担当し、メッセージ変換や経路制御を行います。
このような階層構造により、変化スピードとコスト対効果に優れたシステムを実現しています。

サービス実行基盤WebOTXにおいて、HUB製品は「WebOTX Enterprise Service Bus」、プロセス層は「WebOTX Process Conductor」がそれぞれ対応しています。各製品はシステム要件に合わせて選択します。

3.サービスの設計から実装へ

「4.サービスを設計する」タスクまでの作業により、サービスが抽出され、サービスメッセージ、実装方式が決定された状態となります。
抽出されたサービスには、プロセスサービスと基本サービスの2種類があります。

プロセスサービス
業務の流れを表現したフローです。画面系とバッチ系の機能が含まれます。業務フロー図との違いは、プロセスとしてステータス管理を行わない手作業は含まない点です。

基本サービス
公開可能な単位(それ1つでビジネスとして成り立つ単位)のアプリケーションロジックのことです。標準インタフェースをもち、データの授受はメッセージ経由で行われます。

今回は、基本サービスの実装にはESBを利用し、プロセスサービスの実装にはBPEL(Business Process Execution Language)を利用します。以降の節で詳細をご紹介します。

4.ESBによる基本サービスの実装

基本サービスの実装は、サービスの単位で切り出した業務ロジックをツールを用いてWebサービス化する方法もありますが、ここでは、ESBを用いた実装方法をご紹介します。

ESBによる実装は、「4.サービスを設計する」タスクで作成した基本サービスのサービス仕様およびインタフェース設計から、ESBと基本サービスを接続するためのプロトコルを選定しESB(Enterprise Service Bus)による経路制御を下図の手順にて設計します。WebOTXでは、これらの手順を支援する開発ツールをご提供しており、画面上の操作により簡単に実装することができます。

ESBによる基本サービスの実装手順

ESBとは、アプリケーション統合を行うための技術、あるいはミドルウェアです。HTTPやSOAP、JMSなどのプロトコルをサポートしており、異なる基盤の間でのデータのやりとりを行うためのメッセージ変換や、経路制御、非同期接続を行うことができます。

4.1.プロトコルの選定

WebOTX ESBはバインディングコンポーネント(以下、BC)と呼ばれる通信機能とサービスエンジン(以下、SE)と呼ばれるコンポーネントを提供しています。

既存システムとの連携では、そのシステムが持つ通信手段にあわせてBCを選択します。新規にシステムを構築する場合は、基本サービスとのインタフェース、通信経路の信頼性、システム間連携の種類(同期/非同期通信、ファイル、データベースなど)を考慮してBCを決定します。

通信機能(バインディングコンポーネント)

SOAP SOAPにより各種プラットフォームと連携。メッセージの暗号化や署名等をサポート。
JMS 高性能・非同期な連携。メッセージ到達保障。C/C++APとの連携も可。
RMI RMI-IIOPプロトコルによりEJBを呼び出し。APサーバ上のJavaプログラムと高速に連携。
CORBA RMI-IIOPプロトコルによりCORBAサービスを呼び出し、APサーバ上のサービスと連携。
JCA ACOS上の業務APとの連携。iWayアダプタ群により多数のシステムと連携を実現。
ファイル ファイルによるメッセージ交換により、通信機能を持たないプログラムと容易に連携。
データベース データベースからデータを入出力します。テーブルへの追加データを自動入力することも可。
FTP FTPサーバからファイルを入出力。
HTTP HTTPリクエストの受信、送信。

ESB内部でメッセージに対する処理を行うものとしてサービスエンジンがあります。ESB内部の経路制御やメッセージ変換などの機能を持ち、前述のBCと組み合わせて使用します。

配送制御・変換機能(サービスエンジン)

配送制御
(シーケンサ)
複数のサービス呼び出しを組み合わせて、逐次実行する機能を提供します。
XMLデータの加工、障害発生時の通知、障害発生後の処理を指定することも可能です。
XSL変換 XMLの変換において最も広く使われているXMLスタイルシートによるXMLの変換機能(XSLT)を提供します。
選択呼出し メッセージ中に格納されたデータをXPathで指定し、JavaScriptで呼び出し先を指定する機能を提供します。

4.2.ESB内部の経路設計

ESB内部の経路設計では、連携するシステムとの接続設定の定義と、サービス間を流れるメッセージの経路を定義します。
ESB内部の経路設計をツールを用いて行った際の定義画面例を以下に示します。

経路設計の定義画面例

4.3.メッセージ設計

メッセージ設計では、接続するサービスへ入出力するメッセージのインタフェースと、サービス間のメッセージ変換を定義します。メッセージ設計は以下の手順で行います。

手順1.オペレーションのスキーマ定義
ESBへ入出力するメッセージのスキーマを定義します。

メッセージのスキーマ定義

手順2.外部プロトコルのメッセージからXML形式への変換
ESB内部を流れるメッセージはXML形式のため、必要に応じて、外部プロトコルから入力された非XMLメッセージをXML型へ変換します。

手順3.メッセージ変換定義
「ESB内部の経路設計」で呼び出すサービス同士の接続において、データ形式が異なる場合は、メッセージ変換を行います。ESB内部を流れるメッセージはXML形式のため、XMLデータの変換定義となります。

メッセージ変換定義にはツールを利用します。

メッセージ変換定義

4.4.基本サービスの製造

ESBによる基本サービス(従来のアプリケーションレイヤ構造でいうAP層と同じレイヤ構造)の実装は、ツールを利用してサービス接続定義を作成する作業になります。

5.BPELによるプロセスサービスの実装

プロセスサービスの実装は、「4.サービスを設計する」タスクで作成したプロセスサービスのサービス仕様およびインタフェース設計から、BPEL準拠のBPMエンジン上で動作可能にするために必要な情報を下図の手順で設計します。こちらについても基本サービスと同様、WebOTXの開発ツールにより画面上の操作によって簡単に実装を行うことができます。

プロセスサービスの実装手順

5.1.プロセスサービスのモデリング

SOAのシステム開発プロセスの中の「サービスを設計する」で作成したプロセス図から、ローレベル・プロセス図を設計します。ここでは主に2つの作業を行います。

5.1.1.「ローレベルBPMNパターン」によるプロセス図の見直し

プロセス図をBPEL仕様に準拠したビジネスプロセスとして表現しやすい形式に変更します。BPELで表現可能なBPMNを設計するというアプローチに関しては、UMLモデリング推進協議会のローレベルBPMNパターンが参考になります。

BPMN(Business Process Modeling Notation)とは、ビジネスプロセスをモデル化して可視表現するための表記法の標準です。

5.1.2.アクティビティの詳細設計

作成したプロセス図内の各アクティビティに設定する属性を決定します。

設定例

5.2.メッセージ設計

メッセージ設計では、プロセスサービス内で定義する変数のメッセージ構造と、プロセスサービス内で行うXMLメッセージ変換を定義します。
メッセージ変換は、前節ESBによる基本サービスの実装と同様、ツールを利用して定義します。

5.3.基本サービス拡張設計

「ビジネスプロセスインスタンスを一意に識別する仕組み」です。変化するプロセスをアプリケーションから外出しする構成をとるには、ビジネスプロセスから外部サービスを呼び出して、処理が完了してから応答を返してもらうといった動作、いわゆる非同期接続が必要になります。これを実際に個々のアプリケーションの中で実現しようとすると非常に大変ですが、BPELには、この非同期接続を実現するための機構が組み込まれておりメッセージとビジネスプロセスインスタンスを関連付けるプロパティを定義するだけで実現できます。

5.4.プロセスサービスの製造

BPELによるプロセスサービスの実装は、ツールを利用してBPEL準拠のプロセス図を作成する作業になります。
参考情報として開発ツールの実行画像を示します。

プロセス図の作成

6.おわりに

今回は下流工程のバックエンド部分を中心とした実装手順のご紹介でしたが、この他にもフロントエンド部分のシステム構築手順等含め、クラウド化への対応も着実に進めています。

関連URL

NECの開発方法論は、個別のお客様向けにテーラリングして、お客様における標準としてお使いいだくことが可能です。

SystemDirectorおよびSystemDirector Enterpriseは日本電気株式会社の登録商標です。
その他の会社名、製品名等は一般に各社の商標または登録商標です。

ページの先頭へ戻る