扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
这篇文章主要讲解了“WCF性能是怎样的”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“WCF性能是怎样的”吧!
让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:主机域名、虚拟空间、营销软件、网站建设、兴山网站维护、网站推广。
随着时代的发展,Microsoft推出的WCF被我们越来越多的人使用,我们就WCF性能分析一下,设计、构建、维护和版本控制分布式应用时一个复杂的任务。安全性、可靠性、事务性和伸缩性的因素和任务变得更加复杂。因为问题的复杂性,所以WCF被设计来解决这些问题,WCF是相当复杂的技术。为了能看清WCF性能,我把主要的功能分为10个类别:独立版本控制、异步只进消息、平台统一、安全性、可靠性、事务支持、互操作性、性能、扩展性和配置性。
独立版本控制
应用系统版本控制已经成为一个头疼的问题。如我之前提到的,面向组件的设计不能在分布式应用中很好地解决这些问题。任何技术如果在分布式世界里获得认可,必须允许分布式应用的不同部分能够独立的版本控制。遵照WS-*规范,关注WS-*关于消息定义的内容,允许被调用的服务可以再不同速率开发。这些特性不像创建WCF应用的底层原理那么重要,但是我认为这是使用WCF最重要的副产品。
异步单向消息
我们的许多应用是使用请求-响应模式调用功能的。典型的是,我们调用一个功能,然后等待结果返回,然后根据返回结果执行。这种方式在Internet上尤为多见。每次我们请求一个页面,我们必须等待网页的响应。局限我们的条件,大部分分布式应用使用的都是请求-响应方式。尽管开始看起来不自然,对于穿越 IO边界的任务分布式应用,异步只进消息方式是更加高效的方式。我认为这是使用WCF的又一个好处。异步只进消息方式允许使用高效的处理资源,更加方便地使用分布式应用的高级的功能、可靠性和相应能力。
平台统一
过去微软已经发布的很多分布式技术;有些成为WCF诞生的重要的导向技术。并且许多技术依然在使用。例如,在WCF发布以前,微软支持5种主要的分布式技术: RPC, WSE, ASMX, Remoting, COM+, 和MSMQ。过去,***的分布式技术取决于应用系统的需求。例如,假如分布式应用都是基于.NET Framework,那么会选择.NET Remoting,因为它是.NET Remoting应用程序之间一种高效的通信方式。如果一个应用需要担保消息传输和持久化,那么MSMQ是***的选择。两个技术有不同的API、编程方式、操作要求和配置需求。结果,应用程序代码紧密地绑定到这些技术上,这些技术也绑定到特定的功能上。一些新的技术允许我们组合特性,比如事务性和队列性的COM+。只要需求不改变或者不使用其它的不支持的方式,这种模式是可以工作的。
什么是你的应用系统与其他的 .NET Framework应用、非 .NET Framework应用和支持事务的处理通信所需要的?在WCF之前,没有好的选择,本质上讲,这些需求使得开发者要么放弃一个需求要么编写自己的通信技术。与旧的技术相比,WCF能够集成旧的技术特性并且统一为一个编程模型,如表1-1所示。
表1-1 WCF特性对比
Feature | WSE | ASMX | Remoting | COM+ | MSMQ | WCF |
---|---|---|---|---|---|---|
WS-* support | X | X | X | |||
Basic Web service interoperability | X | X | X | |||
.NET -to-.NET communication | X | X | ||||
Distributed transactions | X | X | X | |||
Queued messaging | X | X |
客观地说,WCF性能没有提供给我们无约束连接的特性,但是确实提供给了我们比以更多的连接特性。
感谢各位的阅读,以上就是“WCF性能是怎样的”的内容了,经过本文的学习后,相信大家对WCF性能是怎样的这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流