計(jì)算機(jī)外文資料翻譯---要求操作系統(tǒng)環(huán)境下的解決方案白皮書

1、<p><b>　　外文資料翻譯</b></p><p><b>　　資料譯文</b></p><p>　　要求操作系統(tǒng)環(huán)境下的解決方案白皮書</p><p><b>　　面向服務(wù)的移植體系</b></p><p>　　作者：IBM全球服務(wù)部Kishore Chann

2、abasavaiah 和 Kerrie Holley, </p><p>　　和Edward M. Tuggle, Jr.，IBM 軟件部</p><p><b>　　2004年4月</b></p><p>　　//////////////////////////////////////////////////////////////////

3、//</p><p><b>　　內(nèi)容</b></p><p>　　2．介紹：發(fā)展面向服務(wù)體系的案例</p><p><b>　　3．問題1：復(fù)雜性</b></p><p>　　4．問題2：多余的不能再度使用的設(shè)計(jì)</p><p>　　4 問題3：多重接口</p>

4、<p><b>　　5 未來是怎樣的？</b></p><p><b>　　7 SOA的需求</b></p><p>　　8 SOA—不僅僅是網(wǎng)絡(luò)服務(wù)</p><p><b>　　10 服務(wù)的性質(zhì)</b></p><p><b>　　12 選擇舊問題&l

5、t;/b></p><p>　　14 系統(tǒng)的綜合需求</p><p>　　17 配置SOA的好處</p><p>　　19 未來：新模型新需求</p><p><b>　　21概要</b></p><p><b>　　21更多的信息</b></p><

6、;p>　　//////////////////////////////////////////////////</p><p><b>　　面向服務(wù)體系的移植</b></p><p>　　介紹：發(fā)展面向服務(wù)體系的案例</p><p>　　40多年來，IT系統(tǒng)以指數(shù)的速度增長，使公司面對(duì)要操作日益復(fù)雜的軟件體系。傳統(tǒng)的體系已經(jīng)到了他們性能的

7、極限，當(dāng)IT機(jī)構(gòu)堅(jiān)持傳統(tǒng)的需求，IT部門仍然需要對(duì)新的商業(yè)需求做出響應(yīng)，持續(xù)的降低商務(wù)的IT成本，有效地吸引和整合新的商務(wù)伙伴有效地吸引和整合新的商務(wù)伙伴和客戶。軟件行業(yè)已經(jīng)徹底達(dá)到了實(shí)現(xiàn)設(shè)計(jì)為允許完全的分布式處理多重處理體系，達(dá)到了程序語言可以實(shí)現(xiàn)運(yùn)行于任何平臺(tái)上并可以明顯減少執(zhí)行時(shí)間和無數(shù)的連通性產(chǎn)品設(shè)計(jì)為更好和更快的應(yīng)用軟件的綜合。無論如何，通用的方法是難以理解的。</p><p>　　現(xiàn)在，面向服務(wù)體系S

8、OAs正在被提倡作為下一代的先進(jìn)的方法，它可以幫助IT機(jī)構(gòu)面對(duì)他們不斷的更復(fù)雜的挑戰(zhàn)。但問題依舊存在：SOAs是真實(shí)的嗎？即使它們能夠被概括和描述，它們能實(shí)際執(zhí)行嗎？這個(gè)白皮書就是論述</p><p>　　如何使SOAs的許諾變成現(xiàn)實(shí)。在公開程度已經(jīng)有所下降之后，和所有的過度的期望已經(jīng)回歸真實(shí)，IT機(jī)構(gòu)IT機(jī)構(gòu)將會(huì)發(fā)現(xiàn)SOAs提供了一個(gè)IT機(jī)構(gòu)能夠建立新的應(yīng)用程序系統(tǒng)的最好的基礎(chǔ)，并且可以繼續(xù)利用現(xiàn)有的資產(chǎn)。白皮

9、書是第一個(gè)一系列的有意識(shí)的幫助你更好的理解SOA的價(jià)值， 并幫助你實(shí)現(xiàn)一個(gè)實(shí)際的計(jì)劃，能夠評(píng)估你當(dāng)前的基礎(chǔ)組織并把它們移植為面向服務(wù)的體系。</p><p>　　一段時(shí)間以來，網(wǎng)絡(luò)服務(wù)技術(shù)的存在已經(jīng)刺激了SOAs的討論。這個(gè)討論的內(nèi)容并不是新的了，這些概念現(xiàn)在已經(jīng)發(fā)展了十多年了，從CORBA被擴(kuò)展為完全不同平臺(tái)下應(yīng)用程序整體性的肯定性。</p><p>　　整合這些完全不同的應(yīng)用程序而引發(fā)

10、的問題，常常是因?yàn)檫@么多不同的（非CORBA適應(yīng)性）對(duì)象模型變得受歡迎。結(jié)果，很多架構(gòu)師和工程師在</p><p>　　解決建立一個(gè)充滿活力的體系的技術(shù)問題上陷入困境，而這個(gè)體系允許簡單，高效和高安全性的系統(tǒng)綜合，而應(yīng)用程序消失了。不幸的是，問題一直存在，而且每一年都變得更加復(fù)雜。根據(jù)最基本的商務(wù)需求使你為了更好的解決方案進(jìn)行研究。需求像低成本，降低周期時(shí)間，越過企業(yè)整合系統(tǒng)，整合企業(yè)到企業(yè)（B2B）和企業(yè)到客戶

11、(B2C)系統(tǒng)，達(dá)到投資的最快回報(bào)，和創(chuàng)造一個(gè)適應(yīng)的和能夠做出響應(yīng)的商務(wù)模型。但是更多的是，你將會(huì)發(fā)現(xiàn)點(diǎn)對(duì)點(diǎn)的解決方案不能解決基本的問題：缺乏一個(gè)相容的能夠讓你快速建立，整合和重復(fù)使用的應(yīng)用程序的體系框架。更重要的是，你需要一個(gè)能讓你集合各種結(jié)構(gòu)和服務(wù)來表述動(dòng)態(tài)解決方案就像你的商務(wù)需要解決的體系結(jié)構(gòu)。這個(gè)白皮書將超出討論為什么特殊的技術(shù)就像網(wǎng)絡(luò)服務(wù)是優(yōu)異的。它將會(huì)提供一個(gè)不受技術(shù)約束的體系觀點(diǎn)。開始，你應(yīng)該考慮一些基本的能夠使你的研究有

12、個(gè)好基礎(chǔ)的問題。你怎樣對(duì)待這些問題將決定你成功的程度。</p><p><b>　　問題1 ：復(fù)雜性</b></p><p>　　一些面向你的IT機(jī)構(gòu)商務(wù)問題是一貫的相似。公司管理層的管理努力爭取更好的利用IT資源，更豐厚的投資回報(bào)(ROI)，以往的獨(dú)立的系統(tǒng)的整合和新系統(tǒng)的更快的執(zhí)行。但是一些事情現(xiàn)在是不同的。環(huán)境越來越復(fù)雜。預(yù)算限制和操作的效率要求你重復(fù)使用繼承的

13、系統(tǒng)而不是取代它。廉價(jià)的，隨處可使用的INTER網(wǎng)已經(jīng)創(chuàng)造了建立全新的而你不得不進(jìn)行評(píng)估以保證和你的競(jìng)爭者同步的商務(wù)模型可能性。通過合并和獲得來成長已經(jīng)變成了標(biāo)準(zhǔn)的經(jīng)營，因此整個(gè)IT機(jī)構(gòu)，應(yīng)用程序，和基礎(chǔ)構(gòu)造必須是整合的和一致的。在這樣復(fù)雜的環(huán)境里，點(diǎn)對(duì)點(diǎn)解決方案不過是使問題惡化，并不會(huì)真正的解決這個(gè)挑戰(zhàn)。你必須建立一個(gè)能夠把不同種類的合并為你的IT環(huán)境的一個(gè)基本部分，因此它們能夠適應(yīng)硬件，操作系統(tǒng)，中間設(shè)備，語言和數(shù)據(jù)存儲(chǔ)的不停的變化

14、，數(shù)十年的成長和進(jìn)化的累積影響已經(jīng)造就了你現(xiàn)在必須解決的復(fù)雜性。 面對(duì)這些IT的商務(wù)挑戰(zhàn)，許多CIO把應(yīng)用程序的整合放在優(yōu)先考慮的時(shí)間表中是不足為奇的。</p><p>　　問題2 ：多余的和不能重復(fù)使用的設(shè)計(jì)</p><p>　　像許多公司，你的應(yīng)用程序包可能因?yàn)楹喜⒑瞳@得而增大。結(jié)果，你可能要處理多余的應(yīng)用程序—或功能不能容易的重復(fù)使用的應(yīng)用程序?？赡茉谀愕慕M織中的每一個(gè)商業(yè)團(tuán)體已經(jīng)和

15、其他的每一個(gè)團(tuán)體相互分離，有效的阻礙了任何一個(gè)同等的影響而創(chuàng)造可以重復(fù)使用的功能的資產(chǎn)或服務(wù)。全部的這些冗余增加交易的成本和時(shí)間而破壞新的產(chǎn)品或服務(wù)，因?yàn)樽兓呀?jīng)在每個(gè)受到影響的應(yīng)用程序或系統(tǒng)中產(chǎn)生。重復(fù)使用的缺乏從根本上要求更多的資源—和通常更多的時(shí)間—來表述新的應(yīng)用程序。</p><p><b>　　問題3：多重的接口</b></p><p>　　考慮到n(n-l

16、)整合問題。所有的機(jī)構(gòu)面對(duì)著一些種類的整合問題；可能因?yàn)閳F(tuán)體的合并，新的商業(yè)聯(lián)盟，或僅僅是相互連接現(xiàn)有系統(tǒng)的需求。如果n應(yīng)用程序系統(tǒng)必須直接相互連接，進(jìn)城將會(huì)建立n(n-l)連接，或是接口。在圖1中，每個(gè)箭頭表示一個(gè)接口。</p><p>　　////////////////////////////////////////////////////////</p><p>　　根據(jù)Aberd

17、een部，全球2000CIO的調(diào)查始終確定成本，復(fù)雜性和企業(yè)應(yīng)用程序整合（EAI）和商務(wù)對(duì)商務(wù)(B2B)的整合 的綜合時(shí)間作為他們的關(guān)注點(diǎn)之一。甚至在固定的預(yù)算和較低的利潤率，一個(gè)固定的整合策略的商業(yè)利益是如此的引人注目以至于那些CIOs預(yù)言他們將花費(fèi)他們預(yù)算的的35~60%在整合計(jì)劃上。</p><p>　　////////////////////////////////////////////////////

18、/////////</p><p>　　////////////////////////////////////////////////////////////</p><p>　　圖1 n(n-l)整合問題</p><p>　　////////////////////////////////////////////////////////////////<

19、;/p><p>　　因此，如果你必須整合另外的應(yīng)用程序系統(tǒng)A (n+1),你將需要設(shè)計(jì)，形成文檔，測(cè)試和維護(hù)2n的新接口。在圖1中，5個(gè)應(yīng)用程序的設(shè)置要求20個(gè)直接的接口。增加第六個(gè)應(yīng)用程序?qū)?huì)需要10個(gè)新的接口。并且為了擴(kuò)展性增加了復(fù)雜性，你必須修改每一個(gè)現(xiàn)有的應(yīng)用程序的代碼使其包含新的接口，設(shè)計(jì)實(shí)際的測(cè)試代價(jià)。為了降低這些代價(jià)和復(fù)雜性，你需要一個(gè)最優(yōu)的解決方案得到n應(yīng)用程序的最少的接口數(shù)n，只為每個(gè)系統(tǒng)增加一個(gè)新

20、的接口。 無論如何，直接的聯(lián)系是不能實(shí)現(xiàn)的。</p><p>　　未來怎么樣？在過去的40多年中，軟件發(fā)展已經(jīng)走過了幾個(gè)不同的建模階段。</p><p>　　每次變化都是局部以應(yīng)變巨大的軟件復(fù)雜性并使建構(gòu)師能夠通過局部，組件和服務(wù)整合應(yīng)用程序。最近，Java技術(shù)提供了一種跨平臺(tái)的編程方式。XML提供了自我描述，跨平臺(tái)數(shù)據(jù)?，F(xiàn)在網(wǎng)絡(luò)服務(wù)已經(jīng)遠(yuǎn)離了另外的通過應(yīng)用程序來連接其他的跨平臺(tái)對(duì)象模型屏

21、障。舉例來說，使用一個(gè)簡單的基于XML的消息配置，Java應(yīng)用程序能夠調(diào)用Microsoft. .NET應(yīng)用程序或CORBA-compliant,甚至COBOL，應(yīng)用程序。因此IBM CICS,或是IBM IMS.在新加坡主機(jī)上的處理能夠被運(yùn)行在慕尼黑的Lotus. Domino.服務(wù)器上的一個(gè)代理的輪流執(zhí)行的.NET應(yīng)用程序調(diào)用。最好的是，正在調(diào)用的應(yīng)用程序不必知道哪里的處理將會(huì)運(yùn)行，它是用什么語言寫的或消息將會(huì)走哪條路徑。一個(gè)服務(wù)被

22、請(qǐng)求，答案就會(huì)被提供。</p><p>　　網(wǎng)絡(luò)服務(wù)相比于以前的任何一個(gè)標(biāo)準(zhǔn)更可能是通過實(shí)際上的標(biāo)準(zhǔn)來表述有效的，可靠的和可擴(kuò)展的機(jī)器對(duì)機(jī)器的交互。一些必要的技術(shù)和文化上的先決條件及時(shí)地集中幫助這種表述的方式，包括：一個(gè)普遍存在的，基于開放標(biāo)準(zhǔn)的，低成本的網(wǎng)絡(luò)基礎(chǔ)，和提供了分布式環(huán)境的技術(shù)越來越有益于網(wǎng)絡(luò)服務(wù)的采用，而不是CORBA和分布式計(jì)算的計(jì)算環(huán)境（DCE）。接受的程度和技術(shù)的成熟度在網(wǎng)絡(luò)中心環(huán)境下運(yùn)行要求

23、協(xié)作來達(dá)到要求的商務(wù)目標(biāo)，例如分布式的協(xié)作。一致同意通過開放的基于互聯(lián)網(wǎng)的標(biāo)準(zhǔn)和相關(guān)技術(shù)的低成本協(xié)作是最好的達(dá)到目標(biāo)的方式?；诰W(wǎng)絡(luò)的技術(shù)的成熟（例如TCP/IP）;工具設(shè)置</p><p>　?。ňC合發(fā)展環(huán)境[IDEs]和統(tǒng)一模型語言[UML]平臺(tái)（例如Java2平臺(tái)，企業(yè)版[J2EE]）和相關(guān)方法論（例如面向?qū)ο骩OO]技術(shù)和服務(wù)），提供給基礎(chǔ)需要的促進(jìn)寬松的聯(lián)系和共同使用的機(jī)器對(duì)機(jī)器的交互—這種狀態(tài)比COR

24、BA使用者經(jīng)歷更先進(jìn)。</p><p>　　SOA可以是一個(gè)體系和一個(gè)程序模型，一種建立軟件思想的方式。SOA使你能設(shè)計(jì)通過公布的和顯露的接口提供服務(wù)給其他應(yīng)用程序的軟件系統(tǒng)，</p><p>　　并且在網(wǎng)絡(luò)上可以調(diào)用這些服務(wù)。當(dāng)你用網(wǎng)絡(luò)服務(wù)技術(shù)執(zhí)行SOA時(shí)，你就創(chuàng)造了一個(gè)新的建立更強(qiáng)大，更通用的設(shè)計(jì)模型的應(yīng)用程序的方法。你能降低你的發(fā)展和擁有的成本—和你的運(yùn)行風(fēng)險(xiǎn)。</p>

25、<p>　　在視野內(nèi)，無論如何，有更多的意義重大的機(jī)會(huì)。首先，網(wǎng)格計(jì)算，即以超過每秒處理百萬指令來實(shí)現(xiàn)計(jì)算的解決方案。網(wǎng)格計(jì)算將會(huì)提供一個(gè)框架能夠使你動(dòng)態(tài)查找，重新部署，平衡和管理眾多的服務(wù)因此你可以保證需要的應(yīng)用程序總是安全的可用，而不必系統(tǒng)中的登錄。這個(gè)框架，形成了能在任何結(jié)構(gòu)上執(zhí)行的計(jì)算需求上的觀念，從一個(gè)簡單的服務(wù)器群到有1024的節(jié)點(diǎn)的IBM SP2系統(tǒng)的網(wǎng)絡(luò)。如果一個(gè)用戶需要解決一個(gè)問題并需要提供適當(dāng)?shù)挠?jì)算資源給

26、它—不多不少—你只需為實(shí)際使用的資源付費(fèi)。有效的使用這些新的性能將要求改造許多現(xiàn)有的應(yīng)用程序?，F(xiàn)有的單片機(jī)能夠在這些環(huán)境下運(yùn)行，</p><p>　　但不會(huì)在最佳的方式下使用這些有效的資源。這些環(huán)境，伴隨著以前討論過的問題，意味著你的基礎(chǔ)結(jié)構(gòu)必須經(jīng)過一些基本的變革—到SOA的轉(zhuǎn)變。</p><p><b>　　資料原文</b></p><p>

27、　　On demand operating environment solutions</p><p>　　White paper</p><p>　　Migrating to a service-oriented </p><p>　　architecture</p><p>　　by Kishore Channabasavaiah and

28、 Kerrie Holley, </p><p>　　IBM Global Services, and Edward M. Tuggle, Jr., </p><p>　　IBM Software Group</p><p>　　April 2004</p><p>　　////////////////////////////////////

29、////////////////</p><p><b>　　Contents</b></p><p>　　2 Introduction: the case for developing a service-oriented architecture</p><p>　　3 Problem 1: complexity</p>&l

30、t;p>　　4 Problem 2: redundant and nonreusable programming</p><p>　　4 Problem 3: multiple interfaces </p><p>　　5 What about the future?</p><p>　　7 Requirements for an SOA</p>

31、<p>　　8 An SOA—not just Web services</p><p>　　10 The nature of a service</p><p>　　12 Addressing the old problems</p><p>　　14 Integration requirements within the architecture&

32、lt;/p><p>　　17 Benefits of deploying an SOA</p><p>　　19 The future: new models, new requirements</p><p>　　21 Summary</p><p>　　21 For more information</p><p>　

33、　///////////////////////////////////////////////</p><p>　　Migrating to a service-oriented architecture</p><p>　　Introduction: the case for developing a service-oriented architecture</p>&

34、lt;p>　　Over the last four decades IT systems have grown exponentially, leaving </p><p>　　companies to handle increasingly complex software architectures. Traditional </p><p>　　architectures h

35、ave reached the limit of their capabilities, while traditional </p><p>　　needs of IT organizations persist. IT departments still need to respond </p><p>　　quickly to new business requirements, c

36、ontinually reduce the cost of IT to </p><p>　　the business and seamlessly absorb and integrate new business partners </p><p>　　and customers. The software industry has gone through multiple comp

37、uting </p><p>　　architectures designed to allow fully distributed processing, programming </p><p>　　languages designed to run on any platform and greatly reduce implementation </p><p&

38、gt;　　schedules and a myriad of connectivity products designed to allow better and </p><p>　　faster integration of applications. However, the complete solution continues </p><p>　　to be elusive.&

39、lt;/p><p>　　Now, service-oriented architectures (SOAs) are being promoted as the next </p><p>　　evolutionary step to help IT organizations meet their ever more-complex </p><p>　　challe

40、nges. But questions remain: Are SOAs real? And even if they can be </p><p>　　outlined and described, can they actually be implemented? This white paper </p><p>　　discusses how the promise of SOA

41、 is true. That after all the publicity has </p><p>　　subsided, and all the inflated expectations have returned to reality, IT </p><p>　　organizations will find that SOAs provide the best foundat

42、ion upon which </p><p>　　an IT organization can build new application systems, while continuing to </p><p>　　capitalize on existing assets. This white paper is the first in a series intended <

43、;/p><p>　　to help you better understand the value of an SOA, and to help you develop </p><p>　　a realistic plan for evaluating your current infrastructure and migrating it to </p><p>　

44、　a service-oriented architecture.</p><p>　　For some time now, the existence of Web services technologies has stimulated </p><p>　　the discussion of SOAs. The discussion isn’t a new one; the conc

45、ept has been </p><p>　　developing for more than a decade now, ever since CORBA extended the </p><p>　　promise of integrating applications on disparate heterogeneous platforms. </p><p&

46、gt;　　Problems integrating these disparate applications arose, often because so </p><p>　　many different (and non-CORBA-compliant) object models became popular. </p><p>　　As a result, many archit

47、ects and engineers became so bogged down in </p><p>　　solving technology problems that developing a more robust architecture </p><p>　　that would allow simple, fast, and highly secure integratio

48、n of systems and </p><p>　　applications was lost. Unfortunately, the problems persist, and become more </p><p>　　complex every year. Meeting basic business needs drive your search for a </p&g

49、t;<p>　　better solution. Needs like lowering costs, reducing cycle times, integrating </p><p>　　systems across your enterprise, integrating business-to-business (B2B) and </p><p>　　busine

50、ss-to-consumer (B2C) systems, achieve a faster return on your investment, </p><p>　　and creating an adaptive and responsive business model. But more and </p><p>　　more, you’re finding that point

51、-to-point solutions won’t solve the basic problem: </p><p>　　the lack of a consistent architectural framework that enables you to rapidly </p><p>　　develop, integrate and reuse applications. Mor

52、e importantly, you need an </p><p>　　architectural framework that allows you to assemble components and services </p><p>　　to deliver dynamic solutions as your business needs evolve. This white

53、paper </p><p>　　will go beyond discussing why particular technologies such as Web services </p><p>　　are good. It will provide an architectural view unconstrained by technology. </p><

54、p>　　To begin, you should consider some of the fundamental problems that underlie </p><p>　　your search for a better foundation. How you address these problems will </p><p>　　determine your le

55、vel of success. </p><p>　　Problem 1: complexity</p><p>　　Some business problems facing your IT organization are consistently the </p><p>　　same. Corporate management pushes for bett

56、er utilization of IT resources, </p><p>　　greater return on investment (ROI), integration of historically separate systems </p><p>　　and faster implementation of new systems. But some things are

57、 different now. </p><p>　　Environments are more complex. Budget constraints and operating efficiencies </p><p>　　require you to reuse legacy systems rather than replace them. Inexpensive, </p

58、><p>　　ubiquitous access to the Internet has created the possibility of entire new </p><p>　　business models that you have to evaluate to keep pace with your competitors. </p><p>　　Gro

59、wth by merger and acquisition has become standard fare, so entire IT </p><p>　　organizations, applications, and infrastructures must be integrated and </p><p>　　absorbed. In an environment of th

60、is complexity, point-to-point solutions merely </p><p>　　exacerbate the problem, and will never really meet the challenge. You must </p><p>　　develop systems that incorporate heterogeneity as a

61、fundamental part of your </p><p>　　IT environment, so they can accommodate an endless variety of hardware, </p><p>　　operating systems, middleware, languages and data stores. The cumulative <

62、/p><p>　　effect of decades of growth and evolution has produced the complexity you’re </p><p>　　now dealing with. With all these business challenges for IT, it is no wonder </p><p>　　t

63、hat application integration tops the priority list of many CIOs. </p><p>　　Problem 2: redundant and nonreusable programming</p><p>　　Like many companies, your application portfolios may have gro

64、wn as a result </p><p>　　of mergers and acquisitions. As a result, you may be dealing with redundant </p><p>　　applications—or applications with function that can’t easily be reused. Perhaps <

65、;/p><p>　　each business unit within your organization has acted separate from every </p><p>　　other unit, effectively hindering any coordinated effort to create reusable </p><p>　　func

66、tional assets or services. Collectively this redundancy increases both cost </p><p>　　and time to market to deploy new products or services, because changes have </p><p>　　to be made in each app

67、lication or system affected. This lack of reuse ultimately </p><p>　　requires more resources—and often more time—to deliver new applications.</p><p>　　Problem 3: multiple interfaces</p>&

68、lt;p>　　Consider the n(n-1) integration problem. All organizations face integration </p><p>　　problems of some sort; perhaps because of a corporate merger, a new business </p><p>　　alliance, o

69、r just the need to interconnect existing systems. If n application </p><p>　　systems must be directly interconnected, the process will produce n(n-1) </p><p>　　connections, or interfaces. In Fig

70、ure 1, each arrowhead represents an interface.</p><p>　　///////////////////////////////////////////////////////////</p><p>　　According to Aberdeen Group, </p><p>　　surveys of Global

71、 2000 CIOs consistently </p><p>　　identify the cost, complexity </p><p>　　and integration time of enterprise </p><p>　　application integration (EAI) and </p><p>　　busin

72、ess-to-business (B2B) integration </p><p>　　as one of their top concerns. </p><p>　　Even with tightening budgets and </p><p>　　lower profit margins, the business </p><p&g

73、t;　　benefits of a solid integration </p><p>　　strategy are so compelling that CIOs </p><p>　　predict they’ll spend between 35 </p><p>　　percent and 60 percent of their </p>&

74、lt;p>　　budgets on integration projects.1</p><p>　　/////////////////////////////////////////////////////////////</p><p>　　////////////////////////////////////////////////////////////</p>

75、<p>　　Figure 1. The n(n-1) integration problem</p><p>　　///////////////////////////////////////////////////////////////</p><p>　　Consequently, if you must integrate another application sy

76、stem A(n+1) , </p><p>　　you will need to generate, document, test and maintain 2n new interfaces. In </p><p>　　Figure 1, the set of five applications requires 20 direct interfaces. Adding a <

77、/p><p>　　sixth application would require ten new interfaces. And to further increase </p><p>　　complexity, you must modify the code in each of the existing applications to </p><p>　　in

78、clude the new interfaces, generating substantial testing costs. To reduce </p><p>　　this cost and complexity, you need an optimum solution that produces the </p><p>　　minimum number of interface

79、s n for n applications, with only one new </p><p>　　interface for each system added. However, it can’t be done by direct connection.</p><p>　　What about the future?</p><p>　　Over th

80、e last four decades the practice of software development has gone </p><p>　　through several different programming models. Each shift was made in part </p><p>　　to deal with greater levels of sof

81、tware complexity and to enable architects </p><p>　　to assemble applications through parts, components or services. More </p><p>　　recently, Java. technology has provided platform-neutral progra

82、mming. </p><p>　　XML has provided self-describing, platform-neutral data. Now Web services </p><p>　　have removed another barrier by allowing applications to interconnect in </p><p>

83、;　　an object-model-neutral way. For example, using a simple XML-based </p><p>　　messaging scheme, Java applications can invoke Microsoft. .NET applications </p><p>　　or CORBA-compliant, or even

84、COBOL, applications. So, IBM CICS. or IBM </p><p>　　IMS. transactions on a mainframe in Singapore can be invoked by a .NET </p><p>　　application which in turn may be invoked by an agent running

85、on an IBM </p><p>　　Lotus. Domino. server in Munich. Best of all, the invoking application </p><p>　　doesn’t have to know where the transaction will run, what language it is written </p>

86、<p>　　in or what route the message may take along the way. A service is requested, </p><p>　　and an answer is provided.</p><p>　　Web services are more likely to be adopted as the de facto s

87、tandard to deliver </p><p>　　effective, reliable, scalable and extensible machine-to-machine interaction </p><p>　　than any of their predecessors. The timely convergence of several necessary <

88、;/p><p>　　technological and cultural prerequisites have contributed to this adoption, </p><p>　　including: </p><p>　　. A ubiquitous, open-standards-based, low-cost network infrastructu

89、re, and </p><p>　　technologies that offer a distributed environment much more conducive to </p><p>　　the adoption of Web services than both CORBA and Distributed Computing </p><p>　

90、　Environment (DCE)-faced environments</p><p>　　. A degree of acceptance and technological maturity to operate within a network-</p><p>　　centric environment that requires interoperability to ach

91、ieve critical business </p><p>　　objectives, such as distributed collaboration</p><p>　　. Consensus that low-cost interoperability is best achieved through open Internet-</p><p>　　b

92、ased standards and related technologies</p><p>　　. The maturity of network-based technologies (such as TCP/IP); tool sets </p><p>　　(integrated development environments [IDEs] and Unified Modeli

93、ng Language </p><p>　　[UML]) platforms (such as Java 2 Platform, Enterprise Edition [J2EE]) and </p><p>　　related methodologies (such as object-oriented [OO] technology and services), </p>

94、<p>　　that provide the infrastructure needed to facilitate loosely-coupled and </p><p>　　interoperable machine-to-machine interactions—a state far more advanced </p><p>　　than what CORBA

95、users experienced.</p><p>　　SOA can be both an architecture and a programming model, a way of thinking </p><p>　　about building software. An SOA enables you to design software systems </p>

96、<p>　　that provide services to other applications through published and discoverable </p><p>　　interfaces, and where the services can be invoked over a network. When you </p><p>　　impleme

97、nt an SOA using Web services technologies, you create a new way </p><p>　　of building applications within a more powerful, flexible programming </p><p>　　model. You can reduce your development a

98、nd ownership costs—and your </p><p>　　implementation risk. </p><p>　　On the horizon, however, are even more significant opportunities. First, </p><p>　　grid computing, which is much

99、 more than just the application of millions </p><p>　　of instructions per second (MIPS) to effect a computing solution. Grid </p><p>　　computing will also provide a framework that will enable yo

100、u to dynamically </p><p>　　locate, relocate, balance and manage massive numbers of services so you can </p><p>　　guarantee that needed applications are always securely available, regardless <

101、/p><p>　　of the load placed on your system. </p><p>　　This framework, in turn, gives rise to the concept of on demand computing, </p><p>　　which could be implemented on any configurati

102、on, from a simple cluster of </p><p>　　servers to a network of 1024-node IBM SP2. systems. If a user needs to solve </p><p>　　a problem and wants the appropriate computing resources applied to i

103、t—no </p><p>　　more, no less—you can pay only for the resources actually used. The effective </p><p>　　use of these new capabilities will require the restructuring of many existing </p>&

104、lt;p>　　applications. Existing monolithic applications can run in these environments, </p><p>　　but will never use the available resources in an optimal way. These circumstances, </p><p>　　alo