從事分行端應用程式的開發,週邊設備的使用一向是個很大的挑戰,一方面是因為一般程式設計者對較低階難度高的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 正式時候.
可否進一步說明一下狀況
Kevin的說明十分專業,令人佩服.但是對於J/XFS在分行系統的使用狀況還是有點需要請您補充以便學習.其實我同時關切的是現在有哪些銀行是用J/XFS的硬體設備.使用狀況如何,是否已經大規模的在銀行內實施.如果是這樣,我想應該有很多硬體廠商想要去標案子了耶 呵呵!對了 還要請問那WOSA在分行的狀況呢
回覆: WOSA/XFS,JXFS 在分行的使用狀況
抱歉 那麼晚才回覆你的問題, 其實不管是 WOSA/XFS 或 JXFS 在台灣金融業使用其實也是這幾年的事,當然因微軟在台灣是主流派,所以用 WOSA/XFS 較多. 就我所知,如玉山,聯邦,安泰,富邦,郵局的郵匯,郵務窗口等都有採用(WOSA/XFS 或 JXFS) ,聽說未來的郵遞系統也將使用.
但除了少部分是真的用到 WOSA/XFS 或 JXFS 的 form 的標準(例如郵局),其他銀行大部分是使用 WOSA/XFS 或 JXFS 提供直接控制硬體的 api 直接控制硬體(原本這個 api 是為了針對各廠牌獨特的功能,提供特殊用途之用, 但這將無法用在其他廠牌,也就是說是非標準規格下的特殊用法),完全失去了使用 WOSA/XFS 或 JXFS 的意義. 這其實是對 WOSA/XFS 或 JXFS 認知的錯誤所致,我甚至看過有軟體廠商,在 WOSA/XFS 或 JXFS 的form 上再自己訂一個 form 的格式然後自己處理 form 後再 call 那個 api,試問這和直接 call driver有何不同, 完全將 WOSA/XFS 或 JXFS 當作 device driver 使用,而不是將它們當作一套標準的規格來用, 最後以訛傳訛,間接造成對 WOSA/XFS 或 JXFS 的誤解.
所以分行端末也一樣嗎
所以我們可以說分行端末跟ATM一樣沒有很成功的產生通用軟件嗎?
其實很可惜
或者是說沒有很了解如何正確使用較為洽當, 我所看到的只有郵局是正確的使用(當然或許還有其他我不知道的).
我經常跟銀行資訊室的人談,其實有很多銀行有興趣,甚至已經採用,但他們都不知道軟體開發廠商並沒有正確的使用,因為他們也不懂,等開發完驗收了,即使後來知道怎麼回事,改也來不及了.
如果因為不了解它們的用法,只把它們當傳統的 direct I/O api 來使用,那是看不到它們的優點的, 其實是很可惜的.
其實沒有很同意你的看法
我們都知道優點,但是我懷疑比方說郵局,真的有達到說只要符合XFS的硬體都可以隨意替換嗎?
不知道POS上如果要上JAVA，是按照J/XFS呢，还是JAVAPOS，还是GPD的STIP呢？
KEVINTZ 你好，我是pos的开发人员，不知道POS上如果要上JAVA，是按照J/XFS呢，还是JAVAPOS，还是GPD的STIP呢？另外，J/XFS的官方网站在哪里呢？可否告知？谢谢:)
J/XFS的官方网站是: http://www.jxfs.net
POS 我不熟,無法給你建議.你可以參考 jxfs,javapos... 有無符合你的需要,
只要能夠掌握住 "被業界認同的標準介面規格" 這個原則就可以了.
J/XFS的官方网站是: http://www.jxfs.net
缺點是一定會有的
也許在實際使用上有一些缺點,我不知道,也許有郵局的人能說明會較清楚,但沒有什麼東西是完美的,軟體技術本來就是一直在進步,xfs, jxfs 都還在繼續發展,如果要等到完美的東西出現才能用,那可能永遠只有等待.
郵局這麼多次的 wosa/xfs 的標案是大家都知道的,從郵務窗口到郵匯業務也都是用 wosa/xfs 也是事實, 郵遞也將採用 J/XFS(因為用 java 開發),我想不會沒有原因.
缺點是一定會有的,但重點是當前是否符合你的需求.如果有其他選擇並非一定要使用 xfs 或 jxfs 不是嗎 ?
雖說WOSA/JXFS有標準，但是你買一台存摺印表機，廠商並不會附贈對應的Driver
K姐說Kevin大有文章，我來表示一點意見...
當你買了一台印表機，會不會附贈Widnows的Printer Driver? 這時候應用程式只要用標準的Window Printer API call就可以了。
雖說WOSA/JXFS有標準，但是買一台存摺印表機，廠商並不會附贈對應的Driver，或是Driver有問題（這網站每次說的I公司就是如此），如果真的用了標準去撰寫程式，那做出來的東西必定有問題。
所以說JXFS技術的優點包括：
* 設備無關性,銀行還可以方便地轉換硬體供應商.
--> 理想上是如此，但光是 IBM 公司的產品就上不了。
* 可以跨平台.
--> 如果有native level call，本來就跨平台，之前有作過pin pad直接打com port，完全跨平台。
* 提供遠程裝置資源分享.
* 設備集中管理.
--> 以上兩點沒問題。
* 透過 Java applet, 可直接在 web browser 叫用 J/XFS.
--> 只有能不安裝，才算是優點，事實上JXFS在server叫用更好。
* 同時可用WOSA/XFS和IBM LANDP做為底層驅動裝置.
--> 這不是優點吧。
如果要等到完美的東西出現才能用，那可能永遠只有等待。
沒問題，這不是硬體廠商的工作嗎? 買硬體不提供驅動程式，或是要花大錢來買驅動程式合理嗎?
買資料庫，會給jdbc驅動程式，但是買Comminication server，JCA的驅動程式卻要 1M/cpu。還是要等待合理的價格與80%可用的產品出現才行。
大概回覆一下
大概回覆一下:
1. 當你買了一台印表機，會附贈Widnows的Printer Driver,但買一台存摺印表機，廠商並不會附贈對應的Driver，或是Driver有問題（這網站每次說的I公司就是如此），如果真的用了標準去撰寫程式，那做出來的東西必定有問題.
-->我想沒有人會天真的認為廠商的附贈是免費的吧,其實都已計算在產品售價中,只是市場的大小不一樣,價格相較之下當然較貴(舉例吧,一支滑鼠的利潤能有多少,但數量卻可能是以百萬計).
其實 wosa/xfs 或 jxfs 從某種角度來看他的原理就是像 windows driver 一樣,只是從 OS 變成了 AP 去叫用,至於Driver有問題,那應該是硬體廠商的問題,當然要硬體廠商修正,像windows的硬體廠商不是也經常會有driver或firmware的fix 嗎?
2.JXFS技術的優點這部分我沒有寫清楚,其中有些是 jxfs 相較於 wosa/xfs,如:物件導向, thin client.
3.如果有native level call，本來就跨平台，之前有作過pin pad直接打com port，完全跨平台
-->直接輸出 com port 的方式,跨平台當然沒問題, 但問題是你能保證,所有的 device 都有提供這種方式嗎? pin pad 這種簡單的功能你或許可以應付,若是複雜的控制,除非你要很瞭解 rs232 的通訊規格,否則一般人根本做不到
4.光是 IBM 公司的產品就上不了
-->如果沒有像 microsoft 這樣擁有足夠市場的公司能夠主導,強迫廠商一定要依照 windows driver 規格來寫 driver 現在會是怎樣的情景.所以有沒有支援是取決於市場,這種小錢IBM當然看不在眼裡, 但 IBM 自己沒提供,不代表沒有,否則 BTT 裡怎麼會有 WOSA, jxfs 的 service 呢? 由此可知 IBM 也是建議使用 WOSA, jxfs.
5.只有能不安裝，才算是優點，事實上JXFS在server叫用更好
-->wosa/xfs ,JXFS device 一定要配一個 spi 或 device service 不能不安裝,所以除非你將所有 device 都接在同一台電腦(Server?), 只需安裝一台電腦, 否則只要有接 device 就必須安裝.
6. 同時可用WOSA/XFS和IBM LANDP做為底層驅動裝置,這不是優點吧
-->如果全世界只有 java 一種程式語言那確實不是優點. 因為一台 PC 可能不是只跑一個程式,若有其他用 C/C++,VB,Cobal...寫的程式要共用 device 呢?
關於 wosa/jxfs 1, 2, 3
1, 2, 3 是個人觀感，想想9068已經賣了多少年，9068的driver (wosa/jxfs)，9068的價錢，再看看你的回答。
4. jxfs的設定繁複，不容易更改,...BTT裡面那個半成品的 xfs/jxfs...,IBM內部文件說BTT不要用 wosa/jxfs...
5. 你說的是安裝，我想的是browser無active x下的印表方式
6. 說反了吧，jxfs只能用java，而landp你要用c了，只有用comm port才是通用語言，不然你要用web service的模式，web service當然可以把client當server
回覆你的問題 1, 2, 3, 4
1. 9068的價錢，再看看你的回答
--> 我不懂 9068的價錢和 wosa/xfs 或 jxfs 有什麼相關, 再說又不是只有一家供應商, 如果認為 IBM 價格太貴(IBM 價格貴,這又不新聞),就更換別家供應商,但現在很多銀行想換不能換的原因很多是 AP 被 device 绑住(正因為直接使用 com port, AP 才被 device 绑住).
2. jxfs的設定繁複，不容易更改,...BTT裡面那個半成品的 xfs/jxfs...,IBM內部文件說BTT不要用 wosa/jxfs...
--> jxfs的設定繁複, 我也不知道什麼程度叫繁複(SNA, DATABASE,J2EE.... 的設定不繁複嗎 ?), 在我認為只有經常設定才叫繁複,但沒事不會經常更改設定吧.所以重點應該是他的穩定性及是否需要經常更改設定.
-->我想 IBM 這樣的公司還不至於像一般小公司一樣需要做假廣告或沒東西賣需要賣半成品騙客戶來砸自己招牌,他能賣高價不就是靠這塊招牌嗎? 至於IBM內部文件有沒有說BTT不要用 wosa/jxfs, 我不是 IBM 員工,我不知道,但我前面提的那些使用 xfs/jxfs 的銀行,大部分是用 IBM 的 BTT/WSBCC.若是真的有,我想也不是xfs/jxfs 的問題,恐怕是怕被其他廠牌取代,而失去市場佔有率.
3. 你說的是安裝，我想的是browser無active x下的印表方式
--> JXFS 也不需要 active x
4.說反了吧，jxfs只能用java，而landp你要用c了，只有用comm port才是通用語言，不然你要用web service的模式，web service當然可以把client當server
--> 我不是說不用 comm port 而是不應該由 AP 直接控制, 而且像 device 應該要透過一個扮演 manager 角色的元件來控管,才不會互相衝突 (wosa/ landp 就是扮演 manager 這個角色), 至於 jxfs是不是只能用java，而landp是不是一定要用c呢? 正確,也不正確, 應該說 jxfs 的 AP 只能是java程式,也正是如此要底層 device service 透過 jni 做到(請看 jxfs 的架構圖).用comm port才是通用語言這點我不同意(例如可以透過 USB,LPT...), java 要列印怎麼做, 他也是透過 OS 的 api 而非直接控制 device 來列印不是嗎? 如果是這樣不是就如同透過 xfs/jxfs 是同樣意思
Add new comment