bpel4wsを適用したプロジェクト事例紹介 - xml...

BPEL4WSを適用したプロジェクト事例紹介

2004.05.17

(株)JIEC 技術統括室

坂下秀彦

本日の内容

■ プロジェクト開発の背景

◆ プロジェクトの目的

■ システム概要

■ 今回のシステムの特徴

◆ SOAP通信

◆ ワークフローエンジン

■ 構築期間

■ リリース後の評価

■ 今後の展開

■ SOAへの一歩を踏み出すために

お客様のご紹介

■ オーエスジー株式会社 (OSG Corporation)

■ 資本金 104億4百万円、東証・名証1部上場

■ 売上げ平成15年度343億24百万円(単独)

■ 本社愛知県豊川市

◆生産拠点、営業流通拠点を国内に、また海外にも多くの生産・販売拠点を持つ

■ 事業内容

◆切削工具・転造工具・測定工具・工作機械・機械部品の製造販売、工具の輸入販売、工業所有権等の取得、貸与、譲渡及びこれらの技術指導

■ 社会人バスケットボールチーム「OSG Phoenix」を傘下に持つ

■ 今回、「Web/Orderサービスシステム」を、OSG様、富士ゼロックス様、そしてJIECで構築

プロジェクト開発の背景

■ 「Web/Orderサービスシステム」の目的

全世界のOSGグループで共通に利用できる受注システムの構築

各OSGグループの主要情報システムとシステム間連携を行い、適切な業務プロセスの自動化を実現する

各OSGグループの在庫情報をリアルタイムに統合/照合を可能とすることで、見積もり，発注～出荷までの業務精度、スピードを向上させる

OSGグループ（海外）の発注者及びOSG国内の関連担当者は、注文受領～製品発送までの主要ステータスをオンラインで追跡できる

OSGグループ

システム概要

JASTシステム(．NETサーバー）

シンガポール

ワークフローエンジン

業務アプリケーション

メッセージコントローラ

アプリケーション・フレームワーク

（ＤＡＬＡＮ）

アプリケーション・フレームワーク

（ＤＡＬＡＮ）

特殊品管理システム（．NETサーバー）

製造進捗管理システム（．NETサーバー）

INVOICEシステム（．NETサーバー）

ORACLE 9i

Ｉ/ＦＩ/ＦＩ/ＦＩ/Ｆ

Ｉ/ＦＩ/Ｆ

CGIコール

IIOP（CORBA）

注文注文

ステータス照会

在庫照会

CORBAｸﾗｲｱﾝﾄ群

■ システム概要

マレーシアインドネシア

日本

Ｗｅｂ／Ｏｒｄｅｒサービスシステム（Interstage Application Server Standard Edition V5.01）

図面管理システム（EDMICS）DALAN : JIEC開発のWebアプリケーションフィレームワーク

今回のシステムの特徴

■ システムの特徴（技術要素）

JASTシステムをはじめ、ホストを除く他システムとの通信にSOAPを適用

各業務要件をワークフロー化し、各アクティビティの実行/制御を行うワークフローエンジンを構築。また、プロセス定義言語にはBPEL4WSを使用

非同期メッセージサービスを実現するため、メッセージコントローラを構築。

永続/非永続モードの切替可能

発注書等の各帳票を、Apache.orgのFOP（Formatting Objects Processor）を使用し、PDF形式にて出力

SOAP通信 1/3

■ SOAP通信概要

JASTシステム(.NET） ⇔ Web/Orderサービスシステム（J2EE）

VBアプリケーション

サービス提供クラス

JASTシステム（.NET）

J2EEアプリケーション

サービス提供クラス

Web/Orderサービスシステム（J2EE）

ｻｰﾋﾞｽ提供ｸﾗｽ処理結果

稼動確認ｻｰﾋﾞｽ

Proxy Class

IIS / .NET

Pｻｰﾋﾞｽ･ﾌﾟﾛﾊﾞｲﾀﾞｰ

注文ﾃﾞｰﾀ・ｱｲﾃﾑ1・ｱｲﾃﾑ2

SOAP通信 2/3

■ 開発を行って・・・

◆ メリット

導入の容易性異種プラットフォーム間の相互接続が容易に行える。Webアプリの設定も含めて、CORBAより低コストで実現できる。

機能拡張の柔軟性要件追加等により機能拡張が必要になった場合、１サービスの追加と考える事ができ、既存システムへの影響を最小限に抑えることが可能となる。

SOAP通信 3/3

◆ デメリット（但し、このコメントは2003年4月頃の時点でのものです）ベンダー依存

WSDLファイルより生成されるProxy Classは各ベンダーに依存したソースが生成される。

例えば、Apworksで生成したProxy ClassはINTERSTAGEでしか動作しない。

また、Proxy Classの生成手順，サービスプロバイダーへのDeploy手順等も各ベンダーによって異なるため、使用するアプリケーションサーバーによって難易度，コストが異なってくる。

→ ．NET，INTERSTAGEにおいての各仕様，手順の調査を実施

オブジェクト型パラメータについてINTERSTAGE ⇔ .NET間のサービスメソッドは、プリミティブ型のみをパラメータに持つメソッドしか定義できない。オブジェクトをパラメータにもつメソッドを定義すると、WSDLファイルを取り込む際エラーとなってしまう。

→ パラメータをString型１つとし、中のデータをXMLとすることで回避

エラーオブジェクトの相違エラーオブジェクト自体が各ベンダー依存のものとなっているため、エラーをハンドリングする側（SOAP クライアント側）もベンダー依存のコーディングとなってしまう。

→ SOAP I/F用のラッパークラスを使用し、業務部分に依存コードが存在しない設計を実施

セキュリティ暗号化、電子認証等のセキュリティの仕組みがいまだ標準化されていないため、実装が困難，もしくはセキュリティ関連のパッケージ導入が必要となる。

→ 今回は基本的にイントラのシステムだったということも有り、対策なし。

■ 構成図

アクティビティ2アクティビティ3

アクティビティ1

・・・

業務アプリケーション

SOAP注文依頼HTTP request

HTTP response

ﾌﾟﾛｾｽ定義ﾃﾞｰﾀ(BPEL4WS）

メッセージコントローラー

Message PutMessage GetHTTP

（ex.ステータス照会･･･）

業務フローの考え方

■ 新たに設計された業務毎のプロセス群を業務テンプレートと呼ぶ

■ 業務テンプレートは、複数のJOBにより構成される

◆個々のJOBがサービス

◆業務テンプレートはBPEL4WSで記述

■ 1つのJOBは複数のタスクから構成され、それをタスクテンプレートと呼ぶ

◆今回は１JOB：1タスクのみで、フローの入れ子はなし

◆ タスクテンプレートは独自XMLファイルで記述。将来的にはBPELに変更予定

ワークフロー記述

■ BPEL４WSとは米Microsoft、IBMおよびBEA Systemsの3社が、さまざまなWebサービスを含む業務処理や、社内外のメッセージ交換を標準化した業務処理を記述する言語として発表したもの(最新V1.1)で、現在OASISで標準化作業中(WSBPEL TC)。これからの業界標準となりうる可能性のあるフロー定義言語

</proc ess>

<reply><invoke>･･･

</faultHandlers>

</c ontainers>

</partners>

【パートナー】

・BPEL4W Sを処理するエンジンが呼び出す W ebサービスプロバイダー・UM Lで言えば、アクター（登場人物）

【コンテナ】

・パートナー間でやり取りを行うデータ、またはメッセージ（XM L）

【エラー処置】

・トランザクションが失敗した時の処置

【アクティビティ】

・フロー定義本体

</variables>V1.1

内部処理の流れ

今回実装したBPEL定義体

■ 基本定義◆ process

◆ partners

◆ containers

◆ faultHandlers

■ 今回のプロジェクトのフロー処理で必要としたもの◆ アクティビティ

●ベーシックアクティビティ：receive, reply, invoke, wait, terminate, throw

●構造化アクティビティ：sequence, switch

■ 実装しなかったもの◆ compensationHandler, correlationSets, while, flow, scope等

■ XMLファイルとして作成したもの◆ ワークフローエンジン設定ファイル

◆ フロー定義ファイル、パートナー定義ファイルなど、制御用定義ファイル

◆ その他、プロパティファイル等

フロー定義の実例

■ BPEL４WSBPELファイル業務テンプレート

待機中処理

前処理(データチェック)

受注処理

データ異常正常データ

データ修正処理非同期でJ0211を開始

ホスト停止中処理（標準品）

ホスト稼動確認処理

ホスト停止中ホスト稼動中

受注完了処理

条件：完了通知受信

BPEL化

構築期間

イテレーション１： JASTシステムとの接続検証及び一部の業務アプリケーションデモイテレーション２：全機能

リリース後の評価

■ 評価/感想

◆ お客様からの評価

●当初イメージしていたシステムが構築できた

●予想以上のスループット

╼ SOAP通信を採用するにあたって懸念していたパフォーマンスだが、お客様からは問題ないとの評価（３秒ルールを死守）

◆開発者からのコメント

●SOAP通信は簡単

╼ 初めての技術だったのではじめは苦労したが、結果的には非常に安易に接続が出来た

╼ 異種プラットフォーム間においては、CORBA通信より断然安易でかつ汎用性が高い

●ワークフローエンジンを改善していきたい

今後の展開

■ Web/Orderサービスシステム今後の展開/課題

◆世界展開

今回は東南アジア地域（JASTシステム）への対応のみだったが、他のアジア地域、北欧，そしてアメリカなどの全OSGグループへの適用を考えている

◆ ワークフローエンジンの機能拡張

Webサービスを絡めたワークフローの実行

BPEL4WSの仕様を完全に網羅したパース機能

プロセス定義ツール（エディター）

トランザクション制御の実装

◆ SOAP通信

セキュリティの強化

UDDIサービスの使用（ローカルUDDI，グローバルUDDI）

SOAへの一歩を踏み出すために

■ お客様を中心とした業務分析が重要

◆現行システムフローの作成、新システムフローの作成

◆良い意味での、割り切りも必要

●現実的なシステムに落ち着く

■ システム化に関するこだわり

◆ システム間連携はWebサービスに統一する

◆ プロセスの組み換えが容易なワークフローシステムの導入

◆ UMLの積極活用

●ユースケース図、アクティビティ図、クラス図、シーケンス図

●業務フローの検討・見直しはアクティビティ図をベースに実施

■ 100点満点のシステムはありえない

◆ トレーサビリティ、モニタリングを開発プロセス（システムライフサイクル）の中で実施する

■ まずは、スモールスタートから始める

Q&AQ&ADALANは、株式会社JIECの登録商標です。その他各種製品名は、各社の製品名称、商標または登録商標です。本資料に記載されているシステム名、製品名等には、必ずしも商標表示（ (R)、TM ）を付記していません。

bpel4wsを適用したプロジェクト事例紹介 - xml...

Documents

-soap/uddi/wsdlによるwebサービスの開発- 日本...

beaシステムズが実現するwebサービスの概要xmlconsortium.org/seminar/m05/data/20011211_2.pdf ·...

grid/ws-rfと...

xmlコンソーシアム soa環境における...

bml及び...

第92回ランチョンセミナー...

sun java system...

javaとvisual...

流通ビジネスメッセージ標準（bms...

documento genérico possivelmente com mais do que uma...

epk-visualisierung von bpel4ws prozessdefinitionen jan...

xmlの可能性を最大限に引き出すxmlデータサーバxmlconsortium.org/seminar/m09/data/20020417_05.pdf ·...

priminimas: eai - vilniaus...

webサービス技術動向と...

services on demand を実現する suntm one( sun...

アニモにおける音声技術への取り組み - xml...

入札情報サービスシステムで仕様書のダウンロード...

xml soa web2.0...

第92回ランチョンセミナー...

エンタープライズ・リッチクライアント・webプ...

bpel4wsを適用したプロジェクト 事例紹介 - xml...

bpel4wsを適用したプロジェクト事例紹介 - xml...