Topo平台化过程中的一些想法

前阵子整完项目内部的异步服务，大概有两个月的时间都没有再写过代码，让我挺郁闷的。整天的讨论方案出方案，主要是融合静态融合多个网元系统到一起，虽说对设计能力有些提升但不是最喜欢做的事情。

最近终于有机会写代码了，刚把方案给了项目老大，不过老大忙着跟设备部讨论接口，估计也没时间看。这次主要的目标是重构原来最烂的Topo模块，整个代码乱的要死，完全不管什么mvc，多态也死的干干净净，到处是百行多的IF和ELSE，重构之后还要融合，要把两种网元设备在一个模块里面显示，当然两个项目的代码不能简单的拼凑在一起，否着等其他的项目合进来的时候岂不是还要在上面继续折腾。

思路就是面向服务的架构，虽然是在同一个虚拟机里也不妨碍这种轻量级的SOA思想的实施，说白了，ServiceProvider就是最简单的SOA实现。我也是利用ServiceProvider这种概念来设计的Topo平台，通过定义SPI来让业务平台实现，解决了Topo中数据加载的问题和页面加载的问题，当然如果把所有的事情都委托给别人去作也不现实，还需要提供Topo组件的默认实现，和相应的API，让用户基本可以复用这些组件，同时声明自己的监听器，菜单生成器和Layout来定制组件。象类似这种组件，不应该让用户去扩展，集成，而是怎样提供接口（API）去使用他，让用户基本可用，逐步定制。

第一阶段基本上是沿用原来的使用组件的方式，直接继承ILog（IBM的TOPO图形工具包）组件，并重写了原来的模型层，去掉界面显示相关的（当初怎么能把界面放到模型层做。。 ），低层用RepositoryDelegate来委托给具体业务层加载具体数据。

第二阶段准备采用桥接的方式去掉对ILog组件的强依赖，我也受Swing UI层设计的启发，当然其实现在大多数集成框架都是这么干的。

设计中也在恰当的位置或按以往经验有性能瓶颈的地方预留了拦截器作为后期优化的SPI。

最近也在看dubbo，看的不是很明白，行业还是隔着的对里面有些东西不是很了解，希望自己可以仔细的看看，因为director是ITeye上面的牛人，写的确实很好，很多地方可以借鉴，之前看OSGI的Framework也对这次融合有蛮大的帮组，继续加油，工作也快两年了，感觉还是不行，不知道是不是行业就是闭塞啊。。