该公司拥有一个企业服务总线,并且几乎所有开发的Web服务都是通过该总线公开的.我向周围的一些同事询问了何时通过ESB公开服务,我得到了这样的答案:
>如果有ESB,请通过它公开所有内容:有一些好处,如负载平衡和位置透明度
>如果ESB仅作为代理 – 即没有消息转换 – 只是不要使用它:您将使ESB过载并失去性能.你最好做一个点对点的连接.
>如果存在协议转换(如将存储过程公开为SOAP服务),则应通过ESB公开组件.如果没有这个,你最好去点对点.
所以我很好奇是否有通过或不公开Web服务的一般协议或最佳实践.任何阅读/参考都将是一个很大的帮助.
解决方法 从我的角度来看,经过4年的SOA技术经验,使用ESB总是会使系统超载,因为您要添加一个新层并使所有通信都通过它.如果没有ESB,转换(消息传递或协议)和路由并不难实现,点对点通信将具有更高的吞吐量.业务流程自动化也是如此,有一些方法可以在不需要ESB的情况下实现.另一方面,ESB的使用在公司范围内有几个好处,但它必须在愿景和战略范围内.最好的例子之一是一家公司长期以来一直使用各种工具,每种工具都用于特定目的,并使公司分布在孤岛工作的团队中,与其他人隔离.经过很长一段时间,团队之间的互动变得复杂而缓慢.精心策划的SOA策略将有助于集成所有这些工具并开始替换它们以获得更有意义的轻量级项目.
所以,恕我直言,在没有企业战略的情况下使用ESB来解决单个项目中的几个“问题”并不是一个好主意,最终,当问题不在时,你的公司会禁止使用SOA这个词. SOA本身就缺乏远见和企业战略.
我发现关于ESB使用的唯一经验法则是:在单个项目中转换,路由,业务流程自动化(有或没有人工交互)等的要求不是SOA的表现(几乎每个项目)必须执行转换,路由和业务流程自动化),但是当这些需求是整个公司的需求时,从业务角度考虑它是值得的,而不是技术性的.如果没有业务视角,那么SOA将失败.
这是一个非常广泛的主题,讨论可以持续很长时间,我会建议你进一步阅读的几个链接:
>大约SOA Case Studies
> Top 10 Reasons why SOA fails
以上是内存溢出为你收集整理的Web服务 – 何时通过ESB公开服务?全部内容,希望文章能够帮你解决Web服务 – 何时通过ESB公开服务?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)