從事分行端應用程式的開發,週邊設備的使用一向是個很大的挑戰,一方面是因為一般程式設計者對較低階難度高的I/O控制不了解, 二方面是各家廠牌提供的driver控制方法通常相差很大(所有的硬體廠商都希望只用他們的機器) .
一定有人會問為什麼這些硬體不像滑鼠這樣,一接上 PC , 應用程式就可以直接使用呢? 其實目前世界上早就有兩種標準, WOSA/XFS 與 J/XFS 來規範銀行週邊設備 (同時均被納入歐洲標準 CENT), 其中 XFS 是 Microsoft 主導, 只能用在Windows 和 OS/2 (等於只有Windows ), 另外 J/XFS則是IBM跟SUN主導,參考 XFS 制定給 Java 平台使用...
從事分行端應用程式的開發,週邊設備的使用一向是個很大的挑戰,一方面是因為一般程式設計者對較低階難度高的I/O控制不了解, 二方面是各家廠牌提供的driver控制方法通常相差很大(所有的硬體廠商都希望只用他們的機器) .
一定有人會問為什麼這些硬體不像滑鼠這樣,一接上 PC , 應用程式就可以直接使用呢? 其實目前世界上早就有兩種標準, WOSA/XFS 與 J/XFS 來規範銀行週邊設備 (同時均被納入歐洲標準 CENT), 其中 XFS 是 Microsoft 主導, 只能用在Windows 和 OS/2 (等於只有Windows ), 另外 J/XFS則是IBM跟SUN主導,參考 XFS 制定給 Java 平台使用.
目前， J/XFS 標準包括下面幾種設備類型的規範：
- Printer(收據印表機、日誌印表機、存摺印表機、文檔印表機)
- Check Reader/Scanner
- Cash Dispenser (現金分配器、現金回收器、ATM)
- Personal Identification Number (PIN) Keypad
- Identification Card (IC卡讀寫器、磁條卡讀寫器)
- Text Terminal Unit
- Vendor Dependent Mode
- Alarm
- Sensor and Indicator Units
- Camera
除了和 WOSA/XFS 一樣具有設備無關性,銀行可以方便地轉換硬體供應商的優點外,J/XFS技術相較於 WOSA/XFS 的優點包括了：
- 採用物件導向的設計.
- 可以跨平台.
- Thin client的解決方案.
- 提供遠程裝置資源分享.
- 設備集中管理.
- 透過 Java applet, 可直接在 web browser 叫用 J/XFS.
- 同時可用WOSA/XFS和IBM LANDP做為底層驅動裝置.
試想若像郵局這樣, 有這麼多家支局, 設備又要分批公開招標的單位那要怎麼辦? 是只選定某一廠牌(有圖利廠商之嫌), 還是每購入不同牌子硬體, 就修改應用程式(可能不只一個應用系統,難維護, 光是每次修改後的測試就要命了); 當然還有一個辦法就是,買 b 廠牌但模擬 a 廠牌來用 (但要用 a 廠牌的 driver, 若 a 廠牌禁止 b廠牌使用它的 driver 呢?). 所以郵局在幾年前就採用了 XFS 的標準. 這幾年隨著 Java 的迅速普及和 Linux 的受到重視, 我們也看到更多銀行開始使用 J/XFS 來一次解決長遠的需求 (如上所言 J/XFS Device Service 不只可單獨在 J/XFS 環境運作, 還可以搭配 WOSA/XFS 或 LANDP 使用, 才真是一次購買永久使用呢).
使用 J/XFS 標準, 不但可使行內所有軟體程式開發有所規範, 具有良好的可移植性和伸缩性, 容易維護外, J/XFS 規範了一個穩定的架構, 使應用邏輯和硬體設備邏輯都是分離的, 兩邊都只和 J/XFS 的核心溝通, 實現硬件更換與應用程序升級之間的無關性, 降低應用程式開發的難度. 技術難度高的部分也就是實際控制硬體的部分, 是由提供 J/XFS 的專業服務廠商來解決, 就像 WINDOWS 下要使用各式各樣的滑鼠並不需要自己開發driver 或透過不同的 API 是相同的道理..
至於曾經在one in SH's blog ”關於銀行自行維護ATM端末軟體的技術與可能性”一文中提到這類通用型軟體目前在 ATM 專案中成功的機率不是太高的原因, 我想跟ATM上面已有一些市佔較高的端末應用控制程式有關, 而這在一般分行系統內並不存在. 以下是我個人對分行系統使用 J/XFS 類似問題的看法 :
- 使用者付費觀念的欠缺, 造成軟體廠商的被動:
硬體的驅動技術並非一般銀行資訊人員所能掌控, 軟體廠商定義了自己的架構後, 也多了自己的一些操控空間, 在台灣使用者付費的觀念還是欠缺, 提供 J/XFS 這類標準服務, 並沒有額外的利潤, 所以廠商不見得願意主動提出使用共通性的介面, 也因此有很多銀行並不知道有這樣的標準.
- 硬體廠商的私心:
硬體廠商都希望所有的專案軟體使用他們自己的東西, 所以提供共通性介面裝置驅動對高佔有率的廠商是不利的.
- 硬體及軟體技術難度高:
硬體廠商通常專注在硬體方面, 對這類共通性介面裝置驅動軟體程式了解較少, 更缺乏對 Java 熟悉的人才. 軟體廠商則對硬體的控制驅動,缺乏相關的人才, 技術難度是比較高的, 都要投入相當多的成本, 所以相對的 J/XFS 較少有廠商提供, 所幸現在已有專業服務廠商針對現有硬體開發 J/XFS 裝置驅動, 並可對新的裝置從事撰寫服務, 如此一來只要再要求應用軟體廠商爾後準此規範, 一切就天下大同了.
如前面所說應用程式並不會實際控制硬體, 而是叫用共通的應用介面, 所以若是邏輯上錯誤那一定是應用程式的問題, 若是硬體沒有正確的動作那必定是提供的 J/XFS服務有問題, 而且這些都可以在採購前的測試標(資格標)中解決. 而且過去一但選中那家廠商, 其他廠商就幾乎註定沒希望了(因為軟體硬體無法切開), 但使用 J/XFS 軟體硬體是切開, 所以落選廠商還是有機會的, 因此採用 J/XFS 的技術, 銀行可以完全自主採購符合規格需求又經濟實惠的硬體設備, 當然舊有週邊設備也可繼續沿用, 大幅降低建置成本,何況還有軟體維護的成本也大大降低, 多花一點成本, 可以得到的效益絕對物超所值. 標準化已是未來的趨勢, 日前 J/XFS 3.01 已經正式 release, 技術上也更趨成熟, 對目前有意更新分行系體的銀行來說, 採用 J/XFS 正式時候.