精彩的人生

　　在SOA的上下文中設計WebServices必須處理好一系列問題，包括可重用性和靈活性等。然而，一旦最初的設計是讓獨立的服務一起以集成的方式出現(xiàn)就會導致另一些需求的出現(xiàn)，其中大多數(shù)可以被業(yè)務過程執(zhí)行語言(Business Process Execution Language ，BPEL)來處理。

　　BPEL是由IBM、Microsoft和BEA在2003年共同發(fā)明的。但從誕生尹始，BPEL就得到了Web services標準的引導。現(xiàn)在，在OASIS的資助下已經(jīng)升到了2.0版本，有超過35家公司正在參與規(guī)劃未來標準的方向，它將成為處理Web services編排的標準。

　　但如何通過BPEL來進行Web services編排呢?一些其它公司把它稱為Web services工作流，意思是已經(jīng)使用基礎的Web services協(xié)議棧SOAP/WSDL/UDDI。讓我們來談這個問題之前先假設你被派去遷移一個信用卡應用系統(tǒng)并使用到Web services。

　　由于自身的特性，我們的信用卡應用程序必須與第三方系統(tǒng)交互，并且在同樣的過程中有成百的調(diào)用。她們基于同樣的Web services，這樣可以滿足不同系統(tǒng)用戶的要求。

　　BPEL就是用來構建這些Web services決策鏈或工作流的。但是，在更深入探討它的具體使用之前，你應該認識到一個重要事情或者說必備條件，即BPEL背后的價值:可重用性。

　　為了盡可能多的構建基于Web services的業(yè)務過程并用BPEL把它們粘合到一起，必須使每個獨立的服務都達到精確的平衡。使用粗粒度的Web services比使用BPEL創(chuàng)建不同決策鏈的整體目標更重要，因為它們可能是完整的業(yè)務過程。同樣的，細粒度的服務不利于重用和構建BPEL工作流。

　　這個過程本質(zhì)上與面向?qū)ο蟮脑O計很類似，即一個對象需要完成足夠的工作來證明它的存在才能不被認為是上層調(diào)用對象。你應該用同樣的方式考慮Web service。Web service 的可重用性是SOA的一個主要原則，這自不必說，而在使用BPEL的時候這一點體現(xiàn)的更加明顯。

　　作為核心，BPEL用XML語法來表達Web service交互，而像聲明變量、流控、事務和錯誤處理等其它事情你可以讓另一種語言來負責編排協(xié)作。

　　因為這樣也隱含著Web servcies基本的SOAP/WSDL/UDDI方法，因此BPEL要求其自身環(huán)境能夠執(zhí)行這些命令，我們稱之為BPEL引擎。

　　現(xiàn)在，BPEL引擎存在著不同的成熟度和復雜性。當SOA領域的一些廠商用其它核心產(chǎn)品例如ESB來緊密集成他們的BPEL引擎時，其他人則在同樣的領域創(chuàng)建單獨的產(chǎn)品。

　　為了牢固掌握BPEL，我們通過最中立和不侵權的方法，即一個叫做ActiveBPEL的開源Java BPEL引擎來看看下面的BPEL示例。

　　ActiveBPEL是一個單獨的BPEL引擎，可以在任何Java/J2EE應用服務器下以Web應用(WAR文件)的形式運轉。由于ActiveBPEL屬于開源產(chǎn)品，所以它與事實上的Java/J2EE開源Tomcat、Apache's Web services框架Axis以及流行的構建工具Ant緊密的結合在一起。

　　這些特點使ActiveBPEL成為開發(fā)BPEL功能的優(yōu)秀產(chǎn)品，因為它基于已經(jīng)被熟知并已獲得應用的技術。如果你的機器上還沒有這些包，可以下載它們并按照基本安裝命令進行安裝。我們不會談論配置問題，因為本文的目的是讓你能更快的使用BPEL。

　　讓我們從高層審視ActiveBPEL編排的過程。你的銀行系統(tǒng)需要執(zhí)行一個信用卡應用過程，并根據(jù)一系列詳細的決策鏈返回一個簡單的"yes" or a "no"。這些決策鏈需要拿到貸款數(shù)額、某個律師的信用歷史或支出地點，所有這一切都是通過調(diào)用單獨的Web services來完成的。

　　根據(jù)市場條件或銀行政策，這個業(yè)務過程將很可能改變信用卡應用的驗證方式。用上層Web services返回結果是相當不靈活的方法，因為它使得每次修改Web services之后都要繼續(xù)修改業(yè)務邏輯。另一方面，讓BPEL過程來編排應用邏輯會給我們帶來兩大好處。

　　BPEL的XML語法授予我們一種指令級別，通過它可以改變應用的工作流而不必在現(xiàn)場業(yè)務邏輯之后再修改。這為我們以后在更復雜的工作流情況下重用某套核心Web services提供了方便。

　　假設我們已經(jīng)為我們的核心Web servcies完成了最后的設計。我們有兩個Web services，它們組成了一個approver和一個assessor。初始分析顯示這兩個服務都能很容易地被其他信用演進過程重用。因此，現(xiàn)在來看BPEL的偽代碼并看看為創(chuàng)建BPEL-XML語法我們需要做什么。

if (creditapplication < $10,000) {
??????? if (assessor returns "lowrisk")
??????????????? return "yes"
??????? else
??????????????? return approver response
}
else
??????? return approver response

　　首先是檢查信用卡應用的數(shù)額。如果它的量超過$10,000，我們就把輸入的數(shù)據(jù)轉交給approver Web service以獲得一個響應。反之，如果數(shù)量在$10,000以下，我們就先調(diào)用assessor Web service，讓它返回一個回答，如果響應是"lowrisk"，那么應用程序立即被證實。否則我們就需要進一步調(diào)用approver Web service。

　　這是一個很直接的業(yè)務過程，很明顯的展示了BPEL的強大，達到了為我們的核心Web services編排不同調(diào)用場景的目的。現(xiàn)在，讓我們來看看實際的BPEL-XML語法。

<?xml version="1.0" encoding="UTF-8"?>
<process name="loanApprovalProcess" suppressJoinFailure="yes"
targetNamespace="http://acme.com/loanprocessing"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:apns="http://tempuri.org/services/loanapprover"
xmlns:asns="http://tempuri.org/services/loanassessor"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:lns="http://loans.org/wsdl/loan-approval" xmlns:loandef="http://tempuri.org/services/loandefinitions"
?xmlns:xsd="http://www.w3.org/2001/XMLSchema">
?? <partnerLinks>
????? <partnerLink myRole="approver" name="customer" partnerLinkType="lns:loanApprovalLinkType"/>
????? <partnerLink name="approver" partnerLinkType="lns:loanApprovalLinkType" partnerRole="approver"/>
????? <partnerLink name="assessor" partnerLinkType="lns:riskAssessmentLinkType" partnerRole="assessor"/>
?? </partnerLinks>
?? <variables>
????? <variable messageType="loandef:creditInformationMessage" name="request"/>
????? <variable messageType="asns:riskAssessmentMessage" name="riskAssessment"/>
????? <variable messageType="apns:approvalMessage" name="approvalInfo"/>
????? <variable messageType="loandef:loanRequestErrorMessage" name="error"/>
?? </variables>
?? <faultHandlers>
????? <catch faultName="apns:loanProcessFault" faultVariable="error">
???????? <reply faultName="apns:loanProcessFault" operation="approve" partnerLink="customer"
?????? portType="apns:loanApprovalPT" variable="error"/>
????? </catch>
?? </faultHandlers>
?? <flow>
????? <links>
???????? <link name="receive-to-approval"/>
???????? <link name="receive-to-assess"/>
???????? <link name="approval-to-reply"/>
???????? <link name="assess-to-setMessage"/>
??????? <link name="assess-to-approval"/>
????????? <link name="setMessage-to-reply"/>
????? </links>
????? <receive createInstance="yes" name="receive1" operation="approve" partnerLink="customer"
????? portType="apns:loanApprovalPT" variable="request">
???????? <source linkName="receive-to-approval" transitionCondition="bpws:getVariableData('request',
???????? 'amount')>=10000"/>
???????? <source linkName="receive-to-assess" transitionCondition="bpws:getVariableData('request',
???????? 'amount')<10000"/>
????? </receive>
????? <invoke inputVariable="request" name="invokeapprover" operation="approve"
????? outputVariable="approvalInfo" partnerLink="approver"
???? portType="apns:loanApprovalPT">
???????? <target linkName="receive-to-approval"/>
???????? <target linkName="assess-to-approval"/>
???????? <source linkName="approval-to-reply"/>
????? </invoke>
????? <invoke inputVariable="request" name="invokeAssessor" operation="check" outputVariable="riskAssessment"
???? partnerLink="assessor"
???? portType="asns:riskAssessmentPT">
???????? <target linkName="receive-to-assess"/>
???????? <source linkName="assess-to-setMessage" transitionCondition=
???????? "bpws:getVariableData('riskAssessment', 'risk')='low'"/>
???????? <source linkName="assess-to-approval" transitionCondition="bpws:getVariableData
??????? ('riskAssessment', 'risk')!='low'"/>
????? </invoke>
????? <reply name="reply" operation="approve" partnerLink="customer" portType="apns:loanApprovalPT"
????? variable="approvalInfo">
???????? <target linkName="approval-to-reply"/>
???????? <target linkName="setMessage-to-reply"/>
????? </reply>
????? <assign name="assign">
???????? <target linkName="assess-to-setMessage"/>
???????? <source linkName="setMessage-to-reply"/>
???????? <copy>
??????????? <from expression="'approved'"/>
??????????? <to part="accept" variable="approvalInfo"/>
???????? </copy>
????? </assign>
?? </flow>
</process>

　　注意BPEL的元素有<partnerLink>, <variable>, <faultHandler>, <flow>, >target>等等。繼續(xù)講解BPEL語法的含義超出了本問的范圍，但如果你跟進的話你就能發(fā)現(xiàn)在偽代碼中有同樣的模式。還要注意到，很多BPEL過程是使用特殊的編輯器創(chuàng)建的，這樣可以避免手寫XML時的錯誤。

　　在看過實際的BPEL過程后，你大概會問這跟實際的Web servcies的UPI或WSDL描述符有什么關系。在ActiveBPEL中，它需要你定義一個過程部署描述符(Process Deployment Descriptor)文件來告訴BPEL引擎你的過程。下面就是這個PDD文件。

<process location="bpel/loanapproval.bpel" name="bpelns:loanApprovalProcess"
xmlns="http://www.active-endpoints.com/schemas/deploy/pdd.xsd"
xmlns:bpelns="http://acme.com/loanprocessing"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
? <!-- Partner Link for inbound request from customer -->
? <partnerLinks>
??? <partnerLink name="customer">
????? <myRole allowedRoles="" binding="RPC" service="ApproveLoan"/>
??? </partnerLink>
??? <!-- Partner Link for outbound request to delegate approver -->
??? <partnerLink name="approver">
????? <partnerRole endpointReference="static">
?<wsa:EndpointReference xmlns:approver="http://tempuri.org/services/loanapprover">
?? <wsa:Address>approver:anyURI</wsa:Address>
?? <wsa:ServiceName PortName="SOAPPort">approver:LoanApprover</wsa:ServiceName>
?</wsa:EndpointReference>
????? </partnerRole>
??? </partnerLink>
??? <!-- Partner Link for outbound request to risk assessment process -->
??? <partnerLink name="assessor">
????? <partnerRole endpointReference="static">
?<wsa:EndpointReference xmlns:assessor="http://tempuri.org/services/loanassessor">
?? <wsa:Address>assessor:anyURI</wsa:Address>
?? <wsa:ServiceName PortName="SOAPPort">assessor:LoanAssessor</wsa:ServiceName>
?</wsa:EndpointReference>
????? </partnerRole>
??? </partnerLink>
? </partnerLinks>
? <wsdlReferences>
??? <wsdl location="project:/wsdl/loandefinitions.wsdl"
??? namespace="http://tempuri.org/services/loandefinitions"/>
??? <wsdl location="project:/wsdl/loanapproval.wsdl"
??? namespace="http://loans.org/wsdl/loan-approval"/>
??? <wsdl location="project:/wsdl/loanapprover.wsdl"
??? namespace="http://tempuri.org/services/loanapprover"/>
??? <wsdl location="project:/wsdl/loanassessor.wsdl"
?? namespace="http://tempuri.org/services/loanassessor"/>
? </wsdlReferences>
</process>

　　注意這個描述符是如何與剛才的BPEL過程協(xié)作的。它聲明了<process location="bpel/loanapproval.bpel">來為每個<partnerLink>定義物理地址，并聲明了多個WSDL描述符。

　　重要的是，這個文件與我們的Web services一起綁定到BPEL過程。通過上面的講解，你應該能意識到Web services WSDL文件組成了任何BPEL過程的主體。

　　前面的因為WSDL定義了一個Web service的方法、消息和特征。而一個BPEL過程則通過它的引擎使得豐富的使用信息被包含在這些標準Web services文件中，以此來編排需要的業(yè)務過程。

　　本文通過ActiveBPEL讓大家了解BPEL。如果你已經(jīng)看過Loan Approval Application for ActiveBPEL 并知道它的內(nèi)部工作方式，那么現(xiàn)在就能體會到BPEL對給你的Web services和SOA開發(fā)所帶來的價值。

Q: BPEL、WSBPEL和 BPEL4WS之間的區(qū)別是什么?
A: 除了歷史參考文獻不同外，沒有什么其他的不同。這些名字都涉及到相同的未決標準。“BPEL4WS”是起初規(guī)范的名字，它由BEA、IBM和Microsoft編寫和公布的。“WSBPEL”目前是規(guī)范和未決標準的名稱。當這個規(guī)范提交到OASIS時,出于Web服務相關標準的努力，按照OASIS命名方案更換了這個名字。盡管如此，大部分團體仍然簡單地稱這個標準為“BPEL”。

Q: 什么是 BPELJ？
A: BPELJ 是BPEL和Java 語言的組合，它允許一起運用這兩種編程語言來構建完整的業(yè)務流程應用程序。通過允許BPEL和Java一起工作， BPELJ使得每種語言可以做它最擅長的事。BPELJ優(yōu)于BPEL，但沒有它那么有競爭力。

Q:如何把BPELJ和 BPEL聯(lián)系起來，它們之間區(qū)別在哪里？
A: BPEL基本上向編程發(fā)展，它支持業(yè)務處理流程的邏輯。這些業(yè)務處理流程是獨立的應用程序，這些應用使用Web服務作為實現(xiàn)業(yè)務功能的活動。BPEL 不會成為一門通用的編程語言。然而，有人認為BPEL將和用來實現(xiàn)業(yè)務功能的其他語言（少部分的編程）結合起來。為了方便BPEL和Java 結合起來，BPELJ對BPEL做了一些小的改動并且做了一些擴展。

Q: BPEL不是針對業(yè)務分析員嗎? 如果是，為什么把Java加進來?
A: 有這么一個普遍的誤解，那就是BPEL想達到非程序設計人員或者所謂的“業(yè)務分析員”也能使用的程度。這個錯誤的概念部分根源于市場上許多針對于這組用戶的業(yè)務流程管理工具這樣的一個事實。無可置疑，工具供應商為構建BPEL和BPELJ流程提供了廣泛的可視化接口，但是語言本身的目的是為了開發(fā)人員。

Q: BPELJ如何工作？
A: 通過允許在BPEL流程定義中包含Java代碼段（稱為Java片斷），BPELJ使得Java 和BPEL能夠相互協(xié)作。

Q: 難道不應該考慮允許使用任何語言（C#、JavaScript和Java等）來設計代碼片斷嗎？
A: 這個片斷背后想法是有代表性，我們希望它能用于許多不同的語言。然而，要集成BPEL和一門特定的語言包含的不僅僅是用XML包裝目標語言。集成變量綁定、事務管理、調(diào)用路徑等問題必須周全地定義，然而，每種語言是用不同的方法解決這些問題，對所有語言進行統(tǒng)一的綁定是不現(xiàn)實的。所以， BPELJ集中解決 BPEL 和 Java的這些集成問題。我們期待著解決其他的語言的集成問題 。

Q: 難道BPELJ 沒違反“ BPEL中活動是Web服務，數(shù)據(jù)是XML,數(shù)據(jù)結構用XML架構描述”這一原則嗎？
A: 并不是世界上所有的服務都是Web服務，它們也不應該是。用J2EE更適合緊密耦合的系統(tǒng)，在這種系統(tǒng)中，容器提供的功能如安全和事務是特別有價值的。那些把業(yè)務邏輯部署成J2EE組件的人員應該能夠在業(yè)務流程中充分利用這些組件，BPEL是描述這個過程最好的一門語言。
一些人爭論說在程序片斷中用Java來完成少量計算和數(shù)據(jù)操作非常合適，但是應該通過XML/Web服務視圖強制所有服務調(diào)用。這是一個特別站不住腳的觀點。如果您有一個用Java代碼片斷寫的流程，很明顯，有一個Java開發(fā)人員參與創(chuàng)建這個流程。
這意味著您可能有下面的設想：有一個開發(fā)人員熟悉用Java調(diào)用組件，他想用Java操縱組件的輸入和輸出。迫使那個人把所有的調(diào)用看成好像是調(diào)用Web 服務一樣，這會產(chǎn)生一層混亂，阻止考慮業(yè)務邏輯。


原文地址：http://dev2dev.bea.com.cn/techdoc/2004120205.html


盡管我知道了bpel的理論，但是仍然覺得寫一個bpel挺麻煩的。盡管有一些圖形化的編輯工具，但是仍然覺得并不好用，可能是我對bpel還是不熟悉的緣故吧

但是，我可以寫一個jave類，在這個類中用各個方法描述出了各個web service的組合調(diào)用關系。現(xiàn)在我要做的，就是找一個bpel編輯器和一個bpel服務器來將這個java類的邏輯變成bpel，然后運行之

為什么沒有人將這個步驟作成自動化的呢？？？是因為沒有必要還是因為別的什么？？

本文介紹如何發(fā)布一個BPEL到一個ActiveBPEL引擎。

?

要發(fā)布一個BPEL process,你必須創(chuàng)建，安裝一個發(fā)布文件來包含你的BPEL文件。一般使用jar。

發(fā)布你的BPEL Process

發(fā)布一個BPEL process 調(diào)用創(chuàng)建一個發(fā)布文件。（一個jar但是使用.bpr為后綴）并且拷貝到你的servlet容器中。要創(chuàng)建這個文件，你必須把你的文件用特殊的目錄結構組織起來，創(chuàng)建一個或者2個配置文件。

首先創(chuàng)建一個文件夾，這個例子中我們命名為mybpel.創(chuàng)建以下子文件夾：

C:\> cd mybpel
C:\mybpel> jar cf mybpel.bpr *.pdd META-INF bpel partners wsdl
C:\mybpel> copy mybpel.bpr $CATALINA_HOME/bpr

% cd mybpel
% jar cf mybpel.bpr *.pdd META-INF bpel partners wsdl
% cp mybpel.bpr $CATALINA_HOME/bpr

你的WSDL文件可以是遠程的，但是要寫到.pdd中。

如果現(xiàn)在引擎在運行，它馬上會發(fā)現(xiàn)新的.bpr文件然后自動讀取它。你的BPEL process就可以使用了。

?

原文地址：http://robertpi.blogchina.com/422342.html

本文描述如何安裝ActiveBPEL引擎.

?

1.要求：

ActiveBPEL引擎需要一個servlet容器。安裝腳本使用了CATALINA_HOME環(huán)境變量。另外它可以在任何標準servlet容器下運行。

2.安裝：
運行安裝腳本文件：install.bat(Windows)或者是install.sh(Unix).它把需要的lib拷貝到CATALINA_HOME/shared/lib下，并且創(chuàng)建一個$CATALINA_HOME/bpr,這個目錄是放置.bpr文件的地方。

修改引擎配置文件：
服務啟動時候包含一下參數(shù)，他們放在aeEngineConfig.xml文件中，你可以在$CATALINA_HOME/bpr找到它。你可以通過http://localhost:8080/BpelAdmin/config.jsp?修改。

3.發(fā)布:

參看專門的文章：發(fā)布BPEL。
一旦引擎啟動，在你發(fā)布你的BPEL后，引擎會知道讀取對應的.bpr文件。

4.啟動引擎：

C:\activebpel> %CATALINA_HOME%\bin\startup.bat

activebpel% $CATALINA_HOME/bin/startup.sh