Activitiを最初に見る

今週、Javaの新しいワークフローエンジンであるActivitiに対処する必要がありました。このトピックはまだHabréで議論されていなかったため、印象を共有することにしました。 私はすぐに言わなければなりません-印象は少し悲しいですが、これについてはカットの下で

少しの背景

jBPM 3

昔々、 jBPMのようなjavaのワークフローフレームワークがありました。 このフレームワークは優れていました（原則として、まだ存在していますが、なぜ過去形で後に明らかになるのでしょうか）。 EmForgeの最初のバージョンを開発した頃に使用していました。 私はこのフレームワークがいくつかの理由で好きでした：

*アプリケーションへの簡単な埋め込み-実際、アプリケーションにJarニックネーム（依存関係を含む）を追加し、アプリケーションで構成可能なプロセスをサポートします。

* APIをクリア。

*使い慣れたテクノロジー（同じHibernate）。

* Hibernateを使用した結果-多数のデータベースのサポート。

*開発者への「近接」-プロセスはEclipseで描画されます。作成されたプロセスをテストする単体テストをすぐに作成できます。

*使用されたjPDL表記は、標準ではありませんが、「毎日」のプロセスを説明するのに便利でした。



これにより、主に開発者にとってjBPMは非常に使いやすくなりましたが、「深刻な」アーキテクトにとっては、SOAソリューションは「おもちゃ」のままでした。jBPMのBPELサポートは根付きませんでした。決定-まあ、それぞれに。 それにもかかわらず、jBPMはJavaの最も人気のあるワークフローソリューションになりました（間違いないと思います）。



作業を開始したバージョン（jBPM 3）では、すべてがスムーズに行われたわけではなく、問題がありました。 私は強調します：

*「クランチ」スプリングモジュールを介したSpring Frameworkとの統合。

*休止状態へのオリエンテーション-さまざまな実装で動作する機能を持つJPAを使用することを好みます（開発されたアプリケーションの統合機能を改善します）。

* APIは、タスクとプロセスの「検索」の実装には不便でした-私は、独自の「直接」SQLクエリを作成する必要がありました。つまり、jBPM実装内に登る必要がありました。

*プロセスの説明には特定の制限がありました。



私たちは何かを我慢しなければなりませんでした、何かは松葉杖を必要とし、何かは私たち自身の「上部構造」によって修正されました。 一般的に-次のバージョンの「改善」と「修正」に期待するのは論理的です

jBPM 4

ただし、次のバージョン-jBPM 4では、開発者は「ディープ」リファクタリングの道を歩みました。 実際、まったく新しいAPIと新しいベースを備えた新しいエンジンが作成されました。 そのようなすべてを処理するのに必要な量はわかりませんが、それにもかかわらず、新しいバージョンには特定の利点がありました。

* Springとのネイティブ統合

*プロセスおよびJavaコードまたはスプリングコンポーネントの呼び出しのより便利な説明。

*検索に便利なAPI。

*データと「履歴」のランタイムデータベース内の個別のストレージ-理論的には、作業を高速化する必要があります。



一般に、新しいバージョンは良い印象を残しました-jBPM3に存在していたすべての機能がjBPM4にあったわけではありません。 欠点のうち、jBPMはjBossの「翼の下」で開発されたため、以前のバインディングはおそらくHibernateに起因すると考えることができます。

Activiti

さて、コードは再パックされました。ユーザーを満足させることもできます-つまり、新しいバージョンを思い浮かべてください。 しかし-それはありませんでした。 jBPMの主な開発者-トム・ベイエンスはRedHat（jBoss）を離れ、Alfrescoに移ります

その結果、新しいプロジェクトActivitiが開始されます。 プロジェクトはすぐにバージョン5.0（jBPMの継続でヒンティング）を受け取り、今ではステージ5.0.rc1に到達しています。 主な変更点：

* Hibernateはスローされます-代わりにiBatisが使用されます（大腸炎！）。 私が理解しているように、解決策は政治的です。Apacheライセンスの下でコンポーネントのみを使用します（LGPLからコンポーネントが防止するものを理解しませんでした-これは原則として最終製品自体にライセンス制限を課しません）、さらに何らかの理由で Alfresco は HibernateからiBatisに切り替えます

* jPDLの代わりに、BPMN2表記が使用されます。



ActivitiとLiferayの統合を実装するためにActivitiと協力しました。 そして、現在のバージョンのいくつかの印象があります（リリース間近）：

* APIはJBPM 4と非常によく似ています。実際、パッケージとクラス名を変更しました。

*長い議論の後、JPAを介してデータベースを操作するためのサポートを追加したようです。ただし、これはあなた自身の危険とリスクで「実験的」です（まだ試していません）。

*他の企業もこのプロジェクトに参加しました-これにより幅広いサポートが約束されます（ただし、サポートされているjBPMも多くあります）。



しかし、実際には、これは一歩前進ではなく、サイドステップです。 そして、プロジェクトがさらに先に進むと良いです。そして、別の「グローバルな」リファクタリングやブランド変更はありません。



しかし、マイナスとして得られるもの：

*サポートされるデータベースのリストは（myBatisを支持してHibernateが拒否されたため）大幅に絞り込まれました。さらに、データベースのタイプは自動的に決定されません。スキームのアップグレードには誤解があります。

* BPMN2を支持してjPDLを拒否したため、jPDLにあった便利な機能がいくつか失われました（たとえば、タスクからのいくつかの出力遷移）。 私は標準を使用するためのものですが、妥当なところならどこでもです。 Activitiデザイナーで説明されているプロセスは、Activiti以外の場所では実行できないため、標準では何も提供されておらず、jPDLは（IMHO）日常のタスクに便利でした（BPMNはより学術的であり、実際には人間化されたBPELです）。 一般に、jBPM 4で簡単に実行できたいくつかのことは、Activitiでは実行できないことを主張し、議論できることは明らかですが、事実は変わりません。

*コードの品質が悪いように思えた。 私の目を引いたのは、サービスインターフェースの説明がオブジェクトのインターフェース（jBPM 4のように）だけでなく、特定の実装にも作用することです。 たとえば、 IdentitySessionは、ユーザーおよびグループインターフェイスだけでなく、その実装（UserEntityおよびGroupEntity）でも動作します。 比較のために-jBPMの同じクラス -javaDocコメントの数に注意してください。 これは基本的にすべて些細なことです-しかし、Activitiは急いで開発されているという印象を受けます-これはコードの品質にあまり影響を与えないかもしれません。 （ちなみに、私は完璧ではありません。また、javadocのコメントを常に書いているわけではありませんが、ポイントはjBPMにありましたが、Activitiにはありませんでした）

*（APIとプロセス開発の観点から）新しい機能はあまりありませんでしたが、jBPMの多くは「失われました」。 つまり、現在jBPM 4を使用している場合、Activitiに切り替える理由はありません。

最後に悲しい考えはなぜですか？

*優れたプロジェクトの体系的で進化的な開発の代わりに、一連のリファクタリングとブランド変更と「政治的」な飛躍を実現します。その結果、プロジェクト（IMHO）は機能を失うだけです。

* jBPMは本質的に死んでいます。 jBoss がjBPM 5.0を発表しているにもかかわらず、私はプロジェクトがその主要開発者の退任後も生き続けることには懐疑的です。

*同時に、Activitiがどのように生き続けるかは完全には明らかではありません。 1つの良いエンジンの代わりに2つのエンジンを使用することは可能ですが、それは何でしょうか？



さて-泣いた-それで十分です。 ここに記載されている情報が、次のプロジェクトのワークフローエンジンの選択に役立つことを願っていますが、正直なところ、正しい選択が失われています。