熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java核心技術 >> 正文

設計移動Web服務需要考慮的三個設計層次

2013-11-23 18:50:55  來源: Java核心技術 
      從何時選擇移動 Web 服務到總體設計指導原則再到用於移動 Web 服務的值類型本文提出了在設計用於移動設備的 Web 服務時需要考慮的許多設計事項文中還介紹了許多設計移動 Web 服務方面的最佳實踐從本文中您可以了解如何決定何時使用 Web 服務在設計 Web 服務時需要考慮什麼事項以及在規劃移動 Web 服務時必須謹記哪些問題

  Web 服務是一種集成技術在集成異構系統時 Web 服務的價值可以得到最好的證明因為其支持許多類型的編程語言運行時環境和網絡當需要從不兼容的環境連接應用程序時Web 服務就有了用武之地通過 Web 服務您可以將業務應用程序從 Java&#; Platform Enterprise Edition (JEE) 連接到 NET您還可以使用某個運行在 Linux&#; 中的應用程序將一個應用程序集成在 Windows&#; 操作環境中在本文中我提供了一些針對移動 Web 服務的重要設計考慮事項並且向您介紹了一些與之有關的最佳實踐

  首先我將討論在開始之前 需要考慮哪些事項

  開始之前

  在開始設計整個系統的體系結構之前您必須做出如下決定——何時使用移動 Web 服務以及何時不使用移動 Web 服務

  對於移動設備Web 服務是利用工作站的強大計算功能的一種最佳方式Java Specification Request (JSR) 定義了用於 Java Platform Micro Edition (JME) 平台的 Web 服務 API由於移動服務主要從客戶端的角度進行編程並且是服務使用者因此本文只需要介紹一部分遠程服務調用 API (JAXRPC) 和 JAXP (Java API for XML Parsing)

  設計移動 Web 服務的主要目的在於使嵌入式設備能夠使用由服務器提供的服務換句話說移動 Web 服務是從 Web 服務使用者的角度進行設計的目的在於支持輕量級設備共享服務器的計算功能和數據庫

  移動 Web 服務無縫地集成了運行在不同平台上的兩種不同的應用程序並且提供了它們之間的互操作性通常在考慮移動設備的參與時有三種類型的集成技術可以運用


套接字通信
Web 服務
消息傳遞技術(如 WebSphere® MQ Everyplace)

  與套接字通信和消息傳遞技術相比Web 服務有一些突出的優勢Web 服務使用可擴展標記語言 (XML) 來傳輸消息(包括結構良好的數據信息)使用簡單對象訪問協議 (SOAP) 來傳輸對象如果您使用的是套接字通信則必須完全負責定義要傳輸的數據結構而且如果客戶端和服務器是用不同的編程語言編寫的(例如 C++ 和 Java 編程語言)則您的工作量將大大增加——您必須負責數據傳輸和 C++ 和 Java 編程中的編碼細節

  消息傳遞軟件可能是一種解決方案但如果您所關注的是性能並且不擔心事務和安全級別則消息傳遞軟件真的不是一個非常好的選擇如果使用消息傳遞軟件您將花大量的時間和精力解決安全問題並且您的客戶很有可能站在您的門口問為什麼這麼慢?

  我不准備告訴您正確的選擇應該是什麼而給出一些理由來說明為什麼 Web 服務可能是一個好的選擇

  其中的一個理由可能是服務器端編程即使是像 Web 服務這樣好的機制也仍然由於 XML 處理以及傳輸和接收 SOAP 消息的開銷的原因而不能滿足嚴格的實時處理需求因此在設計時需要考慮兩個問題


與普通的 HTTP 訪問和專用的消息傳遞方法相比每次 Web 服務調用的開銷都比較大所以當您主要考慮性能時您可能需要首先選擇另一項技術
由於開銷的原因如果您只需要在應用程序的各層之間進行通信就不必選擇 Web 服務例如不要將 Web 服務放在應用程序的視圖層和控制器層之間

  現在我假定您已經決定使用 Web 服務那麼在總體設計方面需要考慮哪些問題?

在決定使用 Web 服務之後

  您需要考慮的下一個問題是 Web 服務的總體設計可以運用下列通用設計指導原則


管理 Web 服務的粒度
首先定義 Web 服務接口然後加以實現
使用 Document/literal 作為編碼樣式
優先選擇 JavaBean 組件而不是 Enterprise JavaBean (EJB) 組件作為服務提供者
避免 XML 元素嵌套太深因為這可能大大延長解析封送處理和取消封送處理的時間

  下面詳細介紹這些設計考慮事項

  管理 Web 服務粒度

  關於粒度管理需要謹記以下幾點


始終優先考慮粗粒度的 Web 服務決不要在分布式系統之間使用細粒度 Web 服務調用
Web 服務是一個很好的工具集但是當您以細粒度的方式使用 Web 服務時它可能對應用程序的性能有很大的影響因為 XML 解析序列化和反序列化的開銷很高這種開銷可能占處理時間的百分之三十

  在本文中我以 Task Management 系統中的登錄功能為例驅動程序首先登錄到系統如果登錄成功則有兩列任務顯示在屏幕上

  對於此登錄問題有兩種解決方案


一種解決方案是首先調用登錄方法然後當該方法調用返回 true 時調用一個方法來獲取相應的任務
其他的事情將在一步中完成如果驅動程序登錄到 Task Management 系統則返回驅動程序的角色以及分配的任務和啟動的任務如果登錄失敗則返回指示驅動程序未登錄到該系統的信息

  對於第一種解決方案它是細粒度登錄系統而顯示任務列表需要兩次調用 Web 服務這可能帶來很大的延遲第二種解決方案是粗粒度登錄系統它返回您在一次調用中需要的所有信息並確保由於網絡延遲和系統 I/O 帶來的影響最小

  首先定義 Web 服務接口然後進行實現

  這不僅從移動 Web 服務的角度來看是適用的而且從 Web 服務設計和(更高的層次)面向對象的軟件設計來看也是適用的正如您所知道的接口是客戶端和服務提供程序之間的契約而且保持穩定非常重要(因為正如您所知道的實現容易改變)

  定義功能接口非常直接和直觀——只需考慮


您的目標
您需要獲取什麼信息
您需要將何種結果返回到客戶端

  然後您應該將該接口的相關要點寫下來並在這些要點的指導下完成所有實現細節

  這是一條簡單的設計指導原則了解您的目標非常重要目標可以驅動您編寫測試用例並且指導您編寫功能實現這也是為什麼測試驅動開發 (TDD) 廣泛地應用於各種開發技術的原因

  使用 Document/literal 作為編碼樣式

  目前JAXRPC 支持三種操作模式


RPC/encoded其優點在於簡單接收方可以輕松地將消息發送到操作的實現其缺點在於類型編碼信息的開銷較大這會降低吞吐量性能
RPC/literal其優點與 RPC/encoded 相同而且 遵循 WSI 組織制定的規范
Document/literal其優點在於沒有類型編碼信息任何 XML 驗證器都可以驗證消息其缺點在於 SOAP 消息中缺少操作名所以發送消息很難甚至不可能

  在一些資料中您還可能發現名為 Document/encoded(使用這種模式的人不多)和 Document/literal wrapped(由 Microsoft 定義但是沒有相關規范其缺點在於比其他模式復雜)的模式對這些操作模式的詳細解釋可以在參考資料中的Which style of WSDL should I use?內找到

  在這些模式中WSI 標准僅支持 RPC/literal 和 Document/literal對於移動 Web 服務JAXRPC 實現必須使用 Document/literal 將基於 Web 服務描述語言 (WSDL) 的服務描述映射到相應的 Java 表示形式因此如果您只使用 Document/literal 作為編碼樣式則您是最安全的

  優先選擇 JavaBeanser 組件而不是 EJB 組件作為服務提供程序

  在使用 Java 編程語言公開服務時需要考慮兩種類型的服務提供程序


從 JavaBean 組件生成 Web 服務
使用無狀態會話 EJB 組件

  雖然在某些情況下EJB 組件非常有用但是 JavaBeans 組件常常是更好的選擇特別是在開發移動 Web 服務時實現使用 JavaBean 組件生成的服務提供程序比較簡單和容易而且與相應的會話 EJB 組件相比JavaBean 組件更穩定但是如果您需要從使用 EJB 組件開發的現有 JEE 應用程序公開 Web 服務則請使用 EJB 組件

  避免 XML 元素嵌套太深

  如果數組的數組復雜類型的數組或包含另一個自定義復雜類型的復雜類型等嵌套太深則將大大影響 Web 服務的性能清單 顯示一個 XML 描述示例——一個自定義數據類型 Task 類的數組

清單 自定義數據類型

  

  import javaioSerializable; public class Task implements Serializable { /** * The id of the task */ private int taskID = ; /** * Owner name of the task */ private String ownerName; /** * public default nonargument constructor * */ public Task() { } /** * Constructor of the Task class * * @param taskID * id of the task * @param ownerName * owner name of the task */ public Task(int taskID String ownerName) { thistaskID = taskID; thisownerName = ownerName; } /** * @return Returns the ownerName */ public String getOwnerName() { return ownerName; } /** * @param ownerName * The ownerName to set */ public void setOwnerName(String ownerName) { thisownerName = ownerName; } /** * @return Returns the taskID */ public int getTaskID() { return taskID; } /** * @param taskID The taskID to set */ public void setTaskID(int taskID) { thistaskID = taskID; } }

  如果一個方法返回如 清單 中定義的 Task 的數組則該方法的源代碼包含在下面的清單中方法 getTasks() 返回一個由五個 Task 對象組成的數組如清單 所示

清單 返回自定義數據類型的數組的方法


  

  public Task[] getTasks(String name){ Task[] tasks = new Task[]; for(int i=; i<; i++){ tasks[i] = new Task(i name); } return tasks; }

  當使用 getTasks()(如清單 所示)所屬的 JavaBean 組件公開 Web 服務時Task 類映射到其中包含 Task 類的名稱空間的 tn:Task

清單 WSDL 定義中的 XML 數據類型

  

  <complexType name=Task> <sequence <element name=ownerName nillable=true type=xsd:string/> <element name=taskID type=xsd:int/> </sequence> </complexType>

  同時數據類型 Task[] 映射到 ArrayOf_tn_TaskArrayOf_tn_Task 的 XML 描述如清單 所示

清單 ArrayOf_tn_Task 的 XML 描述

  

  <complexType name=ArrayOf_tns_Task> <sequence> <element maxOccurs=unbounded minOccurs= name=Task nillable=true type=tns:Task/> </sequence> </complexType>

  如清單 所示為單個自定義復雜類型數組生成的 XML 描述很長相反Java 語言中的單個 String 類型映射到 xsd:string而沒有生成 complexType 元素諸如 booleanint 和 byte 這樣的基元類型分別映射到 xsd:booleanxsd:int 和 xsd:byte

  您可能已經注意到 XML 元素的嵌套(避免嵌套太深)和粒度考慮(使用粗粒度)之間的沖突在實際運用中嵌套和粒度之間應該有一個平衡如果您更關注應用程序的性能則應該仔細地權衡這兩個考慮事項以獲得一個更好的解決方案

移動 Web 服務的設計考慮事項

  我已經討論了設計 Web 服務的指導原則現在我將把重點放在移動 Web 服務的考慮事項上在大多數情況下當將 JAXRPC 值類型用於移動 Web 服務時需要考慮一些事情JAXRPC 值類型(遵循 JSR)是 Java 類其值可以在服務客戶端和服務端點之間移動為了獲得一致的值類型必須遵循一系列規則我只列出其中的幾條與本文關系最大的規則是


您必須具有公共缺省構造器
您必須具有用於需要在網絡上傳輸的字段的 setter 和 getter 方法
在處理數據集合時您應該使用數組
移動 Web 服務中有一些首選的數據類型
在處理輸入和輸出參數時注意可能出現的問題

  您必須具有公共缺省構造器

  在反序列化的過程中SOAP 運行時環境使用缺省構造器來構造對象如果您試圖在沒有公共缺省構造器的情況下編寫值類型(也稱為數據傳輸對象在當 JAXRPC 運行時嘗試序列化和反序列化數據對象時可能會遇到錯誤對於像 IBM Rational® Application Developer (RAD) 這樣的 IDE將不為該數據類型生成序列化和反序列化 Helper 類(由 RAD 通過前綴 _Helper_Ser_Deser 生成)所以在調用與自定義數據類型相關的方法時會出現序列化錯誤不帶參數的構造器確保可以根據序列化狀態遠程構造對象

  您必須具有用於網絡傳輸字段的 setter 和 getter 方法

  首先看一看清單 中的類 FailTask 的源代碼

清單 FailTask 類的定義

  

  public class FailTask { /** * The owner of the task */ private int ownerid; /** * The name of the task */ private String name; /** * Default public nonargument constructor * */ public FailTask(){ } /** * Constructor of FailTask class * @param ownerid Owner of the task * @param name Name of the task */ public FailTask(int ownerid String name){ thisownerid = ownerid; thisname = name; } /** * Getter method * @return the ownerid of the task */ public int getOwnerid(){ return ownerid; } /** * Setter method * @param ownerid the ownerid to be set */ public void setOwnerid(int ownerid){ thisownerid = ownerid; } }

  您可以將清單 中所示的方法添加到 Web 服務中該方法將返回單個 FailTask 對象

清單 返回 FailTask 對象的方法

  public FailTask getFailTask(int ownerid String name){ return new FailTask(ownerid name); }


  當使用 RAD 附帶的 Universal Test Client 中的 和 Rachel 參數調用 getFailTask() 方法時所得到的響應如圖 中所示

Universal Test Client 中的響應視圖

  Universal Test Client 中的響應視圖

  name 字段在哪裡?它不在這裡因為我沒有通過 getter 和 setter 方法提供 name 字段Setter 和 getter 方法是必須提供的兩個方法FailTask_Ser 類中一樣name 字段 getter 方法用於將 name 字段值寫入 SOAP 消息FailTask_Deser 類中name 字段 setter 方法用於設置反序列化的 FailTask 對象的 name 值

  在處理數據集合時您應該使用數組

  為了有效地使用 Web 服務您必須或多或少地使用數據集合但是必須提醒當處理許多值類型時事情會變得比較麻煩因此需要考慮以下問題

  當需要動態長度的數組時請考慮 ArrayList您已經反復聽說過如果不考慮同步ArrayListVector 更有效但遺憾的是JSR JAXRPC 規范沒有強制要求支持 Java Collection 類型有些 Web 服務引擎可能沒有為 ArrayList 提供支持例如IBM Web 服務引擎只正式支持 Java Collection Framework 中的一小部分類包括 javautilVectorjavautilHashTablejavautilHashMap

  那麼嘗試一下另一個動態數組 Vector 會如何呢?如果在相同平台上生成存根文件它將正常工作但是如果在不同的平台上生成存根文件則將遇到一些問題例如在 Web 服務描述語言 (WSDL) 文件中Vector 或其他 Collection 類型映射到 ArrayOfAnyType其他平台可能不知道將其映射到哪個 Collection 類型而且 Vector 中包含的數據元素也映射到 WSDL 中的 AnyType(這裡存在的一個大問題是其他的平台不知道 AnyType 代表什麼類型)有關該主題的詳細信息請參閱參考資料中的 Web services programming tips and tricks: Improve the interoperability between JEE and NET

  使用數組的最後一個原因是移動 Web 服務不支持 Java Collection 類型這使得所有其他的解釋都顯得沒有必要這意味著您可能無法從形式良好的 WSDL 文件為移動 Web 服務生成存根文件

  移動 Web 服務中的首選的一些數據類型

  使用基元類型 long 傳輸 Date 或 Calendar 表示形式

  對於標准 JAXRPC 運行時實現有兩種支持的標准類型映射


Java 類型到 XML 數據類型
XML 數據類型到 Java 類型

  在 JAXRPC 子集規范中只需要第二種映射 顯示了從支持的 XML 數據類型到 Java 類型的映射的簡要列表有關詳細信息請參閱 JSR



從 XML 數據類型到 Java 類型的映射
簡單 XML 類型 Java 類型 xsd:string javalangString xsd:int int xsd:long long xsd:short short xsd:boolean boolean xsd:byte byte xsd:float javalangStringfloat xsd:double javalangStringdouble xsd:QName javaxxmlnamespaceQName xsd:baseBinary byte[] xsd:hexBinary byte[]

  從表 中您可以清楚地看出該列表中不存在像 xsd:dateTimexsd:date 或 xsd:time 這樣的元素而在標准 JAXRPC 規范中這三個元素確實是映射到 javautilCalendar 的 XML 類型請注意在 JAXRPC 中定義的 Java 據類型映射到 XML 類型的映射中javautilDate 映射到 xsd:dateTime

  那麼在嘗試傳輸日期或時間表示形式時您應該使用什麼?改為使用 long 類型的時間long 類型的日期格式與不同時區的時間表示形式無關並且因為它是基元類型所以比其他類型的 Java 對象更有效

  注意 float 和 double 類型的使用

  首先需要注意的一點是正如您所知CLDC (Connected Limited Device Configuration) 並沒有出於性能的原因而提供 float 和 double 本機類型即使 CLDC 和 CDC 都為其提供了支持那麼如果您必須使用針對 CLDC 的 Web 服務您該如何做呢?JSR 為您提供了部分答案

  為了在 CLDC 中缺省支持 xsd:float 和 xsd:double實現必須 生成代碼來將這些類型映射到 javalangString為了支持為 float 和 double 提供本機支持的配置和平台(CLDC 和 CDC)存根生成器實現也必須 生成代碼來將這些類型映射到適當的本機 Java 類型(詳細信息請參閱參考資料以獲得指向 JSR: JME Web 服務規范的鏈接

  我將演示一個添加兩個 float 數的簡單 Web 服務(清單

清單 添加兩個 float 數

  

  public class TaskWs { public TaskWs() { } /** * Adding two float numbers and return their sum * @param a First number to add * @param b Second number to add * @return The sum of a and b */ public float addTwo(float a float b) { return a + b; } } }

  所生成的 WSDL 定義中的 XML 數據類型定義如清單 所示

清單 與清單 對應的 WSDL 定義


  

  <wsdl:types> <schema targetNamespace= xmlns= xmlns:impl= xmlns:intf= xmlns:wsdl= xmlns:xsd=> <element name=addTwoResponse> <complexType> <sequence> <element name=addTwoReturn type=xsd:float/> </sequence> </complexType> </element> <element name=addTwo> <complexType> <sequence> <element name=a type=xsd:float/> <element name=b type=xsd:float/> <element name=b type=xsd:float/> </sequence> </complexType> </element> </schema> </wsdl:types>

  對於針對 CLDC 的 Web 服務客戶端所生成的存根如清單 所示

清單 為 CLDC 生成的客戶端存根

  

  public interface TaskWs extends javarmiRemote { public javalangString addTwo(javalangString _a javalangString _b) throws javarmiRemoteException javaxxmlrpcJAXRPCException; }

  所以當調用 CLDC 中的 Web 服務時您必須使用 addTwo() 方法提供兩個 String 參數而對於針對平台 CLDC 的 Web 服務客戶端所生成的服務接口與清單 中所描述的類似

清單 為 CLDC 生成的客戶端存根

  

  public interface TaskWs extends javarmiRemote { public float addTwo(float _a float _b) throws javarmiRemoteException javaxxmlrpcJAXRPCException; }

  這將 xsd:float 映射到所生成的客戶端存根中的 float 類型看到 CLDC 和 CLDC 之間的不同之處了嗎?

  在為移動設備開發 Web 服務時請注意 float 和 double 類型因為 CLDC 虛擬機實現無法加載為 CLDC 生成的存根(使用到 float 和 double 的本機映射)同時針對 CLDC 和 CLDC 的 Java Platform Micro Edition (JME) 應用程序的開發人員應該使用到 javalangString 的缺省映射以獲得最好可重用性

  在處理輸入和輸出參數時注意可能出現的問題

  JSR 指定了以副本的形式傳送並以副本的形式創建返回值的所有參數但是當處理數據集合時零數組 (返回零)和空數組 (返回其本身)需要密切關注

  我的建議是盡可能地避免使用空數組當處理移動 Web 服務時空數組可能是一個問題

  假定您需要返回任務對象數組原始代碼如清單 所示

清單 一個簡單的值對象

  

  public class SimpleTask { /** * The name of the task */ private String name; /** * The default constructor * */ public SimpleTask() { } /** * @return Returns the name of the task */ public String getName() { return name; } /** * @param name * The name to set */ public void setName(String name) { thisname = name; } }

  Web 服務實現如清單 所示

清單 返回值對象的數組的方法

  

   public SimpleTask[] getSimpleTasks(){ SimpleTask[] tasks = null; /* * Your code dealing with DB goes here * * tasks = */ return tasks; }

  當生成 Web 服務存根和使用生成的存根測試 Web 服務時本例中的每一個部分都將正常工作但是因為在結束一個階段之前您需要使用 Jtest 進行完整的代碼檢查所以當您對代碼片段運行 Jtest 時您將看到一條建議Return zerolength arrays instead of null在猶豫片刻之後後您將贊同 Jtest 的建議如果您返回零數組該代碼的客戶端必須編寫額外的代碼來檢查返回值是否為零(如清單 所示)

清單 用於調用 Web 服務的客戶端代碼片段


  

  SimpleTask[] tasks = servicegetSimpleTasks(); if(tasks != null){ int length = taskslength; //do something here }

  當您將 SimpleTask[] tasks = null;(清單 中的第 行)修改為 SimpleTask[] tasks = new SimpleTasks[]; 時您只需將清單 編寫為

  SimpleTask[] tasks = servicegetSimpleTasks(); int length = taskslength;


  在修改之後您會認為代碼邏輯沒有更改並再次運行客戶端來調用 Web 服務但是現在卻引發了異常到目前為止您已經根據 Jtest 的建議做了許多小的修補——您忘記修改了什麼——這可能導致需要花額外的時間來努力找到發生錯誤的原因這個過程真的漫長而乏味

  那麼問題究竟出在什麼地方呢?一般來說對於零對象數組(如 SimpleTask)返回的 SOAP 消息如清單 所示

清單 返回零數組時的 SOAP 消息

  <soapenv:Body> <p:getSimpleTasksResponse xmlns:p=> <getSimpleTasksReturn xsi:nil=true /> </p:getSimpleTasksResponse> </soapenv:Body>


對於空數組(如 SimpleTask[] tasks = new SimpleTask[])SOAP 消息如清單 所示

清單 返回空數組時的 SOAP 消息

  <soapenv:Body> <p:getSimpleTasksResponse xmlns:p=> <getSimpleTasksReturn /> </p:getSimpleTasksResponse> </soapenv:Body>

  其不同之處在於 <getSimpleTasksReturn/><getSimpleTasksReturn xsi:nil = true> 之間 說明了空數組參數大部分時間是無效的對於自定義的數據類型(包括另一個自定類型的數組)不要將類變量初始化為空數組——相反要將其初始化為零數組盡管所生成的空數組和零數組的 WSDL 定義是相同的

根據 JSR 編碼零數組參數和空數組參數
根據 JSR-172 編碼零數組參數和空數組參數





結束語

  在處理移動 Web 服務時您需要更加謹慎因為移動 Web 服務規范只支持部分 API如果您計劃開發移動 Web 服務則當您處理值類型和集合類型時我向您介紹了一些竅門此外我還提供了以下信息


設計前考慮事項例如何時使用 Web 服務以及如何分析使用 Web 服務套接字或消息傳遞技術之間的利弊
在決定使用 Web 服務後需要考慮的設計事項包括

    管理粒度
    設計 Web 服務接口
    使用 Document/literal 作為編碼樣式
    為什麼您應該使用 JavaBeans 組件而不是 EJB 技術作為您的服務提供程序
    為什麼您應該避免 XML 元素嵌套太深
    嵌套和粒度之間的平衡

在使用 JAXRPC 值類型時需要考慮的移動 Web 服務設計事項包括

    公共缺省構造器
    Setter 和 getter 方法
    使用數組類型而不是 Java Collection 類型
    確定首選數據類型
    處理輸入和輸出參數

  參考資料

學習

您可以參閱本文在 developerWorks 全球站點上的 英文原文


Web 服務編程技巧及竅門: 改善 JEE 與 NET 之間的互操作性(developerWorks 月)向您介紹在處理標准 Web 服務時如何管理集合數組和原型數據類型


JSRJME Web 服務規范定義了一個可選的包其提供了從 JME 到 Web 服務的標准訪問


我應該采用哪一種 WSDL 樣式? (developerWorks 月)描述了本文所提供的操作模式(以及另外兩種模式)RPC/encodedRPC/literalDocument/encodedDocument/literal 和 Document/literal wrapped 模式


Web Services Interoperability Organization (WSI) 是一個開放的行業組織旨在促進跨平台操作系統和編程語言之間的互操作


Tips and tricks: XML does the job(developerWorks 月)說明了如何使用 XMLRPC 來定義移動 Web 服務客戶端


Crossplatform programming with Java technology and the IBM Web Services Toolkit for Mobile Devices(developerWorks 月)幫助確保您的 Java 應用程序在不需要修改的情況下作為盡可能多的平台運行


JSR: Java APIs for XMLbased RPC 討論了如何使用 JAXRPC 值類型


Using Mobile Devices with the WSTK(developerWorks 月)說明了 Web Services Tool Kit for Mobile Devices 如何幫助開發在小型移動設備上使用 Web 服務的應用程序


交付 Web 服務至移動式應用程序(developerWorks 月)說明了如何使用支持 JME 的移動設備和 kSOAP 庫訪問 Web 服務


為移動設備開發 Web 服務客戶端 (developerWorks 月)指導您完成構建 JME MIDP 設備上的移動 Web 服務客戶端的必要步驟


Connected Limited Device Configuration (CLDCJSR 和 JSR)定義了用於資源約束型設備的一組基本 API 和虛擬設備提供了一個功能強大的 Java 平台用於開發與 Mobile Information Device Profile (MIDP) 結合在具有有限內存處理能力和圖形功能的設備上運行的應用程序


Best practices for Web services 系列(developerWorks 月)詳細介紹了 Web 服務設計考慮事項


請查閱 Safari eReference Bookstore以找到許多特定於移動和其他技術的主題


developerWorks Wireless technology 專區專門發布有關基於移動和普及計算的解決方案的各方面的文章

  獲得產品和技術


Jtest 可以自動完成 Java 單元測試從正在運行的應用程序自動生成 JUnit 測試用例以及測試單個類或大型的復雜應用程序


Web Services Tool Kit for Mobile Devices (alphaWorks) 是成熟的技術——弄清楚該技術的應用領域

  關於作者

  

  Shu Fang Rui 畢業於中國上海交通大學她對無線技術和 Web 服務非常感興趣除了旅行之外她還喜歡從


From:http://tw.wingwit.com/Article/program/Java/hx/201311/25862.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.