理論介紹（一些定義）
業務流程是一個組織及其合作伙伴的人員及系統所完成的工作的一種正式表達， 它旨在給內部或外部客戶提供產品或服務。業務流程最簡單的表達形式就是一組活動，它們表示流程的不同步驟，通過一些轉換連接在一起。活動可能需要人爲干預，也可能是全自動的。對於需要人爲交互的活動，可以在流程中定義一個角色，標識允許誰在這裏與流程交互。流程起到定義的作用，而流程中的實例就是完成整個流程的實際項目，從一個活動轉換到另一個活動。實例總是開始於流程的Begin活動，而結束於流程的End活動。實例的路徑完全取決於實例的數據以及外部環境。
轉換是活動之間的直接連接, 許多的轉換進出一個活動.。一旦某個實例完成了一項活動件，外發轉換將被評估， 其中之一被選中，以使實例轉向下一活動。條件轉換包含一個布爾表達式，該表達式將被計算，要使實例繼續沿流程前進，結果必須爲true。有些轉換是基於時間的，這就意味着如果到了預期時間，實例還在那裏，這些轉換將會觸發到目標活動的自動路由。流程也可以有狀態：可爲流程定義屬性，接受每個實例的一個值，這能幫助您保持實例狀態，以轉換到不同的活動（例如，報價總數>X，那麼就執行該活動）。.
從純建模的角度看，這就是BPM。但要執行流程，這裏的定義是不夠的；您還需要與其他系統溝通，將流程反映到基礎架構中。這就是集成發揮作用的地方了。對於流程中的每一個活動，您都可以定義任務，這些任務基本上是由一個實例抵達該活動時所執行的代碼組成的。任務可以通過多種方式實現。當某個實例抵達一個自動活動時，爲該活動定義的任務就會被執行，實例將根據執行結果移動到下一活動。
對於人爲交互的活動，任務的執行是由最終用戶通過客戶端工作空間觸發的。AquaLogic產品內置了集成功能，可以應用於任務代碼之中（這一特性將在以後的文章中更全面地加以介紹，它也是本產品最重要的特性）。任務更新流程狀態、訪問和更改外部系統，並與最終用戶交互等等。任務就是將一個簡單的流程模型轉變爲一個流程驅動的應用程序。
業務流程管理是正式化和自動化業務流程的技術。要想成功地進化爲一個面向流程的組織，您必須使用合適的工具來設計、執行和監控業務流程。這就是業務流程管理系統的構建目的。也是AquaLogic BPM設計的目的所在。
時間問題（轉移到BPM之前）
如果組織想要獲得更高的敏捷性，就需要適應業務運轉所用到的軟件。從概念的角度來看，變化最頻繁的不是後臺應用程序、不是訪問客戶的web服務定義、不是EJB的位置，也不是它們所基於的ERP的版本。業務需要適應的最重要的變化就是流程本身：業務必須以某些標準爲依據，添加一條更快捷的途徑，來自動地認可順序，從而修改提高或降低認可率的參考值。組織需要處理認可，並平行地檢查活動；需要改變執行某項活動的角色；需要手動處理一些異常；需要實施新的業務規則。處理此類變更是BPM的核心內容，允許在不更改任何底層組件的情況修改業務流程。
下節將介紹一些我認爲對於理解BPM的真正價值十分重要的東西。
業務流程管理背後（流程盡在控制之中）
通過接納BPM，也就具體化了業務中的一個重要片段。問題是，如果用戶的流程模型不可執行（即它只是純粹的模型），那麼最終您是不得不將其映射到一個應用程序、轉換它，就像從“分析”到“設計”再到“實現”時的轉換一樣。這使得將業務流程映射到生產中真正運行的部分非常困難。採用AquaLogic BPM Suite，您可以構建出一個完整的流程驅動的應用程序，將任務附加到活動，而這些活動就是業務流程內部發生的真實操作。任務是流程的代碼，既可以是用戶驅動的，也可以是系統驅動的。任務的執行是流程中狀態改變的主要驅動力。因此，這個流程切實地驅動了應用程序，直接實施了流程中允許的流、任務和操作。
編寫流程驅動的應用程序並不會改變您編寫代碼或實現服務的方式，您仍然是在以相同的方式編寫Java類、Web services和JSP。主要的差異在於這個應用程序是流程驅動的。也就是說，所有的代碼是通過活動任務觸發的，所以您只需專注於這些任務的代碼即可，剩下的事情都可由AquaLogic BPM Suite處理。用戶工作空間中提供了一些開箱即用的基本流程操作。
設身處地（爲最終用戶着想）
對於您的最終用戶（即您所構建的解決方案的用戶）來說，最主要的變化就是他們有了一份待完成任務的單一列表。他們可以在收件箱中查看待處理的實例以及對於各實例來說可執行的任務。
以前，用戶必須在不同的頁面、系統和應用程序上查看需要執行的任務。幸運的是，如果有新的待執行任務，用戶會接收到相關通知，但他們很有可能不會在一個單獨的視圖中發現這樣的通知。而BPM可以將工作分配情況很直觀地展現在用戶面前。
對於最終用戶來說，最重要的改變就是呈現在他們面前的將是更加面向任務的工作視圖。他們能夠很容易地瞭解，他們有等待通過執行爲相應活動啓用的任務而許可的待處理事項單。只要清晰地定義流程，您就可以創建出對所有參與實體（如其他系統和人員）來說都很清晰明瞭的工作單元。
有了流程和實例後，您就需要一個用戶前臺來管理實例（類似CRUD的基本操作）。對於BPM，這些操作將是創建、搜索、執行、取消、委託和路由。AquaLogic BPM Suite 通過HiPer Workspace（以任意風格）或直接通過使用API（基於Java或Web服務）提供了所有這些特性。用戶無需再構建這些功能，它們已經存在了。
BPM是波瀾壯闊的SOA運動的一部分，在其中發揮着非常重要的作用。下面分析一下它是如何發揮作用的。
我眼中的世界（BPM眼中的SOA世界）
許多知名人士對BPM和SOA之間的關係做了定義。
- Bruce Silver的BPM Watch有一篇非常出色的 文章，標題爲BEA's take on BPM-SOA。
- Alfred Chuang 在Exec2Exec時事通訊中撰寫了一篇 文章，也提供了很好的描述。
我對SOA的觀點是：它與構建封裝的、可重用、去耦的服務有關。SOA涉及兩個主要“方面”：構建去耦服務和以簡單的方式將它們綁定在一起。在SOA企業中，所有服務都將在不同級別上自頂向下地連接在一起（否則就不能使用這些服務）。一些綁定極爲靜態，而另一些綁定卻非常動態。BPM試圖提供一種工具，來建模變化最大的層次——業務層。流程利用SOA服務作爲構建塊，它將在底層系統中反映您的業務流程。這些核心服務將在所有流程中重用，提供了真正的重用價值。這些流程將業務、數據和表示服務綁定在一起，實現價值產生因素：真正的業務流程。
如果沒有流程層，您最終就要在表示層或業務層裏連接這些服務調用，業務邏輯的某些變更將決定哪些服務器要修改，並重新根據新的業務定義來連接服務。下面通過一個例子來詳細描述：您擁有一個Web應用程序，它具有雙層架構，即業務組件和表示。某些表示組件包含應用程序的排序邏輯。商業用戶決定改變業務流程，改變某些操作的順序及一個業務組件的使用。那麼您應如何將這樣的業務需求精確地映射到需要更改的代碼呢？如何才能知道在哪裏修改？爲什麼需要了解更改流程所需的實現？
使用業務層，您擁有明確的空間來利用可用服務，這裏流程層就扮演了這些服務的膠合劑，使它們在業務流程的範圍內能夠起作用。因此，當業務發生改變時，只有一個地方發生更改：流程，而不是服務。
在BPM的上下文中提到重用時，有多個級別需要考慮：
- 外部系統的低級重用，這裏有許多業務流程要訪問同一Web服務。
- BPM的中級重用，這裏您可以在共享流程和組件模板，重用代碼和流程模型的最佳實踐。
- 流程的高級重用，這裏您可以公開一個流程，該流程可供組織的其他部分使用。
