介紹
在
2008年10月發(fā)行的Dr Dobbs雜志中，Michael Swaine撰寫了題為
《您的下一代語言是COBOL嗎？》的文章。他指出，“每年新增的數(shù)十億行COBOL代碼”證明了當(dāng)前傳統(tǒng)大型機應(yīng)用的規(guī)模和強度仍在繼續(xù)發(fā)展。毫無疑問，整合大型機應(yīng)用和分布式系統(tǒng)，尤其是基于Java的系統(tǒng)，仍然是一個重要的課題。
這些年來人們在大型機集成中積累了很多經(jīng)驗，其中一個慘痛教訓(xùn)是系統(tǒng)間的緊耦合是不可取的。當(dāng)然，除了大型機應(yīng)用之外，應(yīng)用間的技術(shù)差異正在進一步擴大：比如一些應(yīng)用是基于COBOL、CICS/IMS，另一些應(yīng)用是基于Java、J2EE、Eclipse的。具有不同生命周期、由不同開發(fā)者使用不同工具開發(fā)出的應(yīng)用之間存在著過多的依賴，這些導(dǎo)致了系統(tǒng)的脆弱和不穩(wěn)定。
大型機集成商很早就采用了面向服務(wù)架構(gòu)（SOA），這導(dǎo)致了受SOA啟發(fā)的第一代大型機集成解決方案的出現(xiàn)。這些解決方案的大多數(shù)是以大型機為中心的，在某種程度上是將COBOL綁定到XML和直接運行在大型機之上的SOAP消息傳遞系統(tǒng)。
最近，由于某大型IT社區(qū)對
企業(yè)集成模式的推廣和作為SOA基礎(chǔ)設(shè)施的
企業(yè)服務(wù)總線（ESB）的出現(xiàn)，大型機集成有了新的可選架構(gòu)。本文中，我們將提倡一種以ESB為中心的大型機集成的新觀點，同時也將介紹一種實現(xiàn)這個架構(gòu)的開源解決方案，即在
JBoss ESB中使用LegStar實現(xiàn)大型機整合。
以大型機為中心的第一代整合框架所突顯出的局限性和成本MichaelSwaine指出，COBOL語言正在通過自身不斷地發(fā)展來支持XML，像CICS系統(tǒng)現(xiàn)在也支持SOAP。除了IBM，還有許多供應(yīng)商在大型機上將COBOL綁定到XML和SOAP協(xié)議棧上。近幾年來，專注于遺留集成系統(tǒng)的分析師一直贊同這種以大型機為中心的整合方式，即將XML和SOAP直接運行在大型機上。
由于當(dāng)時標(biāo)準(zhǔn)的大型機SOAP棧還沒有出現(xiàn)，大部分以大型機為中心的集成商不得不開發(fā)自己的SOAP棧。有些甚至還自己開發(fā)XML解析器。
然而從那之后，SOA和Web服務(wù)發(fā)展非常迅速。幾年前，只要提供基本的XML處理和SOAP 1.1就足以聲稱是面向服務(wù)的。再后來，客戶對SOA的期望和認(rèn)識逐步清晰，開始采用新標(biāo)準(zhǔn)，如WS-*。因此對集成商而言，維護自己開發(fā)的SOAP棧的成本快速增長。
大型機開發(fā)人員缺少像開源所能提供的大型開源社區(qū)和豐富資源。因此，一些大型機的SOAP棧還不支持SOAP1.2或者WS-Addressing規(guī)范，而這些規(guī)范則是許多WS-*規(guī)范的基礎(chǔ)。相比之下，Apache中最新發(fā)布的Axis2，其大小為20MB，其中包括了59個lib，覆蓋了SAAJ（SOAP1.1和SOAP1.2）、XML Schema、WSDL 1.1和WSDL2.0、WS-Addressing、Fastinfoset、WS-MetadataExchange、MTOM、WS-Policy等規(guī)范。
另外，許多新技術(shù)還在不斷涌現(xiàn)，如
RESTful WebServices。在Google、Yahoo和Amazon的支持下，這類架構(gòu)越來越受歡迎，并且針對RESTful WebServices的Java API已經(jīng)成為JSR 311規(guī)范，這足以說明RESTful WebServices的受歡迎程度。作為XML的輕量級替代品的JSON也備受關(guān)注。比如Axis2已經(jīng)支持JSON 。在不久的將來，使用RESTfulWebServices集成大型機應(yīng)用和對JSON的支持很可能會成為需求，而且還可能會給本來就已經(jīng)很長的需求列表中增加更多的項目。除了基本W(wǎng)eb服務(wù)功能外，對Web服務(wù)編排和腳本語言的需求也已經(jīng)出現(xiàn)，這給以大型機為中心的開發(fā)團隊帶來了更大的壓力。
SOAP出現(xiàn)后，這些以大型機為中心的解決方案，不僅在功能方面長期滯后，而且也遭受了因草率而做出的設(shè)計決定所帶來的痛苦。
例如，以大型機為中心的解決方案往往將綁定層、消息傳遞層和傳輸層緊耦合在一起。相反，開源社區(qū)則強調(diào)將語言綁定（比如，從Java到XML的綁定）從傳輸和消息傳遞中清楚地劃分出來。在Java中，符合JSR 222的Java for XMLbinding（JAXB）通常是獨立于任何Web服務(wù)技術(shù)而實現(xiàn)的；可以將它同SOAP或者RESTful WebServices一起使用。同樣，消息傳遞和傳輸通常也是相互獨立的，除了可以將SOAP消息使用HTTP/HTTPS傳輸之外，也可以將它使用JMS或TCP傳輸。因此，以大型機為中心的解決方案很難適應(yīng)不斷變化的SOA。
在設(shè)計上，以大型機為中心的集成解決方案也把大型機作為IT基礎(chǔ)設(shè)施的中心來考慮。分布式應(yīng)用被看作是大型機的外圍應(yīng)用。這導(dǎo)致了一種非對稱的大型機集成愿景，其中唯一的需求（或是最重要的需求）是這些外圍應(yīng)用消費大型機資源。隨著分布式應(yīng)用重要性的日益顯現(xiàn)，大型機應(yīng)用不再相互孤立。最近，許多以大型機為中心的集成商感覺到了威脅，并開始提供向外發(fā)送請求的功能，但是它們極少經(jīng)過徹底改造，而這正是支持一個使IT基礎(chǔ)設(shè)施中的大型機角色更為平衡的愿景所需要的。在大型機上的SOAP客戶端功能非常薄弱和有限，這嚴(yán)重制約了對外部分布式服務(wù)的訪問。
最后，以大型機為中心的集成的另一個重要問題就是成本。大型機的軟件許可證和維護費用非常昂貴。開源不會或許永遠(yuǎn)不會涉及到這些費用問題。另外，XML和SOAP處理是一種CPU密集型活動。大型機的CPU成本仍然相對較高，雖然IBM的某些舉措對此有所緩解。
總之，對于以大型機為中心的整合提供商，要遵循最新的Web服務(wù)標(biāo)準(zhǔn)，響應(yīng)新需求，適應(yīng)大型機應(yīng)用的變化角色以及由開源普及的新費用結(jié)構(gòu)，變得越來越困難。
以ESB為中心的下一代大型機集成在開源社區(qū)中，企業(yè)服務(wù)總線（ESB）已成為SOA的最佳基礎(chǔ)設(shè)施。ESB支持多種傳輸協(xié)議、注冊服務(wù)、消息轉(zhuǎn)換、服務(wù)編排等功能。從某種程度上，它們涵蓋了曾經(jīng)由私有的企業(yè)應(yīng)用集成（EAI）平臺涉及的領(lǐng)域。
以ESB為中心的大型機集成解決方案通過建立在ESB架構(gòu)之上，充分利用了這些優(yōu)勢。例如，將COBOL綁定到Java或XML就是作為ESB的內(nèi)部轉(zhuǎn)換活動處理的。大型機中的消息交換可以使用ESB標(biāo)準(zhǔn)傳輸協(xié)議或現(xiàn)有的傳輸協(xié)議。大型機應(yīng)用程序還沒意識到ESB的優(yōu)勢，ESB也可以與其他大型機交換數(shù)據(jù)。
在開源社區(qū)中，ESB社區(qū)非?；钴S，與大型機相比，社區(qū)中的年輕開發(fā)人員能更好地理解ESB。ESB得益于大型的開源社區(qū)，同時它也直接面臨著新技術(shù)的挑戰(zhàn)，如BPM、動態(tài)語言和RESTful WebServices。BPM和BPEL已經(jīng)廣泛運用于ESB，但以大型機為中心的集成解決方案卻面臨著很多挑戰(zhàn)。借助以ESB為中心的集成，大型機集成能直接參與復(fù)雜的業(yè)務(wù)流程。
和以大型機為中心的解決方案一樣，以ESB為中心的大型機集成工具在設(shè)計時和運行時都起到了作用。相同的是，設(shè)計時工具需要將COBOL映射成復(fù)雜的數(shù)據(jù)類型。不同的是，以ESB為中心的設(shè)計時工具所生成的制品是專門針對ESB的。這些制品一旦部署到ESB，它們將把大型機的數(shù)據(jù)流轉(zhuǎn)換成開放世界中的對象。數(shù)據(jù)轉(zhuǎn)換是ESB的功能之一，并受益于ESB的多線程、可伸縮架構(gòu)。
ESB為中心的大型機集成還得益于豐富的XML優(yōu)化技術(shù)，如今在開放社區(qū)，這些技術(shù)廣泛用于減少內(nèi)存消耗，以及降低處理XML所消耗的CPU使用率。可以說，分布式平臺上的CPU成本比大型機上的要便宜得多，但最重要的是，像profiler這樣成熟的工具已經(jīng)廣泛地在Java中使用，而在大型機中尤為少見。以ESB為中心的解決方案可以更好地監(jiān)測和控制CPU或內(nèi)存消耗，從而降低整體集成成本。
在以ESB為中心的解決方案中，所生成制品與任何可以部署在ESB上的制品（Java,XML,jars等)是一致的。這意味著這些制品可以使用豐富的管理工具（源代碼控制、構(gòu)建控制、依賴管理和持續(xù)集成等）來管理，而且可以被單元測試、測量和保護。集成制品是非常重要的開發(fā)制品。它們往往是事務(wù)性系統(tǒng)的關(guān)鍵部分。在以ESB的為中心的解決方案中，這些制品可以看作是軟件開發(fā)生態(tài)系統(tǒng)中的一等公民。
和以大型機為中心的SOAP堆棧相比，ESB還提供了一個更高層次的抽象層。為了說明這一點，可參考下面的用例：在分布式平臺中，大型機應(yīng)用所消費的服務(wù)是由大型機之外提供的。因為分布式環(huán)境的特性日益增多和在IT資產(chǎn)中發(fā)揮越來越大的作用，分布式環(huán)境提供引用數(shù)據(jù)和流程也越來越常見。在這種情況下，大型機上原有流程需要使用這些分布式功能。在以大型機為中心的集成解決方案中，COBOL程序會發(fā)出SOAP請求。相反，在以ESB為中心的集成解決方案中，COBOL程序?qū)δ炒翁厥獾南鬟f或者對它正在對話的分布式平臺一無所知。它只需是將大型機數(shù)據(jù)放入一個WebSphereMQ隊列中或是一個HTTP有效負(fù)載中。目標(biāo)服務(wù)和協(xié)議的細(xì)節(jié)被隔離在ESB的內(nèi)部。以ESB的為中心的解決方案提供了更高層次的解耦，這正是系統(tǒng)集成最期望得到的特性。
一種以ESB為中心的大型機集成解決方案：LegStar和JBoss ESBLegStar for JBoss ESB是一種開源的大型機集成技術(shù)，它是第一個專門面向ESB作為整合平臺的方案。本文演示了如何使用Redhat的開源ESB——JBossESB和LegStart讓大型機的COBOL程序訪問外部系統(tǒng)。這種組合架構(gòu)使用同步或異步消息傳遞（這是大型機極少涉及的技術(shù)）有效地將大型機應(yīng)用和分布式流程進行了解耦。
用例我們將為COBOL消費者暴露一個Java對象（Plain Old Java Objec或者POJO ）。
LegStar for JBoss也能滿足更經(jīng)典的用例，即COLOBL程序被暴露給Java消費者。但當(dāng)COBOL代碼作為客戶端時，尤其是對松耦合要求比較高時，會面臨一些特殊挑戰(zhàn)。
LegStar for JBoss也可以讓COBOL代碼訪問ESB服務(wù)和Web服務(wù)。出于簡單考慮，本用例中我們選擇消費一個POJO。
架構(gòu)在大型機一側(cè)，我們假設(shè)COBOL是開發(fā)語言，WebSphere MQ是傳輸機制。
在服務(wù)器端，我們使用免費的開源技術(shù)：
JBoss ESB和
LegStar。
部署架構(gòu)如下：
[url=resource://Legs4JBossESB-article-architecture.png]
[/url]
對于這個架構(gòu)選擇有如下幾點值得說明：
WebSphere MQ和JBoss ESB之間的數(shù)據(jù)交換使用原始數(shù)據(jù)你也可以選擇使用HTTP與ESB交換數(shù)據(jù)，但WebSphereMQ已在大型機上得到廣泛使用，與HTTP相比它能提供更好的異步消息。COBOL代碼可運行在TSO中，作為一個批處理程序運行在CICS或IMS中。WebSphere MQ API正好適用于這些環(huán)境，甚至更多。
COBOL程序?qū)⒃嫉拇笮蜋C數(shù)據(jù)發(fā)送到WebSphere MQ隊列。在大型機上這個內(nèi)容不需要轉(zhuǎn)換。這意味著JBoss ESB只需要接收原始的大型機數(shù)據(jù)。這樣做有兩個優(yōu)點：
[li]在大型機上減少了CPU消耗（無數(shù)據(jù)轉(zhuǎn)換）[/li][li]大型機并不需要知道它在跟一個非大型機平臺交換數(shù)據(jù)[/li]
就解耦來說，第二點尤其重要。
雖然架構(gòu)圖顯示了一個在z/OS上運行的WebSphere MQ管理器，但是在分布式平臺可能存在另外一個WebSphere MQ管理器。為了架構(gòu)簡單，我們并沒有給出額外的管理器，同時也因為這樣做并不是必需的。
從ESB的角度來看，我們使用一個標(biāo)準(zhǔn)的監(jiān)聽器與JBoss ESB連接在一起。這是一個高性能、多線程的監(jiān)聽器，它能夠支持來自大型機的高負(fù)荷傳入消息、并發(fā)和請求。
在大型機上，客戶端代碼的交互可以是同步的或異步的COBOL客戶端代碼可以使用標(biāo)準(zhǔn)WebSphere MQ API等待響應(yīng)，也可只要請求發(fā)送后就返回。異步通信模式是通過使用WebSphere MQ標(biāo)準(zhǔn)的觸發(fā)機制實現(xiàn)的，在收到應(yīng)答后COBOL程序可以處理應(yīng)答。
異步是可取的，因為它減少了系統(tǒng)間的依賴。這種消息交換模式同樣也適用于ESB。
JBoss ESB服務(wù)是COBOL客戶端程序和POJO之間的一個代理JBoss ESB支持多種傳輸協(xié)議并提供了我們這里使用的通用管道的概念。
JMS網(wǎng)關(guān)是一個標(biāo)準(zhǔn)的JBoss ESB的監(jiān)聽器，它負(fù)責(zé)監(jiān)聽WebSphere MQ隊列，當(dāng)接收到消息時會觸發(fā)一系列動作。JBoss自帶了一些開箱即用的工具，比如我們這里會用到的對象調(diào)用器或JMS路由器。
列集/散集（marhaling/unmarshaling）原始大型機數(shù)據(jù)所需要的消息轉(zhuǎn)換動作是由LegStart在設(shè)計時產(chǎn)生的，其細(xì)節(jié)將在下一節(jié)中描述。LegStar生成的制品是特定于JBoss ESB的，而且經(jīng)過專門優(yōu)化。
在某種程度上，ESB代理服務(wù)使COBOL客戶端不受那些可能會導(dǎo)致目標(biāo)POJO改變的變更的影響。首先，改變POJO位置或軟件包的名字不會影響COBOL客戶端。你還可以在不影響客戶端的前提下為POJO添加新特性。當(dāng)然如果發(fā)生較大變化時，如刪除屬性或者改變屬性的類型，仍會對COBOL代碼產(chǎn)生一定的影響。
實現(xiàn)步驟本小節(jié)中我們描述了為POJO創(chuàng)建ESB服務(wù)代理的主要步驟，開發(fā)者可以按照這些步驟來操作。LegStar提供了Eclipse插件，簡化了開發(fā)。另外，相同的工具也可作為ant腳本獲得，但我們選擇LegStar的Eclipse插件，因為它更友好。
本實例的Eclipse項目代碼可以在
這里下載。
目標(biāo)Java對象（POJO）在本文中我們使用POJO，相同的做法也適用于JBoss ESB服務(wù)或ESB外的Web服務(wù)。
它不僅是一個Java對象，我們還期望該類被暴露成一個粗粒度的方法，接受參數(shù)為一個復(fù)雜對象，輸出則為一個對象，如果發(fā)生錯誤還會拋出異常。這種行為涉及到遠(yuǎn)程門面模式（
Remote Facade pattern ）。在這一模式中，輸入和輸出對象被稱為數(shù)據(jù)傳輸對象（
Data Transfer Objects）。在下文中，我們將稱這些對象為數(shù)據(jù)對象。
這里顯示了一種獨特的方法。表示請求的輸入數(shù)據(jù)對象被稱為JVMQueryRequest。它包含一組環(huán)境變量名。被稱為JVMQueryReply的輸出數(shù)據(jù)對象將包含一組被請求環(huán)境變量的值，以及一組本地化相關(guān)的值。
[pre]public class JVMQuery {
public JVMQueryReply queryJvm(JVMQueryRequest request) throws JVMQueryException {
ListenvVarValues = new ArrayList ();
try {
for (String envVarName : request.getEnvVarNames()) {
if (envVarName == null) {
throw new JVMQueryException(\"Invalid variable name\");
}
String value = System.getenv(envVarName);
if (value == null) {
envVarValues.add(\"Not found\");
} else {
envVarValues.add(value);
}
}
} catch (SecurityException e) {
throw new JVMQueryException(e);
}
JVMQueryReply reply = new JVMQueryReply();
reply.setEnvVarValues(envVarValues);
Locale locale = Locale.getDefault();
reply.setCountry(locale.getDisplayCountry());
reply.setLanguage(locale.getDisplayLanguage());
reply.setFormattedDate(
DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL,
locale).format(new Date()));
reply.setCurrencySymbol(Currency.getInstance(locale).getSymbol());
return reply;
}
}[/pre]
將Java數(shù)據(jù)對象映射到COBOL結(jié)構(gòu)當(dāng)原始大型機數(shù)據(jù)被傳送到ESB時，LegStar會將這個數(shù)據(jù)列集（marshal）到一個Java數(shù)據(jù)對象。這是LegStar所起到的作用。LegStar提供了設(shè)計時工具將COBOL結(jié)構(gòu)映射到XMLSchema和Java。它還提供了一個運行時綁定框架來完成原始大型機數(shù)據(jù)的列集/散集（marhaling/unmarshaling）。
LegStar還提供了Eclipse插件，允許用戶選擇Java對象和請求自動映射到COBOL結(jié)構(gòu)：
其結(jié)果是一個具有特殊COBOL注解的XML Schema。下圖中Eclipse的標(biāo)準(zhǔn)XML Schema編輯器顯示了JVMQueryReply的數(shù)據(jù)結(jié)構(gòu)：
[url=resource://Legs4JBossESB-article-mapping-1.png]
[/url]
您可能會注意到，有些COBOL屬性有默認(rèn)值。例如，字符串的默認(rèn)大小是32。這是因為COBOL只支持固定大小的字符串。類似的，COBOL不支持非固定的數(shù)組。在XML Schema編輯器中可以方便地修改這些默認(rèn)值。
生成COBOL綁定類LegStar的COBOL綁定類是Java類，這些Java類完成原始大型機數(shù)據(jù)到Java數(shù)據(jù)對象的列集/散集（marhaling/unmarshaling）。
在Eclipse插件中，可以從XML Schemas提取復(fù)雜類型（complext type）。然后你可以選擇需要生成綁定類的復(fù)雜類型。在下面的例子中，我們選擇輸入和輸出類型：
LegStar的COBOL綁定機制是建立在Java到XML的綁定框架之上的，它被稱為
JAXB 或 JSR 222。綁定過程會產(chǎn)生帶有COBOL注解的JAXB類。如果你打開一個已生成的JAXB類，就能看到Java對象中的每個屬性如何持有COBOL注釋：
[url=resource://Legs4JBossESB-article-binding-2.png]
[/url]
生成JBoss ESB的動作（Action）和簡單配置最后一步會生成一系列制品，以幫助部署和測試JBoss ESB的代理服務(wù)。在Eclipse中，我們選擇WebSphere MQ選項并指定目標(biāo)JBoss ESB服務(wù)應(yīng)當(dāng)部署的位置：
[url=resource://Legs4JBossESB-article-generating-1.png]
[/url]
LegStar會生成JBoss ESB示例配置文件，文件包含了處理管道的完整動作，以供測試。它還生成了COBOL客戶端示例代碼，這些代碼可以調(diào)用JBoss ESB的服務(wù)，并為開發(fā)做好準(zhǔn)備。
結(jié)論在JBoss ESB中使用LegStar是一個以ESB為中心的下一代大型機集成解決方案的例子。
這種新架構(gòu)具備如下特征：
[li]真正實現(xiàn)了雙向通信，根據(jù)情況，大型機代碼既可以是服務(wù)器，也可以是客戶端。[/li][li]對分布式服務(wù)而言，大型機COBOL程序是高度松耦合的。在本文的例子中，COBOL程序使用普通的WebSphereMQ隊列名作為其目標(biāo)服務(wù)。至于COBOL程序，目標(biāo)服務(wù)在網(wǎng)絡(luò)中其它大型機上，它可以使用Java或者PHP實現(xiàn)，借此，它可以在網(wǎng)絡(luò)的任何地方。ESB知道服務(wù)在哪里實現(xiàn)，或者至少知道如何將請求轉(zhuǎn)發(fā)給它。[/li][li]ESB可以在大型機代碼和目標(biāo)服務(wù)之間實現(xiàn)松耦合。總之，即使技術(shù)迅速發(fā)展，當(dāng)目標(biāo)服務(wù)發(fā)生變化時，也可以減少對COBOL程序的修改。[/li][li]大型機程序可以隨時參與復(fù)雜的工作流。不像本文中所描述的簡單管道，JBoss jBPM或Active Endpoints公司的ActiveBPEL能夠提供工作流和服務(wù)編排，大型機程序可以作為活動的參與者。[/li][li]使用標(biāo)準(zhǔn)、開放的技術(shù)，如XML Schema、JAXB、JAX-WS、JMS或HTTP，可以確保大型開源社區(qū)保持其活力。這與當(dāng)前以大型機為中心的SOAP協(xié)議棧形成鮮明對比，因為以大型機為中心的SOAP協(xié)議棧有些是使用匯編語言寫的，這些協(xié)議棧都是封閉、專有的，并且發(fā)展緩慢。[/li][li]所有生成的制品是友好、開放的：Java代碼、XML Schema、XML配置文件等。這樣可以使用強大的工具來管理這些制品，這些工具在Java社區(qū)中非常常見。[/li][li]減少了大型機內(nèi)存消耗。在我們的這種場景下，針對大型機根本沒有外來技術(shù)。使用COBOL編譯器和WebSphere MQ（或者可以使用HTTP）就足夠了。CPU密集型活動，如數(shù)據(jù)轉(zhuǎn)換和XML處理等，全部在大型機上消失，轉(zhuǎn)而移到CPU成本更低的平臺上。[/li]
COBOL和大型機應(yīng)用程序?qū)⒃诤荛L時間內(nèi)繼續(xù)存在。許多這樣的應(yīng)用程序可以很好地履行其職責(zé)。與此同時，以SOA和ESB為基石的開源應(yīng)用也正在逐步擴大規(guī)模。在這種背景下，以ESB為中心的大型機集成帶來的獨特優(yōu)勢是值得我們考慮的。
作
