gic根本沒有CORBA構(gòu)造，而缺省使用t3協(xié)議。
WebSphere和Visual Age銜接緊密，而WebLogic是IDE無(wú)關(guān)的，實(shí)際上，你幾乎可以使用任何的開發(fā)工具。
由此可見，差異還是相當(dāng)多。如果你是一種應(yīng)用服務(wù)器的專家，并不意味著你就是所有應(yīng)用服務(wù)器的專家。這種區(qū)別體現(xiàn)在IDE，debugger，build工具，配置管理等等方面。具備某提供商的某項(xiàng)特殊工具的使用經(jīng)驗(yàn)，可以在評(píng)估該提供商的競(jìng)爭(zhēng)對(duì)手產(chǎn)品時(shí)具有一些便利。但是，不要奢望在不同產(chǎn)品之間進(jìn)行無(wú)縫的轉(zhuǎn)移或銜接。因此，你不得不花費(fèi)足夠多的時(shí)間在熟練掌握這些工具上。
風(fēng)險(xiǎn)7: 設(shè)計(jì)中沒有充分考慮到可伸縮性和產(chǎn)品性能
項(xiàng)目階段：
設(shè)計(jì)
受影響的項(xiàng)目階段:
開發(fā)、負(fù)載測(cè)試及成熟化
對(duì)系統(tǒng)的影響:
可伸縮性、性能、可維護(hù)性
癥狀:
無(wú)法忍受的速度緩慢
系統(tǒng)給服務(wù)器端增加的沉重負(fù)擔(dān)，而無(wú)法利用到一些聚簇技術(shù)。
規(guī)避方案:
把精力集中于性能和可伸縮性方面的需求，明確開發(fā)中要達(dá)到的性能指標(biāo)。如果你需要每秒50個(gè)事務(wù)，而你的EJB設(shè)計(jì)只能提供40個(gè)，那么你就需要考慮替代方案，諸如存儲(chǔ)過(guò)程，批處理，或者重新考慮OLTP的設(shè)計(jì)。
盡可能讓你的提供商加入進(jìn)來(lái)，他們應(yīng)該非常清楚其產(chǎn)品的強(qiáng)項(xiàng)和弱處在哪里，然后給你提供最直接的幫助。
備注:
本風(fēng)險(xiǎn)與風(fēng)險(xiǎn)2 (over-engineering)似乎有些沖突。實(shí)際上，兩者相互影響。 我對(duì)風(fēng)險(xiǎn)2給出的解決方案是，只在絕對(duì)必要的情況下才進(jìn)行構(gòu)建。而對(duì)與性能和可伸縮性，你要預(yù)先劃分好什么是必須要做的。
如果你實(shí)現(xiàn)就識(shí)別出系統(tǒng)需要非常強(qiáng)的可伸縮性，并把它作為一個(gè)比較關(guān)鍵的需求，那么你首先需要選擇一個(gè)帶有很強(qiáng)的簇支持及事務(wù)型緩存的應(yīng)用服務(wù)器。另外，你應(yīng)把業(yè)務(wù)對(duì)象設(shè)計(jì)為EJB，從而可以充分利用服務(wù)器架構(gòu)的優(yōu)勢(shì)。 XP也沒有問(wèn)題，你仍然是只做絕對(duì)必要的工作。
我把這樣的觀點(diǎn)看作是一種檢查和平衡的方法。我們只需要最簡(jiǎn)單可能性的系統(tǒng)，該系統(tǒng)只提供客戶所需要的功能與行為即可。
風(fēng)險(xiǎn)8: 陳舊的開發(fā)過(guò)程
項(xiàng)目階段：
開發(fā)
影響階段:
穩(wěn)定化，成熟化
對(duì)系統(tǒng)的影響:
可維護(hù)性、代碼質(zhì)量
癥狀:
項(xiàng)目計(jì)劃看上去似乎類似于瀑布模型: “首先草構(gòu)設(shè)計(jì)，然后在一個(gè)很長(zhǎng)的周期里進(jìn)行開發(fā)?！?
由于不存在構(gòu)建（build）過(guò)程，每次構(gòu)建都象是噩夢(mèng)
構(gòu)建的日期等于損失開發(fā)的日期，因?yàn)槭裁匆矝]有做成
在集成以前組件沒有分別被充分地測(cè)試過(guò)，而集成測(cè)試意味著將2個(gè)不穩(wěn)定的組件放在一起，然后查看堆棧里的跟蹤結(jié)果。
規(guī)避方案:
好的軟件方法學(xué)將提高你的軟件生命期。此前我已經(jīng)提到XP方法，你可以在網(wǎng)上找到很多這方面的資料。
備注:
JUnit可以用來(lái)進(jìn)行單元測(cè)試，Ant工具可以進(jìn)行編譯與構(gòu)建，這2種工具都對(duì)XP方法有很好的支持。
風(fēng)險(xiǎn)9: 沒有好的架構(gòu)方式
項(xiàng)目階段：
開發(fā)
影響階段:
開發(fā)、穩(wěn)定化、成熟期
對(duì)系統(tǒng)的影響：
可維護(hù)性、可伸縮性、代碼質(zhì)量
癥狀:
在代碼中使用了很多次的核心庫(kù)中發(fā)現(xiàn)Bug。
沒有建立日志標(biāo)準(zhǔn) -- 于是系統(tǒng)的輸出很難讀取或者解析。
不良的不一致的異常處理。在有些站點(diǎn)中我們甚至可以看到，出錯(cuò)信息直接暴露給了最終用戶，例如在用戶在他的購(gòu)物車核帳時(shí)發(fā)送一條SQLException堆棧跟蹤信息，用戶接著會(huì)怎么做？打電話給數(shù)據(jù)庫(kù)管理員要求對(duì)primary ke