如今,面向服务的架构似乎越来越热门,但在办公室里四处询问后,我发现我似乎得到了许多不同的定义。你们如何定义 SOA?你认为官方的定义是什么?
9 回答
正如 Martin Fowler 所说,它对不同的人意味着不同的事情。他关于该主题的文章非常好,尽管它不是一个完整的定义。
http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
它可以解释,很难提出一个具体的定义。
维基百科:“SOA 是一种软件架构,它使用松散耦合的软件服务来支持业务流程和软件用户的需求。SOA 环境中网络上的资源作为独立服务提供,无需了解其底层平台即可访问执行。”
SOA 并不是什么新鲜事物,但它有潜力实现一些令人惊奇的事情。但组织必须为此做好准备:企业必须在流程中思考,这是大问题
我会去:
定义一系列无状态、与客户端无关的业务操作,这些操作被创建用于在多个应用程序中使用。
SOA 设计包括代码可以使用的组件(即服务),而不管实现如何(即任何操作系统或语言)。一个服务的单个实例也可能被多个应用程序使用,然而,例如,一个 DLL 必须为每个应用程序复制,并且需要与链接应用程序相同的实现技术。
SOA 设计中的服务通常实现为可互操作的 Web 服务。
正如瑞安之前提到的,没有官方定义。然而,我发现 Thomas Erl 对整个面向服务的观点结构良好且相关。以下是他的SOA Glossary (更多) 中对 SOA 的定义:
面向服务的架构代表了一种架构模型,旨在提高企业的敏捷性和成本效益,同时减轻组织的 IT 总体负担。
Thomas Erl 是许多 SOA 书籍的作者,其中大部分都得到了 SOA 供应商的认可,包括 IBM、Oracle 和 Microsoft。他的书的好处是它们尽可能独立于 SOA 供应商。这意味着您更多地了解面向服务本身,而不是了解一些支持 SOA 的供应商的中间件。
我同意所有将你指向福勒的人的观点。基本上它是这样运行的:面向服务的架构以良好而著称,因此人们希望与良好相关的任何事物都称为 SOA。实际上,它有很多缺点,并且可以创建面向服务的僵局或面向依赖的架构。
这是我的定义:面向服务的架构是一种系统集成和代码重用方法,其中应用程序依赖于连接到网络上其他正在运行的应用程序提供的服务。这与组件架构不同,在组件架构中,软件组件以库或 SDK 的形式在应用程序之间静态共享。
这里有一个澄清 - “面向服务的架构是一种系统集成和代码重用方法,其中应用程序依赖于连接到网络上其他正在运行的应用程序提供的服务。”
我有一个场景,其中两个 j2ee 应用程序已使用事件驱动的消息传递进行集成。在这里,上述系统集成和连接到网络上其他正在运行的应用程序提供的服务的短语很好用。我可以称之为 SOA 吗?
以下原则在这里适用 1) 无状态 2) 面向消息 - 松散耦合事实上解耦 3) 可扩展。
但是,以下内容不适用 1) 平台独立性 - 所集成的应用程序均未设计为在不同平台上工作。2) 应用程序是普通的 j2ee 应用程序,没有使用所有 soa 概念设计。
我试图在我的一篇博客文章中定义 SOA 。这是摘录...
多年来,将功能分离为函数、类和模块一直是标准做法。一直以来的想法是,这些更小、高度专业化的组件比单片代码块更容易共享和维护。
在功能上,SOA 并没有太大的不同。目标是相同的 - 可重用性和易于维护。最大的区别——在 Web 服务 SOA 的情况下——是应用程序中包含的共享库被 HTTP 调用所取代。
这是给你的定义:
SOA - 软件过度架构。在一个漂亮的网站中包含无意义、过度膨胀的功能性界面框架,称为架构,其中 3d 图形文件夹从一侧飞到另一侧,其中“dir /s > a.txt | ftp -s:upload.ftp”做了这项工作。
软件组件不是砖块,不能通过通用的功能模式来概括,企业中出现的架构来自良好的实践,而不是良好的设计。软件不是架构的,它是设计的。
开始吧!