我在一个聚合组织工作，我们用多种不同的语言和建筑风格进行编码。
我已经写了两年以上的面向服务应用程序了，并且对我的工作方式感到很自在，这就是问题所在。
在Big SOA级别，我们都同意如何使用SOA原则来连接解决方案/企业的不同部分。
在组件级别，我们都略有不同;
目前，我将每个高级组件作为SOA的服务方法，支持功能驱动的接口和软件堡垒。作为实现bean或wcf服务，模式保持不变。
我的组织中的其他人选择在立面下面的标准类的丰富域模型。 像SOAP，REST这样的架构风格都在这个层面上使用过。
我们在方法调用，命令样式消息与更多活动描述性消息的风格上也有所不同。
我已经使用了两者并且对其中任何一个感到满意，我的问题是其他工程师使用其他方法来构建他们的SOA。
我很喜欢新的想法，如何古怪，以激发围绕构建SOA主题的新思维方式。
答案 0 :(得分：0)
我花了一段时间构建一个基于组件的SOA方法，称为SoaKit可能会有所帮助。有关基本原理，请参阅http://bradjcox.blogspot.com。
基本思想是避免使用基于工具的方法（JAX-WS）来支持一组预构建的组件（由SoaKit提供），每个组件都执行常用功能，并且可以轻松地拼接在一起以完成整个工作工作。示例组件：添加SAML签名标头，解密/加密消息部分，XSLT / XQUERY转换等等，每个此类组件可独立配置。
如果一个企业是一个城市，那么一个服务就是那个城市的房子，而SoaKit组件则是建造房屋的砖块。该博客的文章与今天常用的泥砖方法形成鲜明对比。这个比喻是为了唤起罗马砖建筑给建筑施工带来的影响，寻求给软件带来同样的影响。
希望这个概念很有帮助。搁置这个想法是因为世界似乎倾向于单片魔术按钮式方法（JAX-WS）几乎无法控制或理解。这至少是我对JAX-WS / Metro和WSO2的体验。