用于组成面向服务的应用程序的组件的选项
我在一家多元化组织工作，我们使用多种不同的语言和架构风格进行编码。
我编写面向服务的应用程序已经大约两年了，并且已经习惯了我做事的方式，这就是问题所在。
在大型 SOA 级别，我们都同意如何使用 SOA 原则来连接解决方案/企业的不同部分。
在组件级别，我们都略有不同；
目前，我将每个高级组件作为 SOA 的服务方法，支持功能驱动的接口和软件堡垒。无论是实现 bean 还是 wcf 服务，该模式都保持不变。
像这样，SOA 设计模式
我组织中的其他人选择丰富域立面下的标准类模型。 SOAP、REST 等架构风格都已在这一级别使用。
我们在方法调用的风格、命令风格消息与更多活动描述性消息方面也有所不同。
我已经使用过这两种方法并且对其中任何一种都感到满意，我的问题是其他工程师还使用其他方法来构建他们的 SOA。
我对新想法很感兴趣，无论多么古怪，都可以激发围绕构建 SOA 主题的新思维方式。
I work for a polygot organisation where we code in multiple different languages and architectural styles.
I have been writing Service Orientated Application's for around two years now, and have gotten comfortable with the way I do things, and that's the problem.
At the Big SOA level we all agree on how to use SOA principles to connect different pieces of the solution/enterprise.
At the component level we all differ slightly;
Currently I take the every high level component as a service approach to SOA, favouring capability driven interfaces and softeware fortresses. Be the implemenation beans or wcf services the pattern remains unchanged.
Like so, SOA Design Pattern
Others in my organisation opt for the rich domain model of standard classes underneath a facade.
Architectural styles like SOAP, REST have both been used at this level.
We also differ in the style of method call, command style messages vs more activity descriptive messages.
I have used both and am happy with either, my question are there other methods are other engineers using to compose their SOA.
I am interesed in new ideas, how ever wacky, to stimulate new ways of thinking around the topic of building a SOA.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我花了一段时间构建了一种基于组件的 SOA 方法（称为 SoaKit），它可能会有所帮助。请参阅 http://bradjcox.blogspot.com 了解基本原理。
基本思想是避免基于工具的方法 (JAX-WS)，而使用一套预构建的组件（由 SoaKit 提供），每个组件都执行常用的功能，并且可以轻松地组合在一起以完成整个工作。示例组件：添加 SAML 签名标头、解密/加密消息部分、XSLT/XQUERY 转换等等，每个此类组件均可独立配置。
如果说企业是一座城市，那么服务就是这座城市的一栋房子，SoaKit组件就是盖房子的砖头。该博客的文章将其与当今常用的泥砖方法进行了对比。这个类比是为了唤起罗马砖砌建筑给建筑施工带来的影响，并寻求给软件带来同样的影响。
希望这个概念有帮助。搁置了这个想法，因为世界似乎偏向于几乎不可能控制或理解的单一魔法按钮方法（JAX-WS）。至少这是我使用 JAX-WS/Metro 和 WSO2 的经验。
I spent awhile building up a components-based approach to SOA called SoaKit that might be helpful. See http://bradjcox.blogspot.com for rationale.
The basic idea is to avoid tools-based approaches (JAX-WS) in favor of a suite of pre-built components (provided by SoaKit) that each do commonly-needed functions and can be snapped together easily to do the whole job. Example components: add SAML signed header, decrypt/encrypt message parts, XSLT/XQUERY transforms, and so forth and so on, with each such component independently configurable.
If an enterprise is a city, a service is a house in that city, and SoaKit components are bricks for building houses. The blog has articles that contrast that with the mud-brick approach commonly used today. The analogy is to evoke the impact Roman brick architecture brought to building construction, seeking to bring the same impact to software.
Hope the notion is helpful. Shelved the idea because the world seemed bent on monolithic magic push-button approaches (JAX-WS) that are nearly impossible to control or understand. That's been my experience with JAX-WS/Metro and WSO2 at least.