Excellent
最終更新：
the_pandas_panda 2009年01月30日(金) 18:05:29履歴
ＢＰＥＬ とはなんでしょうか。
ＢＰＥＬはＸＭＬベースのワークフロー記述言語。
ＷＳＤＬで定義されたサービスを順序性などを定義し連携します。
こうだけ書くとあまりたいしたことないような気がします。
私も最初はそう思いました。
しかも、Ｗ３Ｃで仕様策定中のＷＳ−ＣＤＬがこの上位の振り付け（choreography）を行うと謳われてしまってはしまっては、ＢＰＥＬはなんかちっさくみえます。
しかし私は、勉強の途中でこの言語がソフトウェア開発に与える影響は大きいと感じました。
なぜならば。
新しい振る舞いを記述できるからです。
ＢＰＥＬ は 新しい振る舞い を記述できる言語なのです。
−−−
ＢＰＥＬの勉強をしていたときに、
学生時代、ソフトウェア工学の授業で聞いた言葉が浮かんできました。
「ブーチ法の偉大なところは同期バーが存在する事で、それまでのフローチャートとは違う」
分岐、繰り返しを書けるようになったフローチャート
同期が書けるようになったブーチ法（ＵＭＬに引き継がれます）
うろ覚えだったのでブーチ法じゃなくてＯＯＳＥかもしれませんし、
振る舞いの順序ではなくて、状態遷移だったかもしれません。
気になった方も、ＵＭＬではアクティビティ図に同期バーが存在するので聞き流してください。
ＵＭＬのステートチャート図なら並行状態も書ける？
いえいえここで言いたいのは振る舞いの記述。
振る舞いについてなんてＵＭＬですべて書けるじゃないかという方もいらっしゃるかもしれません。
私が注目したのは、具体的にはスコープ(scope)と
補正（compensate）です。
スコープとはアクティビティをくくりつける枠。
補正とは異常時に正常な状態に戻すための処理です。補償と書いている本が多いですね。※
※なんとなく補正がよいかなと。
補正：不十分な（ぐあいの悪い）所をあとから手を加えて直すこと。
補償：与えた損害などを償うこと。
ソフトウェア設計（システム設計）をしていて振る舞いを表現するときに
分岐、繰り返し、そして同期は当然表現できなければ困ります。
しかし、さらに設計をしていると欲しい概念があります。それがスコープ(scope)と補正（compensate）。
どんなときに欲しいかと言うと 異常時の振る舞い を
表現するときです。ここでこけたら全部なかった事にして欲しいと思うときありますよね。BPELだと、スコープに対して補正してよ！という定義をすることになります。トランザクションを表したいだけ？と言われたら、まあそれに近いものはあるんですが・・・
ＵＭＬでは表現しきれない部分※なのでＢＰＭＮでこれを表現できるとよいのですが・・・私の知る限りではできないようです。
※
�．掘璽吋鵐洪泙世叛犠錙�異常をそれぞれ書かねばならない（異常が複数パターンあればそれ毎に書く事に・・・）
�▲▲�ティビティ図だと異常時も交えたフロー図を書く事はできるが、スコープ全体に補正をかけているというのが、うまく書きづらい
自己完結してくれているサービスを相手にしているという前提で、スコープと補正があると異常時の記述は大部分書けます。少ない経験上ですが・・・これで書けるようになる仕様がシステム設計の肝になってきます。
大きな視点で（サービス単位で）見た時に、異常時の振る舞いが確実に規定されていることは、とても大事です。
−−−
記述できると言ってもＸＭＬじゃあ困るよ※言われる方もいらっしゃるかも。
記述できると言うのは絵で描けるという意味ではありません。
標準として認知された仕様で定義できるという意味です。言葉は標準で無ければ意味が無いんです。
定義に使う絵（ＢＰＭＮとか）も出来れば標準化して欲しいですけどね！
ＷＳ−ＣＤＬは？
ＩＢＭ、ＭＳが参加しない（したのかな？）のでＷＳ−ＣＤＬまでみんなが思いをはせるのは難しいかもしれません。ＩＢＭはＢＰＥＬに振り付け（choreography）をさせると明言してます。
−−−
、、、ところで絵なんですが、ＢＰＭＮってスコープと補正、書けるんですかね。
ＢＰＥＬに落とせるのが売りのようなんですが、少し調べただけでは書けそうに無いような・・・む？補正アクティビティは表せるのか。
勉強不足なので知っている方いたら教えてください。
書けないととちっとも嬉しくないんですけどね。
−−−
以上、一風変わったＢＰＥＬ必要論でした。
これらはＢＰＥＬだけでは実現できません。連携するWebサービスの実装にも影響します。
でも、一番大事なところが
書けるようになる。見えるようになる。
（いろんな意味で／BAMなんかもあったりして）
これだけで十分じゃないですか？
−−−
最近業務で使うようになっていろいろ勉強しているんですが、
BPELがターゲットとしているLRT（Long Running Transaction）に対応するため、
非同期処理がこなせるのも非常に魅力的です。
これはメモリ上に存在しているビジネスプロセスを、
長い待ち時間が予想される外部のWebサービスなどを呼び出したときに（非同期呼び出し）
一度DBなどに退避してしまう処理です。
システム連携にうまく使うとビジネスプロセスの処理時間短縮、リアルタイム性の向上、などが
計れます。
（バッチ処理でこなしていたシステム連携を１件ずつ処理することができる）
ＢＰＥＬはＸＭＬベースのワークフロー記述言語。
ＷＳＤＬで定義されたサービスを順序性などを定義し連携します。
こうだけ書くとあまりたいしたことないような気がします。
私も最初はそう思いました。
しかも、Ｗ３Ｃで仕様策定中のＷＳ−ＣＤＬがこの上位の振り付け（choreography）を行うと謳われてしまってはしまっては、ＢＰＥＬはなんかちっさくみえます。
しかし私は、勉強の途中でこの言語がソフトウェア開発に与える影響は大きいと感じました。
なぜならば。
新しい振る舞いを記述できるからです。
ＢＰＥＬ は 新しい振る舞い を記述できる言語なのです。
−−−
ＢＰＥＬの勉強をしていたときに、
学生時代、ソフトウェア工学の授業で聞いた言葉が浮かんできました。
「ブーチ法の偉大なところは同期バーが存在する事で、それまでのフローチャートとは違う」
分岐、繰り返しを書けるようになったフローチャート
同期が書けるようになったブーチ法（ＵＭＬに引き継がれます）
うろ覚えだったのでブーチ法じゃなくてＯＯＳＥかもしれませんし、
振る舞いの順序ではなくて、状態遷移だったかもしれません。
気になった方も、ＵＭＬではアクティビティ図に同期バーが存在するので聞き流してください。
ＵＭＬのステートチャート図なら並行状態も書ける？
いえいえここで言いたいのは振る舞いの記述。
振る舞いについてなんてＵＭＬですべて書けるじゃないかという方もいらっしゃるかもしれません。
私が注目したのは、具体的にはスコープ(scope)と
補正（compensate）です。
スコープとはアクティビティをくくりつける枠。
補正とは異常時に正常な状態に戻すための処理です。補償と書いている本が多いですね。※
※なんとなく補正がよいかなと。
補正：不十分な（ぐあいの悪い）所をあとから手を加えて直すこと。
補償：与えた損害などを償うこと。
ソフトウェア設計（システム設計）をしていて振る舞いを表現するときに
分岐、繰り返し、そして同期は当然表現できなければ困ります。
しかし、さらに設計をしていると欲しい概念があります。それがスコープ(scope)と補正（compensate）。
どんなときに欲しいかと言うと 異常時の振る舞い を
表現するときです。ここでこけたら全部なかった事にして欲しいと思うときありますよね。BPELだと、スコープに対して補正してよ！という定義をすることになります。トランザクションを表したいだけ？と言われたら、まあそれに近いものはあるんですが・・・
ＵＭＬでは表現しきれない部分※なのでＢＰＭＮでこれを表現できるとよいのですが・・・私の知る限りではできないようです。
※
�．掘璽吋鵐洪泙世叛犠錙�異常をそれぞれ書かねばならない（異常が複数パターンあればそれ毎に書く事に・・・）
�▲▲�ティビティ図だと異常時も交えたフロー図を書く事はできるが、スコープ全体に補正をかけているというのが、うまく書きづらい
自己完結してくれているサービスを相手にしているという前提で、スコープと補正があると異常時の記述は大部分書けます。少ない経験上ですが・・・これで書けるようになる仕様がシステム設計の肝になってきます。
大きな視点で（サービス単位で）見た時に、異常時の振る舞いが確実に規定されていることは、とても大事です。
−−−
記述できると言ってもＸＭＬじゃあ困るよ※言われる方もいらっしゃるかも。
記述できると言うのは絵で描けるという意味ではありません。
標準として認知された仕様で定義できるという意味です。言葉は標準で無ければ意味が無いんです。
定義に使う絵（ＢＰＭＮとか）も出来れば標準化して欲しいですけどね！
ＷＳ−ＣＤＬは？
ＩＢＭ、ＭＳが参加しない（したのかな？）のでＷＳ−ＣＤＬまでみんなが思いをはせるのは難しいかもしれません。ＩＢＭはＢＰＥＬに振り付け（choreography）をさせると明言してます。
−−−
、、、ところで絵なんですが、ＢＰＭＮってスコープと補正、書けるんですかね。
ＢＰＥＬに落とせるのが売りのようなんですが、少し調べただけでは書けそうに無いような・・・む？補正アクティビティは表せるのか。
勉強不足なので知っている方いたら教えてください。
書けないととちっとも嬉しくないんですけどね。
−−−
以上、一風変わったＢＰＥＬ必要論でした。
これらはＢＰＥＬだけでは実現できません。連携するWebサービスの実装にも影響します。
でも、一番大事なところが
書けるようになる。見えるようになる。
（いろんな意味で／BAMなんかもあったりして）
これだけで十分じゃないですか？
−−−
最近業務で使うようになっていろいろ勉強しているんですが、
BPELがターゲットとしているLRT（Long Running Transaction）に対応するため、
非同期処理がこなせるのも非常に魅力的です。
これはメモリ上に存在しているビジネスプロセスを、
長い待ち時間が予想される外部のWebサービスなどを呼び出したときに（非同期呼び出し）
一度DBなどに退避してしまう処理です。
システム連携にうまく使うとビジネスプロセスの処理時間短縮、リアルタイム性の向上、などが
計れます。
（バッチ処理でこなしていたシステム連携を１件ずつ処理することができる）
このページへのコメント
Excellent - BPEL鐃緒申鐃緒申鐃� - Seesaa Wiki鐃淑ワ申鐃緒申鐃緒申鐃緒申 for 鐃緒申鐃殉￥申鐃夙フワ申鐃緒申 ��≪�潟�������若�� 2014 http://www.pslcbi.com/moncler2014.html
はじめまして。補償（補正）は、BPMNでも記載
できますよ。
BPMNで補正を記載した場合、BPELに変換した場合にも
compensateアクティビティとして出力されます。
下記の資料が参考になると思います。
http://www.jsys-products.com/iwaken/bpmn/pub/BPMN.pdf
P168あたりが補償中間イベントとBPELとのマッピング
について説明が載っています。