追根究底還是OMCS-從OMCS到SOA

前題,先對OMCS(Online Mission Critical System)作一個定義:On-Line Real-Time ,End-to-End Service,Quick Response Time,High Transaction Throughput, Transaction Management(Load Balance, Exception handling, Fault isolation, Commit or Rollback, Logging and Recovery) and well design capability...以上大致涵蓋OMCS必要的技術與經驗.
1980年代,是一個單純的連線環境(Propriety,INQ/ANS...)CICS是一個符合OMCS需求的好產品,可惜它是一個Single Procssor產品,不似IMS是一個Multiple Procssor的產品(交易量的考慮),所以日本大銀行都就IMS而捨CICS.(筆者個人主觀Fujitsu的AIM也較類似IMS).台灣就比較多樣化了,有些銀行選擇CICS(第一,中國國際)有些則選擇了IMS(合庫,華銀)基本上兩者都是當時最成熟的OMCS產品,就看技術者的偏好而已.依筆者主觀看法當時銀行選系統其實是在選OMCS產品,否則當時也有許多知名廠商例如Burrough,NCR,Fujitus,NEC在銀行IT領域技術經驗都不錯,但是其OMCS產品如COMS,TOX,AIM,VIS知名度技術面略遜CICS,IMS,所以競爭力就不如IBM了.
1990年代,跨異質OMCS間的交易需求開始,典型的範例就是金資跨行交易.最理想的情況下當然是跨多個OMCS的交易但是Quality of Service仍然需維持如單一OMCS一樣水準,但是以當時技術的觀點是做不到的(最多只能解決到"連結"-通訊協定與電文格式,甚至不保證訊息送達,更不要說UOW).另外從應用設計的觀點"同步型"交易也是不適當的,對金資的系統言,因為中介的角色,"非同步型"顯然較合適(response/throughput),雖然recovery要費一番功夫(因為系統面無法提供,只好應用系統設計自己考慮).這個階段,即使進行系統間交易的整合,考慮的重心仍擺在OMCS.
2000年代,因應銀行自身應用系統的多樣化,而這些應用系統多數開發在與核心系統相異的OMCS環境,但是應用上必要與核心系統整合,所以跨系統的整合技術與規格便非常迫切與需要.與金資系統比較雖是雷同但其實有很大不同.金資系統應用範圍與型式固定,所以系統間的整合規格可以說是量身定製的,也可說是專屬的系統.但是2000年代銀行IT所需的整合需要的是工業級的技術規格與產品,代表性的產品EAI此時是受到關注與期待的解決方案.只不過牽涉到複雜的應用需求與新舊技術的格格不入,EAI有理想的外表下其實技術是不完備的,EAI最大的特徵應是"異質OMCS系統間訊息的保證送達-MQ技術",所以只堪稱是Message Broker腳色擔當而已,這點雖然是異質OMCS交易交談的關鍵技術,但是並未對被整合的對象有多大的幫助,C計劃專案就是一個最佳範例.然而EAI仍舊有其貢獻之處,畢竟連接方式從過去P2P,進化到Hub-spoke也算是一大進步了.這個階段,雖說考慮的重心已逐漸轉從OMCS轉移至AP的結合.但是換個角度看,也可說OMCS已是基本需求而不需再強調了.
2006現在,SOA被提出來,SOA基本精神就是從應用面思考系統間整合(同質或異質),簡單的說就是各個系統本身是服務(Service)的需求者(Requester)也是供給者(Provider),系統間彼此交換情報(Data),至於技術對方系統是如何做是不需考慮的,對使用者而言,他得到的是一個E2E的服務.在這樣的前題下Loosely coupling,Function Decomposing,Standard formatting,End to End service,Enterprise Service Bus等等功能標準需要系統提供者共同遵守.目前SOA概念與規範已獲得廠商與客戶的支援,多數廠商也提供相關產品,過雖然都宣稱支援SOA產品,只不過技術水準仍然有很大的差別.以筆者看來過去長於支援OMCS環境下Middleware的大型廠商仍會佔儘優勢,大型金融客戶其實也沒有太多選擇,倒是小型客戶,規格沒必要定那麼高,倒是有很多的選擇,銀行客戶剩下來要改變的是-應用系統的設計觀念,過去是"功能包資料",往後是"資料包功能"了,何謂?下章再談.