传统的java类库要解决是的代码的复用
而SOA架构的目的是服务复用,因为java代码的复用是无状态,而服务的重用则是有状态的(此处的无状态或是说跟环境相关的,如中国移动提供一个短信发送网关,那么我们通过这个网关即可以发送短信,这就是服务),并且一般还有跨语言的重用要求(这样可以更加的保障投资价值,所以经常选择webserice soap作为传输协议).
为何说是一种风格呢?因为有很多人以为webservice就是SOA,如前所述,SOA需要解决是的服务的重用问题,所以为达这个目的,不管你使用何种传输协议.只要能够解决服务复用问题即可. 在这里要给EJB平反一下,EJB的无状态Session Bean应该是专属于JAVA的SOA服务架构(它解决了服务复用问题及服务集成问题,但没有解决跨语言复用,但如果是企业内部系统,跨语言也并不是EJB的致命缺点)
服务与服务之间可能存在依赖问题, EJB中使用jndi用于查找ejb对象,而SOA架构中也需要该项措施,采用集中式的服务查找服务.将交叉且复杂的依赖关系转变为易于理解的星型关系.
service使用者 ========> service服务注册中心 <======= service提供方
查找服务 注册服务
而在webservice协议中办演该角色是的UDDI, 并且通过service服务注册中心,我们可能还提供可以做到如服务的负载均衡,服务的故障自动检测等集中式管理功能.(自己扩展实现一个类似UDDI的功能也可)
现实存在的情况是很多程序员以为简单的webservice调用即是SOA,如果在服务过多的情况下,会导致服务依赖关系复杂