一般情況下流程運行中所涉及到的Web服務實例都是固定的，其調用的端點地址是在流程設計時期就指定了的，在運行期間引擎將會向指定的Web服務發送調用信息，並獲得運行結果。這種設計雖然執行起來簡單，但是其缺點也有很多，首先，流程運行的容錯性不高。如果某個流程是一個長期運行實例（其一次運行可能持續幾天，甚至幾個月），那麼在流程設計初期爲其指定的服務可能會因爲各種原因停止服務，那麼引擎對於該實例的合作伙伴的調用將會出錯，從而使得實例運行失敗；其次，這種設計限制了整個系統運行的性能發揮。很多情況下，某個特定領域中的某個計算程序會在一個流程實例中多次被調用，而同時也會有多個組織或個體擁有該計算程序，如果在設計過程中就將某個常用計算程序指定到某個固定服務器上，那麼隨着該服務的不斷被調用，其服務性能將會迅速下降，從而影響流程運行效率。
因此本系統採用向流程部署文件集（所有流程部署所需信息的集合）中添加動態信息描述文件dynamic.properties的方式，在不影響BPEL標準的前提下，爲系統增加服務動態選擇功能。該特性可以讓流程在運行時對服務的綁定進行重新選擇，其選擇的依據就是目前該服務的多個實例所部署的服務器當前性能指標，同時可以根據用戶所定義的選擇策略進行服務篩選，以獲得較好的執行效率。
上圖是本系統的動態服務選擇框架圖，加入該特性後引擎在調用每個服務時候首先檢查該服務是否在動態配置文件中存在，該配置文件指定了當前流程中哪個服務的調用是採用動態機制調度的，通過服務名稱來表明，同時給出了該服務應該採取的選擇策略。如果當前服務不需要進行動態選擇，則使用該服務的原始地址進行常規調用；如果需要動態選擇，則引擎首先會向動態選擇服務發送請求，獲得在當前服務名稱和選擇策略下所對應的最佳服務地址。然後再使用該調用地址替換原來的地址進行調用。在這裏，需要注意的是在拿到需要進行動態調用的服務信息之後，要想取得該服務所對應的最佳服務地址，必須有服務註冊中心的支持和選擇算法的應用。本系統所採用的服務註冊中心採用UDDI技術實現，具體工作由本項目組其他成員負責完成，在這裏不做討論。
本系統中服務動態選擇實現的特點是，並沒有擴充BPEL標準，也就是說在加入該功能後BPEL定義文件不需要做任何修改，仍然是符合標準規範的，而只是在部署流程的時候添加相應的動態信息描述文件即可。與服務註冊中心的結合可以通過配置文件實現，當然其中的選擇策略也可以由用戶自己定義。通過向系統添加該功能特性，對系統運行流程性能有一個較大的提高，但同時付出的代價是服務註冊中心部分需要負責收集各個服務性能指標，對其造成了一定的負擔。