Widgets、SOA与Mashup

一、我的设想

建立一种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资源注册到引擎上。

可能还不全，慢慢考虑吧。