松散耦合架构下系统模块管理面临的挑战

今天在公司的时候遇到一个问题。我们的软交换系统设计的时候，参考了IMS中业务，控制，承载相分离的思想，及软交换只负责处理呼叫控制，对外提供呼叫控制的接口，通过应用服务器供业务程序调用，来完成特定的业务。对于交换机的增值业务，我们是放在应用服务器之上进行处理的，当初考虑这样处理的时候是要把业务处理的东西都从交换模块中剥离出去，以便于后续的扩展，并且保证增值业务对核心控制模块没有影响。

当初这样设计的时候，虽然我们的设计团队没有明显的意识到要采用“微内核+松散耦合”的系统架构思路，但是我们确实是按照这样的思路进行实施的。及软交换是整个系统的核心，业务（包括增值业务和其他的业务）为扩展点，整个系统，包括核心交换，业务，资源，都是松散耦合的。

今天遇到的问题是，其他业务和增值业务中存在类似的业务，要同时对呼叫进行控制，这样就产生了一个控制冲突。为了解决这种冲突，并且考虑都流程的复用和中心控制点，我们不得已，把增值业务的整个流程作为应用服务器的接口对外开放，并且在增值业务处理完毕后，把状态通知给其他业务。这样，为了实现一个流程，绕了好大的一大圈。

这就是我今天要说的问题，我们为了解耦，把系统设计成松散耦合的，在享受松散耦合带来的方便的同时，没有很好的解决松散耦合带来的更大的复杂度，便使这种松散耦合系统的优势大打折扣。

最近在开OSGI方面的知识，也许它可以解决这个问题。但是，我们的底层基本上都是c语言开发的，现在OSGI的主要是面向JAVA，对c的支持不多，无奈。不过他的思想倒是可以借鉴。盼望有一天OSGI能够支持C的系统。

这也是我最近产生要在操作系统内核的基础上构建类似于OSGI开发框架设想的原因。现在只是一个不成熟的想法，我觉得现在的框架离操作系统渐行渐远，所以，我想让开发框架直接基于操作系统内核来构建。前者拥有良好清晰的分层，以及成熟的应用。我的想法还是有点稚嫩的。哈哈，不过我会努力的，好好研究一下OSGI框架，以及linux操作系统。看看我的想法是否可以实现。也请各位小牛，大牛，牛魔王们对我这个晚辈的想法提些想法，谢谢啦。。。