关于WCF、WebAPI、WebService之间的区别总结 分布式通信技术(Distributed Communication Technologies)浅析

关于WCF、WebAPI、WebService之间的区别总结
分布式通信技术(Distributed Communication Technologies)浅析

早在1996年Gartner就前瞻性地提出了面向服务架构的思想(SOA),SOA 的走红在很大程度上归功于 Web Service 标准的成熟和应用的普及。 Service Oriented Ambiguity 中文一般理解为:面向服务架构,简称SOA,这个概念算得上微服务的鼻祖了。 SOA 的提出是在企业计算领域,就是要将紧耦合的系统,划分为面向业务的、粗粒度、松耦合、无状态的服务。服务发布出来供其他服务调用,一组互相依赖的服务就构成了SOA架构下的系统。 SOA 本质上是服务的集合。 在分布式通信技术选型中,就本人曾经使用过的基于微软平台的分布式通信进行概述,先明确一下分布式框架的三个基本需求:
  • 客户端: Web、Android、IOS、跨平台(Java 开发的系统和.NET 开发的系统可以通信)
  • 服务端:部署在Windows、Linux
  • 合约(Contract):传递的格式(REST,Json、SOAP、XML)、通信协议(HTTP、XML-RPC、TCP)、消息超时设置、消息包大小
要打造分布式平台,各家技术栈多有不错的实践,这里重点说一下微软技术栈下,丰富的技术选型:
  • .NET Remoting (15年前技术,目前已经失传)
  • Web Service (ASMX, ASP .NET Web Services,15年前技术,维护项目依然存在)
  • WCF (Windows Communication Foundation,10年前技术,维护项目中比较多)
  • Web API (5年前技术开始火起来,和跨平台需求密不可分,最近3年的新需求大部分迁移在这里了)
下面展开来说:

.NET Remoting

是2.0时代的产物, 即2004年的技术,我还没有机会实战过。在微软Roadmap中已被WCF取代(.NET Remoting做得到的事,理论上WCF都可以实现) 依据微软一份,WCF在效能上比ASP.NET Web Service快了25%-50%,比.NETRemoting快25%,弃.NET Remoting改用WCF将有性能能上的突破。 详见报告链接

Web Service

在很早前开发WebForm ASP.NET中用的比较多,因此可以将 Web Service 理解为一个基于 HTTP 协议开发的上层应用程序 Web service 是一个平台独立的,低耦合的,自包含的、基于可编程的 Web 的应用程序,可使用开放的 XML(标准通用标记语言下的一个子集)标准来描述、发布、发现、协调和配置这些应用程序,用于开发分布式的互操作的应用程序。 Simple Object Access Protocol,中文为简单对象访问协议,简称 SOAP。
1、它是基于SOAP协议的,数据格式是XML (SOAP )

2、只支持HTTP协议

3、它不是开源的,但可以被任意一个了解XML的人使用

4、它只能部署在IIS上 

SOA 不是 Web Service,Web Service 是当年最适合实现SOA的技术。

WCF

WCF是取代Web Service及.NET Remoting的接班人,我记得这个是微软2010年开始力推的技术。 我第一次是用WCF是2012年,做一个电信级项目,结合微软吹水的Silverlight技术(Silverlight技术,2013年底该技术被微软安乐死了,again!)
1、这个也是基于SOAP的,数据格式是XML

2、这个是Web Service(ASMX)的进化版,可以支持各种各样的协议,像TCP,HTTP,HTTPS,Named Pipes, MSMQ.

3、WCF的主要问题是,它配置起来特别的繁琐!!! (此处特别强调了3个感叹号 )

4、它不是开源的,但可以被任意一个了解XML的人使用

5、它可以部署应用程序中或者IIS上或者Windows服务中

WCF门槛有些太高,仅仅在Windows平台开发,而且配置文件比较复杂(WCF 客户端\WCF 服务器端,仅Binding、Behavior的复杂度就能单独写一篇文章,踩过不少坑,都是泪。) 众所周知,微软.net技术未来是.netCore,成熟的.NetCore3 2019年底就可以应用于生产系统了, 但多年来微软一直拒绝将WCF 的服务器端移植到.NET Core, 导致这个分布式技术,面临的极大的技术瓶颈,即若干年后几无可用人才来维护WCF项目,所以大约3年前开始,我知道周围朋友公司的新项目大都避而不谈WCF了。

ASP.NET Web API

随着SOAP 逐渐淡出,RESTful大行其道, Web API火了起来。 微软技术栈的工程实现是 ASP.NET Web API,而且微软建议使用 ASP.NET Core Web API 或 gRPC,它们提供基于跨平台和跨编程语言的 RPC,也能使用 gRPC 来编写代码,并替换掉一些 WCF 服务器服务。
1、一个简单的构建HTTP服务的新框架

2、在.net平台上Web API 是一个开源的、理想的、构建REST-ful 服务的技术

3、不像WCF REST Service.它可以使用HTTP的全部特点(比如URIs、request/response头,缓存,版本控制,多种内容格式)

4、它也支持MVC的特征,像路由、控制器、action、filter、模型绑定、控制反转(IOC)或依赖注入(DI),单元测试。这些可以使程序更简单、更健壮

5、它可以部署在应用程序和IIS上

6、这是一个轻量级的框架,并且对限制带宽的设备,比如智能手机等支持的很好

7、Response可以被Web API的MediaTypeFormatter转换成Json、XML 或者任何你想转换的格式。

WCF 的未来是Web API,而且微软2014年推出开源.NetCore中就有ASP.Net Core Web API,可见重视程度。

分布式技术这么多,我该选谁?

都2019年了,新项目肯定是WebAPI,原因如下:
WebAPI只要有能力发送HTTP Request跟解析JSON,比较符合微服务要求, 跨平台支持。

创建一个基于HTTP的面向资源的服务并且可以使用HTTP的全部特征时(比如URIs、request/response头,缓存,版本控制,多种内容格式),你应该选择WebAPI

让你的服务用于浏览器、手机、iPhone和平板电脑时,你应该选择Web API

双工消息模式,过SignalR和WebSockets整合(创建一个支持消息、消息队列、双工通信的服务时)

微软.Net Core 3.0 预览版 7 发布:大幅减少 SDK 空间大小

这个预览版是 .Net Core 3 中重要的版本,可以视为原计划在 7 月发布的 RC 版本 (引自微软 .NET Core 首席 Program Manager Richard 先生原话),故可在生产环境进行开发和部署。

据悉,这个预览版是 .Net Core 3 中重要的版本,可以视为原计划在 7 月发布的 RC 版本 (引自微软 .NET Core 首席 Program Manager Richard 先生原话),故可在生产环境进行开发和部署。 Windows, macOS 和 Linux 版本的Download .NET Core 3.0 预览版 7 下载地址如下: 与此同时,ASP.NET Core 和EF Core 实体框架 也同于同一天发布。 针对 .NET Core 3.0 预览版 7 的新特性,Visual Studio 用户需要在 Visual Studio 2019 16.3 预览 1 中使用。 Microsoft .NET 站点已更新为.NET Core 3.0 预览版 7(请参阅网站页脚中提示 Powered by .NET Core 3.0.0-preview7-27912-14)。 且该站点已经在预览 7 上正常运行了两周多。 微软声称可能会在几周内将 Microsoft .NET 网站迁移到.NET Core 3.0 预览 8 版本。 另外,开发团队正在努力确保与 .NET Core 1.x 和 2.x 应用程序的高度兼容性,从而可以直接将现有应用程序快速升级到 .NET Core 3.0 版本。

.NET Core SDK 大小精简

使用 .NET Core 3.0 的 .NET Core SDK 要小得多。 主要原因是改变了构建 SDK 的方式改变,转而使用各种特定的“包”(引用程序集,框架,模板)。 在以前的版本(包括 .NET Core 2.2)中,我们使用 NuGet 包构建了 SDK,其中包含许多不需要的引用,导致浪费了大量空间。 您可以在.NET Core 3.0 SDK Size Improvements如何计算这些文件大小。 文章提供了详细说明,以便在自己的环境中运行相同的测试。 .NET Core 3.0 SDK 大小(括号中标注了大小更改)
操作系统安装包大小占用磁盘大小
Windows164MB (-440KB; 0%)441MB (-968MB; -68.7%)
Linux115MB (-55MB; -32%)332MB (-1068MB; -76.2%)
macOS118MB (-51MB; -30%)337MB (-1063MB; -75.9%)
Linux 和 macOS 的大小改进是令人惊奇的。 Windows 的改进较小,因为我们已将 WPF 和 Windows Forms 添加作为 .NET Core 3.0 的一部分。 令人惊讶的是,我们在 3.0 中添加了 WPF 和 Windows Forms,并且安装程序仍然(稍微)小一些。 您可以通过.NET Core SDK Docker映像包看到改进也不错(此处仅限于 x64 Debian 和 Alpine)。
发行版2.2 压缩大小3.0 压缩大小
Debian598MB264MB
Alpine493MB148MB
.NET Core 3.0 版本即将完成,故不再构建新功能,因此团队专注于稳定性和可靠性。 请尽快通过 Github 告诉开发团队您发现的任何问题,这样在发布 3.0 版本之前尽可能多地修复问题。

风生水起:我用过的IM工具

p>    不同的企业,有不同的文化,也有不同的沟通方式。

  1. QQ: 2000年开始使用,95%的联系人是见过面的人(约10%是同事)clip_image002 中国最火的IM,没有之一,据说用户数超过7亿。尤以其QQ群、QQ空间、QQ微博、QQ游戏等一系列附加值著称。QQ的模式,在 IT业内算是一个标杆: 主业务不挣钱,大把大把的投入资源;而附属业务则实现了火箭般增长。据说QQ公司内的创新文化是3~5个人,2个月的DIY小项目,可获公司层立项,从而快速出demo,抢占市场。正是因为这样灵活的研发策略,使得QQ这个小企鹅10年来,依旧强健无比。
  2. MSN:2005年开始使用,90%的联系人是同事。clip_image004 当年,可以说MSN属于北、上、广;外企的“标配”。“高端、大气、上档次”,其登录的立体小人非常cool,登录过程还要360度转几圈。MSN辉煌的时代,真实微软在IT业内独占鳌头的时代,一家独秀。然,微软2012年宣布,2013.4月使得MSN安乐死了—微软为了力挺其12亿美金收购的SkyPe权威地位。 故MSN目前只能算是一个历史记忆了。
  3. Skype:2007年开始使用, 联系人很少( 2012年底从MSN倒过去了几十个)   clip_image006   刚开始使用的时候,它还没有被微软收购。其有2个优点:语音聊天、拨打电话。Skype目前是微软旗下的王牌IM,为了它的市场布局,微软自宫了MSN,不过,目前不太火。 其未来发展得看Win 8.1和WP 8.1市场的推进。
  4. 飞信:2007年开始使用,90 %的联系人是同事 (移动电信行业IM标配)。clip_image008 刚开始是因为能够免费发短信(移动手机注册),这个功能非常让人兴奋。 再后来,因为做的项目是移动的,故同事、客户90%以上选择了飞信用来沟通。故,飞信对我而言,属于每天必用的软件(2009年到2013年)。
  5. GTalk:2008年开始使用,日常的联系人约10人(截止2012年底)。clip_image010最近几年年,GTalk火了起来,可能是随着Google Android系统的内置Gtalk吧。但从用户体验上看,它比飞信、MSN、QQ要“差”–至少登录UI掉渣级的土;传文件、传图片等常用功能也不尽如人意。 

但随着时间推进,我发现Gtalk好像还有一些优点:

  1. 聊天记录:因为“三屏一云”后,多个终端通过GTalk聊天,能够浏览完整的聊天记录,且不用付费,这,确实很爽。而同样功能QQ是要收费的。
  2. Google Group:接触邮件组,是在2006年,那个时候公司内部好像还很流行。但是随着组织的急剧扩张,导致出现内、外部大量的群发邮件。后来公司某个政策出台,解散了邮件组这种形式。那个时候的印象是:邮件组很土。   而随着最近2年西安软件园的一些活动,我订阅了3个邮件组,发现这个玩意有它的优点:免费保存记录,熟人圈子等。
  3. Gmail邮箱:使用Gtalk的,一般都有对应账号的Gmail邮箱。这个功能确实比较酷,IM和邮箱实现了彼此的互补。 如,IM实现短、平、快;邮件辅助实现:长、博、稳。
  4. 日历提醒: 整合了时间管理的元素。如预定会议,某某重要的事情提醒等等。

总结:上述的5个IM工具,没有绝对的好坏、黑白之分。 相反,同质化好像日趋明显了。 如,凡是其他IM有的功能,QQ未来也会有。仅从中国市场看,QQ的生态圈子最好的,其市场很强:小马哥通过它美美的挣了很多钱!

Silverlight 点点滴滴

p>SL, RIA,即不仅仅是普通的层三架构的web系统。SL前台呈现,调用后端查询数据库传递,更多的东西可在前端,如浏览器实现更多的动作,xap包都下载到本地了,用户会默认安装SilverLight runtime,近似CRL的东西。

一个基于Silverlight的model至少由3个部分构成:

前段,一个SilverLight工程,生成xap包,

通信,一个WCF工程,生成dll

后端,一个class Library,生成dll

为了启动1个这样的model,你需要有一个web host(宿主程序),即asp.net web应用程序,他会生成对应的一个silverlight的defaul.asps文件, 部署在IIS上后,用户点击Http://192.168.1.1/SL_demo则打开的这个defaul.asps,故而第一次,用户通过IE浏览器,把你的SilverLight xap下载本地,启动了SL页面。

对于企业应用级别的SL借鉴方案,一般有10几个开发人员在做model,怎么把这些model组织为web site的菜单项,可以实现不同的region区域:固定展示log的region,展示当前用户信息的region,展示导航树的region,展示主工作区间的region。

需要采用插件架构,如Prism简介, 详细的可看这一系列blog:

*****************

  • MVVM:binding everything 一种新的思维,数据和UI交互的新思维。 MVVM
  • 页面代码分离:asp.net思路。 xaml+xaml.cs文件组成前台用户看到的内容。 Xaml里面写页面元素,如Grid、textBox, cs里面写具体逻辑代码(实际上,如果完全通过上面的MVVM实现逻辑,则这个cs文件里面写的代码少得很)
  •       其项目编译后对应为xap文件(zip压缩文件,方便用户网络下载)

  • 前端,只能引用添加Silverlight项目、WCF引用,必须引用SilverLight类库(当添加非SL的,则Visual Stuido会报错提示)。
  • UI组件采用的是成熟的Telerik,主要用了其GridView、TreeView、Chart、RickTextBox、RadButton等。
  • 后端,普通的class Library项目即可,同以往的.net应用程序没有任何区别。
  •   WCF: 前段和后端通信的桥梁,写一个专门的WCF工程(位于后端),可直接调用后端的Class Library。 前段和后端通信,就靠这个了:前段传递数据给后端, 后端返回数据给前段。

  • 前后台怎么复用代码方法:
  •       通过添加WCF引用,会自动生成Entity的代码,在reference.cs文件里面

    通过链接类、条件编译方式,可以实现前、后端代码级别复用,这种办法,效率非常高。

  • 几个现金陷阱:

陷阱一:泛型传递

泛型是在编译器确定了数据类型,而WCF仅仅是XML封装的接口,如果发布了一个T的接口,那么使用者使用,谁编译WCF接口? 怎么编译WCF? 所以,不行的。

陷阱二:object传递: 基类、子类传递。参见上面说的基本类型,如果一个数据的calss,没有添加标签封装,WCF会报错的。

陷阱三:DataTable传递

典型的ADO.net思想,还停留在windows桌面应用系统领域, JSON、byte[]才是WCF\SL的王道。

主要因为,你引用DataTable的System.Data类库,在前段不可见(前段相对后端裁剪了很多,更轻巧)。 如果你实在要这么做,推荐一个开源的SL.DataTalbe给你,需要源码的发邮件给我。

如果数据流大,可通过byte[]方式通信,在后端序列化为byte[],WCF传递给前段,(上篇写过,前段可通过链接类、条件编译复用后端代码:类变量、类方法), 前段可反序列化为实体类。

在多年单机版思路,几年前转换为Client-Server开发思路模式。 最近的2年往Brower-Server开发模式转变,同时也兼顾Windows Phone移动端思路吧。

[译] 开发者角度,王道之论:Android 与 Windows Phone

前几天,在codeproject搜索Silverlight资料,偶然看到这篇文章,耐心读了2遍,非常不错:文章通过访谈聊天形式叙述,2位主角目前在《斯法克斯国家工程学院》软件学院上学。

周五晚上,我给作者Houssem Dellai发gmail,咨询能否授权我翻译为中文,并发布。 3个小时后,他很爽快的回邮件说没有问题,给我一个原文链接就行。

英文原文地址: Android vs Windows Phone

———————————————————————————————————————————

作者目前在突尼斯,属于非洲北部一个小国家,人口1000万左右,约西安市人口的规模。

自我介绍

大家好,我是Houssem Dellai: 一名Windows Phone 开发者(译:他曾多次参加突尼斯Windows Phone编程挑战赛并屡屡获奖,且已获得微软Windows 8认证)。我身边的这位是我的同学Zied Jaballah: 他是Android 开发者 (译: 他已有3年Android开发经验).

我们一起曾在droidcon conference in tunis中做了一个session分享:从开发者的视角分别就Android和Windows Phone移动终端开发平台的几个方面问答。

Android和Windows Phone PK:

首先,我们通过应用商店,即一个移动终端开发者如何挣钱这个话题展开讨论;紧接着又讨论了手机终端支持情况。 然后,对IDE集成开发环境进行了分析: Visual Studio和Eclipse. 再然后,讨论了开发者最关注的模拟器。最后,我们又讨论了Google和微软对UI设计的规范要求。 结尾部分,又聊了一下平板电脑的话题。

1 – 应用商店

Houssem: 首先,让我们从应用商店开始讨论吧,看看Google为开发者做了些什么?

Zied: Google的应用商店叫 Google Play, 目前包含了近百万的app应用, 全球下载次数超过250亿次以上。那么,Houssem, 微软应用商店的情况如何?

Houssem: Windows Phone 应用商店目前有超过13万应用app. 虽然在数量远远不如Android商店的庞大, 但是,你可以找到你需要的所有应用app程序。

Zied: 开发者如要在google商店发布Android应用, 首先需要拥有一个 Google Play账号,申请注册费用为25刀。 那么,开发者申请一个微软的商店账号,需要多少钱?

Houssem: 在微软商店发布应用,有2类不同账号:开发者账号,需要49刀;还有一个是企业账号,需要99刀的费用。

Zied: 为了在Googe Play商店发布你的应用,你必须要通过Google的验证审核,这个过程很快,大约需要15到30分钟。 那么, 微软的应用审核策略呢?

Houssem: 微软商店的审核大约需要5天时间。 如果你的app被拒绝,你同样会受到一个审核错误报告,微软会告之你如何改进。 Zied! 我注意到你的PPT中提到了’恶意软件’ ?!!

Zied: 是的, 这不是笔误。Google play商店良莠不齐,有很多恶意软件, 这个可能是因为审核过程过快,且 Android开发者群体数量庞大导致的。 事实上,google已经认识到这个问题的严重性,并且出了一个新政策,它参考了微软和苹果的做法,即通过应用的使用反馈情况来代替审核制度,如:Google允许你发布你的应用app, 然后它会扫描app是否属于恶意软件。 在今年2月,Google创记录的从应用商店下架了6万款应用程序。

Houssem: 感谢上帝,在Windows Phone商店,你不会受到恶意软件侵扰,她值得信赖。

2 – 手机终端

Zied: Ok, 我们现在讨论手机终端吧。你知道Android阵营拥有数量庞大的终端吗? 这些是为数众多的手机厂商生产的,如我们耳熟能详的三星、LG、摩托罗拉等。(译:还包括HTC和华为、中兴) 这些手机终端,纵横了低端、中端、高端市场的不同的用户需求。那么Windows Phone手机的情况如何?

Houssem: 拥抱Windows Phone的手机厂商有诺基亚、三星、HTC、LG等等(译:还包括华为、中兴)。微软出于想给消费者以最佳体验品质,故对硬件比较挑剔, 所以,目前市场上的终端的售价都较高。

3 – 集成开发环境(IDE)

Houssem: 截止现在,我们讨论应用商店和手机终端, 下面接着讨论一下集成开发环境(IDE)吧。为了开发Windows Phone 8程序,你需要安装Visual Studio 2012,如免费的Express版。 那么Zied, 谈谈Eclipse吧?

Zied: Eclipse是Android程序员使用最多的IDE,免费且开源。呵呵,最重要的是,它没有太多的需求。( Zied望着Houssem乐了一下 :P ).

Houssem: 对于要通过VS 2012来开发WP8应用程序,确实对运行环境比较挑剔,或者说稍微有点困难吧。如,VS 2012要求操作系统和硬件必须达到最低配置:硬件需要支持能够安装虚拟环境; 操作系统的要求是Win 8 专业版或者企业版,Basic版本不支持,更重要的是,要求Win8操作系统是64位的。

Zied: 那么对你来说,能够满足WP8开发的必备条件, 你算是很幸运了。 但是, 对于Eclipse 来说,则更幸运:压根就不挑剔操作系统和硬件环境。 如,你只需要安装JVM虚拟机即可。事实上,只要能够安装JVM虚拟机,程序员可以在Windows、Mac、Linux等任何操作系统下用Eclipse开发Android应用程序。

Houssem: 众所周知,Visual Studio给程序员非常爽的体验,如:调试源码很容易、高效的编程能力、定位错方便误、修复问题非常快等等优势。

Zied: Houssem,在调试源码这一点上你获胜了, Visual Studio的的确确在调试上把Eclipse远远甩在后面。 但是,我更喜欢Ecipse数量众多的插件,通过这些插件的配合,你可以做得更出色。那么,VS有插件吗?

Houssem: 插件,Visual Studio当然有啦! VS也有大量的插件,且这些插件大部分开源。 你可以通过VS来搜索不同的插件,安装或升级来扩展Visual Studio的IDE。

4 – 模拟器

Houssem: Ok, 我们接着讨论下一个开发者关注的话题:模拟器.

Zied: Android 模拟器运行的不够快,我周围的很多开发者都饱受其害。但是,Google 对一些新机器,通过类似快照技术加速,目前看效果还不错。 如,这里还有一个模拟器开源项目Android x80, 其运行效率非常高,或许是Google模拟器的可选方案之一吧。让我们看看,微软为开发者在模拟器方面做了些什么?

Houssem: Windows Phone 模拟器运行效率非常高。她采用了hyper-v作为虚拟化环境,所以响应很及时。

5 – UI设计

Zied: Ok, 对比WP8的模拟器,Android确实显得力不从心。那么,微软的UI设计方面的支持情况如何呢?

Houssem: 呵呵, 我很欣赏你的坦率。Windows8采用了一种叫做现代UI设计的新的图形风格。它基于“内容胜过形式”的思路,这也意味着,编程开发者只需要把心思放在编码逻辑上,而不用太多注意主题、颜色、外形等。 这种UI设计有其严格的设计规范,但也有一些可复用的模板和控件,故UI可以被做的很漂亮。 如,作为WP8的程序员或者美工,你将会通过微软的expression Blend设计工具的做出最佳视觉效果。 Blend是一个IDE,专门为美工而生,即美工不用安装VS 这种程序员专属的IDE。 当程序员熟悉这些规则后,他将在一开始的时候不用美工。等程序demo成型后,在考虑美工介入提升UI设计、美化等。

Zied: 在Android这一侧,设计是程序员较头痛的一件事情。 你不得不写大量的XML去调整UI,拖拽的方式调试UI元素效果往往不好。 但是,一旦你精通XML的设计模式,则会爽翻天。Google也有自己的设计规范,只是没有微软这么严格罢了。

截止目前,我们讨论应用商店、IDE、设计规范、手机终端。 下面讨论一下平台电脑情况吧。

6 – 平板电脑

Houssem: Windows tablet平台没有运行WP的操作系统,它运行的是Windows RT,这是一种轻量级的Windows 8操作系统,专为平板电脑设计: 不能运行.exe程序, 仅只能运行Windows商店里面应用程序。但是,另外一种叫做Surface Pro平板可以运行
windows 8操作系统和.exe程序。

我猜测WP8有80%的API和Windows8 API相同。故,你可以很容易的在WP8和Windows 8之间共享代码。

Zied: Android操作系统不仅可运行在手机终端,也可以运行在平板电脑。从Android 3.0开始, Google新增了专门为大尺寸屏幕设计的API,故你可以开发专门适用于平板电脑的应用。其平板应用程序使用起来效果非常好。

总结

一般而言,这种讨论无法一决雌雄。某些方面,Windows Phone占据优势, 另外一方面说,Android获得胜利。至于谁是王者,这取决于你选择采用哪个平台,选择权在你。