如何在基於面向服務架構設計的項目中應用WebService技術(上篇)

2020-12-02 楊教授工作室

軟體項目實訓及課程設計指導——如何在基於面向服務系統架構設計的項目中應用Web Service技術(上篇)

1、了解軟體系統開發人員所能夠獲得的各種層次的功能服務及所存在的問題

(1)計算機作業系統中所提供的「Service」(服務)

個人計算機軟體的發展早期是基於微軟DOS作業系統的,在早期DOS作業系統中就提供有「中斷服務」的概念和有關的API,允許應用程式直接調用DOS作業系統所提供的中斷服務程序而獲得DOS作業系統中的各種功能(服務)。

隨著個人計算機作業系統從DOS平臺進入到微軟Windows圖形界面的系統平臺,Windows作業系統仍然繼續為PC應用程式提供服務支持,而形成「Window Service」的概念(如開發人員利用VC++訪問Window系統API)。

(2)某種程式語言中所提供的API服務

軟體應用系統的開發人員在應用某種程式語言開發相關的軟體程序時,在該語言中一般也會提供語言級別的API服務。如Java語言中的JDK、C/C++語言中的API庫等形式。如下示圖為JDK API系統庫的幫助文檔的局部截圖,Java程式設計師在開發軟體系統項目時一般都會隨時查閱這個幫助文檔中的相關類、方法及接口等說明信息。

(3)某種開發平臺中所提供的組件服務

在微軟的技術平臺中,提供有COM/DCOM組件;而在Sun J2EE技術平臺中提供有EJB組件。它們都是平臺級別的組件服務。軟體系統的開發人員在應用系統程序的設計和開發實現中,充分地應用這些平臺級別的組件服務,能夠大大地簡化軟體系統的開發工作量和提高軟體系統的可靠性。

儘管在軟體開發中,從作業系統底層乃至開發平臺的高層都提供有不同層次的功能服務,但這些功能服務都存在有一定的限制或者應用要求——作業系統中所提供的各種系統服務只適用該作業系統中運行的各種應用程式,而某種程式語言中所提供的API服務也只適用基於本語言編程實現的各種源程序代碼之間,而開發平臺中所提供的組件服務也同樣只適用該開發平臺,如在J2EE平臺下的程序不能直接獲得微軟的COM/DCOM組件所提高的功能服務,反之也一樣(在微軟的COM/DCOM組件中也不能直接獲得J2EE平臺下的EJB組件所提供的功能服務)!

2、Web Service技術是面向對象/面向組件技術在Internet環境中的進一步延伸

(1)Web Service是面向對象/面向組件技術在Internet中的延伸

Web Service是一種新型的Web應用程式,它們是自包含、自描述、模塊化的應用程式,可以在Web環境(包括企業內部網Intranet和廣域網Internet)中被描述、發布、查找以及通過Web方式來調用其它的Web服務組件。

從這個角度來看,Web Service組件技術其實是面向對象開發技術和更高級別的面向組件開發技術在Intranet/Internet環境中的進一步延伸和擴展。

(2)Web Service從本質上講是放置於Web站點上的可重用組件

WebService組件是分布式和模塊化組件,每個組件本身能夠完成特定的業務功能或者服務、並且遵守WebService技術規範(WS標準),這些WebService技術規範保證Web Service組件之間能夠進行互操作。

作者註:

分布式系統是由一組通過網絡進行通信、為了完成共同的任務而協調工作的計算機節點組成的系統。

(3)Web Services是對諸如RMI、COM和CORBA等現有面向服務的技術的擴展

但Web Services技術目前是一套標準的平臺技術,它定義了Web服務組件如何在Web級別的平臺上實現互操作和在不同的平臺下的應用協同。

由於Web Service技術是採用簡單對象訪問協議(SOAP)進行數據通訊,而SOAP的下層協議仍然為超文本傳輸協議(Http,Hypertext Transfer Protocol)。因此,基於Web Services技術實現的各種服務組件可以是在現有的各種平臺組件的技術基礎上進一步功能擴展和升級完善。

這為企業應用Web Service技術降低了技術應用的成本!因為基於Http協議的網絡已經普及和廣泛地應用了。

3、Web Service技術與微軟的COM組件和Sun的J2EE EJB組件技術不同點

(1)微軟COM組件和Sun J2EE EJB組件協議是基於特定技術平臺

微軟COM/DCOM/COM+組件技術平臺下的客戶端和其伺服器端程序之間相互通訊採用的是基於微軟Windows系統中特有的COM協議——COM協議是微軟公司定義的用於對象、應用程式之間交互功能的標準協議。

而Sun(現為Oracle公司)的J2EE EJB組件技術平臺下的客戶端和其伺服器端程序之間相互通訊採用的是RMI-IIOP協議——RMI-IIOP是基於Internet ORB間協議的Java遠程方法調用,是J2EE標準體系中實現分布式對象的相互通信的標準。

如下示例圖的左邊為微軟的DNA架構體系工作原理示圖(DNA是指Windows Distributed Internet Application Architecture,也就是「Windows分布式應用結構」的含義),而右邊代表J2EE三層架構的工作原理示圖。

由於微軟的COM協議和J2EE的RMI-IIOP協議一方面都是某個特定的技術平臺下特有的專用協議,另一方面它們都採用二進位格式的數據作為網絡協議,這樣將無法穿越企業網絡系統的防火牆——組件的客戶端無法在企業網絡的外部對部署在企業內部的伺服器端中的組件進行訪問以獲得相關的功能服務。

(2)Web Service技術組件之間的協議是跨平臺的XML技術標準

Web Service核心技術基礎是可擴展標記語言XML,其相關標準協議包括服務調用協議SOAP、服務描述語言WSDL以及服務註冊檢索訪問標準UDDI等都是基於XML標準的。這將保證Web Service組件能夠適應「異構的企業應用環境」和「不斷變化的企業需求」。

另外,也為企業推廣「移動辦公」和跨地區(包括跨國)、跨行業的「遠程訪問」和「業務協同」提供了技術實現的可能性。因為XML是文本格式,基於XML格式的交互消息可以穿越企業網絡系統的防火牆——組件的客戶端可以在企業網絡的外部對部署在企業內部的伺服器端中的組件進行訪問以獲得相關的功能服務。

4、Web Services組件的客戶端和伺服器端組件的請求和響應過程

(1)Web Services組件客戶程序通過網絡並利用SOAP協議向Web Services服務組件所在的應用程式伺服器發出SOAP消息的請求,該請求中的URI中包含有該伺服器識別和被調用的具體Web Services組件的標識。請參考下圖所示的過程說明圖。

(2)支持Web Services技術的伺服器讀取SOAP請求消息,並且識別它需要調用的目標組件中的方法。

(3)伺服器進一步解析SOAP請求消息以獲得請求參數、並對客戶端傳遞來的請求參數實現從XML到Java之間的轉換(利用對象反序列化技術實現)。

(4)然後再對目標組件中的請求方法進行調用,並向目標方法傳遞由客戶端通過SOAP請求消息傳遞來的調用參數。

(5)目標組件中的請求方法被調用完畢之後,後端Web服務功能組件返迴響應的結果,由Web Services伺服器使用合適的序列化類將該響應從Java數據類型再轉換為XML數據類型(利用對象序列化技術實現),然後再將它打包為SOAP消息響應向客戶端調用者返送。

整個請求響應的過程請見上圖示例圖所示,根據Web Service的請求響應的過程也可以了解到Web Service體系架構中存在有三個不同的角色。

(1)服務提供者

從業務角度看,它是服務的擁有者;而從系統體系看,它是訪問服務的平臺。

(2)服務請求者

從業務角度看,它是請求特定功能的業務;而從系統體系看,它是尋找並調用服務或啟動與服務交互的應用。服務請求者可以是基於B/S系統的Web程序或者是基於GUI圖形用戶界面的應用程式實現。

(3)服務註冊中心

是一個可搜索的註冊器,服務提供者將服務描述發布其中,服務請求者查找服務並獲取綁定信息的工作。

5、應用Web服務組件技術的開發實現過程

(1)Web服務組件開發者的工作內容

主要涉及設計和編程需要發布為Web服務的業務功能組件,並向WebService伺服器的註冊中心提供本WebService服務方法的說明信息——這可以利用WSDL來描述本WebService組件中的Web服務方法。

當然,為了使WebService的客戶端程序(Web服務的請求者)能夠找到和了解本Web服務組件,需要對本Web服務組件進行註冊——這同樣也是利用WSDL來描述本WebService組件有關的信息。

(2)Web服務組件使用者的工作內容

Web服務組件使用者(Web服務客戶)從Web服務組件所在的WebService伺服器的註冊中心中搜尋和發現所需要訪問的目標Web服務組件——這要利用統一描述、發現和集成協議UDDI(UDDI, Universal Description Discovery and Integration,它是一套基於Web的、分布式的、為Web Service提供的、信息註冊中心的實現標準規範而且也是基於XML標準)。

成功找到後,然後使用Web服務組件中的目標方法、並獲得目標方法的返回結果——這仍然要應用SOAP協議進行通訊和描述返回的信息。

(3)MyEclipse開發工具全面地提供了對開發WebService的技術支持

Java平臺的開發人員可以藉助於MyEclipse IDE開發工具開發實現WebService組件、包括發布Web服務等,大大地簡化了開發過程,並提高了開發效率。而且提供了對JAX-RS和JAX-WS兩種不同風格的WebService框架的支持。如下示圖為在MyEclipse IDE開發工具創建WebService項目的界面局部截圖。

相關焦點

  • 什麼才是真正的架構設計?
    系統協作關係:各個組成部分如何協作來實現業務請求。約束規範和指導原則:保證系統有序,高效、穩定運行。因此架構師具備能力:理解業務,全局把控,選擇合適技術,解決關鍵問題、指導研發落地實施。架構的本質就是對系統進行有序化地重構以致符合當前業務的發展,並可以快速擴展。那什麼樣的系統要考慮做架構設計 技術不會平白無故的出和自驅動發展起來,而架構的發展和需求是基於業務的驅動。
  • 在軟體系統設計中如何降低軟體系統中程序類之間耦合關係(上篇)
    軟體項目實訓及課程設計指導——如何降低軟體系統中程序類之間耦合關係(上篇)1、分離軟體應用系統中各個模塊類的接口定義和對應接口的具體功能實現面向對象程序類設計的五大原則中的「開放-封閉原則」 ( OCP,Open-Close Principle)倡導分離接口的定義和接口的具體功能實現的設計原則
  • 如何合理地設計軟體應用系統中數據訪問服務層內的各個功能程序類
    軟體項目實訓及課程設計指導——如何合理地設計數據訪問服務層中的各個功能程序類作者已經在本系列文章《軟體項目實訓及課程設計指導--如何正確地設計J2EE應用系統持久層中的各個組件結構及關係》中為讀者介紹了為什麼要設計和應用數據訪問服務接口的目的及如何設計該接口以真正達到利用數據訪問服務層組件隔離業務處理邏輯和數據訪問操作邏輯的應用效果
  • 如何正確地應用Web MVC架構模式分離表示層和模型處理層耦合關係
    軟體項目實訓及課程設計指導——如何正確地應用Web MVC架構模式分離表示層和模型處理層耦合關係1、MVC體系架構設計模式是用來幫助系統設計人員控制「變化」的一種設計模式MVC體系架構設計模式是上世紀80年代在Smalltalk-80中出現的一種軟體設計模式
  • 盤點面向物聯網的21個開源軟體項目
    DSA  分布式服務架構(DSA)便於去中心化的設備互通、邏輯和應用程式。DSA項目正在構建分布式服務鏈路(DSLinks)庫,以便支持協議轉換、與第三方數據源整合數據。DSA提供一種可擴展的網絡拓撲結構,這種拓撲結構包括在連接到分層代理層次體系的物聯網邊緣設備上運行的多個DSLinks。
  • 基於Yocto Project的嵌入式應用設計
    本設計主要基於Yocto Project在嵌入式設備上輕鬆定製嵌入式Linux應用,並實現Yocto Project的定製過程。Yocto Project提供基於社區測試的支持多種架構的鏡像。Yocto Project的優點如下:具有高質量的構建系統,平等地支持所有主流的嵌入式架構(ARM、Power PC、MIPS、x86(32&64位)),緊密跟蹤許多上遊開源項目的最新發布版本,具有統一的Linux BSP格式和應用程式開發套件,還可輕鬆地實現從原型切換到商用嵌入式Linux產品。
  • 基於容器雲的微服務架構實踐
    微服務架構(Microservices Architecture)是一種架構風格(Architectural Style)和設計模式,提倡將應用分割成一系列細小的服務,每個服務專注於單一業務功能,運行於獨立的進程中,服務之間邊界清晰,採用輕量級通信機制(如HTTP/REST)相互溝通、配合來實現完整的應用,滿足業務和用戶的需求。
  • 架構師必須知道的架構設計原則
    寫在前面 如果一個技術已經存在 2 年,比如現在很火的前端技術 react 和 vue 等,那麼我能預估這個技術大致還有 2 年的生命期,再久就不確定了;如果一個架構或設計原則已經存在 15 年,例如單一職責和依賴倒置原則,我可以預期它還有 15 年甚至更久的生命期。原則是比具體技術更抽象,更接近事物本質,也更經得起時間考驗的東西。
  • 如何應用數據訪問服務層分離系統中的業務層和持久層之間耦合關係
    軟體項目實訓及課程設計指導——如何應用數據訪問服務層分離業務層和持久層之間耦合關係作者已經在本系列文章《軟體項目實訓及課程設計指導--如何正確地設計J2EE應用系統持久層中的各個組件結構及關係》中為讀者介紹了為什麼要設計和應用數據訪問服務接口的目的及如何設計該接口以真正達到利用數據訪問服務層組件隔離業務處理邏輯和數據訪問操作邏輯的應用效果
  • 架構設計:業務邏輯和技術分離
    例如,阿里巴巴在沒有中臺部門之前,每個業務部門的技術架構都是煙囪式的,淘寶、天貓、飛豬、1688 等各有一套體系結構。而後,成立了共享平臺事業部,打通了帳號、商品、訂單等體系,讓商業基礎實施的復用成為可能。 應用架構:由應用架構師負責,他需要根據業務場景的需要,設計應用的層次結構,制定應用規範、定義接口和數據交互協議等。
  • DevOps 核心能力:技術篇——架構
    如上表所示,支持精簡產品開發工作的單體式架構(例如,快速設計新功能原型、潛在策略變化或重大策略變化)不同於需要數百個開發者團隊的架構,這些團隊必須能夠獨立為客戶帶來價值。通過允許架構不斷演進,您可以確保架構始終能夠滿足組織的當前需求。無論原型如何,在設計架構以便於持續交付的過程中,團隊都必須有能力實現本文檔簡介中所述的功能。
  • 基於iBeacon定位技術的智慧圖書館
    編者按:  摘要:本項目遵循物聯網技術架構,設計了智慧圖書館整體解決方案。它以iBeacon室內定位、3D實境、移動網際網路、SaaS等技術為基礎,實現了圖書館場景下的智能定位與導航服務、圖書館增強現實位置服務、3D運行監管、角色個性化服務等功能。
  • 基於面向5G城域光傳送網綜合承載架構以及城域OTN/WDM組網方案介紹
    基於綜合業務的承載需求,本文將從面向5G的城域光傳送網綜合承載架構,以及對城域OTN/WDM組網方案進行探討。 面向5G的城域光傳送網綜合承載架構 面向5G的城域光傳送網綜合承載架構如圖1所示,包括轉發層和控制管理層。
  • 15 年架構設計經驗:我眼中的那些優秀架構師
    去年底,我曾經面試過一位架構師的候選人。這位候選人是一位大廠高級工程師,因為技術好,在團隊中承擔一些管理工作。從他簡歷上的項目經驗,我能看出他的編程能力和技術深度都屬於優秀行列,在某些項目上,已經承擔了一部分架構設計職責,是個潛力型人選。
  • 什麼是微內核架構設計?
    阿里妹導讀:作為一名Java程式設計師,相信同學們都聽說過微內核架構設計,也有自己的理解。那麼微內核是如何被提出來的?微內核在作業系統內核的設計中又有什麼作用?本文從插件化(Plug-in)架構的角度來詮釋微內核架構設計,通過微內核架構和微服務架構的對比,分享其對微服務設計的參考意義。
  • 民生銀行大數據體系架構設計與演進
    :   銀行有很多面向客戶的數據,數據積累非常快也非常多,以流水數據為例,為了保證系統服務質量,通常是縮短可查詢的周期,依託大數據的海量數據存儲能力,基於分布式體系構建了歷史數據管理平臺來滿足業務場景中海量數據的存儲和查詢服務需求。
  • 八種常見的業務設計和架構模型
    為了推斷這些策略和目標,有許多業務模型用於業務設計。我們將研究八種最常見的業務設計方法並研究每種方法如何與企業架構息息相關。這些重要活動可以分為兩種,要麼是財務活動、面向客戶的活動、面向內部業務流程的活動,要麼涉及到學習和發展。 這種業務設計方法通常在更傳統的組織中使用,在公司或業務部門的級別得以應用。平衡計分卡使項目和計劃與組織戰略高度一致。它還可以改善關鍵活動的績效報告。
  • 從企業架構到信息化規劃,從現狀調研到架構設計的核心邏輯
    整體規劃方法論IT規劃涉及到諮詢方法論、流程管理和分析、信息架構、應用系統分析和設計、技術架構、項目管理和實施等眾多方面的內容。從企業戰略到業務目標,從業務目標到IT目標,從IT目標到應用藍圖,從應用藍圖到分階段實施落地,任何一個步驟的脫節將導致規劃內容無法落地。
  • 分布式架構概述
    分布式架構是一個非常複雜的體系,任何技術都不是孤立的存在,任何技術都無法適應所有場景。作為一名分布式系統架構或者資深研發人員,我們必須儘可能多的學習與之相關的各種知識,掌握各種技術的演進路線,正式從一名碼農蛻變成為架構師什麼是分布式?網際網路應用的特點是:高並發,海量數據。
  • 馬蜂窩數據中臺起步建設:數倉的架構、模型與應用
    它是在企業的數據建設經歷了數據中心、數據倉庫等積累之後,藉助平臺化的思路,將數據更好地進行整合與統一,以組件化的方式實現靈活的數據加工與應用,以更清晰的數據職能組織應對業務的快速變化,以服務的方式更好地釋放數據價值的一種方式。所以,數據中臺更多的是體現一種管理思路和架構組織上的變革。