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

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

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

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

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

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

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

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

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

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

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

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

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

13、的性能，比如Oracle RAC。圖 企業(yè)和組織的軟件架構(gòu)現(xiàn)狀以上是軟件架構(gòu)的現(xiàn)狀，但是技術(shù)總是在不斷演進(jìn)。隨后的HTML5是用于取代1999年所制定的HTML4.01和XHTML1.0標(biāo)準(zhǔn)的，現(xiàn)在仍處于發(fā)展階段，但大部分瀏覽器已經(jīng)支持某些HTML5技術(shù)。HTML5強(qiáng)化了Web網(wǎng)頁的表現(xiàn)性能，并且追加了本地?cái)?shù)據(jù)庫等Web應(yīng)用的功能，提供更多能有效增強(qiá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è)計(jì)人員遞交給了程序員，即可以直接在We

14、b的前端使用JavaScript腳本來描述一個(gè)UI組件模型，然后在運(yùn)行時(shí)，由瀏覽器的腳本解釋器調(diào)用核心的UI技術(shù)框架來將其轉(zhuǎn)換成HTML的UI界面。此類UI技術(shù)框架跟服務(wù)器端UI技術(shù)的思路一致，只是在客戶端瀏覽器中封裝了一套UI模型。這樣界面設(shè)計(jì)不需要服務(wù)器端的支持，在開發(fā)期間能更好地展示和測(cè)試界面效果。同時(shí)由于UI界面的構(gòu)建和控制都在客戶端，只需要和服務(wù)器端傳遞請(qǐng)求參數(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端為中心進(jìn)行UI設(shè)計(jì)的，應(yīng)用都是以功能為中心。在云計(jì)算環(huán)境中，服務(wù)能力都通過網(wǎng)絡(luò)來提供，可將服務(wù)擴(kuò)展到不同類型的客戶端平臺(tái)，如手機(jī)、PAD等。這種端的變化，使傳統(tǒng)IT轉(zhuǎn)變?yōu)橐砸苿?dòng)為中心來設(shè)計(jì)UI，同時(shí)應(yīng)用變?yōu)橐杂脩魹橹行摹＿@就要求企業(yè)應(yīng)用的UI層越來越需要朝著HTML5、JavaScript和CSS3的方向演變和發(fā)展，也就是說UI層對(duì)于傳統(tǒng)的應(yīng)用服務(wù)器端來說將變得越來越輕量化。另外由于UI的輕量化將導(dǎo)致傳統(tǒng)的應(yīng)用服務(wù)器中的JSP容器等逐漸變得不再需要了，更不用說EJB容器早就被大部分企業(yè)拋棄，

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

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

18、案如下：產(chǎn)品方案iUAP開發(fā)平臺(tái)業(yè)務(wù)流程管理（BPM）平臺(tái)企業(yè)移動(dòng)平臺(tái)下面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ò)對(duì)松散耦合的粗粒度應(yīng)用組件進(jìn)行分布式部署、組合和使用。SOA是一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通過簡(jiǎn)單、精確定義接口進(jìn)行通訊，不涉及底層編程接口和通訊模型。SOA將能夠幫助軟件工程師們站在一個(gè)新的高度理解企業(yè)級(jí)架構(gòu)中的各種組件的開發(fā)、部署形式，它將幫助企業(yè)系統(tǒng)架構(gòu)者以更迅速、更可靠、更具重用性架構(gòu)整個(gè)業(yè)務(wù)系統(tǒng)。較之以往，以SOA架構(gòu)的系統(tǒng)能夠更加從容

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

20、Service Oritented Architecture, SCA）應(yīng)用而生。SCA使用戶在構(gòu)建企業(yè)應(yīng)用時(shí)有一個(gè)不再直接面對(duì)具體的技術(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ù)實(shí)現(xiàn)對(duì)SOA規(guī)范的支持，采用組件化的編程規(guī)范和模式，使得iUAP可開發(fā)出具有架構(gòu)優(yōu)化、高靈活性、高擴(kuò)展性的企業(yè)應(yīng)用。運(yùn)用iUAP對(duì)SOA規(guī)范（SCA，SDO）的支持，可以開發(fā)出高可用、架構(gòu)優(yōu)化的大型企業(yè)應(yīng)用，NC大型ERP產(chǎn)品就是iUAP開發(fā)平臺(tái)基于SO

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

22、與部署：開發(fā)平臺(tái)可與其他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ù)組件的接口模型請(qǐng)參考服務(wù)模塊（Module）服務(wù)模塊由一個(gè)或多個(gè)具有內(nèi)在業(yè)務(wù)聯(lián)系的服務(wù)組件構(gòu)成。模塊可以獨(dú)立部署，只要保持模塊接口不變，就可通過重新部署新的模塊而替換原有的業(yè)務(wù)邏輯，而不影響應(yīng)用的其它部分。導(dǎo)入（Impo

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

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

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

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

27、。業(yè)務(wù)數(shù)據(jù)：組件內(nèi)業(yè)務(wù)處理涉及的數(shù)據(jù)對(duì)象；業(yè)務(wù)策略：（一組）業(yè)務(wù)活動(dòng)的Selector，不同的場(chǎng)景可能使用不同的業(yè)務(wù)策略；組件治理：根據(jù)組件自身的治理要求，獨(dú)立對(duì)組件的內(nèi)容進(jìn)行約束及管理；業(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ā)組件：每個(gè)業(yè)務(wù)組件可以包含一組開發(fā)組件。開發(fā)組件包括：UI組件業(yè)務(wù)服務(wù)組件業(yè)務(wù)活動(dòng)組件業(yè)務(wù)實(shí)體組件引用組件其它組件業(yè)務(wù)組件、業(yè)務(wù)單元與業(yè)務(wù)活動(dòng)的關(guān)系：業(yè)務(wù)單元：一個(gè)在業(yè)務(wù)組件內(nèi)部具有更緊密關(guān)系的業(yè)務(wù)活動(dòng)的集合。1）一個(gè)業(yè)務(wù)組

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

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

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

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

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

33、）WSDL定義2）XML Schema定義3）WS-Policy描圖：服務(wù)合約服務(wù)的可復(fù)用性。實(shí)現(xiàn)通用的合可復(fù)用的邏輯與合約服務(wù)自治。實(shí)現(xiàn)獨(dú)立的功能邊界和運(yùn)行時(shí)環(huán)境服務(wù)無狀態(tài)性。實(shí)現(xiàn)可適應(yīng)的和狀態(tài)管理無關(guān)的邏輯服務(wù)的可發(fā)現(xiàn)性。實(shí)現(xiàn)可交流的元信息主要用來塑造和控制如何應(yīng)用其他原則的原則包括：服務(wù)松散耦合。最小化依賴關(guān)系服務(wù)抽象。最小化元信息的可用性服務(wù)可組合性。最大化可組合性組件依賴兩個(gè)業(yè)務(wù)組件之間可能存在下圖的依賴關(guān)系：采用依賴倒置的原則，組件應(yīng)依賴于抽象，而不是實(shí)現(xiàn)。所以一個(gè)組件應(yīng)只依賴另一個(gè)組件的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è)計(jì)評(píng)審；2）調(diào)整設(shè)計(jì)通過調(diào)整設(shè)計(jì)消除組件之間的Public部分循環(huán)依賴考慮是否可合并組件；考慮將一方的VO的屬性/方法的參數(shù)改為弱類型，元數(shù)據(jù)中記錄業(yè)務(wù)對(duì)象類型；將Public依賴改為實(shí)現(xiàn)依賴另一方的Public；考慮使用動(dòng)態(tài)屬性；3）如果考慮2）后依然不能解決存在的問題，可選擇下面的編譯方法：手工編譯：假如組件A和B存在循環(huán)依賴：先將A的VO屬性/方法的參數(shù)改為弱類型，這樣B就可以編譯；等

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

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

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

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

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

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

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

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

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

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

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

46、rivate string m_Field2;/ 這里必須要有一個(gè)空行，用來區(qū)分代碼塊，增加可讀性public void Method1()public void Method2()局部變量盡量在它第一次使用之前聲明。請(qǐng)不要將局部變量的聲明與使用它的地方相隔太遠(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縮進(jìn)規(guī)則行縮進(jìn)請(qǐng)使用下面建議兩種方式中的一種每個(gè)縮進(jìn)用一個(gè)Tab（四個(gè)字符寬）每個(gè)縮進(jìn)用四個(gè)空格不論采用何種策略，您的代碼中始終應(yīng)該保持唯一的一種風(fēng)格。起始大括號(hào)的使用請(qǐng)遵守下面兩種方案中的一種，請(qǐng)?jiān)谀拇a中唯一的使用其中一種，該設(shè)置可以通過Esclipse的Option修改。起始大括號(hào)始終占一個(gè)新行。推薦：public class MyClass/ public void MyMethod()/ ./ 起始大括號(hào)在行的末尾。public class MyClass/ public void MyMet

48、hod()/ ./ 在使用匿名方法的時(shí)候，為了代碼清晰，請(qǐng)使用下面的方式不推薦：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對(duì)齊someDelegate(“wujian”);代碼注釋任何時(shí)候注釋的縮進(jìn)應(yīng)該保持和代碼在同一個(gè)級(jí)別上。推薦：bool hasNode = HasNode(node);if(hasNode)/ 如果存在節(jié)點(diǎn)則為該節(jié)點(diǎn)添加新的子節(jié)點(diǎn)node.AddChildNode(childNode);/ 這里注釋的縮進(jìn)請(qǐng)保持和代碼的級(jí)別一致所有的注釋必須是清晰明確的。也就是說，注釋能明確的解釋代碼的含義，請(qǐng)不要在代碼中添加無意義的注釋，絕對(duì)不要出現(xiàn)注釋說明注釋的情況，并且請(qǐng)確保沒

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

51、用微軟XML文檔化注釋，以便生成API文檔。而不對(duì)外發(fā)布的內(nèi)容盡量不要采用這種注釋方法。- add by hjf盡量在需要的時(shí)候包含 和 ，效果不錯(cuò)。流程控制代碼中一定不要出現(xiàn)goto語句，如果出現(xiàn)了一定是代碼邏輯有問題，請(qǐng)仔細(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部分，保證邏輯覆蓋完整。請(qǐng)不要顯式的判斷條件的真?zhèn)?，即不要顯示的將bool值和true和false比較。不推薦：if(condition = false) if(condition != true) if(condition =

53、 true) = true = true) / 看著頭暈推薦：if(condition)不論if語句或者else語句有多短，必須對(duì)其后的語句塊使用大括號(hào)。不推薦：if(number = 1)return 0;elsereturn 1;推薦：if(number = 1)return 0;elsereturn 1;為了提高可閱讀性，盡量避免非標(biāo)準(zhǔn)的，和復(fù)雜的條件縮寫語句，雖然這看起來很Cool，但是可能其他人看起來會(huì)比較困難。避免一個(gè)條件語句中出現(xiàn)多個(gè)邏輯判斷，如果必須這么做請(qǐng)將多個(gè)邏輯表達(dá)式賦值本地變量然后再使用本地變量進(jìn)行邏輯判斷。不推薦：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)不要訪問在一個(gè)表達(dá)式里面改變多次的變量，雖然這看起來很酷，但是真的很難理解，這些看起來挺不錯(cuò)的優(yōu)化編譯器已經(jīng)幫你做了，通常情況下你不需要這么做。不推薦：arrayi = +i; / 這里你是在給a

55、rrayi賦值還是給array+i 賦值i = +i +1;推薦：arrayi = +t; / 這里很清楚的說明你是在給arrayi賦值i += 2; 通用的縮寫方式不但可以使代碼簡(jiǎn)潔并且容易理解。不推薦：bool b1;if(val 0)b1= true;elseb1= false;bool b1;b1 = (val 0);推薦：bool b1 = (val0)? true : false;bool b1 = (val 0);避免將錯(cuò)誤代碼作為方法的返回值，方法是執(zhí)行一個(gè)單一功能的邏輯單元，方法在語義上都有準(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)的核心實(shí)現(xiàn)方式，JAVA WebService 服務(wù)分為Server、Client 兩部分，Server 公開Web 服務(wù)，Client 調(diào)用Web 服務(wù)，JAX-WS 的服務(wù)端、客戶端雙方傳輸數(shù)據(jù)使用的SOAP 消息格式封裝數(shù)據(jù)，在后面我們會(huì)看到其實(shí)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ī)范、模版平臺(tái)提供完善的開發(fā)規(guī)范，包括：Java編碼規(guī)法、應(yīng)用開發(fā)規(guī)范、組件開發(fā)標(biāo)準(zhǔn)規(guī)范；提供移動(dòng)開發(fā)相關(guān)規(guī)范；提供完善的業(yè)務(wù)開發(fā)模板；提供開發(fā)、移動(dòng)、流程管理相關(guān)培訓(xùn)文檔。詳見附件：開發(fā)規(guī)范平臺(tái)公共基礎(chǔ)功能支持統(tǒng)一身份驗(yàn)證平臺(tái)支持集成開發(fā)、支持普通的用戶名/密碼認(rèn)證方式,以及支持 CA 證書、USBKEY 等多種身份認(rèn)證方式多種認(rèn)證方式、AD域認(rèn)證完美集成UAP IDM提供統(tǒng)一的應(yīng)用系統(tǒng)訪問規(guī)范，支持多種認(rèn)證協(xié)議或方式，加強(qiáng)訪問方式的規(guī)范性、安全性。對(duì)內(nèi)，向管控用戶提

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

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