|
構件技術應運而生 |
| 在信息時代,新的技術革命正在改變我們日常生活的面貌，而這場技術革命的核心是計算機軟件系統。在面向對象技術給解決軟件危機帶來曙光之時, 分佈式網絡計算的巨大壓力又給軟件開發提出了許多新的難題,使軟件開發仍處於高風險狀態。新的分佈式網絡計算要求軟件實現跨空間、跨時間、跨設備、跨用戶的共享，導致軟件在規模、複雜度、功能上的極大增長，迫使軟件要向異構協同工作、各層次上集成、可反覆重用的工業化道路上前進。爲適應軟件的這種需求，新的軟件開發模式必須支持分佈式計算、瀏覽器/服務器結構、模塊化和構件化集成，使軟件類似於硬件一樣，可用不同的標準構件拼裝而成。具體地說可實現下列幾點要求： |
| ● 提供一種手段，使應用軟件可用預先編好的、功能明確的產品部件定製而成, 並可用不同版本的部件實現應用的擴展和更新。 |
| ● 利用模塊化方法，將複雜的難以維護的系統分解爲互相獨立、協同工作的部件，並努力使這些部件可反覆重用。 |
| ● 突破時間、空間及不同硬件設備的限制，利用客戶和軟件之間統一的接口實現跨平臺的互操作。 |
| 爲滿足上述要求，軟件構件技術出現了。而構件重用的目標是達到需求、分析、設計、編碼、測試的重用。從此，一種影響軟件產業發展的新的軟件開發方法誕生了。 |
| 從抽象程度來看，面向對象技術汛鐗攪死嗉噸賾?代碼重用)，它以類爲封裝的單位。這樣的重用粒度還太小，不足以解決異構互操作和效率更高的重用。構件將抽象的程度提到一個更高的層次，它是對一組類的組合進行封裝，並代表完成一個或多個功能的特定服務，也爲用戶提供了多個接口。整個構件隱藏了具體的實現，只用接口提供服務。這樣，在不同層次上， 構件均可以將底層的多個邏輯組合成高層次上的粒度更大的新構件，甚至直接封裝到一個系統，使模塊的重用從代碼級、對象級、架構級到系統級都可能實現，從而使軟件像硬件一樣，能任人裝配定製而成的夢想得以實現。近幾年來，構件技術的發展已證明了它的巨大威力，在這其中，CORBA標準和Java技術的突破，功不可沒！ |
| 至今, 構件技術已形成三個流派:Sun的Java平臺、Microsoft的COM+、IBM的CORBA。 |
| 構件發展自律當先 |
| 基於構件的軟件開發技術近年來取得了突飛猛進的發展，這不僅對軟件產業的技術革新影響深遠，還將爲許多其他領域帶來巨大的效益。早在1998年4月，在日本京都召開的基於構件的軟件開發(CBSD)國際專題學術會議上達成了兩個共識： |
| 1. 對於CBSD而言，對象技術並不是必需的，同時僅僅依靠對象技術也不能實現CBSD。 |
| 這似乎有些難以理解。對象技術僅僅是CBSD的開始，但是就對象技術本身而言，它並不能全面地表述CBSD所需的抽象概念，而且脫離對象技術，CBSD也完全可以實現。因此，對於CBSD而言，對象技術既不是必需的，僅有對象技術也是不夠的。CBSD將導致使用對象技術的系統設計方法、項目管理方法和組織形式的實質性變革。 |
| 具體地說，將構件看做是一個可替換的單元時，單純的對象技術就不夠了。構件的各種定義中都或多或少地強調了構件的一個特性：對上下文的依賴性。這一特性能夠通過在規範中定義一種“use”語句而實現，也就是對所需系統資源的一種聲明。儘管對這種方式很多人持有異議，他們認爲使用這種“use”語句,意味着接口描述就是一種實現機制，而不是一種對實現方法的抽象，但是,對象技術卻根本不支持構件的這種特性，這樣不利於進行設計層的抽象，特別是在試圖使用已有的構件進行集成時,經常會遇到麻煩。 |
| 現在人們比較一致的觀點是將分佈式對象技術當做是一種基礎設施，而把構件看做是能夠應用於不同的基礎設施的抽象和實現。 在實踐中人們也體會到這一點，如長事務的處理不能靠對象技術來解決。由於事務的原子性、一致性、隔離性和持久性的特點，不能把長事務簡單地看成一個對象,它是一連串處理步驟的序列。這也是企業應用軟件中常遇到的問題,目前一些服務器上的軟件提供的事務服務,就是爲了解決這個複雜的疑難問題。 |
| 2．構件離不開體系結構 |
| 由於發展CBSD的一個初衷是通過一種集成的開發方式來增強系統的靈活性，因此自然要考慮這種集成方式的可行性。然而,通過抽象接口來描述,已經超出了對象技術的能力。但是，對“插件”式構件的重用程度，與構件對一套預先定義的限制和約定的依賴程度有直接的關係。 |
| 大多數構件技術如EJB、ActiveX、CORBA等對於構件都有一定的限制。例如，儘管構件基礎設施對構件的接口有一定的訪問能力，但這種能力要求構件必須能夠實現一定的服務或遵循構件基礎設施所定義的一些規範。 |
| 許多專家認爲，構件應當實現兩種接口：一種是功能性接口，能夠反映構件在系統中的角色；另一種是非功能性接口，能夠反映由底層的構件框架所定義的構件模型。非功能性接口描述了一種體系結構上的限制，這種限制允許CBS（components-based system）具有集成能力和其他的一些特性。所以，對構件概念的理解,必然與體系結構強加於構件的這些限制密切相關。 |
| 許多專家認爲，儘管構件與其所屬的體系結構密切相關，但是上述的兩種接口仍然過於強調構件框架在軟件體系結構中的地位。而實際上，很多人都曾極力地尋求軟件體系結構和構件框架的區別。但是通過對體系結構的三種不同觀點的定義,保留構件框架概念的二義性： |
| ● 運行期間：包括爲基於構件的系統提供運行時服務的框架和模型。 |
| ● 設計期間：包括對構件的特定觀點，如功能性接口和構件依賴性。 |
| ● 集成期間：包括系統對各種構件進行集成時所需的各種因素，如生成器和一些構造期間的服務，一個構件框架可能就會提供這些服務。 |
| 在研討中出現的這些關於構件的更多特性,表明構件是一種設計階段的複雜實體，它包括抽象的概念和具體的實現。 因此，許多專家認爲，使用現成構件的CBSD,把構件視爲一種商業上的現成商品，在這種情況下，CBSD必須建立關於構件框架的行業規範。 |
| 構件影響不可小覷 |
| 要實現構件技術必須具備下列幾個條件: |
| ● 有標準軟件體系結構,保證構件間通信協議統一, 實現同步和異步操作控制，突破本地空間限制,充分利用網絡環境。 |
| ● 構件有標準接口, 保證系統可分解成多個功能獨立的單元, 用構件組裝而成。 |
| ● 構件獨立於編程語言。 |
| ● 構件提供版本兼容, 來實現應用系統的擴展和更新。 |
| 總之，CBSD爲軟件開發技術帶來了新的生機，其影響力正在顯現。 |
