面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)及方法
【專利摘要】本發(fā)明公開了一種面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)及方法，主要包括：業(yè)務(wù)平面，用于確定當(dāng)前的業(yè)務(wù)需求是否適用于業(yè)務(wù)生成系統(tǒng)生成；所述業(yè)務(wù)生成系統(tǒng)具有良好的可擴(kuò)展性，通過增加XPL語言的標(biāo)簽和新開發(fā)對應(yīng)的構(gòu)件，擴(kuò)展業(yè)務(wù)生成系統(tǒng)的能力來滿足業(yè)務(wù)的需求；業(yè)務(wù)流程的腳本描述平面，主要用于完成業(yè)務(wù)的開發(fā)工作；在業(yè)務(wù)平面的業(yè)務(wù)需求確定后，使用XPL語言描述業(yè)務(wù)邏輯；可執(zhí)行代碼平面，用于從描述好的業(yè)務(wù)流程生成的可以部署運(yùn)行的代碼；網(wǎng)頁服務(wù)接口平面，用于向業(yè)務(wù)生成系統(tǒng)提供開發(fā)業(yè)務(wù)所需的業(yè)務(wù)能力。采用本發(fā)明，能夠利用XPL語言，搭建一個(gè)網(wǎng)絡(luò)增值服務(wù)平臺，提供下一代網(wǎng)絡(luò)業(yè)務(wù)所需的全部業(yè)務(wù)能力。
【專利說明】面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)及方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及計(jì)算機(jī)軟件開發(fā)技術(shù)與下一代網(wǎng)絡(luò)(NGN)技術(shù)，尤其涉及面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)及方法。
【背景技術(shù)】
[0002]隨著電信網(wǎng)絡(luò)和互聯(lián)網(wǎng)絡(luò)向下一代網(wǎng)絡(luò)的方向演進(jìn)，如何快速靈活的開發(fā)種類豐富的新型增值業(yè)務(wù)是電信領(lǐng)域和計(jì)算機(jī)領(lǐng)域所面臨的一個(gè)重要問題。
[0003]下一代網(wǎng)絡(luò)(NGN)的業(yè)務(wù)開發(fā)，一個(gè)基本問題是如何描述業(yè)務(wù)需求。擴(kuò)展標(biāo)記語言(XML)由于具有易于人和機(jī)器的理解、與底層實(shí)現(xiàn)語言無關(guān)、易于圖形化表示等優(yōu)點(diǎn)成為業(yè)務(wù)描述語言的重要發(fā)展方向之一?；赬ML的語言可以分為通用型語言和面向特定領(lǐng)域的專業(yè)語言兩種類型。其中，通用型語言以IBM的業(yè)務(wù)流程執(zhí)行語言(Business ProcessExecution Language, BPEL)為代表,其主要針對一般性流程的控制,接近于高級語言的水平，已經(jīng)成為工作流領(lǐng)域的工業(yè)標(biāo)準(zhǔn)。電信領(lǐng)域中面向特定領(lǐng)域的專業(yè)語言有很多，其中面向呼叫流程控制的代表性語言有IETF的呼叫處理語言(Calling Process Language,CPL)、W3C的呼叫控制可擴(kuò)展標(biāo)記語言(CCXML)和JAIN論壇的服務(wù)組合管理語言(ServiceComposition Management Language, SCML)等，其語言元素本身就是對呼叫處理的高度抽象，這些專業(yè)語言已經(jīng)或正在成為國際標(biāo)準(zhǔn)。
[0004]相比較而言，通用型語言有適用面廣的優(yōu)勢，缺點(diǎn)是語言復(fù)雜，開發(fā)效率低，對開發(fā)人員的要求高。而專業(yè)語言的優(yōu)點(diǎn)是語言簡單，開發(fā)效率高，對開發(fā)人員的要求低，但不能描述特定領(lǐng)域以外的業(yè)務(wù)?？焖俚臉I(yè)務(wù)開發(fā)、部署業(yè)務(wù)是企業(yè)保持競爭力的關(guān)鍵之一，所以專業(yè)語言具有相當(dāng)?shù)难芯績r(jià)值。融合網(wǎng)絡(luò)條件下通信類業(yè)務(wù)的特點(diǎn)應(yīng)該是業(yè)務(wù)種類繁多、內(nèi)容豐富、具有個(gè)性化，CPL、CCXML, SCML基本上針對傳統(tǒng)的呼叫處理業(yè)務(wù)，不能描述短信、彩信、數(shù)據(jù)庫操作等數(shù)據(jù)類業(yè)務(wù)，而且不能進(jìn)行并發(fā)、循環(huán)等操作，受到的局限較大，因而不利于下一代網(wǎng)絡(luò)的業(yè)務(wù)開發(fā)。

【發(fā)明內(nèi)容】

[0005]有鑒于此，本發(fā)明的主要目的在于提供一種面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)及方法，利用面向綜合通信的服務(wù)描述語言(ICSDL)，如擴(kuò)展呼叫處理語言(Extended-CalIing Process Language, XPL),綜合呼叫、短信、彩信、web 網(wǎng)頁、Email 等通信手段，搭建一個(gè)網(wǎng)絡(luò)增值服務(wù)平臺，能夠提供下一代網(wǎng)絡(luò)業(yè)務(wù)所需的全部業(yè)務(wù)能力，并能夠?qū)崿F(xiàn)較復(fù)雜的數(shù)據(jù)庫操作。
[0006]本發(fā)明的另一目的在于，通過利用所述面向綜合通信服務(wù)的專業(yè)語言即XPL語言，還能夠提供受到限制的并發(fā)和循環(huán)操作，確保不會(huì)出現(xiàn)死鎖和死循環(huán)。
[0007]為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的:
面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)，包括業(yè)務(wù)平面、業(yè)務(wù)流程的腳本描述平面、可執(zhí)行代碼平面以及網(wǎng)頁服務(wù)接口平面；其中: 業(yè)務(wù)平面，用于確定當(dāng)前的業(yè)務(wù)需求是否適用于業(yè)務(wù)生成系統(tǒng)生成；所述業(yè)務(wù)生成系統(tǒng)具有良好的可擴(kuò)展性，通過增加XPL語言的標(biāo)簽和新開發(fā)對應(yīng)的構(gòu)件，擴(kuò)展業(yè)務(wù)生成系統(tǒng)的能力來滿足業(yè)務(wù)的需求；
業(yè)務(wù)流程的腳本描述平面，主要用于完成業(yè)務(wù)的開發(fā)工作；在業(yè)務(wù)平面的業(yè)務(wù)需求確定后，使用XPL語言描述業(yè)務(wù)邏輯；
可執(zhí)行代碼平面對應(yīng)于所述業(yè)務(wù)流程的腳本描述平面，用于從描述好的業(yè)務(wù)流程生成的可以部署運(yùn)行的代碼；
網(wǎng)頁服務(wù)接口平面，主要包括Parlay網(wǎng)頁服務(wù)接口和其他類型的網(wǎng)頁服務(wù)接口 ；所述網(wǎng)頁服務(wù)接口平面用于向業(yè)務(wù)生成系統(tǒng)提供開發(fā)業(yè)務(wù)所需的業(yè)務(wù)能力。
[0008]面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)方法，其特征在于，包括:
A、采用業(yè)務(wù)平面確定當(dāng)前的業(yè)務(wù)需求是否適用于業(yè)務(wù)生成系統(tǒng)生成；所述業(yè)務(wù)生成系統(tǒng)具有良好的可擴(kuò)展性，通過增加XPL語言的標(biāo)簽和新開發(fā)對應(yīng)的構(gòu)件，擴(kuò)展業(yè)務(wù)生成系統(tǒng)的能力來滿足業(yè)務(wù)的需求；
B、利用業(yè)務(wù)流程的腳本描述平面，完成業(yè)務(wù)的開發(fā)工作；在業(yè)務(wù)平面的業(yè)務(wù)需求確定后，使用XPL語言描述業(yè)務(wù)邏輯；
C、然后利用對應(yīng)于所述業(yè)務(wù)流程的腳本描述平面的可執(zhí)行代碼平面，從描述好的業(yè)務(wù)流程生成的可以部署運(yùn)行的代碼；
D、最后通過網(wǎng)頁服務(wù)接口平面向業(yè)務(wù)生成系統(tǒng)提供開發(fā)業(yè)務(wù)所需的業(yè)務(wù)能力；所述網(wǎng)頁服務(wù)接口平面，主要包括Par lay網(wǎng)頁服務(wù)接口和其他類型的網(wǎng)頁服務(wù)接口。
[0009]一種包括面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)的網(wǎng)絡(luò)增值服務(wù)平臺，包括CPL業(yè)務(wù)腳本、OAM模塊及協(xié)議網(wǎng)關(guān)層；其特征在于，其業(yè)務(wù)處理系統(tǒng)還包括業(yè)務(wù)翻譯器和消息分發(fā)系統(tǒng)；其中:
業(yè)務(wù)翻譯器，用于對擴(kuò)展CPL業(yè)務(wù)腳本進(jìn)行解析，得到符合EJB規(guī)范的java代碼，然后生成java文件,并得到文件包；
消息分發(fā)系統(tǒng)，用于接收Web客戶端提交的消息和協(xié)議網(wǎng)關(guān)層上報(bào)的消息，判斷并分發(fā)到業(yè)務(wù)層中對應(yīng)的業(yè)務(wù)實(shí)例；另外消息分發(fā)系統(tǒng)還接收來自業(yè)務(wù)實(shí)例發(fā)送的消息，判斷并轉(zhuǎn)發(fā)到協(xié)議網(wǎng)關(guān)模塊。
[0010]本發(fā)明所提供的面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)及方法，具有以下優(yōu)點(diǎn):
第一，本發(fā)明通過對CPL語言進(jìn)行了擴(kuò)展，包括對CPL本身語法上的擴(kuò)展和CPL附加功能的擴(kuò)展:1)增加標(biāo)簽message-switch。使腳本執(zhí)行到這一點(diǎn)的時(shí)候阻塞,等待外界信息上報(bào)，當(dāng)外界信息到來時(shí)根據(jù)其下級標(biāo)簽中聲明的消息類型進(jìn)行分支處理。2)增加類型messageType和3)增加各種消息標(biāo)簽。4)增加能力構(gòu)件標(biāo)簽的聲明。5)增加與OAM模塊接口的標(biāo)簽。使擴(kuò)展的CPL即XPL語言支持:需要與用戶進(jìn)行交互的較為復(fù)雜的業(yè)務(wù)邏輯；業(yè)務(wù)的多入口 ；包括定位、發(fā)送短信、發(fā)送彩信以及GIS等數(shù)據(jù)業(yè)務(wù)的服務(wù)；對數(shù)據(jù)庫的訪問；以及業(yè)務(wù)自身主動(dòng)發(fā)起的業(yè)務(wù)。
[0011 ] 第二，本發(fā)明采用翻譯器模式對擴(kuò)展CPL腳本進(jìn)行解析，將XML格式的腳本到語法樹的翻譯過程劃分為前端，語法樹到目標(biāo)Java代碼(直至EJB)的過程劃分為后端。在需要做某些大的變動(dòng)，如要求翻譯CPL之外的語言，那么需要修改的部分只有前端，后端基本上可以不動(dòng)。反過來，如果生成目標(biāo)代碼需要是Java語言之外的語言，那么也只需要修改后端代碼生成部分，就可以達(dá)到目的，從而最大地減小了牽一發(fā)而動(dòng)全身的可能。
[0012]第三，本發(fā)明還設(shè)計(jì)了一套基于上下文的構(gòu)件模型和針對該模型的腳本轉(zhuǎn)換一構(gòu)件粘合算法，該算法依照業(yè)務(wù)腳本產(chǎn)生“膠水代碼”，由“膠水代碼”來把構(gòu)件粘合起來，來控制構(gòu)件的執(zhí)行。這種基于上下文的構(gòu)件組裝機(jī)制使得構(gòu)件本身得到簡化，形式上更加規(guī)整，制作也變得容易，有利于擴(kuò)展新的構(gòu)件。構(gòu)件組裝方法體現(xiàn)為一種算法和純粹的基于接口的構(gòu)件組裝方法相比雖然復(fù)雜，但對業(yè)務(wù)開發(fā)者是透明的，且相對穩(wěn)定，可以進(jìn)行充分復(fù)用。這種構(gòu)件復(fù)用模型是適用于XPL的一種更高抽象層次的構(gòu)件復(fù)用模型。
[0013]第四，本發(fā)明的開發(fā)系統(tǒng)采用的消息分發(fā)系統(tǒng)，接收業(yè)務(wù)平臺系統(tǒng)中其他模塊發(fā)送來的消息，對消息進(jìn)行判斷、處理，將其分發(fā)到對應(yīng)的業(yè)務(wù)層的模塊中去。同時(shí)，還接收來自業(yè)務(wù)層內(nèi)部模塊發(fā)送到平臺系統(tǒng)中其他模塊的消息，對消息進(jìn)行相應(yīng)的處理和判斷后，將消息發(fā)送到相應(yīng)的模塊中去。消息分發(fā)系統(tǒng)接收Web客戶端提交的消息和協(xié)議網(wǎng)關(guān)層上報(bào)的消息，判斷并分發(fā)到業(yè)務(wù)層中對應(yīng)的業(yè)務(wù)實(shí)例；另外消息分發(fā)子系統(tǒng)還接收來自業(yè)務(wù)實(shí)例發(fā)送的消息，判斷并轉(zhuǎn)發(fā)到協(xié)議網(wǎng)關(guān)模塊。其內(nèi)部的消息分發(fā)模塊既要處理業(yè)務(wù)邏輯模塊向網(wǎng)關(guān)下發(fā)的消息又要處理網(wǎng)關(guān)向業(yè)務(wù)邏輯模塊上發(fā)的消息。對于下發(fā)消息直接在消息發(fā)送子模塊的相應(yīng)接口中調(diào)用下層網(wǎng)關(guān)側(cè)提供的接口即可。
[0014]第五，采取了以上第一?第四優(yōu)點(diǎn)的業(yè)務(wù)系統(tǒng)，與目前使用CPL等專業(yè)語言的平臺相比，采取XPL的業(yè)務(wù)系統(tǒng)具有面向領(lǐng)域范圍較大、能夠適用于較復(fù)雜業(yè)務(wù)的優(yōu)點(diǎn)，更能適用于融合網(wǎng)絡(luò)條件下的下一代網(wǎng)絡(luò)(NGN)通信類業(yè)務(wù)。
【專利附圖】

【附圖說明】
[0015]圖1為本發(fā)明融合網(wǎng)絡(luò)增值服務(wù)平臺的總體結(jié)構(gòu)示意圖；
圖2為本發(fā)明的業(yè)務(wù)生成系統(tǒng)的模型示意圖；
圖3為本發(fā)明的業(yè)務(wù)翻譯器/模塊的功能框圖；
圖4為本發(fā)明的業(yè)務(wù)翻譯器實(shí)現(xiàn)的任務(wù)過程示意圖；
圖4a為腳本生成的樹結(jié)構(gòu)示意圖。
[0016]圖5為業(yè)務(wù)能力構(gòu)件結(jié)構(gòu)示意圖；
圖6為協(xié)議網(wǎng)關(guān)和業(yè)務(wù)的接口描述不意圖；
圖7為協(xié)議網(wǎng)關(guān)和業(yè)務(wù)的消息類型示意圖；
圖8為本發(fā)明的消息分發(fā)系統(tǒng)的結(jié)構(gòu)示意圖；
圖9a為業(yè)務(wù)邏輯發(fā)送消息的合作圖；
圖9b為業(yè)務(wù)邏輯發(fā)送消息的序列圖；
圖10為面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)的應(yīng)用實(shí)施例；
圖11為代理登錄腳本login, xml的示意圖；
圖12為代理服務(wù)腳本service, xml的示意圖。
【具體實(shí)施方式】
[0017]下面結(jié)合附圖及本發(fā)明的實(shí)施例對本發(fā)明的面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)及方法作進(jìn)一步詳細(xì)的說明。[0018]圖1為本發(fā)明融合網(wǎng)絡(luò)增值服務(wù)平臺的總體結(jié)構(gòu)示意圖。如圖1所示，所述平臺主要包括CPL業(yè)務(wù)腳本處理模塊、業(yè)務(wù)生成系統(tǒng)、協(xié)議網(wǎng)關(guān)層以及操作管理和維護(hù)(OAM)系統(tǒng)。其中，所述業(yè)務(wù)系統(tǒng)進(jìn)一步包括業(yè)務(wù)翻譯器、業(yè)務(wù)EJB(Enterprise Java Beans)、業(yè)務(wù)運(yùn)行環(huán)境、構(gòu)件(庫)以及消息分發(fā)系統(tǒng)。本發(fā)明將對上述各個(gè)部分分別進(jìn)行說明。
[0019]圖2為本發(fā)明的業(yè)務(wù)生成系統(tǒng)的模型示意圖。如圖2所示，為了便于對下文中基于XPL的業(yè)務(wù)生成系統(tǒng)進(jìn)行介紹，建立業(yè)務(wù)生成系統(tǒng)的概念模型。我們將所述整個(gè)業(yè)務(wù)生成系統(tǒng)大體上劃分為四個(gè)平面:即業(yè)務(wù)平面、業(yè)務(wù)流程的腳本描述平面、EJB平面和WebServices接口平面。其中:
所述業(yè)務(wù)平面，是從業(yè)務(wù)用戶和業(yè)務(wù)提供者的角度出發(fā)，確定當(dāng)前的業(yè)務(wù)需求是否適用于該業(yè)務(wù)生成系統(tǒng)生成。業(yè)務(wù)生成系統(tǒng)具有良好的可擴(kuò)展性，如果當(dāng)前的業(yè)務(wù)生成系統(tǒng)不能完全滿足需求，可以考慮增加XPL語言的標(biāo)簽和新開發(fā)對應(yīng)的構(gòu)件，擴(kuò)展業(yè)務(wù)生成系統(tǒng)的能力來滿足業(yè)務(wù)的需求。
[0020]所述業(yè)務(wù)流程的腳本描述平面，主要完成業(yè)務(wù)的開發(fā)工作。在業(yè)務(wù)平面的業(yè)務(wù)需求確定以后，使用XPL語言來描述業(yè)務(wù)邏輯。業(yè)務(wù)開發(fā)者可以直接使用XPL語言描述業(yè)務(wù)流程，也可以在圖形化的開發(fā)界面里通過拖放圖形化的標(biāo)簽控件來來開發(fā)業(yè)務(wù)，即是一種“所見即所得”的業(yè)務(wù)開發(fā)模式。
[0021]所述可執(zhí)行代碼平面對應(yīng)于業(yè)務(wù)流程的腳本描述平面，是從描述好的業(yè)務(wù)流程生成的可以部署運(yùn)行的代碼。所謂的業(yè)務(wù)生成技術(shù)，其實(shí)現(xiàn)方法的本質(zhì)就是某種形式的軟件復(fù)用技術(shù)。在軟件復(fù)用領(lǐng)域，基于構(gòu)件的復(fù)用技術(shù)是當(dāng)前的研究熱點(diǎn)?；旧蟈PL的每個(gè)標(biāo)簽在代碼實(shí)現(xiàn)上都對應(yīng)著一個(gè)構(gòu)件，業(yè)務(wù)生成系統(tǒng)事先準(zhǔn)備好XPL中所有用到的構(gòu)件并存放在構(gòu)件(庫)中。業(yè)務(wù)生成系統(tǒng)根據(jù)用XPL所描述的業(yè)務(wù)邏輯將業(yè)務(wù)流程中所涉及到的構(gòu)件組裝起來，并封裝成EJB，形成可以實(shí)際部署運(yùn)行的業(yè)務(wù)。
[0022]網(wǎng)頁服務(wù)(Web Services)接口平面,主要包括Parlay Web Services接口和其他類型的Web Services接口。Web Services接口平面負(fù)責(zé)向業(yè)務(wù)生成系統(tǒng)提供開發(fā)業(yè)務(wù)所需的業(yè)務(wù)能力。
[0023]以上所述的業(yè)務(wù)生成系統(tǒng)，即本發(fā)明面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)。本發(fā)明設(shè)計(jì)并實(shí)現(xiàn)了一種面向綜合通信服務(wù)的專業(yè)語言即XPL，通過使用所述XPL語言，綜合呼叫、短信、彩信、web網(wǎng)頁、Email等通信手段，構(gòu)建一個(gè)如圖1所示的網(wǎng)絡(luò)增值服務(wù)平臺，以提供下一代網(wǎng)絡(luò)(NGN)業(yè)務(wù)所需的全部業(yè)務(wù)能力。
[0024]一、下面對面向綜合通信的服務(wù)描述語言(ICSDL)作一簡要介紹。
[0025]1.1面向綜合通信的服務(wù)描述語言(ICSDL):
CPL是IETF提出的一種基于XML的呼叫控制語言。它用于控制IP電話類業(yè)務(wù)，被設(shè)計(jì)成可以在服務(wù)器端或用戶端分別或同時(shí)執(zhí)行。CPL具有功能強(qiáng)大、資源消耗少、工作高效、容易實(shí)現(xiàn)、易于檢驗(yàn)、運(yùn)行安全、方便編寫和處理、獨(dú)立于操作系統(tǒng)/網(wǎng)絡(luò)控制協(xié)議、可擴(kuò)展性好的特點(diǎn)。但出于安全的考慮，CPL語言中沒有提供變量、循環(huán)等特性，也不允許在服務(wù)器端運(yùn)行程序，從而保證CPL能夠安全在服務(wù)器端運(yùn)行。CPL推出的目的是作為更加方便的業(yè)務(wù)開發(fā)手段提供給業(yè)務(wù)提供商、第三方業(yè)務(wù)開發(fā)商和終端用戶，用于進(jìn)行業(yè)務(wù)定義和使用，它是IPTEL推薦的在H.323/SIP網(wǎng)絡(luò)系統(tǒng)中使用的呼叫處理語言。CPL的功能包括指定呼叫控制方式、指示呼叫操作的以及對非呼叫動(dòng)作的支持功能。[0026]但是CPL語言由于其自身的簡單性和它本身的目的，目前對以下幾種狀況無法支持:(1)需要與用戶進(jìn)行交互的較為復(fù)雜的業(yè)務(wù)邏輯；(2)業(yè)務(wù)的多入口 ；(3)包括定位、發(fā)送短信、發(fā)送彩信以及GIS等數(shù)據(jù)業(yè)務(wù)的服務(wù)；(4)對數(shù)據(jù)庫的訪問；(5)業(yè)務(wù)自身主動(dòng)發(fā)起的業(yè)務(wù)。
[0027]因此，需要對CPL語言進(jìn)行一定的擴(kuò)展，目前包括兩方面的擴(kuò)展一CPL本身語法上的擴(kuò)展和CPL附加功能的擴(kuò)展，擴(kuò)展策略如下:
(I)增加標(biāo)簽message-switch。該標(biāo)簽為switchType類型。腳本執(zhí)行到這一點(diǎn)的時(shí)候阻塞，等待外界信息上報(bào)，當(dāng)外界信息到來時(shí)根據(jù)其下級標(biāo)簽中聲明的消息類型進(jìn)行分支處理。
[0028](2)增加類型 messageType ；
(3)增加各種消息標(biāo)簽。這些標(biāo)簽為messageType類型。
[0029](4)增加能力構(gòu)件標(biāo)簽及其聲明。標(biāo)簽的內(nèi)容包括:構(gòu)件的名稱、參數(shù)的名稱和類型、是否有返回值、返回值的名稱、是否拋出異常、對構(gòu)件的調(diào)用是同步還是異步。這些內(nèi)容在擴(kuò)展CPL schema里面聲明。目前增加的構(gòu)件標(biāo)簽包括定位、發(fā)送短信、發(fā)送彩信、GIS服務(wù)等。
[0030](5)增加與OAM模塊接口的標(biāo)簽，例如計(jì)費(fèi)。
[0031]1.1.1 ICSDL Message-switch 標(biāo)簽引入與 Incoming 標(biāo)簽語義擴(kuò)充。
[0032]如果用擴(kuò)展CPL即XPL實(shí)現(xiàn)的業(yè)務(wù)能夠以多種觸發(fā)方式來觸發(fā)，那么業(yè)務(wù)種類將得到大量增加，業(yè)務(wù)的豐富性也將極大提高。我們沿用以前的incoming入口，而擴(kuò)展其語義，使之能夠接受除了呼叫上報(bào)消息以外的觸發(fā)消息。能夠較好的延續(xù)CPL的單入口式業(yè)務(wù)觸發(fā)機(jī)制，對于業(yè)務(wù)開發(fā)者來說，不需要學(xué)習(xí)太多新的概念，只需要知道:在這個(gè)incoming入口，除了可以接受呼叫上報(bào)消息之外，還可以接受諸如web頁面點(diǎn)擊消息、短信觸發(fā)消息、地理位置變更上報(bào)消息等等消息類型。因此對于業(yè)務(wù)開發(fā)者來說，采取擴(kuò)展incoming語義方式的CPL具有較平緩的學(xué)習(xí)曲線。
[0033]然而,擴(kuò)展incoming語義帶來的問題是:判斷究竟是呼叫消息還是別的消息觸發(fā)的業(yè)務(wù)時(shí)，顯然需要一種類似于CPL里的string-switch那樣的分支判斷功能語句。在CPL中，switch類型的語句有以下幾種:string-switch (對字符串內(nèi)容進(jìn)行判斷)，address-switch (對呼叫地址的所有或者部分進(jìn)行判斷)，language-switch (對會(huì)話使用的語言類型進(jìn)行判斷)，priority-switch (對會(huì)話的優(yōu)先級進(jìn)行判斷)以及time_switch(對呼叫到達(dá)的時(shí)刻進(jìn)行判斷)。在這些switch中，如果要最大化地利用現(xiàn)有基礎(chǔ)而不作大的變動(dòng)，那么最有可能的候選者就是string-switch。只需要在incoming后面緊接一個(gè)string-switch,并且對處在這個(gè)位置的string-switch的處理流程做一些特殊處理,使之有別于原始意義上的string-switch，而能夠?qū)ο⒌念愋瓦M(jìn)行判斷就可以了。問題在于，業(yè)務(wù)并不只是在開始的時(shí)候需要對消息類型進(jìn)行判斷。在對CPL該語言本身進(jìn)行分析的過程中，可以發(fā)現(xiàn)，出現(xiàn)業(yè)務(wù)“暫?！钡牡胤綖閜roxy。例如，當(dāng)呼叫觸發(fā)某業(yè)務(wù)時(shí)，經(jīng)過一系列其它處理流程，業(yè)務(wù)邏輯決定要接續(xù)呼叫，于是這里出現(xiàn)了 proxy標(biāo)簽。這時(shí)候，proxy后面所跟的busy/noanswer等標(biāo)簽,都是一種提示，即:proxy是下發(fā)呼叫接續(xù)消息給協(xié)議網(wǎng)關(guān)的動(dòng)作發(fā)出者，之后進(jìn)入“等待”，也就是“業(yè)務(wù)暫停”狀態(tài)。業(yè)務(wù)的繼續(xù)執(zhí)行，是由協(xié)議網(wǎng)關(guān)來控制的:要么返回接續(xù)成功指示，要么返回各種接續(xù)失敗指示。接到這些指示以后，proxy后繼的標(biāo)簽就會(huì)沿著相應(yīng)的分支走下去。這就是一個(gè)典型的“業(yè)務(wù)暫?！卑咐?。在實(shí)際的業(yè)務(wù)中，不僅僅是proxy處才需要這樣的暫停。假設(shè)這樣的業(yè)務(wù)需求出現(xiàn)了，原始CPL顯然是無法滿足要求。因此，要達(dá)到我們的要求，需要在proxy之后引入一種“業(yè)務(wù)暫?！睓C(jī)制，使得業(yè)務(wù)在啟用“業(yè)務(wù)暫?！钡倪@一點(diǎn)能夠暫停下來，等待事件的發(fā)生，從而再根據(jù)事件的類型(也就是消息的類型)來判斷往下的分支如何執(zhí)行。在本業(yè)務(wù)中，可以想象，在proxy之后，可以啟動(dòng)定時(shí)器定時(shí)15分鐘，時(shí)間到達(dá)的時(shí)候通知業(yè)務(wù)邏輯；之后就是業(yè)務(wù)暫停點(diǎn)，它后面可以跟timeout標(biāo)簽(新引入，表示超時(shí)事件到達(dá))、onhook標(biāo)簽(新引入，表示通話方掛機(jī))等標(biāo)簽。在定時(shí)器超時(shí)以后，業(yè)務(wù)邏輯就會(huì)執(zhí)行到業(yè)務(wù)暫停點(diǎn)，判斷是timeout事件，于是執(zhí)行timeout分支，后面的業(yè)務(wù)邏輯就可以任意地進(jìn)行呼叫控制和用戶提示音操作了?？梢?，引入業(yè)務(wù)暫停點(diǎn)，做到了原CPL不可能做到的事情，很好地提高了業(yè)務(wù)的交互性。并且以終極搜索業(yè)務(wù)為研究案例而言，業(yè)務(wù)暫停點(diǎn)應(yīng)用最多的情況就是等待座席的web界面按鈕點(diǎn)擊，這些點(diǎn)擊也會(huì)作為消息下發(fā)給業(yè)務(wù)邏輯，因此用業(yè)務(wù)暫停點(diǎn)來捕捉這些點(diǎn)擊事件是再合適不過的了。為了清晰，以及與原始CPL結(jié)構(gòu)統(tǒng)一起見，將業(yè)務(wù)暫停點(diǎn)的形式也規(guī)定為 “message-switch”。
[0034]定義:當(dāng)message-switch 緊接在 incoming 之后出現(xiàn)時(shí)，該 message-switch 認(rèn)為是作為異步形式出現(xiàn)，它的作用就是判斷觸發(fā)業(yè)務(wù)的消息是呼叫消息還是其它消息，之后跟message標(biāo)簽,用于劃分不同分支。當(dāng)message-switch出現(xiàn)在業(yè)務(wù)邏輯的其他部分時(shí)，該message-switch認(rèn)為是同步,也就是它需要等待外界消息觸發(fā)方能繼續(xù)往下執(zhí)行。
[0035]該標(biāo)簽在腳本中表示腳本運(yùn)行到這點(diǎn)之后便阻塞，直到由外界消息到來才繼續(xù)往下運(yùn)行，將收到的消息與message-switch標(biāo)簽下級定義的各種消息類型進(jìn)行比較，如果找到匹配的消息標(biāo)簽，就執(zhí)行相應(yīng)消息標(biāo)簽下面指定的動(dòng)作。如果沒有找到匹配消息，默認(rèn)處理就是結(jié)束業(yè)務(wù)。所以業(yè)務(wù)編寫者在編寫業(yè)務(wù)的時(shí)候就要考慮完備在該點(diǎn)可能收到的消息。此外，也可以考慮提供”default”標(biāo)簽，表示對找不到匹配消息的默認(rèn)處理。視開發(fā)中的需求而定。
[0036]1.1.2 ICSDL中間變量標(biāo)簽variables的引入。
[0037]在業(yè)務(wù)邏輯的執(zhí)行過程當(dāng)中，能力構(gòu)件會(huì)產(chǎn)生一些數(shù)據(jù)結(jié)果，輸入消息也會(huì)攜帶數(shù)據(jù)，這些數(shù)據(jù)往往可以被后面運(yùn)行的能力構(gòu)件使用。比如在一個(gè)業(yè)務(wù)邏輯中，可能會(huì)先調(diào)用獲得位置信息的能力元素獲取用戶的位置，然后生成地圖圖片的構(gòu)件需要使用這個(gè)位置信息去生成相應(yīng)的圖片。這種數(shù)據(jù)在業(yè)務(wù)邏輯描述語言中被稱為中間數(shù)據(jù)。中間數(shù)據(jù)可以保存在外存(如，數(shù)據(jù)庫)中，再通過提供訪問外存的能力元素來獲取中間數(shù)據(jù)。但是如果中間數(shù)據(jù)的使用比較頻繁，勢必會(huì)降低業(yè)務(wù)的運(yùn)行速度。因此有必要將這些數(shù)據(jù)以中間數(shù)據(jù)的形式保存在內(nèi)存中，并提供一種合適的方式對內(nèi)存中的中間數(shù)據(jù)進(jìn)行訪問。
[0038]1.1.3 ICSDL等待輸入消息通信能力的擴(kuò)展。
[0039]雖然在CPL語言中一些標(biāo)簽已經(jīng)能夠提供等待消息的能力，如proxy標(biāo)簽，但是這些標(biāo)簽都是功能標(biāo)簽，與具體應(yīng)用相關(guān)，無法滿足業(yè)務(wù)通用性的需求，因此專門擴(kuò)展
了一個(gè)通用的等待輸入消息的標(biāo)簽-recvMessage。在一般情況下，recvMessage需
要等待外界的輸入，然后根據(jù)輸入的消息轉(zhuǎn)入不同的分支。但如果recvMessage出現(xiàn)在緊接著incoming元素的情況下，由于此時(shí)業(yè)務(wù)必定已經(jīng)收到一條觸發(fā)業(yè)務(wù)的消息，所以recvMessage就不需要再等待外界的輸入，而直接判斷這條觸發(fā)業(yè)務(wù)的消息的名稱即可，也就是說緊接著incoming的recvMessage元素不需要等待外界的輸入。
[0040]由于在某一時(shí)刻等待的消息可能會(huì)有多種，因此在該標(biāo)簽下就可能會(huì)有多個(gè)消息節(jié)點(diǎn)，每個(gè)消息節(jié)點(diǎn)代表一種收到的消息。這與proxy有些類似,但不同的是，proxy后等待的消息是固定的，可以在schema里明確定義,而recvMessage等待的消息則是隨著業(yè)務(wù)的不同而不同，因此schema里其子節(jié)點(diǎn)就無法直接寫成消息的名稱。為了解決這個(gè)問題，recvMessage的子節(jié)點(diǎn)統(tǒng)一使用標(biāo)簽message,該標(biāo)簽有一個(gè)屬性name表示收到的消息的名稱。通過這種方式，業(yè)務(wù)開發(fā)者就可以動(dòng)態(tài)地根據(jù)自身業(yè)務(wù)的需求寫上需要等待的消息名稱而又遵守了腳本的schema。
[0041]在前面曾經(jīng)提到，收到的消息有可能需要將其攜帶的參數(shù)賦給腳本中的一些中間變量。Message標(biāo)簽實(shí)際上就是消息節(jié)點(diǎn)，因此,當(dāng)需要賦值的時(shí)候,在message下面需要增加parameters和parameter兩種子標(biāo)簽,添加的方式與前面相同,在此不再贅述。
[0042]1.1.4 ICSDL的循環(huán)控制Goto標(biāo)簽。
[0043]除了擴(kuò)充構(gòu)件、message-switch以外，還需要對語法結(jié)構(gòu)增加循環(huán)語句就是goto。CPL原先設(shè)計(jì)有sub標(biāo)簽，它可以理解為函數(shù)調(diào)用，即可以調(diào)用在它之前聲明過的action,而事實(shí)上也可以理解為一種特殊的goto,只不過是單方向的goto,也就是只能夠跳轉(zhuǎn)到在sub語句之前。為了提高程序的效率，同時(shí)又不破壞程序的良好結(jié)構(gòu)，有控制地使用一些goto語句是有必要的。在實(shí)際業(yè)務(wù)場景中，最經(jīng)常遇到的跳轉(zhuǎn)情況就是循環(huán)放音收號，這是不可避免的回跳型goto。對于終極搜索業(yè)務(wù)來說，座席不斷接聽新用戶來話也是在該座席登錄以后的整個(gè)會(huì)話過程中——也就是座席腳本執(zhí)行的過程中——的回跳型循環(huán)過程。另一種是非回跳型跳轉(zhuǎn)，例如從等待狀態(tài)根據(jù)用戶的輸入或者類似的外界條件來多次跳轉(zhuǎn)到不同的action (例如循環(huán)地發(fā)送短信、email等)然后又跳回等待狀態(tài)——這在今天的手機(jī)導(dǎo)航業(yè)務(wù)中可以很明顯地看出來。因此如果繼續(xù)沿用CPL純線性順序執(zhí)行機(jī)制，那么這些用戶體驗(yàn)豐富的特色業(yè)務(wù)都將成為不可能。綜合考慮兼容性和功能性，決定在擴(kuò)展CPL中添加goto標(biāo)簽。這樣既保留了原有sub語句的定義，又滿足了新的跳轉(zhuǎn)要求。goto標(biāo)簽與sub標(biāo)簽的使用方式基本相同，所不同的只是它的語義是可以跳轉(zhuǎn)到在任何地方聲明的subaction。
[0044]1.1.5 ICSDL業(yè)務(wù)能力構(gòu)件標(biāo)簽的擴(kuò)展。
[0045]腳本語言將會(huì)包含許多與具體應(yīng)用相關(guān)的業(yè)務(wù)能力標(biāo)簽，比如呼叫能力標(biāo)簽、短信能力標(biāo)簽、GIS能力標(biāo)簽等，這些標(biāo)簽不僅是網(wǎng)絡(luò)能力在腳本語言中的簡單表示，有的標(biāo)簽可以具有一些簡單的邏輯性。軟件構(gòu)件技術(shù)提高了代碼的可重用性能力，因此可以將這些能力標(biāo)簽對應(yīng)的功能用軟件構(gòu)件技術(shù)進(jìn)行實(shí)現(xiàn)，在業(yè)務(wù)腳本中被稱為業(yè)務(wù)能力構(gòu)件(簡稱構(gòu)件)。構(gòu)件與具體應(yīng)用相關(guān)，隨著以后應(yīng)用環(huán)境和網(wǎng)絡(luò)能力的增加，構(gòu)件的數(shù)量也會(huì)隨之增加。業(yè)務(wù)能力構(gòu)件是一個(gè)較為復(fù)雜的技術(shù)，本文將在后文中給出構(gòu)件的較為詳細(xì)的設(shè)計(jì)。在腳本schema中構(gòu)件標(biāo)簽都繼承自Node類型。
[0046]1.1.6 ICSDL擴(kuò)展能力標(biāo)簽描述文件。
[0047]ICSDL擴(kuò)展能力標(biāo)簽是指用來表示通信網(wǎng)支持的呼叫控制能力以及其他支撐網(wǎng)能力等的能力標(biāo)簽。在不引起混淆的前提下，所述的能力標(biāo)簽也可稱為構(gòu)件。目前系統(tǒng)內(nèi)建的能力標(biāo)簽包括短信發(fā)送/接收能力、呼叫控制能力、定位能力等。隨著網(wǎng)絡(luò)能力的不斷擴(kuò)充和豐富，會(huì)出現(xiàn)更多的網(wǎng)絡(luò)能力，這時(shí)候就可以通過在業(yè)務(wù)腳本中使用擴(kuò)充能力標(biāo)簽來增加業(yè)務(wù)的功能。擴(kuò)充能力標(biāo)簽時(shí)，要求遵循擴(kuò)展語法，并且能力提供者要提供能夠調(diào)用的相應(yīng)Java類。書寫規(guī)范:參見能力標(biāo)簽擴(kuò)展schema。
[0048]1.1.7 ICSDL支持多腳本交互的擴(kuò)展標(biāo)簽。
[0049]復(fù)雜業(yè)務(wù)需要多個(gè)腳本來描述多個(gè)獨(dú)立子業(yè)務(wù)流程，這些腳本之間的交互需要通過消息隊(duì)列來進(jìn)行。腳本通過指定消息隊(duì)列的名稱來說明自己使用到哪些消息隊(duì)列，每個(gè)腳本可以往消息隊(duì)列中寫消息，也可以從消息隊(duì)列中取消息，也可以既讀又寫。通過在參與交互的各個(gè)腳本中商定好需要使用的消息隊(duì)列的名稱，就可以實(shí)現(xiàn)多腳本之間的交互。
[0050]為此，引入notify_message 和 pick_message 標(biāo)簽，向名為 bufferName 的字符串鏈表添加一個(gè)記錄，此標(biāo)簽是同步的。向本腳本樹對應(yīng)的字符串鏈表查找滿足匹配條件的記錄，此標(biāo)簽是同步的。
[0051]1.1.8 ICSDL數(shù)據(jù)庫訪問語法元素。
[0052]為了能夠在業(yè)務(wù)邏輯描述語言中能夠訪問和修改數(shù)據(jù)庫里的數(shù)據(jù)，在業(yè)務(wù)邏輯描述語言中專門定義了相應(yīng)操作的構(gòu)件，目前包含最常用的添加、刪除、查詢和更新操作。這些功能都可以以構(gòu)件的形式提供。
[0053]1.1.9 ICSDL 其他擴(kuò)展。
[0054]擴(kuò)展CP L為了能夠支持強(qiáng)大的業(yè)務(wù)邏輯能力，需要能夠在腳本中嵌入表達(dá)式，以便在運(yùn)行時(shí)獲取并處理各種數(shù)據(jù)。為此，規(guī)定用“$”作為表達(dá)式的起始標(biāo)識，在此符號后，緊接表達(dá)式的內(nèi)容，可以為各種算術(shù)、邏輯運(yùn)算表達(dá)式，也可以是從業(yè)務(wù)運(yùn)行上下文ServiceContext (見后文)中提取內(nèi)容并進(jìn)行運(yùn)算。當(dāng)構(gòu)件的參數(shù)為數(shù)組時(shí)(主要是于數(shù)據(jù)庫查詢操作的參數(shù))，腳本中可以用“…”作為數(shù)組的各個(gè)元素的分隔符，將各個(gè)元素的值隔開，從而可以將一個(gè)數(shù)組放在XML標(biāo)簽的一個(gè)屬性中。
[0055]二、下面我們對基于構(gòu)件的1-VASDL解析器的設(shè)計(jì)與實(shí)現(xiàn)過程進(jìn)行說明。
[0056]根據(jù)前述內(nèi)容，我們采用翻譯器模式來進(jìn)行CPL腳本的解析。面對以XML格式出現(xiàn)的CPL腳本時(shí)，所需要做的工作是將XML文檔解析成樹型結(jié)構(gòu)，之后再通過某種方式映射成翻譯類語法樹，最后進(jìn)行代碼生成。這樣，可將XML腳本到語法樹的翻譯過程劃分為前端，語法樹到目標(biāo)Java代碼(直至EJB)的過程劃分為后端。這樣劃分的優(yōu)點(diǎn)是:當(dāng)如果需要做某些大的變動(dòng)，例如，如果要求翻譯CPL之外的語言，那么需要修改的部分只有前端，后端基本上可以不動(dòng)。反過來，如果生成目標(biāo)代碼需要是Java語言之外的語言(如由于技術(shù)的選擇或者政策等原因要求使用EJB以外的技術(shù))，那么也只需要修改后端代碼生成部分，就可以達(dá)到目的，從而最大地減小了牽一發(fā)而動(dòng)全身的可能。
[0057]具體的前端主要組成部分包括:DOM (Document Object Model)解析器和Converter類組。后端主要組成部分是CodeGenerator類組。前端將XML文本經(jīng)過DOM引擎解析之后成為DOM樹對象，每個(gè)節(jié)點(diǎn)就映射為一個(gè)個(gè)Element對象，之后由一個(gè)稱為ConverterFactory的核心類，將Element樹映射到Converter樹(這里用了一次翻譯器模式)，至此為前端。后端從Converter樹開始，由每個(gè)Converter類(準(zhǔn)確地說,是Converter的Converter的各個(gè)子類)再將自己映射為CodeGenerator樹,每個(gè)CodeGenerator子類進(jìn)行實(shí)際的語境分析和最終Java代碼生成。到CodeGenerator為止，翻譯器所做的工作已經(jīng)完成了從CPL腳本到Java主要代碼的轉(zhuǎn)換工作，要成為最終可運(yùn)行的EJB模塊，還需要依賴于相當(dāng)一部分的周邊工作。這些工作主要包括Java類的最終生成、EJB配置文件的生成、業(yè)務(wù)EJB的打包(如果使用到數(shù)據(jù)庫的話，還需要涉及到數(shù)據(jù)庫EJB的配置文件生成和EJB打包)、運(yùn)行依賴庫的生成、最終EAR包的打包，至此，一個(gè)可運(yùn)行的EJB模塊即告成。如圖3所示的一個(gè)完整的業(yè)務(wù)，包括CPL腳本、業(yè)務(wù)數(shù)據(jù)描述文件以及業(yè)務(wù)配置文件，它們均由業(yè)務(wù)開發(fā)者提供。
[0058]圖3為本發(fā)明的業(yè)務(wù)翻譯器/模塊的功能框圖。如圖3所示，該業(yè)務(wù)翻譯模塊，主要包括:
CPL腳本:定義了業(yè)務(wù)的流程，包括對各個(gè)功能構(gòu)件的調(diào)用、消息的收發(fā)和處理等。
[0059]CPL腳本管理模塊:對下層模塊屏蔽CPL腳本的物理位置，即無論CPL腳本是以物理文件形式還是以數(shù)據(jù)庫表項(xiàng)或者其它形式存在，此模塊都能夠分別對待，無差別地向下層模塊提供CPL腳本的內(nèi)容。
[0060]樹結(jié)構(gòu)生成模塊:根據(jù)上層模塊傳進(jìn)來的CPL腳本，生成腳本對應(yīng)的樹。以便下層模塊對其進(jìn)行解析、翻譯。
[0061]CPL解析模塊:為業(yè)務(wù)翻譯模塊的核心。它根據(jù)樹結(jié)構(gòu)生成模塊生成的樹結(jié)構(gòu),對其進(jìn)行語義分析，并結(jié)合上下文，生成相應(yīng)的Java代碼(詳細(xì)翻譯算法參見后文)。它要用到的幾大數(shù)據(jù)結(jié)構(gòu)包括:擴(kuò)展CPL Schema、業(yè)務(wù)運(yùn)行上下文(Service Context)、符號表。
[0062]這里，擴(kuò)展CPL Schema是本業(yè)務(wù)平臺對基本CPL Schema進(jìn)行擴(kuò)展后的Schema。業(yè)務(wù)運(yùn)行上下文(Service Context)，是某特定業(yè)務(wù)實(shí)例運(yùn)行時(shí)存儲變量以及上下文交互信息等內(nèi)容的環(huán)境對象。Service Context用于存儲業(yè)務(wù)運(yùn)行時(shí)數(shù)據(jù)。隨著業(yè)務(wù)的不同,它們運(yùn)行時(shí)所需要維護(hù)的數(shù)據(jù)也不同，例如呼叫/ web消息等外界消息中的屬性，以及調(diào)用構(gòu)件的返回值等等。這些數(shù)據(jù)需要存儲在業(yè)務(wù)EJB中。由于這些數(shù)據(jù)的類型各不相同，因此用統(tǒng)一的名一值對映射來存儲比較好。這樣的名一值對映射就是由Service Context來維護(hù)的。符號表，用來保存解析過程中識別的符號，便于后繼的代碼生成。
[0063]Java代碼生成模塊:根據(jù)CPL解析模塊解析的結(jié)果，以及上述幾大數(shù)據(jù)結(jié)構(gòu)，進(jìn)行適當(dāng)綜合，代碼寫入，最終生成可編譯的Java代碼。
[0064]這里，業(yè)務(wù)數(shù)據(jù)描述文件，描述了該業(yè)務(wù)使用到的數(shù)據(jù)庫表及其對應(yīng)的程序語言數(shù)據(jù)結(jié)構(gòu)。業(yè)務(wù)配置文件，描述業(yè)務(wù)在部署時(shí)的一些配置項(xiàng)。
[0065]配置文件管理模塊:對下層模塊屏蔽上述兩類業(yè)務(wù)相關(guān)信息文件的物理位置。
[0066]配置模塊:根據(jù)配置信息，結(jié)合Java代碼，生成與之相符合的部署配置文件。
[0067]翻譯器主要實(shí)現(xiàn)將XML格式的業(yè)務(wù)邏輯描述文件和業(yè)務(wù)數(shù)據(jù)描述文件轉(zhuǎn)換成遵循EJB規(guī)范的java文件和部署描述符文件并最終編譯、打包成可以在EJB容器中部署的ear文件。
[0068]翻譯過程有多個(gè)子任務(wù)需要完成，如圖4所示，顯示了這些子任務(wù)(由于對業(yè)務(wù)邏輯描述文件和業(yè)務(wù)數(shù)據(jù)數(shù)據(jù)描述文件的子任務(wù)相同，因此這里不再單獨(dú)區(qū)分開來)。其中:
子任務(wù)一:腳本驗(yàn)證。這一步主要是對腳本文件進(jìn)行驗(yàn)證，如果驗(yàn)證通過則生成一棵DOM樹為后面的子任務(wù)作準(zhǔn)備。
[0069]子任務(wù)二:代碼生成。對于業(yè)務(wù)邏輯描述文件，這一步遍歷前一步得到的DOM樹的每個(gè)DOM節(jié)點(diǎn)，根據(jù)DOM節(jié)點(diǎn)代表的構(gòu)件的類型進(jìn)行翻譯，生成符合EJB規(guī)范的java代碼，包括Home接口、Remote接口和Bean文件的代碼，以及部屬描述符文件。對于數(shù)據(jù)描述文件，這一步也是遍歷前一步得到的DOM樹節(jié)點(diǎn),根據(jù)節(jié)點(diǎn)的名稱生成實(shí)體bean的LocalHome文件、Local文件、Bean文件、PK文件以及部署描述符文件。
[0070]子任務(wù)三:文件生成。這一步是將上一步生成的java代碼和部屬描述符文件的內(nèi)容寫到相應(yīng)的文件當(dāng)中。
[0071]子任務(wù)四:編譯、打包。這一步是將上一步生成的java文件進(jìn)行編譯生成class文件，然后將class文件與部署描述符文件打成jar包，最后再將根據(jù)業(yè)務(wù)邏輯文件生成的jar包和根據(jù)業(yè)務(wù)數(shù)據(jù)文件生成的jar包打到ear包中。
[0072]2.1 ICSDI業(yè)務(wù)腳本驗(yàn)證。
[0073]由于語法驗(yàn)證可以通過schema直接進(jìn)行驗(yàn)證，因此在這里不再贅述。
[0074]將數(shù)據(jù)查詢操作返回結(jié)果賦給中間變量的驗(yàn)證也比較特殊，由于返回結(jié)果在構(gòu)件配置文件中無法定義，因此需要查詢數(shù)據(jù)描述文件，獲得結(jié)果名稱和結(jié)果類型的信息，然后進(jìn)行驗(yàn)證。
[0075]2.2 ICSDL業(yè)務(wù)翻譯規(guī)則。
[0076]2.2.1業(yè)務(wù)邏輯描述文件翻譯的設(shè)計(jì)。業(yè)務(wù)邏輯描述文件將被翻譯成有狀態(tài)的Session Bean，翻譯出的文件需要考慮如何與外界交互，如何維護(hù)業(yè)務(wù)實(shí)例的狀態(tài)等問題。
[0077]2.2.2構(gòu)建標(biāo)簽的翻譯。每個(gè)構(gòu)件標(biāo)簽在翻譯時(shí)都要先生成一個(gè)函數(shù)，調(diào)用構(gòu)件的代碼都在這個(gè)函數(shù)作用域中。為了使函數(shù)名稱唯一，可以將從腳本中根節(jié)點(diǎn)到此標(biāo)簽節(jié)點(diǎn)的路徑上的所有節(jié)點(diǎn)名稱合在一起作為函數(shù)名稱。
[0078]每個(gè)構(gòu)件都會(huì)有一個(gè)構(gòu)件類，當(dāng)遇到代表構(gòu)件的標(biāo)簽時(shí)，在翻譯代碼里添加調(diào)用構(gòu)件接口函數(shù)的語句。由于構(gòu)件是無狀態(tài)的，因此接口函數(shù)可以設(shè)計(jì)成靜態(tài)函數(shù)。接口函數(shù)的參數(shù)分為兩種:一種是內(nèi)建的參數(shù)，表示該參數(shù)的賦值自動(dòng)取自腳本內(nèi)建的中間變量；一種是非內(nèi)建的參數(shù)，表示該參數(shù)的賦值由業(yè)務(wù)開發(fā)者在腳本中指定。在翻譯構(gòu)件的時(shí)候，每種類型的構(gòu)件都會(huì)有固定的翻譯方法。構(gòu)件的類型、名稱以及接口函數(shù)的信息翻譯器可以通過讀取構(gòu)件的屬性配置文件來獲取。
[0079]2.2.3產(chǎn)生條件分支標(biāo)簽的翻譯。由于在schema里沒有指定腳本中必須寫上默認(rèn)邏輯輸出節(jié)點(diǎn)，因此當(dāng)在條件分支里沒有出現(xiàn)默認(rèn)節(jié)點(diǎn)時(shí)，需要添加默認(rèn)子節(jié)點(diǎn)，且根據(jù)默認(rèn)節(jié)點(diǎn)的意義可以判斷出默認(rèn)節(jié)點(diǎn)應(yīng)作為最后一個(gè)條件分支節(jié)點(diǎn)去解釋，亦即在前序遍歷中默認(rèn)子節(jié)點(diǎn)應(yīng)被添加為產(chǎn)生條件分支的標(biāo)簽節(jié)點(diǎn)的最右邊的子節(jié)點(diǎn)。
[0080]自動(dòng)添加的默認(rèn)節(jié)點(diǎn)后沒有子節(jié)點(diǎn)，其語義表示采取腳本語言設(shè)計(jì)的默認(rèn)操作，在翻譯的時(shí)候，可以返回默認(rèn)消息DefaultRetMessage的實(shí)例。消息分發(fā)層在收到此消息后轉(zhuǎn)換成合適的消息，比如業(yè)務(wù)實(shí)例在收到一條呼叫消息后返回的消息是DefaultRetMessage。則消息分發(fā)層應(yīng)該返回一條讓呼叫網(wǎng)關(guān)自行處理后面呼叫的消息。
[0081]在翻譯邏輯輸出分支節(jié)點(diǎn)時(shí)，除了默認(rèn)節(jié)點(diǎn)外，每個(gè)分支節(jié)點(diǎn)要生成一個(gè)if作用域，而默認(rèn)節(jié)點(diǎn)應(yīng)生成一個(gè)else作用域。但如果只有默認(rèn)節(jié)點(diǎn)作為邏輯輸出節(jié)點(diǎn)，則在翻譯的時(shí)候不需要加上else作用域。這些作用域都包含在產(chǎn)生條件分支標(biāo)簽節(jié)點(diǎn)生成的函數(shù)作用域中。在每個(gè)作用域里要加上設(shè)置該分支邏輯中下一個(gè)處理函數(shù)的名稱的語句。
[0082]2.2.4等待消息標(biāo)簽節(jié)點(diǎn)的翻譯。這些節(jié)點(diǎn)在執(zhí)行完后需要等待外界的輸入消息，因此業(yè)務(wù)邏輯在執(zhí)行完該節(jié)點(diǎn)后應(yīng)該結(jié)束執(zhí)行，并等待直到新的消息輸入。因此，該節(jié)點(diǎn)應(yīng)該產(chǎn)生兩個(gè)函數(shù)，第一個(gè)函數(shù)里包含調(diào)用該類型節(jié)點(diǎn)的代碼，第二個(gè)函數(shù)包含等待消息的代碼,且第二個(gè)函數(shù)作為第一個(gè)函數(shù)的后繼,第二個(gè)函數(shù)可以稱為回調(diào)函數(shù)，以“Callback”作結(jié)尾。
[0083]該類型節(jié)點(diǎn)的子節(jié)點(diǎn)必定是消息分支節(jié)點(diǎn)，因而回調(diào)函數(shù)中的代碼將采用產(chǎn)生條件分支作用域，等同于條件分支作用域的翻譯方法。
[0084]2.2.5葉子標(biāo)簽節(jié)點(diǎn)的翻譯。對于沒有子節(jié)點(diǎn)的標(biāo)簽節(jié)點(diǎn)(包括在翻譯過程中添加的默認(rèn)節(jié)點(diǎn)default或otherwise),即葉子標(biāo)簽節(jié)點(diǎn)，除了 sub和goto外,其他的節(jié)點(diǎn)都表示在執(zhí)行完該節(jié)點(diǎn)代表的功能后，腳本邏輯結(jié)束了。因此，在該節(jié)點(diǎn)所生成的函數(shù)作用域中將下一個(gè)處理函數(shù)的名稱設(shè)置成空字符串，還需要將返回消息標(biāo)志成最后一條消息，表示業(yè)務(wù)邏輯已執(zhí)行完畢，供消息分發(fā)模塊維護(hù)業(yè)務(wù)實(shí)例的生命周期。
[0085]2.2.2.6翻譯規(guī)則。由于通用業(yè)務(wù)平臺中腳本要被翻譯成EJB程序，因此這里翻譯器將以翻譯成EJB程序作為描述基礎(chǔ)。
[0086]對于Home接口文件、Remote接口文件和部屬描述符文件，由于它們里面的內(nèi)容比較固定，與具體腳本的名稱及內(nèi)容沒有太大聯(lián)系，所以可以直接生成，而不用遍歷腳本文件。而對于Bean文件，其內(nèi)容與腳本文件有緊密聯(lián)系，因此只有在遍歷腳本文件后才能生成文件內(nèi)容，下面將介紹生成Bean文件內(nèi)容的翻譯規(guī)則。
[0087]2.2.7代碼生成的優(yōu)化。分析各種類型標(biāo)簽的翻譯規(guī)則可以發(fā)現(xiàn)，每種類型的標(biāo)簽在被翻譯的過程中都需要一些信息，比如同步且無邏輯輸出類型的構(gòu)件標(biāo)簽，只需要知道構(gòu)件接口函數(shù)的參數(shù)；異步類型構(gòu)件標(biāo)簽，還需要知道其下面都有哪些消息分支；而recvMessage標(biāo)簽,還需要知道recvMessage標(biāo)簽是否在incoming標(biāo)簽下。需要哪些信息對每種類型的標(biāo)簽是固定的，但這些信息在腳本中以何種語法格式進(jìn)行表達(dá)則可能會(huì)隨著腳本schema的變化而改變。為了減小語法格式對翻譯規(guī)則的影響，可以將代碼生成子任務(wù)劃分成兩個(gè)階段:翻譯信息的轉(zhuǎn)換和翻譯規(guī)則的實(shí)施。
[0088]翻譯信息的轉(zhuǎn)換:解析腳本生成的DOM樹結(jié)點(diǎn)，獲取對應(yīng)類型標(biāo)簽翻譯時(shí)所需要的信息，這個(gè)階段與腳本的具體語法格式有緊密的聯(lián)系；
翻譯規(guī)則的實(shí)施:根據(jù)前一階段獲取的信息實(shí)施具體的翻譯工作，該階段與具體語法格式?jīng)]有聯(lián)系。
[0089]兩個(gè)階段的劃分，可以帶來兩個(gè)好處:其一，如果腳本語言的語法格式在以后發(fā)生了變化，比如構(gòu)件接口函數(shù)參數(shù)賦值在腳本中采取構(gòu)件標(biāo)簽子節(jié)點(diǎn)的形式表達(dá)，則只需要更改第一階段中獲取函數(shù)參數(shù)賦值的方法即可，而不需要改動(dòng)具體的翻譯算法，減小了翻譯器的改動(dòng)量。其二，如果需要擴(kuò)展翻譯器實(shí)現(xiàn)對其他語言的翻譯，由于翻譯器受語言語法格式的影響較小，因而翻譯器的改動(dòng)量也就減小了。比如實(shí)現(xiàn)XTML語言的翻譯器的情況。XTML語言中的功能也是通過構(gòu)件的方式進(jìn)行提供，其構(gòu)件也完全可以劃分成本腳本語言中構(gòu)件的類型，因此XTML語言翻譯器完全可以采用構(gòu)件標(biāo)簽的翻譯規(guī)則。
[0090]三、ICSDL業(yè)務(wù)構(gòu)件設(shè)計(jì)。
[0091]業(yè)務(wù)能力構(gòu)件(以下簡稱構(gòu)件)是實(shí)現(xiàn)一定功能的代碼段，它是對網(wǎng)絡(luò)能力API的進(jìn)一步封裝。當(dāng)業(yè)務(wù)流程執(zhí)行到某個(gè)構(gòu)件時(shí)，構(gòu)件可以從外界獲取信息實(shí)現(xiàn)邏輯功能，并向外界返回?cái)?shù)據(jù)結(jié)果；此外，構(gòu)件在執(zhí)行完成后可能會(huì)產(chǎn)生多種結(jié)果分支，使邏輯流程出現(xiàn)分支。根據(jù)前面對構(gòu)件功能的描述，構(gòu)件的結(jié)構(gòu)如圖5所示。主要包括:
邏輯輸入模塊:每個(gè)構(gòu)件被調(diào)用在腳本中表現(xiàn)為一個(gè)標(biāo)簽節(jié)點(diǎn)，根據(jù)前面的描述業(yè)務(wù)邏輯描述語言采用樹狀結(jié)構(gòu)，因此每個(gè)業(yè)務(wù)構(gòu)件都會(huì)有一個(gè)邏輯輸入，表示邏輯已經(jīng)轉(zhuǎn)入該構(gòu)件的執(zhí)行。
[0092]邏輯輸出模塊:構(gòu)件在執(zhí)行完后業(yè)務(wù)邏輯的執(zhí)行將要轉(zhuǎn)到別的業(yè)務(wù)構(gòu)件，邏輯輸出指向了下一個(gè)將要執(zhí)行的構(gòu)件。一個(gè)構(gòu)件的邏輯輸出就是其邏輯執(zhí)行流程中的下一個(gè)構(gòu)件的邏輯輸入。有的構(gòu)件在執(zhí)行完后可能會(huì)有多個(gè)邏輯輸出，而有的構(gòu)件可能沒有邏輯輸出，即構(gòu)件執(zhí)行完后業(yè)務(wù)流程立即結(jié)束。邏輯輸出在腳本里表示成構(gòu)件節(jié)點(diǎn)的子節(jié)點(diǎn)。
[0093]數(shù)據(jù)輸入模塊:每個(gè)構(gòu)件在運(yùn)行的時(shí)候可能需要從外界獲取一些信息，外界信息可以是業(yè)務(wù)開發(fā)者在腳本里使用的常量，也可以是腳本中的自定義變量保存的業(yè)務(wù)實(shí)例中間數(shù)據(jù)。
[0094]數(shù)據(jù)輸出模塊:構(gòu)件在執(zhí)行完后可能需要產(chǎn)生一些數(shù)據(jù)，這些數(shù)據(jù)可以被以后的構(gòu)件所使用，構(gòu)件可以將這些數(shù)據(jù)賦給腳本中的自定義變量。
[0095]構(gòu)件功能實(shí)現(xiàn)模塊:這是構(gòu)件功能邏輯的實(shí)現(xiàn)所在。
[0096]腳本需要解釋器進(jìn)行解釋分析，構(gòu)件的動(dòng)態(tài)增加性會(huì)給腳本解釋器帶來一個(gè)問題:如果構(gòu)件的語法格式與構(gòu)件的具體含義關(guān)聯(lián)在一起，那么解釋器就需要識別出構(gòu)件的具體含義，然后進(jìn)行解釋。這樣，每增加一個(gè)構(gòu)件，就需要改動(dòng)一次解釋器。為了能夠在不需要改變腳本解釋器的情況下將新增的構(gòu)件添加到腳本中，就需要腳本為構(gòu)件在語法格式上定義標(biāo)準(zhǔn)的形式，構(gòu)件遵從這些形式融入到腳本中，解釋器只需要能正確解釋這些標(biāo)準(zhǔn)的形式就可以解釋所有的構(gòu)件了。這種關(guān)系類似于插座和插件的關(guān)系，腳本語言提供的標(biāo)準(zhǔn)接口就是插座，而構(gòu)件就是插件，構(gòu)件通過這些插座插入到腳本語言中，即便以后增加了新的插件，只要這些新的插件遵從已有的插座接口，這些插件仍舊可以通過插座插入到腳本中。不同的構(gòu)件往往會(huì)有不同的特質(zhì)，比如有些構(gòu)件可能會(huì)有輸出結(jié)果，有些構(gòu)件就沒有；有些構(gòu)件在完成功能后產(chǎn)生的結(jié)果只有成功和失敗，而有些構(gòu)件可能會(huì)有更多的輸出結(jié)果；有些構(gòu)件在執(zhí)行完后立即執(zhí)行其下面的構(gòu)件節(jié)點(diǎn)，而有些構(gòu)件在執(zhí)行完后可能需要等待外界的消息再執(zhí)行下面的構(gòu)件節(jié)點(diǎn)?？梢詫?gòu)件按這些特質(zhì)進(jìn)行歸納分類，每種類型的構(gòu)件具有固定的語法格式，為方便構(gòu)件標(biāo)簽的翻譯，本腳本語言中的構(gòu)件被劃分為以下幾種類型:
同步且無邏輯輸出類型構(gòu)件:這種構(gòu)件在執(zhí)行完后不需要等待外界輸入即可直接執(zhí)行下一個(gè)構(gòu)件，同時(shí)這種構(gòu)件不會(huì)產(chǎn)生輸出結(jié)果，如success、failure等,亦即這種構(gòu)件的節(jié)點(diǎn)不會(huì)有輸出結(jié)果子節(jié)點(diǎn)。比如CPL語言中原有的redirect和reject構(gòu)件就屬于這種類型，因?yàn)樗鼈兊暮竺娌荒芨庸?jié)點(diǎn)。
[0097]同步且有邏輯輸出類型構(gòu)件:這種構(gòu)件在執(zhí)行完后不需要等待外界輸入即可直接執(zhí)行下一個(gè)構(gòu)件，同時(shí)這種構(gòu)件會(huì)產(chǎn)生多個(gè)輸出結(jié)果，如success、failure等,亦即這種構(gòu)件的子節(jié)點(diǎn)必須是輸出結(jié)果子節(jié)點(diǎn)，否則該構(gòu)件的節(jié)點(diǎn)不能帶子節(jié)點(diǎn)。比如發(fā)送短信構(gòu)件，其輸出結(jié)果子節(jié)點(diǎn)可以是suCCeSS、failure。只有在輸出結(jié)果子節(jié)點(diǎn)下面才可以跟其他的構(gòu)件節(jié)點(diǎn)。
[0098]異步類型構(gòu)件:這種類型的構(gòu)件是指當(dāng)該構(gòu)件執(zhí)行完畢后，需要等待外界的輸入，根據(jù)外界的輸入繼續(xù)執(zhí)行后面的邏輯。這種構(gòu)件的節(jié)點(diǎn)包含消息子節(jié)點(diǎn)，如果在腳本中沒有指定任何輸出結(jié)果子節(jié)點(diǎn)，則會(huì)有一個(gè)默認(rèn)的default子節(jié)點(diǎn)作為輸出節(jié)點(diǎn)，并執(zhí)行默認(rèn)的操作。CPL中的proxy構(gòu)件就是這種類型的構(gòu)件，proxy在執(zhí)行完前轉(zhuǎn)呼叫的動(dòng)作后，等待前轉(zhuǎn)返回的消息。[0099]選擇類型構(gòu)件:這種類型構(gòu)件是名稱以“-switch”為結(jié)尾的節(jié)點(diǎn)表示的構(gòu)件，它表示將根據(jù)某些中間數(shù)據(jù)的值進(jìn)行匹配選擇，產(chǎn)生條件分支。其分支子節(jié)點(diǎn)在本文中被稱為選擇后繼節(jié)點(diǎn)。
[0100]與其他產(chǎn)生條件分支的節(jié)點(diǎn)不同的是，選擇后繼節(jié)點(diǎn)要執(zhí)行構(gòu)件動(dòng)作。以string-switch為例，string-switch表示對字符串進(jìn)行比較,而真正的比較動(dòng)作是其選擇后繼節(jié)點(diǎn)——string節(jié)點(diǎn)完成的，即具體是跟哪個(gè)參數(shù)比較，是精確匹配還是模糊匹配等都是由string節(jié)點(diǎn)完成的。因此，只有在遇到選擇后繼節(jié)點(diǎn)時(shí)才真正執(zhí)行構(gòu)件，然后根據(jù)構(gòu)件的邏輯輸出判斷邏輯是否該沿著對應(yīng)選擇后繼節(jié)點(diǎn)的分支走下去。這里可以規(guī)定當(dāng)選擇后繼節(jié)點(diǎn)代表的構(gòu)件的邏輯輸出是success時(shí)則執(zhí)行該分支，其他的任何邏輯輸出都表示邏輯不走該選擇后繼節(jié)點(diǎn)分支，但是這個(gè)邏輯輸出不在腳本中表達(dá)出來。選擇后繼節(jié)點(diǎn)下直接跟其他的構(gòu)件節(jié)點(diǎn)。選擇類 型構(gòu)件執(zhí)行完后也不需要等待外界的輸入，而是直接可以運(yùn)行后面的邏輯。
[0101]異步:在調(diào)用完這種構(gòu)件的API后，業(yè)務(wù)邏輯需要阻塞等待消息；
這里，消息是指業(yè)務(wù)邏輯實(shí)例從網(wǎng)關(guān)或web客戶端獲得的消息，允許業(yè)務(wù)開發(fā)者自己定義；Switch類型,是腳本語言中的條件判斷類型,例如cpl中原有的switch類型以及擴(kuò)展的〈message-switch〉, switch類型的標(biāo)簽沒有對應(yīng)的構(gòu)件,其屬性將作為switch后繼標(biāo)簽屬性的一部分；Swich 后繼，是例如 cpl 中的〈string〉、〈timeXaddressXpriority〉以及擴(kuò)展的〈message〉,它們除了包括自己的屬性外,還包括所在的switch標(biāo)簽的屬性。
[0102]通常情況下，腳本解釋器在執(zhí)行過程中需要一些信息，包括:構(gòu)件的類型；構(gòu)件輸出的數(shù)據(jù)結(jié)果；構(gòu)件實(shí)現(xiàn)中調(diào)用接口的參數(shù)類型。但腳本的schema無法提供這些信息，因此需要為構(gòu)件專門設(shè)計(jì)一個(gè)配置文件來指定這些信息，解釋器通過讀取構(gòu)件屬性文件中的信息即可獲得構(gòu)件的類型和調(diào)用參數(shù)。
[0103]這里主要說明系統(tǒng)核心部件即業(yè)務(wù)生成引擎的主要實(shí)現(xiàn)技術(shù)。業(yè)務(wù)生成技術(shù)的本質(zhì)就是某種形式的軟件復(fù)用技術(shù)?；跇?gòu)件的軟件復(fù)用是目前研究和應(yīng)用的重點(diǎn)。當(dāng)前基于接口的構(gòu)件組裝方法討論得較多，這種方法依靠構(gòu)件直接調(diào)用其它構(gòu)件的接口(或者通過所謂的連接子進(jìn)行調(diào)用)完成構(gòu)件的組裝。XPL這種應(yīng)用場合的構(gòu)件組裝與一般意義上的構(gòu)件組裝的區(qū)別在于:
1)業(yè)務(wù)開發(fā)者用XPL描述業(yè)務(wù)流程，并不直接進(jìn)行構(gòu)件組裝，構(gòu)件組裝需由系統(tǒng)完成，系統(tǒng)在構(gòu)件組裝的實(shí)現(xiàn)上需要統(tǒng)一的方法來自動(dòng)實(shí)現(xiàn)；
2)如果沿用基于接口的構(gòu)件組裝模式，那么如順序執(zhí)行、選擇等流程操作也必須實(shí)現(xiàn)在構(gòu)件的內(nèi)部，構(gòu)件會(huì)比較復(fù)雜，可以考慮將構(gòu)件中流程控制等共性的東西從構(gòu)件中剝離出去，系統(tǒng)在完成從XPL到可執(zhí)行代碼轉(zhuǎn)化的過程中再把這些共性的東西加入。
[0104]基于此，我們設(shè)計(jì)了一套基于上下文的構(gòu)件模型和針對該模型的腳本轉(zhuǎn)換一構(gòu)件粘合算法，該算法依照業(yè)務(wù)腳本產(chǎn)生“膠水代碼”，由“膠水代碼”來把構(gòu)件粘合起來，來控制構(gòu)件的執(zhí)行。
[0105]XPL的標(biāo)簽是需求的描述單元，對應(yīng)的能力實(shí)現(xiàn)單元是構(gòu)件。每個(gè)構(gòu)件都有特定的前置條件鍵P和后置條件鍵E (P和E也可為空)。構(gòu)件在運(yùn)行前先從上下文中載入前置條件，運(yùn)行結(jié)束后向上下文回寫后置條件。構(gòu)件是一個(gè)類，必須實(shí)現(xiàn)4個(gè)方法:
void 1adCon text O::=<從上下中加載P所對應(yīng)的信息>。[0106]boolean wiIIBeTrigered()::=<判斷該標(biāo)簽是否滿足運(yùn)行的條件，實(shí)現(xiàn)XPL的選擇操作>o
[0107]void process O::=〈實(shí)現(xiàn)該標(biāo)簽的主要業(yè)務(wù)邏輯〉。
[0108]void fillContext O::=〈將標(biāo)簽運(yùn)行結(jié)果寫入到上下文中E所對應(yīng)的地方〉。
[0109]采用腳本轉(zhuǎn)換——構(gòu)件粘合算法:
I)按定義2將XPL腳本文件拆成多棵業(yè)務(wù)片段構(gòu)成的樹tree，每棵tree對應(yīng)一個(gè)EJB商務(wù)方法，該方法將用來響應(yīng)Event事件。因?yàn)橐獫M足各個(gè)方法之間被網(wǎng)絡(luò)調(diào)用的次序，方法名定為從Flow的根到tree的根所經(jīng)過標(biāo)簽的名稱組成的字符串。
[0110]2)將〈subaction〉進(jìn)行和響應(yīng)標(biāo)簽同樣的處理，即〈subaction〉定義的腳本子樹也拆成業(yè)務(wù)邏輯片段，和步驟I所不同的是對應(yīng)的EJB方法被業(yè)務(wù)自己調(diào)用，因此對應(yīng)一個(gè)EJB私有方法，方法名為〈subaction〉屬性id的值。
[0111]3)對在步驟1)、2)中形成的所有業(yè)務(wù)片段樹進(jìn)行一種特殊的前序遍歷，在遍歷的過程中把標(biāo)簽對應(yīng)的構(gòu)件用“膠水代碼”粘合起來，形成業(yè)務(wù)片段對應(yīng)的EJB方法內(nèi)的代碼。如下述偽碼所示。
【權(quán)利要求】
1.面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)，其特征在于，包括業(yè)務(wù)平面、業(yè)務(wù)流程的腳本描述平面、可執(zhí)行代碼平面以及網(wǎng)頁服務(wù)接口平面；其中: 業(yè)務(wù)平面，用于確定當(dāng)前的業(yè)務(wù)需求是否適用于業(yè)務(wù)生成系統(tǒng)生成；所述業(yè)務(wù)生成系統(tǒng)具有良好的可擴(kuò)展性，通過增加XPL語言的標(biāo)簽和新開發(fā)對應(yīng)的構(gòu)件，擴(kuò)展業(yè)務(wù)生成系統(tǒng)的能力來滿足業(yè)務(wù)的需求； 業(yè)務(wù)流程的腳本描述平面，主要用于完成業(yè)務(wù)的開發(fā)工作；在業(yè)務(wù)平面的業(yè)務(wù)需求確定后，使用XPL語言描述業(yè)務(wù)邏輯； 可執(zhí)行代碼平面對應(yīng)于所述業(yè)務(wù)流程的腳本描述平面，用于從描述好的業(yè)務(wù)流程生成的可以部署運(yùn)行的代碼； 網(wǎng)頁服務(wù)接口平面，主要包括Parlay網(wǎng)頁服務(wù)接口和其他類型的網(wǎng)頁服務(wù)接口 ；所述網(wǎng)頁服務(wù)接口平面用于向業(yè)務(wù)生成系統(tǒng)提供開發(fā)業(yè)務(wù)所需的業(yè)務(wù)能力。
2.根據(jù)權(quán)利要求1所述面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)，其特征在于，所述增加XPL語言的標(biāo)簽和新開發(fā)對應(yīng)的構(gòu)件包括: switchType類型的標(biāo)簽，messageType類型的標(biāo)簽及各種消息標(biāo)簽；增加能力構(gòu)件標(biāo)簽的聲明，所述標(biāo)簽的內(nèi)容包括:構(gòu)件的名稱、參數(shù)的名稱和類型、是否有返回值、返回值的名稱、是否拋出異常、對構(gòu)件的調(diào)用是同步還是異步；以及增加與OAM模塊接口的標(biāo)簽。
3.根據(jù)權(quán)利要求2 所述面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)，其特征在于，所述增加XPL語言的標(biāo)簽和新開發(fā)對應(yīng)的構(gòu)件，進(jìn)一步包括: 語義擴(kuò)充的Incoming標(biāo)簽，中間變量標(biāo)簽variables,循環(huán)控制Goto標(biāo)簽,業(yè)務(wù)能力構(gòu)件標(biāo)簽擴(kuò)展schema以及支持多腳本交互的擴(kuò)展標(biāo)簽notify_message和pick_message標(biāo)簽。
4.根據(jù)權(quán)利要求1至3任一所述面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)，其特征在于，所述增加XPL語言的標(biāo)簽和新開發(fā)對應(yīng)的構(gòu)件，主要用于: 需要與用戶進(jìn)行交互的復(fù)雜業(yè)務(wù)邏輯； 業(yè)務(wù)的多入口，包括定位、發(fā)送短信、發(fā)送彩信以及GIS等數(shù)據(jù)業(yè)務(wù)的服務(wù)； 對數(shù)據(jù)庫的訪問；以及 業(yè)務(wù)自身主動(dòng)發(fā)起的業(yè)務(wù)。
5.根據(jù)權(quán)利要求1所述面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)，其特征在于，所述可執(zhí)行代碼平面通過使用業(yè)務(wù)生成技術(shù)，使XPL的每個(gè)標(biāo)簽在代碼實(shí)現(xiàn)上都對應(yīng)著一個(gè)構(gòu)件，業(yè)務(wù)生成系統(tǒng)事先準(zhǔn)備好XPL中所有用到的構(gòu)件并存放在構(gòu)件庫中；所述業(yè)務(wù)生成系統(tǒng)根據(jù)用XPL所描述的業(yè)務(wù)邏輯將業(yè)務(wù)流程中所涉及到的構(gòu)件組裝起來，并封裝成EJB，形成可以實(shí)際部署運(yùn)行的業(yè)務(wù)。
6.面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)方法，其特征在于，包括: A、采用業(yè)務(wù)平面確定當(dāng)前的業(yè)務(wù)需求是否適用于業(yè)務(wù)生成系統(tǒng)生成；所述業(yè)務(wù)生成系統(tǒng)具有良好的可擴(kuò)展性，通過增加XPL語言的標(biāo)簽和新開發(fā)對應(yīng)的構(gòu)件，擴(kuò)展業(yè)務(wù)生成系統(tǒng)的能力來滿足業(yè)務(wù)的需求； B、利用業(yè)務(wù)流程的腳本描述平面，完成業(yè)務(wù)的開發(fā)工作；在業(yè)務(wù)平面的業(yè)務(wù)需求確定后，使用XPL語言描述業(yè)務(wù)邏輯； C、然后利用對應(yīng)于所述業(yè)務(wù)流程的腳本描述平面的可執(zhí)行代碼平面，從描述好的業(yè)務(wù)流程生成的可以部署運(yùn)行的代碼； D、最后通過網(wǎng)頁服務(wù)接口平面向業(yè)務(wù)生成系統(tǒng)提供開發(fā)業(yè)務(wù)所需的業(yè)務(wù)能力；所述網(wǎng)頁服務(wù)接口平面，主要包括Par lay網(wǎng)頁服務(wù)接口和其他類型的網(wǎng)頁服務(wù)接口。
7.一種包括面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)的網(wǎng)絡(luò)增值服務(wù)平臺，包括CPL業(yè)務(wù)腳本、OAM模塊及協(xié)議網(wǎng)關(guān)層；其特征在于，其業(yè)務(wù)處理系統(tǒng)還包括業(yè)務(wù)翻譯器和消息分發(fā)系統(tǒng)；其中: 業(yè)務(wù)翻譯器，用于對擴(kuò)展CPL業(yè)務(wù)腳本進(jìn)行解析，得到符合EJB規(guī)范的java代碼，然后生成java文件,并得到文件包； 消息分發(fā)系統(tǒng)，用于接收Web客戶端提交的消息和協(xié)議網(wǎng)關(guān)層上報(bào)的消息，判斷并分發(fā)到業(yè)務(wù)層中對應(yīng)的業(yè)務(wù)實(shí)例；另外消息分發(fā)系統(tǒng)還接收來自業(yè)務(wù)實(shí)例發(fā)送的消息，判斷并轉(zhuǎn)發(fā)到協(xié)議網(wǎng)關(guān)模塊。
8.根據(jù)權(quán)利要求7所述的網(wǎng)絡(luò)增值服務(wù)平臺，其特征在于，所述業(yè)務(wù)翻譯器主要包括: CPL腳本管理模塊，用于對下層模塊屏蔽CPL腳本的物理位置，即無論CPL腳本是以物理文件形式還是以數(shù)據(jù)庫表項(xiàng)或者其它形式存在，此模塊都能夠分別對待，無差別地向下層模塊提供CPL腳本的內(nèi)容； 樹結(jié)構(gòu)生成模塊，用于根據(jù)上層模塊傳進(jìn)來的CPL腳本，生成腳本對應(yīng)的樹，以便下層模塊對其進(jìn)行解析、翻譯； CPL解析模塊，用于根據(jù)樹結(jié)構(gòu)生成模塊生成的樹結(jié)構(gòu)，對其進(jìn)行語義分析，并結(jié)合上下文，生成相應(yīng)的Java代碼； Java代碼生成模塊，用于根據(jù)CPL解析模塊解析的結(jié)果和相應(yīng)的數(shù)據(jù)結(jié)構(gòu)，進(jìn)行綜合、代碼寫入，最終生成可編譯的Java代碼。
9.根據(jù)權(quán)利要求7所述的網(wǎng)絡(luò)增值服務(wù)平臺，其特征在于，所述消息分發(fā)系統(tǒng)包括消息分發(fā)模塊，其進(jìn)一步包括消息發(fā)送子模塊、消息接收子模塊、業(yè)務(wù)管理子模塊和業(yè)務(wù)實(shí)例管理子模塊；其中: 消息發(fā)送子模塊和消息接收子模塊，用于根據(jù)消息分發(fā)系統(tǒng)接收到的消息的方向的不同，將處理協(xié)議網(wǎng)關(guān)模塊、Web客戶端的消息的模塊成為消息接收模塊，而把處理業(yè)務(wù)實(shí)例模塊的消息的模塊成為消息發(fā)送模塊；所述兩個(gè)子模塊完成的功能是實(shí)現(xiàn)接收到的外部消息與業(yè)務(wù)層內(nèi)部消息的相互映射，實(shí)現(xiàn)對外部消息的屏蔽； 業(yè)務(wù)管理子模塊，用于與OAM模塊進(jìn)行消息交互，實(shí)現(xiàn)與管理業(yè)務(wù)相關(guān)信息的功能，提高系統(tǒng)的可擴(kuò)展性； 業(yè)務(wù)實(shí)例管理子模塊，用于完成創(chuàng)建、保存、查找、刪除業(yè)務(wù)實(shí)例的功能。
10.根據(jù)權(quán)利要求7所述的網(wǎng)絡(luò)增值服務(wù)平臺，其特征在于，所述服務(wù)平臺中的面向融合網(wǎng)絡(luò)混合服務(wù)流程編制語言的開發(fā)系統(tǒng)進(jìn)一步包括業(yè)務(wù)能力構(gòu)件，其主要包含: 邏輯輸入模塊，每個(gè)構(gòu)件被調(diào)用在腳本中表現(xiàn)為一個(gè)標(biāo)簽節(jié)點(diǎn)，根據(jù)前面的描述業(yè)務(wù)邏輯描述語言采用樹狀結(jié)構(gòu)，因此每個(gè)業(yè)務(wù)構(gòu)件都會(huì)有一個(gè)邏輯輸入，表示邏輯已經(jīng)轉(zhuǎn)入該構(gòu)件的執(zhí)行； 邏輯輸出模塊，構(gòu)件在執(zhí)行完后業(yè)務(wù)邏輯的執(zhí)行將要轉(zhuǎn)到別的業(yè)務(wù)構(gòu)件，邏輯輸出指向了下一個(gè)將要執(zhí)行的構(gòu)件；數(shù)據(jù)輸入模塊，每個(gè)構(gòu)件在運(yùn)行的時(shí)候可能需要從外界獲取一些信息，外界信息為從業(yè)務(wù)開發(fā)者在腳本里使用的常量，或腳本中的自定義變量保存的業(yè)務(wù)實(shí)例中間數(shù)據(jù)； 數(shù)據(jù)輸出模塊，構(gòu)件在執(zhí)行完后可能需要產(chǎn)生一些數(shù)據(jù)，所述數(shù)據(jù)能夠被以后的構(gòu)件使用，構(gòu)件將所述的數(shù)據(jù)賦給腳本中的自定義變量； 構(gòu)件功能實(shí)現(xiàn)模塊，為構(gòu)件功能邏輯的實(shí)現(xiàn)所在。
【文檔編號】G06F9/44GK103942055SQ201410181352
【公開日】2014年7月23日 申請日期:2014年4月30日 優(yōu)先權(quán)日:2014年4月30日
【發(fā)明者】程渤, 孟祥武, 吳步丹, 陳俊亮 申請人:北京郵電大學(xué)