原文：
Among software people, the word “architecture” is commonly used in three distinct contexts: application architecture, infrastructure architecture, and enterprise architecture. The notion of service-oriented architecture spans all three of these areas. Yet whenever somebody talks about SOA, he or she is often implicitly thinking about only one of them. Developers are mostly interested in the challenges of building service-oriented applications, for instance, and so their focus tends to be on the application architecture aspects of SOA. A vendor of web services management tools commonly thinks of SOA primarily in the infrastructure sense, while an enterprise architect at a user organization is likely to be concerned mainly with SOA’s enterprise aspects.
All three perspectives have value. Here are simple descriptions of each one:
- Service-oriented application architecture: Guidelines, patterns, and practices for creating service-oriented applications. People who focus on platforms for service-oriented software and on the architecture of individual applications tend to emphasize this perspective. Technologies such as Microsoft’s Windows Communication Foundation (WCF) and the recently-announced Service Component Architecture (SCA) are directly relevant here.
- Service-oriented infrastructure architecture: Guidelines, patterns, and practices for managing and operating service-oriented applications. Big thinkers about SOA sometimes give this perspective short shrift, but anybody who’s actually trying to make it real knows how important these issues are. Vendors like AmberPoint and Actional are focused here.
- Service-oriented enterprise architecture: Guidelines, patterns, and practices for using and getting business value from service-oriented applications. Technical issues still appear here, but many of the biggest concerns revolve around people. (In fact, I’d argue that this view of SOA encompasses the most difficult challenges--people are usually more problematic than technology.) Advice on SOA from analyst firms such as ZapThink often emphasizes these aspects.
I’ve seen people argue about the meaning (and even the value) of SOA when their real difference was that one took an application-focused view while the other took an enterprise view. Words are only useful when we can agree on what they mean, and so having a clearer sense of what we’re talking about when we use this overloaded term would be a step in the right direction.
译文：
在开始的时候先介绍一下 SOA 的概念。
什么是 SOA ？
SOA 的全称是 Service Oriented Application ，面向服务的应用。
她是指为了解决在 Internet 环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。这句话的意思就是 SOA 不是一门语言或具体的技术，而是一种软件的系统架构，应该说更像一种模式，是一种为了解决复杂的 Internet 业务应用而提出的一种体系结构（在我感觉里，这种架构的提出更像 MVC 模式，不过我们总喜欢用模式啊，架构啊的话来体现自己是行业内的人，但其实无论说是模式还是架构，这都只是一些名词，如果组合现拥有的技术去实现自己的应用才是最有用的，就不用多谈所谓的架构还是模式了）。
我有几个 IBM 的咨询师在中远演示 SOA 留下的 PPT ，把 SOA 的概念解释得相当好，如果需要的话我可以发到邮箱（不能发上来，会挨人砍的）。
译文 ( 翻译：陈朋奕，如果有错误请来我的博客指出 ) ：
在做软件开发的人，架构这个词经常被用在三种不同的场合中：应用体系架构（ Application Architecture ），基础体系架构 (Infrastructure Architecture) 以及企业架构体系 (Enterprise Architecture) 。而 SOA 的概念横跨了这三种体系，然而很多人在谈到 SOA 的时候总喜欢不自觉的把 SOA 跟其中的一种混为一谈。
譬如开发者大多对如何建立 SOA 应用感兴趣，因此他们关注的趋向更多是 SOA 中的应用程序体系架构方面。而 Web Serivces 管理工具的卖主一般认为 SOA 主要是关于基础组件体系架构的，同样的用户团体会认为 SOA 是用于企业应用架构体系的。
这三种观点都是有意义的，因为这映射了 SOA 的三个应用层面。下面是关于这三个方面的一些简单的讲解：
―――― SOA 应用体系架构：是建立 SOA 服务的方向指导、模式以及实现方法。关注于面向服务软件的平台和个体应用结构的开发者会强调这个方面。类似 Microsoft’s Windows Communication Foundation （ WCF 微软视窗通讯基础组件）以及最近提出的 Service Component Architecture (SCA 服务构件体系 ) 就是跟 SOA 这个方面有关的。
―――― SOA 基础体系架构：是管理和操作 SOA 服务的指导、模式以及实现方法。 SOA 的大思想家们有时也会承认自己在这个方面的不足，但真正实现这些功能的人却知道这些的重要性。卖主会喜欢把关注和行动集中在这里。
―――― SOA 企业应用架构：利用 SOA 并从 SOA 中获得商业利益的指导、模式以及实现方法。技术上的讨论仍然会在这里出现，但更多的关注已经转到了人身上（以人为本？事实上，我对 SOA 面临的最大挑战是人的观点——人通常比技术更多问题——有一些自己的看法）。来自 ZapThink 的分析家通常对 SOA 提出的建议都强调这个方面。
我看到过很多人关于 SOA 的意义（甚至是价值）的争论，其实他们的争论只是关于应用体系架构主导还是企业体系架构主导而已。专业术语仅仅是在我们都认同的情况下才会体现其价值的，因此当别人在讨论这个被过度使用的术语的时候我们应该保持清晰的思路，清楚我们到底讲的是什么才是正确的方向。
