所選用的插件工具都集成到Eclipse中（如圖4）同時需要，安裝1．6版本以上的JDK。其中，Tomcat7．0為Web服務提供運行環境，它是Apache－Jarkartr的一個免費、開源的子項目，而Ant／Maven工具起到輔助作用。安裝所選定的插件時，往往需要先安裝其依賴性插件，此時可由Eclipse的Help菜單上的“Install New Software…”自動安裝完成。另外，可進一步結合免費的Google Eclipse插件開發云應用程序，并可上傳到Google App Engine（GAE）云應用平臺上運行。但GAE主要面向云計算應用，當前還不完善，用于云制造還存在許多局限。
如前所述，SOA4CM 繼承了SOA 和云計算的特性。SOA于1996年最先提出，已經形成Web服務和WS－BEPL系列的標準和協議，相對成熟，目前有Tuscany SCA和Synapse ESB等開源產品；而云計算于10年后的2006年才被正式提出來，雖然也有Apache Hadoop開源產品，但版本很低，還未成熟，只是云計算的初級實現，更沒有形成標準規范。云制造發展有賴于云計算等相關技術的發展，反過來又促進云計算技術的發展。圖4中的各層次與圖2的各層次有一定對應關系，通過CloudSim虛擬化和Tuscany SCA服務化，解決松耦合、可重用的、可互操作的服務開發問題，并通過Apache ODE解決不同業務問題的Web服務聯合起來執行的難題，以Synapse企業服務總線為中心實現不同服務之間的通信與整合。當業務需求變化時，流程中不符合要求的服務組件很容易被其他符合要求的服務組件替代，也可由已有服務通過SCA生成所需的新服務而不必從頭開發，同時這種修改或調整限定于最小的范圍，不會因某一層次變化引起其他層次的變化，從而實現業務服務的靈活裝配、業務流程的定制和業務服務的快速集成，而Drools和Esper進一步增強了業務的敏捷性，Hadoop為資源集約化管理和服務交付提供支持。
下面以多工序生產問題為例，從簡單到復雜展示集成開發環境（包括插件工具）的具體應用。
3 開發應用示例用
Eclipse開發Web應用程序（工程），生成一個部署描述設置文檔web．xml，而在安裝了云插件（如Hadoop插件或Google的GAE 插件）的Eclipse環境中開發云制造（云計算）應用程序，與Web應用程序開發類似，同樣需要web．xml，此外，還需要額外的設置文檔。如開發Hadoop應用程序，就需要額外的core－site．xml，hdfs－site．xml，mapred－site．xml設置文檔，又如開發Google的GAE應用程序，還需要額外的appengine－web．xml設置文檔，以便讓系統清楚如何部署和運行云應用程序。云制造以服務（“一切皆為服務”）的方式提供資源，并為這種服務方式提供按需即取手段，因此如何實現制造資源服務化（含虛擬化）和服務按需即取（包含服務發現、調度和部署等）就成為關鍵問題。如前所述，SOA 是SOA4CM 的技術基礎，Web服務是目前實現SOA／SOA4CM 最適宜的技術，因此SOA4CM 的服務開發可基于已有SOA 規范和Web服務技術進行，不同的是將所開發的服務放置于云端而形成云服務，然后通過云設置文檔（如appengine－web．xml等）來管理云服務。
如前所述，生產加工即服務（FaaS），如何按需選擇服務來組織生產是云制造面臨的一個重要問題。現用前述的云制造服務開發工具，以一個零件的簡單加工為例探討FaaS的應用。在這個加工流程中，該零件（J1）有O11，O12和O13三個工序，按工藝先后順序要求分別在機器1、機器2和機器3上加工2min，3min和5min，如圖5所示。
圖5 零件加工工序
要實現該流程加工，需要將3臺機器服務化，而要實現服務化又首先需要將加工設備（Machine）虛擬化。這里利用CloudSim創建各個機器的虛擬機，并以Java 類表示（如對Machine1 機器，建立Machine1Service．Java），此時只要在該Java類上手工添加“＠WebService”標注就可將其變成Web服務。更為方便的是，通過JAX－WS的創建，Web服務向導自動將其變為Web服務，包括可生成相應的Web服務程序和客戶端程序，以及發布和監控Web服務，如圖6所示。圖6所示的情景是已生成了Machine1和Machine2的Web服務，正在選項生成Machine3的Web服務中，選擇好后點擊“Finish”按鍵就會生成Java類對應的wsdl和配置文件，并可發布到Tomcat中，同時會生成調用服務的客戶端。這里生成的Web服務是為BPEL流程調用服務做準備。
通過Eclipse BPEL 設計器將經服務化后的Machine1，Machine2和Machine3（采用WSDL 定義服務，三者分別用Machine1Service．wsdl，Machine2Service．wsdl和Machine3Service．wsdl表示）按預定加工順序連接起來，形成所需的業務流程，如圖7所示。其中，receive（圖中為receiveInput）表示接收請求輸入，是整個BPEL流程的起點；Assign表示賦值，如AssignMachine1表示對Machine1賦值；Invoke表示調用服務，如InvokeMachine1表示調用Machine1服務；reply（圖中為replyOutput）表示整個BPEL流程終點，把響應結果返回給服務請求者。類似地，BPEL流程本身也可生成一個Web服務，然后部署到Apache ODE服務器，此時請求者可調用該流程來實現預定功能。
圖6 由Web服務想到創建Web服務
圖5給出的簡單加工例子旨在展示，只用到其中的CloudSim，Java EE 的JAX－WS 和ApacheODE等插件或工具。對于更為復雜的情形，例如圖5所示的零件加工完成后，還需要運到另一熱處理車間進行熱處理，或者需要用不同于Java的其他語言編程，或者集成歷史遺留應用系統，此時采用Tuscany SCA 就顯得更方便并具有優勢。圖8所示為用Tuscany SCA 將圖5所示的工序組合成一個稱為Machining服務的子流程，并封裝成Web服務方式，再與熱處理服務（Heattreating）結合。
圖7 BPEL表示的實例業務流程
圖8 用Tuscany SCA開發圖5所示的加工服務程序
圖5只是單個零件的加工情形，該流程以串行的方式調用3臺加工機器，而實際流程還可能有并行處理的機器和循環調用的機器。一個由4個工件（J1，J2，J3和J4）和6臺機器（M1，M2，…，M6）組成的稱為FT46的柔性作業問題，如表2所示，其中J1有下劃線的數據對應圖5所示的加工情形。
表2 FT46問題的時間表
對于表2所示的柔性作業加工調度問題，每個工件的每道工序可以由一臺或者多臺機器為其加工，因此每個工件可能有多條加工路徑。在相同的工序中，由于其所對應的可加工機器的加工性能不同，同一道工序在不同機器上的加工時間也不同，不同的加工路徑對應著不同的加工時間，需要引入智能技術來求解作業調度問題。使用Drools規則引擎，可以按先來先服務（First Come First Served，FCFS）或稱先入先出（First In First Out，FIFO）的規則進行調度，但是因為車間作業調度問題屬于NP－hard問題，基于規則的專家系統并不能保證系統全局優化，所以復雜車間作業調度問題往往采用遺傳算法和粒子群優化算法等智能優化算法求解。
目前，生產調度研究主要針對靜態生產環境中的調度優化，多數集中在以Job－Shop問題為代表的基于最小化完工時間的靜態車間調度問題上。靜態調度要求生產中的所有零件信息和車間狀態是明確的，一旦生產計劃確定，車間就按計劃生產，但加工的不確定性（如故障、延誤）使得這種既定生產作業難以實施，因此需要根據系統中工件的狀況不斷進行重新調度，即進行動態調度，此時可用Esper監控和管理服務或流程中的活動情況。但是因為云制造環境的高度動態性、分布性和自治性，而且不像傳統生產調度那樣以某一性能指標為目標，而是以包括完工時間、成本和可靠性等在內的QoS為目標來選擇和調度制造資源，所以云制造資源調度機制與傳統車間作業調度問題有很大不同，其復雜性更高。
在云計算產品中，雖然各個軟件供應商都有自己的資源分配與任務調度模式，但是并沒有形成統一的標準和規范，當前流行的云計算調度模型是Google于2004年提出的MapReduce，其模擬開源實現包括在Apache Hadoop項目中，Amazon，IBM，Facebook和Ｙahoo等許多著名IT公司都采用Hadoop構建自己系統。Hadoop MapReduce默認使用FIFO調度算法，它根據優先級高低和到達時間的先后選擇被執行的作業，但存在資源利用率不高等問題。FIFO這樣的作業調度算法已在傳統制造車間獲得了應用。雖然Hadoop還可提供公平調度算法（fair scheduler）和容量調度算法（capacityscheduler）以改善FIFO 的不足，但仍存在一定的缺陷，如未能很好地考慮不同作業需求差異和節點資源實際使用情況，資源利用率有待進一步提高，資源配置仍是云計算面臨的一大挑戰。資源配置（資源調度）無疑也是云制造面臨的一大挑戰和關鍵問題，但是因為包括MapReduce在內的云計算調度模型是針對云計算資源提出來的，所以需要根據云制造資源的特點，結合云計算調度算法和物聯網感知技術，研究適用云制造的作業調度策略和資源映射方式，尤其要關注那些可為制造資源動態配置（動態調度）提供新思路的云計算容錯機制和負載均衡等理念，這些內容將另文深入探討。需要說明的是，真正實現云制造將任重而道遠。
當使用SOA4MC 來開發實際企業應用程序時，除了考慮服務功能需求外，還需要考慮整個系統的性能問題、可用性、安全性、可靠性、容錯性和可擴展性等非功能性需求問題（即QoS問題）。采用ESB集成模式是滿足這些非功能性需求的有效手段，所選用的Synapse ESB 支持HTTP，SOAP，SMTP，JMS，FTP，POP3，SMTP，MTOM 等傳輸協議、許多Web服務規范（WS－＊）和QoS，如WS－Addressing，WS－ReliableMessaging，WS－Security 和WS－Policy等，幾乎覆蓋了全部的基礎特性。與圖7和圖9a所示的基于服務編制的流程集成模式將各個服務直接集成有所不同，圖9b（該圖省略了底層的制造資源及其虛擬化層）所示的ESB集成模式將企業所執行的業務活動、流程或規則視為服務，采用總線來管理和簡化應用之間的集成拓撲結構，ESB起連通性和服務中介的作用，同時具有服務注冊等功能，從而實現不同形式的協議請求（如SOAP，SMTP，JMS，FTP等）和不同形式的服務或程序（包括Web服務、流程服務和規則服務，以及遺留應用程序和數據庫等）的集成。
圖9 服務集成的兩種模式
4 結束語
本文在抽象分析了SOA、云計算和云制造的基礎上，提出SOA4MC，并以Eclipse為集成開發平臺，選擇CloudSim，Tuscany SCA／STP，ApacheODE，Apache Synapse，Drools，Esper，Hadoop等開源插件，搭建了面向SOA4MC的開發環境，并通過從簡單的串行實例到復雜的柔性加工實例，展示了不同應用場景需要用到不同插件的情形。
SOA4MC為集成開發環境提供了藍圖，而集成開發環境是實現SOA4CM 的工具和途徑，這種工具和途徑不是唯一的，這里采用廣泛使用的Web服務技術和常用開源軟件工具來實現。SOA4MC通過物聯網實現物理設備的智能接入，并通過虛擬化和服務化將計算資源延伸和拓展到制造資源，同時兼有SOA和云計算的特性來滿足云制造按需應用的要求：一方面按面向服務原則通過松耦合、可重用、可互操作的服務構建云制造應用；另一方面按云計算理念對制造資源進行集約化經營管理，以更高質量、更低成本的服務交付模式為用戶提供按需即取的服務。
在集成環境或應用程序的開發中，采用開源軟件不但節省了軟件費用并加快了開發進度，而且研究這些開源代碼有益于啟發研究思路和博采眾家之長。在具體應用中，并非一定要用到集成環境中的所有開發工具，也可能因應用程序的需求，還要加入其他插件工具，由于所搭建的集成開發環境具有開放性和可伸縮性，可根據應用需求和問題的復雜性按需選用或拓展。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：面向云制造服務架構及集成開發環境(下)
相關文章
