大概在十年前左右,开源软件还是“足够好”的,因为它是可行的,通常也是低成本、少麻烦的商业软件替代方案。而现在,软件都在变得越来越开放(虽然并不一定是完全开放),也许有的非开源软件对你来说已经是“足够开放”。
这里最好的例子莫过于Amazon的云计算API,虽然它既不是开源的也不是开放标准,但事实上已经被认为是真正的业界标准了。抛开不完全开源的底层代码不谈,AWS
API似乎已经足够便于你集成、连接和服务。

应用集成从1980年代中期就已经成为企业软件的痛点,也是那个时候我第一次开始做IT报道。同样的老问题让不同的软件共存,大部分是因为业主权益要比开放标准高。此外,应用集成也始终是购买者被最新的应用吸引之后产生的想法,集成的痛点经常被遗忘。

随着信息技术的高速发展,其承载的基本设施以及后方所提供的应用服务在不断完善.云计算的概念受到社会上更多人的关注和论证,搭建稳健、高效、多样化的“云上日子”正受各大IT厂商所追捧,其大部分IT厂商都不约而同地启动了各自的云计算战略。但是“云计算”这个大概念的背后,各项现有技术如何实现合理整合,对外标准如何制定,为迎合新时代新需求的商业模式如何等,诸如此类的问题冲击着TT行业。特别在随着SaaS的愈发火热.再者SOA架构的深层应用,这两种概念开始引出了一些新的混淆,模糊了看待技术发展的界限。从软件技术角度理解SOA,一切都以服务为核心,其对外部提供了一个统一的契约.而服务由组件构成,组件是若干操作的集合,操作对应具体实现的程序模块
服务是通过对业务过程模型的分析而识别出来,专注于实现应用逻辑。而应用逻辑属于业务逻辑的一部分,设计直接源于需求中的用例。每个服务能够实现若干功能,这些功能由组建而不是操作来实现。这样格外的抽象去除了两个相对独立的功能之间的耦合度,同时实现一个粗粒度的远程接口。在具体实践上,只要能提供服务的技术都可以实现SOA思想。若要让服务能够更广泛的被外界所应用,在互联网上发布,那么就要遵循一定的规则标准。这样的标准包括:SOAP、Java
API for XML-based RPC (JAX-RPC)、WSDL和WS-*
规范等等。另外它的实现还需要安全性、可靠消息传递、策略管理以及控制支持。SaaS,Software
as a
Service,软件即服务。SaaS是一种软件服务提供的模式,是一种将软件部署为托管服务并通过lnterrnet进行访问的模式。SaaS是基于互联网提供软件服务的软件应用模式。由Saas提供商为企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台,并负责所有前期的实施、后期的维护等一系列服务,企业无需购买软硬件、建设机房、招聘IT人员。而是终端客户根据自己实际需求,通过互联网向厂商定购所需的应用软件服务,按定购的服务多少和时间长短向厂商支付费用,并通过互联网获得厂商提供的服务。用户不用再购买软件,而改用向提供商租用基于Web的软件,来管理企业经营活动,且无需对软件进行维护,服务提供商会全权管理和维护软件,软件厂商在向客户提供互联网应用的同时,也提供软件的离线操作和本地数据存储,让用户随时随地都可以使用其定购的软件和服务。即可通过互联网使用信息系统,便于用户通过互联网托管、部署及接入,从而根据用户实际业务情况进行系统搭建及应用。近年,SOA和SaaS模式二者的社会关注度都非常高,甚至在市场宣传中常常让人容易混淆。SOA作为一种软件架构方式,所指的“服务”既是划分的软件模块化单元,也是软件中模块间交互模式——表现为服务供应和消费关系:而SaaS模式中所描述的“服务”是供应商向终端用户提供的增值产品,是产品所涵盖的应用服务。也就是说,SOA和SaaS这二者所提及的“服务”是分别两个范畴上的概念。但在更高层的角度去分析SOA和SaaS之间的关系,却发现二者都在不同层面七具有支撑作用,可以实现一种很好的外接模式,使得软件更具有灵活件和生命力。首先,SOA提供的是一个松耦合的系统,能够帮助SaaS对终端用户提供更多个性化的服务。面向服务架构的软件是通过这些服务之间定义良好的接口和契约联系起来,软件模块的交互也以标准协议达成,使得松耦合的软件模块能够容易的被替换或升级。特别是针对“长尾理论”所描述的大量冷门商品,在网络时代,商品储存流通展示和渠道足够宽广,商品生产成本和销售成本急剧下降时。这些需求和销量不高的产品亦会有人购买,甚至超过主流商品所占据的市场份额。也就是个性化的需求市场将逐步放大,这样就使得SaaS厂商能够更好地按照终端用户自身的偏好或者要求,聚合不同的软件模块,为终端用户提供个性化的服务。例如,在一个基于SOA的房产中介信息平台中,可以为美国用户使用Google
Map提供的软件模块显示地图和卫星图,也能按照中国的用户要求定制,聚合中国本地开发的地图软件模块,更好地提供本土地图细节。这样的软件模块替换,在SOA下更加容易实现,甚至能够低成本的为每个客户定制,而不失SaaS规模化的优势。其次,SOA推动的软件生产工业化改变着SaaS厂商之间的生态系统。近年有人提出软件开发工业化的概念,类似于汽车行业或者更多已经成熟的产业,未来的工业化软件开发将像堆积木一样,只要把标准模块设计出来,不同的产品只需要进行不同的组装即可使用。这将彻底颠覆传统开发的模式,将转而根据既定时间和已有资源量根据市场需要来相应变动开发计划
软件工厂的模式将更容易控制开发成本、管理开发组件、缩短开发周期,是开发者能够专注于完成重要功能,保证开发计划高质量地完成。新的软件开发模式将逐渐使开发规范与其基于的技术分离出来,而向更高级别的抽象应用发展。而SOA所描述的思想,正好让IT变得更有弹性,以更快地响应业务需求,实现实时企业等。作为面向服务的体系架构,SOA需要提供一套统一的软件标准或协议,用软件工业化生产的角度来看,SOA架构必须支持软件的工厂化生产。同时,这一这个变革影响着SaaS的生态系统,使得SaaS从单一供应商提供所有终端用户需求方面的服务的状态,逐步过渡到众多供应商分工协作,系统由各个供应商所提供的不同服务所聚合而成,从而为终端用户提供强大的全方位的服务支持。当这种融合的模式发展到一定成熟程度,每个IT服务提供商均有所针对的细粒度市场,使用SOA服务的机构用户或个人用户对外逐渐摆脱对单一厂商、供应商平台技术的依赖,加大对自主开发或外包开发模式的控制力度,甚至将行业经验反哺到整个S0A市场,重新包装形成自身“一站式”的高层服务对外提供支持。SOA技术架构改变了整个软件的构建方式,推动着企业IT应用创新,SOA的意义就在于让IT变得更有弹性,按需聚合功能服务,使IT与业务保持同步,从而更好地驾奴变化
而saaS能在此基础上,让终端用户能够以服务组合的形式快速搭建复合的灵活应对变化的系统,甚至整合SaaS厂商所提供的特殊领域的服务,实现个性化需求的极大满足,提高生产和管理等各方面的效率。目前,国内外各大IT提供商都积极进入SOA市场,并力图解决厂商内部产品和客户方面的功能整合需求,扩展其SaaS模式下按需服务的提供能力。同时,传统的EAI和MOM厂商也在重新定位为ESB(企业服务总线)或SOA服务供应商
未来软件行业将会在这两者融合的市场下,迎来新一轮的春天,千姿百态,大放异彩,请拭目以待。(end)

图片 1

在云计算时代这两个因素也没有改变,因此我怀疑新的基于云的集成服务也会如此。因为企业软件实践中一些云服务首要集成策略和彻底改变,我也对此充满希望。

这确实是一个不错的思路,但我并不完全赞同这一观点。相反,我认为下面三种技术的融合才是现在的趋势,将会带来新的部署应用的方法。
SOA——这一切的基础正是SOA。(译者注:SOA即Service
Oriented Architecture,面向服务架构。)创建离散、松耦合并且能够被轻松调用的功能是这一切的先决条件。SOA能够动态地串起整个
IT行业最优秀的各种类功能。随着SOA正在往轻巧化发展,像JSON和REST这样的开放途径,美好的未来正在渐渐变得更清晰。

早在1980年代,企业内部部门应用通常彼此不兼容。集成客户和合作伙伴软件呢?忘了吧。在这个巴别塔场景中,大多数企业在不同的操作系统、数据库、开发语言上构建一种混合应用。

云计算——如果说SOA是这一切的基础,那云正是发展的转折点。SaaS应用完完全全地打乱了传统应用市场。类似Salesfoece.com、
Workday以及SugarCRM这样的应用迫使传统开发商重新考虑应用策略。而且这些SaaS应用大多数是面向服务的,并且从第一天起就开放了
API,为应用产业带来了革命性的创新!SaaS为更多的公司开发优秀的应用提供了机会。

下一步发生了什么?理想中,软件和硬件制造商就标准、接口和其他的让所有事物更好地彼此协作的基础上进行协作。互操作性和集成问题逐渐消失,刺激创新和创新者赚钱模式的创作出现。相反专属打包软件创造出来,短期的东西为那些从一个厂商那购买一切的购买者安置好。

社交网络——因为SOE的作用以及云计算的发展,社交技术变得像催化剂一样。像Facebook和Twitter这样的网站都开放了不少的API,而且因
为其庞大的用户基础,可以为应用提供很多新的市场和客户拓展机会。Salesforce.com本质上也已经是在提供云社交服务来加强这种联系。

“密月阶段”将组合价格提升,并导致套件过剩。开源操作系统(尤其是Linux)的出现,以及厂商导致的应用锁定尤其让人感到任务繁重,随着创新者创建了比一些软件应用组件更好的点产品。一些企业想要完全的开源或者混合开源和专属软件,但是都面临着集成的问题。

因此,这一切的趋势是企业会更多地使用利用开放API来创建新应用,而不是像以前一样从头开发底层技术。反过来这也开辟了新的机遇,新老企业都能通过发布
能嵌入应用里的服务来创造新的营收流。像Pitney
Bowes这家主要做邮政测量的传统公司现在也开始发布航运和位置追踪服务,并且正在成为很多这样的新型应用的标准。

他们还是做了。在TechTarget最近的调查中,应用集成是软件架构师、工程以及C级别执行人员首要的云问题。在最新的2013
TechTarget Cloud Pulse
Survey中,很多受访者表示他们忽视了自定制和集成问题,直到问题出现。还有64%的受访者表示在云和本地系统之间连接数据、应用和流程是立即要解决或者近期要解决的问题。

所以,这是一个令人兴奋的发展趋势!但我并没有看到任何它能很快任何完全取代系统的任何证据。有的应用能够很好地适应现在的变化,而有的仍然只能和以前一样运行在企业内部系统上。新类型应用正随着云计算的出现和发展而飞速发展,但并不能完全替代这些企业自建的内部系统。
能看到的是这些基础系统也正在渐渐开放自己的主要服务的API,很多时候还会伴随着商业交易,但随时可能会有翻天覆地的变化。

同样的,TechTarget Applications Survey
2012的受访者将集成和自定制列为软件即服务(SaaS)应用(每个14%)的首要问题。在Cloud
Pulse调查中,SaaS应用成为34%的受访者的集成挑战,其项目不能同其他云端或者内部的项目交互。再一次,自定制同集成紧密相连:即时有自定制,34%Cloud
Pulse受访者仍旧表示SaaS应用不适用于其客户端业务需求。

你的观点是什么?欢迎讨论!
 
原文链接:mikecurr55.wordpress.com

根据Cloud Pulse调查受访者,Ovum高级分析师Saurabh Sharma和CIMI云咨询师Tom
Nolle所述,增加了云应用到企业应用组合中,解决了棘手的问题。他们再一次告诉我,奇怪的应用混合拼凑在一起,遗留系统、移动、云等等,但是在这个案例中,它们处在动态资源分配环境中,每一个的复杂性导致集成更加困难。事物转移到云端,转移的应用和数据的集成就更难实现,Nolle说道。

(文/linux伊甸园)    

专属保护主义,也是我上面提到的集成障碍,确是大多数SaaS厂商支持的,Sharma表示,产业不可能为云计算表转化每一种架构,让事情变得更容易。此外,Web服务应用程序接口(API)并没有承诺为SaaS和本地应用之间清晰的集成交付银弹。那是因为本地应用在不同的标准下开发,通常需要更加自定制的代码开发,来和SaaS环境交互。

即使人性的贪婪锁定了标准,但是对于云端和本地之间的应用集成还是有希望的。平台即服务(PaaS)会协助开发者构建与云兼容的应用。Cloud
Pulse受访者在被问到是什么因素导致他们选择了其PaaS提供商时:

– 49%表示提供商是已经计划的云生态系统的一部分;

– 36%表示提供商支持应用开发语言;

– 35%指出提供商和现有架构集成;

– 31%指出提供商比其他提供商有更好的性能或者功能;

– 25%报告开发者已经拥有这个PaaS平台的相关经验。

PaaS平台主要用于开发和部署云应用,63%的受访者说道。PaaS也在SAP这样的应用中起到扩展SaaS产品的作用(43%),开发和部署移动应用(40%)和提供应用测试环境(36%)。

面向服务架构(SOA)以很多方式提供了强有力的集成基础,包括通过暴露依附开源标准的服务降低集成成本。在Web服务范式上构建,SOA应用可以轻松迁移到云端,并同其他的基于Web服务的项目集成,他们很好的咬合了云的应用到资源的关系模型。

转移到DevOps团队需要开发者考虑部署战略和IT来提供互操作性以及为开发者整合上下文环境。

新的基于云的工具和服务提供了一些安慰,这些包括现在的应用集成工具和服务,比如Dell
Boomi、Informatica云集成平台、CloudSwitch集成服务、IBM Cast
Iron、MuleSoft等。新工具和服务也在不断发展。比如Tasktop关于软件生命周期集成服务的介绍,承诺将集成策略固定在企业的业务计划中,是预先的,而不是事后才做。

更多应集成期望

我不久前曾看到对于“集成架构师”职位的招聘广告。如果这要转移到拥有一个内部集成专家,我完全同意。集成可不是“马后炮”,尤其如果这是DevOps团队成员的核心关注点。

开放标准会是应用集成和互操作性的圣杯。直到厂商找出开放标准组成的赚钱模型,然而,放入一些新的集成工具、服务以及内部专家来工作更容易。