构件化开发，SOA初涉

一直提倡的Java构件化开发，到今天偶总算渐渐想明白是怎么回事啦。

每一个业务模块都是构件，构件可以是独立部署的war应用程序或者jar包。

每一个构件都能够独立部署运行，又能在集成环境下运行，这时候怎么管理构件之间的依赖关系成为了一种关键。

偶像的是同一个App Server下部署的构件，可以通过App Server本身提供的功能进行服务的调用，例如发布成JMX服务之类。
也就是说，例如在同一个JBoss下发布了A构件和B构件，A构件想调用B构件里的b1接口，可以将b1的实现类发布成一个服务，然后把接口提供给A，就实现了A构件调用B构件的服务。

有人说，为什么不直接把b1打成jar包直接提供给A，让A本地化调用？

请注意，使用b1服务的不只是A,可能还有C,D,E，如果打jar包给A,C,D,E构件的话，那么意味着B一旦升级功能，需要重新编译打包，同时A,C,D,E的代码也有可能发生变化。所以必须通过服务的方式提供。

那么其他的问题又来了，如果A和B不在同一个server里呢？那又需要怎么做呢？

webservice的方式是一个好的解决方法。但是，在开发的时候，A根本不知道B最终会被部署到哪个App Server下，再者，B部署的App Server，也可能在各种环境下变化。

所以，需要一个服务的管理者出现，任何需要提供服务的构件，都必须在服务管理者里进行注册。而服务的调用者，同样是通过服务管理者进行服务的获取。这样即便B部署的环境发生了变化，只需要服务管理者变化即可，A,C,D,E这样的调用者是不需要知道任何实现细节的。

偶很艰难的悟清了上面这些道理，恍然一想，是否跟最近流行的SOA的架构极为相似涅？