2010年3月19日金曜日

雑感:BPELとXSLT

なんかのフレームワークの設定ファイルくらいでしか XML を触った事のない Java/.NET の技術者が、いきなり BPEL 書きの仕事を始めると、SOAP や WSDL のような SOA/Webサービスの仕様だとか、それ以前の XSLT や XPath のような XML の基礎技術まで、BPEL というカテゴリに包含される技術だと思ってしまう傾向があるらしい。
特に XSLT などは、Transform アクティビティ(Oracle BPELの話)でしか使った事がない人が想像するよりも、本来は遥かにいろいろできたりするので、けっこうもったいない。

例として、1 から任意の自然数nまでの合計を求める処理を考えてみる。
これを 変数とループを使って手続き型のBPEL コードで書くこともできるけど、初歩のXSLT を知っていれば以下のようなXSLT で書くことができる。
<?xml version="1.0" encoding="windows-31j" ?>

<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:n1="http://xmlns.oracle.com/OracleBpelTest1App_jws/Project2/BPELProcess2">
<xsl:output method="text"/>
<xsl:template match="/">
<xsl:call-template name="sum">
<xsl:with-param name="n" select="n1:process/n1:n" />
</xsl:call-template>
</xsl:template>
<xsl:template name="sum">
<xsl:param name="n"/>
<xsl:choose>
<xsl:when test="$n = 1">1</xsl:when>
<xsl:otherwise>
<xsl:variable name="x">
<xsl:call-template name="sum">
<xsl:with-param name="n" select="$n - 1" />
</xsl:call-template>
</xsl:variable>
<xsl:value-of select="$n + $x" />
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>

これを "exercise1.xsl" というファイル名でプロジェクトに含めておくと、BPEL のAssign アクティビティからこんな感じで呼び出せる。
<assign name="Assign_1">

<copy>
<from expression="ora:processXSLT('exercise1.xsl',bpws:getVariableData('inputVariable','payload','/client:process'))"/>
<to variable="sum"/>
</copy>
</assign>

ora:processXSLTから*.xsl ファイルを実行するところまでは同じでも、いつもの BPEL の Transform とは主に以下のような点で違う。
  • transformation パターンのアノテーションがない。
  • XSLTがtextを出力している。
  • to で単純型の変数を指定して、これでXSLTの出力を受けている。
  • XSL に oracle-xsl-mapper インストラクションが無い

なんだかこの例だと手続き型の作法で書いたBPELコードと大差ないし、下手したら XSLT に不慣れな人には余計複雑に見えるようなった気がしないでもないが・・・

ただ、センスも腕もそこそこあるプログラマが、XSLT みたいなフツーのXML技術でできることを活用しないまま「BPELが不便すぎて」だとか「BPEL仕様の制約が・・・」なんてブツクサ言うのを見ると、ちょっともったいない気がする。第一、本人のスキルも十分生かされていないだろうし。

思うに、IDE のグラフィカルなデザイナ上では、XML 技術のわずかな部分しか使うことができない。入力XML要素から出力XML要素に線を引っ張るだけの作業がアホらしくなったら、いっそ 思い切って transform アノテーションを外してソース直接編集に切り替えた方が、自分にもチームにも品質にも、いろいろ良い効果があるかも。

0 件のコメント:

コメントを投稿