JBoss jBPM はJava SE や EE 環境のためのビジネスプロセス管理エンジンです。 jBPM はビジネスプロセスやユーザーインタラクションを、 待ち状態、デシジョン、タスク、WEBページなどノードの図式として表現を可能にします。 図式は簡単でとても読みやすい jPDL と呼ばれる XML 表現を使用して定義されており、 Eclipse プラグインを利用して編集、グラフィックによる視覚化が可能です。 jPDL は拡張可能な言語でありWEB アプリケーションのページフローを定義することから、典型的なワークフローの管理、SOA 環境におけるサービスのオーケストレーションまで対応します。

Seam アプリケーションは jBPM を2 つの異なる問題に使用します。

この二つを混乱させないでください！まったく異なるレベルまたは粒度で動作します。Pageflow, conversation と task すべて、一人のユーザーの一つのインタラクションを指しています。ビジネスプロセスはたくさんのタスクに広がります。さらに二つのjBPMアプリケーションは完全に直行しています。それらを一緒にも利用できますし、個別にも利用できます。まったく使わないということもできます。

Seamを使うためにJPDLのことは知らなくていいです。もしページフローの定義やSeamナビゲーションルールの定義に何の問題もなく、アプリケーションがプロセスドリブンよりかはデータドリブンである場合には、おそらくjBPMは必要ないでしょう。しかし、私たちはユーザー間のインタラクションを、よくまとまったグラフィカルな図で考えることは、より堅牢なアプリケーションを構築しやすくしてくれます。

8.1. Seamのページフロー

Seam にはページフローを定義する 2 つの方法があります。

• JSFあるいはSeam ナビゲーション規則の利用 - ステートレスなナビゲーションモデル

• jPDL の利用 - ステートフルなナビゲーションモデル

簡単なアプリケーションではステートレスなナビゲーションモデルで十分です。 とても複雑なアプリケーションは場所に応じて両方を使用します。 それぞれのモデルはそれぞれの強みも弱みもあります。

8.1.1. 二つのナビゲーションモデル

ステートレスなモデルは 一組の名前の付いた論理的なイベントの結果 (outcome) から 直接、結果として生じるビューのマッピングを定義します。 ナビゲーション規則は、どのページがイベントのソースであったかということ以外、 アプリケーションによって保持されたどのような状態も全く気にしません。 これは、アクションリスナーメソッドがページフローを決めなければならないことがあることを意味しています。 なぜなら、アクションリスナーメソッドだけがアプリケーションの現在の状態にアクセスできるからです。

これは JSF ナビゲーション規則を使用したページフローの例です。

<navigation-rule>

    <from-view-id

>/numberGuess.jsp</from-view-id>

        

    <navigation-case>

        <from-outcome

>guess</from-outcome>

        <to-view-id

>/numberGuess.jsp</to-view-id>

        <redirect/>

    </navigation-case>



    <navigation-case>

        <from-outcome

>win</from-outcome>

        <to-view-id

>/win.jsp</to-view-id>

        <redirect/>

    </navigation-case>

        

    <navigation-case>

        <from-outcome

>lose</from-outcome>

        <to-view-id

>/lose.jsp</to-view-id>

        <redirect/>

    </navigation-case>



</navigation-rule

>

これは Seam ナビゲーション規則を使用したページフローの例です。

<page view-id="/numberGuess.jsp">

        

    <navigation>

        <rule if-outcome="guess">

            <redirect view-id="/numberGuess.jsp"/>

        </rule>

        <rule if-outcome="win">

            <redirect view-id="/win.jsp"/>

        </rule>

        <rule if-outcome="lose">

            <redirect view-id="/lose.jsp"/>

        </rule>

    </navigation>



</page

>

ナビゲーション規則が冗長過ぎると考えるならば、 アクションリスナーメソッドから直接、ビューIDを返すことが可能です。

public String guess() {

    if (guess==randomNumber) return "/win.jsp";

    if (++guessCount==maxGuesses) return "/lose.jsp";

    return null;

}

これは、リダイレクトの結果であることに留意ください。 リダイレクト中に使用するパラメータを指定することも可能です。

public String search() {

    return "/searchResults.jsp?searchPattern=#{searchAction.searchPattern}";

}

ステートフルなモデルは名前の付いた論理的なアプリケーションの状態間で起こる遷移の組み合わせを定義します。 このモデルではjPDL ページフロー定義中に、どのようなユーザーインタラクションのフロー表現も可能であり、 インタラクションのフローを全く知らないアクションリスナーメソッドを書くことも可能です。

これは jPDL を使用したページフロー定義の例です。

<pageflow-definition name="numberGuess">

    

   <start-page name="displayGuess" view-id="/numberGuess.jsp">

      <redirect/>

      <transition name="guess" to="evaluateGuess">

              <action expression="#{numberGuess.guess}" />

      </transition>

   </start-page>

   

   <decision name="evaluateGuess" expression="#{numberGuess.correctGuess}">

      <transition name="true" to="win"/>

      <transition name="false" to="evaluateRemainingGuesses"/>

   </decision>

   

   <decision name="evaluateRemainingGuesses" expression="#{numberGuess.lastGuess}">

      <transition name="true" to="lose"/>

      <transition name="false" to="displayGuess"/>

   </decision>

   

   <page name="win" view-id="/win.jsp">

      <redirect/>

      <end-conversation />

   </page>

   

   <page name="lose" view-id="/lose.jsp">

      <redirect/>

      <end-conversation />

   </page>

   

</pageflow-definition

>

ここですぐに気づく 二つのことがあります。

• JSF/Seam ナビゲーション規則は、より 簡単です。 (しかし、これは根底となる Java コードがより複雑化であるという事実をあいまいにしています。)

• jPDL はJSP や Java コードを見る必要がなく、 即座にユーザーインタラクションの理解ができます。

それに加えてステートフルモデルはもっと 制約的 です。 各論理的な状態 (ページフローの各ステップ) に対して他の状態に遷移可能な制約された組み合わせがあります。 ステートレスモデルはアドホックな モデルです。 それはアプリケーションではなく、 比較的制約のない、ユーザーが次に行きたいところを決めるフリーフォームナビゲーションに適しています。

ステートフル / ステートレスナビゲーションの違いは、 典型的なモーダル / モーダレスインタラクションの考え方ととてもよく似ています。 さて、アプリケーションをモーダルな振る舞いから回避することは、 対話を持つ 1 つの主な理由ですが、 Seam アプリケーションは、 通常、単純な意味でのモーダルではありません。 しかし、Seam アプリケーションは、 特定な対話レベルで、モーダル可能であり、しばしばそうです。 モーダルな振る舞いは、 可能な限り回避すべきものとして知られています。 ユーザーがしたいことの順番を予測することは、とても困難です。 しかし、ステートフルモデルの存在意義があるのは疑う余地はありません。

二つのモデルの最大の違いは、 戻るボタンの振る舞いです。

8.1.2. Seam と 戻るボタン

JSF あるいは Seam ナビゲーション規則が使用される場合、 Seam は、ユーザーに戻る、進む、更新ボタンの自由なナビゲーションを可能にします。 これが発生したとき、 内部的な対話状態の一貫性を保持することは、 アプリケーションの責任です。 Struts や WebWork のような対話モデルをサポートしない WEB アプリケーションフレームワーク、 そして、EJB ステートレスセッションBean や Spring framework のようなステートレスコンポーネントモデルの組み合わせの経験は、 多くの開発者にこれをすることは、ほとんど不可能であることを教えていました。 しかし、Seam のコンテキストでの経験から、 ステートフルセッション Bean に裏付けられた明確な対話モデルがあるところでは、 それは実際とても簡単です。 通常、それは、アクションリスナーメソッドの最初に、 no-conversation-view-id アノテーションと null チェックの使用を組合わせるのと同じ位に簡単です。 私たちは、フリーフォームナビゲーションのサポートは、 ほぼいつも要求されるものと考えています。

この場合、no-conversation-view-idの宣言は pages.xmlで行います。 対話中のレンダリングされたページからの要求の場合、 それは Seam にリダイレクトを指示し、対話はもはや存在しないことを知らせます。

<page view-id="/checkout.xhtml" 

        no-conversation-view-id="/main.xhtml"/>

一方ステートフルなモデルでは、戻るボタンは以前の状態への未定義な遷移として解釈されます。ステートフルなモデルでは現在の状態から定義済みな遷移のみを行なえるようになっているため、戻るボタンはデフォルトでは有効になっていません。Seam は戻るボタンの利用を透過的に検知します、そして陳腐化した以前のページからの動作を一切ブロックし、単純に現在のページにリダイレクトします。(faces messageを表示します)。これを機能とみるかステートフルモデルの制約とみるかは視点によります：アプリケーション開発者の視点からは機能とみて、ユーザーからの視点としてはフラストレーションを引き起こすようなものかもしれません。back="enabled"を指定することによって特定のページでの戻るボタンを有効にすることもできます。

<page name="checkout" 

        view-id="/checkout.xhtml" 

        back="enabled">

    <redirect/>

    <transition to="checkout"/>

    <transition name="complete" to="complete"/>

</page

>

これは、checkout 状態 から以前のどの状態 にでも戻るボタンでの遷移が可能です。

もちろん、ページフロー時のレンダリングされたページからの要求の場合に何をするのか、そして、その際にページフローでの対話は存在していないのか、といったことを 定義しなければなりません。この場合、no-conversation-view-id の宣言は、ページフロー定義で行います:

<page name="checkout" 

        view-id="/checkout.xhtml" 

        back="enabled" 

        no-conversation-view-id="/main.xhtml">

    <redirect/>

    <transition to="checkout"/>

    <transition name="complete" to="complete"/>

</page

>

実際には両ナビゲーションモデルとも使い道がありますが、どんなときにどちらのモデルの方が適切かを理解するために、これから簡単に学んでいきます。

<bpm:jbpm />

<bpm:jbpm>

    <bpm:pageflow-definitions>

        <value

>pageflow.jpdl.xml</value>

    </bpm:pageflow-definitions>

</bpm:jbpm

>

@Begin(pageflow="numberguess")

public void begin() { ... }

<page>

        <begin-conversation pageflow="numberguess"/>

    </page

>

<pageflow-definition name="viewEditDocument">



    <start-state name="start">

        <transition name="documentFound" to="displayDocument"/>

        <transition name="documentNotFound" to="notFound"/>

    </start-state>

    

    <page name="displayDocument" view-id="/document.jsp">

        <transition name="edit" to="editDocument"/>

        <transition name="done" to="main"/>

    </page>

    

    ...

    

    <page name="notFound" view-id="/404.jsp">

        <end-conversation/>

    </page>

    

</pageflow-definition

>

<page name="displayGuess" view-id="/numberGuess.jsp">

    <redirect/>

    <transition name="guess" to="evaluateGuess">

        <action expression="#{numberGuess.guess}" />

    </transition>

</page

>

<h:commandButton type="submit" value="Guess" action="guess"/>

<h:commandButton type="submit" value="Guess"/>

<page name="displayGuess" view-id="/numberGuess.jsp">

    <redirect/>

    <transition to="evaluateGuess">

        <action expression="#{numberGuess.guess}" />

    </transition>

</page

>

<h:commandButton type="submit" value="Guess" action="#{numberGuess.guess}"/>

<page name="displayGuess" view-id="/numberGuess.jsp">

    <transition name="correctGuess" to="win"/>

    <transition name="incorrectGuess" to="evaluateGuess"/>

</page

>

<decision name="evaluateGuess" expression="#{numberGuess.correctGuess}">

    <transition name="true" to="win"/>

    <transition name="false" to="evaluateRemainingGuesses"/>

</decision

>

<page name="win" view-id="/win.jsp">

    <redirect/>

    <end-conversation/>

</page

>

<page name="win" view-id="/win.jsp">

    <redirect/>

    <end-task transition="success"/>

</page

>

<process-state name="cheat">

    <sub-process name="cheat"/>

    <transition to="displayGuess"/>

</process-state

>

8.3. Seam のビジネスプロセス管理

ビジネスプロセスは誰が、いつ実行されるべきかが明確に定義されたルールの上で、ユーザーやソフトウェアによって実行される明確に定義されたタスクの集合です。 Seam の jBPM インテグレーションはタスク一覧をユーザーに表示することやタスク管理を容易にします。また Seam はアプリケーションにビジネスプロセスに関する状態をビジネスプロセスコンテキストに保管することを可能にします。

<page> の代わりに<task-node> ノードを持つ以外、 簡単なビジネスプロセス定義はページフロー定義とほぼ同じであるように見えます。 (一貫した原則 (The One Kind of Stuff principle)) 長期間のビジネスプロセスにおいて、 待ち状態はシステムが、ユーザーがログインしタスクを実行するのを待っているところです。

<process-definition name="todo">

   

   <start-state name="start">

      <transition to="todo"/>

   </start-state>

   

   <task-node name="todo">

      <task name="todo" description="#{todoList.description}">

         <assignment actor-id="#{actor.id}"/>

      </task>

      <transition to="done"/>

   </task-node>

   

   <end-state name="done"/>

   

</process-definition

>

同じプロジェクトの中にjPDL ビジネスプロセス定義と jPDL ページフロー定義を持つことは可能です。 そうであれば2 つの関係は ビジネスプロセス中の <task>は ページフロー <process-definition>全体と一致します。

<bpm:jbpm>

    <bpm:process-definitions>

        <value

>todo.jpdl.xml</value>

    </bpm:process-definitions>

</bpm:jbpm

>

@In Actor actor;


public String login() {

    ...

    actor.setId( user.getUserName() );

    actor.getGroupActorIds().addAll( user.getGroupNames() );

    ...

}

@CreateProcess(definition="todo")

public void createTodo() { ... }

<page>

    <create-process definition="todo" />

</page

>

<task name="todo" description="#{todoList.description}">

    <assignment actor-id="#{actor.id}"/>

</task

>

<task name="todo" description="#{todoList.description}">

    <assignment pooled-actors="employees"/>

</task

>

<h:dataTable value="#{pooledTaskInstanceList}" var="task">

    <h:column>

        <f:facet name="header"

>Description</f:facet>

        <h:outputText value="#{task.description}"/>

    </h:column>

    <h:column>

        <s:link action="#{pooledTask.assignToCurrentActor}" value="Assign" taskInstance="#{task}"/>

    </h:column

>                    

</h:dataTable

>

<h:commandLink action="#{pooledTask.assignToCurrentActor}"

> 

    <f:param name="taskId" value="#{task.id}"/>

</h:commandLink

>

<h:dataTable value="#{taskInstanceListForType['todo']}" var="task">

    <h:column>

        <f:facet name="header"

>Description</f:facet>

        <h:outputText value="#{task.description}"/>

    </h:column>

    <h:column>

        <s:link action="#{todoList.start}" value="Start Work" taskInstance="#{task}"/>

    </h:column

>                    

</h:dataTable

>

@StartTask

public String start() { ... }

<page>

    <start-task />

</page

>

@EndTask(transition="completed")

public String completed() { ... }

<page>

    <end-task transition="completed" />

</page

>