一、我的设想
建立一种Widgets标准服务,可供Mashup,形成面向这种标准服务的架构。
于是,Top Widgets诞生了,这是一个极尽简化的Widgets引擎,也可以说是个适合永远不最大化的浏览器加上类似IE的略为简化的插件结构。尽管最近没有花太多的功夫去更新,但我对它的期望是很高的。
于是,Top Library诞生了,这里将包括一切关于Top Widgets的库,比如引擎的插件、比如供Widgets开发的网页脚本库。其中最有意义的可能是那个轻量级代理服务器。在这里,我也希望能够统一脚本库,并升级成为一个良好的Rich Web Platform,模拟一个操作系统的行为。一个比较简单的范例是iGoogle,但它更倾向于Ajax体验,而我更倾向基于更简单的Widgets标准,实现松耦合、易过渡。大家也可以看看现在所谓真正的Mashup,可以参考http://sandbox.afrous.com/,离应用还太远...
于是,我同时在思考,如何能够在现有的环境下顺利地将Mashup形式的SOA顺利应用在现有的服务器平台上(中间件、流程引擎等)。
二、我的困难
1、个人时间总是不够的,但目前在这方面做思考的人并不多,更何况是没有商业背景的思考呢?当然我也不可能站在商业背景下进行思考,因为我本身就希望能够拿出一个放诸四海皆可用的方案,而不是成为IBM或者Oracle抑或微软甚至JBoss的嫡系。如果做出来的东西不能松耦合,还不如不做。单挑真的很累啊!
2、带来规划之外的系统压力。仔细想想平时做项目的经验,做个接口要考虑是否会连累自己的系统,会不会被来者拖垮,会不会被客户压死,连用iframe都要考虑,取不到数的话,岂不是大白片子了。这只有两种解决方法:一个是在服务规范上提供catch机制,那会降低Mashup的效率;一个是严格控制面向服务的规划,翻来覆去地计算一个服务究竟有多少实际用户,防止虚调用带来的压力,这也使业务敏捷成了IT规划的负担。
3、最恶心的一个接口:SSO的问题。目前我的方案是一个轻量级的代理服务器,统一管理一下cookie,绕过浏览器。还是松耦合的原因,我无论如何不能做成google或者yahoo那样子,自由联盟也不行。
三、在企业应用中的位置
我喜欢画图...
解释一下:
1、BPEL流程、Adapter等应用所用的工具性质数据库,Adapter逻辑上有一部分处于接口数据库下面;
2、完整、供统计需求使用的数据库;
3、提供即时数据路由的数据库;
4、导入、导出数据;
5、将原子服务封装到流程、业务层面,并返回注册到服务层;
6、注册到企业ESB;
7、很正常吧...;
8、提供辅助Mashup的功能,应该本身就是Mashup应用;
9、将Mashup资源注册到引擎上。
可能还不全,慢慢考虑吧。