iweroulsdjf

本文描述了一種面向服務的方法，用于為普及設備提供公用接口。本文用財政案例演示了如何通過關鍵 Web 服務應用程序類型，包括事務、通訊、基于位置的服務以及更多，將 Web 服務擴展到普及環境中。

引言

普及運算是信息技術的下一階段。業界分析家預言移動設備將是下一個范例轉換，并且包括 IBM 在內的供應商都在為構建普及運算應用程序大力投資，以開發最好的工具。象移動電話、PDA、尋呼機這樣的普及設備在數量上已經遠遠超過臺式機和膝上型電腦，而且趨勢正在擴大。除此還正在用嚴格的運算能力和通訊鏈接構建各種各樣的裝置，例如空氣調節系統、吸油煙機、汽車監控系統，為了在除 PC 和工作站以外的設備上構建應用程序，首先要了解在新的運算環境中的巨大投資。

在本文中，我們提出了一種面向服務的方法，用于提供獨立于設備的公用接口。該方法為普及運算環境作出了很大的貢獻。我們的目的是指出用于各種應用程序類型的獨特服務。我們將用一個財政案例來演示面向服務的體系結構 (SOA) 在普及環境中的擴展。本文首先簡要介紹了 Web 服務和普及運算環境。接著是概述部分，描述了如何通過關鍵 Web 服務應用程序類型，包括事務、通訊、基于位置的服務、同步、設備管理、數據管理和媒體應用程序，將 Web 服務擴展到普及環境中。

SOA 概述

從概念上講，SOA 是一種實現動態電子商務的體系結構。它是一種軟件系統設計方法，通過已經發布的和可發現的接口為終端用戶應用程序或其它服務提供服務。服務為封裝離散的業務功能提供了一個更好的方法，因此，服務也是開發支持業務流程應用程序的一個好方法。

圖 1. 通常的 SOA 環境

Web 服務組件

在任何面向服務的環境中都需要進行一些基本操作：

• 需要創建 Web 服務，并定義其接口和調用方法。
• 需要將 Web 服務發布到一個或更多的內聯網（Intranet）或互聯網（Internet）儲存庫中，供潛在的用戶查找。
• 需要查找 Web 服務供潛在的用戶調用。
• 無論基于什么好處都要調用 Web 服務。
• 當 Web 服務不再可用或不再需要時，需取消其發布。

圖 2. SOA 模型

服務是一個邏輯實體，其合約是由一個或多個已經發布的接口定義的。

服務提供者是一個網絡節點，它為處理一系列特定任務的軟件資源提供服務接口。服務提供者節點能代表商業實體的服務，或者它甚至能代表可重用子系統（實現服務規范的軟件實體）的服務接口。

服務請求者是一個網絡節點，它發現并調用其它的軟件服務來提供商業解決方案。服務請求者節點常常代表執行遠程過程調用分布式對象或者服務提供者的商業應用程序組件。提供者節點可能就在本地的企業內部網內，或者在遠端的因特網上。從概念上來說，SOA 本質上是將網絡、傳輸協議和安全細節留給特定的實現來處理。通常稱為 客戶端，但是，服務請求者也可以是終端用戶應用程序或別的服務。

服務定位器是一類充當注冊表的特定服務提供者，允許查找服務提供者接口和服務位置。

服務中介者是一個網絡節點，作為儲存庫、電話黃頁或票據交換所，產生由服務提供者發布的軟件接口。商業實體或者獨立的運營商能代表服務中介者。

這 3 種 SOA 參與者、服務提供者、服務中介者以及服務請求者通過 3 個基本操作： 發布、 查找、 綁定相互作用。服務提供者向服務中介者 發布服務。服務請求者通過服務中介者查找所需的服務，并綁定到這些服務上。

SOA 實現技術

SOA 實現技術包括：

• XML：可擴充標記語言 (Extensible Markup Language) 1.0 標準是一個基于文本的 World Wide Web 組織 (W3C) 規范的標記語言。與 HTML 使用標簽來描述外觀和數據不同，XML 嚴格地定義可移植的結構化數據。它可以作為定義數據描述語言的語言，例如標記語法或詞匯、交換格式和通訊協議。
• SOAP：簡單對象訪問協議 (Simple Object Access Protocol) 是一個基于 XML 的，用于在分布式環境下交換信息的輕量級協議。SOAP 在請求者和提供者對象之間定義了一個通訊協議，這樣，在面向對象編程流行的環境中，該請求對象可以在提供的對象上執行遠程方法調用。SOAP 規范是由 Microsoft、IBM、Lotus、UserLand 和 DevelopMentor 聯合制訂的。該規范隨后發展并建立了 W3C XML 協議工作組，有超過三十家公司參與其中。在大多數廠商的 SOA 實現中，SOAP 為分布式對象通訊構建了基礎。盡管 SOA 沒有定義通訊協議，但由于在 SOA 實現中的普遍使用，最近 SOAP 被稱為面向服務的架構協議 (Services-Oriented Architecture Protocol)。SOAP 的優點在于它完全和廠商無關，相對于平臺、操作系統、目標模型和編程語言可以獨立實現。另外，傳輸和語言綁定以及數據編碼的參數選擇都是由實現決定的。
• WSDL：Web 服務描述語言 (Web Services Description Language) 是一個提供描述服務 IDL 標準方法的 XML 詞匯。WSDL 是融合 NASSL (IBM) 和 SDL (Microsoft) 之間的活動產物。它為服務提供者提供了一個簡單的方法，描述遠程方法調用 (RMI) 的請求消息和響應消息的格式。WSDL 不依賴于底層的協議和編碼要求來涉及服務 IDL 這個主題。通常，WSDL 提供一種抽象的語言，利用各自的參數和數據類型來定義被發布的操作。該語言還涉及了服務的位置和綁定細節的定義。
• UDDI：統一描述、發現和集成 (Universal Description, Discovery, and Integration) 規范提供了一組公用的 SOAP API，使得服務中介得以實現。UDDI 規范是由 IBM、Microsoft 和 Ariba 制定的，促進了基于 Web 的服務的創建、描述、發現和集成。在 UDDI.org 之后的動機是為 B2B 互操作性定義一個標準。

Web 服務應用程序設計

圖 3. Web 服務標準

Web 服務通訊可以使用 XML，但它可能要傳輸二進制數據，它通常使用 SOAP 消息頭，但是不需要為消息體進行 SOAP 編碼。它可能用 HTTP 進行傳輸，但是也還可以用 SMTP 或其它的方法。為描述和發現 Web 服務，有兩種定義完好的標準：WSDL 和 UDDI。

背景及相關工作

用面向服務的方法進行運算已經引起了研究人員和業界的廣泛關注。主要目的包括用于構建軟件組件的面向服務的編程 (SOP) 和用于分布式應用程序的面向服務的體系結構 (SOA)。

SOP 引入并實施面向服務的編程，但它是面向啟用進程內和進程間通訊的軟件組件的開發的。用 SOP 開發的軟件程序可以作為多線程程序，在多線程程序中，各個線程可以通過明確定義的接口交換消息。程序的組件設計集中在為組件所提供的服務定義接口。SOP 提供的特性包括合同、組件、連接、容器和上下文。SOP 軟件應該具有聯合性、易部署性、移動性、安全性和可用性。

SOA 建立在 SOP 上來構建系統和應用程序以獲取軟件組件所提供的服務的最大限度的復用，同時要確保他們交互中的松散耦合。基本元素是服務，SOA 指定一組實體（服務提供者、服務消費者、服務注冊表、服務條款、服務代理和服務契約），這些實體詳細說明了如何提供和消費服務。遵循 SOA 觀點的系統必須要有服務，這些服務是可互操作的、獨立的、模塊化的、位置明確的、松耦合的并且可以通過網絡查找其地址。

Web 服務技術是以 SOA 概念為基礎的。該項技術直接面向企業應用程序集成，為半自動交互式和組織內部的業務流程提供了公用數據交換平臺。構成 Web 服務的技術包括 XML、UDDI、HTTP、SOAP 和 WSDL。XML 用于定義 Web 服務間消息的結構。UDDI 是可供查詢的 Web 服務資源庫。HTTP 是底層的通訊媒介。SOAP 是交換消息的容器。WSDL 用于描述 Web 服務。相關研究已經進展到涉及交互和協調性問題，雖然沒有提及或整合針對 Web 服務合成的研究，反之亦然。

Jini 是另一個主要的 SOA 目標，它已經以服務為基礎直接面向構建本地運算環境。假設設備能提供服務，并且 Jini 指定特定的特性，例如發現、結合、查找、聯合、租賃以及其它的能實現網絡部署的特性。Jini 緊密綁定到 Java ^TM 編程語言。例如，通過 Java RMI 進行通訊，以 Java 對象接口作為服務接口規范。

在普及環境中使用 SOA

下面的部分概述了普及環境中的 SOA 和 Web 服務。

普及環境簡介

普及運算方案可以看作是針對特定問題的特定解決方案，其中問題通常表現為案例。從這方面來看，他們趨向于傳統的嵌入式系統設計，只是規模更大一些，而且添加了網絡。對于嵌入式系統設計，各種方案傾向于創建自定制解決方案，這些解決方案是專有的而且缺乏可擴展性。看上去缺少的東西正好適合于編程普及運算環境。相反，各種普及運算案例似乎設想了一種軟件的無縫系統，該系統根據用戶的期望和目的運行。我們認為這種觀點既與可能越來越多的采用這種方案這個現實矛盾，又與各普及運算設備供應商無疑會擴大生產的多樣性相矛盾。因此，我們提出了一種標準的基于服務的編程環境供普及運算所采用。

普及運算是由 NIST（簡寫）為強大新興趨勢的朝向所定義的：

• 無數的、方便使用的、通常無形的運算設備
• 頻繁移動的或內嵌在環境中的
• 與日益無處不在的網絡結構連接

目的是為了使任何需要運算的地方更容易。各種研究人員已經證實了為實現這個設想，需要網絡和中間件基礎設施。這種普及基礎設施的特征包括規模、移動性和普遍存在性。這個規模將使任何現有的設施顯得太矮小。基于這一點，我們可以推斷出基礎架構必須要涉及到各種附加問題。由于故障和/或連接中斷是一個至關重要的問題，而且隨著組件數量的增加，組件發生故障的可能性也隨之擴大。即使系統不出故障，它也必須有容錯功能。在本質上，基礎架構應該是對等的，而不是客戶端/服務器端或多層的形式，但目前在中間件和構建數據網絡中通常使用的是這些形式。就因特網而言，這么大的系統能否有單獨的授權域很是值得懷疑。假設有大量能移動的授權域，還需要一些訪問者身份，既用于連接到外部網絡的移動設備，又用于他們的所有者下面的移動應用程序。因此，訪問者身份必須既要保護外部網絡的完整性又要保護移動數據的安全性。普遍存在性和可移動性意味著設備期望能一直連接到基礎設施。最后，這樣的系統能不異構很是值得懷疑。

另一方面，普及運算方案常常采用提供單一集成解決方案的方法，通常是針對特定案例或案例集的。因此，普及運算需要一個能用于編程的公用抽象，在這個抽象中各種問題都可以解決。這種抽象必須足夠強大能捕獲現有的方案，而且要足夠靈活能在普及運算內實現各種突出問題解決方案的開發。我們認為基于服務的方法可以提供這樣的抽象。該方法能為普及運算環境作出重大的貢獻。

首先，它提供了一種查看普及運算系統的方法。目前，大量關于普及運算的研究結果都是圍繞案例展開的。因此，普及運算到底是什么還不是很清楚。基于服務的方法將普及運算定義為一種無處不在的可用的服務環境。

其次，它提供了一個架構，在這個架構中可以查看現有的普及運算方案。因此，我們可以確定那些方案所缺少的特征。我們還可以以各種方案實現我們的服務視圖的方法為基礎對這些方案進行比較。

第三，我們的方法允許在無處不在的可用的服務環境中進行普及運算的增量開發。

普及運算安全性

普及運算環境依靠各種客戶端和服務器間通過不同網絡所傳輸的信息的交換。在這種設置中，由于信息要從源傳輸到目的地，通常要冒數據被攔截的危險。Web 服務事務也要冒同樣的安全性危險。在使用 SOAP 進行傳輸的 Web 服務事務中，服務調用方和服務提供方之間所傳送的數據是簡單的 XML，因此任何人攔截了該消息都能讀取所交換的數據。在 Web 服務案例中，基于以下原因，安全性方面變得更復雜：

• 可以用不同的應用程序或傳輸協議，例如 HTTP、SMTP 等來發送 SOAP 消息，這些程序或協議可能會有一些安全模型，從非常高級的模型到根本什么模型都沒有。因此，Web 服務應用程序需要一個全面的安全性架構，能適用于所有類型的傳輸協議。
• 可能有一些合法的中介需要訪問甚至修改部分或整個 SOAP 消息。因此安全性模型必須足夠全面，從而可以允許這些中介。

下面的部分定義了 Web 服務安全性的各個方面，他們可以應用于 在普及應用程序中使用 SOA中所描述的應用程序類型。

Web 服務安全性指導方針

W3C Web 服務體系結構需求概述了全面安全性架構的六個重要的安全性考慮：

• 認證保證任何有認證身份的人都可以訪問服務。
• 授權保證通過認證的人有權訪問服務或數據。
• 機密性保證請求方和提供方之間傳輸的數據不會被竊聽者竊取。
• 完整性使消息從請求方到提供方這條傳輸通道上不會被修改。
• 不可抵賴保證消息的發送者不能否認他/她稍后會及時發送消息。
• 可訪問性確保服務一直是可用的，并且不會被拒絕服務 (denial-of-service，DoS) 這樣的攻擊所削弱，無論是從托管服務系統的外部還是內部進行攻擊。

如今的 Web 服務安全性

Web 服務安全性還處在不成熟的階段。不斷地有新的標準和應用程序被開發和應用。如今，可以從兩個層面實現 Web 服務安全性：

1. 傳輸層：傳輸層的安全性利用傳輸技術的內置安全特性，例如 HTTP、IBM WebSphere MQSeries、IBM Websphere Everyplace Connection Manager 等等。
2. SOAP 或通訊層：目前正在廣泛研究該層以及例如 OASIS 這樣的安全性小組所開發的規范。這一層以及 XML 文檔層的安全性包括使用數字簽名、證書等等。

用 HTTP 保護 Web 服務

可以用下列方法保護通過 HTTP 傳輸的 Web 服務事務：

• HTTP 基本授權
• 帶安全套接層 (SSL) 的 HTTP
• HTTP 基本授權 + HTTPS

但是，HTTP 安全性沒有涉及到前面所描述的整個 Web 服務安全性指導方針。最好的可能配置是使用帶 HTTP 基本授權的 HTTPS，這樣的 HTTPS 涉及到了 Web 服務安全性中除不可抵賴和可訪問性之外其余的所有方面。

HTTP 基本授權：基本授權 (BASIC-AUTH) 是 HTTP 中所使用的一種簡單的機制。使用該機制，可以防止未授權用戶訪問 Web 資源。要使用 HTTP BASIC-AUTH 訪問受保護的資源，用戶需要提供用戶名和密碼。Web 站點系統管理員用一列合法的用戶和用戶可以訪問的資源來配置 Web 服務器。因為通過 HTTP 調用 Web 服務和訪問端點 URL 是類似的，所有可以利用 BASIC-AUTH 限制 Web 服務訪問。

HTTP 安全 (HTTPS)：安全套接層 (SSL) 是一種允許 Web 瀏覽器和 Web 服務器通過安全連接進行通信的技術。也就是說，發送的數據由一方加密，在處理之前由另一方來傳輸和解密。這是一種雙向的過程，即在發送數據之前，服務器和瀏覽器都要對所有的傳輸進行加密。

HTTP 基本授權 + HTTP 安全：為 Web 服務事務提供了極好的安全性。它還通過簽名證書為用戶提供了授權機制。但是，如果復制的證書也可用，那么任何人都可以充當代理。因此，安全性的最佳形式是結合使用 HTTP BASIC-AUTH 和 HTTPS。這既滿足了 Web 服務安全性前四個方面的要求，又為防止抵賴提供了更好的保護。在接下來的部分中，我們將說明如何配置 Web 服務應用程序來利用這種安全性方法。

在普及應用程序中使用 SOA

本文剩下的部分描述了如何用 SOA 和 Web 服務為關鍵普及應用程序類型提供公用接口。對于關鍵普及應用程序，我們主要關心的是：通信、事務、設備管理、同步、基于位置的服務、數據管理以及多媒體服務。為了幫助說明如何在這些應用程序中使用 SOA 和 Web 服務，我們將以一個財政服務為例。該案例是基于下列體系結構的：

圖 4. 常見的財政門戶體系結構

財政服務案例概述

下面的圖表演示了這里所描述的財政服務案例：

1. 新銀行客戶通過膝上型電腦簽約在線銀行，包括例如欺騙發現警告、有新的產品和在線帳單付款之類的服務。
2. 客戶決定檢查帳戶余額情況（使用膝上型電腦或智能設備）。
3. 然后客戶決定進行在線付款（使用膝上型電腦或智能設備）。
4. 客戶收到一個警告，說已經從帳戶中提取大量的金額。警告使客戶得以響應，并通過通訊或語音與銀行服務代理進行交談。
5. 客戶在他們的普及設備上使用銀行的 Web 服務客戶端在線處理事務。

圖 5. 場景 1


圖 6. 場景 2 和 3


圖 7. 場景 4


圖 8. 場景 5

用于通訊的 SOA

通訊的概念包括將消息分散給一組通過許多無線網絡和協議進行傳輸的普及設備。通訊操作的實例范圍很廣，從廣播型，例如新聞、股票報價和事件通知到個人通信型，例如尋呼機消息和即時傳送 (instant messaging，IM)。近來在無線技術，例如短信服務 (Short Message Service，SMS) 和會話發起協議 (Session Initiation Protocol，SIP)，領域中的更多進展已經提供了創新解決方案，這些方案利用了 Web 服務的功能。

應用程序需求

• IM 應用程序的無縫集成：目前在其它的一些專有提供者中存在一組相當支離破碎的 IM 服務提供者，包括 AIM、MSN 和 Yahoo。為了提高可用性和管理需要鞏固這些服務。Trillian Pro 已經通過允許用戶從單一客戶端配置和使用這些服務在桌面應用程序領域中涉及到了這個問題。通過遵循公用接口加強 IM 服務提供者這一原則在普及環境中也可以工作得很好。
• 會話管理：新近完成的 SIP 規范促進了 IM 應用程序在移動設備上的開發，代表了流行桌面 IM 應用程序和無線 SMS 系統的融合。SIP 提供會話管理支持，允許用戶從傳統的請求和響應對象中存儲和檢索數據，這些對象實際上跨越了多個 SIP 請求。有關詳細信息請參閱 JSR 180。
• 保證傳送：如今很多 IM 應用程序不能保證消息的傳送，他們是“發送并忘記”型的。在 IM 會話過程中發送給不可用的用戶的消息通常會丟失。雖然這在大多數情況下還是可以接受的，但有時可能需要保證傳送高優先級的消息。這無疑會引起更復雜的問題，包括對消息的認可以及排列或高速緩存不被認可的消息，直到用戶在線回答。
• 高級通訊：SMS，EMS，MMS
• 安全性：參閱 普及運算安全性。

如何使用 Web 服務

Web 服務充當了一個公用的、獨立于設備的接口，提供者可以從這個接口向已經訂閱的客戶端發布他們的服務。該接口也可能直接由客戶端或其它的服務調用。這個特性允許使用上面提到的 IM 集線器，在 IM 集線器中可以將各種專有 IM 服務提供者合并為一個客戶端應用程序。對于桌面應用程序領域，這樣可以提高管理的可用性和易用性。Web 服務通過調用可發現的接口滿足客戶端的需要竭力提取后端處理同樣重要。

最基本的解決方案由一個連接到設備的胖的、客戶編寫的 Web 服務客戶端組成。雖然開發這種方法需要更多的時間和精力，但是由于通過應用程序控制和表示細節給予了客戶端詳盡的責任使得該方法具有更大的靈活性。而且，各方面通常由容器來處理，包括安全性和會話管理，所以不需要涉及這些問題。

您應該注意到雖然 Web 服務技術對于桌面應用程序和企業應用程序已經很成熟了，但是還需要考慮很多額外的問題使其能適應普及設備在容量上有限這樣的局限性。例如，解析 XML/SOAP 消息就需要相當集中，尤其需要考慮處理能力。為緩和這一點， JSR 172規范將提供一個對應于 J2SE/J2EE 的更“瘦”版本。有關詳細信息請參閱 J2ME 和 Web 服務。

圖 9. 胖客戶端環境

通過允許較小的處理能力或內存，從客戶端提取后端處理增加了可用設備的實際數量。如果假設客戶端支持對 Web 接口的訪問，即通過 TCP/IP 進行通信，那么合并 portlet 集和 WebSphere Portal Server (Portal) 將是一個完美的解決方案，如下所述。通常，客戶編寫的 portlet 以及專門的可復用 Java servlet 能組成門戶頁面上的定義區，并且能訪問很多不同的應用程序、服務和 Web 內容。Portal 支持對 Web 服務后端 porlet 的部署。這使關注由 Portal 所處理的管理的開發人員自由了，并且允許開發人員將重心轉移到實現特定業務邏輯上。 有關實現的詳細信息請參閱 創建自己的 portlet 和 Web 服務和 利用 Web 服務從遠程系統中獲取數據來開發 portlet。

圖 10. WebSphere EveryPlace Connection Manager 和 Portal Server 環境

WebSphere EveryPlace Connection Manager (Connection Manager) 充當了客戶端設備和 WebSphere EveryPlace Access 服務器間的可選傳輸通道。Connection Manager 允許從后端應用程序中提取低層的詳細信息，例如無線協議，因此產生了復用和分離關注點。

Connection Manager 的通訊服務裝備啟用 Web 應用服務器與前面提到的那些普及設備進行交互。雖然通訊服務支持更流行的 SMS 和不被認可的 WAP 推傳送，但是它還啟用了很多其它的消息模式，包括通過專有網絡傳送短信、通過 SMTP 和 SNPP 發送郵件。有關詳細信息請參閱 IBM WebSphere Everyplace Connection Manager 版本 5 手冊。

Everyplace Access 充當了移動客戶端和企業環境之間的連接。Everyplace 客戶端，作為 Everyplace Access 的一個核心產品，充當了一個附屬軟件包，提供了帶更健壯設備環境的各種 PDA。它提供了取出即可用（out-of-the-box）的 IM 服務，但是，目前還只局限于 Lotus Sametime。

Everyplace Access 的另一個高級特性是智能通知服務 (Intelligent Notification Services，INS)。該服務在訂閱通知應用程序和觸發器的基礎上讓企業自動通知移動用戶。這是由 Everyplace Access 系統管理完成的，在系統管理中，用戶指定信息源、通知標準以及一些愛好和訂閱設置。更多詳細信息請參閱 WebSphere Everyplace Access 版本 4.3 開發人員手冊。

圖 11. Portal 環境

因為 Portal 被評價為是一個高可配置的、被認可的架構，因此可以利用它的很多內置功能來減少開發時間和費用。Portal 結合 Everyplace Access 通過用任何標記語言生成頁面來支持移動設備，包括用于 WAP 的官方支持的 WML。請求一個頁面時，Portal 處理后端流程來自動檢測設備類型并以適當的標記語言返回呈現頁面內容的 portlet。

財政服務案例中的通訊

在財政服務案例中，通訊為用戶帶來了更多特性和便利。例如，可以將系統基礎架構設置為當檢測到可疑的帳戶活動時，例如提取大量資金，警告用戶。正如上面所提到的，Everyplace Access 的 INS 支持基于訂閱的通知，在這種通知中，消息由用戶訂閱的特定事件觸發。

然后用戶可以通過 IM 應用程序選擇連接代理并進行通信來解決問題。由于會話的本性和重要性，可能將消息作為保證傳送，一直保留直到客戶端認可該消息。

用于事務服務的 SOA

考慮普及環境中的事務時，必須要考慮到普及環境強加在事務上的限制能夠執行。而且，由于普及環境能包含不同功能的任意數量的不同設備，所以有必要考慮如何用相同的事務來服務不同的設備和他們的功能。

對于這個問題，最明顯的回答是從客戶端提取事務普通的詳細信息。有兩種方法可以實現這一點。其一是使抽象層完全不知道哪些客戶端訪問了它。這需要客戶端足夠智能化，能捕捉并顯示適當的數據。很明顯，這指的是胖客戶端，胖客戶端能使服務面向多種客戶端，但是對每個客戶端可能有較高的 CPU 和內存需求。

使抽象層足夠智能化的另一個方法是區分請求它的服務的客戶端的不同功能。在這種情況下，每種設備的不同功能的詳細信息必須由服務提供者來說明。客戶端將被看作一種提供低 CPU 和內存需求的瘦客戶端，但是需要受服務提供者支持的有限數量的設備。

Web 服務和 SOA 能涉及提供簡單的抽象層還是智能抽象層之類的問題。下面的部分演示了這種 Web 服務如何提供所述功能。

應用程序需求

普及環境中的事務服務同樣需要考慮傳統應用程序中的事務問題，以及客戶端能運行在幾個不同類型的有著不同功能的硬件和軟件環境中。同樣的，設備可以放在任何地方，并且由于要在給定的環境中顯示信息，所以必須要注意其類型問題。下面的列表并沒有準備詳盡列出潛在的需要考慮的地方，但是考慮普及環境中事務的實現需要一個合理的開端：

1. 由于設備只能顯示一定數量的結果，因此用戶可能需要在服務器端緩存一些會話。
2. 在服務器端將事務合并為幾個集合調用，從而減少通過寶貴的低無線帶寬傳輸的網絡調用。
3. 讓服務器端執行一些復雜的排序或其它的 CPU 密集型操作。
4. 同步和異步事務之間的區別。如何實現這兩類事務？
5. 在線和離線事務。
6. 關鍵是要最大限度使用有限的在線時間。盡量最少時間，因為設備需要等待結果。這樣可以減少在線費用。
7. 發送并忘記事務。排隊等候代表設備的作業。然后當設備反方向檢查時，就能得到結果。
8. 安全性更容易受到威脅。基于顯示在這些設備上的信息種類問題，需要特別關注。例如，銀行型的事務可能允許主用戶修改他們的帳戶信息，但是用無線通信進行相同的事務可能不允許編輯功能，只有查看功能。

如何使用 Web 服務

在普及環境中有兩層可以使用 Web 服務。一是在遠程設備上實現 Web 服務客戶端，這樣將直接調用 Web 服務。該方法如下所示：

圖 12. 使用 Web 服務胖客戶端模型的普及事務

這個案例的好處是遠程設備已經完全控制了如何顯示數據。設備將知道它自己的局限性并以適合于那臺設備的方式顯示返回的數據。

這個方法還有一個好處，即允許嵌入式程序對事務進行優化。這是通過允許設備存儲大量的事務直到它認為在時間上適于發送或請求數據實現的。適當的時間可以由排隊等候的事務總量決定，或者在普及環境中網絡可能斷斷續續的可用，因此可以一直保存事務直到網絡可用。

在這里，SOA 還有一個好處，即客戶端不需要擔心調用事務的任何詳細情況。客戶端不需要擔心數據庫連接、特定的協議、專有數據格式以及不斷變化的后端系統。它所需要做的是構建 XML 并利用 Web 服務客戶端發送數據。因為這些都是開放的標準，所有能創建各種設備都能支持的單獨事務。Web 服務提供者不需要編寫特定的代碼來支持不同的設備。這也從根本上普及了事務本身，從而通過允許在各種不同設備的服務提供者間共享中央邏輯促進不同設備間數據的一致性。

財政服務案例中的事務服務

要繼續銀行實例，我們先來看一下用戶想用手持 PDA 設備在線購買商品的情況。那個設備可能有一個內置的客戶端，可以查找從銀行請求臨時信用卡數量的 Web 服務事務。客戶端然后可以使用這個信息來填充商品的購買信息。同樣地，智能電話也可以用于運行同樣的 Web 服務事務，但這時購買一罐蘇打水的信息可能是被傳送到自動售貨機的。因為有些 Web 服務客戶端可以運行在任何設備上，一個事務也可以供多個設備所用。

用于設備管理的 SOA

隨著無線設備的數量到 2006 年將達到 11,100,000， 設備管理也變得越發困難。而且，由于多媒體性能和帶寬問題不斷的嚴重，通過這些設備運行的應用程序的復雜性也無疑會增加。為了通過被部署的應用程序進行維護控制，必須要管理所有這些設備。

可以迅速的將新的特性和功能添加到移動設備中。因此，最新的、高級移動設備中的設備罷免和軟硬件的更新也變得越來越常見，多得讓網絡操作人員也感到吃驚。

應用程序需求

和一直圍繞著 LAN 和受后端防火墻保護的 PC 和服務器不同，無線設備，例如智能電話、PDA 甚至很多主流移動電話在本質上來說更難管理。他們通常既充當運營工具又充當私人生產性設備，并且很容易丟失或損壞，而且換代非常頻繁。因此，CIO 和網絡操作人員必須要認識到移動設備常遭受設備管理上下文中規則的不同設置。下面列出了一些關于設備管理應用程序 人們想要的功能：

1. 通過無線網絡 (OTA，Over The Air) 向設備發送升級包
2. 存儲、管理和提供軟件映象
3. 駐留在移動設備上的客戶端
4. 軟件部署
5. 資源和配置管理
6. 故障管理
7. 設備控制和數據安全性
8. 備份和恢復

主要區別是在移動設備上進行實現自我診斷和自我處理的能力，通過無線網絡與客戶端軟件協同工作的集中管理的、基于 Web 的控制臺，以及以帶寬和網絡連接為基礎進行更新的智能傳送。

如何使用 Web 服務

在這個案例中，設備系統管理員通過 Web 服務接口調用對所有設備的更新處理。Web 服務接口允許對任何能用 Web 瀏覽器查找設備管理服務器的客戶端的管理。更重要的是，它在所有不同設備的專有管理接口間添加了一個抽象層，允許用一個統一的接口管理所有的設備。下圖演示了這種思想：

圖 13. 通過 Web 服務和專有接口進行設備管理

通過 Web 服務提供設備管理的另一個好處是能從單一集中的位置管理包含在安全環境內的設備。所有要做的是讓每個單獨的位置包含一個啟用了 Web 應用服務器的 Web 服務，例如 WebSphere Portal Server 5.1，并通過防火墻訪問端口 80 和 443。這種情形尤其適于兩種情況：一是可能不能從公司內聯網訪問遠程辦公室，二是遠程辦公室位于內聯網中的安全子網內部。下面的圖表描述了這種情形：

圖 14. 設備管理體系結構

另一個要考慮的設備管理情形是在設備意識到它需要更新的情況下。有人可能允許專有設備接口直接由遠程設備調用。但是，這可能有很重要的含意，假設有很多不同的設備類型，并且每種都需要封裝自己的專有設備接口。這些設備接口中的每一個都必須按照企業的需要來確保他們的安全。只有一個 Web 服務供設備調用可能要更容易一些。每個設備都將傳送企業所需的適當的安全性證書請求。經過驗證和認證后，Web 服務將調用適當的專有設備接口來發送必需的更新。

財政服務案例中的設備管理

回到我們的銀行實例中，假設有一個包含銀行應用程序的 PDA。當 PDA 運行銀行應用程序時，它首先調用一個 Web 服務，檢索最新的軟件版本列表。設備用一列當前安裝的軟件和認為余額應用程序需要更新的通知與這個列表匹配。然后設備調用軟件來更新 Web 服務和安全性證書以及為標識它自身所需的信息和需要下載的軟件。Web 服務用適當的參數依次查找特定于 PDA 的軟件更新設備接口，從而標識設備并找出需要部署到那個設備的軟件的位置。在該實例中，Web 服務就設備和專有設備更新軟件間的安全性提供了一個抽象層，并指出了關于如何管理以及在哪里管理可部署的軟件。每種設備都調用相同的 Web 服務，因此企業不會受到安全性或軟件版本的干擾，并且管理計劃也是由專有設備接口提供的。

用于基于位置服務的 SOA

基于位置的服務 (Location-based services，LBS) 是為用戶提供定制內容的通道。全球定位衛星 (Global Positioning Satellite，GPS) 系統是一個提供準確用戶三角位置的測量機制。這樣的系統需要普及組件設備提供更多的功能。并不是所有的設備都有這樣的功能，因此必須通過用戶基本信息和用戶輸入來提供 LBS。最初的檢查可以通過 IP 路由和發現用戶的可能位置進行管理。

客戶端應用程序需要提供通過 Web 服務向服務器發送信息的功能，從而為客戶端提供內容，這些內容用戶可以使用。由于服務器知道用戶的位置，所以它可以向客戶端發送例如以用戶當前 GPS 位置為基礎的本地信息之類的數據。

應用程序需求

• 運行在設備上的客戶端應用程序
• 允許設備定位的可選 GPS 硬件
• 用于設備定位的可選用戶輸入或配置設置

如何使用 Web 服務

在客戶層使用 Web 服務允許在用戶指定位置的基礎上按需發現和傳送內容。Everyplace Access 服務器還有額外的功能，例如內部 UDDI 發現。盡管沒有預封裝產品也可以提供開發和功能，但是使用 Everyplace Access 可以節省時間。

考慮到普及運算的本性，LBS 必須和其它的服務一起使用，來決定是否以用戶設備為基礎將指定內容傳送給用戶。為了將內容傳送給指定的普及設備必須進行代碼轉換。例如 Everyplace Access 服務器這樣的預封裝產品有預先定義的針對各種設備的代碼轉換模板。所有的片段都能從頭進行開發，但是正如前面所提到的，這樣將需要更多的時間和精力。在設計和開發的過程中，SOA 允許公用 API 和函數提供幫助。

Everyplace Access 服務器提供了很多用于實現 LBS 的工具。Everyplace Access 中的 知道位置的服務 實現了知道位置的應用程序的快速開發和部署。為了支持知道位置的服務，Everyplace Access 提供的 API 使開發人員以標準的方式添加知道位置的 portlet。服務適配器必須由各個服務提供者編寫，從而允許在知道位置的環境中提供服務。服務適配器可以扮演很多角色，例如接口轉換、服務調用和錯誤處理以及帶服務提供者的身份驗證。根據 Everyplace Access 提供的知道位置的服務 API 所編寫的服務能夠處理通常的身份認證和其它特性，不需要開發人員對那些公用片段進行改寫。

用于 LBS 的自動售貨機案例

在快餐店自動售貨機實例中，普及設備以其位置為基礎，可以通過 Web 服務連接鄰近的服務提供者，并獲得一列可用的自動售貨機及其內容。鄰近的服務提供者可以由內容瀏覽應用程序來提供，這些內容瀏覽應用程序接受用于用戶位置的用戶輸入，或由客戶端應用程序提供，客戶端應用程序足夠智能化能發現鄰近的服務提供者并查詢可用的服務。然后用戶能夠通過瀏覽可用商品，并用他們希望的商品繼續執行自動售貨機。購買業務也可以在設備上進行，如果這項特性可用的話。服務提供方可能會列出區域周圍可用的其它服務，例如本地地圖、商店以及更多。有了多種獨特的客戶端設備和 Everyplace Access 服務器提供的帶援助的知道位置的服務，就可以定義公用服務了。Everyplace Access 服務器能處理很多常見步驟，例如認證和事務處理。如果不能處理，它會將請求向前傳送給能處理請求的服務。

財政服務案例中的 LBS

在我們的財政服務案例中，用戶能以他們當前的位置為基礎簽名，他們當前的位置是用戶輸入的或由 LBS 決定的。可能已經安裝了客戶端應用程序和設備，因此可以與服務提供者進行無縫通信。信息可以通過 Web 服務發送并以他們的位置為基礎及時向用戶提供必需的信息。Web 服務可以用于傳輸客戶端和服務提供者之間的數據，但是基于用戶的當前位置，并不是所有的服務都可以。例如，如果用戶在加油站，他們可能只能選擇財政服務案例中的選項 2，該選項是用來檢查用戶帳戶余額的。這可以結合用戶位置、用戶對應用程序的預配置設置或各種其它可能的案例來確定。這也可能是由于位置缺少服務或要冒安全危險而造成的。在幾個街區之外的別的位置中，相同的用戶可能能執行前面提到的所有情形。有關實例請參閱圖 15：

圖 15. 基于位置的案例

Everyplace Access 與 Portal Server 一起能提供例如身份驗證這樣的功能，但是，如果有必要它也能單獨實現。

用于同步服務的 SOA

同步服務可以讓用戶同步發送郵件、PIM 數據以及常用數據。設備上需要有客戶端來同步發送數據。使用 SOA 能允許通過 Web 服務以常用方式傳送客戶端和服務器之間的數據。從普及運算的角度來看，數據傳送必須考慮客戶端的性能，例如處理數據的能力、存儲量和帶寬。

設備在尺寸上可以不盡相同，這就帶來同步數據必須能適合各種類型的設備，包括進行代碼轉換向客戶端設備提供內容。Everyplace Access 服務器用大型郵件服務器提供了同步發送郵件和 PIM 數據的功能。有了 SOA 和標準，就可以擴展這樣的 Web 服務，從而為能解析這樣數據的任意類型的客戶端提供同步服務。

應用程序需求

• 能夠提供同步服務和為用戶提供有用信息的客戶端應用程序
• 帶各種存儲介質的數據存儲機制
• 確保數據合法性的數據完整性 (CRC) 機制

如何使用 Web 服務

LBS 還可以通過啟用應用程序來確定用戶的位置，然后以那個位置為基礎同步傳送特定的數據來幫助數據的同步傳送。Web 服務發現還可以用于幫助查找提供所需數據的同步服務提供者。在公司內部使用同步服務非常重要，因為這樣可以允許用戶在公司內依靠用戶的位置同步傳送所需的數據。使用 SOA 和 Web 服務的常用方面的好處在于他們允許同步傳送無限多的數據。常用的弊端是需要更長的開發時間，這是由于很多方面都沒有定義而造成的。有關實例請參閱圖 16：

圖 16. 公司內部的數據同步

假設用戶從大型商店部門出發，并希望同步發送數據，那么詳細信息也會同步發送。假設用戶進入了財政部并決定同步發送數據，那么財政數據也將同步發送。

在大型商店購物中心實例中，通常，大型商店結算過程需要預掃描商品，雖然會員們正在排隊等候。商品在無線普及設備上進行預掃描。會員登記時，收銀機服務員掃描會員的會員卡。一旦卡被掃描，系統就能拖出所有的預掃描商品，事務很快就能完成。這加快了結算過程，因為不需要在購物車間轉移商品。SOA 為無線設備和結算登記都提供了公用接口。即使大型商店有時突然決定要更新或更換設備，但是接口保持不變，而且還可能減少實現費用。

財政服務案例中的同步服務

用戶的設備可能有一個私人資金管理應用程序，這樣用戶就應該和他們的銀行提供者同步。Web 服務實現能提供同步發送用戶銀行信息的公用方法，無論是否要發送信息類型。如果用戶檢查他們的余額，會給他們提供一個選項，可以將數據下載到設備上。以客戶端設備為基礎，服務提供者能確定同步傳輸數據的數量。用戶還可以在客戶端設備上準備離線付款，并且稍后和服務提供者一起同步進行，最后當數據同步發送后，事務完成。客戶端應用程序還可以連接其它的實現了相同體系結構和數據傳輸/通訊方法的財政服務提供者。

用于媒體應用程序的 SOA

媒體應用程序特指音頻/視頻流和或回放。這些類型的應用程序可以用于員工培訓和身份驗證甚至是新聞和基于信息的服務。媒體應用程序主要關注的是客戶端設備能夠按照指定的媒體格式解碼和回放。已經有很多帶各種硬件規范的無線設備。為了支持用于媒體應用程序的所有這些設備，我們需要了解哪些類型的媒體格式可以形成流或甚至回放。Web 服務復用的完美實例是使用設備管理服務處理大多數設備。我們還必須考慮用什么協議來支持媒體格式的傳輸。例如，如果有一個商業案例需要視頻/音頻回放，我們可以安全地假設作為一種客戶端設備上的傳輸方式 SMS 消息將不被支持。

應用程序需求

• 客戶端設備上的高處理能力
• 支持流的客戶端設備
• 支持媒體格式回放

如何使用 Web 服務

下圖演示了如何在瘦客戶端設計中使用 Web 服務：

圖 17. 瘦客戶端設計

在瘦客戶端設計（也稱為客戶端/服務器端設計）中，開發人員可以假設他們支持能訪問 web 接口的客戶端設備，例如瀏覽器，因此允許他們查看 http 請求并能回放 Real Network、Quicktime、Media Player 甚至 Macromedia Flash 媒體格式。有了這個解決辦法，開發人員就不用擔心設備支持哪些協議，只需要服務提供者允許訪問因特網即可。

對于瘦客戶端設計，多數實現是由服務器端的代碼處理的，檢測客戶端設備的性能并決定用什么格式形成流甚至下載到設備上供回放。可以發現，這個解決方案與為桌面應用程序架構 Web 應用程序的客戶端/服務器端方法沒有什么不同，這是因為開發人員還需要考慮客戶端的性能。唯一的區別是現在包括了對小型存儲設備的額外檢查。

這些瘦客戶端設計中的服務器端應用程序可以是自產的，可以運行在任意的應用服務器上。記住，定制應用程序將延長開發時間并需要長期的維護費用。IBM 提供了作為 Portal Server 一部分的替代解決方案。Portal Server 已經有一個被業界認可的架構，該架構易于擴展用來支持額外的設備和容量，并有一些受支持的現成的 (out of the box) 設備。Portal Server 能否允許客戶修飾編寫的 portlet 取決于客戶端是否有這方面的請求。自產的解決方案還必須提供認證、授權、報告等等之類的功能。

在 SOA 中，定制實現和 Portal Server 都能利用 Web 服務來封裝媒體應用程序和利用現有的 Web 服務。然后，可以將其用于實現推模式設計，在這種設計中，Web 服務自己調用客戶端設備上的命令，從執行程序或想要發送廣播或目標消息的管理程序將公司廣播形成流。另外，我們可以使用訂閱和基于位置的服務來跟蹤設備。

下圖演示了一個樣本胖客戶端設計：

圖 18. 胖客戶端設計

胖客戶端設計增加了更多復雜性，例如需要一些其它的胖客戶端體系結構。有了胖客戶端，設備就能分解和組裝 Web 服務消息了。胖客戶端設計限制了能受支持設備的數量，這是由于目前在北美市場上設備性能有限。和任何其它應用程序類型類似，胖客戶端設計可以使用設備專有接口。缺點是需要在設備和應用服務器間安放相同類型的傳輸通道。

和瘦客戶端設計不同，在胖客戶端設計中，客戶端設備和服務器端（WebSphere Application Server 或 Portal Server）都需要實現。架構客戶端實現使開發人員可以選擇使用設備專有接口或調用 Web 服務從非專有設備編碼中得到好處。在媒體應用程序實例中，兩種解決方案都是可行的，因為第一個選項可以使用 SMS 通過 MMS 來請求要發送的媒體。

正如上面所提到的，例如 SMS 或 MMS 這樣的解決方案需要在客戶端設備和應用服務器間安放象 Connection Manager 這樣的傳輸通道。有了 Web 服務，就不需要 Connection Manager 和對 SMS 和 MMS 的專有調用了，取而代之的是一個能與支持 Web 服務消息的其它設備進行通信的普通接口。

財政服務案例中的媒體應用程序

在財政服務案例中，可以利用媒體應用程序來支持想為其用戶和客戶提供無能服務的客戶端。胖客戶端實現可以用于通過 Web 服務封裝基于事務服務傳輸的 VoiceXML，從而處理銀行事務。

用于數據管理應用程序的 SOA

為了向客戶提供適時信息，數據管理應用程序控制、保護并促進了數據的訪問。這些功能都是由數據庫管理系統提供的。

應用程序需求

• 針對瘦客戶端解決方案的客戶端設備上的 Web 接口
• 針對胖客戶端解決方案的 SQL 客戶端
• 常用數據的獲取、驗證、處理、存儲、檢索和顯示界面

如何使用 Web 服務

在瘦客戶端模型中，通過 Web 接口可以促進服務器端的數據管理服務。如今這種設計與典型的 web 應用程序不再有很多區別，盡管 Web 服務設計可以利用基于事務的服務和基于同步的服務執行提交和回滾來保持數據是準確和最新的。對于瘦客戶端設計，實現都是在服務器端進行的。

用于數據管理服務的胖客戶端設計有兩種解決方案。和任何其它胖客戶端解決方案一樣，Web 服務的便攜性和可復用性使其成為最簡單的解決方案。第二種解決方案需要在客戶端設備和應用服務器間安放一個工具，用于將設備上的指令進行代碼轉換從而傳送給應用服務器上的服務。

Web 服務設計還允許體系結構在數據管理實現能駐留在客戶端設備上這方面的靈活性，允許其訪問上面提到的其它服務來幫助促進作為數據管理包的一部分的事務和同步性。另一個可能的解決方案是將數據管理服務當作 Web 服務自身來實現，因此其它的需要數據管理的服務都能使用。

第二種設計要求將 DB2? Everyplace 安放在客戶端設備和應用服務器間，從而方便數據管理。有了 DB2 Everyplace，就能構建使數據管理隨處可用的 PDA 應用程序了。您的應用程序可以連接常見的 PDA，例如 Palm ^TM、Handspring ^TM、HP? Jornada、Cassiopiea ^TM以及 Compaq iPAQ ^TM 設備。DB2 Everyplace 還支持基于 EPOC 的 PDA 和帶內嵌 Linux 的設備。

財政服務案例中的數據管理

數據管理服務可以作為財政服務開發中的一個輔助工具。允許財政指令的靈活性是在客戶端還是服務器端實現依賴于安全性、數據的準確性以及其它需求，從而將數據管理封裝為 Web 服務既利于瘦客戶端設計又利用胖客戶端設計。如果使用數據管理服務是應用程序設計的中心，那么數據的分析和報告會更準確。

結束語

本文描述了如何在普遍環境中利用 SOA 為使用 Web 服務提供簡明的解決方案。本文描述了各種應用程序類型，在設計解決方案中可以使用這些類型。我們用一個財政服務樣本演示了如何在特定的情形下實現特殊的服務。最后，描述了能夠幫助使 Web 服務更便于使用的工具，例如用于應用程序的基礎設施安全性和可擴展性的網關或代理裝置。

附錄：J2ME 和 Web 服務

就目前的情況而言，在面向服務的體系結構 (SOA) 環境中，還沒有標準和有效的機制供啟用了 J2ME 的設備利用 Web 服務技術。雖然已經詳細定義了用于 J2SE 和 J2EE 領域的 Web 服務規范，但是沒有涉及到 J2ME 領域中的額外限制問題。這些限制包括要求 Web 服務技術符合平臺性能和容量要求。更明確的講，必須在運行時內存和處理需求內執行 API，并且要滿足目標設備的內存要求。此外，還必須考慮到部署環境的局限性，包括低帶寬和高延遲。

來自 Java Community Process Program 的 JSR 172試圖通過引入兩個附加包來涉及這些問題，這樣將能在啟用了 J2ME 的設備上實現 Web 服務技術。因為 XML 是消息格式的實際標準，所以即將引入的附加包主要負責優化 JAXP 和 JAX-RPC。

JAXP 為操作結構化的 XML 數據提供了必需的基本的 API。J2ME 版將包含一個為 J2SE 和 J2EE 平臺而定義的嚴格的子集。它將通過只支持起決定性的功能實現這一點，包括 SAX 解析以及對 XML 名域空間、UTF-8 和 UTF-16 編碼的支持。包括 XSLT 和其他 XML 解析的變體——如 DOM，將不被支持。之所以不支持 DOM，是由于它的實現容量和運行時的內存占用問題。

JAX-RPC 為實現來自 J2ME 基于 XML 的 RPC 通信提供了 API 和規定。再一次將它與 J2SE 和 J2EE 中的對應版本相比，可以看出不支持 SOAP 1.1 編碼，擴展類型映射和服務端點能使 JAX-RPC 得以優化。

JSR 規范，加上這種功能受限設備的最佳實踐設計模式，到底會產生什么樣的效果呢？本部分主要集中討論概念層次的問題，所有省略了實現細節。有關下列模式的進一步描述和實現細節，請參閱 James Noble、Charles Weir 和 Duane Bibby 撰寫的 小型存儲軟件：存儲受限系統的模式。

Web 服務客戶端案例

SAAJ

客戶端通過 SAAJ 與 Web 服務通信包括幾個過程。首先，它必須程式化的創建一個消息，并依照 DTD 強制規定的預定義格式添加內容。然后，獲得一個 SOAPConnection 對象，發送消息，收到響應消息后阻塞。

• 處理：打包：將應用分成包，只有當需要某個包時，才加載它。
• DTD：資源文件：在二級存儲器中保存配置數據，根據需要加載和釋放數據條目。
• 連接工具：只讀存儲器：在只讀存儲器中保存只讀代碼和數據。
• 響應消息：數據文件：每次處理少量的數據，把其余的保存在二級存儲器中。壓縮數據：在結構內部壓縮數據條目，以使它們占用最小的空間。

JAXR

同預定的方案（如在 SAAJ 中）相比，客戶端可以選擇向 Java WSDP 注冊服務器 (Java WSDP Registry Server searching) 動態發送查詢請求，通過 JAXR 查詢支持 JAX-RPC 的 Web 服務。它必須首先通過查找連接工廠建立一個連接，設置連接屬性，獲得 RegistryServiceObject 對象。利用 RegistryServiceObject 對象，然后客戶端能夠用相應的 BusinessQueryManager 方法進行查詢，例如 findOrganizations、findServices 和 findServiceBindings。這些方法返回 BulkResponse——一個對象集。要想進行優化，客戶端可以選擇緩存和創建一個發行人的本地數據庫。

• 處理：打包：將應用分成包，只有當需要某個包時，才加載它。
• 連接工具：只讀存儲器：在只讀存儲器中保存只讀代碼和數據。
• BulkResponse：數據文件：數據文件：每次處理少量的數據，把其余的保存在二級存儲器中。壓縮數據：在結構內部壓縮數據條目，以使它們占用最小的空間。
• 緩存：共享：一次保存數據，在任何需要的地方共享。

JAX-RPC

一旦通過 JAXR 構建了相關的 Web 服務資源庫，客戶端就能夠通過 JAX-RPC 執行業務邏輯。實現此功能的方法之一是創建靜態存根或動態代理。更常見的是，結果以 Java Bean 集返回。以前，客戶端首先創建存根對象，設置存根的端點地址來訪問特殊的服務，并且向服務器端點接口投擲存根。

創建動態代理時，客戶端創建一個服務對象，該服務對象帶有一個 ServiceFactory 和兩個參數：WSDL 文件的 URL 地址 和 Qname（受 XML 限制的名稱）。然后創建一個服務端點接口型的代理。

• 處理：打包：將程序分成包，只有當需要某個包時，才加載它。
• 存根/代理工具：只讀存儲器：在只讀存儲器中保存只讀代碼和數據。
• 參數/結果集：數據文件：數據文件：每次處理少量的數據，把其余的保存在二級存儲器中。壓縮數據：在結構內部壓縮數據條目，以使它們占用最小的空間。

通用 J2ME 應用程序設計模式

• JavaBeans：
  • 壓縮數據：在結構內部壓縮數據條目，以使它們占用最小的空間。
• 接口：
  • 小型接口：設計接口讓客戶端控制數據傳輸。
• 屬性文件：
  • 資源文件：在二級存儲器中保存配置數據，根據需要加載和釋放條目。
• 內存使用情況：
  • 應用程序轉換：將您的系統分為獨立的執行部分，一次只執行其中的一個。
  • 內存限制：為每個組件限制它能夠使用的最大內存，當超過界限時擇存儲單元分配失敗。
  • Captain Oates：寧可為不太重要的組件犧牲內存，也不能讓重要的任務出現故障。
  • 局部故障：確保內存溢出時，系統總是處于安全狀態。
  • 存儲單元分配池：對于類似對象，預分配一個對象池，并回收無用的對象。
• 存儲器：
  • 壓縮數據：在結構內部壓縮數據條目，以使它們占用最小的空間。
  • 壓縮：在內存中移動對象，來移除它們之間無用的空間。
  • 自適應壓縮算法。