煤炭企業(yè)信息化平臺方案建議書

1、 467/467煤炭企業(yè)信息化平臺方案建議書目 錄 TOC o 1-3 u 第1部分平臺技術(shù)方案 平臺技術(shù)方案平臺技術(shù)發(fā)展趨勢概述在企業(yè)和組織信息化變革的大環(huán)境下，我們需要全新的思想，通過模塊化漸進式的改變，來重新定義計算資源的使用方式、服務(wù)的提供方式，以及社會化大生產(chǎn)的協(xié)作過程。云計算帶來了這種思想的落地機制，這種機制使我們可以組織資源以服務(wù)，組織技術(shù)以實現(xiàn)，組織流程以應(yīng)變。而且，云計算擴大了我們對服務(wù)的定義，并帶來了一個全新的計算資源管理思路，一種信息技術(shù)的系統(tǒng)工程理念和一次信息社會的工業(yè)化革命。信息技術(shù)正在使當(dāng)代世界發(fā)生重大變化，如何讓信息系統(tǒng)真正適應(yīng)企業(yè)的發(fā)展變化？如何降低信息系統(tǒng)使用

2、、升級、維護、實施和開發(fā)的復(fù)雜度？如何降低信息系統(tǒng)建設(shè)和運營的成本、提升其應(yīng)用的價值？云計算為以上關(guān)鍵問題的突破提供了廣闊的創(chuàng)新空間和平臺。IT架構(gòu)演化如圖下圖所示，在傳統(tǒng)的豎井式信息系統(tǒng)架構(gòu)中，通常只能事先根據(jù)對各業(yè)務(wù)應(yīng)用的容量預(yù)測，來規(guī)劃資源和能力的分配，難以實現(xiàn)靈活動態(tài)的能力保障來應(yīng)對快速多變的業(yè)務(wù)需求。從資源共享和隔離的粒度來看，傳統(tǒng)IT是一個資源完全不共享的架構(gòu)，用戶需要管理所有的物理資源到應(yīng)用的所有方面。而企業(yè)目前廣泛關(guān)注的IaaS是一個利用虛擬化技術(shù)，共享計算資源、存儲資源和網(wǎng)絡(luò)資源的架構(gòu)，用戶需要手工管理從操作系統(tǒng)往上的數(shù)據(jù)庫、中間件和應(yīng)用。以后發(fā)展的PaaS平臺，對于PaaS

3、資源共享和隔離主要分為兩個方向，一個是以O(shè)penshift為代表的，繼承了IaaS資源共享和隔離的思路，在操作系統(tǒng)層面再進行計算資源、存儲資源和網(wǎng)絡(luò)資源的細(xì)粒度的切分；另外一個方向是從中間件共享的角度，實現(xiàn)不同租戶間應(yīng)用程序運行環(huán)境的隔離以及運行時數(shù)據(jù)的隔離，用戶需要手工管理從中間件往上的應(yīng)用。再往后發(fā)展是基于云的SaaS，傳統(tǒng)的SaaS應(yīng)用主要采用元數(shù)據(jù)驅(qū)動的方式，強烈依賴于數(shù)據(jù)庫，所有租戶采用一個數(shù)據(jù)庫Schema，元數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)都存儲在數(shù)據(jù)庫中，在性能上廣泛采用數(shù)據(jù)緩存技術(shù)，主要代表為Salesforce，缺點主要是針對于某一個應(yīng)用領(lǐng)域，比如CRM，不能靈活地重用到其他領(lǐng)域。未來Saa

4、S應(yīng)用將基于云的架構(gòu)，能夠充分利用PaaS和IaaS多租用和自動彈性技術(shù)，以及 PaaS豐富的云服務(wù)，快速搭建基于云的SaaS，并且能夠?qū)崿F(xiàn)底層資源層面、操作系統(tǒng)層面、應(yīng)用服務(wù)器層面、數(shù)據(jù)層和應(yīng)用代碼粒度的共享。圖 企業(yè)和組織的IT架構(gòu)演化路線在云計算環(huán)境下，傳統(tǒng)的應(yīng)用IT架構(gòu)將發(fā)生重大變化，但SOA繼承了下來，并得到了發(fā)展， SOA與云計算結(jié)合將是未來的企業(yè)應(yīng)用IT架構(gòu)方向。如下圖所示，云計算在垂直方向上將應(yīng)用和物理硬件進行了解耦，而SOA在水平方向上實現(xiàn)了應(yīng)用之間的解耦。垂直方向上的解耦意味著云可以在水平方向上進行伸縮(通過增加/減少工作節(jié)點)，另外從應(yīng)用的角度，SOA倡導(dǎo)的無狀態(tài)化設(shè)計原

5、則也能更好地支撐云的水平擴展。水平方向上的解耦意味著應(yīng)用可以在垂直方向上進行伸縮(應(yīng)用的不同組件垂直分布到不同的中間件工作節(jié)點上)，最終也能夠?qū)崿F(xiàn)應(yīng)用從一朵云自動遷移到另外一朵云上 (如：私有云遷移到公有云或混合云)。圖 企業(yè)和組織的IT架構(gòu)趨勢基礎(chǔ)設(shè)施管理技術(shù)發(fā)展趨勢以前以“服務(wù)器+網(wǎng)絡(luò)+存儲”構(gòu)成的IT基礎(chǔ)設(shè)施已經(jīng)形成一個很穩(wěn)定的架構(gòu)，但是這種 IT基礎(chǔ)設(shè)施是靜態(tài)和僵硬的。傳統(tǒng)數(shù)據(jù)中心基礎(chǔ)架構(gòu)層面的設(shè)備之間通過標(biāo)準(zhǔn)化連接和協(xié)議互通，保證了計算、存儲和網(wǎng)絡(luò)設(shè)備的管理系統(tǒng)之間相互分離和獨立，從而使得不同的運維團隊可以按照自身業(yè)務(wù)發(fā)展與架構(gòu)演進的趨勢不斷完善和深化各自的管理規(guī)程，滿足數(shù)據(jù)中心業(yè)務(wù)

6、不斷發(fā)展的要求。而今天的需求則是一種全新的動態(tài)IT基礎(chǔ)設(shè)施，即IT基礎(chǔ)設(shè)施要能夠“按需生成、按需擴展、按需縮減、按需計費、自動生成，即時交付”。在云計算環(huán)境下，各自獨立和分離的運行模式不能支持云服務(wù)的展開，新的IT運行模式對傳統(tǒng)的管理架構(gòu)提出了挑戰(zhàn)。虛擬化 傳統(tǒng)數(shù)據(jù)中心中每個物理服務(wù)器上只是單個或幾個應(yīng)用的固定運行，業(yè)務(wù)基本是與主機的綁定運行方式，對主機的管理，某種意義上也就是對業(yè)務(wù)的管理。而在云計算環(huán)境下服務(wù)器大量采用虛擬化技術(shù)，每一個物理網(wǎng)絡(luò)端口下都會分布多達(dá)數(shù)十個虛擬機，物理主機上運行著多個不同的操作系統(tǒng)和應(yīng)用，網(wǎng)絡(luò)中應(yīng)用密集度極大增長，對網(wǎng)絡(luò)的性能、規(guī)格和可靠性都提出了更高要求，而虛擬

7、機網(wǎng)絡(luò)屬性的可管理性更是面臨巨大挑戰(zhàn)。動態(tài)性傳統(tǒng)數(shù)據(jù)中心的業(yè)務(wù)針對物理主機展開，而物理服務(wù)器一般固定連接在某個網(wǎng)絡(luò)端口上，并且業(yè)務(wù)屬性單一，無論是網(wǎng)絡(luò)策略、安全控制都比較固定。只要主機與網(wǎng)絡(luò)運維界面清晰、系統(tǒng)歸屬明確，業(yè)務(wù)就容易展開，并能平穩(wěn)運行。但是云計算環(huán)境中部署著高密度的虛擬機，在虛擬化環(huán)境下，基于服務(wù)變更、容災(zāi)、分布式計算等業(yè)務(wù)運行要求使得虛擬機動態(tài)遷移成為必備屬性。如果網(wǎng)絡(luò)無法感知這種動態(tài)性計算方式，持續(xù)的運行必將造成業(yè)務(wù)的紊亂、運維的不可控，這就要求管理系統(tǒng)能夠具備動態(tài)計算的感知能力。關(guān)聯(lián)性當(dāng)前的網(wǎng)絡(luò)與計算之間以一種松耦合方式運行，網(wǎng)管與主機管理系統(tǒng)之間基本上沒有信息關(guān)聯(lián)交互。而虛

8、擬機的動態(tài)計算特性，將使得當(dāng)前的網(wǎng)絡(luò)管理系統(tǒng)無法對虛擬機進行定位，網(wǎng)絡(luò)對業(yè)務(wù)的安全、控制、配置、監(jiān)管也就無法關(guān)聯(lián)到虛擬機，也就無法實現(xiàn)云計算下的靈活部署和擴展性。另外在云計算環(huán)境下，應(yīng)用是根據(jù)租戶的訂購請求，動態(tài)地部署到各個虛擬機中的，再加上應(yīng)用程序與組件是多對多的依賴關(guān)系，一個應(yīng)用程序出了故障，很難快速地準(zhǔn)確定位是哪一個組件出現(xiàn)了問題，在哪一臺虛擬機上和哪臺物理機上，因此問題故障的定位是云計算環(huán)境下數(shù)據(jù)中心管理的又一大挑戰(zhàn)。這里面涉及租戶到應(yīng)用的關(guān)聯(lián)，組件和應(yīng)用的關(guān)聯(lián)，應(yīng)用到虛擬機的關(guān)聯(lián)，虛擬機到物理機的關(guān)聯(lián)等信息的動態(tài)維護。自動化在非虛擬化環(huán)境中，業(yè)務(wù)部署后一般都具有相對的固定性，即主機位

9、置、網(wǎng)絡(luò)接入比較確定，運行維護的目標(biāo)與物理機、物理端口一致，主機系統(tǒng)、網(wǎng)管系統(tǒng)分別部署，調(diào)試對接相對比較容易。但在大規(guī)模云數(shù)據(jù)中心，基于傳統(tǒng)的分離調(diào)試無法有效支持云服務(wù)的業(yè)務(wù)模式，這就要求整個服務(wù)的供應(yīng)能夠簡單提交，且不同系統(tǒng)(基礎(chǔ)的計算、網(wǎng)絡(luò)，上層的主機、網(wǎng)絡(luò)管理系統(tǒng))之間能夠交換服務(wù)信息，并基于一致的業(yè)務(wù)要求完成所有部件的自動化部署與運行。多租用在云計算環(huán)境下，計算、存儲和網(wǎng)絡(luò)資源被匯集成資源池，然后將不同的物理和虛擬資源動態(tài)地分配或再分配給多個租戶使用。多租用的目的是為了服務(wù)多租戶而實現(xiàn)計算和數(shù)據(jù)隔離的技術(shù)。如何最大限度地讓各租戶共享資源，降低運營成本，同時保證多個租戶的計算和數(shù)據(jù)相互隔

10、離是云計算環(huán)境下數(shù)據(jù)中心管理上的又一大挑戰(zhàn)。為了支持云計算環(huán)境下的虛擬化、動態(tài)化、關(guān)聯(lián)性、自動化和多租用服務(wù)要求，整個云計算系統(tǒng)將需要有一個統(tǒng)一的操作運行管理平臺，可稱之為云管理平臺，能夠?qū)υ品?wù)進行端到端自動化部署，同時快速響應(yīng)資源調(diào)度與業(yè)務(wù)變更的服務(wù)需求。云管理平臺能夠屏蔽云服務(wù)供應(yīng)層面對底層不同架構(gòu)的差異，使得用戶或業(yè)務(wù)運營部門聚焦在服務(wù)層面，不必關(guān)注底層資源(計算、網(wǎng)絡(luò)、存儲)本身的技術(shù)屬性。軟件架構(gòu)的發(fā)展趨勢1996年是HTML發(fā)展的一個里程碑，JavaScript和層疊樣式表（CSS）相繼誕生，W3C制定的 HTML3.2規(guī)范出爐。此時的Web UI可以與用戶的操作進行交互，根據(jù)用

11、戶的行為方便地修改UI元素和調(diào)整樣式，從而實現(xiàn)動態(tài)的DHTML頁面，此時的內(nèi)容還都是所謂的靜態(tài)頁面，無法根據(jù)不同的外部條件展示不同的內(nèi)容。隨后，CGI、ASP、JSP和PHP等服務(wù)器端腳本技術(shù)相繼涌現(xiàn)，真正的動態(tài)頁面出現(xiàn)了。服務(wù)器端代碼分析用戶提交的請求參數(shù)，從數(shù)據(jù)庫服務(wù)器獲取相應(yīng)的業(yè)務(wù)數(shù)據(jù)，動態(tài)地將網(wǎng)頁和數(shù)據(jù)組合拼裝出網(wǎng)頁的HTML文本推送到客戶端瀏覽器。此時的服務(wù)器端頁面不再是一個單純的UI模型，而是一個服務(wù)器端腳本引擎來處理生成客戶端UI模型的模板，其中包括HTML片段、腳本塊和標(biāo)簽等元素，比如Struts、Tapestry和WebWork等基于Java EE技術(shù)的Web框架就是此類技術(shù)

12、的集大成者。隨著Web開發(fā)技術(shù)的進一步發(fā)展，又出現(xiàn)了服務(wù)器端UI 組件技術(shù)，例如ASP.NET中的服務(wù)器端UI組件和JSP中的JSF組件。其使用服務(wù)器端腳本技術(shù)，封裝部分HTML、JavaScript和CSS片段構(gòu)建一個完整的UI組件模型，在運行期間解釋并與數(shù)據(jù)進行整合，最終輸出為實際的HTML代碼(資料來源：百度百科)。這就是目前企業(yè)和組織的UI層技術(shù)現(xiàn)狀，存在的問題是UI的技術(shù)百花齊放。如下圖所示是目前企業(yè)和組織的軟件架構(gòu)現(xiàn)狀，在中間件這一層存在的主要問題是各種中間件都嚴(yán)重依賴于應(yīng)用服務(wù)器，并且在企業(yè)應(yīng)用中應(yīng)用服務(wù)器不能很好地水平擴展，關(guān)鍵在于應(yīng)用的狀態(tài)化。另外現(xiàn)有的應(yīng)用性能強烈依賴數(shù)據(jù)庫

13、的性能，比如Oracle RAC。圖 企業(yè)和組織的軟件架構(gòu)現(xiàn)狀以上是軟件架構(gòu)的現(xiàn)狀，但是技術(shù)總是在不斷演進。隨后的HTML5是用于取代1999年所制定的HTML4.01和XHTML1.0標(biāo)準(zhǔn)的，現(xiàn)在仍處于發(fā)展階段，但大部分瀏覽器已經(jīng)支持某些HTML5技術(shù)。HTML5強化了Web網(wǎng)頁的表現(xiàn)性能，并且追加了本地數(shù)據(jù)庫等Web應(yīng)用的功能，提供更多能有效增強網(wǎng)絡(luò)應(yīng)用的標(biāo)準(zhǔn)集，與HTML5類似的廠商技術(shù)如Adobe Flash、Microsoft Silverlight以及JavaFX技術(shù)。另外基于JavaScript的UI技術(shù)的出現(xiàn)，將Web UI的控制權(quán)從界面設(shè)計人員遞交給了程序員，即可以直接在We

14、b的前端使用JavaScript腳本來描述一個UI組件模型，然后在運行時，由瀏覽器的腳本解釋器調(diào)用核心的UI技術(shù)框架來將其轉(zhuǎn)換成HTML的UI界面。此類UI技術(shù)框架跟服務(wù)器端UI技術(shù)的思路一致，只是在客戶端瀏覽器中封裝了一套UI模型。這樣界面設(shè)計不需要服務(wù)器端的支持，在開發(fā)期間能更好地展示和測試界面效果。同時由于UI界面的構(gòu)建和控制都在客戶端，只需要和服務(wù)器端傳遞請求參數(shù)和數(shù)據(jù)，這樣就能比服務(wù)器端UI技術(shù)大大降低服務(wù)器端的壓力和網(wǎng)絡(luò)數(shù)據(jù)的傳遞量。這類基于JavaScript的UI技術(shù)目前有模塊化框架的代表oz.js， MVC框架的代表backbone.js、AngularJS和Ember.js

15、，標(biāo)準(zhǔn)化框架的代表Jquery.js，UI框架的代表underscore.js。另外以前的IT是以PC端為中心進行UI設(shè)計的，應(yīng)用都是以功能為中心。在云計算環(huán)境中，服務(wù)能力都通過網(wǎng)絡(luò)來提供，可將服務(wù)擴展到不同類型的客戶端平臺，如手機、PAD等。這種端的變化，使傳統(tǒng)IT轉(zhuǎn)變?yōu)橐砸苿訛橹行膩碓O(shè)計UI，同時應(yīng)用變?yōu)橐杂脩魹橹行?。這就要求企業(yè)應(yīng)用的UI層越來越需要朝著HTML5、JavaScript和CSS3的方向演變和發(fā)展，也就是說UI層對于傳統(tǒng)的應(yīng)用服務(wù)器端來說將變得越來越輕量化。另外由于UI的輕量化將導(dǎo)致傳統(tǒng)的應(yīng)用服務(wù)器中的JSP容器等逐漸變得不再需要了，更不用說EJB容器早就被大部分企業(yè)拋棄，

16、因此未來的應(yīng)用服務(wù)器有退化成Web服務(wù)器的趨勢。以前應(yīng)用服務(wù)器提供的事務(wù)、日志、緩存、持久化、JMX和集群等功能將會下沉到OSGI等模塊化框架中去，從而實現(xiàn)中間件服務(wù)器的輕量化。另外從企業(yè)業(yè)務(wù)本質(zhì)上來說，大部分企業(yè)業(yè)務(wù)都是有狀態(tài)的，那么這些狀態(tài)將保存到哪里呢？在云計算環(huán)境下這些狀態(tài)將存放在內(nèi)存數(shù)據(jù)網(wǎng)格中，內(nèi)存數(shù)據(jù)網(wǎng)格除了要承擔(dān)分布式數(shù)據(jù)緩存和狀態(tài)復(fù)制等功能外，還將融合傳統(tǒng)的數(shù)據(jù)持久化（ORM）和類SQL查詢以及并行計算的功能。內(nèi)存數(shù)據(jù)網(wǎng)格通過數(shù)據(jù)緩存將大大緩解現(xiàn)有企業(yè)應(yīng)用讀數(shù)據(jù)庫數(shù)據(jù)的性能問題，從而使得應(yīng)用性能將不再強烈依賴數(shù)據(jù)庫的性能，最終實現(xiàn)數(shù)據(jù)庫服務(wù)器的輕量化，為數(shù)據(jù)庫在云上的應(yīng)用鋪平道

17、路。企業(yè)與組織的軟件架構(gòu)趨勢如下圖所示。圖 企業(yè)與組織的軟件架構(gòu)趨勢總體技術(shù)平臺方案產(chǎn)品需求分析根據(jù)技術(shù)規(guī)范中的采購內(nèi)容，本次產(chǎn)品需求如下Java 開發(fā)平臺產(chǎn)品 企業(yè)級流程平臺企業(yè)級移動開發(fā)框架定制化開發(fā)其中，Java 開發(fā)平臺產(chǎn)品即業(yè)界的“綜合開發(fā)平臺產(chǎn)品”，包括企業(yè)級的統(tǒng)一應(yīng)用開發(fā)框架（統(tǒng)一應(yīng)用平臺）；企業(yè)級流程平臺即業(yè)界的面相企業(yè)的大型綜合“業(yè)務(wù)流程管理（BPM）”平臺產(chǎn)品；企業(yè)期移動開發(fā)框架，針對廣核工程公司的基本現(xiàn)狀，需要“面向企業(yè)”的綜合移動開發(fā)平臺產(chǎn)品；定制化開發(fā)是對“企業(yè)應(yīng)用開發(fā)框架”的適應(yīng)性改造。iUAP平臺的開發(fā)平臺，集成平臺中的BPM產(chǎn)品，移動平臺能否覆蓋采購需求，產(chǎn)品方

18、案如下：產(chǎn)品方案iUAP開發(fā)平臺業(yè)務(wù)流程管理（BPM）平臺企業(yè)移動平臺下面3.3到3.5章節(jié)按照產(chǎn)品方案中的產(chǎn)品體系分別描述具體技術(shù)方案?？傮w技術(shù)能力支持業(yè)界主流標(biāo)準(zhǔn)規(guī)范支持SOA、SDO、SCA規(guī)范SOA-面向服務(wù)的架構(gòu)，可以根據(jù)需求通過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用組件進行分布式部署、組合和使用。SOA是一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。SOA將能夠幫助軟件工程師們站在一個新的高度理解企業(yè)級架構(gòu)中的各種組件的開發(fā)、部署形式，它將幫助企業(yè)系統(tǒng)架構(gòu)者以更迅速、更可靠、更具重用性架構(gòu)整個業(yè)務(wù)系統(tǒng)。較之以往，以SOA架構(gòu)的系統(tǒng)能夠更加從容

19、地面對業(yè)務(wù)的急劇變化。SCA（Service Component Architecture，SCA）是實現(xiàn)SOA的服務(wù)組件模型。這是一種全新的、跟語言無關(guān)的編程模型，它提供了一種統(tǒng)一的調(diào)用方式，從而使得客戶可以把不同的組件類型，比如POJO, EJB, 流程組件，人工交互組件等都可以通過一種標(biāo)準(zhǔn)的接口來封裝和調(diào)用。結(jié)合SDO的數(shù)據(jù)模型，SCA服務(wù)組件的編程模型就可以簡化編程，提高應(yīng)用的靈活性。這就是面向服務(wù)組件的架構(gòu)?；诮M件編程是軟件業(yè)簡化編程和提高效率和質(zhì)量的一個重要方法，但是對于不同語言有不同的組件模型，需要不同的調(diào)用方式。為了給這些不同的接口提供一個統(tǒng)一的調(diào)用方式，面向服務(wù)的組件模型（

20、Service Oritented Architecture, SCA）應(yīng)用而生。SCA使用戶在構(gòu)建企業(yè)應(yīng)用時有一個不再直接面對具體的技術(shù)細(xì)節(jié)的層次，而是通過服務(wù)組件的方式來構(gòu)建應(yīng)用。這種方式也使得客戶的企業(yè)應(yīng)用具有良好的分層架構(gòu)，能夠很好的分離應(yīng)用的業(yè)務(wù)邏輯和IT邏輯，不但易于應(yīng)用的構(gòu)建，也易于應(yīng)用的更改和部署。iUAP 支持基于Java技術(shù)實現(xiàn)對SOA規(guī)范的支持，采用組件化的編程規(guī)范和模式，使得iUAP可開發(fā)出具有架構(gòu)優(yōu)化、高靈活性、高擴展性的企業(yè)應(yīng)用。運用iUAP對SOA規(guī)范（SCA，SDO）的支持，可以開發(fā)出高可用、架構(gòu)優(yōu)化的大型企業(yè)應(yīng)用，NC大型ERP產(chǎn)品就是iUAP開發(fā)平臺基于SO

21、A架構(gòu)實現(xiàn)的企業(yè)應(yīng)用的典型范例。支持JAVA EE規(guī)范JAVA EE規(guī)范總結(jié)起來包括事務(wù)管理、資源，命名和注入、應(yīng)用程序編程接口，互用性、應(yīng)用程序組裝與部署等。事務(wù)管理：開發(fā)平臺提供基礎(chǔ)事務(wù)和擴展事務(wù)的支持，擴展事務(wù)采用接口形式定義。資源，命名和注入：開發(fā)平臺引用了資源管理器連接工廠的設(shè)計理念，引用了JNDI命名上下文環(huán)境，EJB的支持以及web服務(wù)的引用。應(yīng)用程序編程接口：開發(fā)平臺支持Servlet3.0標(biāo)準(zhǔn)規(guī)范，JMS標(biāo)準(zhǔn)，JSP標(biāo)準(zhǔn)以及企業(yè)級JavaBeans標(biāo)準(zhǔn)?；ビ眯裕簽楸Ｕ袭a(chǎn)品的互用性，開發(fā)平臺支持但不限于Internet和Web協(xié)議、Java技術(shù)協(xié)議、Http協(xié)議等。應(yīng)用程序組裝

22、與部署：開發(fā)平臺可與其他web中間件聯(lián)合管理應(yīng)用程序的生命周期、應(yīng)用程序的組裝、類庫的支持以及類加載標(biāo)準(zhǔn)等。SOA編程模型SCA模型服務(wù)組件模型（SCA）包括服務(wù)組件，模塊，共享庫，導(dǎo)入和導(dǎo)出。服務(wù)組件服務(wù)組件即業(yè)務(wù)邏輯。使用服務(wù)組件的客戶端可以選擇使用WSDL接口或Java接口。服務(wù)組件提供給別的服務(wù)調(diào)用的入口為Interface，而服務(wù)組件調(diào)用出口為Reference。服務(wù)組件的接口模型請參考服務(wù)模塊（Module）服務(wù)模塊由一個或多個具有內(nèi)在業(yè)務(wù)聯(lián)系的服務(wù)組件構(gòu)成。模塊可以獨立部署，只要保持模塊接口不變，就可通過重新部署新的模塊而替換原有的業(yè)務(wù)邏輯，而不影響應(yīng)用的其它部分。導(dǎo)入（Impo

23、rt）和導(dǎo)出（Export）實際的應(yīng)用通常需要多個模塊才能滿足要求，而且這些模塊之間又往往存在相互調(diào)用的關(guān)系。在模塊中引入了兩個特殊的端點，一個是導(dǎo)入（Import），使得模塊中的服務(wù)組件可以調(diào)用模塊外部的服務(wù)。另一個是導(dǎo)出（Export），使得模塊外部的應(yīng)用可以調(diào)用模塊中的服務(wù)組件。由于涉及到模塊內(nèi)外的調(diào)用，因此需要指定專門的綁定信息。導(dǎo)入端點提供了四種綁定方式，包括：JMS綁定，Web Service綁定，SCA綁定和無狀態(tài)會話BEAN的綁定。導(dǎo)出端點提供了三種綁定方式，包括：JMS綁定，Web Service綁定和SCA綁定。對于SCA模塊之間的調(diào)用，把綁定方式設(shè)置為SCA綁定，對于非S

24、CA模塊與SCA模塊之間的調(diào)用選擇其它綁定方式。共享庫（Library）如果有一些資源可以在不同模塊之間共享，可以選擇創(chuàng)建一份可以在不同模塊之間進行共享的資源，共享庫存放這些共享資源。共享庫通過與模塊類似的方式創(chuàng)建，共享庫包含的內(nèi)容只有：數(shù)據(jù)定義，接口定義，數(shù)據(jù)映射和關(guān)系。共享庫不包含服務(wù)組件，不包含業(yè)務(wù)邏輯。當(dāng)一個模塊需要用到共享庫中的資源的時候，使模塊依賴于共享庫。一個共享庫會對應(yīng)一個JAR包。在部署的時候，模塊所對應(yīng)的J2EE企業(yè)應(yīng)用會會自動包含所依賴的共享庫JAR包。調(diào)用方式SCA采用異步調(diào)用方式。有三種方式的異步調(diào)用，它們分別是：1 單向調(diào)用方式。2 延遲響應(yīng)方式。3 請求回調(diào)方式。

25、單向調(diào)用單向調(diào)用方式是最為簡單的異步調(diào)用方式，客戶端發(fā)出請求之后就不再關(guān)心服務(wù)端的情況，包括是否執(zhí)行成功，返回值是什么等等。單向調(diào)用方式是一種不管調(diào)用結(jié)果的方式。延遲響應(yīng)方式延遲響應(yīng)方式是客戶端在發(fā)出調(diào)用請求之后繼續(xù)執(zhí)行，經(jīng)過一段時間之后，再調(diào)用相應(yīng)的方法去檢索返回結(jié)果，并通過參數(shù)指定如何根據(jù)調(diào)用的結(jié)果而執(zhí)行進一步動作。在第一次發(fā)出調(diào)用請求的時候，服務(wù)端需要返回一個稱為票據(jù)（Ticket）的對象，這個對象會作為第二次發(fā)出檢索結(jié)果請求時的一個參數(shù)。請求回調(diào)請求回調(diào)方式的響應(yīng)是由服務(wù)端通過回調(diào)方式來觸發(fā)的。我們可以用圖6來表示請求調(diào)用方式：SCA客戶端調(diào)用方式SCA的客戶端編程模型有兩種方式：1

26、靜態(tài)調(diào)用方式2 動態(tài)調(diào)用方式靜態(tài)調(diào)用方式靜態(tài)調(diào)用方式是示例如下：動態(tài)調(diào)用方式動態(tài)調(diào)用方式與靜態(tài)調(diào)用方式相對，示例如下：當(dāng)提供的接口類型是WSDL類型的，那么客戶端的調(diào)用方式只能是動態(tài)調(diào)用方式。如果提供的接口類型時Java類型的，那么客戶端的調(diào)用方式可以是動態(tài)調(diào)用方式，也可以是靜態(tài)調(diào)用方式。組件開發(fā)標(biāo)準(zhǔn)組件設(shè)計業(yè)務(wù)組件和開發(fā)組件設(shè)計：圖：業(yè)務(wù)組件說明：業(yè)務(wù)組件是產(chǎn)品的組裝單元。業(yè)務(wù)目的：組件需要實現(xiàn)的業(yè)務(wù)功能；業(yè)務(wù)服務(wù)：組件提供的服務(wù)；業(yè)務(wù)活動：一個業(yè)務(wù)活動可以包含一組操作，每個業(yè)務(wù)活動的執(zhí)行結(jié)果使業(yè)務(wù)對象具有業(yè)務(wù)上的一致性狀態(tài)，符合一致性狀態(tài)要求的數(shù)據(jù)是可以訪問的；業(yè)務(wù)活動通常完成一項業(yè)務(wù)職責(zé)

27、。業(yè)務(wù)數(shù)據(jù)：組件內(nèi)業(yè)務(wù)處理涉及的數(shù)據(jù)對象；業(yè)務(wù)策略：（一組）業(yè)務(wù)活動的Selector，不同的場景可能使用不同的業(yè)務(wù)策略；組件治理：根據(jù)組件自身的治理要求，獨立對組件的內(nèi)容進行約束及管理；業(yè)務(wù)組件的分類：基礎(chǔ)組件基礎(chǔ)數(shù)據(jù)、基礎(chǔ)規(guī)則業(yè)務(wù)管理組件業(yè)務(wù)執(zhí)行、業(yè)務(wù)檢查、監(jiān)控業(yè)務(wù)分析組件業(yè)務(wù)分析決策注：公共技術(shù)組件不屬于業(yè)務(wù)組件，可與業(yè)務(wù)組件并列。圖：服務(wù)組件與開發(fā)組件業(yè)務(wù)組件與開發(fā)組件：每個業(yè)務(wù)組件可以包含一組開發(fā)組件。開發(fā)組件包括：UI組件業(yè)務(wù)服務(wù)組件業(yè)務(wù)活動組件業(yè)務(wù)實體組件引用組件其它組件業(yè)務(wù)組件、業(yè)務(wù)單元與業(yè)務(wù)活動的關(guān)系：業(yè)務(wù)單元：一個在業(yè)務(wù)組件內(nèi)部具有更緊密關(guān)系的業(yè)務(wù)活動的集合。1）一個業(yè)務(wù)組

28、件可以有多個業(yè)務(wù)單元，每個業(yè)務(wù)單元可以有多個業(yè)務(wù)活動2）業(yè)務(wù)單元之間推薦采用松散耦合的方式3）業(yè)務(wù)單元可以共享公共的技術(shù)設(shè)計及實現(xiàn)4）業(yè)務(wù)單元可以訪問組件內(nèi)，本單元外的公共業(yè)務(wù)實體的表結(jié)構(gòu)業(yè)務(wù)組件劃分以主設(shè)計為主，應(yīng)用架構(gòu)師、需求、設(shè)計、開發(fā)等參與。多角色多維度分析之后的結(jié)果。如何劃分業(yè)務(wù)組件的原則：1）業(yè)務(wù)組件的業(yè)務(wù)目的和業(yè)務(wù)場景，確定業(yè)務(wù)邊界；2）業(yè)務(wù)組件之間松耦合、業(yè)務(wù)組件內(nèi)部的內(nèi)聚性；3）業(yè)務(wù)的可獨立配置單位；4）業(yè)務(wù)的可獨立部署單位；5）業(yè)務(wù)組件的可替換性；6）每個業(yè)務(wù)活動只能唯一屬于一個業(yè)務(wù)組件，不同業(yè)務(wù)組件的業(yè)務(wù)活動不應(yīng)重復(fù)；業(yè)務(wù)活動應(yīng)基于角色進行劃分。7）從開發(fā)角度的一個約束：

29、一個業(yè)務(wù)組件內(nèi)的開發(fā)組件（操作、服務(wù)的實現(xiàn)類） 可以直接訪問本組件的業(yè)務(wù)實體的表結(jié)構(gòu)。表結(jié)構(gòu)對外是不可見的（報表除外）。8）每個業(yè)務(wù)組件有一個獨立的SRC目錄，不同業(yè)務(wù)組件的代碼必須隔離開；如何劃分業(yè)務(wù)組件，需要深入了解業(yè)務(wù)之間的關(guān)系，并根據(jù)管理模式、應(yīng)用場景、與其它業(yè)務(wù)組件的關(guān)系等各個層面的需求來進行分析。分析業(yè)務(wù)之間的關(guān)系，緊密耦合的組件考慮合并，例如繼承關(guān)系。關(guān)于組件的設(shè)計組件的變化性方面：支持變化性的組件（開發(fā)組件）的詳細(xì)設(shè)計有以下兩種選擇：將變化性的多個變化項設(shè)計為多個組件實現(xiàn)。這樣接口清晰、組件設(shè)計簡單、沒有冗余代碼。把所有的變化性情況設(shè)計到同一個組件中，用一種機制來處理所有的變化

30、項。這樣組件設(shè)計復(fù)雜，但是使用和演化比較靈活，組件的復(fù)用性也較高。組件的詳細(xì)設(shè)計建議采用以下方案：組件有一致的接口：設(shè)計多個組件實現(xiàn)來對應(yīng)變化項；采用參數(shù)化機制。組件的接口是變化的：采用組件技術(shù)提供的一些變化性控制機制；組件定制、組件集成框架等。對于支持變化性的組件的兩種復(fù)用方式：使用大量小的專用代碼，通過膠合代碼(glue code)組裝這些組件來實現(xiàn)變化性使用內(nèi)含一定變化性的大組件大粒度組件和小粒度組件（代碼小片斷）復(fù)用：支持變化性的組件帶來更多好處管理：少量大粒度組件更加容易管理成本效益：集成、組裝大量小粒度組件使得成本效益減少用大粒度組件的成本效益比較好，但是變化性的增加會導(dǎo)致投入的增

31、加另外，開發(fā)組件內(nèi)代碼的名稱空間中不反映業(yè)務(wù)組件，直接在模塊下。這樣在業(yè)務(wù)組件之間移動業(yè)務(wù)實體/業(yè)務(wù)操作時，不影響引用它們的代碼。業(yè)務(wù)服務(wù)的分析及設(shè)計業(yè)務(wù)服務(wù)和接口之間是1:1的關(guān)系，實現(xiàn)業(yè)務(wù)服務(wù)與軟件服務(wù)的對齊。分析業(yè)務(wù)服務(wù)及粒度：服務(wù)功能范圍的粒度是由其功能上下文所決定的。一個服務(wù)的整體粒度并不反映它當(dāng)前封裝的邏輯的數(shù)量，而是反映它基于上下文能夠封裝的潛在邏輯的數(shù)量。從業(yè)務(wù)流程中發(fā)現(xiàn)服務(wù)；業(yè)務(wù)服務(wù)是對外提供的業(yè)務(wù)活動；從服務(wù)消費者的使用需求，不同的使用場景，不同的使用角色對服務(wù)的要求可能不同，將導(dǎo)致需要細(xì)分服務(wù)；從授權(quán)角度，服務(wù)包含的方法的范圍將作為一個整體進行服務(wù)授權(quán)，過大或過小將導(dǎo)致服

32、務(wù)授權(quán)存在問題；服務(wù)從重用角度看，經(jīng)常一起使用的服務(wù)，可能需要考慮服務(wù)的合并；從業(yè)務(wù)活動角度看，一個服務(wù)是一個業(yè)務(wù)活動，需要從完成一個業(yè)務(wù)活動的業(yè)務(wù)操作的完整性上來考慮服務(wù)的范圍；服務(wù)的可替換性考慮服務(wù)粒度從四個角度考慮：服務(wù)范圍；服務(wù)能力；服務(wù)數(shù)據(jù)和服務(wù)約束。服務(wù)設(shè)計原則：分為兩類，包括主要導(dǎo)致實現(xiàn)具體服務(wù)設(shè)計特性的原則和主要用來塑造和控制如何應(yīng)用其他原則的原則。主要導(dǎo)致實現(xiàn)具體服務(wù)設(shè)計特性的原則包括：標(biāo)準(zhǔn)化服務(wù)合約。實現(xiàn)一個標(biāo)準(zhǔn)化合約，以支持服務(wù)的運行時（被消費）一個服務(wù)合約可以包含一組服務(wù)描述文檔，其中每個文檔都描述了服務(wù)的一部分。例如，一個Web服務(wù)的合約可以包含以下的服務(wù)描述文檔：1

33、）WSDL定義2）XML Schema定義3）WS-Policy描圖：服務(wù)合約服務(wù)的可復(fù)用性。實現(xiàn)通用的合可復(fù)用的邏輯與合約服務(wù)自治。實現(xiàn)獨立的功能邊界和運行時環(huán)境服務(wù)無狀態(tài)性。實現(xiàn)可適應(yīng)的和狀態(tài)管理無關(guān)的邏輯服務(wù)的可發(fā)現(xiàn)性。實現(xiàn)可交流的元信息主要用來塑造和控制如何應(yīng)用其他原則的原則包括：服務(wù)松散耦合。最小化依賴關(guān)系服務(wù)抽象。最小化元信息的可用性服務(wù)可組合性。最大化可組合性組件依賴兩個業(yè)務(wù)組件之間可能存在下圖的依賴關(guān)系：采用依賴倒置的原則，組件應(yīng)依賴于抽象，而不是實現(xiàn)。所以一個組件應(yīng)只依賴另一個組件的public部分。在開發(fā)環(huán)境下，跨模塊的組件依賴采用Jar包依賴的方式，業(yè)務(wù)組件之間的調(diào)用必需

34、是調(diào)用public部分的調(diào)用。關(guān)于組件間Public部分的循環(huán)依賴，有以下要求：1）原則NC業(yè)務(wù)組件間的Public部分盡量避免循環(huán)依賴，將循環(huán)依賴降至最低；存在Public部分循環(huán)依賴的業(yè)務(wù)組件必須提交設(shè)計評審；2）調(diào)整設(shè)計通過調(diào)整設(shè)計消除組件之間的Public部分循環(huán)依賴考慮是否可合并組件；考慮將一方的VO的屬性/方法的參數(shù)改為弱類型，元數(shù)據(jù)中記錄業(yè)務(wù)對象類型；將Public依賴改為實現(xiàn)依賴另一方的Public；考慮使用動態(tài)屬性；3）如果考慮2）后依然不能解決存在的問題，可選擇下面的編譯方法：手工編譯：假如組件A和B存在循環(huán)依賴：先將A的VO屬性/方法的參數(shù)改為弱類型，這樣B就可以編譯；等

35、B編譯過后，A依賴B的public 的jar包，A再將弱類型改為強類型進行編譯，以后雙方均依賴jar包進行編譯；工具編譯。編寫輔助編譯工具，將兩個循環(huán)依賴的public部分的源碼進行聯(lián)編。產(chǎn)生這兩部分的Jar包；注：組件Public 部分的循環(huán)依賴編譯問題只存在于同時沒有編譯的情況。當(dāng)編譯后彼此只采用public 部分的Jar包依賴，此問題將不復(fù)存在JAVA程序編碼規(guī)范平臺采用JAVA作為程序開發(fā)語言，經(jīng)過自身和大量用戶使用過程中總結(jié)如下基本編碼規(guī)范，如下：通用規(guī)則任何時候都必須遵照本規(guī)范的建議執(zhí)行，除非你有更好或者特殊的理由，如果有請將它反饋給我們，我們將根據(jù)您的建議修改該文檔，或者給您修改

36、建議。任何時候都不要將一些不相干的代碼放到一個文件里，代碼應(yīng)該按照邏輯來組織保存在文件中。命名規(guī)則與約束一般規(guī)則所有的標(biāo)識符都必須用英文命名。當(dāng)對集合變量命名時，請使用復(fù)數(shù)形式，用以描述該變量是一個集合。命名const變量時請保持所有的字母大寫，并且每個單詞之間用“_”連接。不推薦：private const int Max_Account = 100;推薦：private const int MAX_ACCOUNT = 100;請使用大家認(rèn)識一致的縮寫，不要自己隨意發(fā)明縮寫，這樣理解上會比較困難并且會產(chǎn)生歧義。不推薦：GetH()：H的具體含義請看下面的推薦方案UserInterface：這

37、里應(yīng)該用縮寫推薦：GetHandler()UI：大家都是知道UI指的是User Interface雖然private是默認(rèn)的訪問控制，但是建議不要省略這個關(guān)鍵字，請嚴(yán)格根據(jù)您設(shè)計的類的訪問控制規(guī)約明確的給出是否使用該關(guān)鍵字。不推薦：public class SomeClassstirng s;推薦：public class SomeClassprivate string s;每個變量的聲明必須占一行，避免一行聲明多個變量。不推薦：private string s,s1,s2;推薦：private string s;private string s1;private string s2;請不要只

38、用大小寫來區(qū)分標(biāo)識符，請使用明確的語義。不推薦：private Bus bus;private Bus bUs;推薦：private Bus PublicBus;private Bus InternalBus;聲明必須使用Java內(nèi)置的類型，不要使用類型的別名（這些別名在System命名空間）使用object 而不是Object使用string 而不是 String所有的本地變量和參數(shù)都是用Camel Case（請參考術(shù)語定義）。推薦：private void SomeMethod(string someParam)string localVariable = “Example local v

39、ariable”;類和結(jié)構(gòu)必須使用名詞或者名詞短語來命名。推薦：public class Carpublic class RedCar例外：如果是為繼承的組件命名，則可以使用繼承的組件名稱以及擴展特性來命名，例如，從Button繼承的ClickOnceButton。當(dāng)一個類作為某個接口的默認(rèn)實現(xiàn)時，請使用和接口相似的名稱命名。推薦：public class Component:IComponent或者public class DefaultProvider:IProvider所有的接口必須使用I作為前綴public interface IMyInterface所有的局部成員變量都推薦用m_作為

40、前綴，其他單詞部分遵循Pascal Case。變量的命名中請不要包含變量的類型信息（前綴后綴都不要包含）。不推薦：public enum GCCollectionModeEnumpublic class clsBuspublic struct RectangleStruct推薦：public enum GCCollectionModepublic class Buspublic struct Rectangle所有派生于Attribute的類均使用Attribute作為后綴，關(guān)于本條目可以參考微軟所有的Attribute類的設(shè)計，都有這個潛在的約束在里面。推薦：MyCustomAttribut

41、e:Attribute始終使用具有描述特性的變量名而不是用類型命名避免使用單個字符作為變量名。例如：index盡量避免寫成i，temp盡量避免寫成t。例外：循環(huán)變量。不要使用縮寫。例如：number不能縮寫成num，縮寫一定不要聲明成public的，一定不要存在暴露給外界語義不明確的縮寫。不要使用類型來描述變量不推薦：public void Render(int intValue); 推薦：public void Render(int Value);屬性方法方法的命名必須使用動賓結(jié)構(gòu)的短語。推薦：private void DoSomething()帶有返回值的方法名稱中必須有返回值的描述信息。

42、推薦：private State GetViewState(); / 這里返回的是一個狀態(tài)命名空間請使用有準(zhǔn)確含義的的命名空間，例如：單位.產(chǎn)品.模塊.XX UAP.Portal.SubModule。推薦：.在類型、枚舉、接口的命名上盡量避免和系統(tǒng)的同名。即使在不同的命名空間下，在使用這些類型的時候也可能存在定義不明確的問題?？丶?guī)則控件命名建議采用控件名縮寫+英文描述的形式，下表為控件縮寫對照表?？丶愋涂s寫對應(yīng)UF控件類型UF空間縮寫LabellblUFLableuflblTextBoxtxtUFTextBoxuftxtButtonbtnUFButtonufbtnUFButtonNor

43、malufbtnnCheckBoxchkUFCheckBoxufchkCheckBoxListchksUFCheckBoxListufchksDropDownListddlUFDropDownListufddlImageimgUFImageufimgLinkButtonlnkUFLinkuflnkListBoxlbUFListBoxuflbRadioBoxListrblUFRadioBoxListufrblWebControlwebctlUFWebControlufwebctlPanelpnlUFPanelufpnlGridgrdUFGridufgrd代碼風(fēng)格代碼風(fēng)格約束編碼時應(yīng)該遵循的大多數(shù)

44、情況，這里描述的內(nèi)容都是一般性的，通常情況下的，對于例外情況需要在代碼中做特殊的注釋說明。同樣此部分內(nèi)容依然遵循通用規(guī)則里面的第一條?；静季秩魏螘r候不要將多個類放到一個源文件中，但是一個類可以分別放在多個源文件中。感謝微軟為我們提供的部分類吧。任何時候一個源文件中只能有一個命名空間，也就是說在同一個源文件中不能存在兩個不同的命名空間定義。按照下面的方式布局你定義的類。成員變量構(gòu)造函數(shù)和析構(gòu)函數(shù)（如果有）內(nèi)部定義的類和枚舉型等嵌套的內(nèi)容屬性方法如果是你自己寫的代碼，任何一個源文件的大小不要超過500行代碼，超過500行的源代碼閱讀起來比較困難，可以考慮將他們按照功能分類，或者放到部分類中。任何

45、一個方法都不要超過200行，超過200行的方法通常情況下做的不是 一件事情，請將功能按照方法來劃分，可以考慮使用重構(gòu)的方式分解方法，請參考重構(gòu)。正如通用規(guī)則里面描述的，一個文件里面不能超過一個以上的類，該文件 的文件名必須能準(zhǔn)確的反應(yīng)出文件保存的類，建議直接使用類名作為文件的名稱。變量參數(shù)當(dāng)給方法傳遞參數(shù)的時候，參數(shù)的個數(shù)應(yīng)該限制在5個以內(nèi)（包括5個），如果多于5個可以考慮使用結(jié)構(gòu)將參數(shù)封裝以后再傳遞。所有的私有成員變量必須放在其他成員的前面。也就是說私有的成員變量必須位于所有聲明的最頂端。推薦：public class CustomClassprivate string m_Field1;p

46、rivate string m_Field2;/ 這里必須要有一個空行，用來區(qū)分代碼塊，增加可讀性public void Method1()public void Method2()局部變量盡量在它第一次使用之前聲明。請不要將局部變量的聲明與使用它的地方相隔太遠(yuǎn)，不便于理解。不推薦：public void Method1()int nodeCount = 0;if(hasNode)nodeCount = GetNodeCount();if(nodeCount 10)/ Do Something推薦：public void Method1()if(hasNode)int nodeCount =

47、GetNodeCount();if(nodeCount 10)/ Do Something縮進規(guī)則行縮進請使用下面建議兩種方式中的一種每個縮進用一個Tab（四個字符寬）每個縮進用四個空格不論采用何種策略，您的代碼中始終應(yīng)該保持唯一的一種風(fēng)格。起始大括號的使用請遵守下面兩種方案中的一種，請在您的代碼中唯一的使用其中一種，該設(shè)置可以通過Esclipse的Option修改。起始大括號始終占一個新行。推薦：public class MyClass/ public void MyMethod()/ ./ 起始大括號在行的末尾。public class MyClass/ public void MyMet

48、hod()/ ./ 在使用匿名方法的時候，為了代碼清晰，請使用下面的方式不推薦：delegate void SomeDelegate(string someString);void SomeMethod()SomeDelegate someDelegate = delegate(stirng productName)ShowString(productName); someDelegate(“wujian”);推薦：delegate void SomeDelegate(string someString);void SomeMethod()SomeDelegate someDelegate =

49、 delegate(stirng productName)ShowString(productName); /和delegate對齊someDelegate(“wujian”);代碼注釋任何時候注釋的縮進應(yīng)該保持和代碼在同一個級別上。推薦：bool hasNode = HasNode(node);if(hasNode)/ 如果存在節(jié)點則為該節(jié)點添加新的子節(jié)點node.AddChildNode(childNode);/ 這里注釋的縮進請保持和代碼的級別一致所有的注釋必須是清晰明確的。也就是說，注釋能明確的解釋代碼的含義，請不要在代碼中添加無意義的注釋，絕對不要出現(xiàn)注釋說明注釋的情況，并且請確保沒

50、有錯別字。任何時候不要給看起來顯而易見的方法添加啰嗦的注釋，方法的命名，變量的命名應(yīng)該盡量做到能自我解釋，通常不需要對某個變量做特殊的注釋。注釋應(yīng)該描述一些關(guān)于算法和變更日志的信息。建議使用/樣式的注釋，可以通過IDE的工具欄中的實現(xiàn)塊注釋。每個源文件開頭的部分都必須包含文件的簡要說明，并且嵌入#region#endregion。推薦：請參考命名規(guī)則于約束文件的相關(guān)內(nèi)容。行注釋必須在雙斜線后面跟一個空格推薦：/ 這是一個標(biāo)準(zhǔn)的注釋行/注釋中始終應(yīng)該包括，和。對于具體需要注釋的內(nèi)容請參照API模板文檔對每種類型的要求。- add by hjf對于對外發(fā)布的類，接口，委托，枚舉及其相關(guān)內(nèi)容，必須采

51、用微軟XML文檔化注釋，以便生成API文檔。而不對外發(fā)布的內(nèi)容盡量不要采用這種注釋方法。- add by hjf盡量在需要的時候包含 和 ，效果不錯。流程控制代碼中一定不要出現(xiàn)goto語句，如果出現(xiàn)了一定是代碼邏輯有問題，請仔細(xì)檢查并使用合適的方法消除goto語句。避免在foreach里面修改枚舉集合的內(nèi)容。在for使用的引用型數(shù)組必須顯式的初始化。所有的流程控制語句都必須保持語句塊的清晰，以減少閱讀上的困難。不推薦：if(b1)if(b2) Foo();else Bar();推薦：if(b1)if(b2)Foo();elseBar();所有的switch語句必須包含default標(biāo)簽。在sw

52、itch語句的default語句中必須添加Assertint busNumber = GetBusNumber();switch(busNumber)case 753:/ 開往回龍觀break;case 443:/ 開往龍澤break;default:Debug.Assert(false); / 這一行是必要的break;else子句中的ifelse語句必須包括else部分，保證邏輯覆蓋完整。請不要顯式的判斷條件的真?zhèn)?，即不要顯示的將bool值和true和false比較。不推薦：if(condition = false) if(condition != true) if(condition =

53、 true) = true = true) / 看著頭暈推薦：if(condition)不論if語句或者else語句有多短，必須對其后的語句塊使用大括號。不推薦：if(number = 1)return 0;elsereturn 1;推薦：if(number = 1)return 0;elsereturn 1;為了提高可閱讀性，盡量避免非標(biāo)準(zhǔn)的，和復(fù)雜的條件縮寫語句，雖然這看起來很Cool，但是可能其他人看起來會比較困難。避免一個條件語句中出現(xiàn)多個邏輯判斷，如果必須這么做請將多個邏輯表達(dá)式賦值本地變量然后再使用本地變量進行邏輯判斷。不推薦：if(條件表達(dá)式1 & 條件表達(dá)式2 | 條件表達(dá)式3

54、)推薦：bool condition1 = 條件表達(dá)式1;bool condition2 = 條件表達(dá)式2；bool condition3 = 條件表達(dá)式3;if(condition1 & condition2 | condition3)避免在條件語句中賦值語句不推薦：if(bus.Number = 753) = 443)推薦：bus.Number = 753;if(bus.Number = 443)不要訪問在一個表達(dá)式里面改變多次的變量，雖然這看起來很酷，但是真的很難理解，這些看起來挺不錯的優(yōu)化編譯器已經(jīng)幫你做了，通常情況下你不需要這么做。不推薦：arrayi = +i; / 這里你是在給a

55、rrayi賦值還是給array+i 賦值i = +i +1;推薦：arrayi = +t; / 這里很清楚的說明你是在給arrayi賦值i += 2; 通用的縮寫方式不但可以使代碼簡潔并且容易理解。不推薦：bool b1;if(val 0)b1= true;elseb1= false;bool b1;b1 = (val 0);推薦：bool b1 = (val0)? true : false;bool b1 = (val 0);避免將錯誤代碼作為方法的返回值，方法是執(zhí)行一個單一功能的邏輯單元，方法在語義上都有準(zhǔn)確的含義。不推薦：public string GetUserName()tryret

56、urn DB.GetUserName();catch(Exception ex)return ex.Message;推薦：public string GetUserName()tryreturn DB.GetUserName();catch(Exception ex)throw;避免使用異常處理作為流程控制的一部分。不推薦：public Bus GetBus()tryreturn innerGetBus();catchreturn new Bus();推薦：public Bus GetBus()tryBus bus = innerGetBus();if(bus=null)bus = new B

57、us();return bus;catch(Exception ex)throw;JAVA WebService編碼規(guī)范JAVA WebService作為SOA標(biāo)準(zhǔn)的核心實現(xiàn)方式，JAVA WebService 服務(wù)分為Server、Client 兩部分，Server 公開Web 服務(wù)，Client 調(diào)用Web 服務(wù)，JAX-WS 的服務(wù)端、客戶端雙方傳輸數(shù)據(jù)使用的SOAP 消息格式封裝數(shù)據(jù)，在后面我們會看到其實SOAP 信封內(nèi)包裝的就是一段XML 代碼。支持主流的操作系統(tǒng)、中間件、數(shù)據(jù)庫支持主流的操作系統(tǒng)包括Windows、Linux、unix等。支持主流的數(shù)據(jù)庫包括Oracle、SQLSe

58、rver、MySql、PostgreSQL等。支持主流的中間件包括：中間件、WebSphere、WebLogic等。成熟的開發(fā)規(guī)范、模版平臺提供完善的開發(fā)規(guī)范，包括：Java編碼規(guī)法、應(yīng)用開發(fā)規(guī)范、組件開發(fā)標(biāo)準(zhǔn)規(guī)范；提供移動開發(fā)相關(guān)規(guī)范；提供完善的業(yè)務(wù)開發(fā)模板；提供開發(fā)、移動、流程管理相關(guān)培訓(xùn)文檔。詳見附件：開發(fā)規(guī)范平臺公共基礎(chǔ)功能支持統(tǒng)一身份驗證平臺支持集成開發(fā)、支持普通的用戶名/密碼認(rèn)證方式,以及支持 CA 證書、USBKEY 等多種身份認(rèn)證方式多種認(rèn)證方式、AD域認(rèn)證完美集成UAP IDM提供統(tǒng)一的應(yīng)用系統(tǒng)訪問規(guī)范，支持多種認(rèn)證協(xié)議或方式，加強訪問方式的規(guī)范性、安全性。對內(nèi)，向管控用戶提

59、供單一的身份認(rèn)證憑據(jù)；對外，提供身份認(rèn)證服務(wù)。認(rèn)證服務(wù)提供標(biāo)準(zhǔn)化、規(guī)范化服務(wù)，支持靜態(tài)口令、AD域、數(shù)字證書、多因子、LDAP等多種不同強度的認(rèn)證方式。UAP IDM提供與微軟AD域認(rèn)證完美適配，啟動電腦可直接進入系統(tǒng)，無需手工輸入用戶密碼認(rèn)證。圖：多種認(rèn)證方式支持組織機構(gòu)配置管理平臺具有動態(tài)建模能力，可以對集團企業(yè)的組織、管控、流程等進行建模抽象，可以滿足成長型集團企業(yè)的組織機構(gòu)變化調(diào)整需求。1.企業(yè)結(jié)構(gòu)與管控建模。實現(xiàn)對企業(yè)的組織地點的管理，這些地點可能或安裝企業(yè)管理軟件。支持針對企業(yè)結(jié)構(gòu)建立企業(yè)管控的策略、模型及規(guī)則等。2.組織建模。動態(tài)組織建模功能支持企業(yè)組織變革、并購、重組。支持多級

60、集團和多組織建模，支持組織的多版本管理。每個業(yè)務(wù)單元可具有不同的組織職能，企業(yè)可以根據(jù)需要為業(yè)務(wù)單元設(shè)置其需要具有的組織職能。利用動態(tài)建模能力可以靈活的通過配置方式調(diào)整組織機構(gòu)而無需修改代碼，從而快速適應(yīng)業(yè)務(wù)變化。豐富的通用組件開發(fā)平臺開發(fā)了大量的通用技術(shù)組件，基于這些組件，可以大大降低開發(fā)成本，提高開發(fā)效率。通用組件包括：表單組件、列表組件、導(dǎo)航組件、打印組件、布局組件、流媒體組件、數(shù)據(jù)訪問控制組件、安全處理組件等數(shù)百個組件。對于流程中間件，為了幫助快開發(fā)，提供流程樹控件、流程跟蹤圖控件、流程跟蹤列表控件、工作項領(lǐng)取控件、取消工作項領(lǐng)取控件、工作項執(zhí)行控件、保存工作項控件、工作項代辦控件、代