189 8069 5689
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%的市场。谁也不会。大多数大公司将会两者都使用。现在，Java基于它的跨平台的能力，在大公司中还有很强的实力。小公司不能负担得起使用两者，他们将会转向其中之一。微软因为它的成本低和众多的开发者，对中小型组织还是很有吸引力的。为了完成.net难题还需要做什么？
中间件架构应该被拿走。我们需要MTS的替代品。我们需要一个与本地.net同步的messaging broker。更有效的是，我们需要作为本地.net服务的COM+的替代品。当然。你已经有了数据库APIs和类似的功能。但是我们需要的是Java 2平台、J2EE在.net上的替代品。现在，如果你仔细看那些零碎功能的话，我们已经有了一半了。有一个清晰的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接口。具体信息您可以参考以下文档：