回首頁

線上論壇

線上資源

資源下載

新聞與活動

技術文章

關於Move-To.NET

Whidbey專欄

徵才&接案

登入
加入會員

還沒成為會員嗎?
趕快加入吧~

網站後台
累計:52861小時未停機
伺服器平台: 程式平台: 開發工具: 資料庫:
建置人力: 2 人-週
語言: C#/VB.NET
主機:HP-ProLiant
機型:DL380 G3

Web services 之規劃策略與設計模式--首部曲

Posted by on Monday, August 18, 2003 (台)

介紹資訊技術的演進對商業行為的影響、企業軟體架構的演進、Web services所創造的全新商業模式,平台與工具應該如何選擇、Web services有那些限制及將來的發長趨勢是什麼。

離線閱讀檔案,可至『線上資源 > 技術文章』處下載。

Web services設計模式--企業觀點

首部曲:Web services與全新的商業模式

 

李清培

弈飛資訊首席顧問 /台灣微軟特約資深講師

 

Internet導入到商業環境後,資訊工業又進行了另一項重大的變革。這一項變革除了影響整個資訊產業的整體概念,包括軟體的設計、銷售、部署、與執行的方式外,更進而影響到整個網路經濟的商業模式。

資訊技術的演進對商業行為的影響

在商業行為深度依賴資訊科技的今天,我想不會有人去質疑資訊技術的改革對商業行為所具有的影響力,只是對影響深度的認知有所差異而已。

拜規模經濟之賜,科技進步的速度常是令人無法想像的,不論是在電腦的運算能力,網路的連結能力,亦或是個人智慧型的周邊設備上,都有驚人的發展。其中在運算能力上,大約每十八個月,CPU的運算速度就可以加快一倍;在連結能力上,高速的網際網路,以及無線通訊、寬頻的普及,讓人與人、企業與企業間的互動日趨頻繁,尤其在台灣,寬頻的普及率甚至高過美國;另一方面,消費性電子的普及化,豐富的周邊設備,像智慧型手機、手持式電腦、個人數位助理更提供了方便的資訊存取管道;再加上資訊產業的一些標準規範不斷的出現,一個完整的網路經濟環境儼然成形。在這樣的環境下,傳統的商業行為與市場生態勢必受到衝擊。

典型的商業世界與電腦所建立之關係包括:資料處理與儲存、商業邏輯的運算、商務規則的執行、商業流程之整合、電子交易等…,其中最能凸顯商業世界與電腦世界兩者之關係的在於商業規則與企業需求之實現。

商業規則所規範的是一些定義商業行為的典範與策略,通常可能是一些通用的概念或規則,而在這些規則下所產生的特有企業行為則決定了公司的市場優勢。這些特有的企業行為,往往來自於企業自我定義的企業需求。在規劃企業應用系統程式架構的時候,這些特定的需求自然成為應用程式需求的基礎,同時也是程式開發者開發企業程式時所必須依循之規範,企業系統開發者必須儘可能的去滿足這些需求目標。而一但將這些商業規則與企業需求包裹成企業系統程式後,整個商業行為即必須依循這一套系統來運作。因此,一但系統發生任何錯誤或變更時,都可能對企業造成極大的影響。

在建立一套能協助企業達成其營運目標的應用程式系統時,商業規則與個別的企業需求構成了系統分析所需之參數;而電腦系統則在實現商業目標以及與市場互動的優勢上扮演了非常重要的角色,因此形成商業世界與電腦世界密不可分的現象。而隨整科技的發展,這樣的關係更加的緊密,也因此一但資訊技術有任何的改變,企業軟體架構與商業行為也會跟著改變。

企業軟體架構的演進

PC時代來臨以前,電腦的世界屬於大型主機的天下,而電腦的使用者也只是少數IT部門的人員。1980`s PC的到來,改變了部份企業的工作方式,電腦文書處理取代了傳統打字機;1990年,圖型化介面以及PC的網路架構來臨,縮短了人與電腦的距離,並快速地改變了這個世界與商業運作的模式;1995年Internet的到來,推翻了我們原有的溝通方式,全球吹起了一股網路風,豐富的資訊與快速的資訊散佈模式,帶給我們一個全新的電子商務環境。而隨著資訊技術的演變,企業軟體架構也由傳統大型主機與終端機的組合,轉而以PC為操作介面的主從架構或三層式架構為主,尤其是後期分散式運算與網際網路存取架構的大量使用,更是徹底的打破傳統大型主機的做法。並迫使一些主導網路市場的垂直整合系統大廠,紛紛改變策略,開始切割原有的解決方案,提供客戶更彈性的選擇。(這一部份將在談到工具與平台選擇時,再作進一步的說明)

然而,科技的進步是永遠不會遲疑的。我們若將圖型化介面與Internet當作資訊產業與商業模式的兩次革命,那麼我們現在正經歷著第三次的產業革命。在跨入21世紀的時候,全球將近有三十億的人口使用Web,企業與企業間的互動日趨頻繁,使用者對網站的要求已不單單只有瀏覽資訊而已,還希望能夠直接編輯、分析、與交換資料,企業開始期待一個嶄新的程式架構,希望能夠讓應用程式、裝置、與企業流程能夠充份的協同合作,另一方面,由於市場變動與競爭激烈,企業也開始企望一套類似人類神經網路的應用程式系統,希望能對快速變化的市場做出即時的回應,這些需求隨著科技的發展變成可能,其中很重要的技術就是Web services。

不知道您是否注意到一個手機的廣告詞“將無窮的力量,放在一個小盒子裡”,這樣的概念跟Web services的系統架構不謀而合。以前講到電腦系統,就是由硬體、作業系統、應用軟體所組成,未來,不只是電腦,任何豐富的周邊設備皆可利用Web services的開放式存取能力延伸現有應用程式的功能。

Web services延伸了來自網際網路及作業系統的概念,讓網際網路本身成為一種全新的作業平台。Web services擺脫了以往硬體的限制,將資料存放在網際網路中,再透過各種多樣化的平台設備,包括桌上型電腦、手提電腦、手機或掌上型裝置來達到即時傳遞資訊的目的;Web services能讓您輕鬆地在資料或應用程式間建立連結並完成交易;藉著將多種安全性機制與資料整合到單一使用介面,您不再需要為了瀏覽不同部門或不同網站的資料,而開啟一堆的視窗;Web services甚至可以是一種可程式化的自動決策引擎,快速的為您作出最佳的選擇;Web services架構跳脫出目前網頁應用的限制,讓使用者可以隨心隨欲地透過任何裝置,在任何時間、任何地點自由地存取資料或將這些資訊整合於應用程式中,企業的軟體架構也因此而無限延伸。

因此,在Web services的世界裡,如果您要問企業應用程式系統的平台在哪裡?您可能必須先回答我Internet在哪裡?因為Internet本身就是一個應用程式的平台。也就是說,在Web services的世界裡,企業應用程式系統是架構在整個Internet之上。

Web Service如何創造全新的商業模式

電子商務雖然泡沫化,但網路經濟卻一直驅策著商業模式的改革。Web services不同於其他分散式應用程式的重點在於“標準”與“整合”的概念,這兩個概念正好符合目前企業應用程式整合(EAI)與B2B的需求。若以Web services在商業行為中所扮演的角色來分,可以將Web services分成兩大應用範疇,第一種是以Web services作為企業營運與交易之機制,這一類的用途主要用在企業的整合上,包括資料整合、EAI、B2B、流程管理等;另一種做法則是直接將Web services當作交易標的,也就是直接出售Web services的功能服務,包括功能性的隨選服務(Services-on-Demand),以及軟體積木等。

對於許多企業而言,使用Web services的第一個實作通常會是內部應用程式的整合。利用Web services延伸或擴充原有應用程式的功能,或將不同系統,以Web services 加以連結或整合。Web services帶給企業系統整合所需之標準與彈性,有彈性的商務模型會讓組織更適應商業環境裡的變化。

另一個驅動Web services 發展的主要力量則為B2B的商業模式。有人甚至斷言供應鏈整合將會是最具威力的Web services應用程式。主要是因為供應鏈影響的範圍廣,而Web services提供供應鏈應用程式所需之XML及相關之產業標準。利用Web services 加上流程管理軟體,可以讓企業內部或與外部合作夥伴間建立起天衣無縫的作業流程,如此不但能提升企業組織的效率並降低企業經營的成本。

至於將Web services當作交易的標地,則可能直接影響資訊系統的設計、部署與採購模式。企業可經由外部所提供之軟體服務,取得執行商業行為所需之應用程式功能,而不需全然由內部來開發。透過這種方式,程式開發者不須再使用傳統建立單一、集中式伺服器應用程式的方法,即可快速地建立或延伸現有應用程式的規模。企業因此可節省系統開發所需之時間,加快市場開發速度。

例如,您如果想在企業的網站上或一般視窗程式上提供像Google一樣強大的搜尋引擎功能,您大可不必大費周章地建置資料庫、蒐集資料、分析、儲存、再辛苦地建立搜尋索引;您可以直接使用Google所提供的Web services,就可在應用程式中加入此一功能。(目前這個服務是免費的,請參考http://www.google.com/apis/)

在軟體銷售/採購的方式則可能改為租用或隨選服務的模式;企業也可以利用Web services 將原有企業的智慧財產或成功經驗,重新包裝出售,以開拓全新的軟體服務市場。對ISV或VAR、OEM等廠商,更是提升商品附加價值的方式。

有關Web services在商業行為上的應用部份,將會在第三篇的文章中(三部曲:Web services與企業營運之規劃與策略)作更進一步的解說。在這裡,先以一個實際的例子作說明。

由於工作關係,常常往返於北高之間,最佳的交通工具可就非飛機莫屬了。我是一個到了國外也不太會有時差的人(反正日夜顛倒習慣了),而飛機上小睡片刻,可能為一天的工作提供基本的能量,而遠東航空機長優雅的飛行技術,以及體貼的空服員,總是讓我睡得很安穩。在機票的購買上,除了臨時電話訂位外,通常我會選擇透過易飛網 (ezfly.com)的網路訂位系統訂位。在商業的生態上,易飛網代理多家航空公司的網路機票銷售,提供消費者單一窗口的銷售機制;各航空公司則透過這樣的合作模式,在拓展電子商務的市場上,省卻了網路票務系統的開發成本。但若純粹由航空公司的銷售角度來看,ezfly.com只是特殊通路中的一種而已。

雖然在開放的市場上沒有誰是誰的客戶,但卻可以透過一些客戶關係管理的機制,爭取客戶再次消費的機會。最常使用的方式通常是所謂的會員制,除了提高客戶的品牌認同以外,大多會再以哩程數、紅利、積點等刺激再次消費,我除了是遠東航空的會員,當然也是ezfly.com的會員。在一次偶然的機會,我以會員身分登入到遠東航空的網站,網站上提供了線上訂位的機制,好奇的點選後卻被重新導置到ezfly.com的網站,唯一不同於直接登入ezfly.com的是網頁上只顯示遠東航空公司的班次。

這時候您是否跟我一樣開始思考,有沒有一套機制,可以讓客戶一直停留在遠東航空的網站上,卻同時能利用ezfly.com的票務系統呢?傳統的做法就是遠航自行開發一套網路訂位系統;另外一種則是利用Web services直接使用ezfly.com的票務系統,遠航只需在自己的網站上提供一張美美的使用者介面就可以了,客戶將一直停留在遠東航空的網站上,而整個交易行為仍由ezfly.com的票務系統進行處理。

這樣的網路經濟模式對ezfly.com而言,除了原有供應練、B2C的交易模式外,還可將執行多年網路票務系統的成功經驗,重新包裝成Web services出售給其他航空公司;對航空公司而言,除透過ezfly.com的通路銷售機票以外,也可透過ezfly.com所提供的 Web services ,建立自己的電子商務交易機制,並建立起客戶的品牌認同。(以上僅是個人經驗上的認知,若對兩家公司造成困擾,僅此致歉。)

Web Service與分散式應用程式的需求

在了解Web services對企業所造成的影響及可能產生的商業模式後,或許您會問,那是怎麼作到的?這樣的模式對企業有什麼好處?我可以利用Web services做些什麼嗎?要回答這些問題,我們必須回過頭來,談談Web services發展的背景,以及所要解決的問題。

首先,如同前面所說的,Web services也是分散式應用程式的一種,不管是分散式應用程式、三層式架構、或多層架構應用程式,聽了很多,架構也有很多種,那麼Web services又有什麼特別。我們就從分散式應用程式的需求談起。

什麼是分散式應用程式呢?廣義的來講,將應用程式系統分成好幾個子系統,再將這些子系統的程式分別放在不同的行程、不同的機器、甚至不同的國家一起執行以完成共同的任務,那麼這就是所謂的分散式應用程式。但問題是這些程式之間要如何進行溝通呢?這就是各系統或軟體廠商在發展分散式應用程式時所要處理的問題。我們如果以國際貿易來作比喻,不同國家的企業要如何進行交易呢?我們需要一個交易的管道、我們需要一套標準的貨幣機制、我們會依循一般貿易的習慣、我們會訂定一些契約,在雙方認知下才能進行交易。相對的如果回到資訊的世界,兩個跨行程或跨機器的應用程式要能進行溝通,必須有共通的資料格式、共通的應用程式介面、共通的網路環境,當然還要有一套讓兩個應用程式相互認知的機制。為了處理這樣的問題,各家系統或軟體廠商分別提出不同的中介軟體與架構來簡化開發過程。如果以微軟的DCOM架構為例,圖1列出了分散式應用程式所需的四個基本技術。(對於個別技術在此不多作解釋,我將會在另一個Web services系列文章,以技術觀點來談這些架構。)首先兩個應用程式必須協調好透過什麼管道(通訊協定)進行溝通,再來必須協調好使用什麼樣的資料格式,以及契約書描述的方式(IDL),最後則是一套能夠找到遠端程式的機制(探索機制)。有了這四個機制,應用程式之間就可以進行溝通了。

1 DCOM分散式應用程式架構圖

雖然這種分散式的應用程式架構為商業運算帶來了更彈性、更經濟、更具效能的開發與企業營運模式,然而目前各組織或軟體廠商所使用的分散式應用程式架構,如DCOM、CORBA、RMI等皆使用自己獨特的一套技術,使得系統整合不易。企業一旦採用某一套架構後,就很難再作改變。當企業面臨應用系統整合的規劃與需求時,總是困難重重;對一堆異質的資料來源,總必須花費許多的雜工才能加以整合利用。每一個系統都成了一個個孤島,更不要說跟其他企業作溝通與整合了。

2 不同分散式應用程式原件物件技術之比較

當這些技術應用在傳統區域網路時,這些問題還不會構成太大的困擾,然而隨著網際網路技術的發展,企業對網站的要求不單單只有瀏覽資訊而已,還希望能夠編輯、分析料、與交換資料;希望能夠讓應用程式、裝置、與企業流程能夠充份的協同合作,這時候,這樣的應用程式架構立刻面臨了嚴重的考驗。

為了解決這個問題,WS-I組織(ws-i.org)定義了一套共通的分散式應用程式標準-- Web services,利用HTTP、XML、SOAP 和 WSDL這些標準規範,實現跨平台、跨語言、跨Internet的整合目的。透過這樣的開放式標準,應用程式之間可以進行交互作用,並輕易地與其他應用程式分享與共用資訊。圖3所展示的即是利用這四項公開的標準技術,所構成的Web services應用程式架構。在眾多的分散式中,如果Web services能夠成功,其原因應該是在於“標準”與“彈性”。

3 WS-I基本規範之分散式應用程式架構圖

Web services與企業的需求

在了解Web services所要解決的程式架構問題後,另一個重要的問題就是,這樣的技術,是否能滿足企業在商業行為上的需求。

各企業在建立資訊系統時的營運目標可能大不相同,但通常可歸納為以下幾點:

u         R 即時的取得正確資訊

u         R 形成最佳的商業決策

u         R 快速反應變動市場

u         R 加強與員工及客戶的溝通

u         R 員工能力與智慧的激發

u         R 產生最佳的投資報酬率

決策的困難往往在於經驗不足與資訊不足。然而透過高速的運算能力、豐富的周邊設備、廉價的寬頻網路、以及標準的資料格式,即時資訊的取得已不再困難,而Web services則提供取得資訊所需的軟體架構。若再配合專家系統與決策引擎的建置,由Web services提供源源不斷的資訊作為判斷的參考數據,想要“掌握資訊、預測未來”就不是太大的問題了。

傳統取得市場資訊的方式主要來自靜態的新聞,近年來盛行的電子報及電子媒體的即時財經報導,雖然讓資訊的取得更為快速與多樣化,但如何將些資料轉換為決策的參數值,可就很傷腦筋了。雖然許多新聞媒體也提供了網路版的功能,然而要將靜態網頁裡的資料淬取出來也不是一件簡單的事,若能透過Web services直接取得這樣的資料,就可以加快資訊取得與分析利用的速度。也就是讓應用程式自己去瀏覽網頁以取的所需的資訊,不過這樣的網頁不是傳統HTML的網頁,而是Web services。

有一位業界資深的系統分析師在為某家連鎖超商規劃應用程式架構的時候,跟我交換了一些意見。其中一部份與即時資訊取得有密切關係的,在此提出一小段與各位分享。在這家連鎖超商的商品中,有一項是近來非常熱門的商品—便當 (市場白熱化的戰爭我想不是今天的主題) 。這項商品有幾項特色,其中替代性太高與保存期限短,限制了每日生產量。在所有參考的變數中有一項是氣象資訊,有沒有下雨、各時段、各地區的氣溫,都可能影響到整體的銷售量。雖然氣象資訊取得並不困難,但能否在決策者的程式介面上,就可以動態的展示最新的氣象資訊,而不需另外開啟另一個氣象資訊的視窗;或是直接將這些資訊當作參數值輸入到應用程式系統中,而不須由人工查詢與輸入。這樣的解決方案並不難,唯一的需求是氣象局必須提供這些資訊的Web services。

在與員工及客戶的關係上,Web services同樣的可以發揮效用,除了利用Web services提供彈性與客製化的服務外,利用Web services所建立的單一簽入與單一整合操作介面,讓客戶以及公司的知識工作者,可以更輕鬆地利用電腦資訊與公司溝通。透過Web services可以讓公司的知識工作者,包括分公司、駐點辦公室、或行動工作者,可以輕易的與公司建立連結。

而在變動的市場上,企業要能夠快速的調整,並提高投資報酬率並不是件容易的事。根據經驗值,當企業為反應市場的變動而對應用程式作相對調整時,其最大的成本除開發費用以外,開發期間所產生的機會成本、員工的教育訓練及生產力暫時性降低的成本,都是主要的考量。有一次遇到一位以前帶過的學生,他正在為公司進行一套系統移植與升級的工作,他很緊張的告訴我,老闆給他的條件是花多少錢都沒關係,但如果因為計畫的執行,讓公司少接了一張訂單,那他就不要幹了。

如果開發新系統能夠以模組化的方式進行,可以部分自製、部分外購,即可降低系統開發所需的時間與成本,並加快新產品或新服務導入市場的時間;若能夠將人因操作介面與商業邏輯分開,則可以降低因系統或商業邏輯變更,對使用者所造成的衝擊。這些問題一樣是Web services所要解決的。

Web services 的設計目標是讓企業可以透過網際網路,編輯、存取與交換資料,讓應用程式、裝置、與企業流程能夠充份的協同合作。在高度變動與競爭的市場中,資訊收集、管理和使用的方式,即足以決定企業的輸贏;而Web services無論在速度、反應、訊息、認知、執行、應用、主導、整合等各方面都提供了絕佳的表現。

平台及開發工具的選擇

若您已準備要開始建置Web services的解決方案,那麼,在資訊系統的建置上,平台與開發工具的選擇亦是一個重要的課題,這一方面是否具有像Web services一樣的彈性呢?這個答案是肯定的,很多人一聽到平台的選擇,立刻想到.NET與J2EE的競爭,這樣就完全背離了Web services的精神。

拜規模經濟與自由市場之賜,資訊市場早已由傳統的垂直整合轉變為水平整合,因此在平台與開發工具上有更多的選擇機會,更進而降低整體擁有的成本。在傳統的垂直整合市場中,我們幾乎毫無選擇的只能向一家公司購買整個解決方案,從硬體設備、作業系統、應用程式、網路設備和服務,每家廠商都有自己的垂直整合方案,即使號稱所謂跨平台的規範,在各個系統廠商客製化,最佳化、或特殊化的結果的結果,整合不同廠商既困難也不經濟,更不改輕言更換系統。因為整個解決方案從硬體到軟體是環環相扣,牽一髮動全身。再加上軟硬體規格綁死的狀況下,無論建置、服務、與維護成本都高得離譜。尤其以硬體見長的台灣,似乎無法因此取得相對的優勢。

在資訊產品形成規模經濟之後,垂直整合的的架構不再是唯一的選擇。客戶可以在每一個環節上,由硬體設備、晶片、處理器等,到系統軟體、應用軟體、開發工具及系統整合服務等,都可依企業的需求選擇適合自己的產品,雖然原有大型垂直整合廠商仍佔有大部分的市場,但已紛紛改變策略,開始分割並重新包裝原有解決方案,提供客戶彈性的整合。水平整合帶給企業無限的彈性。

目前在實作Web services所使用的平台架構包括.NET與J2EE,相關支援的產品與開發工具也非常多。我們將會在最後一篇文章中,再作詳細的比較說明,不過唯一可以確定的是,您不需再像以前被大型系統業者牢牢的綁死,取而代之的是一種超彈性的選擇。未來在規範標準化後,市場的競爭不在於哪一個平台超越另一個平台,而是在於誰能提供快速、安全、與準確的實作能力。

Web services的限制與展望

雖然前面不斷的展現Web services的威力以及為企業所帶來的競爭優勢,然而在本篇文章的最後,我必須說明的是,Web services並不是萬靈丹。在描繪Web services架構的時候,除注意商業規則與企業需求以外,還必須注意程式開發的環境、商業流程以及流程管理;再來則是資訊表示的方式與系統整合,如此才能設計出符合企業需求且具彈性的應用程式系統架構。

另一方面,一般在介紹到Web services時,通常侷限在XML、SOAP、WSDL、UDDI,這對真實企業環境而言,是不夠的,對於個企業級的應用程式系統,可靠度、妥善率、生產力、安全性、擴充性、延展性等 ...,都是不可或缺的,若不能滿足以上的需求, Web services將只是一個技術名詞而已。目前由WS-I所訂定的規範主要在處理分散式應用程式上的問題,若要將Web services 應用到全球的商業環境上,仍有些技術必須去克服,例如安全性的問題,交易的保全,訊息傳遞路徑的設定,大型資料傳遞等問題。幸運的是,由WS-I的會員組織包括Microsoft與IBM等,不斷的在協商、訂定一些相關的標準規範,以彌補基本規範的不足,而且截至目前為止,已有相當可觀的成果。更令人振奮的是,隨著這些規範的定案,相對的開發工具或模組也陸續的完成,其中以微軟的WSE(Web Services Enhancements)就是屬於這些規範的實作工具。

在未來的幾篇文章中,我們將進一步的探討Web services應用程式的架構與設計模式,以及Web services所衍生的全新商業模式,當然也會包含平台與工具的選擇,以及導入時機與建議步驟。

期待在相會!


歡迎新會員
buh Micpaake
會員人數:
7595
Microsoft MSDN 網站
弈飛資訊 網站

 

Love sought is good, but given unsought is better.
--- Shakespeare

 

最新發表 

  • Buy Flagyl Online No Prescription
    Posted by buyfglaylnowjjsd on Wednesday, July 14, 2010 (台)

  • Fast Payday Loans Of Ohio
    Posted by etedgeanobape on Tuesday, July 13, 2010 (台)

  • nirvana cannabis seeds
    Posted by Clalcuhclatte on Thursday, July 01, 2010 (台)

  •  

    最新回應 

  • mp3鬧鐘程式for PocketPC
    Posted by a0913697944 on Tuesday, June 29, 2010 (台)

  • 如何在Multi-thread的情形下,控制Form元件,例如ListBox???
    Posted by wywcinema on Monday, September 28, 2009 (台)

  • 如何在Multi-thread的情形下,控制Form元件,例如ListBox???
    Posted by wywcinema on Monday, September 28, 2009 (台)

  •  

    最新連結 

  • 下載微軟最新 Visual Studio .NET 技術名詞小幫手
    Microsoft Terminology Assistant 是一個視窗架構的小幫手工具,它可以立即協助您找出滑鼠所指的技術名詞原文和定義。
    當您在閱讀電腦上的技術說明文件時,您可以使用 TA 這個工具根據您滑鼠游標的位置立即協助您找出滑鼠所指的技術名詞原文和定義;這工具也提供軟體技術辭彙字典的功能,讓您能直接查出並不瞭解的技術名詞。您一定可以使用這個小程式來使您能更快、更準確的學習最新的軟體技術,加速您學習軟體技術的時間。


  • DBA 的 SQL Server Yukon 概觀
    這篇文章提供有關資料庫系統管理的新功能,以及資料庫可用性、延展性與安全性的概觀。

  • 伺服器端 ASP .NET 資料繫結之二:自訂 DataGrid 控制項
    DataGrid 是網頁編輯最常使用的控制,但是DataGrid 雖然好用卻有一些使用上的限制,本篇文章介紹了如何自訂DataGrid來滿足所須的功能。



  •  
    本網站由弈飛資訊建置維護