基於 Lotus Expeditor on Device 的手機銀行交易開發

轉自：http://www.ibm.com/developerworks/cn/lotus/expeditor-mobilebank/index.html

前言

隨著 3G 無線網路的發展、手持裝置上網速度的提高、手持裝置的效能提高、移動技術和規範的發展、以及越來越龐大的手持裝置上網使用者群，手機等無線手持裝置渠道已經成為銀行多渠道平臺的一個非常重要的組成部分。所以，近年來國內外很多銀行也都紛紛加大了手機渠道的投入。

從手機銀行的架構來說，主要有兩種方式：B/S（Browser/Server）和 C/S（Client/Server）；從手機銀行業務來講，則包括 手機銀行交易開發，以及 手機特色業務（如基於位置的服務）二者。由於篇幅所限，這一篇文章主要介紹手機銀行的一些特點，以及基於 Lotus Expeditor，也就是 C/S 架構的富客戶端的手機銀行交易開發。

文章的幾位作者具有豐富的手機銀行開發經驗，將就自身經驗和大家一起討論手機銀行的現狀、特點、架構，以及交易開發等內容。

手機銀行的重要性

正所謂哪裡有使用者，哪裡就有業務，近年來手機銀行的逐漸“走紅”離不開廣大的使用者基礎。在國內，手機使用者群已經是個非常龐大的使用者群體。根據 CNNIC（中國網際網路絡資訊中心）釋出的《中國手機上網行為研究報告》和《中國手機媒體研究報告》報告顯示，2008 年中國手機使用者達到 6.4 億，手機上網使用者達到 1.176 億，每天多次使用手機上網的使用者接近 4000 萬。在歐洲等已開發國家，手機使用率和手機上網率要比中國等發展中國家更高。

圖 1. 手機上網使用者比例

通過報告，我們知道手機上網使用者群體正在每年不斷增長，而這些使用者都是潛在的銀行手機渠道的潛在使用者，可觀的使用者群體可以看出手機渠道對銀行電子渠道的重要性。根據 Berg Insight 機構的研究報告，全世界的手機銀行使用者將從 2008 年的 2000 萬，以每年 89% 的年增長率增長，預計到 2014 年，全世界手機銀行的使用者量將達到 9.13 億。Berg insight 分析師說：“在新興市場中，移動銀行正逐漸成為主要的電子服務渠道。”

圖 2. 2008 年和 2014 年全世界手機銀行使用者
 

手機銀行的特點和現狀

手機銀行作為繼網上銀行、電話銀行、POS 機之後的又一大銀行服務創新。在傳統的銀行前端渠道（Front Office）系統中，網點由於地域時間限制只能服務於有限客戶，傳統網上銀行由於軟硬體特性也有一定的侷限性，手機渠道的產生使企業的服務平臺突破了以往所有的銀行前端渠道的侷限，實現了實時的 3A 式服務，即任何時間 (Anytime)、任何地方 (Anywhere) 和任何方式 (Anyhow)。手機銀行具有以下特點：

1. 貼身特性 – 方便，實時：

   作為網上銀行的派生產品之一，手機銀行和網上銀行相比，具有“貼身特性”，它比網上銀行更方便、實時。客戶利用手機銀行在任何地方和任何時間都可以方便、及時的交易，延伸了銀行的服務群體和廣度，也能一定程度緩解 ATM 機和銀行網點的排隊等候時間。手機的貼身、實時的特性，延伸了手機炒股、炒匯、證券、手機電子商務熱潮。

2. 成本低

   對銀行來說，手機銀行是銀行渠道前端轉型的重要渠道之一。手機銀行的交易成本僅為傳統方式的五分之一。據統計，國外傳統櫃檯每筆交易成本為 1.07 美元，而使用手機銀行每筆交易成本則只為 0.16；國內櫃檯每筆交易成本約為 4 元，手機銀行每筆交易成本則只有 0.6 元。一方面在方便使用者的同時，能減少了銀行的成本；另一方面銀行也能釋放出員工進行中間業務等更高附加值的服務，從勞動密集型渠道轉型向知識密集型渠道。

3. 裝置特性 – 螢幕小，顯示差異性大

   手機銀行顧名思意是依賴於手機上執行，手機相比於 PC 的一個特性就是顯示螢幕小。另外，當前的手機廠商數目繁多，手機型號更是不斷更新換代，造成了當前的手機型號多，各型號顯示螢幕存在較大的差異性的特點，比如各種手機型號的螢幕尺寸，解析度，色素等差異。這種裝置的差異對手機銀行的應用會造成一定的影響。因為很難開發一種手機銀行應用去符合所有的裝置需求，根據螢幕的大小來決定顯示的內容長短，根據螢幕的解析度來顯示圖片等。所以當前很多銀行的做法是開發符合最低配置手機配置的需求。這一定程度上影響了大部分手機銀行使用者的使用者體驗。

手機銀行對商業銀行電子渠道至關重要，而當前手機銀行技術和業務的特點和現狀大大限制了它能產生的作用。在國內商業銀行中，當前的手機銀行基本是作為網上銀行的交易的延伸，沒有給客戶帶來新的增值的服務，由於螢幕硬體的限制易用性也很差，不能和銀行的網點或其它渠道形成有效的整合和交叉銷售。所以當前雖然手機上網使用者群體很多，但手機銀行的使用者群體還相對較少。目前國內外銀行的手機銀行的現狀和侷限如下：

1. 較少的手機特色業務和新的商業模式，單純作為網上銀行的交易延伸：

   從目前國內手機銀行應用來看，大多是傳統網上銀行的延伸。包括繳費業務，如賬戶查詢、餘額查詢、賬戶的明細、轉賬、銀行代收的水電費等；信用卡業務，如賬單查詢、還款通知、自動還款、額度設定等；理財業務，如炒股和炒匯等。這些業務是傳統的櫃檯和網上銀行的業務，通過手機銀行這個新平臺服務客戶。

   手機銀行更多更重要的價值是新的業務和商業模式的誕生，如基於位置的服務、近距離支付、虛擬貨幣、二維碼支付等等。這些新的商業模式會帶為銀行使用者帶來增值服務，同時也是銀行的新的利潤增長點。

2. 沒有體現營銷的理念：

   現在的商業銀行同質化競爭日趨激烈，金融市場猶如電器市場一般，陷入紅海戰爭，陷入價格戰的博弈中。如信用卡市場，各大商業銀行為了搶奪市場，免年費，送禮品，積分換好禮，各種促銷活動層出不窮，而且各種信用卡的產品定位和功能類似，同質化競爭搶奪非常激烈。

   銀行要在激烈的競爭市場中佔據一席之地，就需要充分了解客戶、挖掘客戶需求、把合適的產品在使用者合適的價值生命週期內通過合適的渠道推給合適的客戶。此外，銀行的各個渠道應無縫的結合，為客戶提供統一的、良好的客戶服務。

   當前的手機銀行更多的是資訊平臺和交易平臺，而不是一個營銷的渠道平臺。

3. 較差的使用者體驗：

   當前國內外的手機銀行使用者使用者體驗不太令人滿意。

   • 當前的手機銀行是銀行為主，提供的內容、資訊、服務是從銀行的角度進行設計和釋出，而每個客戶由於需求層次不一樣，個性喜好都不一樣，導致對銀行服務的需求也是不一致。但當前的手機銀行上使用者很難在手機銀行上找到自己需要的服務、感興趣的資訊。
   • 當前的手機銀行在不同的手機型號上不能展示很好的效果。不能根據使用者手機的螢幕寬度、解析度、色彩，區分使用者的手機型號。

回頁首

基於 Lotus Expeditor On Device 的手機銀行的架構

對於傳統的應用程式而言，有兩種程式架構，一種是 C/S 架構，一種是 B/S 架構，對於手機裝置的應用程式，也有這兩種架構。接下來，我們比較一下這兩種架構 C/S 和 B/S 優缺點：

1. C/S 架構的優缺點

   C/S 的優點：具有客戶端硬體裝置、儲存檔案的訪問能力，例如地理位置服務需要客戶端硬體的支援，這時候應用程式必須採用 C/S 架構才能訪問客戶端的硬體。第二個優點，就是 C/S 架構，一般客戶端提供 UI 的展示，所以響應速度更快，展示能力更強。此外，還可以支援離線處理，即手機銀行沒有連線在網際網路上時，也可以進行操作，並在連線時和遠端服務同步。

   C/S 的缺點：需要在客戶端安裝單獨的軟體，造成一定使用上的不變，此外維護和升級的成本較高。

2. B/S 架構的優缺點

   B/S 的優點：可以在任何地方、任何時候訪問手機銀行，只需要手機內嵌瀏覽器即可，而無需安裝任何專門的軟體。所有的維護成本都是在伺服器端，客戶端無需版本控制、升級等維護成本。

   B/S 的缺點：因為所有的展示邏輯和業務邏輯都放在伺服器端，所以不能充分發揮客戶端的運算能力，所有的壓力都在伺服器端；此外瀏覽器的展示能力和響應速度也很難和單獨的客戶端相比；最後就是無法訪問客戶端的硬體裝置和儲存，無法離線執行。

基於 Lotus Expeditor On Device 的手機銀行，相容了以上兩種架構的優點同時又克服了兩種架構的缺點：

• 第一，它提供工具來開發豐富的客戶端的 UI 展現，從而充分利用客戶端的計算能力來提高響應速度和展現能力，提供給客戶豐富的客戶體驗。

• 第二，它提供了本地端的程式設計方式，可以訪問客戶端的硬體裝置和儲存檔案，如本地檔案儲存，GPS 裝置，計算器，簡訊電話等功能。

• 第三，提供客戶端軟體的自動更新和升級方法，從而降低了維護和升級成本。

基於 Lotus Expeditor on Device 的手機銀行架構如下圖所示：

圖 3. 基於 Lotus Expeditor On Device 的手機銀行架構圖（檢視大圖）

架構中包括手機銀行客戶端，客戶端與伺服器端通訊連線，渠道整合伺服器，業務邏輯層，與銀行主機通訊連線等幾個部分。手機銀行交易的序圖圖如下所示：

圖 4. 手機銀行交易時序圖（檢視大圖）

基於 Lotus Expeditor On Device 的手機銀行交易開發

如上面架構所示，手機銀行的交易包括幾個部分：介面及介面邏輯開發，與渠道伺服器通訊，交易邏輯，與後臺主機核心銀行通訊。下面以轉賬交易為例，依次介紹手機銀行交易開發的各個部分邏輯：

手機銀行客戶端介面和邏輯開發

Lotus Expeditor 的客戶端介面基於 Eclipse 的嵌入式富客戶端平臺（eRCP）。eRCP 把 Eclipse 的富客戶端平臺（RCP）帶到嵌入式領域。它是基於 SWT 的 widget（稱作 eSWT）和基於 JFace 的高階 widget（稱作 eJFace）的子集。eRCP 由以下元件構成：

• 標準部件工具包（eSWT）：桌面 SWT 的一個子集，它又分為兩部分，核心 eSWT，包含基本的功能和簡單的 widget。擴充套件的 eSWT, 包含了更多複雜的 widget 和佈局。
• eJFace：提供了一系列的擴充套件於 eSWT 的類，使 eRCP 的應用程式可以和 eWorkbench 整合。
• eWorkbench：支援多個 eRCP 程式協作的 UI 框架。
• eUpdate：提供了一系列的 API 和介面來動態更新裝置上的軟體。

下圖是基於 Lotus Expeditor eRCP 的手機銀行轉賬交易交易介面展現：

圖 5. 手機銀行轉賬交易介面展現

下面是轉賬交易介面的示意程式碼。

清單 1. 轉賬交易手機客戶端頁面程式碼

				
 Composite container = new Composite(parent, SWT.NONE); 
 accountFromCombo = new Combo(container, SWT.NONE); 
 accountFromCombo.setBounds(25, 64, 170, 20); 
 accountFromCombo.setItems(new String[] { CurrentUser.accounrNumber }); 
 accountToCombo = new Combo(container, SWT.NONE); 
 accountToCombo.setBounds(25, 126, 170, 20);  

 moneyText = new Text(container, SWT.BORDER); 
 moneyText.setBounds(25, 188, 170, 20); 

 Button btnSubmit = new Button(container, SWT.NONE); 
 btnSubmit.addSelectionListener(new SelectionListener() { 
	 public void widgetDefaultSelected(SelectionEvent arg0) { 
	 } 

	 public void widgetSelected(SelectionEvent arg0) { 
	 } 
 }); 
 btnSubmit.setBounds(49, 214, 60, 20); 
 btnSubmit.setText(Messages.getInstance().getString("Button.Submit")); 

 Button btnBack = new Button(container, SWT.NONE); 
 btnBack.addSelectionListener(new SelectionListener() { 
	 public void widgetDefaultSelected(SelectionEvent arg0) { 
	 } 

	 public void widgetSelected(SelectionEvent arg0) { 
		 Util.getInstance().gotoView(TransferView.this, Menu.ID); 
	 } 
 }); 
 btnBack.setBounds(115, 214, 60, 20); 
 btnBack.setText(Messages.getInstance().getString("Button.Back")); 

 Label label = new Label(container, SWT.WRAP); 
 label.setAlignment(SWT.LEFT); 
 label.setBounds(25, 28, 170, 30); 
 label.setText(Messages.getInstance().getString("TransferView.AccoutFrom"));  

 Label label = new Label(container, SWT.WRAP); 
 label.setBounds(25, 90, 170, 30); 
 label.setText(Messages.getInstance().getString("TransferView.AccoutTo")); 
 label.setAlignment(SWT.LEFT); 

 Label label = new Label(container, SWT.WRAP); 
 label.setBounds(25, 152, 170, 30); 
 label.setText(Messages.getInstance().getString("TransferView.money")); 
 label.setAlignment(SWT.LEFT); 

手機銀行客戶端端與渠道伺服器通訊

開發完相應介面後，接下來是客戶端和銀行的渠道伺服器通訊。通訊時，會把介面端收集的業務資料封裝，並呼叫伺服器端相應的業務邏輯，等待伺服器端執行完業務邏輯後，把返回結果顯示在客戶端。與銀行渠道伺服器的互動模組是通過 MobileChannelAdaptor 介面卡元件來實現，該模組和渠道伺服器互動，傳送交易請求以及交易資料，並返回處理結果給手機客戶端。MobileChannelAdaptor 介面卡可以通過多種協議方式與後臺渠道伺服器互動，有 HTTP、Web Service、MQ 訊息等方式。對於手機的客戶端，由於安裝了 Lotus Expeditor 和 IBM J9 Java 虛擬機器，它提供了對 HTTP、Web Service、JMS 等協議的封裝。

下面是轉賬交易中通過 HTTP 協議和後臺渠道伺服器互動的例項，交易的請求和交易引數通過序列化將 Java 物件通過 HTTP 協議傳送到伺服器端進行通訊，執行的結果也可以通過序列化從伺服器端傳送到客戶端。

清單 2. MobileChannelAdaptor 模組的 HTTP 協議實現

				
HttpConnection connection = ConnectionFactory.getConnection(query); 
if (cookie != null) { 
    connection.setRequestProperty("cookie", cookie); 
} 
ObjectOutputStream stream = null; 
OutputStream s = null; 
try { 
    connection.setRequestMethod(HttpConnection.POST); 
    connection.setRequestProperty("User-Agent", "mobile"); 
    if (param != null) { 
        s = connection.openOutputStream(); 
        stream = new ObjectOutputStream(os); 
        stream.writeObject(param); 
        os.flush(); 
    } 
    return processResponse(connection); 
} finally { 
    try { 
        if (stream != null) { 
            stream.close(); 
        } 
        if (os != null) { 
            os.close(); 
        } 
        if (connection != null) { 
            // close the connection 
            connection.close(); 
            connection = null; 
        } 
    } catch (Exception e) { 
        // do nothing; 
    } 
} 

交易邏輯開發

銀行渠道伺服器處理各個不同渠道傳送過來的業務請求，手機銀行只是其中的一個渠道。通過 MobileHandler 元件接受 MobileChannelAdaptor 介面卡傳送過來的業務請求，並執行交易邏輯。

一般來說一個交易邏輯包括渠道邏輯和業務邏輯兩個方面，渠道邏輯主要包括渠道控制、渠道管理，以及多渠道互動。業務邏輯是銀行業務流程執行。由於篇幅關係，這裡不介紹渠道邏輯。下圖是轉賬交易的業務邏輯：

圖 6. 轉賬交易業務邏輯圖

簡單來說，轉賬交易由業務操作，以及業務操作之間的邏輯跳轉組成。上圖的轉賬業務邏輯由轉賬限額判斷、連線主機、轉賬、記日誌、傳送通知簡訊等幾個轉賬交易操作組成。其中中間部分的“轉賬”業務操作，是將轉賬交易資料封裝並呼叫下面主機通訊模組在主機上執行轉賬交易，示意程式碼如下所示：

清單 3. 轉賬交易其中的轉賬業務邏輯步驟程式碼

				
public class TransferOperation extends BTTServerOperation { 
    public void execute() throws Exception { 
        Account fromAccount = (Account) this.getValueAt("fromAccount"); 
        Account toAccount = (Account) this.getValueAt("toAccount"); 	    
        Double transferAmount = (Double) this.getValueAt("transferAmount"); 

        // 通過主機連線呼叫主機邏輯
        boolean result = transfer(fromAccount,toAccount,transferAmount);  
        this.setValueAt("resultBean.result", result);  
    } 
} 

良好的業務邏輯是與渠道特性無關的，即可以被多渠道複用。基於統一的多渠道平臺，手機銀行開發的業務邏輯可以被 ATM，網上銀行等渠道複用。達到多渠道複用的目的。

主機通訊

銀行的核心交易發生在銀行主機系統中，所以業務邏輯需要和主機通訊，按照主機的通訊協議、資料格式來呼叫主機邏輯。在手機銀行交易中，我們利用 SNA Adaptor 介面卡模組與銀行主流的 SNA 協議的 Lu0，Lu62 主機通訊。和 OSI 模型相對，系統網路架構（SNA）由 IBM 提出，也是最為流行的網路架構模型之一。

1. LU0 （用於 LUA）：LU0 是早期的 LU，支援最初的程式間通訊。有些主機資料庫系統，例如資訊管理系統 / 虛擬儲存（IMS/VS）以及一些零售商店和銀行使用的收款機（如 IBM 4680 儲存系統作業系統）採用的都是 LU0。當前的各種版本也支援 LU62 通訊，而 LU 62 是開發新應用程式的首選協議。
2. LU62（用於 APPC、5250、APPC 應用程式組和 CPI-C）：LU 62 支援分散式資料處理（distributed data processing）環境下的程式間通訊。LU62 資料流既可以是通用資料流（是一種結構化欄位資料流），也可以是使用者定義資料流。可以用於兩個 5 類節點間、一個 5 類節點和另一個 2.0 類或 2.1 類節點間、或者兩個都是 2.1 類節點間的通訊（2.1 類節點可以當作 APPN 節點使用）

轉賬交易中，和主機通訊的示意程式碼如下：

清單 4. 轉賬交易和主機通訊的程式碼

				
// 採用 Lu0 協議和主機通訊的程式碼：
public class SendHostStep extends OperationStep { 
	   public void execute() throws Exception { 
        Lu0SnaSessionService lu0Instance = (Lu0SnaSessionService) getService("host"); 
        // 1 - Format the data. messageToSend is a formatted string 
        String messageToSend =getHostSendFmt().format(getContext()); 
        // 2 - Instantiate semaphore and response handler 
        lu0Instance.addHandler(this, "allEvents"); 
        setHostSemaphore(new Semaphore()); 
        // 3 - Send the formatted Message and wait for the semaphore 
        lu0Instance.send(messageToSend); 
        getHostSemaphore().waitOn(10000); 
         // 7 - If semaphore has been signaled, data already in context 
        if (getHostSemaphore().hasTimedOut()) { /* Timeout */ 
            throw new DSEException(DSEException.harmless, "000000000000", "TimeOut"); 
        } 
         // 8 - Remove the operation as handler 
        lu0Instance.removeHandler(this, "allEvents"); 
    } 
} 


// 採用 Lu62 協議和主機通訊的程式碼：
public class SendHostStep extends OperationStep { 
    public void execute() throws Exception { 
        Lu62Conversation aConversation = (Lu62Conversation)getService("myConversation1"); 
        // 1) Format the data, messageToSend is a formatted string: 
        String messageToSend = ((FormatElement)getHostSendFormat()).format(getContext()); 
        // 2) Instantiate semaphore and response handler: 
        handleEvent("allEvents", "myConversation1", getContext()); 
        setHostSemaphore(new Semaphore()); 
        // 3) Send the formatted message and wait for the semaphore: 
        aConversation.sendAndPrepareToReceive(messageToSend); 
        getHostSemaphore().waitOn(10000); 
        // 7) If semaphore has been signaled, data already in context 
        // 7a) If timeout expired, raise an exception 
        if (getHostSemaphore().hasTimedOut()) { 
            throw new DSEException(DSEException.critical, "000000000000", "TimeOut"); 
        } 
        // 7b) Remove the operation as handler 
        else { 
            stopHandlingEvent("allEvents", "myConversation1", getContext()); 
        } 
    } 
} 

手機銀行的會話管理

在手機銀行交易開發中，還需要考慮會話管理問題。因為手機銀行是有狀態的，所以與渠道伺服器存在會話管理。不同的連線協議需要應用不同的會話管理方案，如對於 Web Service 協議來說，它是無狀態的，所以需要在系統中自動的生成會話 ID，並在手機銀行的客戶端和伺服器端管理會話生命週期。

對於上面介紹的採用 HTTP 協議和伺服器進行通訊的情況下，對於會話的管理，可以依賴於 HTTP 的 session 會話管理機制，就是當客戶端和伺服器進行通訊時，生成 session ID，然後保留在客戶端的 cookie 物件中，然後在後來的每次和渠道伺服器的通訊過程中，都利用該會話 Session ID 來管理會話。下面客戶端和渠道伺服器的會話管理示意程式碼：

				
 public boolean establishSession() throws Exception { 
    Map query = new HashMap(); 
    query.put("createSession", "true"); 
    HttpConnection connection = ConnectionFactory.getConnection(query); 
    try { 
        connection.setRequestMethod(HttpConnection.POST); 
        connection.setRequestProperty("User-Agent", "mobile"); 
        int responseCode = connection.getResponseCode();  
        if (responseCode == HttpConnection.HTTP_OK) { 
            String setCookie = connection.getHeaderField("Set-cookie"); 
            System.out.println(setCookie); 
            int i = setCookie.indexOf(";"); 
            if (i == -1) { 
                return false; 
            } 
            cookie = setCookie.substring(0, i); 
            return true; 
        } 
        return false; 
    } finally { 
        try{ 
            if (connection != null) { 
                connection.close(); 
                connection = null; 
            } 
        } catch (Exception e) { 
				
        } 
    } 
} 

當客戶端建立連線時，伺服器端將會話 session 的資訊自動傳遞回來，客戶端會保留會話 Session 資訊在客戶端 Cookie 物件中，以後每次傳送請求時，都會將 Cookie 的資訊一起傳遞到服務端。

手機終端裝置管理

Lotus Expeditor Client for Device 提供了一個可延伸的平臺，讓採用此結構的開發者可以快速的開發出適合在手機上執行的應用程式。這些應用可以獨立的直接執行程式邏輯（如一連串交易表單的輸入），只在所有在終端輸入完成之後（如提交表單後）才與伺服器連線完成交易，而不需要讓手機保持隨時連線的狀態。這對於目前手持裝置運算效能越來越好，行動上網連線品質卻還未能達到普及和穩定來說，此結構不但減少了開發的成本，更提供了符合手機特性的應用執行環境。但是將此結構與目前一般網路銀行普遍採用的 web-based 結構相比，其部署成本卻可能因此增加不少。適用於桌上型電腦的 web-based 應用程式的部署與更新只需要將開發測試完成的應用部署在應用伺服器上，即完成了部署，使用者只要把瀏覽器連上伺服器，就可以使用最新版的應用程式。而 Lotus Expeditor 的應用如果沒有一個完整的管理方式，將新的版本的應用程式自動的安裝到每一支手持裝置上的執行環境，勢必將造成部署成本的增加。

因此 Lotus Expeditor Server 所提供的 Expeditor Client Management 管理服務，正是為了加速部署並且提供可靠以及充分的終端裝置管理情報為主。Expeditor Client Management 可以將每個開發測試完成，並放置在 eclipse update site 的應用 application ( 或特性 feature)，一次性的下達安裝應用的工作指令給指定的使用者端群組。系統管理員不僅可以通過管理介面看到此部署工作的完成進度和完成比率，更可以利用此服務查詢特定使用者端執行環境上的所有應用 / 特性。並針對其應用 / 特性下達更新或移除的工作指令。

在手機銀行的環境中，由銀行主動提供不同的服務來滿足不同客戶的需求是必要而且吸引人的，這可以藉由在 Expeditor for device 中所提供的 eclipse preference 技術來達成。由客戶設定自己的喜好設定，經由應用程式把這些喜好設定存貯在 eclipse preference 中，最後由 Expeditor Client Management 根據這些喜好設定再配合 server 上的 client filter 功能從遠端把不同的服務提供給需要的客戶來達成主動服務以及客製化的效果。

相較於 web-based 的應用程式，Lotus Expeditor 的應用程式在程式有新的版本或需要修改時，都必須再做一次更新的動作，這包含了下載新的程式，安裝，甚至重新啟動 Lotus expeditor 平臺的時間，並不像 web-based 的應用程式，所顯示的內容都是更新過的。不需要再花更新的時間。在 Lotus Expeditor 中，除了提供 web container 和 web application model 的 framework，更可以用 eclipse property 技術來達成部份更新，舉個例來說：當客戶有一個 Expeditor 應用程式裡面含有某個銀行首頁的 url，程式設計師可以把 url 用 eclipse property 記錄下來，當這個 url 改變時，遠端的系統管理者可以用 Expeditor Client Management 所提供的 property control task 來達成 url 的部份更新，而不需要整個程式做完整的更新。

除了提供安裝部署應用 / 特性的服務，Expeditor Client Management 也可查詢終端裝置執行環境上的設定，增加管理者客製化或效能優化執行環境提供便利性。也就是手持裝置的使用者不需要管理在自己手機上 Lotus Expeditor Device 的設定和應用，這些工作將由 Expeditor Client Management 的系統管理者來完成。

圖 7. Expeditor 客戶端管理架構圖

圖 6 是 Expeditor Client Management 的裝置管理結構圖。Expeditor Server 包含了 Expeditor Client Management service，在 Lotus Expeditor on Device 中有 Device Agent 元件通過 Http or SSL 網路跟 Expeditor Client Management 做註冊的動作，一旦註冊完成，在 Expeditor server 中就會有一個 entry 來記錄剛註冊上的裝置，系統管理者就可以用 web 介面的 Administrator console 通過 Expeditor Client Management service 遠端管理已註冊的裝置。而應用程式 (eclipse update site) 可以放置在的 http server 上，當系統管理者執行一個遠端應用程式安裝或更新的任務，可以通知在裝置上的 device Agent 元件來執行這個任務，而 update installer 元件就會被驅動去 http server 下載 update site 安裝。除了應用程式的管理之外 Expeditor Client Management 也提供了其他功能，更多的資訊請參考 Expeditor infocenter。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14751907/viewspace-625473/，如需轉載，請註明出處，否則將追究法律責任。