軟體平臺關鍵抉擇

2006年第四季的現在，微軟即將推出.NET Framework 3.0，Java SE 6也將上市，而Windows Vista、Longhorn Server與64位元、多核心處理器等軟硬體平臺，以及虛擬化、SOA等技術也蓄勢待發，在這關鍵的時間點，企業下一代軟體平臺該如何選擇？

牽動下一個5年的抉擇
一個專案的開始，理論上應該先評估系統的需求、使用的層面，及現有的軟、硬體環境，再權衡眾多技術的適用性，並計算出可能的成本，經過通盤考量，最後才決定技術平臺。

引頸企盼的Java SE 6效能令人驚豔
不管在效能、API的增加和易開發性，Java SE 6都有大幅的改善。如果是正在使用J2SE 5.0的開發者，那麼轉換到Java SE 6上不會有太大的問題，更可以增進效能，以及JavaSE6新增的Annotation API帶來的易開發性。

微軟新世代開發技術─.NET Framework 3.0
NET Framework 3.0是以.NET Framework 2.0為基礎，擴充WPF、WCF、WF與WCS四個新成員，把平臺的觸角延伸到更廣泛的層次。

真實世界的SOA是策略與架構的調整
多數人對SOA是一知半解的，以為買了什麼產品就可以達到SOA的目的。事實上，SOA是企業資訊架構的議題，特別是面對複雜、新舊交陳的資訊系統架構，本來就不是單一軟硬體可以解決的問題。牽動下一個5年的抉擇

企業關鍵的營運系統，平均5年會因為效能、可用性、容量等達到極限，或者營運擴大的因素，汰換或升級硬體設備，隨著硬體的更新，軟體也將順應新的技術與需求做適度的調整。2006年第四季的現在，微軟即將推出.NET Framework 3.0，Java陣營的Java SE 6也將上市，而Windows Vista、64位元的軟硬體平臺及Longhorn伺服器等也蓄勢待發，站在這個關鍵的時間點，企業下一代的軟體平臺該如何選擇呢？

對企業而言，IT攸關競爭力而非信仰。一個專案的開始，理論上應該先評估系統的需求、使用的層面，及現有的軟、硬體環境，再權衡眾多技術的適用性，並計算出可能的成本，經過通盤考量，最後才決定技術平臺。

就商業層面考量，若有現成的解決方案可以馬上派上用場，那麼管它是什麼技術，搶得市場先機才是最重要的。但若有多種方案任君選擇時，那麼平臺的決策，左右了企業未來IT的布局與維運的考量。錯估情勢可能衍生龐大的補救成本，甚至商機的流失。

決策錯誤的例子層出不窮
根據筆者針對接觸企業及軟體公司的結果，驚訝地發現，許多軟體專案對於技術的選擇，幾乎都純粹基於決策者的喜好，而非客觀環境的判斷。

根據既有團隊所熟悉的技術，開發新系統似乎是合理而常見的現象，在過去選擇VB（Visual Basic）或Delphi，可能根據習慣或喜好，倒也無可厚非。

但現今企業面對的是應用平臺的抉擇，例如許多醫療及金融體系，目前正考慮從大型主機的COBOL系統，轉至開放架構，便站在Java與.NET的十字路口，技術平臺的影響至關重大。

我們從現實的企業營運中，不難找到因為決策錯誤，而產生令人匪夷所思的系統架構案例：

案例1：個人喜好左右平臺決策
一家營業據點遍布全臺的金融機構，聘請Java顧問領導IT團隊自行開發ERP系統，顧問評估的結果，在用戶端為Windows平臺，又希望兼顧使用者操作體驗的情況下，決定開發桌面系統架構Java SE（Standard Edition）的系統。以5年前的軟硬體設備，執行Java Applet的系統，效能簡直慢到令人難以忍受的地步，使用者怨聲載道。筆者問起何以如此考量，原因竟是：「因為喜歡Java的物件導向。」

案例2：品牌迷思盲目追求流行
某運輸業委外開發物流管理的系統，在缺乏專業技術認知的情況下，基於對「Java」的品牌崇拜，要求沒有Java技術背景的資訊廠商，以Java開發高互動的主從架構系統，上線後的執行效能，同樣引發使用者諸多責難。

案例3：片面印象引導技術選擇
筆者曾經訪問多家採用VB.NET的企業，詢問何不選擇.NET平臺最原生的C#語言？答案通常是：「原來公司採用VB，因此以為『VB』.NET跟VB雷同。」他們在實際接觸後才發現：雖然VB.NET許多語法與VB相似，但其實已改為完全物件導向的開發觀念，與VB 6程序導向的精神大不相同。

微軟後來將「.NET」字眼從產品中全面移除，因此現在.NET平臺的VB，稱為Visual Basic 2005，除了「Visual Basic」這塊神主牌依然存在之外，其實Visual Basic 2005與Visual Basic 6.0骨子裏已經是完全不同的東西。最直接的證據就是過去以Visual Basic所開發的系統，根本無法升級到.NET平臺。

廣大的VB開發者，若是早知道升級.NET與Java，在技術本質上存在著同樣高的門檻，將可能重新評估下一代技術的選擇，然而微軟的策略卻已經達到目的，VB開發者憑著字面上的直覺，多數選擇留在.NET平臺，Visual Basic 2005幾乎完全承接VB的用戶。

案例4：技術本位無視主流民意
在一個Web專案中，開發者採用Ajax技術強化操作的互動性，然而業務單位反應IE瀏覽器不支援某些JavaScript功能，技術團隊的回答很乾脆：「請客戶改用Firefox。」

技術無罪，但決策可議
以上看似不可思議的案例，卻不時在IT界真實上演，其中有2個例子是因為Java平臺而導致的爭議，是Java的問題嗎？技術本身是無罪的，關鍵在於決策者的判斷。

Java跨平臺的特性，勢必造成執行效能程度上的犧牲，這是Windows平臺的桌面應用選擇Java技術時，應該深思的。不過，隨著硬體效能不斷的提升，以及Java SE版本的更新，效能也持續地改善，在國外可以看到不少Java SE的應用，而國內採用Java SE的比例不高。另一個影響的因素，則是開發者的水準素質，不同人寫的Java程式執行效能，可明顯比較出開發的功力。

非Windows平臺選Java只是簡單法則
就現在技術平臺的兩大主流Java與.NET而言，如何選擇，其實有一些簡單的法則：跨平臺的系統，或者非Windows平臺的伺服器端應用程式，Java是首選；而Windows桌面應用的解決方案，.NET是開發上比較不吃力的選擇。

但除了以上簡單的通則，還有很多複雜的情況，技術的決策要考量的範圍很廣，針對每個專案的需求、IT人員的素質、軟硬體環境、時效與經費的因素，將產生不同的結果，所以沒有準確放諸四海皆準的原則。

事實上，Java與.NET技術的本質幾乎相同，很多關於.NET及Java的爭論，其實摻雜了對「微軟」這家公司的觀感，純就技術而言，兩者的相似處遠多於相異處。

企業應衡量的是自身IT的能力與預算。.NET是由微軟單一廠商控制平臺的主導權，「友善的使用者介面」是微軟的強項，藉由開發工具封裝.NET的複雜性，在Visual Studio的加持下，使得.NET程式的開發較為簡單且生產力較高。

選擇Java則需評估IT人員的素質，許多金控體系走向開放架構時，選擇委外開發，然後培訓既有的IT人員承接後續的維運工作。

然而過去COBOL、Informix、AS400/RPG、VB習於程序導向開發的人才，如果想進入物件導向的Java世界，學習的門檻很高。

若從成本考量，Java解決方案通常比較「高貴」。不過，Java的選擇多元，若搭配免費的開放源碼，精打細算的企業也可以撿到便宜。

Java向前相容性佳，.NET的優勢是開發速度快
我們可以預期，只要IT界存在Windows以外的作業系統，Java就不會消失。雖然Java領域始終沒有出現可與Visual Studio匹敵的友善開發工具，但「民意」已逐漸領導Java走向簡單化及生產力更高的趨勢，Java技術的複雜性，有機會逐漸降低。

Java 到目前為止，JDK 1.1編譯的class檔，還是可以在JDK 5.0上面執行，企業的投資不會因為版本的變更，而需要重新改寫或是全面測試。但相對的代價是，Java為了維持向前相容及跨平臺的整合性，也使程式語言無法一次跨越的大幅翻新，導致Java越來越肥大的問題。

如果希望系統可以長久使用的話，Java到目前為此，都維持很好的相容性；但若希望快速開發，.NET的生產力有目共睹。至於既有的.NET系統，若希望隨.NET版本升級，必須了解微軟的產品生命周期策略，做好改版時程規畫：微軟針對商業產品與開發工具提供為期10年以上的支援服務，5年的主流支援和5年的延伸支援；針對消費者、硬體、多媒體和商業解決方案產品提供5年以上的支援服務。

下一頁

選Java，人員的素質很重要
資策會資訊工程研究所經理李至霓曾表示：「Java相關技術單就EJB（Enterprise JavaBeans），至少要1年以上的經驗，才能運用得當。」事實上，我們可以發現很高比例的Java開發者，是停留在JSP的階段，因此，很多時候Java與物件導向是兩回事。

在自由、多元且蓬勃發展的Java領域，企業必須關注的焦點，是要擁有素質精良的Java好手，或者找到實力堅強的資訊服務廠商，便可以不受限於「一言堂」的技術，根據自身成本、功能與軟硬體架構的需求，搭配組合量身訂作的資訊系統。

多元社會的好壞相對論
不被單一廠商牽制的好處是「自由」，開放源碼社群有許多很好的創意，例如Struts、Hibernate、Spring就是很好的例子，當那些創意獲得多數人的認同，那麼「民意」將主導一切，便就有可能納入JCP正式的規格，在Java領域，技術是百花齊放多元的社會。

民主的代價是規格制定的過程，比單一廠商「獨裁」的決策來得漫長，所以Java因應新技術的官方標準，時效往往不及微軟陣營，而迫不及待的Java廠商，就會在新產品中「偷跑」，預先實作的情況屢見不鮮，這相對也造成投票的過程中，廠商為了自身的利益，暗藏了政治角力與算計。

跨系統平臺，不代表Java可跨廠商平臺
對於Java跨平臺的論點，其實存在弔詭之處，藉由JVM（Java Virtual Machine，Java 虛擬機器）的設計，確實達到可以在Windows、Linux、Unix、Mac等不同作業系統執行Java程式的目的。

但是針對「Write Once，Run Everywhere」的理想，在Java EE與Java ME領域存在許多瓶頸。Java ME包辦Windows以外的手機市場，不過每家手機廠商都有專屬的設計，最簡單的例子是螢幕大小就沒有統一的規格，便無法保證「Write Once，Run Everywhere」。

在Java EE應用方面，除非採用開放源碼，完全遵循JCP的標準，否則企業只要選擇商用平臺，那麼若未來想要轉換平臺，便是浩大的工程。IBM官方網站針對BEA WebLogic的轉移手冊，就有多達數百頁的說明，甚至有資訊服務廠商提供專業的移轉服務。

雖然許多反微軟的陣營，強調選擇.NET平臺將被微軟緊密綑綁（Vendors Lock In），似乎選擇Java才能擁抱自由，但現實情況是除非有能力掌握程式碼，否則無論選擇.NET或Java，都被廠商緊密綑綁。

差異化是平臺廠商的商業考量
站在應用伺服器廠商的立場，差異化是合理的商業考量，只要是商業軟體就有專屬技術。若沒有專屬技術就沒有差異化，如何競爭？而用了專屬技術的應用伺服器，還可以跨平臺嗎？

過去曾經是Java開發工具市占率第一名的JBuilder，很大的特色在於可以自動化部署Java程式於IBM、BEA及Oracle等多家主流廠商的應用伺服器，Borland於平臺之間的切換技術上，投入相當大的成本。可惜在Eclipse免費的攻勢下，使JBuilder的占有率節節敗退。

唯有開放源碼的Java解決方案，完全奉行JCP制定的標準，才有可能不被廠商緊密綑綁，否則跨「廠商」的平臺只是理想。但沒有原廠掛保證的資訊系統，出問題時，IT主管要思量可以「賴帳」給誰？

自由搭配的前提－別忘了考量維護的永續性
由於Java的跨平臺與百花齊放的技術，所以同樣的解決方案，從硬體伺服器到軟體的作業系統、網站伺服器、應用伺服器、資料庫，甚至MVC架構、物件與關連式資料庫對應技術等都有多種排列組合的可能。

就好像買電腦可以選擇大廠提供的完整方案，但專業人士寧願去光華商場精心挑選喜歡的機殼、風扇、主機板、CPU、記憶體、螢幕、硬碟、光碟機及滑鼠與鍵盤，自行組合價格、功能、需求與造型各方面都完全量身訂作的夢幻機種。

企業面對Java解決方案，可以選擇主流廠商提供的現成應用程式平臺套件，也可以從免費的開放源碼專案中，組裝出完整的平臺。
但不能遺忘的前提－要確保「夢幻組合」，持續有能力足夠的IT人才維護，才能保障系統的永續性。

選.NET，必須解除心中的疑慮
許多企業選擇.NET平臺，主要是看重Visual Studio的簡易性。.NET透過工具封裝了技術的複雜性，相較於Java，確實有效提升軟體開發的生產力。然而微軟長久累積的頻繁改版、不同版本相容性不佳、資安漏洞百出，以及著名的「藍色死亡畫面」等負面印象，使IT人員對.NET平臺的穩定性與安全性充滿疑慮，認為.NET難當「大」任。

在過去，從Windows解決方案在中小企業盛行情況，不難看出微軟的產品在快速開發小型的應用時，有很好的成效。不過對於大型企業關鍵任務型系統，尤其7×24服務及交易量大的系統，對微軟解決方案就存在許多疑慮：

● 更新過於頻繁：Windows作業系統頻繁的Windows Update，對於7×24小時運作的系統，實在經不起重新開機的動作。即使利用離峰時間重新啟動，也要承擔「啟不動」的風險。

即便如此，還是有小技巧，目前有許多微軟大型的企業級客戶，搭配Microsoft System Managment Server，使用叢集的架構，應用程式抽離某個State，使用者完全感受不到系統曾經重新開機；也有半導體業利用一年一度的歲修，統一升級，以避開重新開機的問題。

● 安全性：雖然微軟資訊安全的漏洞很多，但持平而言，其實也是樹大招風結果。Linux、Unix未必沒有安全漏洞，但如果駭客想「駭」一個非Windows平臺的網站，必須猜測它的作業系統用Linux還是Unix？網站是Apache搭配Tomcat、WebSphere、WebLogic還是使用PHP、Perl、Python語言？後端資料庫是Oracle、DB2、MySQL還是Sybase？排列組合過於複雜，所以意願自然不高。

而微軟產品的目標顯著，Windows作業系統搭配IIS、ASP及SQL Server資料庫。相關技術的取得容易，只要把關不夠嚴謹，利用SQL Injection技術就能動手腳。舉例來說「sa」是SQL Server的通用帳號，每一家都有「北風」資料庫，而且內建的預存程序就有關閉IIS服務，或者存取、刪改任何檔案與資料表的功能。小偷行竊，當然選擇簡單的下手。

在目標明顯的情況下，萬全的防備就是必然的成本。Microsoft.com 是全球駭客最想入侵的網站，但目前尚未失守。資料輸入把關的嚴謹程度、加密與數位簽章機制、系統的認證與授權，甚至搭配其他軟硬體的資安產品，經由層層把關才能強化安全性。

● 穩定性：Windows使用者對「藍色死亡畫面」都不陌生，國內某家金控選擇Java平臺時，筆者詢問：「為什麼不選.NET？」他們的回答是銀行系統無法承擔系統不穩定的風險。Windows Server 2003及IIS 6.0已強化穩定性與安全性架構，倫敦證交所和每小時50萬筆交易的臺灣金資中心信用卡結算系統，均使用.NET平臺，但企業基於長久累積的負面印象，對微軟仍存有不信任感。

國內外均有.NET大型應用案例
微軟本身的Microsoft.com、MSN.com及國內名列財星500大企業的鴻海、國泰金控與廣達，均採用.NET平臺的解決方案。Amazon投資的Alexa Web Search網站，針對全球網站的網路流量作即時的調查，目前流量前5名的網站中，有3個是微軟自家平臺，表示.NET平臺也具備承受高流量的擴充性。

Java與.NET技術的本質幾乎完全相同，國內、外已有許多成功案例，是以.NET平臺開發的大型關鍵任務性系統。若.NET平臺既能快速開發，又足以兼具關鍵性任務，那麼可以快快樂樂使用.NET了嗎？

其實.NET的問題就在於Visual Studio的簡單與快速上手，開發工具的低門檻，讓不具基本程式開發觀念的人，也得以成為程式設計師。但是對於初階的程式設計師而言，面對.NET平臺物件導向、大型分散式應用，甚至軟體生命周期的管理，都有很漫長的學習曲線。

簡易上手卻不能輕忽設計的重要性
.NET透過Visual Studio封裝了底層技術的複雜性，很多基本的功能可以利用設定的機制迅速滿足需求，但在系統需要更細緻的微調時，精靈反而顯得綁手綁腳，工具產生的大量程式碼，不易修改與更動，當系統出現問題時，才是考驗工程師功力的開始。

「藍色死亡畫面」就是最明顯的例子，當機不完全是Windows本身的問題，軟體設計、硬體的驅動程式等都有可能造成影響，程式的寫法不當導致記憶體鎖死（Memory Leak）是最有可能的禍源，某種程度上，開發者的不良設計讓微軟背了很多黑鍋。

Visual Studio造就的入門級開發者比比皆是，然而疊床架屋、拖拉點選的簡單設計，應付小型、簡單的需求綽綽有餘，但面對大型企業嚴謹的要求，沒有周詳的分析與規畫，其系統的擴充性、延展性、穩定性與安全性，離最低標準還有很大一段距離。

下一頁

混搭是常態，SOA的價值浮現
企業長久累積的IT投資，新舊技術摻雜的結果，COBOL、VB、Delphi、PowerBuilder、.NET、Java等多種技術混搭是必然的結果，異質平臺的整合現今看來不再是難解的習題，透過Web Services可以滿足互通的訴求，這也是SOA（Services Oriented Architecture）甚囂塵上的原因。

一般而言，當舊有的系統無法滿足新興需求時，重新開發一套新系統取而代之，是最直覺的想法。然而，舊有的機制是全部不敷使用嗎？還是以新的技術補強新的需求即可呢？

SOA更大的價值，在於撇開技術層次的問題，從商業應用的角度，切割系統成為各式各樣的服務，以提高既有系統的再利用性。針對無法拆解、封裝成為服務的部分，或者無法滿足的需求，再從IT技術的角度，思考重新開發的必要性。如此才能在既有的服務不能停擺的情況下，快速開發新功能，以搶得市場先機。

強化IT的靈活性與快速反應的能力
SOA的第一步，不是購置標榜「SOA」的產品，而是要有兼具產業知識與IT技術的顧問，從商業邏輯的角度，分析企業應該提供哪些服務，以決定各項服務正確的顆粒大小，再研究系統該如何切割，才能畫分成許多獨立、再利用性高，又不致過於瑣碎的服務。

當企業的IT系統，被切割成許多獨立的服務，ESB（Enterprise Service Bus，企業服務匯流排），提供了串連、監控與管理服務的平臺。但是沒有ESB也可以實現SOA ，ESB用以是管理與監控服務的品質。但企業必須認知，監控的代價是效能的折損，就像通電話時，有第三方監聽，聲音的品質一定會受到影響。

所以當各個系統變成一個個Web Services，透過WSDL（Web Services Description Language）與UDDI（Universal Description,Discovery,and Integration）曝露出來供其他系統叫用，多一層媒界，效能便打上折扣，再加上一層ESB作為監控與管理平臺，效能再次被拖累。然而，硬體相較於人力及時效的成本，是相對低廉的，因此SOA的好處，是強化IT的靈活性與快速反應的能力，效能的折損，可以擴充硬體來補強。

嚐試新技術，隱藏的成本不低
選定了技術平臺，在應用上仍面臨很多考量。Java的Web Framework要選Struts、JSF還是Spring？物件與關聯式資料庫對應的技術要選Hibernate、JDO、EJB Entities 3、EJB Entity Beans 2.x還是TopLink？

.NET平臺Web架構下，ASP.NET似乎是唯一的選擇，但如果想豐富操作體驗，可以搭配Atlas解決方案，或改採Smart Client架構。再深入探究，既有的Web系統若加入Ajax技術，依據需求的不同，程式與架構影響的層面可大可小；即使全新的專案導入Ajax技術，也要評估學習成本。

若想兼具Windows的高互動性與Web部署的便利性，可以選擇Smart Client架構，但要考量後端資料庫的安全性。在.NET Framework 3.0出現後，又多了WPF（Windows Presentation Framework）的選項。所以實際開發專案時，需要考量的層面很多，IT人員的通病是喜歡追求新技術，但嚐鮮的同時，別忘了考量新技術的成熟度，以及學習背後所隱藏的成本。

決策前，深思IT的初衷
Web Services的出現，使得企業得以回歸應用的初衷，不用牽就系統互通的問題，選擇真正適合的技術。所以當使用者詢問選用某個技術或平臺的理由，你的思維是：「因為物件導向」、「因為討厭微軟」、、「因為熱愛自由」、「因為想要嚐鮮」；而當使用者反應：「這個東西IE不支援。」你的回答是：「請改用Firefox。」表示已經鑽進技術的象牙塔，背離使用者的民意了。

平臺的決策應回顧IT的本質，與企業所擔付的風險。站在商業的角度，技術只是滿足需求的手段，不論Java、.NET、VB、Delphi還是IT人眼中的「骨董」COBOL，都只是輔助企業營運的工具。文⊙李延華引頸企盼的Java SE 6效能令人驚豔

原本預定在10月推出Java SE 6，將延期到12月才會上市，Java SE 6的官方網站每周釋出一份開發中版本，所以對於想趕快轉換平臺的使用者，已經可以下載嘗試。

重新體驗Annotation的好處
依照昇陽提供的資料，Java SE 6在577臺主機、3種架構（x86、AMD64、SPARC），24個不同種類不同版本的作業系統（Red Hat、Fedora Core、Solaris、Windows等）上測試。尤其對於J2EE開發者來說最關心的穩定度，昇陽除了在自家的Sun Java System Application Server 8.1做過測試外，也另外在其他未透露的三家商業應用伺服器測試。根據資料顯示，J2SE 5.0的可用性高達99.999%，而Java SE 6的目標將更高於此之上。

對於Java開發者，尤其需要使用JDBC、Web Services，或者是自己撰寫處理Annotation的人來說，Java SE 6提供更多的API和方便的處理機制。雖然說JDBC要使用Annotation得依照廠商的JDBC驅動程式的實作狀況，但是為了讓開發者嚐鮮JDBC4.0的易開發性，JDK6內附了Derby可以讓大家使用。

Annotation在5.0時候已經提供，但是卻沒多少Annotation API給使用者利用，而撰寫Annotation跟處理Annotation的程式又稍嫌麻煩。在Java SE 6中不只提供了更多的Annotation API，更有標準且較容易撰寫的Annotation Processing API，建議大家可以參考新增的API，以了解Annotation到底可以帶來的好處。

強化管理性
另外從5.0才開始有的可監控、易管理性在Java SE 6時也更加強化，在5.0中新增的JMX Management API，在新版中變得更容易撰寫。尤其在大型軟體最需要的，就是可以方便監控跟管理的環境，如果撰寫方式繁雜，會讓開發者不願使用，但是新版中可以透過Annotation與新的MX Bean，可以簡化繁雜的程式碼。

再加上Java SE 6有更好、更方便的剖析（Profiling）工具，尤其依照多數人Profiling過後的經驗，通常自認為會發生效能瓶頸的程式碼，都不會是最嚴重的部分，這就得依靠Profiling工具幫忙，分析到底問題出在哪部分。

從5.0開始，到Java SE 6以後，都可以透過內附的基本工具做簡單的檢查，而不用一開始就使用較昂貴的工具。透過以上的API跟基本的工具，可以簡化和減少開發過程所需的流程跟時間。

桌面應用的強化令人興奮
對於SE開發者來說，這次的更新應該是最感興奮的。這次改進的重點之一，就是桌面環境的強化。尤其以前要寫程式啟動時的Splash Screen、隱藏在視窗桌面右下角的系統工具列、啟動系統預設的應用程式等，都必須依靠其他API，或者繞個圈子花上一點心思才可以完成。

但是在Java SE 6中，這些以前大家反應的不便都已改進，將上述的API放到Java SE。

而在效能方面，OpenGL的Pipeline機制的增進；DirectX方面，也可以透過使用參數的方式設定改善效能。還有真正的Double buffering以及液晶字體的支援，Netbeans提供的Group Layout，盡量呼叫Windows跟GTK的API，以提供更貼近作業系統的外觀等。

JavaSE6的更新列表，最多的項目非桌面環境開發莫屬了。雖然從1.4到5.0時就揚言桌面環境的Java會扳回一成，成效卻沒想像中成功，造成這次的揚言，多數人覺得又是老梗，但是Java在桌面環境的進步，是不爭的事實。

對於需要利用Java Web Start等方式大量部署的桌面環境使用者，提供了更好的安裝機制。在之前的版本警告訊息較嚇人，部署以後的啟動與安裝方式不直覺，也支援較少的安全性相關通訊協定。以上幾點在新版中有更大的改進跟修正。

Web需留心API的支援
Java EE開發者來說，最擔心的就是轉換後，無法於正在使用的商用應用伺服器執行。根據昇陽測試的消息，轉換平臺後執行既有的軟體不會有什麼問題，當然如果顧慮到開發產品的執行環境，不一定可以使用Java SE 6的API，那麼開發時就得注意不要使用到新的API。

在SPECjbb的效能測試下，新版的效能比起5.0提升20%以上，就算沒有使用Java SE 6的新API，光是為了效能和穩定性就值得一試。比較有趣的是，由昇陽開發且開放原始碼的GlassFish，雖然GlassFish v2並未到達穩定的版本，但是如果使用它搭配Java SE 6的執行環境，就可以使用Java SE 6的Compiler API，加速你的JSP編譯速度。

勇敢體驗Java SE 6的效能改進
不管在效能、API的增加和易開發性，Java SE 6都有大幅的改善。如果是正在使用J2SE 5.0的開發者，那麼轉換到Java SE 6上不會有太大的問題，更可以增進效能，以及JavaSE6新增的Annotation API帶來的易開發性。

如果是還在使用J2SE 1.4的使用者，那麼這次新版本的釋出正是個好機會，可以一起嘗試J2SE 5.0帶來的語法上的變更，從1.4版直接跳到Java SE 6，對於效能以及穩定性的改進，一定會感到驚訝。

當然，並非所有軟體都是可以順利移植到新的平臺上執行，尤其規模愈大更可能遇到各種問題。

本文提供了動機增加各位轉換平臺的意願，但是如同大廠在轉換前必定做了各種測試一樣，在正式轉換前務必要做好詳細的測試。以及可能遇到客戶端基於特定理由不肯使用較新平臺的狀況，都是轉換平臺前必須審慎評估的。文⊙JavaWorld@TW站長林康司微軟新世代開發技術─.NET Framework 3.0

微軟Visual Studio 2005於去年底熱鬧上市，同時也推出.NET Framework 2.0的技術平臺。不到一年的時間，今年又宣布將於Windows Vista上市的同時，推出新一代的開發平臺.NET Framework 3.0，讓人不禁好奇，微軟怎麼會在這麼短的時間之內，推出一個全新版本的開發平臺？.NET Framework 3.0又和過去2.0的平臺有什麼不同？既有2.0版上開發的程式如何持續延續？

在深入討論.NET Framework 3.0的技術內容之前，必須先釐清上述的問題。雖然這個技術平臺的名稱是.NET Framework 3.0，但是它的發展歷程，絕對不同於過去1.x到2.0之間技術的改善，或某些架構的翻新。

事實上，從2.0到3.0，並不牽涉技術的改變，而是「擴充」，是在既有的2.0基礎之上再加上了全新的服務。因此對既有的2.0應用程式而言，並不會有改版的困擾，只有是否應用新加入的技術的抉擇而已。

微軟之所以會擴充.NET Framework 2.0，而非基於改進及更新，是因為最初在發展3.0的新成員時，並沒有考量到這些技術是.NET Framework的成員，而是各自獨立的技術，所以用「WinFX」作為整體技術的代號。

而這些技術的發展，有些與Windows Vista的開發有關，有些則是純粹基於開發平臺的需求，微軟企圖整合各個不同產品間的開發技術。但是隨著WinFX逐漸為市場所熟知時，大家不禁感到疑惑，究竟WinFX和.NET是什麼關係？是不是Windows Vista的專屬技術？為什麼不能像.NET Framework一樣在主要的Windows平臺提供服務？

.NET Framework 3.0的成員
為了避免WinFX在定位上產生的困惑，微軟在今年六月於波士頓舉辦的TechEd 2006中，宣布WinFX的正式名稱為「.NET Framework 3.0」，代表它是延伸自.NET Framework 2.0的技術，並且完全屬於.NET開發技術的一員。

由於是.NET開發技術的後續版本，當然沒有理由獨厚Windows Vista，所以.NET Framework 3.0中新加入的成員，都可以運用在Windows Server 2003、Windows XP等作業系統上。

由於.NET Framework 1.x到.NET Framework 2.0中間的變化不小，而且有些是架構上根本的改變，因此自然會讓大家對.NET Framework 3.0是否也是大改版的疑慮。

事實上，.NET Framework 3.0不是改版，而是擴充。新加入到.NET Framework 3.0中的成員包括WPF（Windows Presentation Foundation）、WF（Windows Workflow Foundation）、WCF（Windows Communication Foundation）以及WCS（Windows CardSpace）四個不同面向的技術，而它們都是架構在.NET Framework 2.0的既有基礎之上。

到底新舊之間如何區隔？原本的.NET Framework可說是作業系統服務的整理，方便開發者存取作業系統中，資料存取、使用者介面技術、加密能力等基礎服務。而新加入的成員，則是在這個基礎之上，把觸角延伸到更廣泛的層次。

WPF：展示層技術
從三層式架構剖析.NET Framework 3.0，可以把應用系統畫分成展示層、邏輯層和資料層等不同的區域，透過三層分割的設計，讓分散式應用程式更容易設計，也更容易在不同的運算設備上，安排共用的邏輯或作業服務。

而WPF就是專注在展示層的服務，企圖讓開發人員以更有效的方式，結合新一代的展示技術，充分運用先進硬體帶來的諸多便利。

WF：視覺化商業邏輯設計模式
在邏輯層的部分，簡化商業邏輯設計最好的方式，就是提供視覺化的設計模式，讓商業邏輯能以清楚的流程圖展現，並進而落實在工作流程的推動上。

WF基於這樣的理念，企圖讓開發人員能以流程為基礎，建立應用程式的商業邏輯。不只是操作介面能夠利用控制項的概念，輕鬆組合出新的操作介面，商業邏輯也可以更視覺化地重複運用。

WCF：統合的通訊技術
至於WCF則是從遠端資料交換及通訊的層次，處理資料層的問題。ADO.NET雖然提供良好的資料庫溝通架構，以及離線資料傳遞的機制，但是資料不只是資料展現和存取的問題，還有如何在網路上傳遞，以及通訊過程中不同作業模式（例如同步或非同步的通訊模式）的問題。

WCF的出現彌補了這方面長久以來的空缺，讓開發人員能夠以一致的架構，面對分散式運算環境中各式各樣的資料通訊技術，同時展現服務導向架構（SOA）的精神。

WCS：身分辨識機制
對於應用程式的作業，身分辨識會是一個很重要的課題，它是整個安全執行環境的重要基礎。

對於企業內部而言，或許可以透過單一目錄服務解決身分辨識的問題，但分散式或跨網際網路的環境，身分辨識始終是個重要的課題，也是個艱鉅的挑戰。

WCS的目的是提供一致的身分辨識機制，以邦聯的概念，結合既有的標準，簡化使用者身分辨識的處理。文⊙品睿資訊資深顧問彭靖灝真實世界的SOA是策略與架構的調整

最近一兩年，企業的IT架構流行SOA（Service Oriented Architecture）的討論，無論是軟、硬體，只要是針對大型企業市場，都會提到自己的產品如何支援SOA，甚至號稱提供SOA完整的解決方案。

但是我們還是聽到很多資訊主管抱怨：「不同的廠商簡報SOA，每一家的講法都不一樣！」、「如何採購SOA產品？為什麼還要有很大比例的客製化費用？」

沒有人說得清楚什麼是真正的SOA，仔細探究原因，會發現這個結果不難理解。因為SOA是企業資訊架構上的議題，特別是面對現在企業複雜的、新舊交陳的資訊系統架構，本來就不是單一軟硬體可以解決的問題。

SOA是企圖提出一種系統規畫的紀律，以有效規範既有應用程式，與未來新建系統的整合方式。個別軟體供應商會針對SOA不同的需求，提出不同部分的方案：中介軟體（Middleware）廠商提出SOA中介平臺、系統管理廠商提出SOA監控與管理系統、資訊安全廠商提出SOA防駭服務、資料庫廠商提供SOA資料整合服務等。

常見的SOA 迷思
SOA幾乎變成一個流行名詞，多數人對SOA還是一知半解，於是市場上普遍存在著一些迷思：

1. 導入SOA需要花大錢
這當然是銷售人員最希望客戶得到的結論；導入SOA當然花錢，卻不表示隨便花錢就能得到SOA。光買軟硬體產品，或是系統建置與程式撰寫的服務，是不可能實現SOA的。

企業必須先從內部既有的系統中，建立服務導向架構的標準，然後依此標準訓練內部人員、調整既有系統、建置未來系統。因此，企業導入SOA的第一步，反而是需要顧問服務，而不是建置任何新的系統。

2. 實作Web Services 就是導入SOA
這是技術人員最喜歡的說法。從技術人員的角度來看，Web Services是跟著SOA同步流行的技術趨勢。多半在談SOA時，也都會提到Web Services的規格，似乎只要在現有的程式中加入Web Services就算是導入SOA，根本不需要修改程式的架構。

其中最大的迷思就是刻意忽略了SOA的「A」指的是「架構」，我們不可能不談架構的調整，而達成SOA的目標，而傳統上技術人員最害怕就是對現有程式，從架構上重新調整。

Web Services當然是SOA最佳的技術方案，更精確地講：Web Services是SOA最佳的邊界 （Boundary）技術方案，以達到彈性且有效的鬆散耦合（Loosely Coupling） 的優點。

但是我們看到許多技術人員任意地誤用 Web Services，完全不是從架構面檢討鬆散耦合的必要，也不思考訊息格式標準化的原則，如此不但未能獲得SOA的好處，最終只會得到效能不彰的後果。

3. ESB 是企業導入 SOA 的標準架構
ESB（Enterprise Service Bus）本來只是一家小公司（Sonic Software）在2002年提出來的說法，後來卻被IBM、BEA、Oracle大型軟體公司毫無顧忌的使用。

因為ESB剛好就是中介軟體所能提供的範圍，如果能夠說服客戶：ESB就等於SOA，意即中介軟體廠商可以獲得客戶絕大部分的SOA預算，似乎只要中介軟體是SOA，其前端與後端介接的系統，也自動SOA了，但這當然是不可能的。

不可否認，ESB確實是企業內部資訊易於管理的、整合的服務導向架構，也是當前最流行的SOA導入的基本架構。但是多數廠商先把SOA與ESB畫上等號，再提供客戶ESB的產品，等於是把SOA簡化成只是軟硬體產品的銷售。

從商業需求面檢討SOA的需要
所有資訊技術的發生，絕對不能忘記技術的本質，是要輔助達成商業目標，企業研議SOA的計畫，自然也得回歸到商業需求面，以確定是否需要導入SOA的架構，以及導入的程度。

整合既有的服務，創造更多元的服務
近年來資訊技術歷經多次技術的創新，許多應用程式才剛建置一兩年，新的應用程式已迫不及待採用新的技術，以獲得更好的生產力，企業內的資訊架構同時並存著.NET、Java、COM+等多種技術，而且多半的資訊系統，還未來得及發揮其原先規畫的功效。

因此有些企業開始為了未來系統整合的需求，規定企業內採用單一的標準技術，後來發現即使單一技術，也會每1、2年就推出新版，並導入新的設計方法或工具。

雖然有所謂的「向前相容」原則，也都是在「系統升級」的前提下，才有相容性可言，如果系統因為預算、人力，或是某種技術原因，必須留在有的舊版，便談不上什麼相容性。於是單一技術標準慢慢變得沒有意義，各個專案又回到沒有標準、各自為政的狀態。

可重用（Reusable）一直都是資訊技術在追求累積現有投資的目標，先是模組化在同一程式內，重用相同的程式碼；再來是物件導向以抽象化的方式，達到更廣泛的程式碼重用，但仍須取得原始碼，並以最新的版本重新編譯；而元件化技術則是進一步走向二進位的可重用。

SOA則是企圖以架構重新思考「可重用」的可行性，SOA希望透過鬆散耦合的方式，建立一個穩定的、標準的、技術中立的系統溝通介面（通常就是 Web Services），讓新舊系統可以維持其原來的技術，達到彼此整合的目的。

及時因應快速變化的市場需求
傳統上，資訊技術的供應是跟不上市場變化的，特別是一個因應市場而做的政策變更，常常要程式設計人員檢查、變更、測試每一支相關的程式，也許真正變動到的程式碼比例並不算多，但是幾乎牽涉到的程式都會小小地更動，只要動過都得重新進行相關的測試，少則三個月多則一年半載。

而市場與業務人員最痛苦的，莫過於眼睜睜看著對手，以舊酒裝新瓶的服務，慢慢擴大市場占有率，而自己公司的資訊部卻說：「還要三個月。」

SOA的另一個好處，則是藉由快速整合既有服務的能力，因應市場變化的需求。既然舊系統可以在不用全面更新到新技術，意味著舊系統不必為了新服務改寫程式，當然也就只需為新服務作有限度的測試，大幅縮短新服務上市的時程。BPM（Business Process Management） 則是針對此一需求，提供特定的、輕量化的新服務整合平臺。

確保既有的投資
現有正在運作的資訊系統，不管是才剛建置不久，或是早已運行10多年，都代表著企業核心的運行，即使沒有SOA，既有系統仍然支持著公司每天的運作。

導入SOA的目的，除了前面提及的部分，最重要還是確保今天的投資，不會一到明天就被新技術淘汰，並能隨時配合新技術的推出，在技術中立的架構下，擴大今日投資對未來的服務範圍。

延展性成為系統生命周期的最終議題
當舊系統可以藉由SOA不斷地延續生命，新技術不再企圖取代舊技術，唯一會結束舊系統生命的理由，就是舊系統的服務能量（Capacity）達到原先設計的上限，因為新服務不斷的加入，使得舊系統必須不斷地擴張其服務能量，直到有一天再也無法擴張了，不得不重新設計新的系統取而代之。

傳統應用程式裡的服務，只為「已知」的需求提供服務，為了節省成本常常刻意忽略延展性的設計。在SOA的服務，還要對「未來」提供服務，而我們又不可能一開始就對未來的服務過度投資硬體設備，一方面硬體設備每季都在降價，而人力成本則是逐年上升。

經由預先設計的具有延展性的服務，可以在初期只投資必要的軟硬體，未來隨著服務能量需求的提高，再增加軟、硬體的採購，以「增加機器取代增加人力」，此時「延展性」成為最值錢的設計，畢竟機器投資相對於人力投資便宜了許多。

不管你願不願意，SOA已然改變資訊技術的思考模式，可見的未來會有更多的軟、硬體直接提供SOA架構所需，甚至連開發方法論與開發工具，都會因應SOA在這幾年有重大的改變，寫程式與管理程式的「人」，也會被迫跟著改變。文⊙臺灣微軟應用開發技術經理周旺暾