1引言
1．1 SOA的產生背景
隨著計算機軟件技術的不斷發展，各企業都傾向于應用特定的信息系統(如：MIS，LES，SMS)來管理企業的內外事務。這砦系統為企業節約了專項人工開支，提高了商業運作反應速度。但從企業內部信息溝通的角度上來看，由于各種軟件的開發應用平臺和設計結構可能不盡相同，從而不可避免地會產生“信息孤島”，即企業內部各特定系統之間的信息數據如不實行人工干預模式就難以互通。這種情形對整合企業內部事務結構，梳理企業內外運作關系是極其不利的，也正是這種“孤島”效應的產生成為了企業自身發展的瓶頸之一。
面向服務的架構(Service—Oriented Architecture，SOA)技術能夠給企業提供一種構建信息系統的標準和方法。通過建立可組合、重用的服務體系以減少企業的信息業務冗余，加快項目開發進程，從而提高企業信息系統利用率并有效降低系統開發成本。近年來，Web服務的出現使得異構系統的交互成為可能，特別是隨著Web服務標準和規范的出臺(如：簡單對象訪問協議、Web服務描述語言、統一描述一發現一集成協議等等)使之越來越趨于現實化。在此基礎上，SOA的推廣和普及工作高速運轉，各大廠商如國外的IBM、SUN、SAP，國內的中軟、普元、用友都紛紛協作努力進行SOA的標準化定制。人們已經把關注點從簡單的Web服務拓展到面向服務體系架構的各個方面。各種支持SOA的開發平臺、工具、中間件紛紛出臺，為SOA的普及化提供了有利的外部環境。這些舉措標志著SOA進入到了實施階段。
1．2 SOA的技術特點
SOA作為一種分布式組件體系結構。其核心特點是跨平臺和松耦合：不管在企業內部還是企業外部，SOA組件都是透明的，并且可以通過一系列統一支持的、可互操作遠程過程調用和消息傳遞協議來統一訪問。接口定義標準支持開發人員工具之間的互操作性。網絡上協議互操作性相對于代碼可移植性是SOA組件的中心部分．支持統一訪問和平臺獨立。調用方無需知道組件的基礎實現技術，如J2EE、Micmsofi．Net和PHP。SOA組件封裝功能，并支持通過業務分析人員和業務模型建模的抽象級別的重用。這使IT功能和它所支持的業務功能之間的映射更加直接，從而提高了可靠性。計算機可處理的約定允許第三方訪問SOA組件提供的服務。這些約定顯式聲明功能性特征以及非功能性(服務質量或QoS)特征和需求，SOA組件使用WSDL記錄它們的操作，還可以使用用Web服務的業務流程執行語言(BPEIAWS)來定義組件的有效操作序列，從而動態發現、選擇、綁定(通過其聲明性屬性)和集成SOA組件。松耦合特性簡單來說即是被整合的各種系統除附加增值屬性外還應保持自身原有的特有屬性功能。
總的說來，SOA強調的是一種體系架構模型，它可以根據企業的業務需求通過網絡對松耦合的不同業務服務進行靈活的分布式部署、整合和使用，這些業務服務獨立于編程語言、實現方式和運行平臺。
2構建適用于中小企業的SOA“核心業務”顆粒度模型
在企業中應用SOA就意味著將業務流程或功能用服務來描述，所謂服務顆粒度(Service Granularitv)就是指一個服務包含的功能大小。服務顆粒度的正確定位將直接影響到服務的質量，包括靈活性和效率等諸多方面。因此。選擇合適的顆粒度劃分對服務設計是至關重要的。目前，國內許多中小企業雖看好SOA的發展趨勢，卻難以接受其高昂的系統成本。這是因為應用SOA技術做標準化信息系統整合時，所慣用的企業服務顆粒度劃分標準為粗粒度劃分模式12l。我們崩粒度來表示一個服務的大小，或者說是服務操作的范圍，粗粒度的服務，涉及的內容廣而且雜；細粒度的服務，涉及的內容細而且簡單。粗粒度的服務設計，可以減小服務之間的耦合性，但付出的代價就是增加服務的復雜性。服務具備了太多的功能．增加了設計的復雜性和維護的難度；細粒度的服務，可以讓服務的實現變得簡單，但這樣會增加服務的數量，服務過細過多，這樣必然有一些服務需要組合才能實現一定的功能，那樣就增加了服務之間的耦合度，只要其中一個服務發生了改變，勢必影響整個系統架構。從以上兩種顆粒度的對比我們不難看出，服務粗粒度的劃分雖符合SOA技術要求達到了松耦合的目的，但增加了服務復雜度，提高了系統開銷。因此，在對中小企業SOA系統服務顆粒度劃分時必須考慮設計成本與SOA標準化之間的平衡。
在SOA顆粒度模型構建上，本文提出一種構建“核心業務”顆粒度流程模型的方法來尋找一種折中的途徑。這里對“核心業務”的定義是企業內外運營中最為重要、使片j頻率最高的業務(服務)項目或流程。我們的SOA設計遵循這樣的設計思路：先從企業信息系統的各功能模塊中分離出核心業務，各個功能模塊可以看作核心業務的階段性表達；然后在核心業務的基礎上設計組件和業務對象；設計完組件和業務對象之后再來設計系統服務整合。這樣不管所需整合的服務范圍多廣，服務多復雜。都可以通過核心業務和企業工作流程把各種形式的服務整合起來。就算是這種整合服務經常需要變動，但是這種變動相對于核心業務層次來說是較為穩定的。因而能夠有效地加強系統的復用性并且降低系統構件成本。
這樣的設計思路也體現了SOA自頂向下的設計方法：功能模塊一>服務一>組件和業務對象。服務不是憑空想象出來的，它必須要滿足客戶的需求，而客戶需求的體現就是系統要提供的功能，所以功能模塊的設計是服務設計的前提。
3中小企業SOA系統的可靠性度量
衡量可靠性的兩個粗略的指標是平均故障間隔時間(MTTF)和平均恢復時間(MTTR)。這兩項指標對于服務用戶是非常重要的，因為這些指標在確定服務合同方面將發揮重要作用。然而，對于服務部署者來說，還有一些需要優先了解的指標，這些指標經常會受到這些服務可能使用的機器的影響。因此，監視和度量機器和分布式系統中的網絡連接的MTTF和MTTR也是必要的。另一方面，SOA中的一項鶯要指標是系統的服務靈活性，而服務靈活性優劣是與開發和部署此項服務的時間成反比的。因此這種靈活性將隨著開發時間的增加而變得難以度量，從而直接對SOA系統可靠性衡量帶來了額外的負擔。換句話說，SOA系統的可靠性度量復雜程度與系統中涉及服務的質量有關，越精細的服務質量所需求的可靠性程度越高，度量丁作量越大，反之度量工作量較小。目前在SOA可靠性研究領域依然沿用著軟件可靠性分析的那一套方法，僅僅從全局的角度來考究系統的可靠性，而SOA系統的核心內容是面向服務的架構，特別是中小企業的SOA系統。其個性化程度相當高，并不滿足于全局考量，企業用戶總希望能夠獲得更優服務質量同時對單個構架的可靠性有較好的把握。
SOA可靠性的衡量需要考慮許多指標，并非每一個治理實施都將幫助衡量這些因素。SOA系統架構需要從初始研發的時候就貫穿可靠性分析。單個服務的可靠性分析也許不容易立即實現，特別是在架構部署的起步階段規模很小并且正在增長的時候。但是，如果你要保證你所架構的服務項目在未來不過時，這些步驟是必要的。
4結語
SOA作為一種新生的軟件架構其自身還有許多不盡完善的地方，如：中小企業SOA系統的技術標準、語義網服務、資產服務、自適應SOA模型、虛擬服務平臺，靈活的行業采用等等。這些技術點的研究都將加速SOA的平民化進程，使得SOA服務得到充分的拓展。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：中小企業構建SOA系統有哪些難點？
相關文章
