把最精彩的东西与你一起分享！！！关心BORLAND，关心DELPHI！！！(0分)

引子:在《.NET的衝擊》中争论的不可开交，纷纷要求李老师出面
嗯, 我又被點名了. 本來我已經在整理一篇文章, 有關Delphi/Delphi.NET和Microsoft.NET的內容, 但是我一直沒有時間完成(我已經在論壇上說了好幾次了). 有些事情我並不方便說, 這些事情應該由Borland的人來說, 例如Tomm兄(转贴者注:台湾宝兰产品经理), 他有關Borland的資訊應該是比較正確的, 因為我是Delphi 6的Beta Tester, 也是Microsoft .NET的Beta Tester.
我可以簡單的說一下我的看法, 不過這些看法是我個人的意見, 各位可以參考一下.
1. Delphi 6仍然將是Window下最好的原生開發工具, 至少在2,3年之內如果我要寫傳統的 原生App, Delphi 6是首選. 只是希望Borland不要急著推出Delphi 6.
2. .NET仍將逐漸成為Window下主流的開發環境, Window下的工具廠商都需要支援. 不過這可能需要最少1到2年的時間.NET才會成為主流.
3. 在.NET開始的版本中, COM+仍然是核心技術. 雖然.NET有了新的元件模型, 類似VCL, 只是可以使用在所有支援.NET的語言中. 但是有關Pooling, Transaction等仍然是靠COM+完成的. 所以COM+仍然非常重要.

4. 在Beta 1中.NET的data-aware做得仍不如Delphi, 但是Beta 2有了改善.
5. 我喜歡C#, 但是我也喜歡Object Pascal. 兩個語言各有優缺點. Borland可以在Delphi.NET中繼續改善Object Pascal. 那麼我可能仍然會用Object Pascal.
事實上我認為.NET的Framework雖然完整, 但是.NET的Framework在我來看仍然和VCL的Component Framework有一點差距. .NET的Framework和Java的class比較接近, 大都需要程式師寫一堆的程式碼. Borland的專長就是設計Framework, 例如OWL, VCL都比Mirosoft設計的好. 因此Borland可以在.NET的Framework上再架構一個比較偏向VCL這種Component Framework, 那麼我們Borlnders就可以在Delphi.NET中享受比使用Microsoft.NET的人更高的生產力. Borland不需要再寫另外一個Framework和.NET Framework競爭, 相反的要好好的利用.NET Framework來建立更棒的.NET VCL. 如此一來即可以避免以往Microsoft利用OS優勢來打擊Borland, 例如MFC對OWL, 又可以建立一個功能完整, 方便好用的Framework來回擊Microsoft.
.NET的確對Borland是一個嚴厲的考驗, 不過我不擔心Borland無法應付. 只要Borland投入足夠的資源, 就像投入JBuilder一樣. 我只是擔心Borland讓一個Team開發Delphi, C++ Builder, Kylix, Kylix For C++. 那麼就不妙了, 這也是我最不能接受的. Delphi明明還為Borland賺不少錢, 卻不投入相對的資源, 有點不公平. 嗯說太多了, 應該閉口讓Tomm來發表一下.
李維

聲明
以下的這篇文章內容是我個人的回憶以及看法，沒有任何特別的偏見，許多的事情是根據我的記憶以及從許多人的訴說中得知的，也許內容不是百分之百的正確，不過我想這些內容有一定的可信度到是可以保證的。當然有一些事情確定的發生時間和順序不一定都和我的記憶一致，不過我想大部份應該是相去不遠的。當然各位如果知道確定的事件而我的記憶有誤，那麼我將非常歡迎您糾正我，我希望這些故事的經歷能夠一直陪我走下去，謝謝。
一直想寫一篇我個人在過去10多年來工作中經歷的一些事情，以及看著一些我認為是偉大的工程師在這些日子中對於資訊界的貢獻。如果你和我的年齡差不多，那麼你可能會對於這些內容很有興趣，因為它們說明了當時許多軟體的興起和沒落的過程以及原因。雖然這些事情已經距離我們很遙遠了，但是我相信許多人仍然對於背後的故事有興趣。如果你沒有經歷過那段美好的回憶，那麼就把這些內容當成是一個有趣的故事來看吧。但是我想更重要的是讓我們一起認識一些偉大的人物，我對於其中的許多人都非常的佩服，也非常的羨慕。我常常在想，如果我也有他們的環境，我是不是也能夠和他們一樣這麼有成就呢?這些人對於以往都有重要的貢獻，在未來也將仍然有重要的影響，因為他們都有一身不凡的技術。對於許多重要的人我都儘量的收集了他們的照片，讓各位也能夠看看這些優秀的工程師和傑出的人物。當然，如果各位也能夠從這些內容中學習到失敗的原因以及成功的經驗，那麼這篇文章就更有價值了。

和Borland的緣由

記得我在大學時第一個在PC上使用的軟體便是SideKick，至今我仍然無法忘記這個讓我津津樂道的軟體，而Borland在當時也就是以SideKick成為全球知名的軟體公司。不過Borland第一個奠立創業基業的軟體卻是我大二使用來交作業的Turbo Pascal。而Turbo Pascal也是第一個我聽到關於Borland的有趣的故事
當年Philippe Kahn (Borland的創使人)和Anders Hejlsberg到美國創業時，便由Anders以組合語言撰寫了Turbo Pascal的編譯器，而Philippe則包辦了Turbo Pascal其他的部份。在這兩位人兄開發完Turbo Pascal之後，窮得快連登廣告的錢都沒有了。但是Philippe為了在Byte雜誌(還記得這個著名的雜誌嗎?)刊登Turbo Pascal的廣告，因此和Anders商量了一個方法，那就是一天他們約了Byte雜誌的人到當時Borland的辦公室討論刊登廣告的事情。
當Byte的人到了Borland之後，Philippe，Anders和公司的助理小姐故意忙著接電話，接受Turbo Pascal的訂單，並且告訴Byte雜誌的人等一下。過了一陣子之後Philippe才進入房間向Byte的人道歉，說他們的Turbo Pascal受到市場的熱烈歡迎，訂單源源不斷的到來，因此可能不需要在Byte雜誌刊登廣告了，接著Philippe向Byte的人展示Turbo Pascal這個產品。由於在當時的機器中Turbo Pascal能夠在少少的RAM中常駐執行，又提供閃電般的編譯速度，立刻讓Byte雜誌的人震驚在當場，憑著專業知識和豐富的經驗，Byte的人也立刻知道這將是一個革命性的軟體，因此馬上希望Philip能夠在Byte雜誌刊登Turbo Pascal的廣告，並且願意以半價刊登。當然，Philip也立刻的答應了，於是一個革命性的軟體Turbo Pascal終於在Byte雜誌刊登出來了，售價49.99美元的Turbo Pascal立刻為Borland帶來了大量的財富，Turbo Pascal也立刻的成為PC上除了基本的Basic之外最暢銷的開發工具，也正式揭開了Borland影響PC開發工具10幾年的序幕。
在Turbo Pascal之後，Borland接著推出了SideKick這套軟體，SideKick可以說是隨後著名的記憶體常駐軟體(TSR)的始祖，也是讓Borland跨出開發工具界，讓幾乎所有PC使用者認識Borland的關鍵軟體。當然SideKick也很快的成為了全球的暢銷軟體，繼續的把Borland往頂尖的軟體公司上推。
而Turbo Pascal也成了我大二，大三撰寫作業的最愛，幾乎所有的作業都是使用Turbo Pascal完成的，當然其時Horowise的Data Structure這門課也是使用Turbo Pascal過關的，因此從那個時候開始我便非常喜歡Borland這家公司，慢慢的也開始對Borland有了特別的感情。
大二時Microsoft也推出了Microsoft Pascal，但是它和Turbo Pascal的確是有一段差距，我使用了一次之後便把它丟到垃圾桶。稍後Borland也推出了Turbo Basic，我記得這個編譯器非常的棒，編譯速度就和Turbo Pascal一樣，是一個非常有前途的產品。但是我不知道為什麼它只有1.0，之後便和Microsoft Pascal一樣消失了。我聽說Microsoft和Borland互相交換條件，Microsoft不進入Pascal的市場，而Borland則退出Basic的市場。至於是不是真的我就不得而知了。
在大二初次的接觸到C語言，第一本閱讀的書便是王興隆先生寫的C語言，也從此開始和C語言結下了淵源。平生第一個使用的C編譯器便是Lattice C，不知道還有沒有人記得。我還記得那個時候使用2個5又1/4磁片抽換以便編譯C程式的情景。稍後Borland終於推出了風行天下的Turbo C編譯器，當然，從此之後Turbo C便成了不離身的工具，而Borland也藉由Turbo C這第三項暢銷產品邁向了世界前10名的項尖軟體公司。
當完2年的兵之後，我在中研院首次使用了C++語言，第一個使用的C++編譯器則是Zortech C/C++，這家公司稍後被Symantec收購成為Symantec C/C++的核心，這個故事稍後再說。後來Borland也推出了Turbo C/C++ 1.0這第一個C/C++編譯器，但是在我和Zortech C/C++比較之後，還是覺得Zortech C/C++比較好，因此就繼續使用Zortech C/C++。一直到Borland的Turbo C/C++ 2.0編譯器推出之後，才逐漸成為C/C++語言的王者，而我也像以往一樣把Zortech C/C++換成了Turbo C/C++。
在1991年到Georgia Institute Of Technology唸碩士時，終於使用自己的零用錢美金49.99購買了生平第一套的正版軟體Turbo C/C++ 4.5，隨後又購買了Borland Pascal。在畢業前的一個Quarter，Microsoft 推出了Microsoft C/C++ 6.0以及MFC 1.0，由於是第一個C/C++的Framework，因此也花了一些錢購買了一套以便瞭解MFC。但是在收到之後卻很失望，因為Microsoft C/C++ 6.0仍然沒有圖形整合發展環境，還是在DOS下的整合發展環境，而且MFC 1.0以我的眼光來看又不好用，而且Microsoft C/C++ 6.0的C/C++最佳化編譯器在其時是一個笑話，不但產生的程式碼效率不好，甚至會產生錯誤的程式碼，許多雜誌也稱Microsoft C/C++ 6.0是一個平庸的(Mediocre)產品。因此就把它丟在一邊。在Microsoft C/C++ 6.0不久之後，Borland終於推了Borland C/C++ 3.0。而這套軟體也開啟了Borland雄霸C/C++編譯器常達5,6年之久的序幕。
Borland C/C++ 3.0推出之後由於擁有第一個在Window下的穩定的圖形整合發展環境，而且它產生的最佳化程式碼也是Microsoft C/C++ 6.0望塵莫及的，因此很快的幾乎所有的C/C++程式師轉而使用Borland C/C++ 3.0。因此在那個時候有一個現象，那就是幾乎所有的公用程式或是Shareware都是使用Borland C/C++開發的，許多硬體廠商的驅動程式也是使用Borland C/C++ 3.0來撰寫的。
1992年我取得Georgia Institute Of Technology的碩士學位之後最想進入的公司便是Borland和Microsoft，不過最後我還是決定回台灣工作。在此時Borland也進入了最巔峰的時期，因為Borland推出了Borland C/C++ 3.1。
Borland在Borland C/C++ 3.0獲得空前的勝利之後，並沒有鬆懈下來，因為Borland知道Borland C/C++ 3.0還缺了一個最重要的勝利因子，那就是如同Microsoft的MFC一樣的C/C++的Framework，因為Borland也看出了Framework將會是未來C/C++產品中最重要的一環科技。不過Borland此時面臨了一個重要的十字路口，那就是到底要自己開發一個和MFC抗衡的Framework，還是要如何做。因為如果要自己開發Framework，那麼勢必要花上一些時間，但是Borland想趁Borland C/C++ 3.0如虹的氣勢再下一城，以便徹底擊潰Microsoft C/C++。因此最後Borland決定向一家叫White Water的公司購買一套由這家公司開發的一個Framework，這套Framework便是後來鼎鼎大名的OWL的源流。而Borland也因為向White Water購買了這套Framework，因而也引進了一個日後非常重要的人物，那就是後來負責開發Delphi的一員大將 - Zack Urlocker。

C/C++的光榮戰役

在Borland購買下White Water的C++ Framework之後，便更命為OWL(Object Window Library)，並且很快的推出了以OWL 1.0為核心的Borland C/C++ 3.1。由於OWL比當時的MFC 1.0封裝的更為完整和好用，再加入Resource Workshop視覺化能力，以及Borland C/C++ 3.1自己最強勁的編譯器和整合發展環境，因此立刻的風靡了全世界，其受歡迎的程度更是遠遠的超過了它的前一版本Borland C/C++ 3.0。
由於Borland C/C++ 3.1的暢銷，立刻讓Borland在C/C++市場一舉擊潰了Microsoft C/C++，市場佔有率超過了50%，是全球第一的C/C++產品，也把Borland推上了最高峰，成為全世界第三大的軟體公司。
很快的，我所工作的開發小組也立刻的以Borland C/C++ 3.1來開發系統，Borland C/C++ 3.1也是我使用過Borland最穩定的C/C++版本之一。也由於那個時候一天到晚都使用C/C++工作，因此就有了一些小心得。稍後我整理了一些東西便投稿到剛出刊不久的RUN!PC，也許是運氣不錯，RUN!PC很快的也登出了我的文章。就是這篇文章登出之後，台灣的Borland注意到了我，開始和我連絡，並且從此展開了和Borland的互動。而Borland C/C++ 3.1也是第一套Borland免費送我的軟體，當然代價就是希望我多寫一些Borland產品的文章。
接著Borland又計劃推出Windows版的Borland Pascal，不過在Borland開發Borland Pascal For Windows 時，當時(現在也還是)最具盛名的Charles Petzold(我的第一本Windows 程式設計的書就是這位仁兄寫的，相信許多人也是看他的書一路學來的)就說除了C/C++之外，Borland不可能做出能夠在 Windows 下執行的Borland Pascal，不過很明顯的，即使是Windows API的大師Charles也錯了。Borland不但做出來了，而且Borland Pascal For Windows 還非常的暢銷，當然Borland Pascal For Windows 也是後來Delphi的根基。
當時的Borland可說是不可一世，不但產品大賣，而且日進斗金。Borland在Scotts Valley豪華的總部也是在那個時候由Philippe Kahn大手筆的花了一億多美金搭建的(想想10年前的60多億台幣可以蓋什麼樣的房子?)。不過也許是Borland太成功了，因此也開始讓Philippe Kahn漸漸的養成了好大喜功，目中無人的態度，也種下了Borland開始走向衰退的因子。




Borland 位於美國加州 Scotts Valley 總部

不過在Borland最強盛的時期，當然也就是Microsoft最想痛宰Borland的時候，在這個時候發生了一個著名的事件和一個著名的虛擬人物。話說由於當時Microsoft的開發工具一直打不過Borland的產品，因此在Microsoft的開發工具刊物上便出現了一個作者不斷的以文章嘲笑Borland，這個作者的筆名是Buck Forland。後來由於這位作者的文章內容以及他的筆名引起了當時Borland的不滿以及大量Borland使用者的強烈抗議，因此稍後這位作者就突然的消失不見了。因此有許多人就推測這個作者應該是Microsoft的工程師，由於一直無法打敗Borland的產品，腦羞成怒，因此才會以這個筆名來發洩。如果各位看倌到現在還摸不著頭為什麼這個筆名會引起軒然大波，那麼請你試著把Buck Foland這兩個英文字的第一個字母一對調就知道為什麼了。現在各位是否會心一笑了?




Philippe Kahn-Borland的創始人

在Borland C/C++ 3.1大獲成功之後，Borland卻開始鬆懈了下去，並且開始走下坡。當然這有許多的原因，我所知其中最重要的原因有數項 :
■Philippe Kahn和當時Borland C/C++的產品經理鬧翻了。這位Borland C/C++的產品經理的名字是Eugene Wang，他是一位非常聰明的中國人。他一手把Borland C/C++ 帶到了世界第一的地位，並且在Borland C/C++ 3.1成功之後有了更偉大的想法，那就是 Eugene Wang 想在下一個Borland C/C++版本中完整的以OWL封裝所有的Windows API，因為OWL 1.0雖然比MFC 1.0來得優秀，但是OWL的隱憂就是OWL尚未完整的封裝所有Windows的API。此外Eugene還計劃以OWL為核心，開發一個類似今日Borland C/C++ Builder的以視覺化元件為開發方式的開發工具。請各位想一想，如果在當時Borland能夠開發出這種C/C++開發工具，那麼將會是一個多麼可怕的產品，稍後Microsoft的Visual C/C++ 1.0只是能夠在整合發展環境中自動產生MFC的程式碼就立刻的轟動了C/C++市場，造成了大量程式師轉入Microsoft的陣營。即使是目前的Borland C/C++ Builder使用的Framework仍然是以Object Pascal以核心的元件Framework，而不是純粹的C/C++程式碼。如果當時 Eugene Wang 能夠做出他心中的下一版Borland C/C++，那麼我想到現在Borland C/C++可能還是市場中第一的C/C++開發工具。不過很不幸的是，Eugene Wang 稍後和Philippe Kahn發生了爭執，Eugene Wang 一氣之下離開了Borland。而Philippe Kahn則認為Borland C/C++的地位已不可動搖，因此也沒有想立刻的做下一版的Borland C/C++。這樣一拖竟然浪費將近2年的時間。
Microsoft Visual C/C++ 1.0在Borland C/C++ 3.1 2年之後推出，並且立刻獲得市場好評。不但在編譯器方面能夠和Borland C/C++ 3.1相抗衡，在整合發展環境方面更大幅領先了Borland C/C++ 3.1，還能夠自動產生MFC的程式碼，再也不是昔日的吳下阿蒙。直到此時Philippe Kahn才從夢中驚醒而急於開發下一代的Borland C/C++ 4.0，但是為時已晚，C/C++的開發工具市場從此就開始逐漸的被Microsoft蠶食了。
Eugene Wang在離開Borland之後，立刻的被Symantec所網羅，稍後Eugene Wang也在非常短的時間之內為Symantec開發出了著名的Symantec C/C++。Symantec C/C++在當時被所有的技術刊物評比為擁有最棒的整合發展環境和最有創意的C/C++開發工具，從此可見Eugene Wang的功力。不過Symantec C/C++稍後也不敵Microsoft Visual C/C++，這個故事的原因在稍後四大C/C++編譯器之爭的段落中再詳細的說明。
我最後聽說Eugene Wang跑去做生意了，並且在前幾年寫了一本教導科技人員如何面試的書籍。我,一直很痛心Borland失去了這麼一位優秀的人材，我常想如果當初Eugene Wang沒有離開Borland，那麼歷史就可能不是現在的這樣了，Sign!!!
■Philippe Kahn大手筆的花了一億多美金買下了Ashton-Tate公司和dBase。在當時許多人都批評Philippe Kahn做了不值得的事情，因為Ashton-Tate不值這麼多錢。但是由於當時Borland多的是錢，因此Philippe Kahn也不多意。不過這並不是Borland走向逐漸走向衰敗的主因，而是在Borland買下了dBase之後，並沒有立刻積極的發展dBase For Windows，反而把dBase丟在一旁。這個原因便是當時Borland的另外一個和資料庫有關的產品Paradox賣得也很好，因此Philippe Kahn並不急著打算開發dBase For Windows。不過Philippe Kahn忘記了一件事情，那就是當時在市場大量人口的dBase程式師需要一個好的Window版dBase，但是Philippe Kahn購買了dBase卻不提供Windows 版的解決方案。因此當稍後Microsoft以極小的代價買下Fox這家公司，並且在數年之後推出FoxPro For Window，吸引了大量原先的dBase程式師以及Paradox的程式師之後，Philippe Kahn才警覺事情不對而充充忙忙的開發dBase For Windows。但是當dBase For Windows 推出之後，Microsoft早已推出了兩個FoxPro For Windows 的版本，而佔據了大部份的市場，dBase For Windows其勢已不可為了。
■Microsoft開始向Borland挖角。由於Microsoft在許多的開發工具戰役中一直被Borland打得灰頭土臉。更何況Borland C/C++ 3.1幾乎搶佔了大部份的市場，因此Microsoft開始準備好好的對付Borland。但是由於其時Borland在編譯器的技術領域領先了Microsoft數年之久，Microsoft無法在短時間之內趕上Borland，因此Microsoft決定使用最有效的方法立刻追上Borland技術，那就是直接挖角。因此稍後Microsoft的Visual C/C++小組有60%的成員是從Borland挖來的，這個舉動不但立刻的讓Borland流失了大量的優秀技術人才，也在數年之後造成了Borland控告Microsoft的導火線。不知道各位看到這裡有什麼感覺，或是沒有感覺。不過我總是覺得Microsoft使用了不好的手段來競爭，並不是光明正大的擊敗Borland，而是使用了不公平的競爭手段。
Philippe Kahn在這段時間不但讓Borland C/C++被Microsoft Visual C/C++反敗為勝，也痛失了幾乎所有dBase的市場，更浪費了大量的金錢，和流失了大量的優秀人員。在這些重要的原因之下，Borland已經不可避免的開始走下坡了。
我最後一次看到Philippe Kahn時是在1994年未於亞特蘭大(Atlanta)參加國際Conference時，還和他打了一聲招呼。後來Philippe Kahn離開了Borland，另外創立了StarFish這家公司，稍後StarFish也被Motorola併購。雖然Borland由於Philippe Kahn一些錯誤的決策而逐漸的從巔峰開始下降，但是Philippe Kahn也不愧為一個人物。因為Philippe Kahn能夠和Bill Gates一直周旋數年之久，而同一時期的許多公司，例如Lotus都一一的被Microsoft所擊敗，因此Philippe Kahn還有一套的。此外Philippe Kahn也是唯一一個擁有工程師特性的Borland CEO，Philippe Kahn仍然重視技術產品和技術人員。但是Borland隨後的CEO幾乎都是Marketing，Finance或是Sales出身的人，這真讓我懷念以往以產品和技術為優先的CEO了。
看完了上面這段今人傷心的歷史之後，再讓我們看看當Borland在受到Microsoft Visual C/C++的強大衝擊之後，如果思索反擊之道。在這段期間也出現了令我敬佩的第一個Borland技術工程師，Carl Quinn。
Carl Quinn在Microsoft Visual C/C++ 1.0推出之後，立刻奉命開發一個能夠和MFC相抗衡的全新OWL，而Carl Quinn也是數年後JBuilder的JBCL Framework的靈魂開發人物。Carl Quinn不但負責開發OWL，也為Borland在元件Framework的技術領域立下了重要的貢獻。由於Carl Quinn的投入，因此開啟了OWL大戰MFC，Borland C/C++纏鬥Visual C/C++數年精彩好戲的序幕。

Carl Quinn到現在我還記得和敬佩的人物，讓我再一次的向他致敬，並且介紹他讓大家認識。





Carl Quinn-我第一個佩服的Borland工程師


Borland C/C++的反擊
火線全開
Borland除了在開發工具市場和Microsoft熱戰之外，其時和Microsoft ，Lotus鼎足而立的Borland看到Microsoft和Lotus正在試算表工具以及文書處理工具大戰之暇，不思好好的集中資源開發新的開發工具和資料庫工具(下一節會詳說)，也不甘寂莫的投入了大量的資源進入這個慘烈的市場。也許是當是Borland太有錢了，或是Philippe Kahn腦袋有問題，居然決定進入這個Borland陌生的市場，更何況在Borland投入時Lotus已現敗象，市場已經慢慢的被Microsoft所一步一步的掌握了。
Borland進入Office市場的第一個產品便是著名的Quattro Pro這個試算表，雖然Quattro Pro是一個不錯的產品，而且當時由Borland C/C++編譯器所開發的Quattro Pro在執行效率上幾乎是最好的，但是Borland沒有想到使用試算表的使用者是一般的辦公室人員，這些人注重的是方便性和功能性，而不是最重視執行速度，這和開發人員是不一樣的。Borland以開發者的心態來開發試算表工具基本上是走錯了方向。因此我記得在那段時間中，雜誌評比Microsoft的Excel，Lotus的1-2-3和Borland的Quattro Pro時，在功能方面領先的都是Excel和Lotus，在執行效率方面領先的則是Excel和Quattro Pro。到了試算表熱戰的未期1-2-3甚至比不上Quattro Pro，因此Lotus敗走試算表市場已是不可避免的結果了。
不過Borland雖然贏了1-2-3，但是和Excel仍然有一大段的距離，Microsoft一統試算表江山之勢已不可搖，因此最後Borland在損失了大量的資源之後，Quattro Pro只能賣給Novell。除了Quattro Pro之外，Borland也投入了很多的資源秘密的開發一個代號稱為Spring的文書處理程式準備和Microsoft的Word以及WordPerfect競爭，這可能是許多人不知道的。但是這個產品最後仍然無法問市而胎死腹中，在文書處理市場方面Borland不但浪費了時間，更虛擲了大量的資源。Philippe Kahn在Office產品方面消耗了Borland大量的金錢和時間，卻落得鎩羽而歸，更連累了開發工具市場以及最有可能成功的資料庫產品市場。
另外一個和Borland無關的故事是關於Excel如何興起的。話說當Lotus 1-2-3最盛的時期，Microsoft一直計覬覦這個市場，但是苦於無法開發一個能夠和1-2-3相競爭的產品。有一次Lotus 1-2-3舉辦了一個Lotus 1-2-3的技術研討會，由當時Lotus 1-2-3的首席工程師主講。在Microsoft知道了這個技術研討會之後，立刻派出了最好的程式設計師，在現場詢問Lotus是如何開發1-2-3的並且也趁機詢問這位首席工程師如何克服1-2-3在許多技術方面的難點，而這些困難處正是 Microsoft 的工程師無法克服的。
當時在現場中Lotus的這位首席工程師雖然知道這些人是Microsoft派來的，而且詢問的問題正是1-2-3許多關鍵的技術點。但是這位首席工程師憑藉著多年開發經驗，並且認為Microsoft不可能在短期之內追上1-2-3，因此就沒有多做保留的回答了許多重要的問題。沒有想Microsoft的這些程式師也是非常聰明的的人，在一經指點之後，立刻暢然全通，在短短的1,2個版本之後不但馬上追上了1-2-3，在許多功能方面更是青出於藍，1-2-3便逐漸失去優勢了。我想這位1-2-3的首席工程師一定很後悔當時回答了關鍵的技術問題吧。
結論 : 千萬不要小看Microsoft，他是非常精於模仿的，也永遠不要小看你的對手。

資料庫市場的失誤

當Borland全盛的時期，事實上也是發展資料庫產品最好的機會。因為在當時Borland手握DOS最暢銷的Paradox，又併購了Ashton-Tate而擁有世界大部份dBase的市場，後來又從 Digital 取得了真正的 RDBMS-InterBase，可以說是全世界資料庫實力最雄厚的廠商。當時的 Oracle 和 Borland 比起來，簡直是小巫見大巫，而 Sybase 更不知道在那裡。如果當時 Borland 能夠好好的掌握這個機會，並且極力發展資料庫產品的話，那麼現在Borland 就算不是世界第一的軟體公司，也將是世界第二的軟體廠商。
可惜 Philippe Kahn 並沒有看到這個在年代80未到90年代成長最快速的產品。說句笑話的是，如果當時Philippe Kahn的死對頭Bill Gates早一點對 Philippe Kahn 說出Information At Your Finger-Tip』的話，那麼 Borland 就可能是現在的 Oracle 了。
說到資料庫市場就不得不對 Microsoft 的眼光佩服，也可以看到Microsoft行銷能力的強悍。當Microsoft以FoxPro For Window強佔了開發者的資料庫市場之後，又看到了一般使用者也需要使用簡易好用的資料庫管理工具。因此發展出了Access。但是當時在這種市場中，Paradox佔有開發者的資料庫大部份的江山，而一般使用者的資料庫管理工具市場則由Lotus的Approach拔得先機。Microsoft為了扳回劣勢，我還記得在當時Visual Basic 3的套裝軟體中Microsoft附了一張優待卷，只要800新台幣就可以買一套Access。這簡直就是流血大拍賣，目標很明顯，就是當時在市場中賣1萬多元的Lotus Approach。果然，Microsoft此招一出，Approach便在市場被Access打得落花流水，很快的便失去了市場，也很快的退出了市場。從此一般使用者的資料庫管理工具市場便逐漸由Access所取代。
但是Borland並沒有警覺到Access會繼續的往開發者市場進功，因此仍然沒有加緊在Paradox產品上開發，Borland總覺得以Paradox在市場的地位是無法輕易憾動的，而且Access的目標市場也不是Paradox的市場。但是Borland忘記了Microsoft非常散擅長模仿，因此在隨後的Access版本中，Microsoft不斷的為Access加入可程式設計的功能，因此也逐漸的吸引了一些Paradox入門使用者的市場，再加入FoxPro For Window又持續的強功開發者資料庫市場，Paradox終於在背腹受敵之下也逐漸的敗下陣來。雖然在未期Philippe Kahn已經對Paradox投下重兵，希望能夠挽回Paradox的劣勢，奈何時不我予，Paradox在奮鬥了Paradox 6和Paradox 7的2個版本之後，終究難逃失敗的命運。
當時我看到Microsoft如何打擊競爭對手時，我就和朋友開玩笑的說。Microsoft有天下無敵的3絕招，那就是『打不過你就模仿你(這讓我想起電影秘密客(Mimic) )，再打不過就和你比流血，看誰流得久(這讓我想起吸血鬼)，最後如果再不行的話，那就挖光你的人(這讓我想起電影 Other People's Money)』。Lotus就在Microsoft的前2個絕招下到地不起，而Borland還算是功力深厚的了，連中了3絕招，雖然不像Lotus和許多其他公司一樣從此Bye-Bye，但也是受傷極重的了。

ODBC和IDAPI之爭

當Microsoft在逐漸的擊敗他的競爭對手，並且擁有了大部份PC資料庫市場之後，便慢慢的瞭解到掌握標準的重要性。此外Microsoft為了統一各應用程式之間不同資料的存取，因此開始製定存取資料的統一標準-ODBC。
Microsoft更大的目的是為了準備和瞄準下一場的大戰，那就是PC上的RDBMS產品。
當然，Microsoft要一統資料存取的江山，Borland不同意，其時一心想從Microsoft扳回一城的IBM也不同意，而Novell更是害怕，因為Novell怕Microsoft成功之後，Netware會消失得更快。於是IBM，Novell和Borland以及一些其他的小廠便聚集在一起，決定也製定一套存取資料的標準介面來和Microsoft對抗，這個製定的資料存取標準便是IDAPI。此時也正式揭開了ODBC和IDAPI競爭的序幕。
不過IBM，Novell和Borland的結合很快的就證明是失敗的，因為就像稍後說明的一樣，IBM在PC軟體上的發展一直是三心二意，反反覆覆，因此當IDAPI 1.0的規格出來之後，IBM這位老兄又失去了和Microsoft對抗的興趣，於是就退出了IDAPI聯盟。至於Novell就更不用說了，Novell對於和Microsoft一象是『說說可以，真打不行』，一定要找到一群廠商才敢和Microsoft對抗。Novell在眼看IBM推出之後，也馬上不戰而降，很快的就也退出IDAPI聯盟，這個現象和稍後Novell對於和Borland秘密合作的Appware/AppBuilder計劃如出一轍，都是虎頭蛇尾，草草收場。
在兩個大ㄎㄚ臨陣脫逃之後，Philippe Kahn仍然不畏懼Microsoft的競爭，還是以IDAPI 1.0的規格實作資料存取引擎，這就是我們現在使用的BDE/IDAPI和SQL Links的前身。當時IDAPI 1.0的功能規格比ODBC 1.0好得多了，我記得Delphi 1.0使用的BDE/IDAPI和SQL Links驅動程式也比當時慢得像烏龜的ODBC快上太多了。只可惜在IBM和Novell推出之後，其他的小廠也是一轟而散。因此Borland只能靠自己獨自和Microsoft對抗。Borland能夠以少量的資源一直對抗到Delphi 3的BDE/IDAPI才逐漸的被ODBC追過，也算是非戰之罪了。怪也只能怪Borland意志不堅的盟友。當然由於IBM和Novell的行事做風是如此，在稍後許多能夠和Microsoft一較長短的機會也因為如此而消逝，最後自食惡果，逐漸失去了PC的軟體市場，再也無力和Microsoft抗衡了。
現在呢Borland似乎記取了當時的錯誤, 正努力的在Linux上定義標準資料存取介面dbExpress, 我希望也祝福Borland能夠成功.
未完待續……

2001 年軟體界的巨星 - Kylix
什麼是Kylix?如果你還不知道的話，那麼你可能已經很久沒有注意軟體界的大事了。Kylix是Borland公司以Windows中最受歡迎的RAD工具-Delphi為基礎，特別為Linux作業系統打造的視覺化RAD工具，簡單的說Kylix就是Delphi For Linux。
為什麼Kylix這麼今人興奮呢?這是因為Linux雖然是一個現在非常流行的作業系統，但是在Linux上要開發應用程式程式師大都使用GNU的GCC編譯器。雖然 gcc 是一個非常穩定編譯器，但是Linux上的程式師必須一行一行的撰寫程式碼，同時必須對於Linux作業系統非常的瞭解。如果還想開發X Window的應用程式，那麼程式師還必須學習X Window API或是Linux上最流行的的兩個圖形使用者介面套件GNOME/KDE的API。由於這個門檻相當的高，因此只有少數的人能夠在Linux上開發應用程式，開發的時程也非常的漫長，也造成了Linux上應用程式的數量一直無法追上Window上的應用程式。但是Kylix的推出將會改變這個情形，因為Kylix就像是Window平台的Delphi或是Visual Basic一樣，它提供了視覺化的整合發展環境，也提供了拖曳元件來設計圖形使用者介面以及應用程式的能力。不但可以立刻讓熟悉Windows開發環境的程式師在Linux上開發應用程式，也能夠讓現有的Linux立刻的增加數倍的生產力。
Kylix不但提供了高生產力，視覺化的整合發展環境，更結合了Delphi有名的閃電般的編譯器，讓程式師在Kylix中開發Linux應用程式有如沐浴在春風中一樣，今人非常的舒服。雖然Kylix現在只是第一版，但是它提供的整合發展環境卻比Window上的Delphi 5.0還先進，可以說Kylix的開發環境大概是Delphi 5.5的水準。從這一點就可以看出Borland對於Kylix的重視。
Kylix 1.0提供了非常豐富的開發功能，能夠讓程式師開發各類的Linux應用程式。基本上Kylix提供了超過了150個的元件讓程式師使用，而Kylix 1.0本身則是由4大核心功能打造而成，它們分別是:
提供視覺化圖形使用者介面功能的CLX元件組
包含了按鈕，串列盒，Grid，圖形元件等先進的視覺化元件。CLX元件不但可以節省程式師大量的開發時間，能夠同時開發執行在KDE/GNOME圖形套件中的Linux應用程式，更是一套跨平台的Framework。由CLX開發出來的應用程式也能夠藉由Delphi 6編譯之後在Window平台執行，反之亦可。當然Borland也延續了Delphi的VCL優良傳統，提供了幾乎所有視覺化CLX元件的原始程式，允許程式師根據自己的需求來修改。
提供Socket和Internet/Intranet程式能力的NetCLX
這組元件允許程式師開發Linux上的Socket應用程式。讓程式師能夠結合CLX和NetCLX開發出圖形使用者介面的通訊應用程式。此外Borland也把Delphi的WebBroker功能移植到Kylix之中，讓Linux的程式師可以快速的開發執行在Apache中的Internet/Intranet應用系統。這對於Linux上的程式師是一個非常棒的訊息，因為藉由Kylix，Linux上的程式師終於可以快速的開發各種Web應用程式，如果再結合稍後介紹存取資料庫的DataCLX，那麼Linux程式師可以開發出極為複雜，先進的Linux Web應用系統。同樣的，Borland也將在Delphi 6中支援Apache的功能。
高速的資料存取引擎DBExpress
要如何在Linux平台中存取資料相信是許多Linux程式師的夢魘，因此大部份的Linux應用程式都是以系統程式，公用程式或是其他周邊小程式為主。但是不否否認的，要讓Linux作業系統能夠成為大眾接受的平台，那麼Linux就必須擁有能夠處理資料的應用系統。在Kylix沒有出現之前，Linux的程式師只能使用JDBC/ODBC存取資料庫。但是Borland為了在Linux和Window平台中建立新一代的跨平台資料存取引擎，特別集中的資源開發出了所謂的DBExpress資料存取引擎。DBExpress資料存取引擎能夠提供最有效率的資料存取速度，讓Linux和Window平台的程式師能夠使用一組相同的元件來存取各種關連資料庫。讓存取資料不再是Linux程式師的最痛，在稍後的章節中將會詳細的介紹DBExpress。
視覺化存取資料的DataCLX元件組
一旦Linux應用程式藉由DBExpress取得了資料之後，DataCLX這組視覺化的元件能夠以各種先進的圖形使用者介面控制元件來呈現資料。這些元件包含了按鈕，串列盒，下拉盒，甚至是複雜的Grid元件。讓展示資料不再是Linux程式師最不願意做的事情。DataCLX元件組將會快速的讓Linux的商業軟體出現在市場之中。
下圖便是Kylix 1.0的核心功能架構圖。


Kylix的4大核心功能

在下面的的內容中，將會進一步的詳細介紹Kylix提供的強大功能，讓各位能夠更瞭解Kylix的極致性能以及它的致命吸引力。
最具生產力的整合發展環境
在Linux平台中開發應用程式最不方便的地方是什麼?那就是Linux程式師缺乏像Window平台下高生產力的開發環境。雖然Linux提供了一些編輯器，如vi，或是一些圖形化的編輯器能夠讓程式師敲打程式。但是這畢竟不方便，此外程式師在打完程式碼之後還得回到命令列下編譯程式，在數個不同的環境中開發應用程式，相當的不方便。因此Kylix的第一個目標便是提供Linux平台下的程式師一個擁有最高生產力的開發環境。在這個開發環境中程式師可以進行所有開發應用系統的工作，從敲打程式碼，編譯程式，連結程式，到執行和除錯程式都能夠一氣喝成。此外這個開發環境必須提供視覺化程式設計的功能，以及拖曳元件，設計表單的工作。簡單的說Kylix要提供比類似Window平台下的Delphi開發環境。 雖然不簡單，但是Borland再次的突破了技術瓶頸，在Linux作業系統下提供了比Window平台下Delphi 5更為先進的整合發展環境。下圖便是Kylix的整合發展環境，從圖中各位可以看到，畫面上方便是有名的元件盤，允許程式師以拖曳元件的方式設計視覺化的表單，左邊是物件檢視器可以讓程式師以動態的修改表單中的元件。這整個整合發展環境是執行在KDE的圖形使用者介面套件之中。


終於展露神秘面紗的Kylix整合發展環境

此外Kylix的編輯器提供了強大的功能讓Linux程式師能夠快速的開發應用程式。這些強大的功能包含了以不同顏色顯示語法的能力，Code Complete和Code Insight等。例如下圖便是Kylix的編輯器，請注意當我在編輯器中輸入了一個物件變數StatusBar1之後，編輯器便會在一個視窗中自動顯示這個元件所有可以呼叫的方法以及能夠存取的特性。此外這個視窗還能夠以不同的顏色來區分function，procedure, constructor，destructor和property等，讓程式師能夠一目瞭然，非常的方便。在這裡也偷偷的告訴各位，下圖中的Code Insight是Delphi 5的Code Insight的改善版，Delphi 6也是使用這個Code Insight，而Kylix則搶先一步提供了這個更先進的Code Insight。


Kylix的Code Insight功能

當然Kylix的整合發展環境也允許客製化開發環境，從編輯器的功能，字形的顏色，大小，到Code Insight的反應速度，整合發展環境的提示功能等，程式師都可以客製化，以打造一個自己喜歡的工作環境。例如下面的兩個圖形即顯示了我在Kylix整合發展環境中自訂我自己喜歡的工作環境。


Kylix允許程式師完全的控制整合發展環境


Kylix允許程式師任意調整工作使用的編輯器

除此之外，除錯能力相信是許多程式師非常重視的開發功能，畢竟程式師有許多的時間是花在除錯應用程式之上。Kylix提供了全方位的除錯能力，不但能夠讓程式師設定中斷點，也能夠檢查任何的變數和物件的狀態。提供了程式師一個高效率的測試和除錯環境。例如下圖便是我在Kylix整合發展環境中執行並且除錯應用程式。從下圖中也可以看出Kylix提供的豐富圖形使用者介面功能，以及處理中文的能力。


程式師可以在Kylix整合發展環境中執行和除錯應用程式

當然由Kylix編譯出來的應用程式是原生的Linux應用程式，程式師可以立刻的在Linux圖形使用者介面中執行。例如下圖便是我使用Kylix建立的一個範例應用程式，並且獨立的執行在KDE環境之中。看到這一幕真是今人感動不已。藉由Kylix，Borland終於可以讓許多的程式師得以美夢成真。那就是Linux的程式師終於可以在Linux作業系統中舒服，而且有效率的開發應用系統了。


Kylix建立的Linux應用程式執行在KDE之中

CLX視覺化元件
在Linux 中最流行的的圖形使用者介面套件便屬KDE和GNOME了，許多的Linux程式師都渴望能夠撰寫一些能夠執行在這兩個圖形套件之中的應用程式，但是這可不是一件容易的事情。Linux的程式師必須先學習圖形套件的API，再撰寫數百行的程式碼，才能夠開發完成一個小小的圖形應用程式，就像數年前使用Window API撰寫Window應用程式一樣。不過除非你對於撰寫圖形套件API有特別的喜好，否則這種苦日子在Kylix出來之後就終於可以結束了。Kylix不但提供了上百個視覺化元件讓程式師可以使用拖曳的方式立刻開發圖形套件的應用程式，而且許多這些視覺化元件都提供了高等的功能和複雜的視覺化效果，讓Linux的程式師可以快速的便開發出可以應用於複雜的情形的圖形使用者介面應用程式，再也不用花上數天，甚至是數個禮拜的時間。下面的圖形就是Kylix提供的視覺化元件。舉凡一般的功能表，按鈕，串列盒元件，到圖形圖形，LED元件，計時元件，再到複雜的Tab控制元件和影像串列盒等元件，Kylix都提供給了程式師。比起Window平台上提供的視覺化功能實在是不遑多讓。有了這些元件之後，Linux程式師可以立刻以數倍的效率開發KDE/GNOME圖形套件下的應用程式。




Kylix提供了上百個視覺化的元件讓程式師開發圖形使用者介面應用程式

除了視覺化元件之外，Borland也花費了許多的苦心讓Linux平台的Kylix和Window平台的Delphi儘量提供一致的架構，以便讓程式師能夠在兩個不同的平台中都使用一樣的技術來開發應用系統。下圖便是Kylix和Delphi的架構比較圖，從圖中我們可以看到Kylix和Delphi的整合發展環境和應用程式在架構上幾乎是一樣的。除了編譯之後產生的機器碼平台不一樣，以及使用的圖形使用者介面層不一樣之外，Kylix和Delphi幾乎擁有相同的架構，以及技術。在這裡也先透露給各位，Delphi 6也將可以使用和Kylix一樣的CLX元件來開發圖形使用者應用程式，讓不同平台的圖形使用者應用程式能夠立刻的移植到另外一個平台。


Window平台的Delphi和Linux平台的Kylix

WebBroker開發Internet/Intranet的功能
要如何在Linux平台中開發Internet/Intranet應用系統?相信許多人使用的方法是純手工打造，直接使用Apache伺服器或是使用PHP開發Web應用程式。Kylix也允許Linux程式師使用純手工打造的方式來開發Web應用系統，不過Kylix提供了更為先進的視覺化元件允許程式師使用視覺化的方式來快速開發Web應用程式。此外這些Web應用程式完全可以使用Kylix的Object Pascal或是稍後推出的C/C++語言，而不需要使用其他的語言。Kylix把Delphi的WebBroker技術移植到Linux平台中，並且繼續的強化WebBroker技術，下圖便是Kylix提供的開發Web應用方案的視覺化元件。


Kylix提供了視覺化元件開發Internet/Intranet應用程式

WebBroker技術允許程式師使用一種技術(即WebBroker)就可以開發CGI/Apache DSO/ISAPI/NSAPI各種不同型態的Internet/Intranet應用程式。在Kylix中WebBroker允許程式師建立CGI和Apache DSO型態的應用程式，例如下圖便是Kylix Web精靈提供的功能。


Kylix可以幫助程式師建立CGI或是Apache DSO型態的Internet/Intranet應用程式

Kylix的WebBroker技術不但可以讓程式師建立一般的Web應用程式，程式師更可以結合稍後介紹的DBExpress元件來存取資料庫中的資料，再把資料和網頁內容結合以建立更為複雜的Internet/Intranet應用系統。這種開發方式不但比Linux中其他語言來得快速，而且Kylix藉由元件化的設計觀念因此可以讓程式師開發出更穩定的Internet/Intranet應用系統。下圖便是使用Kylix的WebBroker技術開發出來的Internet/Intranet應用程式，從圖中我們可以看到WebBroker果然可以開發出實際的Internet/Intranet應用程式。


由Kylix開發出來的Internet/Intranet應用程式

除了WebBroker技術之外，Borland更計劃在未來繼續為Kylix加入即將出現在Delphi 6的SiteExpress技術，讓程式師能夠更進一步的開發功能強勁的Web應用系統，並且將藉由SiteExpress逐步提供程式師一個開發Internet/Intranet應用系統First-Class的工作環境。
高效率的DBExpress元件
要如何在Linux中存取資料庫之中的資料並且能夠讓使用者處理這些資料呢?這相信是許多Linux程式師最感痛苦的地方。由於Linux並沒有一個標準的資料存取引擎，因此Linux程式師以往就只能夠使用ODBC API，或是使用Java藉由JDBC來存取資料。不過不管是使用ODBC或是JDBC API，這都是非常辛苦，也非常沒有生產力的工作。Borland在開發Kylix時，為了提供程式師一個Linux上高效率的資料存取方式，因此決定開發一套標準資料存取引擎，並且公佈這個引擎的介面，讓所有有興趣的程式師都能夠藉由這個標準來存取各式不同的資料。此外這個引擎也必須能夠跨平台，以便Linux和Window的程式師都能夠使用相同的技術來存取資料，這個開發出來的引擎便是DBExpress
DBExpress引擎的觀念是提供一層非常簡單，有效率的資料存取介面和資料來源引擎。藉由這個介面，程式師能夠存取各種不同的資料來源，卻只需要瞭解一個相同的介面即可，而在這個介面之後則是實作存取各種實際資料來源的引擎。Kylix的DataCLX元件組便藉由封裝這個介面的DBExpress元件組來存取並且展示各種資料來源。在Kylix 1.0版中，Borland提供了四個不同資料來源的引擎，這些引擎是存取MySQL，InterBase，DB2以及Oracle資料庫的引擎。此外Kylix也封裝了存取引擎介面的元件，藉由這些DBExpress元件，程式師可以使用視覺化的方式藉由特定的的DBExpress引擎存取到各種資料來源。下圖便是這組DBExpress元件，藉由這些DBExpress元件，程式師可以立刻的連結到MySQL，InterBase，DB2以及Oracle資料庫並且開始存取資料。


DBExpress元件組提供存取資料來源的能力

例如下圖便是啟動TSQLConnection元件，並且指定要連結到特定的InterBase資料庫，並且設定使用者名稱，密碼等必要的連結資訊。程式師只需要使用點選的方式，便可以以視覺化的方式存取資料來源，再也不用寫數百行的程式碼來做到相同的事情，大幅的提升生產力。


DBExpress的TSQLConnection元件允許程式師指定要連結的資料來源

DBExpress引擎為了提供最有效率的資料存取模式，因此使用了名稱Firehose的資料存取能力。這種方式的資料存取方式提供只單向的cursor能力，並且不提供任何緩衝區的機制，這和BDE/IDAPI提供大量緩衝區的機制非常的不一樣。由於Firehose只提供單向的cursor並且沒有提供緩衝區能力，因此一次只能提供一筆資料，而且不能向後存取資料，因此這種模型是存取資料速度最快的模型，沒有任何的負荷。不過一般的資料庫應用程式都必須來回的處理資料，那麼Firehose如何滿足這種需求?答案是Firehose無法滿足這種需求，不過Delphi的MIDAS卻是一個提供雙向cursor並且提供緩衝區能力的資料存取引擎。因此Kylix的DBExpress元件組便可以結合Firehose和MIDAS，這樣不但可以提供Firehose最快速存取資料的好處，也能夠讓程式師充分使用MIDAS提供的所有資料處理能力，因此可以讓程式師魚與熊掌兼而得之。事實上Delphi 6也將使用相同的架構提供Window程式師存取資料的能力。下圖便是DBExpress結合Firehose和MIDAS的功能示意圖。

DBExpress的核心是數個簡潔的介面(Interface)組成的，這些介面定義了如何跟特定的資料庫廠商介面溝通的ISQLDriver，如何連結資料庫的ISQLConnection，如何對資料來源下達命令的ISQLCommand，如何控制Cursor的ISQLCursor，以及存取資料庫MetaData的ISQLMetaData。這些介面定義的目標就是簡易，有效率，它們和Java的JDBC有非常類似的觀念，但是Borland又提供了MIDAS來巧妙的結合這些介面，因此提供了比JDBC高上數倍的生產力。
雖然DBExpress在Kylix中是第一個版本，但是DBExpress的執行速度卻已經和開發多年的BDE/IDAPI有著幾乎一樣的表現，絲毫不遜色，甚至有一些項目還比BDE/IDAPI表現得更好。例如下圖是DBExpress和BDE/IDAPI在連結InterBase的表現，從下面的資料中可以看出DBExpress還略勝一籌。
開啟資料庫 BDE dbExpress
時間 1.832
1.467


此外我還寫了一些測試程式，讓DBExpress和BDE/IDAPI隨機產生資料，並且異動到資料庫之中。下面便是執行測試的結果，從這些數據中我們可以看出DBExpress和BDE/IDAPI幾乎是不分上下的。
新增資料筆數 DBExpress BDE
10 0.052 0.036
100 0.334 0.342
1000 3.186 3.421

2000 6.514 6.732
10000 37.992 36.109

不過DBExpress更吸引人的地方是如果程式師知道如何微調它的話，那麼它幾乎可以使用閃電般的速度處理資料。例如下面的資料便是經過我調整之後的DBExpress和BDE/IDAPI比較處理資料的結果。從這些數據中我們可以看到調整之後的DBExpress幾乎以不先3倍的速度在處理資料，把BDE/IDAPI遠遠的拋在後面。看到這樣的結果，真不禁今人佩服Borland開發DBExpress的功力。
新增資料筆數 DBExpress BDE 改良的DBExpress
10 0.052 0.036 0.047

100 0.334 0.342 0.206

1000
3.186 3.421 1.19
2000 6.514 6.732 2.686

10000 37.992 36.109 17.472


DBExpress不但提供了Linux平台上存取資料的標準，更提供了快速的處理能力，和跨平台的功能。光憑這幾點便足以讓DBExpress吸引程式師的目光。雖然在Kylix 1.0中只提供了存取MySQL，InterBase，DB2以及Oracle資料庫，但是Borland已經宣告在隨後會接著推出更多資料庫的引擎，例如Sybase，Informix等。而且這些引擎會在準備好之後立刻的提供Linux以及Window的程式師使用，而不需要再等待到下一個Kylix的版本。DBExpress的出現在Linux造成了非常有趣的現象，那就是由於在Linux上還沒有一套標準的資料存取引擎，因此Borland目前獨自開發的DBExpress引擎有可能憑藉其強大的功能和生產力，再搭配Kylix，有可能讓DBExpress成為Linux平台上的標準，事實上我感覺Borland正在Linux平台上盡其所長的在定義標準。除了資料存取引擎之外，Borland也正在和Third-Party定義類似Window平台上應用程式互相溝通的標準架構，再加入Borland有VisiBroker和EJB這兩套元件模型產品，Borland極有可能在Linux平台上重現其數年前是Window平台開發工具霸主的地位。DBExpress是如此的強大以及有趣，如果日後有的話，當然會為各位再進一步的介紹DBExpress各種的功能。
當然Kylix提供的功能絕不是短短的一篇文章能夠詳細說明的。Kylix提供的功能遠超過本文章到目前為止討論的。此外如果你是一個行家的話，那就更不能不知道Borland在Kylix背後付出的苦心。那就是Kylix的執行時期函式館 - RTL(Run Time Library)。
Kylix的執行時期函式館
為了在Linux作業系統中提供一個RAD工具，Borland的RTL在背後進做了許多的事情，同時也撰寫來數以千計的函式讓程式師呼叫使用之。更難得可貴的是，為了提供跨Linux和Window平台的能力。Kylix的RTL以及即將推出的Delphi 6 RTL更經過了大幅度的重新改寫，以便讓幾乎相同RTL能夠同時的執行在Linux和Window之中。這其中Borland付出的巨大資源可能會被許多程式師所忽略，不過行家才會瞭解RTL才是真正的幕後英雄。
結論
Kylix的推出不但再次的各世人證明Borland是全世界最頂尖的獨立工具開發廠商之外，也代表了Linux上的應用軟體也將會快速的篷勃發展起來。2001年第一季的Object Pascal版本的Kylix的主要目標市場是Linux上的應用程式開發工具市場，但是隨後準備推出的C/C++版本的Kylix則將會對Linux上的系統程式產生巨大的影響，因為連整個Linux的核心都將可以使用Kylix來建立。
Kylix雖然是一個RAD工具，但是它能夠涵蓋應用程式開發，系統程式開發，甚至是Linux作業系統核心開發的能力讓它足以成為Linux上的殺手級的軟體。因此如果各位讀者對於開發Linux應用程式有興趣，或是Linux上的玩家，都不能夠錯過Kylix。稍待日後Kylix再加入完整的元件開發模型，例如開發CORBA，或是藉由SOAP和EJB以及COM+整合，那麼Kylix將會是Linux打上打遍天下

唉 早看过了[]

樂趣無窮，可能無限的新技術-Web Service

雖然電子商務的狂熱在最近似乎有減溫的現象，讓許多人能夠回歸到正常的步調之中，不過隨著電子商務而發展的軟體技術並沒有稍停腳步，反而更加蓬勃發展。因為由這些技術創造的應用早已成為許多人生活的一部份，甚至是開啟未來趨勢的基石。在目前最熱門且最被看好的技術便是所謂的Web Service了，那麼什麼是Web Service呢？
簡單的說，Web Service是一種想把全世界的Internet/Intranet變成一個虛擬計算環境的觀念和技術。在由Web Service組成的虛擬環境中使用者可以任何的用戶端軟體，例如瀏覽器，一般的Window或是Java應用程式或是電子行動設備等，來呼叫Web Service提供的服務。而Web Service本身則可以由任何的技術實作，例如開發者可以使用Delphi，Java，C/C++或是C#等的語言和工具來開發。
Web Service是建立在開放和標準的規格之上，允許異質的用戶端呼叫以使用它提供的服務。因此各種異質的用戶端必須使用一種共通的溝通標準才能夠順利的和由各種不同技術實作的Web Service互通。目前最流行而且最具潛力的溝通標準當屬SOAP了。
SOAP (Simple Object Access Protocol)是由Don Box起草，並且獲得IBM，Microsoft，Lotus和UserLand等大型公司支持而成為W3C標準之一的通訊協定規格。從SOAP的名稱中我們便可以知道它是讓用戶端呼叫遠端物件服務的一種機制。SOAP以XML標準封裝呼叫遠端服務的格式，有別於其他分散式物件模型呼叫特定的呼叫格式，例如CORBA的GIOP以及DCOM的ORPC。由於SOAP以XML封裝呼叫格式，因此它可以使用任何的實體傳輸層來傳送，例如HTTP，TCP或是SMTP等。也許讓我們使用一個簡單的概例來說明會讓各位更容易的瞭解。
假設現在我在Linux平台上以Java語言實作了一個Web Service，這個Web Service提供了一個服務GetSystemTime。這個服務接受一個使用者名稱和一個密碼，如果成功的登錄之後，這個服務便會回傳Linux平台目前的系統時間。那麼我可以使用Delphi以SOAP的標準封裝使用者名稱和密碼來呼叫這個在Linux平台上的GetSystemTime服務。例如下面就可能是由SOAP封裝的格式：

GordonLi
xx12yh_49

藉由SOAP，Delphi的用戶端應用程式可以輕易的呼叫Linux平台上的Web Service，而無需關心這個Web Service是由什麼技術實作的，或是存在於任何地方，更不需要以特定的二進位格式來封裝呼叫。因此藉由Web Service和SOAP，開發者可以輕易的整合各種異質平台，異質分散式物件模型，而充分的利用所有的計算資源，這在以前是不可能輕易做到的，同時Web Service和SOAP也為未來的發展開啟了另一扇的大門。目前Web Service已經在國外快速的蓬勃發展，各種Web Service也已經在Internet上供人使用，例如搜尋MP3的服務，或是查詢全世界各地氣象的服務等。相信Web Service和SOAP也將很快的在國內發展起來，也終將成為軟體開發人員必備的軟體技能之一。
Web Service本身包含了許多的意義，觀念和技術，在RUN!PC 2001年5月份的『解析Web Service的技術內容與意涵』一文中已經對於Web Service和SOAP有基本的介紹，讀者可以參考該文的說明。
本篇文章的內容在於討論Web Service的技術架構和實作的技巧，並且首先以Delphi 6做為說明如何實際的開發Web Service以及用戶端應用程式來呼叫Web Service。接著再說明如何使用Delphi開發的用戶端應用程式來呼叫Internet上由Java開發的Web Service，來向各位讀者展示Web Service和SOAP的開放性以及標準性。當我們成功的在本地機器呼叫了在世界上某一個角落，由某一個人使用某一種工具開發的Web Service時，相信讀者也會讚嘆Web Service和SOAP所帶來的無限可能和下一波的軟體技術的革命。

Web Service和SOAP的架構
那麼我們要如何才能夠知道每一個Web Service提供的服務？要如何才能夠呼叫到Web Service？又要到那裡找到適合的Web Service呢？簡單的說，Web Service提供的服務是以所謂的WSDL(Web Service Description Language)標準來敘述的，只要我們能夠取得特定Web Service的WSDL，就可以從其中瞭解它提供的服務，以及如何呼叫這個Web Service。
最後一個問題是如何找到適用的Web Service，在目前全世界已經有人公佈了許多的Web Service供人呼叫使用。此外IBM和Microsoft等公司也正在研擬所謂的UDDI標準以提供註冊，搜尋，交換和使用Web Service的標準，開發人員可以藉由UDDI找到需要的Web Service，當然我相信許多的Web Service將會由開發人員根據自己的需求而使用工具開發出來。
說了那麼多，可能讀者會想要知道到底Web Service要如何實作？要使用什麼語言或是工具才能夠撰寫的呢？事實上Web Service並不限定任何特定的工具或是語言才能夠開發，簡單的說你可以使用任何的工具或是語言來開發，甚至可以使用ASP/JSP等稿本語言(Script Language)來實作。當然，開發人員也可以結合各種不同的軟體技術和元件架構來開發。
下圖是以比較實體架構的觀點來敘述Web Service的觀念。圖中的用戶端藉由SOAP和HTTP通訊協定，透過Web Service Provider找到適合的Web Service，再呼叫它。而實體的Web Service可以是實作在Window平台的MTS/COM+或是.NET物件，也可以是實作在Linux/UNIX平台中的CORBA或是EJB物件。這個觀點是以各種元件模型來實作Web Service。



圖一 Web Service的架構示意圖

至於下圖則是以更細微的觀點來看Web Service的實體架構。在這個圖形中呈現了Web Service可以由ASP/JSP或是CGI，ISAPI的形式來實作，以服務用戶端的請求。開發人員可以把所有的Web Service企業邏輯實作在ASP/JSP/CGI/ISAPI/DSO之中。或是只把回應用戶端請求的邏輯實作在ASP/JSP/CGI/ISAPI/DSO之中，而把真正的企業邏輯實作在後端的元件模型之中，或是後端的應用程式之中，例如Delphi的DataSnap伺服器。



圖二 Web Service的實作架構圖

從上面的討論中可以知道，開發人員可以使用任何的技術實作Web Service，只需要根據標準輸出Web Service，就可以由用戶端呼叫使用之。
討論完了觀念之後，現在讓我們回到實際的實作層次中。雖然Web Service可以由任何的技術實作，但是開發人員仍然需要選擇一種方式來開發。開發Web Service除了實作Web Service的企業邏輯之外，也必須提供Web Service的WSDL，並且分發Web Service。由於目前使用Web Service的情形仍然以SOAP/HTTP型式呼叫，因此許多的Web Service也是以Web應用程式的型態實作，例如把Web Service實作成CGI或是ISAPI/DSO的型式，不過只要能夠處理HTTP的呼叫，Web Service也可以實作成一般的獨立應用程式，這一點是讀者必須瞭解的。
開發Web Service雖然不是非常的困難，但是它仍然需要許多的開發步驟和處理程序，這也仍然需要花費一些開發成本。在Borland最新推出的Delphi 6中，Borland特別提供了7個直接的Web Service元件，三個Web Service精靈以及其他數個相關的VCL元件來幫助開發人員快速的開發Web Service，更棒的是，開發人員也可以再結合Delphi原有的MTS/COM+/CORBA/EJB元件模型開發更具延展性的Web Service。下圖便是Delphi 6中直接和Web Service相關的Web Service元件組。



圖三　Delphi 6提供的WebServices元件

這7個Web Service元件可以讓開發人員呼叫遠端Web Service，自動產生Web Service的WSDL，以及進行SOAP/HTTP和Object Pascal語言之間的繫結(Binding)，以便讓Delphi的程式師能夠使用Object Pascal直接處理SOAP之中的訊息。
下圖則顯示了在用戶端應用程式和遠端Web Service之間如何藉由這些元件溝通，以及每一個元件之間的關係。由於Delphi 6是Window平台上的開發工具，因此它使用了Wininet.dll來傳送HTTP封包資訊。



圖四 Delphi 6 WebServices元件的功能示意圖

從上圖可以知道，Delphi 6用戶端應用程式藉由THTTPRIO呼叫遠端Web Service，而TOPToSoapDomConvert可以把Object Pascal的呼叫和參數自動轉換為SOAP封裝的格式資訊，再藉由THTTPReqResp傳送HTTP封包。而在伺服端THTTPSoapDispatcher則負責處理用戶端傳送來的SOAP/HTTP資訊，並且透過THTTPSoapPascalInvoker元件來自動啟動能夠處理這個SOAP/HTTP請求的Object Pascal程式碼。至於TWSDLHTMLPublish則能夠自動的根據Delphi實作的Web Service來產生WSDL並且輸出此WSDL讓用戶端應用程式能夠使用這個WSDL來呼叫Web Service。
說明了Delphi 6中有關Web Service的元件和其功能之後，現在就讓我們看看在Delphi 6中開發Web Service的步驟。下圖便是在Delphi 6中開發Web Service簡易的步驟：



圖五 使用Delphi 6開發 Web Service的步驟

首先程式師必須撰寫Web Service的核心邏輯，然後定義此Web Service的WSDL，以便讓用戶端能夠遵循標準呼叫。在實作完Web Service之後，接著程式師就可以使用Delphi 6提供的WebServices元件組來實作用戶端應用程式，並且藉由WSDL來呼叫Web Service。
在實作Web Service用戶端應用程式時，Delphi 6提供了非常彈性的方法，允許程式師使用Early Binding或是Late Binding，不像某些解決方案只允許使用Late Binding。這種設計可以讓程式師在開發Web Service解決方案時可以根據執行效率或是執行彈性來決定使用Early Binding或是Late Binding。
為了讓讀者能夠真正的瞭解如何開發Web Service系統並且範例Delphi 6在SOAP和Web Service方面的強勁功能，就讓我們使用一個實際的範例來說明如何使用Delphi 6快速開發Web Service和用戶端應用程式，並且結合資料庫來提供用戶端資訊。這個範例Web Service是把MYESSAYS資料表中的所有我寫的文章輸出給用戶端以便查詢資訊，而且不管用戶端是瀏覽器，一般的Window應用程式，或是Linux下的應用程式都可以。下圖便是儲存這些文章資訊的畫面：



圖六 範例資料表

至於這個範例的整體架構如下圖所示。文章資訊是儲存在InterBase之中，並且藉由Delphi 6的dbExpress來技術存取。至於實作Web Service的主體則是一個由Delphi 6撰寫的簡單Web應用程式。最後我們實作一個原生視窗應用程式藉由SOAP來呼叫此Web應用程式實作的Web Service。



圖七 實作Web Service的架構圖


步驟1 – 開發SOAP伺服端應用程式
首先程式師可以在Delphi中使用SOAP Server Application精靈來開發Web Service伺服器。在Delphi 6中我們只需要點選File|New|Others功能表，然後點選WebServices頁次即可看到下圖的畫面，然後再點選SOAP Server Application圖像。



圖八 Delphi 6的SOAP Server Application精靈

在點選了SOAP Server Application圖像之後，Delphi會詢問程式師要以那一種的實體型態來實作Web Service，如下圖所示。程式師可以選擇欲實作的程式型態，例如在這個範例中我選擇以Web App Debugger executable來實作，因為這個程式型態可以讓我們在開發Web Service時能夠輕易的除錯。當然，程式師也可以選擇以一般的Window應用程式來實作Web Service，而不使用SOAP Server Application精靈提供的下列實體型態的程式。



圖九 以Delphi 6的Web App Debugger應用程式的形式開發Web Service

在點選了圖九的程式型態和Ok按鈕之後，Delphi便會自動幫助程式師產生如下的Web模組。



圖十 Delphi 6建立建立的Web Module以及WebServices元件

在圖十的Web模組之中，Delphi自動產生的THTTPSoapDispatcher元件可以讓Web Server自動呼叫此應用程式，而TWSDLHTMLPublish元件則可以自動產生敘述此Web Service的WSDL內容。



圖十一 範例Web Service的主表單

現在再讓我們在這個Web Service程式的主表單中加入一個TLabel並且設定它的Caption特性值為『我的第一個Web Service』，如上圖所示。

步驟 2 – 定義Web Service的服務介面並且實作它
接下來的步驟便是真正的實作此Web Service。首先在Delphi 6中建立資料模組，並且使用dbExpress連結到InterBase：



圖十二 範例Web Service的資料模組，它使用dbExpress元件存取InterBase

點選File|New|Unit功能表定義如下的IMyEssays介面，這個介面定義了此Web Service提供的服務，用戶端應用程式可以呼叫GetEssayTitles函式取得所有文章的資訊，而這些資訊是儲存在TEssaysInfos的陣列中，這個方法展示了Delphi 6的Web Service可以處理複雜的資料型態。至於GetEssayContent則可以根據用戶端傳遞來的文章ID而回傳此文章的內容給用戶端應用程式。


unit uMyEssaysInf;
interface
uses
Types, XSBuiltIns, uEssaysInfo;
type
IMyEssays = interface(IInvokable)
['{1C8ABA87-455B-4430-9881-239F5FFE7F49}']
function GetEssayTitles : TEssaysInfos ;
stdcall;
function GetEssayContent(const iID : Integer) : String;
stdcall;
end;
implementation
uses
InvokeRegistry;
initialization
InvRegistry.RegisterInterface(TypeInfo(IMyEssays));
end.


接著我們定義儲存文章資訊的資料結構。為了讓文章資訊能夠自動傳遞回用戶端，我們可以在Delphi 6中從TRemotable類別繼承子類別，如此一來Delphi 6便會自動幫助我們處理資料Marshalling的問題。最後必須呼叫Delphi 6提供的RemClassRegistry物件來註冊這些類別。


unit uEssaysInfo;
interface
uses
InvokeRegistry, XSBuiltIns;
type
TEssaysInfo = class(TRemotable)
private
FEssayID : Integer;
FEssayTitle : WideString;
published
property EssayTitle : WideString read FEssayTitle write FEssayTitle;
property EssayID : Integer read FEssayID write FEssayID;
end;

TEssaysInfos = array of TEssaysInfo;
implementation
initialization
RemClassRegistry.RegisterXSClass(TEssaysInfo, 'http://www.w3.org/2001/XMLSchema', 'TEssaysInfo', '',False );
RemTypeRegistry.RegisterXSInfo(TypeInfo(TEssaysInfos), 'http://www.w3.org/2001/XMLSchema', 'TEssaysInfos');
finalization
RemClassRegistry.UnRegisterXSClass(TEssaysInfo);
RemTypeRegistry.UnRegisterXSInfo(TypeInfo(TEssaysInfos));
end.


現在到了實作ImyEssays介面的時候了，我們定義TMyEssays類別從TInvokableClass繼承下來並且實作IMyEssays介面。TInvokableClass類別可以讓用戶端從遠端呼叫。最後同樣呼叫InvRegistry物件註冊TmyEssays類別，以便讓THTTPSoapDispatcher元件可以啟動。至於IMyEssays介面之中的GetEssayTitles方法則是使用dbExpress從InterBase中讀取所有的資料，並且把文章的ID和名稱儲存在一個TEssaysInfo物件中，再把TEssaysInfo物件儲存在TEssaysInfos陣列中，最後回傳此陣列給用戶端。


unit uMyEssaysImpl;
interface
uses
SysUtils, Classes, InvokeRegistry, XSBuiltIns, uMyEssaysInf, uEssaysInfo, DB, HTTPProd, udmMyEssays, DBXpress;
type
TMyEssays = class(TInvokableClass, IMyEssays)
private
procedure CreateDataModule;
procedure FreeDataModule;
public
{ IISAPITutorials }
function GetEssayTitles: TEssaysInfos;
stdcall;
function GetEssayContent(const iID : Integer) : String;
stdcall;
end;
implementation
{ TISAPITutorials }
procedure TMyEssays.CreateDataModule;
begin
dmMyEssays := TdmMyEssays.Create(nil);
end;

procedure TMyEssays.FreeDataModule;
begin
if (Assigned(dmMyEssays)) then
begin
dmMyEssays.Free;
dmMyEssays := nil;
end;
end;

function TMyEssays.GetEssayContent(const iID: Integer): String;
begin
Result := '尚未實作, 請待續!!!';
end;

function TMyEssays.GetEssayTitles: TEssaysInfos;
var
iNo : Integer;
iID : Integer;
eInfo : TEssaysInfo;
TD: TTransactionDesc;
begin
CreateDataModule;
TD.TransactionID := 1;
TD.IsolationLevel := xilREADCOMMITTED;
try
dmMyEssays.sconnMyEssays.StartTransaction(TD);
iNo := dmMyEssays.sdsMyEssays.RecordCount;
SetLength(Result, iNo);
iID := -1;
with dmMyEssays.sdsMyEssays do
begin
while not Eof do
begin
Inc(iID);
eInfo := TEssaysInfo.Create;
eInfo.EssayID := FieldByName('EID').Value;
eInfo.EssayTitle := FieldByName('ETITLE').Value;
Result[iID] := eInfo;
Next;
end;
end;
finally
dmMyEssays.sconnMyEssays.Commit(TD);
FreeDataModule;
end;
end;
initialization
InvRegistry.RegisterInvokableClass(TMyEssays);
end.


現在這個能夠處理複雜資料的Web Service便藉由Delphi 6提供的WebServices元件和精靈完成了，接下來就是開發用戶端應用程式來呼叫此Web Service以取得文章資訊了。

步驟 3 – 開發用戶端應用程式呼叫Web Service
使用Delphi 6開發呼叫Web Service的用戶端應用程式更簡單，因為Delphi 6提供的WebServices元件組中的THTTPRIO元件實在是太方便了，我們只要使用物件檢視器設定THTTPRIO元件的WSDLLocation特性值為欲呼叫的Web Service的WSDL，那麼THTTPRIO元件便可以自動的處理所有呼叫Web Service的細節。
例如下面便是使用Delphi 6開發的用戶端應用程式，在這個應用程式的主表單上使用了一個THTTPRIO元件，並且在它的WSDLLocation特性值中輸入剛才開發的Web Service的WSDL檔案的位址。



圖十三 範例用戶端應用程式的主表單

接著在『 我的文章』按鈕的OnClick事件處理函式中撰寫如下的程式碼：


procedure TForm2.BitBtn1Click(Sender: TObject);
var
oriCursor : TCursor;
eInfos : TEssaysInfos;
iCount : Integer;
lStart, lEnd : Longint;
begin
ShowCaption;
StatusBar1.Panels[0].Text := '呼叫Web Service中...';
StatusBar1.Refresh;
lvMyEssays.Items.begin
Update;
lvMyEssays.Items.Clear;
oriCursor := Screen.Cursor;
Screen.Cursor := crHourglass;
lStart := GetTickCount;
try
eInfos := (HTTPRIO1 as IMyEssays).GetEssayTitles;
for iCount := low(eInfos) to High(eInfos) do
begin
with lvMyEssays.Items.Add do
begin
Caption := eInfos[iCount].EssayTitle;
Data := Pointer(eInfos[iCount].EssayID);
end;
end;
finally
lEnd := GetTickCount;
ShowRunTime(lStart, lEnd);
lvMyEssays.Items.EndUpdate;
StatusBar1.Panels[0].Text := '完成呼叫Web Service';
StatusBar1.Refresh;
Screen.Cursor := oriCursor;
end;
end;

procedure TForm2.ShowCaption;
begin
lblCaption.Caption := '太棒了, 我的第一個Web Service程式';
end;

procedure TForm2.ShowRunTime(const lStart, lEnd: Integer);
begin
StatusBar1.Panels[1].Text := FloattoStr((lEnd - lStart) / 1000.0) + '秒';
end;


上面的程式碼藉由THTTPRIO元件呼叫IMyEssays介面的GetEssayTitles方法，取得TEssaysInfos陣列，再從陣列中一一的取出每一篇文章的名稱，最後再填入到主表單中的TListView元件之中。下圖就是執行此用戶端應用程式呼叫Web Service伺服器，並且取得所有文章資訊的畫面。從這麼簡單的數個步驟中，我們已經使用Delphi 6開發了一個真正的Web Service應用系統。



圖十四 範例用戶端應用程式呼叫Web Service得到資料的畫面

雖然這是我們使用Delphi 6建立的第一個Web Service，但是這個範例Web Service展示了Delphi 6的SOAP/Web Service解決方案能夠輕易的傳遞複雜的資料型態，因為在範例Web Service中是使用陣列的型態來傳遞所有的文章資訊。Delphi 6的SOAP/Web Service技術絕不是像一些工具只提供簡單的SOAP/Web Service解決方案，而是充分的提供了一般和複雜的應用程式，並且能夠整合各種元件模型，是目前最具威力，也是最先進的SOAP/Web Service開發工具之一。
Delphi 6除了提供強勁的Web Service開發功能之外，新的Web App Debugger不但可以幫助程式師除錯Web應用程式之外，也可以幫助程式師監督用戶端應用程式和Web Service之中傳遞的資訊。這些資訊包含了SOAP的封包，以及Web Service伺服器回傳回用戶端的所有SOAP封包。這對於程式師學習SOAP和解析SOAP Payload都非常有幫助。例如下圖便是我使用Web App Debugger檢視此範例Web Service應用系統傳遞的SOAP Payload。



圖十五 Delphi 6的Web App Debugger可以顯示用戶端和伺服端之間所有的訊息

為了證明Web Service的威力和相通性，目前全世界已經有許多人成立了各種Web Service的網站，讓開發人員能夠測試Web Service。例如現在WWW.XMethods.COM便是提供各種Web Service的網站之一。這個網站羅列了許多的Web Service，下圖便是這個網站目前提供的Web Service。



圖十六 Internet上的XMethods(www.xmethods.com)提供了許多的Web Service供人呼叫使用

現在讓我們使用Delphi 6開發一個用戶端應用程式來透過Internet/Intranet呼叫遠端由Java實作，執行在Apache上的一個查詢美國各州氣溫的Web Service。下圖是這個Web Service的詳細資訊，這個Web Service的作者甚至提供了Java用戶端應用程式展示如何呼叫這個氣溫Web Service，不過現在我想使用Delphi的用戶端應用程式來呼叫，而不是Java。



圖十七 XMethods上的眾多Web Service之一，Temperature Web Service

下圖便是在我的機器中使用Delphi 6開發的用戶端應用程式，藉由Delphi 6的WebServices元件組來呼叫這個位於遠端，我也不知道在什麼地方的氣溫Web Service的結果畫面。
從下圖中可以證明，雖然我並不知道這個Web Service在那裡，我仍然可以藉由Web Service的標準介面敘述WSDL來使用它，即使它是使用Java實作的，並且執行在Apache之上。



圖十八 Delphi實作的用戶端應用程式呼叫執行在遠端Apache上的Web Service

希望上面的內容可以讓各位讀者瞭解Web Service和SOAP在應用上的潛力以及Delphi 6提供的元件技術可以讓開發人員快速而且輕易的實作出各種威力強大的Web Service。
也許藉由Web Service和SOAP的出現，也會對於目前應用系統架構產生巨大的影響。例如現在『供應鏈』軟體非常的流行，但是許多的供應鏈軟體在整合上，中，下游廠商時，經常會需要所有的廠商使用相同的平台以及基層軟體。但是對於下游廠商而言，可能無法像上游廠商一樣使用昂貴的設備，例如UNIX BOX和大型ERP軟體，許多的下游小廠也許只能使用Window NT或是Linux平台。不過現在Web Service和SOAP可以提供非常完善的解決方案，就如同下圖顯示的一樣，下游廠商可以只使用ASP提供簡單的Web Service讓他的中游廠商呼叫。而上游廠商則可以在UNIX Box中藉由大型的ERP軟體呼叫中游廠商執行在Window 2000中的BizTalk Service。如此一來不但每一個廠商都可以選擇最適合的執行平台和軟體，也可以藉由Web Service和SOAP整合上，中，下游廠商而提供一個及時且完備的供應鏈。Web Service和SOAP正為軟體帶來無限的發展契機。



圖十九 Web Service的應用架構之一

雖然SOAP和Web Service目前已經成為標準並且也已經被世界廠商所接受和支援。但是SOAP和Web Service仍然是在成長期，功能規格仍然在繼續的改善和強化之中，因此SOAP和Web Service的變化也在預期之中。Delphi 6實作的SOAP和Web Service似乎是比較偏向IBM和Java的陣營，因此Delphi 6能夠很容易的和Java以及PHP，Perl等SOAP/Web Service解決方案整合。至於Microsoft的SOAP和Web Service則稍有不同，需要程式師特別注意一下。
如果下次有時間的話，那麼就讓我們繼續討論Microsoft的SOAP Toolkit以及.NET之中的SOAP解決方案，並且比較Delphi和它們之間的差異以及如何整合這些不同的SOAP實作技術。

相关帖子:
李维：軟體服務時代的來臨
看看什么是软件服务时代！大家快来看看！
李维:.net vs delphi 6
delphi6 爆发还是灭亡？
李维:我的回忆和一些有趣的事
看IT风云变幻,宝兰与微软背后的故事,
李维:2001 年軟體界的巨星 - Kylix
看宝兰, 一年之间连续推出kylix1.0 ,interbase6.0, delphi6,jbuilder5 ,c++builder6也不日即出,敬请关注宝兰2001年与微软对绝的杀手锏kylix
李维:Windows 原生開發工具的瑰寶 – Delphi 6

老大，现在换一下行啊！

是啊，偶都看过的，（没换行的版本是第一次看哦），帮你顶一下

不错

我以前没有看过，不错，继续。呵呵

老大，换一下行！

换行。小伙子。我看都不看

我愿意提供这样的服务，但前面的已经改不了了。谁还收集有关于DEPHI6的重要资料，不放
拿来分享一下。。。

哪位老大做过COM服务器。请指教！！！！！！！！！！分数好商量！！！！！
我想做多层结构的数据库系统。。。。。。

我不知道怎么写COM服务器，我能不能写出来像在BCB里封装的控件那样呀！！！
有没有例子可以让小弟看看！！！
分数可以商量！·！！！

后面在叫换一下行的菜鸟们，如果连这点换车行的问题都解决不了，那你也太菜了，离
程序员的距离太远太远太远了。话虽这么说，我还是将“绝色神偷”的帖子重新帖一下。
这其实对这里的许多人而言简直是不费吹灰之力的，重新贴一下实在是照顾那些菜鸟们。

引子:在《.NET的衝擊》中争论的不可开交，纷纷要求李老师出面
嗯, 我又被點名了. 本來我已經在整理一篇文章, 有關Delphi/Delphi.NET和Microsoft.NET
的內容, 但是我一直沒有時間完成(我已經在論壇上說了好幾次了). 有些事情我並不方便說,
這些事情應該由Borland的人來說, 例如Tomm兄(转贴者注:台湾宝兰产品经理), 他有關
Borland的資訊應該是比較正確的, 因為我是Delphi 6的Beta Tester, 也是Microsoft .NET
的Beta Tester.
我可以簡單的說一下我的看法, 不過這些看法是我個人的意見, 各位可以參考一下.
1. Delphi 6仍然將是Window下最好的原生開發工具, 至少在2,3年之內如果我要寫傳統的 原
生App, Delphi 6是首選. 只是希望Borland不要急著推出Delphi 6.
2. .NET仍將逐漸成為Window下主流的開發環境, Window下的工具廠商都需要支援. 不過這可
能需要最少1到2年的時間.NET才會成為主流.
3. 在.NET開始的版本中, COM+仍然是核心技術. 雖然.NET有了新的元件模型, 類似VCL, 只是
可以使用在所有支援.NET的語言中. 但是有關Pooling, Transaction等仍然是靠COM+完成的.
所以COM+仍然非常重要.

4. 在Beta 1中.NET的data-aware做得仍不如Delphi, 但是Beta 2有了改善.
5. 我喜歡C#, 但是我也喜歡Object Pascal. 兩個語言各有優缺點. Borland可以在Delphi.NET
中繼續改善Object Pascal. 那麼我可能仍然會用Object Pascal.
事實上我認為.NET的Framework雖然完整, 但是.NET的Framework在我來看仍然和VCL的
Component Framework有一點差距. .NET的Framework和Java的class比較接近, 大都需要程
式師寫一堆的程式碼. Borland的專長就是設計Framework, 例如OWL, VCL都比Mirosoft設計
的好. 因此Borland可以在.NET的Framework上再架構一個比較偏向VCL這種Component
Framework, 那麼我們Borlnders就可以在Delphi.NET中享受比使用Microsoft.NET的人更高的
生產力. Borland不需要再寫另外一個Framework和.NET Framework競爭, 相反的要好好的利
用.NET Framework來建立更棒的.NET VCL. 如此一來即可以避免以往Microsoft利用OS優勢來
打擊Borland, 例如MFC對OWL, 又可以建立一個功能完整, 方便好用的Framework來回擊
Microsoft.
.NET的確對Borland是一個嚴厲的考驗, 不過我不擔心Borland無法應付. 只要Borland投入
足夠的資源, 就像投入JBuilder一樣. 我只是擔心Borland讓一個Team開發Delphi, C++
Builder, Kylix, Kylix For C++. 那麼就不妙了, 這也是我最不能接受的. Delphi明明還為
Borland賺不少錢, 卻不投入相對的資源, 有點不公平. 嗯說太多了, 應該閉口讓Tomm來發表
一下.
李維

聲明
以下的這篇文章內容是我個人的回憶以及看法，沒有任何特別的偏見，許多的事情是根據我的記
憶以及從許多人的訴說中得知的，也許內容不是百分之百的正確，不過我想這些內容有一定的可
信度到是可以保證的。當然有一些事情確定的發生時間和順序不一定都和我的記憶一致，不過我
想大部份應該是相去不遠的。當然各位如果知道確定的事件而我的記憶有誤，那麼我將非常歡迎
您糾正我，我希望這些故事的經歷能夠一直陪我走下去，謝謝。
一直想寫一篇我個人在過去10多年來工作中經歷的一些事情，以及看著一些我認為是偉大的工
程師在這些日子中對於資訊界的貢獻。如果你和我的年齡差不多，那麼你可能會對於這些內容很
有興趣，因為它們說明了當時許多軟體的興起和沒落的過程以及原因。雖然這些事情已經距離我
們很遙遠了，但是我相信許多人仍然對於背後的故事有興趣。如果你沒有經歷過那段美好的回憶，
那麼就把這些內容當成是一個有趣的故事來看吧。但是我想更重要的是讓我們一起認識一些偉大
的人物，我對於其中的許多人都非常的佩服，也非常的羨慕。我常常在想，如果我也有他們的環
境，我是不是也能夠和他們一樣這麼有成就呢?這些人對於以往都有重要的貢獻，在未來也將仍
然有重要的影響，因為他們都有一身不凡的技術。對於許多重要的人我都儘量的收集了他們的照
片，讓各位也能夠看看這些優秀的工程師和傑出的人物。當然，如果各位也能夠從這些內容中學
習到失敗的原因以及成功的經驗，那麼這篇文章就更有價值了。

和Borland的緣由

記得我在大學時第一個在PC上使用的軟體便是SideKick，至今我仍然無法忘記這個讓我津津樂
道的軟體，而Borland在當時也就是以SideKick成為全球知名的軟體公司。不過Borland第一
個奠立創業基業的軟體卻是我大二使用來交作業的Turbo Pascal。而Turbo Pascal也是第一個
我聽到關於Borland的有趣的故事
當年Philippe Kahn (Borland的創使人)和Anders Hejlsberg到美國創業時，便由Anders以組
合語言撰寫了Turbo Pascal的編譯器，而Philippe則包辦了Turbo Pascal其他的部份。在這
兩位人兄開發完Turbo Pascal之後，窮得快連登廣告的錢都沒有了。但是Philippe為了在Byte
雜誌(還記得這個著名的雜誌嗎?)刊登Turbo Pascal的廣告，因此和Anders商量了一個方法，
那就是一天他們約了Byte雜誌的人到當時Borland的辦公室討論刊登廣告的事情。
當Byte的人到了Borland之後，Philippe，Anders和公司的助理小姐故意忙著接電話，接受Turbo
Pascal的訂單，並且告訴Byte雜誌的人等一下。過了一陣子之後Philippe才進入房間向Byte
的人道歉，說他們的Turbo Pascal受到市場的熱烈歡迎，訂單源源不斷的到來，因此可能不需
要在Byte雜誌刊登廣告了，接著Philippe向Byte的人展示Turbo Pascal這個產品。由於在當
時的機器中Turbo Pascal能夠在少少的RAM中常駐執行，又提供閃電般的編譯速度，立刻讓Byte
雜誌的人震驚在當場，憑著專業知識和豐富的經驗，Byte的人也立刻知道這將是一個革命性的
軟體，因此馬上希望Philip能夠在Byte雜誌刊登Turbo Pascal的廣告，並且願意以半價刊登。
當然，Philip也立刻的答應了，於是一個革命性的軟體Turbo Pascal終於在Byte雜誌刊登出
來了，售價49.99美元的Turbo Pascal立刻為Borland帶來了大量的財富，Turbo Pascal也立
刻的成為PC上除了基本的Basic之外最暢銷的開發工具，也正式揭開了Borland影響PC開發工
具10幾年的序幕。
在Turbo Pascal之後，Borland接著推出了SideKick這套軟體，SideKick可以說是隨後著名的
記憶體常駐軟體(TSR)的始祖，也是讓Borland跨出開發工具界，讓幾乎所有PC使用者認識
Borland的關鍵軟體。當然SideKick也很快的成為了全球的暢銷軟體，繼續的把Borland往頂
尖的軟體公司上推。
而Turbo Pascal也成了我大二，大三撰寫作業的最愛，幾乎所有的作業都是使用Turbo Pascal
完成的，當然其時Horowise的Data Structure這門課也是使用Turbo Pascal過關的，因此從
那個時候開始我便非常喜歡Borland這家公司，慢慢的也開始對Borland有了特別的感情。
大二時Microsoft也推出了Microsoft Pascal，但是它和Turbo Pascal的確是有一段差距，我
使用了一次之後便把它丟到垃圾桶。稍後Borland也推出了Turbo Basic，我記得這個編譯器非
常的棒，編譯速度就和Turbo Pascal一樣，是一個非常有前途的產品。但是我不知道為什麼它
只有1.0，之後便和Microsoft Pascal一樣消失了。我聽說Microsoft和Borland互相交換條
件，Microsoft不進入Pascal的市場，而Borland則退出Basic的市場。至於是不是真的我就
不得而知了。
在大二初次的接觸到C語言，第一本閱讀的書便是王興隆先生寫的C語言，也從此開始和C語言
結下了淵源。平生第一個使用的C編譯器便是Lattice C，不知道還有沒有人記得。我還記得那
個時候使用2個5又1/4磁片抽換以便編譯C程式的情景。稍後Borland終於推出了風行天下的
Turbo C編譯器，當然，從此之後Turbo C便成了不離身的工具，而Borland也藉由Turbo C這
第三項暢銷產品邁向了世界前10名的項尖軟體公司。
當完2年的兵之後，我在中研院首次使用了C++語言，第一個使用的C++編譯器則是Zortech
C/C++，這家公司稍後被Symantec收購成為Symantec C/C++的核心，這個故事稍後再說。後來
Borland也推出了Turbo C/C++ 1.0這第一個C/C++編譯器，但是在我和Zortech C/C++比較之
後，還是覺得Zortech C/C++比較好，因此就繼續使用Zortech C/C++。一直到Borland的Turbo
C/C++ 2.0編譯器推出之後，才逐漸成為C/C++語言的王者，而我也像以往一樣把Zortech C/C++
換成了Turbo C/C++。
在1991年到Georgia Institute Of Technology唸碩士時，終於使用自己的零用錢美金49.99
購買了生平第一套的正版軟體Turbo C/C++ 4.5，隨後又購買了Borland Pascal。在畢業前的一
個Quarter，Microsoft 推出了Microsoft C/C++ 6.0以及MFC 1.0，由於是第一個C/C++的
Framework，因此也花了一些錢購買了一套以便瞭解MFC。但是在收到之後卻很失望，因為
Microsoft C/C++ 6.0仍然沒有圖形整合發展環境，還是在DOS下的整合發展環境，而且MFC 1.0
以我的眼光來看又不好用，而且Microsoft C/C++ 6.0的C/C++最佳化編譯器在其時是一個笑話，
不但產生的程式碼效率不好，甚至會產生錯誤的程式碼，許多雜誌也稱Microsoft C/C++ 6.0
是一個平庸的(Mediocre)產品。因此就把它丟在一邊。在Microsoft C/C++ 6.0不久之後，Borland
終於推了Borland C/C++ 3.0。而這套軟體也開啟了Borland雄霸C/C++編譯器常達5,6年之久
的序幕。
Borland C/C++ 3.0推出之後由於擁有第一個在Window下的穩定的圖形整合發展環境，而且它
產生的最佳化程式碼也是Microsoft C/C++ 6.0望塵莫及的，因此很快的幾乎所有的C/C++程式
師轉而使用Borland C/C++ 3.0。因此在那個時候有一個現象，那就是幾乎所有的公用程式或是
Shareware都是使用Borland C/C++開發的，許多硬體廠商的驅動程式也是使用Borland C/C++
3.0來撰寫的。
1992年我取得Georgia Institute Of Technology的碩士學位之後最想進入的公司便是Borland
和Microsoft，不過最後我還是決定回台灣工作。在此時Borland也進入了最巔峰的時期，因為
Borland推出了Borland C/C++ 3.1。
Borland在Borland C/C++ 3.0獲得空前的勝利之後，並沒有鬆懈下來，因為Borland知道Borland
C/C++ 3.0還缺了一個最重要的勝利因子，那就是如同Microsoft的MFC一樣的C/C++的
Framework，因為Borland也看出了Framework將會是未來C/C++產品中最重要的一環科技。不
過Borland此時面臨了一個重要的十字路口，那就是到底要自己開發一個和MFC抗衡的
Framework，還是要如何做。因為如果要自己開發Framework，那麼勢必要花上一些時間，但是
Borland想趁Borland C/C++ 3.0如虹的氣勢再下一城，以便徹底擊潰Microsoft C/C++。因此
最後Borland決定向一家叫White Water的公司購買一套由這家公司開發的一個Framework，這
套Framework便是後來鼎鼎大名的OWL的源流。而Borland也因為向White Water購買了這套
Framework，因而也引進了一個日後非常重要的人物，那就是後來負責開發Delphi的一員大將 -
Zack Urlocker。

C/C++的光榮戰役

在Borland購買下White Water的C++ Framework之後，便更命為OWL(Object Window Library)，
並且很快的推出了以OWL 1.0為核心的Borland C/C++ 3.1。由於OWL比當時的MFC 1.0封裝的
更為完整和好用，再加入Resource Workshop視覺化能力，以及Borland C/C++ 3.1自己最強勁
的編譯器和整合發展環境，因此立刻的風靡了全世界，其受歡迎的程度更是遠遠的超過了它的前
一版本Borland C/C++ 3.0。
由於Borland C/C++ 3.1的暢銷，立刻讓Borland在C/C++市場一舉擊潰了Microsoft C/C++，
市場佔有率超過了50%，是全球第一的C/C++產品，也把Borland推上了最高峰，成為全世界第
三大的軟體公司。
很快的，我所工作的開發小組也立刻的以Borland C/C++ 3.1來開發系統，Borland C/C++ 3.1
也是我使用過Borland最穩定的C/C++版本之一。也由於那個時候一天到晚都使用C/C++工作，
因此就有了一些小心得。稍後我整理了一些東西便投稿到剛出刊不久的RUN!PC，也許是運氣不
錯，RUN!PC很快的也登出了我的文章。就是這篇文章登出之後，台灣的Borland注意到了我，
開始和我連絡，並且從此展開了和Borland的互動。而Borland C/C++ 3.1也是第一套Borland
免費送我的軟體，當然代價就是希望我多寫一些Borland產品的文章。
接著Borland又計劃推出Windows版的Borland Pascal，不過在Borland開發Borland Pascal For
Windows 時，當時(現在也還是)最具盛名的Charles Petzold(我的第一本Windows 程式設計的
書就是這位仁兄寫的，相信許多人也是看他的書一路學來的)就說除了C/C++之外，Borland不可
能做出能夠在 Windows 下執行的Borland Pascal，不過很明顯的，即使是Windows API的大師
Charles也錯了。Borland不但做出來了，而且Borland Pascal For Windows 還非常的暢銷，
當然Borland Pascal For Windows 也是後來Delphi的根基。
當時的Borland可說是不可一世，不但產品大賣，而且日進斗金。Borland在Scotts Valley豪
華的總部也是在那個時候由Philippe Kahn大手筆的花了一億多美金搭建的(想想10年前的60
多億台幣可以蓋什麼樣的房子?)。不過也許是Borland太成功了，因此也開始讓Philippe Kahn
漸漸的養成了好大喜功，目中無人的態度，也種下了Borland開始走向衰退的因子。




Borland 位於美國加州 Scotts Valley 總部

不過在Borland最強盛的時期，當然也就是Microsoft最想痛宰Borland的時候，在這個時候發
生了一個著名的事件和一個著名的虛擬人物。話說由於當時Microsoft的開發工具一直打不過
Borland的產品，因此在Microsoft的開發工具刊物上便出現了一個作者不斷的以文章嘲笑
Borland，這個作者的筆名是Buck Forland。後來由於這位作者的文章內容以及他的筆名引起了
當時Borland的不滿以及大量Borland使用者的強烈抗議，因此稍後這位作者就突然的消失不見
了。因此有許多人就推測這個作者應該是Microsoft的工程師，由於一直無法打敗Borland的產
品，腦羞成怒，因此才會以這個筆名來發洩。如果各位看倌到現在還摸不著頭為什麼這個筆名會
引起軒然大波，那麼請你試著把Buck Foland這兩個英文字的第一個字母一對調就知道為什麼了。
現在各位是否會心一笑了?




Philippe Kahn-Borland的創始人

在Borland C/C++ 3.1大獲成功之後，Borland卻開始鬆懈了下去，並且開始走下坡。當然這有
許多的原因，我所知其中最重要的原因有數項 :
■Philippe Kahn和當時Borland C/C++的產品經理鬧翻了。這位Borland C/C++的產品經理的
名字是Eugene Wang，他是一位非常聰明的中國人。他一手把Borland C/C++ 帶到了世界第一的
地位，並且在Borland C/C++ 3.1成功之後有了更偉大的想法，那就是 Eugene Wang 想在下一
個Borland C/C++版本中完整的以OWL封裝所有的Windows API，因為OWL 1.0雖然比MFC 1.0
來得優秀，但是OWL的隱憂就是OWL尚未完整的封裝所有Windows的API。此外Eugene還計劃
以OWL為核心，開發一個類似今日Borland C/C++ Builder的以視覺化元件為開發方式的開發工
具。請各位想一想，如果在當時Borland能夠開發出這種C/C++開發工具，那麼將會是一個多麼
可怕的產品，稍後Microsoft的Visual C/C++ 1.0只是能夠在整合發展環境中自動產生MFC的
程式碼就立刻的轟動了C/C++市場，造成了大量程式師轉入Microsoft的陣營。即使是目前的
Borland C/C++ Builder使用的Framework仍然是以Object Pascal以核心的元件Framework，
而不是純粹的C/C++程式碼。如果當時 Eugene Wang 能夠做出他心中的下一版Borland C/C++，
那麼我想到現在Borland C/C++可能還是市場中第一的C/C++開發工具。不過很不幸的是，Eugene
Wang 稍後和Philippe Kahn發生了爭執，Eugene Wang 一氣之下離開了Borland。而Philippe
Kahn則認為Borland C/C++的地位已不可動搖，因此也沒有想立刻的做下一版的Borland C/C++。
這樣一拖竟然浪費將近2年的時間。
Microsoft Visual C/C++ 1.0在Borland C/C++ 3.1 2年之後推出，並且立刻獲得市場好評。
不但在編譯器方面能夠和Borland C/C++ 3.1相抗衡，在整合發展環境方面更大幅領先了Borland
C/C++ 3.1，還能夠自動產生MFC的程式碼，再也不是昔日的吳下阿蒙。直到此時Philippe Kahn
才從夢中驚醒而急於開發下一代的Borland C/C++ 4.0，但是為時已晚，C/C++的開發工具市場
從此就開始逐漸的被Microsoft蠶食了。
Eugene Wang在離開Borland之後，立刻的被Symantec所網羅，稍後Eugene Wang也在非常短
的時間之內為Symantec開發出了著名的Symantec C/C++。Symantec C/C++在當時被所有的技術
刊物評比為擁有最棒的整合發展環境和最有創意的C/C++開發工具，從此可見Eugene Wang的功
力。不過Symantec C/C++稍後也不敵Microsoft Visual C/C++，這個故事的原因在稍後四大C/C++
編譯器之爭的段落中再詳細的說明。
我最後聽說Eugene Wang跑去做生意了，並且在前幾年寫了一本教導科技人員如何面試的書籍。
我,一直很痛心Borland失去了這麼一位優秀的人材，我常想如果當初Eugene Wang沒有離開
Borland，那麼歷史就可能不是現在的這樣了，Sign!!!
■Philippe Kahn大手筆的花了一億多美金買下了Ashton-Tate公司和dBase。在當時許多人都
批評Philippe Kahn做了不值得的事情，因為Ashton-Tate不值這麼多錢。但是由於當時Borland
多的是錢，因此Philippe Kahn也不多意。不過這並不是Borland走向逐漸走向衰敗的主因，而
是在Borland買下了dBase之後，並沒有立刻積極的發展dBase For Windows，反而把dBase丟
在一旁。這個原因便是當時Borland的另外一個和資料庫有關的產品Paradox賣得也很好，因此
Philippe Kahn並不急著打算開發dBase For Windows。不過Philippe Kahn忘記了一件事情，
那就是當時在市場大量人口的dBase程式師需要一個好的Window版dBase，但是Philippe Kahn
購買了dBase卻不提供Windows 版的解決方案。因此當稍後Microsoft以極小的代價買下Fox
這家公司，並且在數年之後推出FoxPro For Window，吸引了大量原先的dBase程式師以及Paradox
的程式師之後，Philippe Kahn才警覺事情不對而充充忙忙的開發dBase For Windows。但是當
dBase For Windows 推出之後，Microsoft早已推出了兩個FoxPro For Windows 的版本，而佔
據了大部份的市場，dBase For Windows其勢已不可為了。
■Microsoft開始向Borland挖角。由於Microsoft在許多的開發工具戰役中一直被Borland打
得灰頭土臉。更何況Borland C/C++ 3.1幾乎搶佔了大部份的市場，因此Microsoft開始準備好
好的對付Borland。但是由於其時Borland在編譯器的技術領域領先了Microsoft數年之久，
Microsoft無法在短時間之內趕上Borland，因此Microsoft決定使用最有效的方法立刻追上
Borland技術，那就是直接挖角。因此稍後Microsoft的Visual C/C++小組有60%的成員是從
Borland挖來的，這個舉動不但立刻的讓Borland流失了大量的優秀技術人才，也在數年之後造
成了Borland控告Microsoft的導火線。不知道各位看到這裡有什麼感覺，或是沒有感覺。不過
我總是覺得Microsoft使用了不好的手段來競爭，並不是光明正大的擊敗Borland，而是使用了
不公平的競爭手段。
Philippe Kahn在這段時間不但讓Borland C/C++被Microsoft Visual C/C++反敗為勝，也痛失
了幾乎所有dBase的市場，更浪費了大量的金錢，和流失了大量的優秀人員。在這些重要的原因
之下，Borland已經不可避免的開始走下坡了。
我最後一次看到Philippe Kahn時是在1994年未於亞特蘭大(Atlanta)參加國際Conference時，
還和他打了一聲招呼。後來Philippe Kahn離開了Borland，另外創立了StarFish這家公司，
稍後StarFish也被Motorola併購。雖然Borland由於Philippe Kahn一些錯誤的決策而逐漸的
從巔峰開始下降，但是Philippe Kahn也不愧為一個人物。因為Philippe Kahn能夠和Bill Gates
一直周旋數年之久，而同一時期的許多公司，例如Lotus都一一的被Microsoft所擊敗，因此
Philippe Kahn還有一套的。此外Philippe Kahn也是唯一一個擁有工程師特性的Borland CEO，
Philippe Kahn仍然重視技術產品和技術人員。但是Borland隨後的CEO幾乎都是Marketing，
Finance或是Sales出身的人，這真讓我懷念以往以產品和技術為優先的CEO了。
看完了上面這段今人傷心的歷史之後，再讓我們看看當Borland在受到Microsoft Visual C/C++
的強大衝擊之後，如果思索反擊之道。在這段期間也出現了令我敬佩的第一個Borland技術工程
師，Carl Quinn。
Carl Quinn在Microsoft Visual C/C++ 1.0推出之後，立刻奉命開發一個能夠和MFC相抗衡的
全新OWL，而Carl Quinn也是數年後JBuilder的JBCL Framework的靈魂開發人物。Carl Quinn
不但負責開發OWL，也為Borland在元件Framework的技術領域立下了重要的貢獻。由於Carl
Quinn的投入，因此開啟了OWL大戰MFC，Borland C/C++纏鬥Visual C/C++數年精彩好戲的序
幕。

Carl Quinn到現在我還記得和敬佩的人物，讓我再一次的向他致敬，並且介紹他讓大家認識。





Carl Quinn-我第一個佩服的Borland工程師


Borland C/C++的反擊
火線全開
Borland除了在開發工具市場和Microsoft熱戰之外，其時和Microsoft ，Lotus鼎足而立的
Borland看到Microsoft和Lotus正在試算表工具以及文書處理工具大戰之暇，不思好好的集中
資源開發新的開發工具和資料庫工具(下一節會詳說)，也不甘寂莫的投入了大量的資源進入這個
慘烈的市場。也許是當是Borland太有錢了，或是Philippe Kahn腦袋有問題，居然決定進入這
個Borland陌生的市場，更何況在Borland投入時Lotus已現敗象，市場已經慢慢的被Microsoft
所一步一步的掌握了。
Borland進入Office市場的第一個產品便是著名的Quattro Pro這個試算表，雖然Quattro Pro
是一個不錯的產品，而且當時由Borland C/C++編譯器所開發的Quattro Pro在執行效率上幾乎
是最好的，但是Borland沒有想到使用試算表的使用者是一般的辦公室人員，這些人注重的是方
便性和功能性，而不是最重視執行速度，這和開發人員是不一樣的。Borland以開發者的心態來
開發試算表工具基本上是走錯了方向。因此我記得在那段時間中，雜誌評比Microsoft的Excel，
Lotus的1-2-3和Borland的Quattro Pro時，在功能方面領先的都是Excel和Lotus，在執行
效率方面領先的則是Excel和Quattro Pro。到了試算表熱戰的未期1-2-3甚至比不上Quattro
Pro，因此Lotus敗走試算表市場已是不可避免的結果了。
不過Borland雖然贏了1-2-3，但是和Excel仍然有一大段的距離，Microsoft一統試算表江山
之勢已不可搖，因此最後Borland在損失了大量的資源之後，Quattro Pro只能賣給Novell。除
了Quattro Pro之外，Borland也投入了很多的資源秘密的開發一個代號稱為Spring的文書處
理程式準備和Microsoft的Word以及WordPerfect競爭，這可能是許多人不知道的。但是這個
產品最後仍然無法問市而胎死腹中，在文書處理市場方面Borland不但浪費了時間，更虛擲了大
量的資源。Philippe Kahn在Office產品方面消耗了Borland大量的金錢和時間，卻落得鎩羽
而歸，更連累了開發工具市場以及最有可能成功的資料庫產品市場。
另外一個和Borland無關的故事是關於Excel如何興起的。話說當Lotus 1-2-3最盛的時期，
Microsoft一直計覬覦這個市場，但是苦於無法開發一個能夠和1-2-3相競爭的產品。有一次
Lotus 1-2-3舉辦了一個Lotus 1-2-3的技術研討會，由當時Lotus 1-2-3的首席工程師主講。
在Microsoft知道了這個技術研討會之後，立刻派出了最好的程式設計師，在現場詢問Lotus
是如何開發1-2-3的並且也趁機詢問這位首席工程師如何克服1-2-3在許多技術方面的難點，而
這些困難處正是 Microsoft 的工程師無法克服的。
當時在現場中Lotus的這位首席工程師雖然知道這些人是Microsoft派來的，而且詢問的問題正
是1-2-3許多關鍵的技術點。但是這位首席工程師憑藉著多年開發經驗，並且認為Microsoft
不可能在短期之內追上1-2-3，因此就沒有多做保留的回答了許多重要的問題。沒有想Microsoft
的這些程式師也是非常聰明的的人，在一經指點之後，立刻暢然全通，在短短的1,2個版本之後
不但馬上追上了1-2-3，在許多功能方面更是青出於藍，1-2-3便逐漸失去優勢了。我想這位1-2-3
的首席工程師一定很後悔當時回答了關鍵的技術問題吧。
結論 : 千萬不要小看Microsoft，他是非常精於模仿的，也永遠不要小看你的對手。

資料庫市場的失誤

當Borland全盛的時期，事實上也是發展資料庫產品最好的機會。因為在當時Borland手握DOS
最暢銷的Paradox，又併購了Ashton-Tate而擁有世界大部份dBase的市場，後來又從 Digital
取得了真正的 RDBMS-InterBase，可以說是全世界資料庫實力最雄厚的廠商。當時的 Oracle 和
Borland 比起來，簡直是小巫見大巫，而 Sybase 更不知道在那裡。如果當時 Borland 能夠好
好的掌握這個機會，並且極力發展資料庫產品的話，那麼現在Borland 就算不是世界第一的軟
體公司，也將是世界第二的軟體廠商。
可惜 Philippe Kahn 並沒有看到這個在年代80未到90年代成長最快速的產品。說句笑話的是，
如果當時Philippe Kahn的死對頭Bill Gates早一點對 Philippe Kahn 說出Information At
Your Finger-Tip』的話，那麼 Borland 就可能是現在的 Oracle 了。
說到資料庫市場就不得不對 Microsoft 的眼光佩服，也可以看到Microsoft行銷能力的強悍。
當Microsoft以FoxPro For Window強佔了開發者的資料庫市場之後，又看到了一般使用者也需
要使用簡易好用的資料庫管理工具。因此發展出了Access。但是當時在這種市場中，Paradox
佔有開發者的資料庫大部份的江山，而一般使用者的資料庫管理工具市場則由Lotus的Approach
拔得先機。Microsoft為了扳回劣勢，我還記得在當時Visual Basic 3的套裝軟體中Microsoft
附了一張優待卷，只要800新台幣就可以買一套Access。這簡直就是流血大拍賣，目標很明顯，
就是當時在市場中賣1萬多元的Lotus Approach。果然，Microsoft此招一出，Approach便在
市場被Access打得落花流水，很快的便失去了市場，也很快的退出了市場。從此一般使用者的
資料庫管理工具市場便逐漸由Access所取代。
但是Borland並沒有警覺到Access會繼續的往開發者市場進功，因此仍然沒有加緊在Paradox
產品上開發，Borland總覺得以Paradox在市場的地位是無法輕易憾動的，而且Access的目標
市場也不是Paradox的市場。但是Borland忘記了Microsoft非常散擅長模仿，因此在隨後的
Access版本中，Microsoft不斷的為Access加入可程式設計的功能，因此也逐漸的吸引了一些
Paradox入門使用者的市場，再加入FoxPro For Window又持續的強功開發者資料庫市場，Paradox
終於在背腹受敵之下也逐漸的敗下陣來。雖然在未期Philippe Kahn已經對Paradox投下重兵，
希望能夠挽回Paradox的劣勢，奈何時不我予，Paradox在奮鬥了Paradox 6和Paradox 7的2
個版本之後，終究難逃失敗的命運。
當時我看到Microsoft如何打擊競爭對手時，我就和朋友開玩笑的說。Microsoft有天下無敵的
3絕招，那就是『打不過你就模仿你(這讓我想起電影秘密客(Mimic) )，再打不過就和你比流血，
看誰流得久(這讓我想起吸血鬼)，最後如果再不行的話，那就挖光你的人(這讓我想起電影 Other
People's Money)』。Lotus就在Microsoft的前2個絕招下到地不起，而Borland還算是功力
深厚的了，連中了3絕招，雖然不像Lotus和許多其他公司一樣從此Bye-Bye，但也是受傷極重
的了。

ODBC和IDAPI之爭

當Microsoft在逐漸的擊敗他的競爭對手，並且擁有了大部份PC資料庫市場之後，便慢慢的瞭
解到掌握標準的重要性。此外Microsoft為了統一各應用程式之間不同資料的存取，因此開始製
定存取資料的統一標準-ODBC。
Microsoft更大的目的是為了準備和瞄準下一場的大戰，那就是PC上的RDBMS產品。
當然，Microsoft要一統資料存取的江山，Borland不同意，其時一心想從Microsoft扳回一城
的IBM也不同意，而Novell更是害怕，因為Novell怕Microsoft成功之後，Netware會消失得
更快。於是IBM，Novell和Borland以及一些其他的小廠便聚集在一起，決定也製定一套存取資
料的標準介面來和Microsoft對抗，這個製定的資料存取標準便是IDAPI。此時也正式揭開了ODBC
和IDAPI競爭的序幕。
不過IBM，Novell和Borland的結合很快的就證明是失敗的，因為就像稍後說明的一樣，IBM在
PC軟體上的發展一直是三心二意，反反覆覆，因此當IDAPI 1.0的規格出來之後，IBM這位老兄
又失去了和Microsoft對抗的興趣，於是就退出了IDAPI聯盟。至於Novell就更不用說了，Novell
對於和Microsoft一象是『說說可以，真打不行』，一定要找到一群廠商才敢和Microsoft對抗。
Novell在眼看IBM推出之後，也馬上不戰而降，很快的就也退出IDAPI聯盟，這個現象和稍後
Novell對於和Borland秘密合作的Appware/AppBuilder計劃如出一轍，都是虎頭蛇尾，草草收
場。
在兩個大ㄎㄚ臨陣脫逃之後，Philippe Kahn仍然不畏懼Microsoft的競爭，還是以IDAPI 1.0
的規格實作資料存取引擎，這就是我們現在使用的BDE/IDAPI和SQL Links的前身。當時IDAPI
1.0的功能規格比ODBC 1.0好得多了，我記得Delphi 1.0使用的BDE/IDAPI和SQL Links驅動
程式也比當時慢得像烏龜的ODBC快上太多了。只可惜在IBM和Novell推出之後，其他的小廠也
是一轟而散。因此Borland只能靠自己獨自和Microsoft對抗。Borland能夠以少量的資源一直
對抗到Delphi 3的BDE/IDAPI才逐漸的被ODBC追過，也算是非戰之罪了。怪也只能怪Borland
意志不堅的盟友。當然由於IBM和Novell的行事做風是如此，在稍後許多能夠和Microsoft一
較長短的機會也因為如此而消逝，最後自食惡果，逐漸失去了PC的軟體市場，再也無力和
Microsoft抗衡了。
現在呢Borland似乎記取了當時的錯誤, 正努力的在Linux上定義標準資料存取介面dbExpress,
我希望也祝福Borland能夠成功.
未完待續……

2001 年軟體界的巨星 - Kylix
什麼是Kylix?如果你還不知道的話，那麼你可能已經很久沒有注意軟體界的大事了。Kylix是
Borland公司以Windows中最受歡迎的RAD工具-Delphi為基礎，特別為Linux作業系統打造的
視覺化RAD工具，簡單的說Kylix就是Delphi For Linux。
為什麼Kylix這麼今人興奮呢?這是因為Linux雖然是一個現在非常流行的作業系統，但是在
Linux上要開發應用程式程式師大都使用GNU的GCC編譯器。雖然 gcc 是一個非常穩定編譯器，
但是Linux上的程式師必須一行一行的撰寫程式碼，同時必須對於Linux作業系統非常的瞭解。
如果還想開發X Window的應用程式，那麼程式師還必須學習X Window API或是Linux上最流行
的的兩個圖形使用者介面套件GNOME/KDE的API。由於這個門檻相當的高，因此只有少數的人能
夠在Linux上開發應用程式，開發的時程也非常的漫長，也造成了Linux上應用程式的數量一直
無法追上Window上的應用程式。但是Kylix的推出將會改變這個情形，因為Kylix就像是Window
平台的Delphi或是Visual Basic一樣，它提供了視覺化的整合發展環境，也提供了拖曳元件來
設計圖形使用者介面以及應用程式的能力。不但可以立刻讓熟悉Windows開發環境的程式師在
Linux上開發應用程式，也能夠讓現有的Linux立刻的增加數倍的生產力。
Kylix不但提供了高生產力，視覺化的整合發展環境，更結合了Delphi有名的閃電般的編譯器，
讓程式師在Kylix中開發Linux應用程式有如沐浴在春風中一樣，今人非常的舒服。雖然Kylix
現在只是第一版，但是它提供的整合發展環境卻比Window上的Delphi 5.0還先進，可以說Kylix
的開發環境大概是Delphi 5.5的水準。從這一點就可以看出Borland對於Kylix的重視。
Kylix 1.0提供了非常豐富的開發功能，能夠讓程式師開發各類的Linux應用程式。基本上Kylix
提供了超過了150個的元件讓程式師使用，而Kylix 1.0本身則是由4大核心功能打造而成，它
們分別是:
提供視覺化圖形使用者介面功能的CLX元件組
包含了按鈕，串列盒，Grid，圖形元件等先進的視覺化元件。CLX元件不但可以節省程式師大量
的開發時間，能夠同時開發執行在KDE/GNOME圖形套件中的Linux應用程式，更是一套跨平台的
Framework。由CLX開發出來的應用程式也能夠藉由Delphi 6編譯之後在Window平台執行，反
之亦可。當然Borland也延續了Delphi的VCL優良傳統，提供了幾乎所有視覺化CLX元件的原
始程式，允許程式師根據自己的需求來修改。
提供Socket和Internet/Intranet程式能力的NetCLX
這組元件允許程式師開發Linux上的Socket應用程式。讓程式師能夠結合CLX和NetCLX開發出
圖形使用者介面的通訊應用程式。此外Borland也把Delphi的WebBroker功能移植到Kylix之
中，讓Linux的程式師可以快速的開發執行在Apache中的Internet/Intranet應用系統。這對
於Linux上的程式師是一個非常棒的訊息，因為藉由Kylix，Linux上的程式師終於可以快速的
開發各種Web應用程式，如果再結合稍後介紹存取資料庫的DataCLX，那麼Linux程式師可以開
發出極為複雜，先進的Linux Web應用系統。同樣的，Borland也將在Delphi 6中支援Apache
的功能。
高速的資料存取引擎DBExpress
要如何在Linux平台中存取資料相信是許多Linux程式師的夢魘，因此大部份的Linux應用程式
都是以系統程式，公用程式或是其他周邊小程式為主。但是不否否認的，要讓Linux作業系統能
夠成為大眾接受的平台，那麼Linux就必須擁有能夠處理資料的應用系統。在Kylix沒有出現之
前，Linux的程式師只能使用JDBC/ODBC存取資料庫。但是Borland為了在Linux和Window平
台中建立新一代的跨平台資料存取引擎，特別集中的資源開發出了所謂的DBExpress資料存取引
擎。DBExpress資料存取引擎能夠提供最有效率的資料存取速度，讓Linux和Window平台的程
式師能夠使用一組相同的元件來存取各種關連資料庫。讓存取資料不再是Linux程式師的最痛，
在稍後的章節中將會詳細的介紹DBExpress。
視覺化存取資料的DataCLX元件組
一旦Linux應用程式藉由DBExpress取得了資料之後，DataCLX這組視覺化的元件能夠以各種先
進的圖形使用者介面控制元件來呈現資料。這些元件包含了按鈕，串列盒，下拉盒，甚至是複雜
的Grid元件。讓展示資料不再是Linux程式師最不願意做的事情。DataCLX元件組將會快速的
讓Linux的商業軟體出現在市場之中。
下圖便是Kylix 1.0的核心功能架構圖。


Kylix的4大核心功能

在下面的的內容中，將會進一步的詳細介紹Kylix提供的強大功能，讓各位能夠更瞭解Kylix
的極致性能以及它的致命吸引力。
最具生產力的整合發展環境
在Linux平台中開發應用程式最不方便的地方是什麼?那就是Linux程式師缺乏像Window平台下
高生產力的開發環境。雖然Linux提供了一些編輯器，如vi，或是一些圖形化的編輯器能夠讓
程式師敲打程式。但是這畢竟不方便，此外程式師在打完程式碼之後還得回到命令列下編譯程式，
在數個不同的環境中開發應用程式，相當的不方便。因此Kylix的第一個目標便是提供Linux
平台下的程式師一個擁有最高生產力的開發環境。在這個開發環境中程式師可以進行所有開發應
用系統的工作，從敲打程式碼，編譯程式，連結程式，到執行和除錯程式都能夠一氣喝成。此外
這個開發環境必須提供視覺化程式設計的功能，以及拖曳元件，設計表單的工作。簡單的說Kylix
要提供比類似Window平台下的Delphi開發環境。 雖然不簡單，但是Borland再次的突破了技
術瓶頸，在Linux作業系統下提供了比Window平台下Delphi 5更為先進的整合發展環境。下圖
便是Kylix的整合發展環境，從圖中各位可以看到，畫面上方便是有名的元件盤，允許程式師以
拖曳元件的方式設計視覺化的表單，左邊是物件檢視器可以讓程式師以動態的修改表單中的元
件。這整個整合發展環境是執行在KDE的圖形使用者介面套件之中。


終於展露神秘面紗的Kylix整合發展環境

此外Kylix的編輯器提供了強大的功能讓Linux程式師能夠快速的開發應用程式。這些強大的功
能包含了以不同顏色顯示語法的能力，Code Complete和Code Insight等。例如下圖便是Kylix
的編輯器，請注意當我在編輯器中輸入了一個物件變數StatusBar1之後，編輯器便會在一個視
窗中自動顯示這個元件所有可以呼叫的方法以及能夠存取的特性。此外這個視窗還能夠以不同的
顏色來區分function，procedure, constructor，destructor和property等，讓程式師能夠一
目瞭然，非常的方便。在這裡也偷偷的告訴各位，下圖中的Code Insight是Delphi 5的Code
Insight的改善版，Delphi 6也是使用這個Code Insight，而Kylix則搶先一步提供了這個更
先進的Code Insight。


Kylix的Code Insight功能

當然Kylix的整合發展環境也允許客製化開發環境，從編輯器的功能，字形的顏色，大小，到
Code Insight的反應速度，整合發展環境的提示功能等，程式師都可以客製化，以打造一個自
己喜歡的工作環境。例如下面的兩個圖形即顯示了我在Kylix整合發展環境中自訂我自己喜歡的
工作環境。


Kylix允許程式師完全的控制整合發展環境


Kylix允許程式師任意調整工作使用的編輯器

除此之外，除錯能力相信是許多程式師非常重視的開發功能，畢竟程式師有許多的時間是花在除
錯應用程式之上。Kylix提供了全方位的除錯能力，不但能夠讓程式師設定中斷點，也能夠檢查
任何的變數和物件的狀態。提供了程式師一個高效率的測試和除錯環境。例如下圖便是我在
Kylix整合發展環境中執行並且除錯應用程式。從下圖中也可以看出Kylix提供的豐富圖形使用
者介面功能，以及處理中文的能力。


程式師可以在Kylix整合發展環境中執行和除錯應用程式

當然由Kylix編譯出來的應用程式是原生的Linux應用程式，程式師可以立刻的在Linux圖形使
用者介面中執行。例如下圖便是我使用Kylix建立的一個範例應用程式，並且獨立的執行在KDE
環境之中。看到這一幕真是今人感動不已。藉由Kylix，Borland終於可以讓許多的程式師得以
美夢成真。那就是Linux的程式師終於可以在Linux作業系統中舒服，而且有效率的開發應用系
統了。


Kylix建立的Linux應用程式執行在KDE之中

CLX視覺化元件
在Linux 中最流行的的圖形使用者介面套件便屬KDE和GNOME了，許多的Linux程式師都渴望
能夠撰寫一些能夠執行在這兩個圖形套件之中的應用程式，但是這可不是一件容易的事情。Linux
的程式師必須先學習圖形套件的API，再撰寫數百行的程式碼，才能夠開發完成一個小小的圖形
應用程式，就像數年前使用Window API撰寫Window應用程式一樣。不過除非你對於撰寫圖形套
件API有特別的喜好，否則這種苦日子在Kylix出來之後就終於可以結束了。Kylix不但提供了
上百個視覺化元件讓程式師可以使用拖曳的方式立刻開發圖形套件的應用程式，而且許多這些視
覺化元件都提供了高等的功能和複雜的視覺化效果，讓Linux的程式師可以快速的便開發出可以
應用於複雜的情形的圖形使用者介面應用程式，再也不用花上數天，甚至是數個禮拜的時間。下
面的圖形就是Kylix提供的視覺化元件。舉凡一般的功能表，按鈕，串列盒元件，到圖形圖形，
LED元件，計時元件，再到複雜的Tab控制元件和影像串列盒等元件，Kylix都提供給了程式師。
比起Window平台上提供的視覺化功能實在是不遑多讓。有了這些元件之後，Linux程式師可以
立刻以數倍的效率開發KDE/GNOME圖形套件下的應用程式。




Kylix提供了上百個視覺化的元件讓程式師開發圖形使用者介面應用程式

除了視覺化元件之外，Borland也花費了許多的苦心讓Linux平台的Kylix和Window平台的
Delphi儘量提供一致的架構，以便讓程式師能夠在兩個不同的平台中都使用一樣的技術來開發
應用系統。下圖便是Kylix和Delphi的架構比較圖，從圖中我們可以看到Kylix和Delphi的整
合發展環境和應用程式在架構上幾乎是一樣的。除了編譯之後產生的機器碼平台不一樣，以及使
用的圖形使用者介面層不一樣之外，Kylix和Delphi幾乎擁有相同的架構，以及技術。在這裡
也先透露給各位，Delphi 6也將可以使用和Kylix一樣的CLX元件來開發圖形使用者應用程式，
讓不同平台的圖形使用者應用程式能夠立刻的移植到另外一個平台。


Window平台的Delphi和Linux平台的Kylix

WebBroker開發Internet/Intranet的功能
要如何在Linux平台中開發Internet/Intranet應用系統?相信許多人使用的方法是純手工打造，
直接使用Apache伺服器或是使用PHP開發Web應用程式。Kylix也允許Linux程式師使用純手
工打造的方式來開發Web應用系統，不過Kylix提供了更為先進的視覺化元件允許程式師使用視
覺化的方式來快速開發Web應用程式。此外這些Web應用程式完全可以使用Kylix的Object
Pascal或是稍後推出的C/C++語言，而不需要使用其他的語言。Kylix把Delphi的WebBroker
技術移植到Linux平台中，並且繼續的強化WebBroker技術，下圖便是Kylix提供的開發Web
應用方案的視覺化元件。


Kylix提供了視覺化元件開發Internet/Intranet應用程式

WebBroker技術允許程式師使用一種技術(即WebBroker)就可以開發CGI/Apache
DSO/ISAPI/NSAPI各種不同型態的Internet/Intranet應用程式。在Kylix中WebBroker允許程
式師建立CGI和Apache DSO型態的應用程式，例如下圖便是Kylix Web精靈提供的功能。


Kylix可以幫助程式師建立CGI或是Apache DSO型態的Internet/Intranet應用程式

Kylix的WebBroker技術不但可以讓程式師建立一般的Web應用程式，程式師更可以結合稍後介
紹的DBExpress元件來存取資料庫中的資料，再把資料和網頁內容結合以建立更為複雜的
Internet/Intranet應用系統。這種開發方式不但比Linux中其他語言來得快速，而且Kylix藉
由元件化的設計觀念因此可以讓程式師開發出更穩定的Internet/Intranet應用系統。下圖便是
使用Kylix的WebBroker技術開發出來的Internet/Intranet應用程式，從圖中我們可以看到
WebBroker果然可以開發出實際的Internet/Intranet應用程式。


由Kylix開發出來的Internet/Intranet應用程式

除了WebBroker技術之外，Borland更計劃在未來繼續為Kylix加入即將出現在Delphi 6的
SiteExpress技術，讓程式師能夠更進一步的開發功能強勁的Web應用系統，並且將藉由
SiteExpress逐步提供程式師一個開發Internet/Intranet應用系統First-Class的工作環境。
高效率的DBExpress元件
要如何在Linux中存取資料庫之中的資料並且能夠讓使用者處理這些資料呢?這相信是許多
Linux程式師最感痛苦的地方。由於Linux並沒有一個標準的資料存取引擎，因此Linux程式師
以往就只能夠使用ODBC API，或是使用Java藉由JDBC來存取資料。不過不管是使用ODBC或是
JDBC API，這都是非常辛苦，也非常沒有生產力的工作。Borland在開發Kylix時，為了提供程
式師一個Linux上高效率的資料存取方式，因此決定開發一套標準資料存取引擎，並且公佈這個
引擎的介面，讓所有有興趣的程式師都能夠藉由這個標準來存取各式不同的資料。此外這個引擎
也必須能夠跨平台，以便Linux和Window的程式師都能夠使用相同的技術來存取資料，這個開
發出來的引擎便是DBExpress
DBExpress引擎的觀念是提供一層非常簡單，有效率的資料存取介面和資料來源引擎。藉由這個
介面，程式師能夠存取各種不同的資料來源，卻只需要瞭解一個相同的介面即可，而在這個介面
之後則是實作存取各種實際資料來源的引擎。Kylix的DataCLX元件組便藉由封裝這個介面的
DBExpress元件組來存取並且展示各種資料來源。在Kylix 1.0版中，Borland提供了四個不同
資料來源的引擎，這些引擎是存取MySQL，InterBase，DB2以及Oracle資料庫的引擎。此外Kylix
也封裝了存取引擎介面的元件，藉由這些DBExpress元件，程式師可以使用視覺化的方式藉由特
定的的DBExpress引擎存取到各種資料來源。下圖便是這組DBExpress元件，藉由這些DBExpress
元件，程式師可以立刻的連結到MySQL，InterBase，DB2以及Oracle資料庫並且開始存取資料。


DBExpress元件組提供存取資料來源的能力

例如下圖便是啟動TSQLConnection元件，並且指定要連結到特定的InterBase資料庫，並且設
定使用者名稱，密碼等必要的連結資訊。程式師只需要使用點選的方式，便可以以視覺化的方式
存取資料來源，再也不用寫數百行的程式碼來做到相同的事情，大幅的提升生產力。


DBExpress的TSQLConnection元件允許程式師指定要連結的資料來源

DBExpress引擎為了提供最有效率的資料存取模式，因此使用了名稱Firehose的資料存取能力。
這種方式的資料存取方式提供只單向的cursor能力，並且不提供任何緩衝區的機制，這和
BDE/IDAPI提供大量緩衝區的機制非常的不一樣。由於Firehose只提供單向的cursor並且沒有
提供緩衝區能力，因此一次只能提供一筆資料，而且不能向後存取資料，因此這種模型是存取資
料速度最快的模型，沒有任何的負荷。不過一般的資料庫應用程式都必須來回的處理資料，那麼
Firehose如何滿足這種需求?答案是Firehose無法滿足這種需求，不過Delphi的MIDAS卻是一
個提供雙向cursor並且提供緩衝區能力的資料存取引擎。因此Kylix的DBExpress元件組便可
以結合Firehose和MIDAS，這樣不但可以提供Firehose最快速存取資料的好處，也能夠讓程式
師充分使用MIDAS提供的所有資料處理能力，因此可以讓程式師魚與熊掌兼而得之。事實上
Delphi 6也將使用相同的架構提供Window程式師存取資料的能力。下圖便是DBExpress結合
Firehose和MIDAS的功能示意圖。

DBExpress的核心是數個簡潔的介面(Interface)組成的，這些介面定義了如何跟特定的資料庫
廠商介面溝通的ISQLDriver，如何連結資料庫的ISQLConnection，如何對資料來源下達命令的
ISQLCommand，如何控制Cursor的ISQLCursor，以及存取資料庫MetaData的ISQLMetaData。這
些介面定義的目標就是簡易，有效率，它們和Java的JDBC有非常類似的觀念，但是Borland
又提供了MIDAS來巧妙的結合這些介面，因此提供了比JDBC高上數倍的生產力。
雖然DBExpress在Kylix中是第一個版本，但是DBExpress的執行速度卻已經和開發多年的
BDE/IDAPI有著幾乎一樣的表現，絲毫不遜色，甚至有一些項目還比BDE/IDAPI表現得更好。例
如下圖是DBExpress和BDE/IDAPI在連結InterBase的表現，從下面的資料中可以看出DBExpress
還略勝一籌。
開啟資料庫 BDE dbExpress
時間 1.832
1.467


此外我還寫了一些測試程式，讓DBExpress和BDE/IDAPI隨機產生資料，並且異動到資料庫之中。
下面便是執行測試的結果，從這些數據中我們可以看出DBExpress和BDE/IDAPI幾乎是不分上下
的。
新增資料筆數 DBExpress BDE
10 0.052 0.036
100 0.334 0.342
1000 3.186 3.421

2000 6.514 6.732
10000 37.992 36.109

不過DBExpress更吸引人的地方是如果程式師知道如何微調它的話，那麼它幾乎可以使用閃電般
的速度處理資料。例如下面的資料便是經過我調整之後的DBExpress和BDE/IDAPI比較處理資料
的結果。從這些數據中我們可以看到調整之後的DBExpress幾乎以不先3倍的速度在處理資料，
把BDE/IDAPI遠遠的拋在後面。看到這樣的結果，真不禁今人佩服Borland開發DBExpress的功
力。
新增資料筆數 DBExpress BDE 改良的DBExpress
10 0.052 0.036 0.047

100 0.334 0.342 0.206

1000
3.186 3.421 1.19
2000 6.514 6.732 2.686

10000 37.992 36.109 17.472


DBExpress不但提供了Linux平台上存取資料的標準，更提供了快速的處理能力，和跨平台的功
能。光憑這幾點便足以讓DBExpress吸引程式師的目光。雖然在Kylix 1.0中只提供了存取MySQL，
InterBase，DB2以及Oracle資料庫，但是Borland已經宣告在隨後會接著推出更多資料庫的引
擎，例如Sybase，Informix等。而且這些引擎會在準備好之後立刻的提供Linux以及Window
的程式師使用，而不需要再等待到下一個Kylix的版本。DBExpress的出現在Linux造成了非常
有趣的現象，那就是由於在Linux上還沒有一套標準的資料存取引擎，因此Borland目前獨自開
發的DBExpress引擎有可能憑藉其強大的功能和生產力，再搭配Kylix，有可能讓DBExpress成
為Linux平台上的標準，事實上我感覺Borland正在Linux平台上盡其所長的在定義標準。除了
資料存取引擎之外，Borland也正在和Third-Party定義類似Window平台上應用程式互相溝通
的標準架構，再加入Borland有VisiBroker和EJB這兩套元件模型產品，Borland極有可能在
Linux平台上重現其數年前是Window平台開發工具霸主的地位。DBExpress是如此的強大以及有
趣，如果日後有的話，當然會為各位再進一步的介紹DBExpress各種的功能。
當然Kylix提供的功能絕不是短短的一篇文章能夠詳細說明的。Kylix提供的功能遠超過本文章
到目前為止討論的。此外如果你是一個行家的話，那就更不能不知道Borland在Kylix背後付出
的苦心。那就是Kylix的執行時期函式館 - RTL(Run Time Library)。
Kylix的執行時期函式館
為了在Linux作業系統中提供一個RAD工具，Borland的RTL在背後進做了許多的事情，同時也
撰寫來數以千計的函式讓程式師呼叫使用之。更難得可貴的是，為了提供跨Linux和Window平
台的能力。Kylix的RTL以及即將推出的Delphi 6 RTL更經過了大幅度的重新改寫，以便讓幾
乎相同RTL能夠同時的執行在Linux和Window之中。這其中Borland付出的巨大資源可能會被
許多程式師所忽略，不過行家才會瞭解RTL才是真正的幕後英雄。
結論
Kylix的推出不但再次的各世人證明Borland是全世界最頂尖的獨立工具開發廠商之外，也代表
了Linux上的應用軟體也將會快速的篷勃發展起來。2001年第一季的Object Pascal版本的Kylix
的主要目標市場是Linux上的應用程式開發工具市場，但是隨後準備推出的C/C++版本的Kylix
則將會對Linux上的系統程式產生巨大的影響，因為連整個Linux的核心都將可以使用Kylix
來建立。
Kylix雖然是一個RAD工具，但是它能夠涵蓋應用程式開發，系統程式開發，甚至是Linux作業
系統核心開發的能力讓它足以成為Linux上的殺手級的軟體。因此如果各位讀者對於開發Linux
應用程式有興趣，或是Linux上的玩家，都不能夠錯過Kylix。稍待日後Kylix再加入完整的元
件開發模型，例如開發CORBA，或是藉由SOAP和EJB以及COM+整合，那麼Kylix將會是Linux
打上打遍天下

樂趣無窮，可能無限的新技術-Web Service

雖然電子商務的狂熱在最近似乎有減溫的現象，讓許多人能夠回歸到正常的步調之中，不過隨著
電子商務而發展的軟體技術並沒有稍停腳步，反而更加蓬勃發展。因為由這些技術創造的應用早
已成為許多人生活的一部份，甚至是開啟未來趨勢的基石。在目前最熱門且最被看好的技術便是
所謂的Web Service了，那麼什麼是Web Service呢？
簡單的說，Web Service是一種想把全世界的Internet/Intranet變成一個虛擬計算環境的觀念
和技術。在由Web Service組成的虛擬環境中使用者可以任何的用戶端軟體，例如瀏覽器，一般
的Window或是Java應用程式或是電子行動設備等，來呼叫Web Service提供的服務。而Web
Service本身則可以由任何的技術實作，例如開發者可以使用Delphi，Java，C/C++或是C#等的
語言和工具來開發。
Web Service是建立在開放和標準的規格之上，允許異質的用戶端呼叫以使用它提供的服務。因
此各種異質的用戶端必須使用一種共通的溝通標準才能夠順利的和由各種不同技術實作的Web
Service互通。目前最流行而且最具潛力的溝通標準當屬SOAP了。
SOAP (Simple Object Access Protocol)是由Don Box起草，並且獲得IBM，Microsoft，Lotus
和UserLand等大型公司支持而成為W3C標準之一的通訊協定規格。從SOAP的名稱中我們便可以
知道它是讓用戶端呼叫遠端物件服務的一種機制。SOAP以XML標準封裝呼叫遠端服務的格式，
有別於其他分散式物件模型呼叫特定的呼叫格式，例如CORBA的GIOP以及DCOM的ORPC。由於
SOAP以XML封裝呼叫格式，因此它可以使用任何的實體傳輸層來傳送，例如HTTP，TCP或是SMTP
等。也許讓我們使用一個簡單的概例來說明會讓各位更容易的瞭解。
假設現在我在Linux平台上以Java語言實作了一個Web Service，這個Web Service提供了一
個服務GetSystemTime。這個服務接受一個使用者名稱和一個密碼，如果成功的登錄之後，這個
服務便會回傳Linux平台目前的系統時間。那麼我可以使用Delphi以SOAP的標準封裝使用者名
稱和密碼來呼叫這個在Linux平台上的GetSystemTime服務。例如下面就可能是由SOAP封裝的
格式：

GordonLi
xx12yh_49

藉由SOAP，Delphi的用戶端應用程式可以輕易的呼叫Linux平台上的Web Service，而無需關
心這個Web Service是由什麼技術實作的，或是存在於任何地方，更不需要以特定的二進位格式
來封裝呼叫。因此藉由Web Service和SOAP，開發者可以輕易的整合各種異質平台，異質分散
式物件模型，而充分的利用所有的計算資源，這在以前是不可能輕易做到的，同時Web Service
和SOAP也為未來的發展開啟了另一扇的大門。目前Web Service已經在國外快速的蓬勃發展，
各種Web Service也已經在Internet上供人使用，例如搜尋MP3的服務，或是查詢全世界各地
氣象的服務等。相信Web Service和SOAP也將很快的在國內發展起來，也終將成為軟體開發人
員必備的軟體技能之一。
Web Service本身包含了許多的意義，觀念和技術，在RUN!PC 2001年5月份的『解析Web Service
的技術內容與意涵』一文中已經對於Web Service和SOAP有基本的介紹，讀者可以參考該文的
說明。
本篇文章的內容在於討論Web Service的技術架構和實作的技巧，並且首先以Delphi 6做為說
明如何實際的開發Web Service以及用戶端應用程式來呼叫Web Service。接著再說明如何使用
Delphi開發的用戶端應用程式來呼叫Internet上由Java開發的Web Service，來向各位讀者展
示Web Service和SOAP的開放性以及標準性。當我們成功的在本地機器呼叫了在世界上某一個
角落，由某一個人使用某一種工具開發的Web Service時，相信讀者也會讚嘆Web Service和
SOAP所帶來的無限可能和下一波的軟體技術的革命。

Web Service和SOAP的架構
那麼我們要如何才能夠知道每一個Web Service提供的服務？要如何才能夠呼叫到Web
Service？又要到那裡找到適合的Web Service呢？簡單的說，Web Service提供的服務是以所
謂的WSDL(Web Service Description Language)標準來敘述的，只要我們能夠取得特定Web
Service的WSDL，就可以從其中瞭解它提供的服務，以及如何呼叫這個Web Service。
最後一個問題是如何找到適用的Web Service，在目前全世界已經有人公佈了許多的Web Service
供人呼叫使用。此外IBM和Microsoft等公司也正在研擬所謂的UDDI標準以提供註冊，搜尋，
交換和使用Web Service的標準，開發人員可以藉由UDDI找到需要的Web Service，當然我相
信許多的Web Service將會由開發人員根據自己的需求而使用工具開發出來。
說了那麼多，可能讀者會想要知道到底Web Service要如何實作？要使用什麼語言或是工具才能
夠撰寫的呢？事實上Web Service並不限定任何特定的工具或是語言才能夠開發，簡單的說你可
以使用任何的工具或是語言來開發，甚至可以使用ASP/JSP等稿本語言(Script Language)來實
作。當然，開發人員也可以結合各種不同的軟體技術和元件架構來開發。
下圖是以比較實體架構的觀點來敘述Web Service的觀念。圖中的用戶端藉由SOAP和HTTP通訊
協定，透過Web Service Provider找到適合的Web Service，再呼叫它。而實體的Web Service
可以是實作在Window平台的MTS/COM+或是.NET物件，也可以是實作在Linux/UNIX平台中的
CORBA或是EJB物件。這個觀點是以各種元件模型來實作Web Service。



圖一 Web Service的架構示意圖

至於下圖則是以更細微的觀點來看Web Service的實體架構。在這個圖形中呈現了Web Service
可以由ASP/JSP或是CGI，ISAPI的形式來實作，以服務用戶端的請求。開發人員可以把所有的
Web Service企業邏輯實作在ASP/JSP/CGI/ISAPI/DSO之中。或是只把回應用戶端請求的邏輯實
作在ASP/JSP/CGI/ISAPI/DSO之中，而把真正的企業邏輯實作在後端的元件模型之中，或是後端
的應用程式之中，例如Delphi的DataSnap伺服器。



圖二 Web Service的實作架構圖

從上面的討論中可以知道，開發人員可以使用任何的技術實作Web Service，只需要根據標準輸
出Web Service，就可以由用戶端呼叫使用之。
討論完了觀念之後，現在讓我們回到實際的實作層次中。雖然Web Service可以由任何的技術實
作，但是開發人員仍然需要選擇一種方式來開發。開發Web Service除了實作Web Service的企
業邏輯之外，也必須提供Web Service的WSDL，並且分發Web Service。由於目前使用Web Service
的情形仍然以SOAP/HTTP型式呼叫，因此許多的Web Service也是以Web應用程式的型態實作，
例如把Web Service實作成CGI或是ISAPI/DSO的型式，不過只要能夠處理HTTP的呼叫，Web
Service也可以實作成一般的獨立應用程式，這一點是讀者必須瞭解的。
開發Web Service雖然不是非常的困難，但是它仍然需要許多的開發步驟和處理程序，這也仍然
需要花費一些開發成本。在Borland最新推出的Delphi 6中，Borland特別提供了7個直接的
Web Service元件，三個Web Service精靈以及其他數個相關的VCL元件來幫助開發人員快速的
開發Web Service，更棒的是，開發人員也可以再結合Delphi原有的MTS/COM+/CORBA/EJB元件
模型開發更具延展性的Web Service。下圖便是Delphi 6中直接和Web Service相關的Web
Service元件組。



圖三　Delphi 6提供的WebServices元件

這7個Web Service元件可以讓開發人員呼叫遠端Web Service，自動產生Web Service的WSDL，
以及進行SOAP/HTTP和Object Pascal語言之間的繫結(Binding)，以便讓Delphi的程式師能夠
使用Object Pascal直接處理SOAP之中的訊息。
下圖則顯示了在用戶端應用程式和遠端Web Service之間如何藉由這些元件溝通，以及每一個元
件之間的關係。由於Delphi 6是Window平台上的開發工具，因此它使用了Wininet.dll來傳送
HTTP封包資訊。



圖四 Delphi 6 WebServices元件的功能示意圖

從上圖可以知道，Delphi 6用戶端應用程式藉由THTTPRIO呼叫遠端Web Service，而
TOPToSoapDomConvert可以把Object Pascal的呼叫和參數自動轉換為SOAP封裝的格式資訊，
再藉由THTTPReqResp傳送HTTP封包。而在伺服端THTTPSoapDispatcher則負責處理用戶端傳送
來的SOAP/HTTP資訊，並且透過THTTPSoapPascalInvoker元件來自動啟動能夠處理這個
SOAP/HTTP請求的Object Pascal程式碼。至於TWSDLHTMLPublish則能夠自動的根據Delphi實
作的Web Service來產生WSDL並且輸出此WSDL讓用戶端應用程式能夠使用這個WSDL來呼叫Web
Service。
說明了Delphi 6中有關Web Service的元件和其功能之後，現在就讓我們看看在Delphi 6中開
發Web Service的步驟。下圖便是在Delphi 6中開發Web Service簡易的步驟：



圖五 使用Delphi 6開發 Web Service的步驟

首先程式師必須撰寫Web Service的核心邏輯，然後定義此Web Service的WSDL，以便讓用戶
端能夠遵循標準呼叫。在實作完Web Service之後，接著程式師就可以使用Delphi 6提供的
WebServices元件組來實作用戶端應用程式，並且藉由WSDL來呼叫Web Service。
在實作Web Service用戶端應用程式時，Delphi 6提供了非常彈性的方法，允許程式師使用Early
Binding或是Late Binding，不像某些解決方案只允許使用Late Binding。這種設計可以讓程
式師在開發Web Service解決方案時可以根據執行效率或是執行彈性來決定使用Early Binding
或是Late Binding。
為了讓讀者能夠真正的瞭解如何開發Web Service系統並且範例Delphi 6在SOAP和Web Service
方面的強勁功能，就讓我們使用一個實際的範例來說明如何使用Delphi 6快速開發Web Service
和用戶端應用程式，並且結合資料庫來提供用戶端資訊。這個範例Web Service是把MYESSAYS
資料表中的所有我寫的文章輸出給用戶端以便查詢資訊，而且不管用戶端是瀏覽器，一般的
Window應用程式，或是Linux下的應用程式都可以。下圖便是儲存這些文章資訊的畫面：



圖六 範例資料表

至於這個範例的整體架構如下圖所示。文章資訊是儲存在InterBase之中，並且藉由Delphi 6
的dbExpress來技術存取。至於實作Web Service的主體則是一個由Delphi 6撰寫的簡單Web
應用程式。最後我們實作一個原生視窗應用程式藉由SOAP來呼叫此Web應用程式實作的Web
Service。



圖七 實作Web Service的架構圖


步驟1 – 開發SOAP伺服端應用程式
首先程式師可以在Delphi中使用SOAP Server Application精靈來開發Web Service伺服器。
在Delphi 6中我們只需要點選File|New|Others功能表，然後點選WebServices頁次即可看到
下圖的畫面，然後再點選SOAP Server Application圖像。



圖八 Delphi 6的SOAP Server Application精靈

在點選了SOAP Server Application圖像之後，Delphi會詢問程式師要以那一種的實體型態來
實作Web Service，如下圖所示。程式師可以選擇欲實作的程式型態，例如在這個範例中我選擇
以Web App Debugger executable來實作，因為這個程式型態可以讓我們在開發Web Service
時能夠輕易的除錯。當然，程式師也可以選擇以一般的Window應用程式來實作Web Service，
而不使用SOAP Server Application精靈提供的下列實體型態的程式。



圖九 以Delphi 6的Web App Debugger應用程式的形式開發Web Service

在點選了圖九的程式型態和Ok按鈕之後，Delphi便會自動幫助程式師產生如下的Web模組。



圖十 Delphi 6建立建立的Web Module以及WebServices元件

在圖十的Web模組之中，Delphi自動產生的THTTPSoapDispatcher元件可以讓Web Server自動
呼叫此應用程式，而TWSDLHTMLPublish元件則可以自動產生敘述此Web Service的WSDL內容。



圖十一 範例Web Service的主表單

現在再讓我們在這個Web Service程式的主表單中加入一個TLabel並且設定它的Caption特性
值為『我的第一個Web Service』，如上圖所示。

步驟 2 – 定義Web Service的服務介面並且實作它
接下來的步驟便是真正的實作此Web Service。首先在Delphi 6中建立資料模組，並且使用
dbExpress連結到InterBase：



圖十二 範例Web Service的資料模組，它使用dbExpress元件存取InterBase

點選File|New|Unit功能表定義如下的IMyEssays介面，這個介面定義了此Web Service提供的
服務，用戶端應用程式可以呼叫GetEssayTitles函式取得所有文章的資訊，而這些資訊是儲存
在TEssaysInfos的陣列中，這個方法展示了Delphi 6的Web Service可以處理複雜的資料型態。
至於GetEssayContent則可以根據用戶端傳遞來的文章ID而回傳此文章的內容給用戶端應用程
式。


unit uMyEssaysInf;
interface
uses
Types, XSBuiltIns, uEssaysInfo;
type
IMyEssays = interface(IInvokable)
['{1C8ABA87-455B-4430-9881-239F5FFE7F49}']
function GetEssayTitles : TEssaysInfos ;
stdcall;
function GetEssayContent(const iID : Integer) : String;
stdcall;
end;
implementation
uses
InvokeRegistry;
initialization
InvRegistry.RegisterInterface(TypeInfo(IMyEssays));
end.


接著我們定義儲存文章資訊的資料結構。為了讓文章資訊能夠自動傳遞回用戶端，我們可以在
Delphi 6中從TRemotable類別繼承子類別，如此一來Delphi 6便會自動幫助我們處理資料
Marshalling的問題。最後必須呼叫Delphi 6提供的RemClassRegistry物件來註冊這些類別。


unit uEssaysInfo;
interface
uses
InvokeRegistry, XSBuiltIns;
type
TEssaysInfo = class(TRemotable)
private
FEssayID : Integer;
FEssayTitle : WideString;
published
property EssayTitle : WideString read FEssayTitle write FEssayTitle;
property EssayID : Integer read FEssayID write FEssayID;
end;

TEssaysInfos = array of TEssaysInfo;
implementation
initialization
RemClassRegistry.RegisterXSClass(TEssaysInfo, 'http://www.w3.org/2001/XMLSchema',
'TEssaysInfo', '',False );
RemTypeRegistry.RegisterXSInfo(TypeInfo(TEssaysInfos),
'http://www.w3.org/2001/XMLSchema', 'TEssaysInfos');
finalization
RemClassRegistry.UnRegisterXSClass(TEssaysInfo);
RemTypeRegistry.UnRegisterXSInfo(TypeInfo(TEssaysInfos));
end.


現在到了實作ImyEssays介面的時候了，我們定義TMyEssays類別從TInvokableClass繼承下來
並且實作IMyEssays介面。TInvokableClass類別可以讓用戶端從遠端呼叫。最後同樣呼叫
InvRegistry物件註冊TmyEssays類別，以便讓THTTPSoapDispatcher元件可以啟動。至於
IMyEssays介面之中的GetEssayTitles方法則是使用dbExpress從InterBase中讀取所有的資
料，並且把文章的ID和名稱儲存在一個TEssaysInfo物件中，再把TEssaysInfo物件儲存在
TEssaysInfos陣列中，最後回傳此陣列給用戶端。


unit uMyEssaysImpl;
interface
uses
SysUtils, Classes, InvokeRegistry, XSBuiltIns, uMyEssaysInf, uEssaysInfo, DB,
HTTPProd, udmMyEssays, DBXpress;
type
TMyEssays = class(TInvokableClass, IMyEssays)
private
procedure CreateDataModule;
procedure FreeDataModule;
public
{ IISAPITutorials }
function GetEssayTitles: TEssaysInfos;
stdcall;
function GetEssayContent(const iID : Integer) : String;
stdcall;
end;
implementation
{ TISAPITutorials }
procedure TMyEssays.CreateDataModule;
begin
dmMyEssays := TdmMyEssays.Create(nil);
end;

procedure TMyEssays.FreeDataModule;
begin
if (Assigned(dmMyEssays)) then
begin
dmMyEssays.Free;
dmMyEssays := nil;
end;
end;

function TMyEssays.GetEssayContent(const iID: Integer): String;
begin
Result := '尚未實作, 請待續!!!';
end;

function TMyEssays.GetEssayTitles: TEssaysInfos;
var
iNo : Integer;
iID : Integer;
eInfo : TEssaysInfo;
TD: TTransactionDesc;
begin
CreateDataModule;
TD.TransactionID := 1;
TD.IsolationLevel := xilREADCOMMITTED;
try
dmMyEssays.sconnMyEssays.StartTransaction(TD);
iNo := dmMyEssays.sdsMyEssays.RecordCount;
SetLength(Result, iNo);
iID := -1;
with dmMyEssays.sdsMyEssays do
begin
while not Eof do
begin
Inc(iID);
eInfo := TEssaysInfo.Create;
eInfo.EssayID := FieldByName('EID').Value;
eInfo.EssayTitle := FieldByName('ETITLE').Value;
Result[iID] := eInfo;
Next;
end;
end;
finally
dmMyEssays.sconnMyEssays.Commit(TD);
FreeDataModule;
end;
end;
initialization
InvRegistry.RegisterInvokableClass(TMyEssays);
end.


現在這個能夠處理複雜資料的Web Service便藉由Delphi 6提供的WebServices元件和精靈完
成了，接下來就是開發用戶端應用程式來呼叫此Web Service以取得文章資訊了。

步驟 3 – 開發用戶端應用程式呼叫Web Service
使用Delphi 6開發呼叫Web Service的用戶端應用程式更簡單，因為Delphi 6提供的
WebServices元件組中的THTTPRIO元件實在是太方便了，我們只要使用物件檢視器設定THTTPRIO
元件的WSDLLocation特性值為欲呼叫的Web Service的WSDL，那麼THTTPRIO元件便可以自動
的處理所有呼叫Web Service的細節。
例如下面便是使用Delphi 6開發的用戶端應用程式，在這個應用程式的主表單上使用了一個
THTTPRIO元件，並且在它的WSDLLocation特性值中輸入剛才開發的Web Service的WSDL檔案
的位址。



圖十三 範例用戶端應用程式的主表單

接著在『 我的文章』按鈕的OnClick事件處理函式中撰寫如下的程式碼：


procedure TForm2.BitBtn1Click(Sender: TObject);
var
oriCursor : TCursor;
eInfos : TEssaysInfos;
iCount : Integer;
lStart, lEnd : Longint;
begin
ShowCaption;
StatusBar1.Panels[0].Text := '呼叫Web Service中...';
StatusBar1.Refresh;
lvMyEssays.Items.begin
Update;
lvMyEssays.Items.Clear;
oriCursor := Screen.Cursor;
Screen.Cursor := crHourglass;
lStart := GetTickCount;
try
eInfos := (HTTPRIO1 as IMyEssays).GetEssayTitles;
for iCount := low(eInfos) to High(eInfos) do
begin
with lvMyEssays.Items.Add do
begin
Caption := eInfos[iCount].EssayTitle;
Data := Pointer(eInfos[iCount].EssayID);
end;
end;
finally
lEnd := GetTickCount;
ShowRunTime(lStart, lEnd);
lvMyEssays.Items.EndUpdate;
StatusBar1.Panels[0].Text := '完成呼叫Web Service';
StatusBar1.Refresh;
Screen.Cursor := oriCursor;
end;
end;

procedure TForm2.ShowCaption;
begin
lblCaption.Caption := '太棒了, 我的第一個Web Service程式';
end;

procedure TForm2.ShowRunTime(const lStart, lEnd: Integer);
begin
StatusBar1.Panels[1].Text := FloattoStr((lEnd - lStart) / 1000.0) + '秒';
end;


上面的程式碼藉由THTTPRIO元件呼叫IMyEssays介面的GetEssayTitles方法，取得
TEssaysInfos陣列，再從陣列中一一的取出每一篇文章的名稱，最後再填入到主表單中的
TListView元件之中。下圖就是執行此用戶端應用程式呼叫Web Service伺服器，並且取得所有
文章資訊的畫面。從這麼簡單的數個步驟中，我們已經使用Delphi 6開發了一個真正的Web
Service應用系統。



圖十四 範例用戶端應用程式呼叫Web Service得到資料的畫面

雖然這是我們使用Delphi 6建立的第一個Web Service，但是這個範例Web Service展示了Delphi
6的SOAP/Web Service解決方案能夠輕易的傳遞複雜的資料型態，因為在範例Web Service中
是使用陣列的型態來傳遞所有的文章資訊。Delphi 6的SOAP/Web Service技術絕不是像一些工
具只提供簡單的SOAP/Web Service解決方案，而是充分的提供了一般和複雜的應用程式，並且
能夠整合各種元件模型，是目前最具威力，也是最先進的SOAP/Web Service開發工具之一。
Delphi 6除了提供強勁的Web Service開發功能之外，新的Web App Debugger不但可以幫助程
式師除錯Web應用程式之外，也可以幫助程式師監督用戶端應用程式和Web Service之中傳遞的
資訊。這些資訊包含了SOAP的封包，以及Web Service伺服器回傳回用戶端的所有SOAP封包。
這對於程式師學習SOAP和解析SOAP Payload都非常有幫助。例如下圖便是我使用Web App
Debugger檢視此範例Web Service應用系統傳遞的SOAP Payload。



圖十五 Delphi 6的Web App Debugger可以顯示用戶端和伺服端之間所有的訊息

為了證明Web Service的威力和相通性，目前全世界已經有許多人成立了各種Web Service的網
站，讓開發人員能夠測試Web Service。例如現在WWW.XMethods.COM便是提供各種Web Service
的網站之一。這個網站羅列了許多的Web Service，下圖便是這個網站目前提供的Web Service。



圖十六 Internet上的XMethods(www.xmethods.com)提供了許多的Web Service供人呼叫使用

現在讓我們使用Delphi 6開發一個用戶端應用程式來透過Internet/Intranet呼叫遠端由Java
實作，執行在Apache上的一個查詢美國各州氣溫的Web Service。下圖是這個Web Service的
詳細資訊，這個Web Service的作者甚至提供了Java用戶端應用程式展示如何呼叫這個氣溫Web
Service，不過現在我想使用Delphi的用戶端應用程式來呼叫，而不是Java。



圖十七 XMethods上的眾多Web Service之一，Temperature Web Service

下圖便是在我的機器中使用Delphi 6開發的用戶端應用程式，藉由Delphi 6的WebServices
元件組來呼叫這個位於遠端，我也不知道在什麼地方的氣溫Web Service的結果畫面。
從下圖中可以證明，雖然我並不知道這個Web Service在那裡，我仍然可以藉由Web Service
的標準介面敘述WSDL來使用它，即使它是使用Java實作的，並且執行在Apache之上。



圖十八 Delphi實作的用戶端應用程式呼叫執行在遠端Apache上的Web Service

希望上面的內容可以讓各位讀者瞭解Web Service和SOAP在應用上的潛力以及Delphi 6提供的
元件技術可以讓開發人員快速而且輕易的實作出各種威力強大的Web Service。
也許藉由Web Service和SOAP的出現，也會對於目前應用系統架構產生巨大的影響。例如現在
『供應鏈』軟體非常的流行，但是許多的供應鏈軟體在整合上，中，下游廠商時，經常會需要所
有的廠商使用相同的平台以及基層軟體。但是對於下游廠商而言，可能無法像上游廠商一樣使用
昂貴的設備，例如UNIX BOX和大型ERP軟體，許多的下游小廠也許只能使用Window NT或是Linux
平台。不過現在Web Service和SOAP可以提供非常完善的解決方案，就如同下圖顯示的一樣，
下游廠商可以只使用ASP提供簡單的Web Service讓他的中游廠商呼叫。而上游廠商則可以在
UNIX Box中藉由大型的ERP軟體呼叫中游廠商執行在Window 2000中的BizTalk Service。如此
一來不但每一個廠商都可以選擇最適合的執行平台和軟體，也可以藉由Web Service和SOAP整
合上，中，下游廠商而提供一個及時且完備的供應鏈。Web Service和SOAP正為軟體帶來無限
的發展契機。



圖十九 Web Service的應用架構之一

雖然SOAP和Web Service目前已經成為標準並且也已經被世界廠商所接受和支援。但是SOAP
和Web Service仍然是在成長期，功能規格仍然在繼續的改善和強化之中，因此SOAP和Web
Service的變化也在預期之中。Delphi 6實作的SOAP和Web Service似乎是比較偏向IBM和Java
的陣營，因此Delphi 6能夠很容易的和Java以及PHP，Perl等SOAP/Web Service解決方案整
合。至於Microsoft的SOAP和Web Service則稍有不同，需要程式師特別注意一下。
如果下次有時間的話，那麼就讓我們繼續討論Microsoft的SOAP Toolkit以及.NET之中的SOAP
解決方案，並且比較Delphi和它們之間的差異以及如何整合這些不同的SOAP實作技術。

相关帖子:
李维：軟體服務時代的來臨
看看什么是软件服务时代！大家快来看看！
李维:.net vs delphi 6
delphi6 爆发还是灭亡？
李维:我的回忆和一些有趣的事
看IT风云变幻,宝兰与微软背后的故事,
李维:2001 年軟體界的巨星 - Kylix
看宝兰, 一年之间连续推出kylix1.0 ,interbase6.0, delphi6,jbuilder5 ,c++builder6也不
日即出,敬请关注宝兰2001年与微软对绝的杀手锏kylix
李维:Windows 原生開發工具的瑰寶 – Delphi 6

大家到www.csdn.net文档中心，搜“李维”

拜托 这些早就贴过了

接受答案了.