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

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修改过]