SOA科技小論文

1.SOA

         當咱們的項目比較小時，咱們只有一個系統，而且把他們寫到一塊兒，放在一個服務器上，可是隨着平臺愈來愈大，數據量愈來愈大，咱們不得不經過分庫，把多個模塊的數據庫分別放在對應得服務器上，每一個模塊調用本身的子系統便可。隨着咱們系統的進一步複雜度的提示，咱們不得不進一步對系統的性能進行提高，咱們將多個模塊分紅多個子系統，多個子系統直接互相調用（由於SOA通常用於大型項目，比較複雜，因此通常總系統不會再集成，會拆分多個，分別作成服務，相互調用）。當咱們的電商UI進行一個下訂單的任務時，多個服務直接互相調用，系統經過數據總線，分別調用對於的子系統便可。

此外，動態業務的工做流不只能夠包括部門之間的操做，甚至還能夠包括與不爲您控制的外部合做夥伴進行的操做。所以，爲了提升效率，您須要定義應該如何得知服務之間的關係的策略，這種策略經常採用服務級協定和操做策略的形式。

最後，全部這些都必須處於一個信任和可靠的環境之中，以同預期的同樣根據約定的條款來執行流程。所以，安全、信任和可靠的消息傳遞應該在任何 SOA 中都起着重要的做用。

我能夠用面向服務的體系結構作什麼？對 SOA 的須要來源於須要使業務 IT 系統變得更加靈活，以適應業務中的改變。經過容許強定義的關係和依然靈活的特定實現，IT 系統既能夠利用現有系統的功能，又能夠準備在之後作一些改變來知足它們之間交互的須要。

SOA的第一個技術與理論體系爲結構編程方法

　　所謂「結構程序設計方法」，就是基於面向對象設計方法的早期藍本，側重於解決程序正確性的編程的方法，以此爲基礎創建了軟件工程這門學科，創建了編程的基礎理論體系。

　　解決軟件開發效率的第二個基礎理論體系是「面向對象」的可重用理論

　　咱們都知道由面向對象發展到面向構件，由面向構件再發展到面向服務，所以它們的認知觀和基礎理論都是息息相關的，解決大型軟件的開發效率和質量除了要解決編程的正確性外，還必需解決開發週期長、複用性差、成本高、文檔多、以及難以適應系統演化等問題，十多年來仍舊困惑着這門學科，「軟件危機」仍未解決。

　　SOA的第三個技術與理論體系是UML統一建模語言

　　鑑於面向對象的缺陷， 三位面向對象的奠定人聯合起來，建立了UML統一建模語言。UML爲軟件開發和SOA的產生起到奠定和里程碑的做用。

　　UML主要理論成果是：①統一面向對象的基本概念，並引進了許多新的概念，②認爲軟件開發的過程實質上是從抽象的模型逐步細化，過渡到具體的實現，其中間的每一個階段都是實現了某一抽象模型，UML爲此提供了創建模型的工具，用直覺的圖形來創建模型，今後軟件專家就有了本身的工具，正如音樂家有了五線譜工具那樣；③爲適應軟件的多變性，提供了演化的概念。

　　實際上此建模理論是第三個技術與基礎理論，它爲演化到構件和架構概念奠基基礎理論模型。

　　第四個技術與基礎理論是構件架構

　　因爲這種OO方法真正用於實際工程中開發的應用軟件卻不多見到，工程上的實施缺少開發規範；在技術上要術開發人員的素質較高；最大的問題是被開發出來的軟件難以演化，而軟件要能適應變化是客觀存在的。

　　爲此發展出單純重用的「構件和架構」技術及其理論體系。在1998年日本京都召開的「基於構件的軟件開發（CBSD）」國際專題學術會議上，一致認爲軟件開發技術離不開構件和體系結構。軟件體系結構現簡稱「架構」。

　　在此以前的軟件架構都採用層次結構的架構，直到分佈式系統提出了用戶端/服務器模式後，才產生對架構的研究，出現了構件和架構。

　　分佈式系統的三層體系結構及其中間件是第五個技術與基礎理論

三層體系結構是由二層結構的胖終端中的應用構件獨立出來組成了應用層。爲解決分佈式系統中的各類潛在複雜性，提出了中間件技術及其理論。

主要標準：

SOAP: 簡單對象訪問協議 (Simple Object Access  Protocol)

WSDL: Web服務描述語言 WSDL (Web Services Description Language)

UUDI:  統一描述、發現和集成 (Universal Description,             Discovery and Integration) 

WSDL用來描述服務；UDDI用來註冊和查找服務；而SOAP，做爲傳輸層，用來在消費者和服務提供者之間傳送消息。一個消費者能夠在UDDI註冊表（registry）查找服務，取得服務的WSDL描述，而後經過SOAP來調用服務。

 

3.實際問題

1. maven問題

  1) maven settings.xml 配置有問題，致使依賴下載失敗

  2) SNAPSHO開啓。

2. dubbo

　　僅需把dubbo.properties和spring xml文件，放到classpath