ICE专题:网络服务平台比较

简介:

网络服务平台的比较----ICE应用系列文章之一

 

自从上世纪九十年代以来,计算工业一直在使用像DCOM 和CORBA 这样的面向对象中间件平台。在使分布式计算能为应用开发者所用的进程中,面向对象中间件是十分重要的一步。开发者第一次拥有了这样的可能:不必是一个网络古鲁(guru),就可以构建分布式应用——中间件平台会照管大部分网络杂务,比如整编(marshaling)和解编(unmarshaling)(对数据进行编码与解码,以进行传送)、把逻辑对象地址映射到物理传输端点、根据客户和服务器的原生机器架构改变数据的表示,以及应需自动启动服务器。然而,由于一些原因,无论是DCOM 还是CORBA,都未能成功占领大部分计算市场:

• DCOM 是Microsoft 的独家解决方案,在异种网络中,各种机器会运行多种操作系统,无法使用DCOM。

• DCOM 不能支持大量对象(数十万或数百万),这在很大程度上是它的分布式垃圾收集机制带来的开销造成的。

• 尽管有多家供应商提供CORBA 产品,几乎不可能找到一家供应商,能够为异种网络中的所有环境提供实现。尽管进行了大量标准化工作,不同的CORBA 实现之间仍缺乏互操作性,从而不断地造成各种问题;而且,由于供应商常常会自行定义扩展,而CORBA 又缺乏针对多线程环境的规范,对于像C 或C++ 这样的语言,源码兼容性从未完全实现过。• DCOM和 CORBA都过于复杂。要熟悉DCOM或CORBA,并进行相应的设计和编程,是一项需要许多个月来掌握的艰难任务(而要达到专家水平,需要好几年)

• 在其各自的历史中,性能问题一直在折磨这两种平台。DCOM 只有一种实现可用,所以不可能购买性能更好的实现。而尽管有多家供应商提供CORBA 产品,很难找到遵从标准、性能良好的实现——其主要原因是CORBA 规范自身所带来的复杂性(在许多情况下,其特性都丰富得超出了需要)

• 在异种环境中,让DCOM 和CORBA 共存从来都不是一件容易的事情:尽管有供应商提供互操作产品,这两种平台之间的互操作从来都不是无缝的,而且难以管理,会产生互不相连的技术孤岛。

2002 年, Microsoft .NET 平台[11] 取代了DCOM。但尽管.NET 提供了比DCOM 更强大的分布式计算支持,它仍然是Microsoft 的独家解决方案,因而不是异种环境下的选择。另一方面,CORBA 近年来已停滞不前,许多供应商离开了市场,给消费者留下了不再受到广泛支持的平台;剩下的少数供应商在进一步标准化方面的兴趣也已衰退,致使CORBA 规范中的许多缺陷未能得到解决,或是在它们被报告多年之后才得到解决。在DCOM 和CORBA 衰败的同时,分布式计算社群对SOAP[23] 和webservices[24] 产生了浓厚的兴趣。使用无处不在的WWW 基础设施和HTTP来开发中间件平台的想法十分迷人——至少在理论上。SOAP 和webservices 曾经允诺要成为Internet 上的分布式计算通用语言。 但尽管引发了很大的公众效应,发表了许多论文, web services 却没有能兑现其允诺:在本书撰写的同时,用web services 架构开发的商业系统非常少。其原因是:

• 无论是在网络带宽方面,还是在CPU 开销方面,SOAP 都会给应用造成严重的性能恶化,以致于该技术无法适用于许多有苛刻性能要求的系统。

• 尽管SOAP 提供了"on-the-wire" 规范,要开发现实的应用,那仍是不够的,因为该规范提供的抽象层次太低。应用可以把各种SOAP 消息拼凑在一起,但这样做极其繁琐而易错。

• 缺乏更高级的抽象促使供应商提供各种应用开发平台,使遵从SOAP 的应用开发自动化。但是,除了协议一级,这些开发平台完全没有标准化,不可避免是私有的,所以用一家供应商开发的应用无法与其他供应商的中间件产品一起使用。

• 关于SOAP 和web services 的架构安全性,有一些严重的担忧 。特别地,许多专家都表示,他们对该平台缺乏内在的安全性感到担忧。

• web services 是一项还处在幼年的技术。到目前为止,已进行的标准化很少,而且看起来还需要好几年,其标准化水平才能达到源码兼容性和跨供应商互操作性所要求的完备程度。结果,想要使用中间件平台的开发者面临着一些使人不快的选择:

• .NET Remoting

最严重的缺点是不支持非Microsoft 平台。[虽然出了Mono,但.....]

• CORBA

最严重的缺点是老化的平台、高度的复杂性,以及仍在发生的供应商磨擦。

• web services

最严重的缺点是严重低效,需要使用私有开发平台,并且还存在安全问题。

这些选择看起来很可能会让你失败:你可以选择只能在Microsoft 架构

上运行的平台,选择复杂的、正在被遗弃的平台,或选择低效的、由于缺

乏标准化而归属私有的平台。




本文转自斯克迪亚博客园博客,原文链接:http://www.cnblogs.com/sgsoft/archive/2007/05/03/735219.html,如需转载请自行联系原作者

相关文章
|
12月前
|
运维 监控 安全
VMware NSX 9.0 正式版发布 - 下一代网络安全虚拟化平台
VMware NSX 9.0 正式版发布 - 下一代网络安全虚拟化平台
707 3
VMware NSX 9.0 正式版发布 - 下一代网络安全虚拟化平台
|
8月前
|
网络协议 API 网络安全
VMware NSX 9.0.1.0 发布 - 下一代网络安全虚拟化平台
VMware NSX 9.0.1.0 发布 - 下一代网络安全虚拟化平台
1056 3
VMware NSX 9.0.1.0 发布 - 下一代网络安全虚拟化平台
|
9月前
|
人工智能 运维 安全
从被动防御到主动免疫进化!迈格网络 “天机” AI 安全防护平台,助推全端防护性能提升
迈格网络推出“天机”新版本,以AI自学习、全端防护、主动安全三大核心能力,重构网络安全防线。融合AI引擎与DeepSeek-R1模型,实现威胁预测、零日防御、自动化响应,覆盖Web、APP、小程序全场景,助力企业从被动防御迈向主动免疫,护航数字化转型。
从被动防御到主动免疫进化!迈格网络 “天机” AI 安全防护平台,助推全端防护性能提升
|
12月前
|
JSON 中间件 Go
Go 网络编程:HTTP服务与客户端开发
Go 语言的 `net/http` 包功能强大,可快速构建高并发 HTTP 服务。本文从创建简单 HTTP 服务入手,逐步讲解请求与响应对象、URL 参数处理、自定义路由、JSON 接口、静态文件服务、中间件编写及 HTTPS 配置等内容。通过示例代码展示如何使用 `http.HandleFunc`、`http.ServeMux`、`http.Client` 等工具实现常见功能,帮助开发者掌握构建高效 Web 应用的核心技能。
560 61
|
10月前
|
运维 安全 网络安全
VMware NSX 4.2.3 - 网络安全虚拟化平台
VMware NSX 4.2.3 - 网络安全虚拟化平台
408 0
|
NoSQL 关系型数据库 MySQL
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
577 56
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
|
Ubuntu 网络协议 Unix
02理解网络IO:实现服务与客户端通信
网络IO指客户端与服务端通过网络进行数据收发的过程,常见于微信、QQ等应用。本文详解如何用C语言实现一个支持多客户端连接的TCP服务端,涉及socket编程、线程处理及通信流程,并分析“一消息一线程”模式的优缺点。
590 0
|
网络协议 安全 Devops
Infoblox DDI (NIOS) 9.0 - DNS、DHCP 和 IPAM (DDI) 核心网络服务管理
Infoblox DDI (NIOS) 9.0 - DNS、DHCP 和 IPAM (DDI) 核心网络服务管理
591 4
|
机器学习/深度学习 人工智能 安全
从攻防演练到AI防护:网络安全服务厂商F5的全方位安全策略
从攻防演练到AI防护:网络安全服务厂商F5的全方位安全策略
365 8
|
算法 安全 大数据
【算法合规新时代】企业如何把握“清朗·网络平台算法典型问题治理”专项行动?
在数字化时代,算法推动社会发展,但也带来了信息茧房、大数据杀熟等问题。中央网信办发布《关于开展“清朗·网络平台算法典型问题治理”专项行动的通知》,针对六大算法问题进行整治,明确企业需落实算法安全主体责任,建立健全审核与管理制度,并对算法进行全面审查和备案。企业应积极自查自纠,确保算法合规透明,防范风险,迎接新机遇。

热门文章

最新文章