关于soa：面向服务的体系结构：如何定义它

Service Oriented Architecture: How would you define it

如今，面向服务的体系结构似乎越来越成为热门报价，但是在办公室里问了一下之后，我发现我似乎对它有了很多不同的定义。你们将如何定义SOA？您如何看待正式定义？

正如马丁·福勒(Martin Fowler)所说，这对不同的人意味着不同的事情。他关于该主题的文章虽然还不是一个很好的定义，但却相当不错。

http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html

它可以解释，提出具体定义的困难。

维基百科：" SOA是一种软件体系结构，它使用松散耦合的软件服务来支持业务流程和软件用户的需求。SOA环境中网络上的资源作为独立服务提供，可以在不了解其底层平台的情况下对其进行访问。实施。"

SOA并不是那么新，但是它有潜力实现一些令人惊奇的事情。但是组织必须为此做好准备：企业必须在流程中进行思考，这是一个大问题

我会去：

Defining a series of stateless, client
agnostic business operations created
to be leveraged in multiple
applications.

SOA设计包括可以由代码使用的组件(即服务)，而与实现(即任何OS或语言)无关。服务的单个实例也可以由多个应用程序使用，而例如，DLL将必须为每个应用程序复制，并且需要与链接应用程序相同的实现技术。

SOA设计中的服务通常实现为可互操作的Web服务。

瑞安(Ryan)提到伯爵(eriler)并没有官方定义。但是，我发现Thomas Erl对整个服务导向的观点是结构合理且相关的。这是他的SOA词汇表中的SOA定义(更多)：

Service-oriented architecture represents an architectural model that aims to enhance the agility and cost-effectiveness of an enterprise while reducing the overall burden of IT on an organization.

托马斯·埃尔(Thomas Erl)是许多SOA标题的作者，其中大多数都得到了IBM，Oracle和Microsoft等SOA供应商的认可。关于他的书的好处是，它们尽可能独立于SOA供应商。这意味着您将了解有关面向服务本身的更多信息，而不必了解某些支持SOA的供应商中间件。

这里的澄清-"面向服务的体系结构是一种系统集成和代码重用方法，其中应用程序依赖于连接到网络上其他正在运行的应用程序提供的服务。"

我有一个场景，其中使用事件驱动的消息传递集成了两个j2ee应用程序。在这里，上面提到的系统集成和连接到网络上其他正在运行的应用程序提供的服务的短语非常有用。我可以称之为SOA吗？

以下原则在这里适用
1)无国籍
2)面向消息-松散耦合实际上已解耦
3)可扩展。

但是，以下内容不适用
1)平台独立性-所集成的应用程序均未设计为可在不同平台上工作。
2)这些应用程序是普通的j2ee应用程序，尚未针对所有soa概念进行设计。

我同意所有在这方面将您带到福勒的人。基本上它是这样运行的：面向服务的体系结构因其良好而享有盛誉，因此人们希望将与之相关的任何事物都称为SOA。实际上，它有很多缺点，并且可以创建面向服务的Gridlock或面向依赖的体系结构。

这是我的定义：
面向服务的体系结构是一种系统集成和代码重用方法，其中应用程序依赖于连接到网络上其他正在运行的应用程序提供的服务。这与组件体系结构不同，在组件体系结构中，软件组件在应用程序之间以库或SDK的形式静态共享。

这是您的定义：

SOA-架构之上的软件。在一个漂亮的网站中包含了无谓的，过度膨胀的功能接口框架，该框架称为体系结构，其中3d图形文件夹从一侧飞到另一侧，其中" dir / s> a.txt | ftp -s：upload.ftp" 做好了

软件组件不是砖头，不能通过通用的功能模式进行概括，并且架构是从良好实践而非良好设计中出现的。不是设计软件，而是设计软件。

擦一下！

我试图在我的一篇博客文章中定义SOA。这是节选...

For years it's been standard practice to separate functionality into functions, classes, and modules. The idea has always been that these smaller, highly specialized components are easier to share and maintain than monolithic blocks of code.

Functionally, SOA is not much different. The goals are the same - reusability and easy maintenance. The biggest difference - in the case of a web service SOA - is that the shared library included in your application is replaced with an HTTP call.