模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。

作者 Matthieu Hug 译者 崔康 发布于 2009年2月20日 上午11时37分
云计算正在快速成为当代最耀眼的技术之一。它悄悄起源于若干先进技术,例如网格计算、虚拟化、SalesForce.com新型基于订购的业务或者Amazon的电子商务平台。最近,大型软件厂商对云计算表现出了浓厚的兴趣,其定义如下:
“一种新型的计算模型,数据和服务分布于大规模可扩展的数据中心,可以通过任何连接的网络设备访问。”
就个人而言,我认为云计算令人兴奋,它会刺激大量的创新,一方面是因为它提供了根据使用付费(pay-per-use)的基础设施,降低了创新的成本和风险,但更主要是因为它提供了一种构建信息系统的基础设施,由需要协作实现共同目标的不同组织分享,例如,跨企业信息系统。
本文专注于云计算领域的跨企业信息系统架构。第一部分简要介绍了云计算,第二部分则研究了云计算中的跨企业信息系统。
云计算在很多方面把通常“痛苦”的问题留给了别人:
我们可以把云计算模型分为三种:
IaaS的最佳例子是Amazon Web服务。Amazon提供了三种基本服务:存储(S3)、计算(EC2)和队列(SQS)。基础设施即服务的关键价值是“弹性”,例如,可以基于特定时间点上的使用情况购买或放弃基础设施元素(存储、服务器...)。例如,Amazon对服务器按小时收费,对存储按Gb/月收费。
PaaS则是提供了一系列工具,构建于IaaS基础之上,并享受它的灵活性、健壮性和安全性,资金投入却不多。PaaS的目标是使开发人员创建由云托管的信息系统。现代PaaS的目标是能够利用云提供的服务,表现层应该与Web和mashup技术很好的集成。
例如,BPM-as-a-Service是一种特殊的PaaS。现在,大多数PaaS是以数据为中心,而不是以过程为中心。它们通常允许你定义数据模型和不同的形式和外表以协作。业务逻辑通常在动作中定义,遵循MVC模式。以数据为中心的PaaS可能难以构建用于协同业务伙伴之间活动的系统。
PaaS背后的一个核心创新是Dev 2.0模式(应用Web 2.0技术的开发工具、敏捷方法和域特定语言的大量使用,而不是多用途程序设计语言)的出现。Dev 2.0使开发人员更具生产力,让非开发人员参与业务逻辑关键元素的定义和验证,例如业务流程、业务规则或者表单定义。
另一个很多PaaS的核心创新是能够通过表现层或者一系列服务(组成新的解决方案)透明的展示信息系统,不论是不是基于云。
SalesForce.com是SaaS的开拓者,用事实表明了采用“软件即服务”是可行的、节约成本的、安全的。他们在云计算刚刚萌芽时就展现了这种模式的强大力量并建立了整个云计算生态系统。
如今,云计算在很多方面表现出了活力:
MEIS的目标是快速建立一种合作伙伴关系,不论是为了提高知名度、管理意外、促进电子数据交换、协助兼容或是加速合资或合并。
直到今天,跨企业信息系统往往采用由为了某一目的多方协作中的一方托管的门户网站来实现,无论是供应商的OEM门户,还是零售商的分销门户。
这种方法导致了明显的低效性、风险和缺乏灵活性,因为其中一方要承担所有的建设、维护和运营成本。业务流程通常会尽可能地简单以满足所有参与方的共同需求。最后但并非最不重要的一点是,门户网已经被证明难以与参与方的系统和流程集成,因为它们没有公开与表示层关联的服务。
如今,云计算通过跨企业信息系统使这一点成为可能,相关各方都能够参与系统的开发,从根本上平衡了开发成本,同时提供了更优异的能力与任意一方的现存系统和基于web的企业内部网集成。

图1 MEIS技术架构
图 1 显示了构建于平台即服务基础之上的跨企业信息系统。其中包括:
显示层需要足够灵活以支持通过不同的技术和跨域广泛的设备(浏览器、手机、RFID...)执行用户任务。
开发工具必须从某种程度上是技术中立的、基于标准的、直观的、支持快速实现、质量保证和部署过程。
业务活动监控和报告必须易于定制以满足各方的需求。
理想情况下,MEIS的基础PaaS运行在一个先进的IaaS上,保证了灵活性、健壮性、可靠性和安全性。
组织和角色必须易于管理,并且可能依赖于单登陆基础设施。各方必须能够无需其他方协助即可管理自己的用户。
面向流行服务和解决方案的连接器是开发高品质MEIS的一个基本因素,不论是收集物流或者市场信息。这些连接器将提供一种技术访问服务,融合了基于web的技术(SOAP、ReST、ftp、http等等)和格式(EDI、XML等)。
人力工作流必须无缝集成到MEIS中。在MEIS流程环境中构建是高度迭代的,流程可能从以人为中心进化为部分自动化:这种演变必须尽可能地简单。
最后但并非最不重要的一点是,平台必须确保与每一方现存系统的有效整合。特别是这意味着平台必须支持开放的协作流程和私有的整合流程。
以过程为中心的PaaS的逻辑架构如图 2 所示。许多PaaS过于以数据为中心了,没有提供建模和执行过程的能力。这种业务逻辑必须单调的用MVC框架编码,难以改变、监控和报告。
使用以过程为中心的PaaS对跨企业信息系统至关重要,因为它们帮助企业协同工作并同步其活动。如今,这种同步通常用过电子邮件或者传真的方式完成,会导致错误和低效。例如在航天工业中,多企业的一个关键流程是运输和接收部分。对于如何运输和接收,供应商和买家必须衡量关键指标(尺寸...),然后比较它们的结果。这会有测量误差、真正的差异...会引起异常,未来需要管理和审计这些。这表明跨企业可跟踪性非常重要,比如化学品或者制药行业。

图 2 以过程为中心的PaaS逻辑架构
通常来说,在一个商业圈中(比如供应链或者一个产业),没有哪一个独立的商业伙伴有能力(或者愿望)为整个商业圈提供所需的IT资源。以过程为中心的平台即服务结合成的云计算提供了开发一种新型企业系统——跨企业信息系统的难得机会。
Matthieu Hug是RunMyProcess.com的首席执行官,RunMyProcess.com是一家以过程为中心的PaaS供应商。他毕业于SupElec,并在Georgia Tech获得硕士学位。
查看原文:Will Cloud-based Multi-Enterprise Information Systems Replace Extranets?
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
本采访是在伦敦举行的QCon2009上记录的,Ian Robinson和Jim Webber探讨了如何将Web作为整合平台以及REST在理论上和实践中的好处。
项目管理对于项目成败至关重要,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。书中从应对实际风险的角度出发,讲述了从项目启动、项目规划到项目结束的整个管理流程,展示了作者的思考过程。本迷你书从原书中精选出5个章节。
在这个演讲中,Fred将会揭示敏捷的一些外在因素,并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看,Fred认为:工具、管理体系都不能让你变得敏捷。敏捷的成功,植根于士气高涨、充分授权的工作者身上,他们能够以不同以往的方式思考问题。
Eben Hewitt的新书《Java SOA Cookbook》从Java实现的角度讨论了面向服务架构。Eben在书中讨论了SOA基础、工具、最佳实践和SOA治理等主题。
Mark Richards的新书《Java消息服务》第二版覆盖了JMS的许多主题, 包括发布和订阅模式以及点对点模式,消息过滤和事务等。InfoQ与Mark谈论了跟他的新作。
没有回复
关注此讨论 回复