开发大型web应用，你会选择什么作为后端语言？ - 编程语言 - ITeye资讯
相关知识库：
近日，Hacker News中有引起了广泛的讨论：如果要开发一个大型的web应用程序，你会选择什么编程语言来进行后端开发，要考虑到开发时间、成本和可维护性。
以下是部分回复：
hendzen 写道对于一个“大型”的web应用，我会老老实实地使用Java，并会选择Jetty作为HTTP服务器，Jersey/JAX-RS作为web框架。JVM是无与伦比的，并且新员工入职培训也相对轻松得多，因为大部分人都了解Java。
尽管不像Rails/Django那么时髦，但是你将得益于众多高性能、可靠的Java库，更不用说那些伟大的分析工具。
meddlepal 写道我同意，我会选择Java来开发核心功能，对于一些非核心功能，我可能会选择Groovy或JRuby。
Jersey/JAX-RS非常不错，但我感觉有些风险，我更倾向于Play2。
Java/JVM生态系统中有很多非常积极的东西，如伟大的虚拟机、库、庞大的社区以及大量的开发者。这是开发一个大型web应用真正要考虑的。
2.& .NET
Avalaxy& 写道比起Java平台，我更倾向于ASP.NET MVC（比如C#）。.NET栈是非常强大的，我个人认为比Java强得多，并且ASP.NET MVC框架包含了大量RoR中的优秀特性。
ralphael& 写道我投.NET、MVC和SQL Server一票。
这个平台上拥有大量的示例程序，况且就是基于.NET的。
spobo& 写道.NET绝对不是一个坏的选择。
过去几年，微软已经真正到达了顶峰，它们最新的框架非常易于开发者掌握和使用，微软同时也开始基于.NET来推动其开源项目，比如codeplex和NuGet，微软同时还是jQuery的核心贡献者。微软最近还发布了WebAPI，为开发者创建REST-ful JSON/XML应用提供了一个相当平缓的方式。
3.& PHP
interwho& 写道对我个人而言，我会选择PHP：
更快地解决事情；
网上有大量的类可以使用，这让事情变得简单；
个人认为，比其他一些语言更容易维护；
可在几乎所有的网站托管服务器中运行，价格便宜；
可扩展。
如果你需要其他更强大的功能，你可以无缝过渡到另一种语言。
4.& Ruby或Python
olalonde& 写道Ruby/Rails和Python/Django似乎是YC初创企业最常见的选择，它们在开发时间、成本、可维护性方面具备一定的优势。
spdy& 写道Python/Django或Ruby on Rails。如果你行动快速、经常改变主意，就选它们。
netgineer& 写道在面向服务架构中，我会选择Ruby。在不同系统之间使用HTTP/JSON用于内部API。如果性能是瓶颈，你可以考虑在部分系统中使用一个稍低级别的语言（Java、Haskell、Go、Erlang等）。
Rails使SOA开发更加容易和快速，除了API客户端，我没有其他好的解决方案。
3pt14159 写道Python（Tornado或Twisted）+ Riak。为什么呢？你可以轻松扩展，并且有大量的库，开箱即用，并且你也无须担心你的数据库受影响。
5.& Clojure
Zak& 写道我倾向于Clojure，因为：
属性清单和类似于继承的行为对于映射和记录是非常自然和方便的。我认为，这些特性将有益于大型应用程序。
Clojure可以抽象数据库，保存和执行关系模型比ORM更加直接。
Clojure可以利用Java库，这意味着你在实现一些常用功能时会非常轻松。
6. 选择喜欢（擅长）的语言
spobo 写道使用一个更高级的编程语言，同时使用标准接口与前端进行通信。如果你为后端构建了一个REST API，使用什么语言是不重要的。你可以随时更换更高性能的部件，也可以使用不同的语言来开发不同的功能。
如果你想降低开发成本，就使用大多数开发者已选择的生态系统，Python、PHP、Ruby、Java、.NET都可以，这些语言都有一些伟大的框架，帮助你进行快速开发。
但是，不管你做什么，不要强制让你的开发人员去使用不喜欢的语言。听从你的开发团队，要相信每种语言都有很大的潜力。
如果让你来选择，你会选择哪种语言呢？欢迎讨论。
longzhun 写道ad6543210 写道上面幾個應該是java最多人用了.但是java有高性能？難道我用的java跟大家都不一樣嘛..明明電腦差就不能用了你懂什么是性能不我只懂在爛掉腦上 java 跟 flash 不分上下的爛爛電腦
longzhun 写道ad6543210 写道上面幾個應該是java最多人用了.但是java有高性能？難道我用的java跟大家都不一樣嘛..明明電腦差就不能用了你懂什么是性能不我只懂在爛掉腦上 java 跟 flash 不分上下的爛
ldbjakyo 写道fjjiaboming 写道ldbjakyo 写道Scala lift 没有上榜...还没有大规模应用. Twitter 是 Scala 搞的, 至少并发处理挺大的，处理数据量也挺大的...Twitter在美国总体选举期间 访问过大 已经部分转向java了
zeeler 写道感觉Java的性能是靠内存来获得的，同样的硬件配置，PHP/Python/Ruby这些脚本语言反而比较容易提升性能不靠内存 靠什么 你糊涂了吗& java对内存的利用和优化是做得很好的
damoqiongqiu 写道项目的体量不是技术选型的最终决定因素，最关键的因素是项目的场景，比如新浪、搜狐这样的大型门户站点，当然是PHP居多；专业的行业应用，比如电力、电信、医疗等等，Java当仁不让。 没常识 大型互联网用的都是java
ad6543210 写道上面幾個應該是java最多人用了.但是java有高性能？難道我用的java跟大家都不一樣嘛..明明電腦差就不能用了你懂什么是性能不
看淘宝和京东的网站架构就知道了， 既然是大型的web应用，那么淘宝和京东可以称为大型web应用了。淘宝是架构在java上的，而京东是asp.net开发的，看看这次双十一就知道了，京东的网站岌岌可危！而淘宝的架构却很稳定！
我用的就是天天被人骂快死掉的语言-JAVA 5555
只有两种计算机语言：一些语言天天挨骂，另外一些没有人用。
要快速还是选ruby了，一些后端服务性的东西还是得用java的
icewubin 写道hardPass 写道icewubin 写道hardPass 写道Java OSGIOSGI只是个Java框架，而且只是在单JVM上比较成熟，对于大型互联网的集群（多JVM）来说，没什么太大的价值。大哥你问我的是数据交换层，我说用OSGI。你还能再断章取义不？icewubin 写道你不用钻牛角尖，你就说说如果你来决策，数据交换层使用哪种技术？而就数据交换层来说，一般不需要大规模集群，一般2台服务器做庄就可以了。实际的业务逻辑都放在应用层。你要大规模集群、横向扩展，应该是说的是实际的应用层。我知道我说的数据交换层的概念你未必能够理解。如果你的子系统不多，业务没有那么复杂多变，可以忽略数据交换层，直接UI层+应用层（这在我之前都帖子中也说过）。另外，就你话的本身的，这是个大谬论。OSGI是本身是基于单JVM的，但话又说过来，又有哪个JVM的程序是跨多个JVM的呢？这和是否分布式没有矛盾。之所以强调OSGI，是因为它的特性更符合数据交换的特征。使用基于OSGI做的数据交换中间件，成熟跑了多年的项目，哥经历过的，尽管放心。既然你觉得OSGI能作为一种“方案”回答数据交换层的语言问题，那就到此为止吧。这不是一个层面上的问题。osgi。。。也就忽悠一下行业内用户吧。互联网没人用这玩意。
hardPass 写道icewubin 写道hardPass 写道Java OSGI
OSGI只是个Java框架，而且只是在单JVM上比较成熟，对于大型互联网的集群（多JVM）来说，没什么太大的价值。
大哥你问我的是数据交换层，我说用OSGI。你还能再断章取义不？
icewubin 写道你不用钻牛角尖，你就说说如果你来决策，数据交换层使用哪种技术？
而就数据交换层来说，一般不需要大规模集群，一般2台服务器做庄就可以了。
实际的业务逻辑都放在应用层。你要大规模集群、横向扩展，应该是说的是实际的应用层。
我知道我说的数据交换层的概念你未必能够理解。
如果你的子系统不多，业务没有那么复杂多变，可以忽略数据交换层，直接UI层+应用层（这在我之前都帖子中也说过）。
另外，就你话的本身的，这是个大谬论。OSGI是本身是基于单JVM的，但话又说过来，又有哪个JVM的程序是跨多个JVM的呢？这和是否分布式没有矛盾。之所以强调OSGI，是因为它的特性更符合数据交换的特征。使用基于OSGI做的数据交换中间件，成熟跑了多年的项目，哥经历过的，尽管放心。
既然你觉得OSGI能作为一种“方案”回答数据交换层的语言问题，那就到此为止吧。
icewubin 写道hardPass 写道Java OSGIOSGI只是个Java框架，而且只是在单JVM上比较成熟，对于大型互联网的集群（多JVM）来说，没什么太大的价值。大哥你问我的是数据交换层，我说用OSGI。你还能再断章取义不？icewubin 写道你不用钻牛角尖，你就说说如果你来决策，数据交换层使用哪种技术？而就数据交换层来说，一般不需要大规模集群，一般2台服务器做庄就可以了。实际的业务逻辑都放在应用层。你要大规模集群、横向扩展，应该是说的是实际的应用层。我知道我说的数据交换层的概念你未必能够理解。如果你的子系统不多，业务没有那么复杂多变，可以忽略数据交换层，直接UI层+应用层（这在我之前都帖子中也说过）。另外，就你话的本身的，这是个大谬论。OSGI是本身是基于单JVM的，但话又说过来，又有哪个JVM的程序是跨多个JVM的呢？这和是否分布式没有矛盾。之所以强调OSGI，是因为它的特性更符合数据交换的特征。使用基于OSGI做的数据交换中间件，成熟跑了多年的项目，哥经历过的，尽管放心。
hardPass 写道Java OSGI
OSGI只是个Java框架，而且只是在单JVM上比较成熟，对于大型互联网的集群（多JVM）来说，没什么太大的价值。
icewubin 写道hardPass 写道伪命题，大规模的web应用，不可能只用一种技术的。一种静态语言+一种编译型语言，算是最起码的了。综合多种语言及平台的优势，才是王道。要兼顾快速变更、性能、横向扩展。因为是大规模的web应用，即使是服务端，至少是应该分为UI层+应用层，或者是协议层+数据交换层+应用层。你不用钻牛角尖，你就说说如果你来决策，数据交换层使用哪种技术？Java OSGI
hardPass 写道伪命题，大规模的web应用，不可能只用一种技术的。一种静态语言+一种编译型语言，算是最起码的了。综合多种语言及平台的优势，才是王道。要兼顾快速变更、性能、横向扩展。
因为是大规模的web应用，即使是服务端，至少是应该分为UI层+应用层，或者是协议层+数据交换层+应用层。
你不用钻牛角尖，你就说说如果你来决策，数据交换层使用哪种技术？
伪命题，大规模的web应用，不可能只用一种技术的。一种静态语言+一种编译型语言，算是最起码的了。综合多种语言及平台的优势，才是王道。要兼顾快速变更、性能、横向扩展。因为是大规模的web应用，即使是服务端，至少是应该分为UI层+应用层，或者是协议层+数据交换层+应用层。
&& 我选PHP～
guoxu1231 写道在JavaEye上争论& 都傻了嘛&&& JavaEye是Java的Eye嘛&& Java当仁不让最牛逼啊& 最炫民族风啊大哥，说的是WEB应用，不是桌面应用，桌面当然是C++无疑，web当然是java
在JavaEye上争论& 都傻了嘛&&& JavaEye是Java的Eye嘛&& Java当仁不让最牛逼啊& 最炫民族风啊
& 上一页 1
相关资源推荐有问题 @ 爱问Powered
举报原因(必选)：
广告或垃圾信息
不雅词句或人身攻击
激进时政或意识形态话题
侵犯他人隐私
其它违法和不良信息出处：http://blog.csdn.net
面向服务架构soa以其独特的优势越来越受到企业的重视，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。Soa的开发方法一般主要有开源的dubbo、dubbox、mule、wso2、cxf，以及付费的oracle
soa、ibm soa等。
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web
Service技术之后的自然延伸。
SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化作用。要实现这一目标，就要在实施SOA的过程中牢记以下特征：
可从企业外部访问
粗粒度的服务接口分级
可重用的服务
服务接口设计管理
标准化的服务接口
支持各种消息模式
精确定义的服务契约
SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL， Web
ervices Description Language
）是用于描述服务的标准语言。
SOA 服务用消息进行通信，该消息通常使用XML Schema来定义（也叫做XSD， XML
Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。
在一个企业内部，SOA服务通过一个扮演目录列表（directory listing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， Universal
Description， Definition， and Integration）是服务登记的标准。
每项SOA服务都有一个与之相关的服务品质（QoS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。
随着全球信息化的浪潮，信息化产业不断发展、延伸，已经深入了众多的企业及个人，SOA系统架构的出现，将给信息化带来一场新的革命。
纵观信息化建设与应用的历程，尽管出现过XML（标准通用标记语言的子集）、Unicode、UML等众多信息标准，但是许多异构系统之间的数据源仍然使用各自独立的数据格式、元数据以及元模型，这是信息产品提供商一直以来形成的习惯。各个相对独立的源数据集成一起，往往通过构建一定的数据获取与计算程序来实现，这样的做法需要花费大量工作。信息孤岛大量存在的事实，使信息化建设的ROI（投资回报率）大大降低，ETL成为集中这些异构数据的有效工具。 ETL常用于从源系统中提取数据，将数据转换为与目标系统相兼容的格式，然后将其装载到目标系统中。数据经过获取、转换、装载后，要产生应用价值，还需另外的数据展现工具予以实现，如此复杂的数据应用过程，必定产生高昂的应用成本。
结构化的数据管理尚可通过以上方法，予以实现其集成应用。在非结构化的内容方面，这些具有挑战性的问题令人生畏。内容管理的应用方案基于不同的信息化应用系统，而且大部分是纵向的以组织部门为界限的。在内容管理市场中，经常使用来自不同厂商的产品来提供这些解决方案。即使是同一个厂商的产品，相互之间的功能也是经常重叠，并且无法集成。
随着信息化建设的深入，不同应用系统之间的功能界限已趋于模糊。同时企业资源计划系统和协同商务系统，又需要商业智能的分析展现数据提供用户操作依据。
在激烈竞争且多变的市场环境下，企业的管理模式很难固化，应用传统的信息化软件，当企业要做出一些改动时需要面对巨大的挑战。
WebService
被誉为下一代
服务的基础框架，已经成为计算机信息领域的一个新的发展方向。
SOA的出现给传统的信息化产业带来新的概念，不再是各自独立的架构形式，能够轻松的互相联系组合共享信息。
可复用以往的信息化软件。基于SOA的协同软件提供了应用集成功能，能够将ERP、CRM、HR等异构系统的数据集成。
松散耦合方式，只要充分了解业务的进程，就可以不用编写一行代码，通过流程图实现一套我们自己的信息系统。就像已经给你准备好了砖瓦和水泥，只需要想好盖什么样的房子就可以轻松的盖起。加快开发速度，并且减少了开发和维护的费用。软件将所有的管理提炼成表单和流程，以记录管理的内容，指定过程的流转方向。
更简便的信息和数据集成。信息集成功能可以将散落在广域网和局域网上的文档、目录、网页轻松集成，加强了信息的协同相关性。同时，复杂、成本高昂的数据集成，也变成了可以简单且低成本实现的参数设定。创建了完全集成的信息化应用新领域。
在具体的功能实现上，SOA协同软件所实现的功能包括了知识管理、流程管理、人事管理、客户管理、项目管理、应用集成等，从部门角度看涉及了行政、后勤、营销、物流、生产等。从应用思想上看，SOA协同软件中的信息管理功能，全面兼顾了贯穿整个企业组织的信息化软硬件投入。尽管各种IT技术可以用于不同的用途，但是信息管理并没有任意地将信息分为结构化或者非结构化的部分，因此ERP等结构化管理系统并不是信息化建设的全部；同时，信息管理也没有将信息化解决方案划分为部门的视图，因此仅仅以部分为界限去构建软件应用功能的思想未必是不可撼动的。基于SOA的协同软件与
ERP、CRM等传统应用软件相比，关键的不同在于它可以在合适的时间、合适的地点并且有正当理由向需要它提供服务的任何用户提供服务。
利用SOA架构开发的优点：
　　第一、更易维护
　　业务服务提供者和业务服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。建立在以 SOA基础上的信息系统，当需求发生变化的时候，不需要修改提供业务服务的接口，只需要调整业务服务流程或者修改操作即可，整个应用系统也更容易被维护。
　　第二、更高的可用性
　　该特点是在于服务提供者和服务使用者的松散耦合关系上得以发挥与体现。使用者无须了解提供者的具休实现细节。
　　第三、更好的伸缩性
　　依靠业务服务设计、开发和部署等所采用的架构模型实现伸缩性。使得服务提供者可以互相彼此独立地进行调整，以满足新的服务需求。
下面详细论述几种主要的开发方法和工具：
DUBBO是淘宝公司的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。淘宝公司的许多应用就是采用dubbo，运行稳定成功。现在，不少企业采用dubbo开发应用系统。Dubbo是简单有效的soa架构，值得采用。
相比于其他服务框架，DUBBO有如下优势：
透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入；
软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点；
服务自动注册与发现，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
其核心部分包含：
远程通讯:提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
集群容错:提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
自动发现:基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo有如下功能：
透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
Dubbo基本原理-分布式服务框架
Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。
服务提供者：定义服务接口
定义服务接口:(该接口需单独打包，在服务提供方和消费方共享)
在服务提供方实现接口
在服务提供方实现接口：(对服务消费方隐藏实现)
用Spring配置声明暴露服务
加载Spring配置
服务消费者：
加载Spring配置，并调用远程服务：(也可以使用IoC注入)
Zookeeper注册中心安装
建议使用dubbo-2.3.3以上版本的zookeeper注册中心客户端。
Zookeeper是Apache Hadoop的子项目，强度相对较好，建议生产环境使用该注册中心。
Dubbo未对Zookeeper服务器端做任何侵入修改，只需安装原生的Zookeeper服务器即可，所有注册中心逻辑适配都在调用Zookeeper客户端时完成。
开源网址：
http://alibaba.github.io/dubbo-doc-static/Home-zh.htm
Zookeeper下载地址：
http://zookeeper.apache.org/releases.html
Zookeeper注册中心安装：
http://alibaba.github.io/dubbo-doc-static/Zookeeper+Registry+Installation-zh.htm
Mule是一个以Java为核心的轻量级的消息框架和整合平台，基于EIP（Enterprise Integeration Patterns，由Hohpe和Woolf编写的一本书）而实现的。Mule的核心组件是UMO(UniversalMessage Objects，从Mule2.0开始UMO这一概念已经被组件Componse所代替)，UMO实现整合逻辑。UMO可以是POJO,JavaBean等等。它支持30多种传输协议(file,FTP,UDP,TCP,email,HTTP,SOAP,JMS等)，并整合了许多流行的开源项目，比如Spring,ActiveMQ,CXF,Axis,Drools等。
Mule Studio是一个功能强大、用户界面友好的基于Eclipse的开发工具。使用者不需要深入了解Mule的XML配置语法，就可以在几分钟内轻松的创建、编辑、测试Mule ESB流程。Mule Studio基于Eclipse技术，包含3个主要部件：项目结构树、工具箱和画布。项目结构树包含整个项目的目录结构。
Mule是一个企业服务总线(ESB)消息框架.它的主要特性包括:
1.基于J2EE1.4的企业消息总线(ESB)和消息代理(broker).
2.可插入的连接性:比如Jms,jdbc,tcp,udp,multicast,http,servlet,smtp,pop3,file,xmpp等.
3.支持任何传输之上的异步，同步和请求响应事件处理机制.
4.支持Axis或者Glue的Web Service.
5.灵活的部署结构[Topologies]包括Client/Server,P2P, ESB 和Enterprise Service Network.
6.与Spring 框架集成:可用作ESB 容器，也可以很容易的嵌入到Spring应用中.
7.使用基于SEDA处理模型的高度可伸缩的企业服务器.
8.强大的基于EIP模式的事件路由机制等.
WSO2ESB是一种根据ApacheV2.0许可证发布的快速、轻量级和灵活的企业服务总线产品。使用ESB在HTTP、HTTPS、JMS、mail等协议基础上通过业务系统过滤、转换、路由和处理SOAP，二进制、纯XML和文本消息。
WSO2ESB是一个为企业准备的完全成熟的ESB。WSO2ESB是建立在Apache Synapse项目基础上的。Apache Synapse是使用Apache Axis2创建的。
应用程序发送消息到ESB，该消息由ESB
Transport捡起。
Transport通过消息管道发送消息。像安全和可靠的消息传递的信息方面的质量受到这个pipe的照顾。在该pipe内部是axis2的流入和流出流。ESB可以有如下两种操作：
消息中介：使用单管道
代理服务：使用独立的管道运输到不同的代理服务。
消息转换和消息路由可以看做一个独立的单元。如图所示，消息转换组件和路由组件之间没有明显的分离。WSO2ESB调用这个中介框架。一些转换发生在路由决定之前，一些转换发生在路由决定之后。这一部分由Synapse执行。
然后根据目的地将消息注入到独立的管道。在这里再次确定消息服务方面的质量。
传输层负责通过ESB所需的传输协议的转换。
该图显示了如何通过ESB的体系架构将请求传到一个实际的endpoint。响应处理是这个操作的反向操作。
所有这些组件可以通过WSO2ESB管理控制台管理和检测。
ESB Components
Transports
WSO2ESB支持所有广泛使用的传输协议包括HTTP/s、JMS、VFS和特定领域的传输如FIX。一个新的传输协议使用axis2传输框架轻松地被添加和插入到ESB中。不同的传输工具为ESB带来各种消息内容／负载。
传输内容：
消息建设者：允许使用内容类型标识消息并使变成普通的XML消息集。因此每个内容类型都有相关联的建设者。WSO2ESB包含基于文本的内容信息的建设者和二进制内容建设者。
消息格式：建设者的相反的搭档。格式化程序通过指出传输协议处理前消息内容的类型将消息转换回原始格式。类似transport的用户可以使用axis2框架实现消息的建设和格式化。
参阅Transports
端点（Endpoints）
Endpoints作为具有传输协议的逻辑组件。两套端点地址和WSDL。地址endpoint可以使用任何可用的transport调度消息。
参阅Endpoints
代理服务（ProxyServices）
在WSO2ESB中代理服务是实现使用消息接收器和开放接收消息的虚拟服务。一个代理服务可以使用类似于一个普通的web服务地址的url访问。代理服务允许将WSDL发布到用于先前使用的程序组。可以使用任何可用的传输协议从代理服务接收和发送消息。
参阅　Proxy Services Sample
主题（Topics）
Topics是另一个恢复消息处理事件的实施，包括subscription和events．
参阅eventing
中介（Mediators）
WSO2ESB的power仍然是为不同方面提供服务的全面调节库。使用mediator库实现广泛使用MEPs和EIPs。由于WSO2ESB提供了一个健康的框架，使得开发者写一个mediator非常容易。mediators可以使用包括Java，scripting和Spring的各种技术。
参阅ｍｅｄｉａｔｏｒ
序列（Sequences）
Sequence充当mediators的配置组件。Sequence允许阻止mediators实现管道和过滤模式。
参阅Sequences
任务和命令（Tasksand Commands）
Tasks提供在WSO2ESB中配置计划工作的设施并且允许执行mediation的内部或外部命令。
QoS组件（QoSComponents）
Qos组件实现可靠的消息传递和代理服务自带的Apache的Rempart和Sandesha两个实现模块的安全性。
配置、库/注册（Configuration,Repository/Registry）
Configuration是ESB架构的架构图。WSO2ESB提供了一个内置的 Repository/Registry存储配置和配置元数据，而且提供了使用远程库设施。
管理和配置界面（Managementand Configuration GUI）
有助于在生产环境中运行WSO2ESB组件可以在组件中找到。这些组件实现集群、高可用性和负载平衡功能。
GUI组件进行综合管理、配置和检测GUI。GUI通过分离前端和后端的关注实现了分层架构。这允许用户使用一个GUI控制台连接到多个后台。
WSO2ESB基于组件的体系结构加强了使用OSGi的松耦合性质。所有组件都建为OSGi包。
ESB特点（ESB Features）
完整的XML和Web服务支持
借助内置的XML、命名空间、XPath、XSLT、XQuery，WSO2ESB支持XML的处理需求。同时也能够很大程度上处理非XML的内容。
WSO2ESB主要支持的服务标准：
SOAP1.1/ SOAP1.2
WSDL1.1／WSDL1.2
WS寻址（支持双通道调用）
使用Apache Smart的安全的WS
使用Apache　Sandesha2可靠的WS消息
使用Apache　Savan的WS事件和WSO2事件
WS策略（支持传入／传出的消息分离策略）
MTOM／SwA优化二进制消息
XML／HTTP（POX）
经验证的互操作性
基于通用的Apache Synapse和Apache Axis2项目，WSO2ESB已经证明含有Microsoft.NET的Web服务堆栈的互操作性
WSO2ESB优化了使用最少资源低延迟支持高吞吐量。可以使用连接节流支持成千上万的并发连接，以及使用一个恒定的内从占有的大量消息使用连接节流。非阻塞的IO和XML流组合的解析设计意味着ESB按照需求缩放而且仍能表现的很好。
最小定制开发
WSO2ESB旨在轻松的支持常见的要求，同时可能要扩展其功能。
这些功能：
基于内容的路由
虚拟化服务
日志记录＆检测
消息分裂和聚合
企业集成模式
可以使用简单的Java扩展功能、POJO类、Spring以及使用JavaScript、Ruby或其它Apache BSF脚本语言扩展
支持以下内置协议整合存在的网络、伙伴及新工程
非阻塞的HTTPs协议
1.0和1.1的交易JMS传输二进制、文本和SOAP消息
Apache VFS文件传输（如：S/FTP、文件、zip/tar/gz、WebDAV、CIFS等）
支持多部分内容的邮件传输（POP3、IMAP、SMTP）
AMQP通过Apache QPid
金融信息交换（FIX）
Web服务的Hessian二进制协议
支持管理经常性工作，通过ESB允许定期更新这些任务计划作为cron守护进程或简单重复的任务支持
事件驱动架构
内置的Qpid代理人作为事件代理人很容易实现使用EDA技术的企业集成。事件通过代理人可以调解执行发布之前的任何需求改变
内置的注册表
WSO2ESB附带一个集成的WSO2注册表，并且轻松的实现连接到外部/远程注册表
高级调解&EIP
WSO2ESB还内置了支持读取或写入到数据库，以及到Java/POJO类或脚本中调用。它也提供消息拆分、聚合、缓存和限制可以轻松的配置能力。
产业驱动协议
支持产业带动财政信息交换（FIX）协议使财政部分一体化和Hessian web服务协议支持二进制消息格式。AMQP、VFS和JMS作为运输企业集成。
国际化图形控制台
WSO2ESB提供了一整套的管理服务和一个图形化用户界面配置/管理/监测运行的WSO2ESB服务器。此图形控制台可以很容易的当后台运行在服务器上时与后台分离。可以在桌面上安装国际化的图形控制台而且还可以用于管理集群中的节点
序列编辑器
代理服务编辑器
端点／本地注册编辑器
内置的注册表浏览器
策略编辑器
预定义的安全方案
配置数据源
日志、追踪和监测统计
有力的通过管理控制台和ＪＭＸ停止和重启ＥＳＢ
WSO2 ESB内通过JMX管理控制台以及配备了全面的监测能力。这些监控功能包括：
系统统计图表
调解统计图表
日志配置和监控
ApacheCXF 是一个开源的Services框架，CXF帮助您利用Frontend 编程 API来构建和开发Services，像JAX-WS。这些Services可以支持多种协议，比如：SOAP、XML/HTTP、RESTful
HTTP 或者 CORBA ，并且可以在多种传输协议上运行，比如：HTTP、JMS或者JBI，CXF大大简化了Services的创建，同时它继承了XFire传统，一样可以天然地和Spring进行无缝集成。
CXF 包含了大量的功能特性，但是主要集中在以下几个方面：
支持Web Services标准：CXF支持多种Web Services标准，包含SOAP、BasicProfile、WS-Addressing、WS-Policy、WS-ReliableMessaging和 WS-Security。Frontends：CXF支持多种“Frontend”编程模型，CXF实现了JAX-WS API（遵循JAX-WS
2.0 TCK版本），它也包含一个“simplefrontend”允许客户端和 EndPoint 的创建，而不需要Annotation注解。CXF既支持 WSDL优先开发，也支持从Java的代码优先开发模式。容易使用： CXF设计得更加直观与容易使用。有大量简单的 API用来快速地构建代码优先的 Services，各种Maven的插件也使集成更加容易，支持 JAX-WS API，支持Spring
2.0更加简化的XML配置方式，等等。支持二进制和遗留协议：CXF的设计是一种可插拨的架构，既可以支持 XML，也可以支持非XML的类型绑定，比如：JSON和CORBA。
下面列出了来自Apache CXF官方网站的项目目标。
高性能可扩展简单且容易使用支持多种标准
支持 JAX-WS、JAX-RS、JSR-181和 SAAJ；支持SOAP
1.1、1.2、WS-IBasicProfile、WS-Security、WS-Addressing、WS-RM 和 WS-Policy；支持WSDL
1.1、2.0；支持MTOM；
多种传输方式、Bindings、DataBindings和Format
Bindings：SOAP、REST/HTTP；DataBndings：目前支持JAXB
2.0、Aegis两种，默认是JAXB 2.0。XMLBeans、Castor和JiBX数据绑定方式将在CXF
2.1版本中得到支持；格式（Format）：XML、JSON；传输方式：HTTP、Servlet、JMS和Jabber；可扩展的API允许为CXF增加其它的Bindings，以能够支持其它的消息格式，比如：CSV和固定记录长度。
2Apache CXF特点编辑
轻量级容器：可在Tomcat或基于Spring的容器中部署Services；集成JBI：可以在如ServiceMix,OpenESB or
Petals 等等的JBI容器中将它部署为一个服务引擎；集成 SCA：可以部署在如Tuscany之类的SCA容器中；集成J2EE：可以在J2EE 应用服务器中部署 Services，比如：Geronimo、JOnAS、JBoss、WebSphereApplication
Server 和WebLogic Application Server，以及Jetty和Tomcat；独立的Java 客户端/服务器。
支持多种编程语言
全面支持JAX-WS 2.0 客户端/服务器编程模型；支持 JAX-WS 2.0 synchronous、asynchronous和one-way
API&s；支持JAX-WS 2.0 Dynamic Invocation Interface (DII) API；支持wrapped and non-wrapped风格；支持XML messaging API；支持JavaScript和ECMAScript
4 XML (E4X)，客户端与服务端均支持；通过Yoko支持CORBA；通过Tuscany支持SCA；通过ServiceMix支持JBI；
Java toWSDL；WSDLto Java；XSDto WSDL；WSDLto
XML；WSDLto SOAP；WSDLto Service；
CXF 框架支撑环境
CXF 框架是一种基于 Servlet 技术的SOA应用开发框架，要正常运行基于 CXF应用框架开发的企业应用，除了 CXF框架本身之外，还需要JDK和Servlet容器的支持。
五dubbox。
当当网我们根据自身的需求，为Dubbo实现了一些新的功能，并将其命名为Dubbox（即DubboeXtensions）。
主要的新功能包括：
支持REST风格远程调用（HTTP +JSON/XML)：基于非常成熟的JBoss RestEasy框架，在dubbo中实现了REST风格（HTTP + JSON/XML）的远程调用，以显著简化企业内部的跨语言交互，同时显著简化企业对外的Open API、无线API甚至AJAX服务端等等的开发。事实上，这个REST调用也使得Dubbo可以对当今特别流行的“微服务”架构提供基础性支持。
另外，REST调用也达到了比较高的性能，在基准测试下，HTTP+ JSON与Dubbo 2.x默认的RPC协议（即TCP + Hessian2二进制序列化）之间只有1.5倍左右的差距，详见下文的基准测试报告。
支持基于Kryo和FST的Java高效序列化实现：基于当今比较知名的Kryo和FST高性能序列化库，为Dubbo 默认的RPC协议添加新的序列化实现，并优化调整了其序列化体系，比较显著的提高了Dubbo RPC的性能，详见下图和文档中的基准测试报告。
支持基于嵌入式Tomcat的HTTP remoting体系：基于嵌入式tomcat实现dubbo的HTTP remoting体系（即dubbo-remoting-http），用以逐步取代Dubbo中旧版本的嵌入式Jetty，可以显著的提高REST等的远程调用性能，并将Servlet API的支持从2.5升级到3.1。（注：除了REST，dubbo中的WebServices、Hessian、HTTP
Invoker等协议都基于这个HTTP remoting体系）。
升级Spring：将dubbo中Spring由2.x升级到目前最常用的3.x版本，减少项目中版本冲突带来的麻烦。
升级ZooKeeper客户端：将dubbo中的zookeeper客户端升级到最新的版本，以修正老版本中包含的bug。
注：dubbox和dubbo 2.x是兼容的，没有改变dubbo的任何已有的功能和配置方式（除了升级了Spring之类的版本）。另外，dubbox也严格遵循了Apache 2.0许可证的要求。
总之，soa架构具有松耦合、高复用、开发、维护灵活方便、支持多平台多系统、对原系统良好支持、消除信息孤岛等许多优点，以dubbo为代表的开发方法有一百多种，以上5种主要的方法值得借鉴采用，相信一定会带来极好的价值！
以上为本人摘自电脑玩物网，作者：
作者：chenleixing 发表于 22:29:09
阅读：28 评论：0
相关 [soa 架构 开发] 推荐：
- 人月神话的BLOG
对于SOA架构咨询，其核心还是在于组件化和服务化，然后才是服务管控和治理，基于服务化思想对传统软件开发生命周期过程的改进. SOA架构大家刚接触时候很容易将其理解为一种单纯的技术架构，或者更多的人仅仅是将SOA理解为service服务接口，这些都是对SOA方法论很大的误解. SOA咨询一个重点就是业务驱动IT，而非单纯的IT架构咨询，SOA咨询一般都会结合企业架构和云的思想，结合组件化架构和领域服务的思想，高层结合BPM端到端流程整合目标，并对这些内容进行有效的融合.
- CSDN博客推荐文章
面向服务架构soa以其独特的优势越来越受到企业的重视，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用. 服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性. Soa的开发方法一般主要有开源的dubbo、dubbox、mule、wso2、cxf，以及付费的oracle
soa、ibm soa等.
- 人月神话的BLOG
参考： https://www.ebayopensource.org/wiki/display/TURMERICDOC/Turmeric+Documentation+Overview. Turmeric是一个综合的、由策略驱动的SOA平台，提供了对SOA服务及其消费者的开发、部署、保护、运行和监控等方面的支持.
- 人月神话的BLOG
今年在这点上谈的比较多，也逐步开始落地实施，将SOA咨询和实施方法论从系统间真正的引入到系统内，将面向对象的需求分析方法和SOA思想进一步融合，从业务建模到系统用例建模，从流程分析到服务识别和分析，从业务组件化到系统模块化，这些工作都逐步开始落地实施. 这样做的好处就是进一步的体现SOA可复用组件的价值，真正的做到业务组件化和组件能力化.
- 人月神话的BLOG
本篇讲主要强调下在常规的企业架构规划和顶层设计中与SOA规划设计之间的融合. 再次强调下SOA的核心思想是解耦，在首先满足解耦的要求下实现共享，协同和复用. 一个完整的业务系统被拆分了应用，服务和资源层能力三个方面的内容. 资源层的能力最终以粗粒度的服务方式暴露出来，应用的构建需要大部分的借助于共享服务层抽取和接入的各种服务能力.
- CSDN博客架构设计推荐文章
SCA实现SOA的最佳方式. Apache开源框架Tuscany实现SCA架构. SOA（Service-Oriented Architecture）面向服务的体系架构. 为了能够深入理解还专门查了单词：Oriented:面向，Architecture：架构，没办法英语太烂. 实际上是一个组件模型，他将应用程序的不同功能单（称为服务）通过定义良好的接口联系起来.
- 人月神话的BLOG
今天在广州交流SOA和微服务架构，特对关键内容做简单记录. 对于SOA和微服务架构的区别，在知乎一个回答里面我已经进行了详细的说明，即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.
- 人月神话的BLOG
对于SOA和云架构设计方面的内容，前面已经有很多文章涉及到，在这里再重点谈下SOA和云架构设计和传统EA企业架构和单业务系统架构设计之间的一些区别和联系. SOA和云架构设计更多的是在企业架构的应用架构和技术架构层面，然后才过渡到单个应用的架构设计约束，因此也可以理解为是传统软件架构设计更加上层的一个内容.
- ITeye博客
并非淘宝系的技术啦，淘宝系的分布式服务治理框架式HSF啦
，只闻其声，不能见其物. 而dubbo是阿里开源的一个SOA服务治理解决方案，dubbo本身
集成了监控中心，注册中心，负载集群...等等. 代码和整体的框架还是很优雅滴呀. github地址 /alibaba/dubbo.
- 人月神话的BLOG
传统业务系统的构建更多的是竖井式的纵向思想，这个主要是从单个业务系统孤立来看都是垂直应用. 那么SOA架构的视角是从整个企业应用架构环境来看，思想的核心转变就是从传统的纵向独立构建模式转变为横向从底朝上逐层构建模式，在这个构建模式中首先是底层的资源层（独立的业务组件），然后是服务层，再上面才是应用层和门户展现层.
坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：@。}