IBM Lotus Domino 7 中的實用 Web 服務，第 1 部分: 什麼是 Web 服務以及它們爲何如此重要

IBM Lotus Domino 7 中的實用 Web 服務，第 1 部分: 什麼是 Web 服務以及它們爲何如此重要

級別: 初級

Julian Robichaux, 開發人員, 獨立顧問

2005 年 11 月 07 日
2006 年 12 月 21 日 更新

在本系列文章（共分爲 3 部分）的第 1 部分中，我們將討論 Web 服務的術語和概念以及 Web 服務可以帶給 IT 專業人士的益處。本文沒有解決任何特定於 Lotus Domino 的問題，只給出了 Web 服務的介紹，以便您快速入門。

您可能聽說過 Web 服務這一術語，在技術文章的上下文、軟件產品的描述或者在與同事的交談中都會提到它。Web 服務固然重要，但若將 Web 服務解釋成 “用來定義能夠交換消息的通信端點集合的 XML 語法” 多少會讓人感覺整個概念太過複雜且難以理解。

幸運的是，只要不過於追究底層的操作細節，Web 服務可以用一種人人都能理解的方式加以定義。您應盡力理解 Web 服務，因爲它們（及其相關術語 Service-Oriented Architecture 或 SOA）是 IT 界相當普遍的概念。

可以將 Web 服務看作是汽車：當您購買汽車、駕駛汽車或與朋友談論汽車（除非他們是地道的修理工）時，您不需要在深奧的技術層面上了解所有活塞、凸輪軸和燃料噴射器的工作方式。Web 服務也是如此，您只需瞭解什麼是 Web 服務和 Web 服務的工作方式以及 Web 服務爲何對於您和您的生活（作爲 IT 專業人士）如此重要就已經足夠了。

實際上，現在使用 Web 服務很容易，無需處理大量的底層技術，因爲在過去的幾年中軟件供應商及開放源碼社區通過努力已經從低級別的任務中提取出 Web 服務的具體細節。這樣一來，您就可以將大量時間花在集成組件上，而不是閱讀冗長詳細的規範文檔以解決如何正確格式化 XML 消息的問題。

此係列文章適合於協助 Domino 開發人員理解並使用 IBM Lotus Domino V7.0 中的 Web 服務。本文是介紹性文章，適用面廣泛，對於想知道什麼是 Web 服務的任何人都是很有用的。Lotus Domino V7.0 合併了多種技術，使得開發人員可以很容易且方便地創建並公開 Web 服務，稍後我們將對此進行更加詳細的討論。

現在我們來討論一下究竟什麼是 Web 服務。

什麼是 Web 服務？

簡單地說，Web 服務允許計算機應用程序間以一種標準的方式進行通信。

兩臺或更多臺機器之間的通信 雖然本文中的示例只討論了單臺機器上或兩臺不同機器之間的 Web 服務事務，但 Web 服務通信可以跨越三臺或更多臺機器。例如，中間設備可以轉發和/或記錄事務，對一臺服務器上的 Web 服務進行調用也可以產生對另一臺服務器上的服務的調用。 實際上，在本文結尾處討論 SOA 時，我們必須討論跨越多臺機器的 Web 服務通信，因爲這就是完整 SOA 環境中中間件棧的本質。

Web 服務是一個抽象的概念 —— 這種抽象多少有點像人與人之間的談話。談話一般會涉及進行交談的兩個或更多人，這些人使用他們都能理解的某種語言進行交談。而這種語言定義了所使用的詞語以及如何將這些詞語組成句子。通常談話將包括一些答覆和響應，其中一個人給出陳述或提出問題，然後其他人根據第一個人所說的內容進行響應。人們可以面對面坐着交談、通過電話交談、或在當今時代，來回發送電子郵件或使用在線聊天服務進行交流。

在任何情況下，談話本身有多個組成部分，根據所涉及的人數、正在使用的語言以及談話人所使用的技術（如果有的話），談話發生的方式也略有不同。

Web 服務允許應用程序間的通信，其中所涉及的內容很多，本文通篇將對這些內容進行討論。但基本的概念仍類似於上述人與人之間的談話的概念，只不過這裏是應用程序使用共同的語言進行通信，且通常會跨越某種網絡。應用程序可以位於同一臺計算機，也可以位於不同的計算機，而不同的計算機彼此之間可能相隔甚遠並僅通過 Internet 線路及之間的一些路由器和服務器來連接。最妙的是應用程序和計算機不必相似。在單個的 Windows 筆記本電腦上可以有兩個 Microsoft .NET 程序互相通信，加拿大的一臺 iSeries 服務器上的 Java 程序也可以與中國的 Linux 臺式機上的 C++ 程序進行通信，所有這些都使用 Web 服務。

下面是在基本 Web 服務通信中通常會使用的標準技術：

• XML：Web 服務組件所使用的語言（數據格式）
• 簡單對象訪問協議（Simple Object Access Protocol，SOAP）：應用程序之間發送的 XML 消息
• Web 服務描述庫（Web Services Description Library，WSDL）：XML 文件，定義了必須以怎樣的方式來構造併發送 SOAP 消息

還有另外一個標準技術可用於基本 Web 服務通信，即通用描述、發現和集成（Universal Description, Discovery, and Integration，UDDI）。我們將在文章末尾對它進行討論；但 UDDI 的使用是可選的，在很多 Web 服務實現中沒有使用它。

回頁首

一些術語：公開並使用 Web 服務

在進一步解釋術語之前，先回顧一下與公開和使用 Web 服務相關的一些定義。

當我們談到公開 Web 服務時，我們指的是這樣一個應用程序，該應用程序發佈 WSDL 文件並允許其他應用程序使用其提供的 Web 服務。公開 Web 服務的應用程序也被稱爲提供程序。

當我們談到使用 Web 服務時，我們指的是調用另一臺機器上的 Web 服務的應用程序。Web 服務的使用者也被稱爲客戶機。

回頁首

XML：公共語言

XML 是用於 Web 服務組件之間的通信的語言。應用程序之間進行交換的消息採用 XML 格式，而且用來定義所使用的 Web 服務的文件也採用 XML 格式。圖 1 描述了簡單的 XML 文件的結構。

圖 1. 基本 XML 結構

從圖中可以看到，文件中單獨的信息（姓、名等等）被帶尖括號的標記包圍起來。例如名字 John 表示爲 <firstname>John</firstname>。還可以具有包含在其他元素中的元素，例如 <person> 元素，它包含了 <firstname>、<lastname> 和 <birthday> 元素。

使用 XML 來編寫 Web 服務有極大的優勢，即：

• 在所有現代編程語言中，XML 解析器是很常見的，因此爲 Web 服務編寫的應用程序不必直接解析原始 XML 文件。
• XML 文件是可讀懂的文本文件（換句話說，只要熟悉 XML 語言，就可以在任何文本編輯器中打開 XML 文件，並讀懂文件內容）。這對調試過程很有幫助。
• XML 提供了在消息中使用任何標準字符集的方法，因此可以像用英語編寫消息一樣，很容易地用德語或日語編寫消息。
• XML 允許使用名稱空間，允許對文件中特定的元素的期望結構進行預定義。例如，可以定義始終是浮點數的 Price 元素或具有字符串子元素 FirstName 和 LastName 的 PersonName 元素。

  如有必要，名稱空間還允許相同名稱的不同的元素具有不同的定義。例如一個名稱空間中的 StockPrice 元素可能有股票代碼和價格，而另一個名稱空間中的 StockPrice 元素可能有股票代碼、價格、每日高低點和一年最高點。

使用 XML 的缺點（如果您將其稱爲缺點的話）是：

• XML 是一種十分嚴格的語言，因此 XML 消息中的任何格式問題都將引起整個消息解析失敗（即使這些問題可以很容易地解決或忽略）。但是，只要在程序中使用標準 XML 庫來生成 XML 文件（這應是帶有 Web 服務實現的情況），那麼標準 XML 庫就會確保以正確的格式表示消息。
• 消息的 XML 表示是純文本文件，因此它通常比其他格式（如分隔符、二進制或定製格式）的等價表示要大得多。

但是，這些都是小問題，XML 的優勢遠遠超過了上述不便。

回頁首

SOAP：發送的消息

知道 Web 服務應用程序之間的通信是以 XML 格式編寫只解決了一半的問題。應用程序可以解析消息，但它們怎樣知道如何解釋解析結果呢？

關於如何格式化 Web 服務 XML 消息的規範是 SOAP。SOAP 定義了消息的結構，因此應用程序知道如何發送和解釋數據。SOAP 消息的基本結構如圖 2 所示。

圖 2. 基本的 SOAP 消息結構

作爲 XML，上述結構可以解釋爲如下內容：

<SOAP-ENV:Envelope  
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"  
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">    
  <SOAP-ENV:Body>
    <ns1:GetStockInfo xmlns:ns1="urn:thisNamespace">
      <symbol>FOO</symbol>
    </ns1:GetStockInfo>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>					
					

在其最基本的格式中，有一個包含 SOAP Body 的 SOAP Envelope，且 Body 包含了所傳遞的實際數據。有時，有一個包含額外信息的 SOAP Header（在 Envelope 中的 Body 之前），不過 SOAP Header 是可選的。

SOAP 規範 雖然 SOAP 是具有公認規範的標準格式，但也應該注意到不同供應商在實現該規範的方式上存在一些差異。例如，由 Apache Axis 生成的 SOAP 消息中的實際名稱空間和 XML 結構與由 Microsoft .NET 生成的 SOAP 消息中的名稱空間和 XML 結構看起來就有很大的不同。不過，正確編寫的客戶機或服務器可以解析任何遵循規範的 SOAP 消息。 另外，SOAP 1.1 和 SOAP 1.2 規範在一些方面也大不相同，因此熟悉 SOAP 1.1 消息的客戶機或服務器可能無法接受 SOAP 1.2 消息。

同時，出現問題的情況下，SOAP Body 將以 SOAP Fault 格式來包含錯誤信息。Fault 是另一個 XML 結構，它包含了錯誤的描述，例如：

<SOAP-ENV:Fault>
  <faultcode>SOAP-ENV:Server</faultcode>
  <faultstring>Server Error</faultstring>
  <detail>Database not available</detail>
</SOAP-ENV:Fault> 			
				

 

儘管 SOAP 消息是標準 XML 格式的文本文件，但手動創建或解釋 SOAP 消息通常很難，因爲所有名稱空間和元素屬性要嚴格按照某些特定方式來定義。幸運的是，現在有大量可用的工具和編程庫能夠用來創建並解釋 SOAP 消息，因此利用這些技術可以大大減少複雜性。這些工具可以爲我們完成複雜工作。

回頁首

WSDL：定義 Web 服務

每個提供 Web 服務的應用程序都使用 WSDL 文件來描述哪些服務是可用的以及這些服務該如何調用。WSDL 是另一種基於 XML 的格式，它具有明確定義的結構，允許應用程序對其進行解析。通常將縮寫詞 WSDL 念做 “Whiz-dull”。

在 WSDL 文件的中心，Web 服務的提供程序定義了可由其他應用程序使用的方法。例如，Web 服務有一個名爲 GetTemperature 的方法，該方法將返回給定城市的溫度。WSDL 文件將該方法和如下信息一起列出：

• 特定的名稱，用於向方法提出請求（在本例中，爲 GetTemperature）
• 請求中必須使用的參數，如果有參數的話（參數的特定名稱和特定的數據類型）
• 成功處理請求時值或返回值的格式（值的特定名稱和數據類型）
• 爲了進行方法調用應使用的 URL 和協議

文件中還有其它信息用來說明應如何格式化 SOAP 消息，例如要使用的名稱空間、參數的順序和結構、以及 SOAP Header 元素或 HTTP header 中所需的額外信息。

WSDL 規範 類似 SOAP，WSDL 規範也是標準規範，可通過多種方式實現。特別地，有很多共同使用的不同 WSDL “樣式”可用，例如 RPC/Encoded 和 Document/Literal。用來查看這些 WSDL 類型之間差異的一個極好資源是 developerWorks 文章 “我應該採用哪一種 WSDL 樣式？”。 另外，WSDL 1.1 和 WSDL 2.0 規範也有一些重大差別。在撰寫本文時，2.0 規範仍處於推薦階段，在短期內，它可能會與 1.1 規範並存。

如果您以前從未看過 WSDL 文件，現在打開一個文件進行閱讀可能很難提取出全部信息，因爲文件的實際結構有些複雜。有關方法的全部信息（名稱、參數、協議等）將分佈在文件的各個部分，並且必須在可以構造 SOAP 消息之前由客戶機應用程序將其拼湊起來。對 WSDL 文件的各個組成部分及它們如何一起工作的說明超出了本文的討論範圍。

還好，我們還可以求助於相關技術的幫助。大多數情況下，開發人員不必讀取、解析並瞭解 WSDL 文件的內部細節。利用一些軟件工具完全可以獲取這些信息，因此您所需要關心的事情就是爲 Web 服務提供數據並且使用作爲響應返回的數據。您不但可以使用工具和庫來實現這種功能，而且應該 始終這樣做。Web 服務所涉及的組件存在很多異常、變數和複雜性，所以需要更加關心使用 Web 服務而不是逐一分解並理解全部組件。

回頁首

協議：消息如何發送

到目前爲止，我們尚未涉及的一個細節是這些 SOAP 消息是如何來回傳遞的？

答案是它們通常通過 HTTP 協議在網絡（和/或 Internet）中傳送，就像 Web 頁面從 Web 服務器傳送到工作站的瀏覽器上一樣。這些消息不一定非要使用 HTTP（SMTP 是 HTTP 協議的主要競爭者，儘管它落後很多）協議來傳送。WSDL 文件中明確定義了 Web 服務所使用的協議。

WSDL 文件中所指定的 SOAP 消息協議通常是 HTTP 協議。SOAP 客戶機根據所使用協議的規範來發送消息。

回頁首

您可能聽說過的其他 Web 服務術語

到目前爲止，我們所討論的內容已包括了最常用的術語，但是在討論 Web 服務時，還可能會聽到其他一些術語。

鬆耦合

使用 Web 服務的應用程序通常是鬆耦合的，這就是說能夠讓程序運轉起來的 Web 服務沒有直接與應用程序捆綁在一起，同樣該應用程序也沒有直接捆綁在 Web 服務上。程序可以方便地利用幕後的不同服務集來提供功能，服務本身也可以等待一個應用程序 —— 任何應用程序 —— 來調用它們並等待響應。

在現實世界中，可以將和朋友一起進餐的活動看作是一種鬆耦合的情況。幾個朋友先是以各種方式（面對面、電話、電子郵件等）互相聯繫。然後大家採用對自己方便的交通方式到達飯店，就餐後，採用某種方式結帳。這其中的細節並不重要，而且就餐這件事還可能以其他方式進行，但是最終的結果都是一樣的 —— 和朋友們共進晚餐。

而駕駛汽車的活動可以說是緊耦合的一個例子。您需要以特定的方式使用一整套固定的工具以便執行預定義的任務。如果您想從車道上倒車出來，則必須掛入倒檔，然後踩油門。如果想左轉，則必須向左轉動方向盤。因爲系統整體上很精確並且各個組件之間也是緊密依賴的，所以對於如何使它運轉起來，您不會有很多選擇。

UDDI

UDDI 是一個標準，用來提供 Web 服務的目錄，該 Web 服務可用於任何數量的不同應用程序。它就像是一個 Web 服務提供程序的“電話簿”。客戶機可以在 UDDI 註冊表中查找服務信息，由註冊表返回連接到該服務所需的詳細信息。

雖然在最早的 Web 服務定義中，UDDI 是一個重要的標準，但由於它是 Web 服務的可選組件，並且一些人選擇不使用它（這是常有的事），因此 UDDI 的重要性有所減弱。

在很多更具組織性的企業環境還存在有 UDDI 註冊表，這些企業環境擁有大量內部的 Web 服務提供程序。實際上，當發佈可在公司內使用的 Web 服務時，設置企業 UDDI 站點是一個很好的主意。除了集合可用 Web 服務外，UDDI 使更改幕後的 Web 服務提供程序變得很容易。只要所有的客戶機使用 UDDI 來定位 Web 服務而不是直接轉到提供服務器，SOAP 調用都將自動指向新的提供程序。

總之，它是一個可選的架構組件，並不是 Web 服務實現所嚴格要求的。

Web 服務安全性

在閱讀 SOAP 和 WSDL 描述時，您一定很關心安全性問題。當調用這些服務時，如果提供程序使用了非公共的信息，那麼該如何實現驗證呢？當然，並不是所有的 Web 服務都是向公衆全部開放的，不是嗎？

這是一個非常好的問題，遺憾地是，沒有一個標準的答案。在很多不同的場景下，必須根據實際情況進行處理，例如：

• SOAP 消息是使用純文本格式進行傳遞還是需要加密？
• 您是需要簡單的用戶名/密碼驗證還是需要持久性的、基於令牌的驗證？
• 如果有令牌，是否需要通過簽署驗證來對它們進行簽名？又如何將其正確地包括在 SOAP 消息中？
• 如果客戶機沒有將 SOAP 消息直接發送到提供程序，而是通過中間節點（例如消息隊列或其他 Web 服務）來發送消息，該怎麼辦？

另外，無法保證 HTTP 始終是信息交流所使用的協議，因此不能僅在現有的 HTTP 安全性方法上使用 Web 服務安全性。

還有一些規範可以解決這些及其他 Web 服務的安全性問題，它們是 WS-Security、WS-Policy、WS-Trust 和 WS-Privacy。一些軟件供應商和委員會已經對此討論多年。當然，並非所有 Web 服務實現都能兼顧所有的安全性規範，因而所形成的安全性標準提供了一些被普遍接受的方式用於解決大多數安全性問題。

中間件和企業服務總線

還有更大的一套支持安全性標準的 Web 服務標準，通常這些標準（在一個相當大的集合中）混在一起，被稱爲 WS-* 規範。它們共同解決了很多重要的架構問題，當您開始在企業環境中放置大量 Web 服務時會出現這些問題。WS-* 中的標準涉及如下主題：

• 安全性
• 可靠性
• 消息傳遞
• 事務
• 服務質量

之所以需要這麼多標準是因爲在企業應用程序中 Web 服務客戶機和服務器交互間的消息傳遞要求比簡單的請求/響應要複雜得多。例如，應該如何確保消息實際到達了提供程序並返回到客戶機？如果 SOAP 請求實際上是一個多方事務請求，該怎麼辦？怎樣管理那些涉及調用了其他 Web 服務的 Web 服務的過程？如果應用程序發送了一系列具有定時要求的請求，該怎麼辦？

對於較大的軟件供應商，解決上述問題並應用這些規範將帶來機遇和挑戰。一些供應商爲市場提供了 Web 服務中間件產品軟件包 —— 通常被稱爲企業服務總線（Enterprise Service Bus）或 ESB —— 這些軟件包提供了一些或全部管理功能以便解決此類問題。通常這些 ESB 產品還有附加功能，比如它們可以將跨機構的很多 Web 服務捆綁在一起並提供諸如登錄和消息排隊這樣的功能。

面向服務的架構

接下來要探討的是面向服務的架構 (Service-Oriented Architecture)。在很多方面，SOA 只是我們已描述的各方面內容的組合：來自多個提供程序的鬆散耦合的 Web 服務在公共標準集（可能是 ESB）下互操作，並通過多個應用程序集中在一起，這些應用程序從服務中提取數據，然後以多種方式表示出來。

因爲它實際上是一個軟件架構，所以構建 SOA 時會涉及大量的計劃和協調。它不是多個 Web 服務胡亂的堆砌和混合；而是對服務如何被收集並公開、使用哪種管理工具和中間件、如何整體上監視並維護服務和系統這些問題的有序組織。

從更高的層次上來講，SOA 也是一種理念體系。它不需要您考慮獨立操作的大型應用程序，而是要求您關注有關使用或提供可在企業中公開或使用的功能模塊集的所有事情。也就是說它要求不要從泛泛的應用程序方面進行考慮，而是應該着眼於具體的明確定義的服務，即 Web 服務。

回頁首

爲什麼所有這些都很重要？

現在您對 Web 服務如何工作有了一些瞭解 —— 客戶機讀取提供程序的 WSDL 文件，根據該文件中的定義來格式化併發送 SOAP 消息，然後接收響應中的 SOAP 消息。那麼這些爲何如此重要？原因何在呢？

重要性的部分原因在於應用程序現在能夠以一種標準方式進行通信，而不管它是採用哪一種語言編寫的或運行在哪一種平臺上。在過去，應用程序（可能進行了也可能沒進行過很好的建檔）需要定製的數據格式，而且必須要處理 API 級功能，這些功能可以也可能不可以被用其他語言編寫的其他程序訪問。所有的 Web 服務標準都採用 XML 格式就意味着所有的服務都是可訪問的且明確定義的。

實際上，它還解放了不相關的應用程序，這些應用程序現在可以使用公共語言方便地進行通信。在使用多個供應商提供的不同技術時，所面臨的困難之一是始終要確保程序之間能夠互相對話並交換數據。現在，只要應用程序可以提供和/或使用 Web 服務，不同技術之間的互操作性就會大大簡化。

另一個優勢在於可以很容易地將 Web 服務客戶機和提供程序放置在完全不同的機器上（可能運行於完全不同的硬件和操作系統），同時通信仍能進行。過去，應用程序只能由相同機器上的其他應用程序或由其他機器上使用了定製數據傳送格式的應用程序訪問。Web 服務應用程序所需要只是網絡連接和 XML 解析器。

將所有這些因素放在一起就是真正的原因所在了。由於現在可以採取一種標準方式用於不同應用程序在網絡上的通信，因此您就可以設計自己不同的應用程序。現在還能夠編寫更加模塊化的程序，而不必多此一舉地編寫提供全部功能的單一應用程序。

例如，現在您不必編寫大型報告型應用程序來收集關於幾個不同進程的數據，然後將數據轉化爲圖表，再將其展示給用戶，您完全可以採用指示板，它是可以提供此功能的一些 Web 服務的前端。經過編譯的數據可以通過對一個或多個 Web 服務的調用進行檢索，而且通過發送數據到接收該數據並返回餅狀圖或類似圖表的繪圖 Web 服務可以生成圖表本身。

指示板已由一個大型的獨立程序演變成了一個簡單的接口。如果需要添加新組件，只需調用附加服務。如果需要其他圖表類型，則可以調用不同的繪圖服務。如果指示板需要與向下鑽取功能或定製排序有更多的交互，則指示板可以在用戶和適當的 Web 服務之間來回傳遞請求。甚至可以在不影響用戶的情況下徹底更改後臺中調用的服務，並且（只要 WSDL 文件沒有更改）無需更改指示板應用程序。

作爲 IT 專業人士，您可能會負責計劃或開發這類接口和/或這類服務。瞭解如何結合使用本文所介紹的這些組成塊（或至少知道這些組成塊的存在）是推動此類項目前進的重要基礎。

幸運的是，有很多工具可用來協助您提供並使用 Web 服務，而且無論您使用何種技術，它們都將爲您減輕大量開發負擔。在本系列文章的後續部分中，我們將討論如何使用 IBM Lotus Domino V7.0 輕鬆地爲客戶機或系統提供 Web 服務。

參考資料

學習

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。
  
  
• 查看完整的 “IBM Lotus Domino 7 中的實用 Web 服務” 系列文章。
  
  
• developerWorks Lotus 文章 “Lotus Notes/Domino 7 Web Services”
  
  
• developerWorks Lotus 文章 “通過 Lotus Domino Java 代理消費 Web 服務”
  
  
• developerWorks 教程 “快速創建 Domino Web 服務，利用 Domino 7 中新的 Web 服務功能加快開發速度”
  
  
• developerWorks SOA and Web services 專區的標準和規範頁面
  
  
• developerWorks 文章 “我應該採用哪一種 WSDL 樣式？”
  
  
• developerWorks SOA and Web Services 專區
  
  
• developerWorks 文章 “觀點與展望，第 1 部分: 選擇 SOA 的原因和時機”
  
  
• developerWorks 文章 “面向服務的體系結構（SOA）：對 IBM Workplace 和 Lotus 開發人員的採訪”
  
  

獲得產品和技術

• 從 developerWorks 可下載 Lotus Domino 試用版。
  
  
• 從 developerWorks 可下載 Lotus Notes 試用版。
  
  

討論

• 參與論壇討論。
  
  
• 通過參與 developerWorks blogs 加入 developerWorks 社區。

關於作者

		Julian Robichaux 是專門研究 IBM Lotus Notes 和 Java 開發的軟件開發人員和專業程序員。他擅長於各種與開發、架構及培訓有關的項目。在業餘時間，他喜歡在 http://www.nsftools.com 上添加個人 Web 站點/博客。他的家人無法理解他爲什麼總要隨身攜帶筆記本電腦，就連他自己也不是很清楚其中的原因。