13518219792
VB.Net中的隊列類在System.Collections.Generic命名空間中，名字叫Queue，是一個泛型類。
林芝網站建設公司創新互聯公司,林芝網站設計制作，有大型網站制作公司豐富經驗。已為林芝上千多家提供企業網站建設服務。企業網站搭建\外貿營銷網站建設要多少錢，請找那個售后服務好的林芝做網站的公司定做！
實例化該類：
Dim myQueue As QueueInt32
myQueue = new QueueInt32();
然后可以通過Queue中的Enqueue和Dequeue函數進行入隊出隊操作：
With myQueue
.Enqueue(1)
.Enqueue(2)
.Enqueue(3)
.Enqueue(4)
.Enqueue(5)
End With
For i = 0 To 5 Step 1
Console.WriteLine(myQueue.Dequeue())
Next i
顯示結果：
1
2
3
4
5
先連接數據庫，然后把數據庫內容讀取出來，顯示在文本框里面，百度上有很多的
摘 要：?目前，在軟件開發平臺方面存在兩大陣營，分別是J2EE和．NET。這兩個平臺都是為了解決構建企業計算等大型平臺而出現的。在這兩個平臺中都包含了一系列的技術，通過這些技術可以縮短開發周期。提高開發效率，節省構造成本。同時這兩個平臺都在安全性、擴展性、性能方面做出了努力，都提供了一系列的技術可供選擇。從這個角度來說，這兩個平臺都實現了它們的目標，都是成功的。兩個平臺的相似之處遠遠多于相異之處。
毫無疑問，程序員，軟件開發商，企業IT經理一直都在密切的關注著J2EE和.NET的發展，但是選擇一個在性能，價格，時間上滿足他們需求的平臺卻并不是一件簡單的事情。本文試圖在技術上做一個簡單的比較，希望對于他們做選擇時有所幫助。
一.技術概觀
在表現形式上，J2EE是一組規范，而.NET更象是一組產品。但它們的目的都是為了企業應用提供分布式的，高可靠性的解決方案.它們在架構上有著很多的相似之處，下表是一個簡單對照:
J2EE?.NET?
通信協議?Remote?Method?Invocation?over?Internet?InterOrb?Protocol?(RMI/IIOP)，XML?
編程語言?Java?C#，VB.NET，COBOL?
運行時環境?Java?Virtual?Machine?(JVM)?Common?Language?Runtime?(CLR)?
胖客戶端?Java?Swing?Windows?Forms?
目錄服務?Java?Naming?and?Directory?Interface?(JNDI)?Active?Directory?Services?Interface?(ADSI)?
數據訪問?Java?Database?Connection?(JDBC)?，Java?Connectors?ADO.NET?
異步消息處理?Java?Message?Service?(JMS)?Microsoft?Message?Queue?
表示層技術?Servlets，?Java?Server?Page(JSP)?ASP.NET?
中間層組件模型?EJB，JavaBean?COM+，COM?
安全訪問?JAAS?COM+?Security?
Call?Context?
事物處理?Java?Transaction?Server?(JTS)?Microsoft?Distributed?Transaction?Coordinator?(MS-DTC)?
開發工具?WebGain?Visual?Café?
Borland?JBuilder?
IBM?VisualAge?等?
(第三方提供，規范本身沒有定義)?Visual?Studio.NET
J2EE平臺的構成
EJB?-?J2EE?中間層，完成商業邏輯；
JAAS?-?J2EE?處理認證和授權的API;
Java?Connectors?-?J2EE?用于連接異種數據源的API，對上層來講是透明的;
JSP，?Java?Servlets?-?J2EE的表示層技術，用于生成用戶界面;
Java?Virtual?Machine?-?Java?語言運行環境；
JDBC?-?J2EE數據庫訪問；
JMS?-?J2EE的異步消息隊列；
JNDI?-?J2EE的名字查找API，獨立于目錄服務器；
JTS?-?J2EE用于處理交易的API；
RMI/IIOP?-?J2EE的分布式對象的通訊API，提供了和CORBA交互的能力。
.NET平臺構成
.NET?Framework?-?.NET應用運行的基礎；
IL?(Intermediary?Language)?-?所有的.NET語言首先被編譯成該中間語言，然后在CLR中運行；
SOAP?-?用于服務訪問的工業標準；
DCOM?-?組件間通信協議；
MS-DTC?-?用來在.NET平臺上使用兩階段提交協議來處理分布式交易；
CLR?-?.NET應用的運行時環境；
COM+?-?.NET的中間層模型，用于構建商務邏輯；
ADO.NET?-?.NET?對數據訪問的API。
此外.NET平臺還包括其他一些產品象Application?Center?Server，BizTalk?Server?，NLBS?(Network?Load?Balancing?Service)，Commerce?Server，Enterprise?Servers，HIS?(Host?Integration?Server)，ISAS?(Internet?Security?and?Acceleration?Server)用來提供象防火墻，安全訪問，B2B交易，負載平衡等服務.J2EE規范本身沒有定義這些服務，但可通過選擇第三方產品來滿足類似的要求。
二.技術比較
1.一?vs?多
一種語言vs多種語言，一個平臺vs多個平臺.這似乎是大家最喜于津津樂道的話題，也似乎是所有問題的焦點。
兩種平臺主流的開發語言Java和C#在架構上有著驚人的相似：虛擬機技術，基于沙箱的安全模型，分層的命名空間，垃圾回收等。所以從第一眼看上去，C#簡直就是Java的克隆。但微軟并不這樣認為，微軟的說明是：“它集成了C++，?Java，Modula?2，C和Smalltalk等多種語言的精華，對它們共同的核心思想象深度面向對象(deep?object-orientation)，對象簡化?(object-simplification)等都一一做了參考。”一方面，C#的大多數關鍵字來源于C++，使它在書寫上有別于Java。但另一方面，C#的嚴格的類型轉換等概念卻明顯來自于Java(當然，它的原始類型的定義更嚴格，并且據微軟聲稱沒有影響到效率.)，使其在內涵上有克隆之嫌.但即是Java，其有些特性也和Smalltalk頗有淵源.所以評價一種開發語言的優劣不僅是看其外在的表現形式，更重要的是其實實在在的功效.作為一種新語言，C#加入了基于XML的標記，可以被編譯器用來直接生成文檔，C#的另一個特點:一站式軟件(one-stop-shopping?software)強調了自解釋(?self-describing)?的編碼方式，即頭文件，IDL(Interface?Definition?Language)，GUID和其他復雜的接口無需再被引用.也即是C#，VB.NET等代碼片斷可以任意的被加入到其他語言中.這無疑在多種語言混合編程的模式中是一次飛躍，但是，其難維護性也是不言而喻的。
微軟的.NET的平臺提供了象C#，VB.NET，COBOL等多種開發語言，C#是新的，而其他的每一種語言都是在原有的基礎上改造而來.這是微軟煞費苦心并且也是不得以的要為習慣于這些語言的程序員鋪一條便捷之路.但是，這些語言的改造與其說是整容到不如說是一次開膛破肚的大手術.首先是觀念變了，Basic，Cobol等語言先天的缺少面向對象的內涵，現在卻變成了面向對象的語言，這就不是要求其傳統的程序員僅僅熟悉一些額外的關鍵字那么簡單的問題了.基于面向對象的軟件分析設計開發測試是完全不同于基于傳統過程性語言的質變，所以這一過程的轉變對傳統程序員來講也是一個痛苦和漫長的過程.在傳統程序員面前，微軟看似提供了豐富多采的解決方法，但對于實際問題而言，卻怕是有些力不從心.所以一個簡單的辦法是:直接使用C#.對于獨立軟件開發商來講，其轉換成本不容忽視.其次，在一個軟件項目中使用多種語言，開發商必須同時擁有多種語言專家和多個獨立的難以互相支援的開發小組，無疑的，這也使其軟件的維護的成本已非線性的曲線增長.多樣性是雙韌劍，實施時需仔細斟酌.
跨平臺是J2EE的最大賣點，也是至今為止還絆住微軟的柵欄.當開發商完成了符合J2EE規范的軟件時，其客戶可以依據其喜好和實力來選擇不同應用服務器.從基于open?source的免費軟件到高端滿足B2B需求的商業套件來搭建自己的平臺.但是由于J2EE的規范還不完善，各個J2EE服務器的提供商為了使其提供其各自理解的完整的功能，不得不添加一些額外的特性.這就使得使用了這些特別功能的應用軟件，綁定到了特定的應用服務器上.隨著J2EE規范的發展，這種差別會逐漸減小.
微軟的跨平臺解決方案是Web?services，它解決的是異種平臺上不同應用之間的連通性問題.從技術角度講，它除了以XML為介質之外沒有什么新意.但它的重要意義在于:它是微軟這樣一個重量級選手所推出的，前景不容小視.構造和使用?Web?services?的過程較為簡單:
服務提供者用他所選擇的語言構造服務;
服務提供者用WSDL(the?Web?Services?Description?Language)來定義該服務;
服務提供者在UDDI?(Universal?Description，?Discovery，?and?Integration?)中注冊該服務;
使用者的應用程序從?UDDI中查找已注冊服務;
使用者的應用程序通過?SOAP?(the?Simple?Object?Access?Protocol?)來調用服務.(SOAP使用HTTP來傳遞基于XML為表現形式的參數)
正如我們所討論的:?Web?services解決的是異構平臺上服務連通性的問題，但在現實中所更迫切需要的是如何在異構的平臺上構造具有可擴展性，高可靠性，高可用性，故障冗余，錯誤恢復能力的企業應用.缺少這一點，從結構上講，.NET平臺還遠未完善.
2.中間層
基于組件的軟件開發技術可以在較高的級別上實現軟件復用，加快企業軟件開發的進程.在J2EE構架中，?JavaBean和EJB(Enterprise?JavaBeans)?被用來完成事物邏輯.其中EJB和?JavaBean?有著類似的模型，但它被用來創建分布式的企業應用.它定義服務器端組件的模型，具有以下一些特性:
生存期模型；
訪問模型；
安全模型；
事物處理模型；
會話處理模型；
數據封裝模型；
部署模型
根據這些模型，簡單的編碼就可完成復雜的功能。
在微軟的.NET平臺中，舊的COM?和?COM+的組件模型被新的組件模型所代替。增加了象基于沙箱的安全模型和垃圾回收等功能.并且實現了多重接口繼承，擴展的元數據和新的代理模型等.舊有的COM和COM+組件也可被映射到新的運行環境中。
綜上所述，兩眾架構在基于組件的中間層的設計上各有千秋，對于創建分布式的，復雜的，高效的，高可靠性的的應用程序都有著足夠的能力。
3.表示層
兩種架構都同時支持胖客戶端和瘦客戶端.即C/S模式和B/S模式.對于C/S模式，J2EE提供了替代Java?AWT的Java?Swing，同時作為可視化組件的JavaBean也可用來構造系統。對于B/S結構的表示層，J2EE使用?servlet?，JSP(Java?Server?Page)?，HMTL，WML，XML等工具來實現。
微軟的胖客戶端技術則由?Windows?Forms代替了MFC.它們起的作用相同，在結構上?Windows?Forms?被插入到.NET的運行時框架(runtime?framework)和組件模型?(component?model)中.在瘦客戶模型中，?ASP.NET代替了舊有的ASP和?HMTL，?WML?，XML作為表示層。在?ASP.NET?中，C#，VB.NET等語言的代碼片斷可被自由引用.ASP.NET?頁面被首先轉換成中介語言(?Intermediary?Language)，然后再被?中介語言及時編譯器(just-in-time?IL?compiler)編譯，最后運行于公共語言運行環境中，并且?ASP.NET?提供了頁面的緩沖，所以，其運行速度要遠遠快于ASP。
大體上，兩種架構所使用的表示層的技術非常類似，雖在細節上各有所長，但總體功能當在伯仲之間。
4.數據訪問
J2EE?和?.Net?已不同的形式支持數據的訪問。JDBC和ADO一樣和所連接的數據庫無關，并且通過連接，命令語句和結果集來對數據進行操作.所以屬于中間層次的?API.更高一級的數據封裝和數據管理是通過實體EJB?(entity?EJB)來完成的.基于容器管理的實體EJB使開發更快捷，管理更方便.事實上，由于實體EJB的load()和store()方法的同步機制，將大大緩解因并發而使數據庫產生的瓶頸.也可以采用不屬于J2EE規范的第三方數據訪問工具，象WebGain的?TopLink。
而微軟的.NET的數據訪問工具則由基于XML的ADO.NET代替了基于COM組件的ADO.任何以XML為輸出的數據源都可以作為?ADO.NET?的數據源.相應的結果集升級為數據集?(DataSets)，命令語句則升級為數據集命令(DataSetCommands).從形式來看，微軟的ADO.NET更新潮和時髦一些，基于XML的特性使其可以處理極其豐富的數據源，并且，因其構架在HTTP協議之上，易于穿透防火墻，使溝通更為便利.但由于XML本身的基于標記的特性，很明顯限制了在有超大數據量和有網絡瓶頸的應用中的使用.而J2EE的數據訪問規則則顯得略有單薄，但同時卻更簡單，更有效.并且通過對應用程序有效的層次的設計，對于數據庫和基于XML的數據源的訪問，也是可以無縫的整合的。
三.整體評價
在微軟還沒有足以和Java平臺相對抗的產品的時候，微軟所樂于做是大聲的宣傳:"write?once，?debug?everywhere"。而它的對手則更樂于這樣評價它:"微軟開始也喜歡Java，他們喜歡它的方式是讓它死去，他們當然也憎恨它，他們甚至憎恨每一個以J開頭的單詞。"但是現在，形式不同了，微軟有了足以自豪的.NET他們可以已他們自己所喜好的方式來對J2EE和.NET來做各種比較。最熱鬧的應該算是微軟出示的第三方對.NET?Pet?Shop和J2EE的?Pet?Store的綜合比較了.有興趣的讀者可以到MSDN，，IBM開發者原地等網站看到相關評論。
bsp;?J2EE?.NET?
易用性?**?***?
擴展能力?***?**?
多平臺支持?****?*?
多語言支持?*?****?
可靠性?***?***?
性能?***?***?
可管理性?***?***?
重用性?****?**?
負載平衡?***?***?
開放標準?*****?*
就企業而言，內部眾多系統的整合、系統的延展性、安全性是更需要注意的議題，而這些都是J2EE的優勢，也是微軟的不足處。?在效率方面，J2EE陣營主張通過硬件的效能增加來彌補軟件的不足.開放標準，功能強大，易于移植這些都是J2EE的賣點。但讓人奇怪的是IBM的WebSphere和BEA的WebLogic在J2EE市場占了大半壁江山，而作為規則制定者的SUN卻在做壁上觀。
微軟確實提供了從桌面的辦公軟件，開發工具，到后臺服務器數據庫的全方位的產品。?但統一平臺的使用者可能要犧牲跨平臺的好處，并也有可能由此就被無窮無盡的鎖定在微軟的許可證的汪洋中.更簡單，更快捷，更高效是微軟的目標，隨著時代的發展，我們也許會看到更完美的技術解決方案。
相比較于標準鎖來說，增加一點工作量即可提高 SpinLock 的性能。但需注意的一點是，SpinLock 比標準鎖更耗費資源。您可以使用分析工具中并發分析功能，查看哪種類型的鎖可以在您的程序中提供更好的性能。有關更多信息，請參見并發可視化工具。C#VBclass SpinLockDemo2 { constint N = 100000; static QueueData _queue = new QueueData(); staticobject _lock = new Object(); static SpinLock _spinlock = new SpinLock(); class Data { publicstring Name { get; set; } publicdouble Number { get; set; } } staticvoid Main(string[] args) { // First use a standard lock for comparison purposes. UseLock(); _queue.Clear(); UseSpinLock(); Console.WriteLine("Press a key"); Console.ReadKey(); } privatestaticvoid UpdateWithSpinLock(Data d, int i) { bool lockTaken = false; try { _spinlock.Enter(ref lockTaken); _queue.Enqueue( d ); } finally { if (lockTaken) _spinlock.Exit(false); } } privatestaticvoid UseSpinLock() { Stopwatch sw = Stopwatch.StartNew(); Parallel.Invoke( () = { for (int i = 0; i N; i++) { UpdateWithSpinLock(new Data() { Name = i.ToString(), Number = i }, i); } }, () = { for (int i = 0; i N; i++) { UpdateWithSpinLock(new Data() { Name = i.ToString(), Number = i }, i); } } ); sw.Stop(); Console.WriteLine("elapsed ms with spinlock: {0}", sw.ElapsedMilliseconds); } staticvoid UpdateWithLock(Data d, int i) { lock (_lock) { _queue.Enqueue(d); } } privatestaticvoid UseLock() { Stopwatch sw = Stopwatch.StartNew(); Parallel.Invoke( () = { for (int i = 0; i N; i++) { UpdateWithLock(new Data() { Name = i.ToString(), Number = i }, i); } }, () = { for (int i = 0; i N; i++) { UpdateWithLock(new Data() { Name = i.ToString(), Number = i }, i); } } ); sw.Stop(); Console.WriteLine("elapsed ms with lock: {0}", sw.ElapsedMilliseconds); } } SpinLock 對于很長時間都不會持有共享資源上的鎖的情況可能很有用。對于此類情況，在多核計算機上，一種有效的做法是讓已阻塞的線程旋轉幾個周期，直至鎖被釋放。通過旋轉，線程將不會進入阻塞狀態（這是一個占用大量 CPU 資源的過程）。在某些情況下，SpinLock 將會停止旋轉，以防止出現邏輯處理器資源不足的現象，或出現系統上超線程的優先級反轉的情況。此示例使用 System.Collections.Generic.QueueT 類，這要求針對多線程的訪問進行用戶同步。在以.NET Framework 4 為目標的應用程序中，還可以選擇使用 System.Collections.Concurrent.ConcurrentQueueT，這不需要任何用戶鎖。請注意，在對 Exit 的調用中使用了 false（在 Visual Basic 中為 False）。這樣可以提供最佳性能。
首先，你應該理解.net是一個新的平臺，微軟喜歡把.net和COM+結合起來，.net有優秀的、強大的與COM+交互的能力，但是它更是有效的、全新的平臺。這就意味著它有自己的強項和弱點。P title="" P Server（MSMQ）的替代品，所有當你超出簡單的ASP.net應用程序時，.net就不能單獨勝任。 Queue Message Server（MTS）或者Microsoft Transaction 第二點，因為它的不成熟，為了交付一個完整的.net方案，至少現在你需要把.net和COM+組合起來。例如，在.net中，現在還沒有Microsoft XMLns:fo=""P title="" P XMLns:fo="" Services概念就想使用.net平臺技術，其程度超過你沒有學習面向對象概念就想開始面向組件編程。 Services緊密地連接在一起。你不能不了解Web 最后一點，.net和WebJavascript:openWindowRes('DotNetMagazine/2001_12/WhereItIs/Figure1.ASP');"The .net Adoption Timeline/TABLE從發布方面來說，IT從業者應該知道什么？
記住，這是1.0版本，這不是Visual Studio 7.0；這不是COM++++；這不是Visual Basic 7.0。十分確切的說，這是全新的。它和大量的新代碼一起引進。你要特別仔細考慮如何計劃.net的采用。特別是在以后的24個月里。P title="" P XMLns:fo="" one做地更好。 然而，它里面包括許多很酷的東西。它彌補了和Java之間的巨大差距，在許多情況下，被證明比Java你對企業什么時候或者是否轉向.net有什么建議？
這是一個什么時候將他們拖、拉、或者尖叫著穿過.net的懸崖的問題，而不是是否需要穿過.net懸崖的問題，不管他們是否愿意。然而，我不希望看見許多人試圖一次重寫他們的所有的Visual Basic代碼或者Visual C++代碼。我們應該逐步的開展。.net將很快被引用到新的開發中。在Visual Studio .net出現的頭一兩年，你將會看到一個混合模型，新開發的代碼中30％的將是ASP.net代碼（我預見ASP.net的擴展將會非常非常之快），但是70％將仍然是COM，COM+代碼。商業應用
Javascript:openWindowRes('DotNetMagazine/2001_12/WhereItIs/BusinessCase.htm');"計劃向新技術轉移
由于.net的許多優勢和微軟的強大的市場努力，.net技術在應用程序開發中最終將被廣泛采用幾乎是可以肯定的，特別是對于中小型企業....
/TABLE我對嚴謹的客戶的一般建議是，不要把有緊急任務的應用程序在很大程度上依賴于.net，至少在.net發布后六到九個月不要這樣做，即2002年8月之前。P title="" P XMLns:fo="" 然而，為了實踐的目的，你可以用.net做一些小的原型，一些沒有緊急任務要求的程序。這取決于beta代碼，第一個產品版本，或者第一個服務包能為你帶來些什么。盡管如此，我們推薦你采取保守的方法。假設一個糟糕的情況：你的30%-40%代碼將遷移，你將不得不重寫或者重設計剩下的代碼。別指望微軟會提供自動工具來遷移你的代碼。對早期的采用者也有一些好的原因。首先是顯示公司在Web Services策略方面的競爭力，你正在尋找在接下來的12個月里支持Web Services最好的平臺。P title="" P XMLns:fo="" ASP.net是另一個原因。太多的程序員從事ASP的開發，如果你正在ASP執行或者安全方面苦苦掙扎，或者受夠了整個ASP的生存空間。ASP.net是一個更強大的環境。實際上，微軟已經有了大量的早期采用者，他們已經在ASP.net系統的測試版下開發。P title="" P XMLns:fo="" 還有，最重要的是，如果你有一個真正的商業原因，你就應該早點采用。例如，如果你正在開發一個無線的應用程序，ASP.net有一些重要的新特征正好可以幫你實現，在許多情況下，冒險早期遷往.net是因為它在移動和無線設備方面做得更好。如果你不關心Web Services，這里沒有一個無可抵抗的和強制性的原因，讓你去很快地采用它。實際上，這就是我們說為什么大多數公司將采用一個相當漸進的曲線來采用它。有許多因素要考慮。要看多少人采用這種主流技術。要參考專家的建議。要看第三方的支持、前景市場的支持。要看本地的.net服務的組件提供者。要看所有的測試公司。要看源代碼管理公司的提供。Visual Studio .net發布的第一年，早期的采用者將會把他們的代碼按70/30的比例劃分在舊平臺和新平臺上。在大約一年半后，我們期待比率會變成30/70。你將看到70％的本地.net代碼將出現在基于微軟的解決方案中。傳統的公司將在Visual Studio .net發布后的24到36個月開始遷移。大約2005年，我們將期待95％的本地.net開發。讓我們來討論.net語言和在遷移應用程序到.net的過程中起作用的部分，從Visual Basic .net開始。
這是一個好消息，Visual Basic 變成了一種成熟的語言。它開始面向對象設計，使用類框架和.net中的其它零碎，VB.net已經變成了一個更強大的工具集。事實上，還沒有哪些商業應用程序不能用VB來實現。P title="" P XMLns:fo="" Basic開發者將有一個艱難的學習過程才能最后完成遷移。 不利的是VB.net有了許多新的語法和設計問題。這意味著對Visual我認為在接下來的48個月中，60％或者更多的C++開發者將轉向C#.C++將仍然會使用。它將會使用在COM和COM+領域，甚至在.net中它將仍然會被使用，但是它將仍是系統層的編程語言。C#的快速開發應用程序的能力和C#和.net組件模型集成工作的能力將會起到一個大的作用。這是我從用戶那兒聽到的最多的問題。我可能今年與八九百人討論過，幾乎一半的問題都是直接地或間接地關于.net與Java相比較的問題。我告訴他們我認為Microsoft和Java將支配電子商務應用程序開發，也就是說，大多數新的項目將會基于這兩個平臺之一。他們到2005年將占有80%的市場。誰也不會。大多數大公司將會兩者都使用?，F在，Java基于它的跨平臺的能力，在大公司中還有很強的實力。小公司不能負擔得起使用兩者，他們將會轉向其中之一。微軟因為它的成本低和眾多的開發者，對中小型組織還是很有吸引力的。為了完成.net難題還需要做什么？
中間件架構應該被拿走。我們需要MTS的替代品。我們需要一個與本地.net同步的messaging broker。更有效的是，我們需要作為本地.net服務的COM+的替代品。當然。你已經有了數據庫APIs和類似的功能。但是我們需要的是Java 2平臺、J2EE在.net上的替代品?，F在，如果你仔細看那些零碎功能的話，我們已經有了一半了。有一個清晰的Java 2平臺、標準編輯器(J2SE)的替代品，不久我們就會有Java 2平臺、J2ME的替代品—J2ME與.net Framework緊密相關。但是，微軟還沒有建立一個真正的J2EE的替代品。我們需要看到.net技術注入SQL Server，這在SQL server的下一個主流產品Yukon中將會看到。我們需要看到各種.net技術，像BizTalk，具有諷刺意味的是，它現在還什么都不能做。微軟的門戶網站，電子商務軟件，所有的零碎東西都需要在.net上執行。他們需要整合將被淘汰的技術。你提到了Web Services的重要性，那我們將會先看到哪種類型的Web Services呢？
我前面提到大多數公司將會同時使用Java和微軟的技術。Web Services是一個很好的方法來整合它們并使他們可以交互操作。我們認為Web Services在移動基于所有權信息方面起著相當重要的作用。P title="" P XMLns:fo="" Services的問題，就象其它問題一樣，還很不成熟。實際上，現在整個XML消息的概念還極不成熟。我們現在只有所有的5%或者10％，我們最終需要全部的XML基礎。 WebP title="" P XMLns:fo="" Services將是一個文化問題。企業將不得不適應系統開放的思想和實時工作的思想。好消息就是有了許多用B2B的基礎。一些特別縱向聯合的企業已經大規模地采用這種方式。 我認為抑制在公共的互聯網上使用Web我認為在使用這項技術時仍然缺少技巧。許多開發者將把Web Services當作分布式對象模型一樣執行。他們將說“好的，Web Services僅僅是包裝了DCOM或者COM組件和Enterprise Java Beans組件，”，這是不對的。Web Services是松耦合的、異步消息協議，而不是鎖定的、同步機制。人們第一次將不可避免的犯錯誤。P title="" P XMLns:fo="" Services將不會變成主流。 Services會有很好的前途，它會是無處不在的相當廉價的服務通訊機制。不管這些服務是在一個子系統，一個企業、跨越一個行業內，或者甚至跨越不同的行業。你可以減少進入這個商業領域的障礙。但是這些好處將不得不和組織結構帶來的新問題相比較。這樣，我們認為2003年之前的這段時間，Web 你可以相信Web這是現在Web Services的一個大黑洞。我們還沒有看到任何好的定價模式。我認為我們將會看到，在某種程度上，小的付款模式將會一點點出來。但是還沒有回答大的付款模式的例子。你知道，我把HailStorm看作是一個大的、具體化的Web Services的例子。然而現在我聽到大量的反對聲，因為它是微軟的。人們認為這是微軟控制互聯網的“Phase II”。我相信如果它不是從微軟而是其他的公司，HailStorm將會直接受到大家的歡迎。讓我驚訝的是，如果AOL或者和它的合作伙伴不提出和HailStorm長期競爭力的產品。我相信它會成功。我認為人們非常關注的電子商務將會有同樣縱向聯系的市場。已經轉向電子商務的行業將會是第一個使用Web Services的行業。它是下一個邏輯革命。/A
在VB中怎樣獲取WINDOWS打印機里的打印隊列里的內容
如果想得到各打印作業的狀態，通常我們可以通過調用以下API:
OpenPrinter
GetPrinter
EnumJobs
ClosePrinter
目前在微軟的網站上沒有現成的關于以上API調用的VB代碼，但有一篇VC的示例代碼，您可以參考一下：
HOWTO: Get the Status of a Printer and a Print Job
（）
另外，您還可以試一下ADSI中的IADsPrintQueueOperations和IADsPrintJobOperations接口。具體信息您可以參考以下文檔：
