虽然我可以找到很多提倡 SOA 或 WCF 的文章,但我的问题是,什么不应该作为服务公开,我们从 SOA 失败中学到了什么。WCF 是实现 SOA 的一种方式,如果我们使用 WCF,是否意味着我们正在实现 SOA。肯定有很多人使用 C# 编写无法维护的代码。
5 回答
我觉得你是对的。在我当前的任务(Web 开发)中,对数据库的每一次访问都是作为服务实现的。正如首席架构师所说,我们是“纯 SOA”……哇!
事实上,这给一切增加了很多复杂性。当我想读取一个简单表格的内容时,我必须生成 8 个项目、42 个文件、8 个程序集,可能还有 9 个配置文件!
正如我所说,很多复杂性。有可能某个地方的某个人会忘记一个文件……将简单的流程公开为服务是愚蠢的。
在我的书中,您应该在以下情况下将流程公开为服务:
- 许多使用不同语言和框架的应用程序必须调用你的东西。
- 涉及的平台不止一个(Windows、Unix ...)。
- 正在处理的数据是企业的核心。
另外,请注意必须将服务设计为服务,并且设计服务至少与设计库一样复杂:必须精心设计错误捕获,日志必须足够灵活,文档必须完整等。
好吧,正如我所看到的,我每天使用的大部分服务都不会被其他人使用:没有文档、错误处理能力差、代码经常更改、第二区数据……
非常有趣的问题。1分:o)
SOA 作为一个概念是一个好主意。
使用 HTTP-WS/BPEL 等实现的 SOA 是一个笑话,在我不那么谦虚的观点中应该死掉。在得知分布式事务的唯一概念是补偿事务后不久,我就不再认真对待系统了... bzzt NEXT!
我知道有两种主要的反模式:
- 通过服务层直接从业务层公开对象
- 公开特定的细粒度方法,例如业务层中的方法
建议您的服务层包含粗粒度的通用方法,并让它们接受和返回较大的基于消息的请求和响应。目标是提供一个相当通用的接口,而不会对服务的使用方式做太多假设,也不需要大量调用来实现基本功能。尽量减少 Web 服务调用的次数。
以下是一些高水平的优秀建议:http ://apparchguide.codeplex.com/Wiki/View.aspx?title=Chapter%2013%20-%20Service%20Layer%20Guidelines
这是指南正在谈论的“消息”类类型的具体示例,以及如何在 WCF 中实现一个:http: //dotnet.org.za/hiltong/pages/windows-communication-foundation-tutorial-part -3-messaging-messagecontracts.aspx
SOA 是最糟糕的概念之一。SOA 是一种架构风格,与 Web 服务或任何技术无关。我同意通过 Web 服务和 BPEL 解释 SOA 显然是一种误导,BPEL 通常与 SOA 无关,而是一种实现 WS 编排的方式。供应商把它弄得一团糟。
我推荐一本非常不错的可下载书籍,它真正解释了 SOA 是什么:
http://www.infoq.com/minibooks/enterprise-soa
然后你可以阅读这个有趣的博客条目
问候