Resource Oriented Enterprise (ROE)面向企业资源整合

09-09-14 banq
WWW已经整合了整个世界的信息资源,面向企业的资源整合只是其一个小的分支罢了。

作为企业资源整合,如果不从WWW万维网这么大道至简的世界性普及技术中获得启发并借鉴,还要另外重起炉灶搞一套企业资源整合,这好像有点简单事情复杂化,或者过于商业利益,从这点来看,基于SOA的所谓企业资源整合,相比抽取WWW万维网精神本质的REST,好像整个业界又被IT商业厂商给误导了一次。

说得直接点:SOA路线有可能是错误的,舍本求末了,简单事情复杂了。

Resource Oriented Enterprise (ROE)一文从企业资源整合角度比较了REST相比SOA的方便性:

假设信息请求者是银行职员,专门与私人客户打交道。这种客户关系是一个相当复杂的信息对象,例如姓名和地址等个人资料,以及该客户帐户和以及抵押物。除了这些,还有其他信息:如签订的合同和行政记录的文件数目。

那么有可能所有这些数据存在4个或更多的数据仓库Silo中。

传统SOA方式,我们会将做一些对主机系统的调用,以便获得看到个人数据,然后到另一个系统,查看帐户资料和抵押物的细节,还要使用该文档管理系统来阅读相关合同文件,等等.

在ROE中,只要使用统一的URI接口就可以,非常简单,通过浏览器浏览客户编号是12345的个人资料:

/privateCustomers/12345

如果想查看该客户的帐户和抵押物,沿着这个URI深入下去:

/privateCustomers/12345/accounts/A1

而/privateCustomers/12345/accounts/A1/docs/balance/2009/01

则是该客户端2009年1月的财务报表输出,当然是一个DOC文本类型输出。

所以,通过URI以及GET/POST/DELETE方法等统一接口操作,可以对企业资源进行方便地整合,以使用者更方便易懂的方式表达出来。

比如,如果我是这个银行职员,经过第一次培训使用后,那么我就会对其他客户,如54321的客户资料学会了查询:/privateCustomers/54321/accounts/A1

在这个URI后面,其实整合了多个资源,/privateCustomers/54321/accounts/A1只是表面链接,真实网址可能是指向另外一个IP或域的,一则悄悄实现负载平衡,二则整合了不同主机系统的资源。

所以,从这里也可以看出,传统SOA以Web服务调用,是将业务方法直接暴露给用户,用户通过Web服务知道调用这些业务方法,但是有一个问题回避不了,这些业务方法存在不同的主机上,用户在进行复杂的WEB服务定位再调用之前,还需要进行主机位置的侦测,如果这些主机IP不得不调整,那么用户必须获得通知,这实际将IT知识直接和业务知识耦合在一起。

有人说,那就用域名替代IP?这个思路对了,使用不同子域名替代IP,但是你得记住几个子域名,如果子域名改变怎么办?所以,最好的办法就是学习google,域名永远只有一个www.google.com,统一URI,统一唯一入口,www.google.com/gmail你可以获得mail资源,http://www.google.com/services/可以获得企业服务入口。

这就是REST架构风格的一个核心,REST实际就是WWW万维网的经验总结。只不过我们把这个经验转移到企业内部网中来,不是很好吗?何必在企业内部网因为企业的特殊性为借口,另外重新整一套新玩意新标准呢?长官意志思维的人经常愿意搞标准,画地为牢。

在ROE一文中还提到云环境的整合,企业网可能与合作伙伴整合,那么我们可以将客户URI

/privateCustomers/12345 转向到/corporateCustomers/09876/attorneys/att2

使用REST框架,可以在我们项目的服务类代码上直接标注资源URI,如@PATH(/privateCustomers/{customeID})

但是一旦发生URI变更,但是又不能影响原来的URI结构,只能实现服务器端的转向,Apache的mode_rewrite功能很有效,但是这种方式太土,太手工化,和业务脱离太远,可控性不强。

看来实现ROE,还需要REST框架拥有URI转向的功能,所以,好的REST框架应该将表现URI和资源服务URI进行分离,

但是目前所谓REST框架,只是给资源服务打上URI,属于Web服务的变种,不真正具备REST精神,这和这些框架开发者的经验背景以及对REST理解有关。

在企业中实现资源整合真的很简单,关键看你有没有WWW万维网背景知识。

[该贴被banq于2009-09-14 12:15修改过]

[该贴被banq于2009-09-14 12:15修改过]

    

2
banq
2009-09-14 16:27
REST带入企业还有其他好处:

1. REST的应用将web分散化的方面带入了企业的世界,并且支持一个网络的系统里的设计者和开发者可以创建并发展他们的组件,而不需要承担把他们聚到一个房间里来讨论API所消耗的资源与时间成本。

解读:Web分散户开放性是最好的,没有什么基本约束,约束就是REST,而你如果以框架或API或者SOA形式整合应用,那么肯定要开会,每个人自以为是大牛,神人一样,汇聚到一个房间对API进行高度抽象和讨论,共产主义模型是可以出来的,但是消耗的资源与时间成本是可观的,没有谁耗得起。

2.我相信REST对于超媒体的运用[...]使得维护,部署与版本控制更加的容易,这一点在一个应用的维护阶段就转化成了业务上更低的成本。

解读:REST的软件维护和部署及其版本控制是有好处的,浏览器模式的好处也是得益与它。

原文:REST的业务用例

snakemic
2009-09-15 20:09
1楼 倒数第5段

长官意志思维的人经常愿意搞标准,画地为牢。--->貌似写错了个字

猜你喜欢