GPL V3

        6月29日FSF(免费软件基金会)发布GPLv3(通用公共许可证),此前业界已经使用GPLv2达16年之久,GPLv3在内容方面主要丰富了全球化的内容,而不是象以前那样针对美国的法律,针对美国的情况。看看我们中国自由软件一团糟的情况,现在看来也要好好整顿了。不过新规矩出来,还是收到很多反对之声,微软和Linux两大阵营都嘘声一片。呵呵,东西的好坏还是让时间来检验吧!

详情关注:        GPL3 开源的机会还是陷阱?
GPL V3 原文: GNU General Public License 

什么是Web 2.0

什么是Web 2.0,看看Tim O’Reilly的这篇文章:
What Is Web 2.0,(中文版:什么是Web 2.0

Web 2.0和Web1.0:

Web 1.0 Web 2.0
DoubleClick Google AdSense
Ofoto Flickr
Akamai BitTorrent
mp3.com Napster
大英百科全书在线(Britannica Online) 维基百科全书(Wikipedia)
个人网站 博客(blogging)
evite upcoming.org和EVDB
域名投机 搜索引擎优化
页面浏览数 每次点击成本
屏幕抓取(screen scraping) 网络服务(web services)
发布 参与
内容管理系统 维基
目录(分类) 标签(“分众分类”,folksonomy)
粘性 聚合

Web 2.0 模拟图:

Web2.0的关键原则:

1. 互联网作为平台
2. 利用集体智慧
3. 数据是下一个Intel Inside
4. 软件发布周期的终结
5. 轻量型编程模型
6. 软件超越单一设备
7. 丰富的用户体验

Web 2.0的设计模式
在“模式语言”(A Pattern Language)一书中,克里斯多夫•亚历山大(Christopher Alexander)为精炼描述对于体系结构问题的解决方案,开了一种格式上的处方。他写道:“每个模式都描述着一种在我们的环境中一遍又一遍地出现的问题,并因此描述了对该问题的核心解决方案。以此方式你可以使用该方案上百万次,而从不需要重复作同样的事情。”
1. 长尾
小型网站构成了互联网内容的大部分内容;细分市场构成了互联网的大部分可能的应用程序。所以,利用客户的自服务和算法上的数据管理来延伸到整个互联网,到达边缘而不仅仅是中心,到达长尾而不仅仅是头部。
2. 数据是下一个Intel Inside
应用程序越来越多地由数据驱动。因此:为获得竞争优势,应设法拥有一个独特的,难于再造的数据资源。
3. 用户增添价值
对互联网程序来说,竞争优势的关键在于,用户多大程度上会在你提供的数据中,添加他们自己的数据。因而,不要将你的“参与的体系”局限于软件开发。要让你的用户们隐式和显式地为你的程序增添价值。
4. 默认的网络效应
只有很小一部分用户会不嫌麻烦地为你的程序增添价值。因此:要将默认设置得使聚合用户的数据,成为用户使用程序的副产品。
5. 一些权力保留
知识产权保护限制了重用也阻碍了实验。因而,在好处来自于集体智慧而不是私有约束的时候,应确认采用的门槛要低。遵循现存准则,并以尽可能少的限制来授权。设计程序使之具备可编程性和可混合性。
6. 永远的测试版
当设备和程序连接到互联网时,程序已经不是软件作品了,它们是正在展开的服务。因此,不要将各种新特性都打包到集大成的发布版本中,而应作为普通用户体验的一部分来经常添加这些特性。吸引你的用户来充当实时的测试者,并且记录这些服务以便了解人们是如何使用这些新特性的。
7. 合作,而非控制
Web 2.0的程序是建立在合作性的数据服务网络之上的。因此:提供网络服务界面和内容聚合,并重用其他人的数据服务。支持允许松散结合系统的轻量型编程模型。
8. 软件超越单一设备
PC不再是互联网应用程序的唯一访问设备,而且局限于单一设备的程序的价值小于那些相连接的程序。因此:从一开始就设计你的应用程序,使其集成跨越手持设备,PC机,和互联网服务器的多种服务。

Web 2.0 定义的更新与企业 2.0 概念的浮现

原文链接:Web 2.0 definition updated and Enterprise 2.0 emerges
原文作者:Dion Hinchcliffe @ 4:19 pm, November 5, 2006

在这周二举行的 Web 2.0 年会上给下一代的网络应用程序的概念做出了很重要的更新。因此,这次会议在准备阶段的主要事情不是将会议的名字改成 Web 2.0 峰会,而是更加确切的讨论 Web 2.0 到底是什么,什么让业界为它如此的如此的疯狂。

就在上周末,一份名为《Web 2.0 原理和最佳实践》的100页左右的新报告对外发布了,它主要由 Programmable Web 的 John Musser 撰写,同时还得到了 Tim O’Reilly 和 O’Reilly Radar Team 的大力支持。就像很多读者所知道的,O’Reilly Media 最早在2004年提出了 Web 2.0 这个概念,并且在2005年通过一份只有5页纸的短文(What Is Web 2.0)描述了它成功的设计模式和 Web 今天所浮现出来的商业模型。今天的这份新报告,并不是对以前那份短文的继续鼓吹,它是一份有用的商业报告,通过多种方式更加清晰的诠释了 Web 2.0。

首先,这份报告深入的阐述了正在改变中的 Web 给特定市场所带来的驱动力,这些改变 Web 的技术也被成功的应用到了今天的 Web 站点里面。这些驱动力包括了接近10亿互联网用户中文翻译)、数量飞增的联网设备、用户对网络的更加依赖、结合紧密的网络生态系统等等。报告还通过大量的背景文章特 别的量化了所有这些趋势,也包括了那些在之前的 Web 2.0 定义里面没有交代清楚地地方。

其次,报告提出了关于 Web 2.0 的五条秘密,人们经常苦恼于如何把这些 Web 2.0 技术运用到他们自己的产品和服务里面。我最欣赏的是第三条:“最重要的就是用户的参与”。为什么用户要来参与呢?你需要通过某些下游的重用(实际生活中的 使用)来驱动,或者是能够传递真正的价值,再或者就是能够触发网络效应。但结果是大家对 Web 2.0 的技术充满了误解(认为 Web 2.0 所需要的就是 Ajax 或者是一个社区之类的),但这些却能够帮助他们解决不少问题。

第三,值得注意的这份报告还提到了企业 2.0这个概念的优势,它是基于 Web 2.0 技术的网络软件在组织和商业中的使用。Andrew McAfee 一直致力于为企业 2.0 提供清晰和简洁的解释,而其他还利用了他的”SLATES” 来指导大家创建和获得企业 2.0的应用软件。

SLATES 描述了将企业搜索(search)和发现(discovery)进行有效的结合,通过 Web 模型中的链接(links)来把信息连接成为一个有意义的信息生态系统,为企业内容的创作者们(authorship)提供一个低障碍的社会工具。标签(tags)可以让用户创建一个自组织的结构,提供一个像 Amazon 的推荐系统那样的智能内容建议扩展(extensions),同时利用信息通知(signals)让用户知道他们所关心的企业信息的发布与更新,例如企业内部的 RSS 输出。

虽然 SLATES 呈现了企业 2.0的基础框架,它并没有否定更高级的 Web 2.0 设计模式和商业模型。在这方面,O’Reilly 这份关于 Web 2.0 的新报告将企业 2.0方面的概念融合到 Web 2.0 之中的做法给人印象深刻。里面包括了关于自服务IT(self-service IT)的讨论,企业 IT 对长尾的需求,还有其他许多在 Web 2.0 时代能够应用于企业的重要应用。这篇报告同时也提到许多值得推荐的刚起步的小项目和评测结果,在一个相当长的列表里面。

这份报告真正有意义的部分是需要购买的(这里有一个摘要可以下载),值得庆幸的是之前那5页纸的短文中所提到的观点基本没有什么变化。事实上,这篇报告更加深入的解释并推荐了一些如何把 Web 2.0 应用到你的产品和服务中的方法,我想这些才是业界真正需要的。

最后,出于对公共教育的兴趣,我把这个报告中关于 Web 2.0 的八个核心模式在这里列出来,同时给出一些有意义的描述:

  • 驾驭集体智慧:有时候我们将这个称为 Web 2.0 的核心模式,这个就是参与的架构(Architectures of Participation:中文翻译),它通过有效的触发网络效应(中文翻译)和回馈来创建一个让人们能够更好使用的系统。
  • 数据是下一个”Intel Inside”:这句话表示了数据将变得越来越重要,它的重要性已经超过了软件本身,这个残酷的现实你必须得接受。
  • 在组合中创新:Web 正在变成一个由一片片小的数据和服务汇集而成的集合体,彼此之间松散结合,这样增加了重组的可能性和对系统与信息的无意识的使用。
  • 丰富的用户体验:Web 页面的进化将超越现有的HTML标识方式,并且能够拥有完全像软件那样体验,创造交互的新方式。
  • 软件将不会在单一的设备上提供:软件会是博客联盟群体(blogosphere:数量众多的Blog平台和聚合者)那样的水平模式,或者是像 iTunes 那样集成的垂直模式(服务器场 + 在线商店 + iTunes 客户端 + iPods 设备),这些都将改变我们软件的前景。
  • 永远的 Beta 版:软件分版本的发行将不复存在,持续更新才是新的规范。
  • 撬动长尾的力量:有效的通过 Web 来提供对微市场的服务将是”杀手级商业应用”之一,Internet 现在的形式将这种应用变成可能。
  • 轻量高效的软件/商业模型:从 Amazon’s S3 到 RSS、到 Ruby on Rails,在线软件开发的经济学模式正在发生变化,它给新的玩家提供了强大的新武器来对抗现有的对手,甚至是整个行业。

大多数人都同意 Web 会继续进化。你觉得什么才是最重要的改变呢?

如何从开发人员走向架构师

        很多架构师都是从好的开发人员逐步过渡而来的,但并非每个好的开发人员都希望成为架构师,而且他们并不是都适合做架构师。无论您是打算进行职业转型的开发人员,还是寻找能承担体系结构设计责任的合适人选的经理,都务必对此转型过程有个清楚的了解。本文将讨论从实现专家到架构师的过渡过程。

 

  在寻找优秀的指挥的时候,您首先要找的是一名优秀的音乐演奏家。但并非每个音乐演奏家都能成为优秀的指挥。架构师的专业发展方面也与此类似。越来越多的 IT 组织开始认识到良好软件体系结构的重要性,架构师职业正迅速发展为 IT 内一个独立的门类。由于要从相当小的候选范围内招募架构师,因此这就给管理带来了一些新挑战。即使人力资源部门找到了候选者,针对经验进行的筛选也比其他门类更为严格。跨越这些障碍的最快方式是要认识到,大部分好的架构师同时也是好的开发人员,因此寻找架构师人才时可能首先应该从普通开发人员中找起。招聘人员在对候选者(内部或外部)进行详细审查时,应该考虑这个观点。不过,对此资源进行挑选可能比较麻烦,因为只有极少的优秀开发人员具有成为架构师的特征或愿望。

  本文列出了开发人员成为架构师要进行的工作。我将从可能考虑进行此转型的开发人员和评估进行此转型的开发人员的经理这两个方面来探讨这一问题。我还将提供一系列在做出这些决策时要考虑的因素。

  个人特征

  软件开发团队和管理层之间的联系始终是 IT 中的一个关键所在。二者都倾向于以完全不同的方式考虑给定的问题。大部分相关技术都是讨论项目经理应如何跟踪和解释开发人员的进度和问题。但沟通不足的情况仍然非常普遍,而且这是项目失败的首要原因。好的架构师是解决这个问题的最有效办法。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应,以确保成功。以下是成功架构师的一些主要特征。

  愿意并有能力进行沟通:在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员,这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计,然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件,以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要,还需要具有制作草图的技能或使用制图软件的能力。

  具有处理谈判细节方面的经验:架构师经常需要负责讨论系统开发的技术折衷方案。优先级的冲突可能会带来实践限制、风险规避或可能导致在各个不同业务组之间需求不同。优秀的架构师能够有效地评估技术可能性,并能在不损失项目的主要价值的前提下制订开发计划来处理各种利害关系和限制。这与前面讨论的沟通技能紧密相关,但同时也要体现架构师的技术能力。好的架构师候选者应该是经常帮助对有争议的讨论进行引导的人,能够使讨论得出新的想法,而不会使其在一个位置停滞不前。

  自觉主动;积极解决设计问题:架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员,以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作,而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何,积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。

  抽象思维和分析:架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念,并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。

  开发人员经常具有很强的数学能力,而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”,而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力,但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节),这种思维能力可能较难形成。

  有些人认为,某种级别的正式教育是成为优秀开发人员的必备条件之一,我并不同意这种精英论。我遇到了很多高中就辍学的优秀开发人员。不过,对于体系结构设计工作,我的个人经验以及我对所需能力的认识都让我相信,好的架构师通常至少获得了一个有挑战性的学士学位。

  跟踪生命周期

  好的架构师通常有在具备定义良好的软件开发生命周期(Software Development Life Cycle,SDLC)的组织工作的经验。架构师必须理解在其所属专业内最重要的操作过程。这并不意味着需要有其他前提,例如,并不需要高能力成熟度模型(Capability Maturity Model,CMM)级别的工作经验。好的架构师可能来自使用 SDLC 的多个小型迭代的极限编程(Extreme Programming,XP)方法的组织。务必注意各种传统软件开发操作,如 Michael A. Jackson 的方法:Jackson 结构编程(Jackson Structured Programming,JSP)和 Jackson 系统开发(Jackson System Development,JSD)。Jackson 的研究对架构师职业发展的意义就像 Donald Knuth 的研究对程序员一样重要。架构师可以偏爱任何经典的、经过时间考验的软件系统开发方法。

  SDLC 也可以成为评估架构师合适人选的有用机制。每个 SDLC 阶段都具有能提供相关线索的特征。SDLC 包含很多小的变体,但在此部分,我将使用几乎所有方法的公共基础部分。下面的列表详细说明了 SDLC 的各个阶段,并列出了好的架构师候选者在每个阶段表现出来的特征。

  •   分析:在分析期间,好的架构师会考虑非技术影响,以便了解需求和将在其中进行开发的环境。架构师可为风险评估任务带来广泛的软件经验供参考。寻找具有丰富经验的开发人员,以帮助业务部门理解技术人员正确解释需求所需的信息。寻找在开发的早期阶段能够预计可能遇到的问题的开发人员。
  •   设计:在高级设计期间,好的架构师会收集问题空间的各个抽象元素,并就其进行沟通,以便开发团队草拟将要开发的系统的相关图表。架构师负责将需求谨慎地映射到所得到的系统体系结构的功能。在详细设计期间,他们所扮演的角色并不是核心角色,但为了根据整个系统的规则对特定模块的元素进行审查,仍然需要他们。寻找善于让团队能够预计设计决策对最终系统的影响的开发人员。寻找善于确定一些最佳构件来促进与技术和非技术受众沟通设计问题的开发人员。
  •   实现:在实现期间,架构师对项目进行引导,以确保其符合系统体系结构。他们在一线评估技术更改请求,并确定如何对设计进行调整,以最好地处理此类请求。架构师还要密切了解开发人员的进度,特别要跟踪系统中模块间的集成点的状态。寻找经常对讨论进行引导来连接多个子系统的开发人员。寻找项目经理可以依赖其快速地进行与更改和出现的问题相关的风险评估的开发人员。
  •   测试:架构师对系统集成和用户接受度测试进行指导,并负责评估进度的正确沟通的持续测试结果。寻找理解错误模式且善于将测试复查结果转换为行动计划的开发人员。
  •   维护:在维护期间,架构师将发起关于系统集成的讨论。无论处理 IT 基础设施问题,还是确保部门之间的技术合作,架构师都必须完全理解应用程序,必须快速学习姊妹应用程序的体系结构,而且必须就集成点和风险进行有效沟通。寻找具有系统集成经验且表现出快速掌握全貌的能力的开发人员。系统集成是一项独特的任务。

  架构师培养建议

  有些组织能比其他组织更有效地进行架构师培养。如果充分考虑到招聘此类新专业人才的困难,努力促成能鼓励开发人员发展为架构师的环境是非常明智的策略。但务必避免对不愿意或不适合走这条路的开发人员进行处罚。组织应该为开发人员制订多条发展路线,包括那些愿意继续担任开发人员的人。对架构师而言,资深开发人员不可或缺。他们可以实现系统中最关键的模块。通过对其他开发人员进行代码检查和测试支持,他们可帮助确保总体软件质量,而如果质量不能保证,即使最好的体系结构也毫无用处。

  组织应制订个人评估程序,以鼓励开发人员考虑其职业目标,其中要包含体系结构设计的选项。应该鼓励经理在其下属中寻找体系结构设计人才。应该实现指导计划,让架构师与希望成为架构师的开发人员协作工作。应该鼓励开发人员通过参加各种协会、撰写文章和参加会议,从而参与到专业领域中来。通过这样参与进来,可帮助开发人员从新的角度理解系统,并帮助他们更好地就其认识进行沟通。这样还能培养可提高效率的重要创新想法。

  结束语

  开发人员一旦迈出了通向体系结构设计专业方向的第一步,就可以利用很多资源来获得帮助,其中包括很多来自 IBM 的资源。有时候,此过程的最困难的部分就是第一步,而本文提供了一些线索和提示,经理和开发人员可以利用其来评估应该鼓励哪些人努力成为架构师。

SOA中的各种概念

一、什么是SOA?
        SOA(Service-Oriented Architecture,面向服务架构) 是一种架构模型,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用,使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。
二、SOA的目标
        SOA的根本目标:实现与敏捷业务相适应的IT基础,促进而不是阻碍企业达成灵活应变,从而在快速变化的时代里获得增长优势。
三、SOA中缤纷的概念
        Java的世界各种各样的名词让人眼花缭乱,有些其实很简单,但因为名次挡在门外,SOA中更是如此,这里简单介绍一下相关的一些名词:

1,SCA(Service Component Architecture)不同的软件模块通过服务组件的标准化而统一地封装起来和被调用访问。

2,SDO(Service Data Objects)则作为一种数据编程架构和API,它统一了不同数据源类型的数据编程,让开发人员可以从不同的数据源以统一的方式访问和操纵数据。可以说,SCA以面向构件的方法,简化了客户的业务逻辑编程,提高了应用的灵活性。而SDO则更进一步从数据对象 上大大简化了开发。

3,OSOA: 2005年11月,IBM、BEA、IONA、Oracle、SAPAG、Sybase、Xcalia和Zend就合作建立新的业内规范来简化SOA 应用发展达成了一致,共同发布了两项针对SOA的重要构件模型规范——SCA 0.9和SDO。此后,该团体陆续吸引了Cape Clear、Interface21、普元、Progress Software(前Sonic Software)、Red Hat、Rogue Wave Software、Software AG、Sun Microsystems和TIBCO Software 、Siemens AG等多家公司的加盟,目前成员数量跃至18家,形成了OSOA联盟。

4,EAI: 什么是EAI(Enterprise Application Integration)企业应用集成? EAI是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构,来联系横贯整个企业的异构系统、应用、数据源等,完成在企业内部的 ERP、CRM、SCM、数据库、数据仓库,以及其他重要的内部系统之间无缝地共享和交换数据的需要。有了EAI,企业就可以将企业核心应用和新的Internet解决方案结合在一起。EAI(企业应用集成)将进程、软件、标准和硬件联合起来,在两个或更多的企业系统之间实现无缝集成,使它们就像一个整体一样。尽管EAI常常表现为对一个商业实体(例如一家公司)的信息系统进行业务应用集成,但当在多个企业系统之间进行商务交易的时候,EAI也表现为不同公司实体之间的企业系统集成,例如B2B的电子商务。

5,ESB是企业服务总线(Enterprise Service Bus)的缩写。企业服务总线是一个灵活的用于集成各种应用和各种服务的连接基础架构。企业服务总线能够通过简化应用和服务之间接口的数量、接口大小及接口复杂度等方法使客户的面向服务体系(SOA)更加的强大。企业服务总线提供以下功能:
        在服务与服务之间路由消息;
        在请求者与服务者之间转换传输协议;
        在请求者与服务者之间转换消息格式;
        处理来自于各种异构源的业务事件;

6,Web Service: Web Service就是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。Web Service所使用的是Internet上统一、开放的标准,如HTTP、XML、SOAP(简单对象访问协议)、WSDL等,所以Web Service可以在任何支持这些标准的环境(Windows,Linux)中使用。注:SOAP协议(Simple Object Access Protocal,简单对象访问协议),它是一个用于分散和分布式环境下网络信息交换的基于XML的通讯协议。在此协议下,软件组件或应用程序能够通过标准的HTTP协议进行通讯。它的设计目标就是简单性和扩展性,这有助于大量异构程序和平台之间的互操作性,从而使存在的应用程序能够被广泛的用户访问。

7,SOAP: SOAP即简单对象访问协议(Simple Object Access Protocol),它是用于交换XML编码信息的轻量级协议。它有三个主要方面:XML-envelope为描述信息内容和如何处理内容定义了框架,将程序对象编码成为XML对象的规则,执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。例如,你可以使用 SMTP,即因特网电子邮件协议来传递SOAP消息,这可是很有诱惑力的。在传输层之间的头是不同的,但XML有效负载保持相同。

8,UDDI: UDDI 的目的是为电子商务建立标准;UDDI是一套基于Web的、分布式的、为Web Service提供的、
信息注册中心的实现标准规范,同时也包含一组使企业能将自身提供的Web Service注册,以使别的企业能够
发现的访问协议的实现标准。

9,WSDL: Web Service描述语言WSDL就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言,
用于描述Web Service及其函数、参数和返回值。因为是基于XML的,所以WSDL既是机器可阅读的,又是人可阅读的。

10,BPEL: BPEL是一门用于自动化业务流程的形式规约语言。 用XML文档写入BPEL中的流程能在Web 服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。 所以,通过允许顾客们在各种各样的创作工具和执行平台之间移动这些流程,BPEL使得他们保护了他们在流程自动化上的投资。尽管以前想使业务流程定义标准化,但BPEL已经引起了史无前例的兴趣,而且它最早在软件供应商中获得大量认可。

11,IBM MQ: 消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信,而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。

12,JMS: 在不同系统之间交换信息的一大障碍是如何在精确交换和格式化数据方面取得一致。Java Message Service(Java消息服务,简称JMS)通过提供一种与J2EE应用程序或传统系统交互的方法部分的解决了这个问题。 JMS的通用接口集合以异步方式发送或接收消息。异步方式接收消息显然是使用间断网络连接的客户机,诸如移动电话和PDA的最好的选择。另外,JMS采用一种宽松结合方式整合企业系统的方法,其主要的目的就是创建能够使用跨平台数据信息的、可移植的企业级应用程序,而把开发人力解放出来。

13,IBM MB: Message Broker是IBM 的应用整合中间件,是IBM WebSphere 业务整合解决方案的重要组成部分之一,用于企业应用整合领域。它的前身为 WebSphere MQ Integrator Borker 是一种Esb的实现