【IT168 SOA文档】
SOA不仅是技术架构 

    SOA在字面上的理解是面向服务架构，但是，在成功实施SOA后，你会清醒的认识到这不仅仅只是一种技术架构。而这一点非常重要的。事实上，SOA是关于业务流程建模的，它并不总是直接由技术组件支持。虽然服务可以由技术组件提供，但是业务流程本身比支持它的服务更为重要。SOA仅仅扮演推动者的角色，而技术并不会直接提供价值。服务不需要像EJBs或.NET组件那样从编写代码开始，SOA技术应当是其他收益的推动者，例如改进和扩大重复使用，对于业务流程变化的更好响应，以及和业务流程更好结合等等。

SOA不等于Web服务 

    当SOA伴随着Web服务一起走入我们的视线的时候，大部分的人将两者混为一谈。Web服务是SOA策略实施标准的一部分，但并不是必须的，而是可以基于HTTP之外其他的标准协议定义服务。通常情况下，服务的前后关系能够帮助你定义它。例如，对于那些与核心业务处理相关的服务来说，采用Web服务的方式可能是有害的，因为在SOAP/HTTP协议上确保业务处理安全非常困难，而且很多服务可能会需要异步运作。在这种情况下，基于队列和channels的消息系统可能更为合适。当然，有效载荷和界面仍然可以使用XML。

在现有的基础架构上实现SOA 

    SOA的关键就在于对遗留系统的重复利用。很多企业都发现可以利用现有基础架构实现SOA，例如，.NET和J2EE平台都支持Web服务开发、解析和生成XML和MSMQ或JMS之类的消息系统通信，而关于SOA经常出现的一些误解主要集中在流程管理和自动化层面。很多公司都已经在EAI(enterprise application integration)工具上投入了资金，EAI工具能够作为流程自动化和管理层，它们可以从现有的或者建立在.NET/ J2EE上的应用访问服务。

SOA是不断进化而来的方法理念 

    SOA不是一种刚刚出现的、全新的解决方案，实际上SOA是一种结构和技术上的自然进化过程。系统结构处于持续不断的调整发展之中，以便能够更好地和业务相适应。设计人员和企业很早就意识到将技术和业务流程相结合的价值，这样做能够更好地使用技术资源，更好地支持业务。 

    SOA技术的一部分是从企业结构理论发展而来的，更重要的是，它能够透视整个企业中的业务和流程并分析出其中的关系，为技术决策提供依据。SOA工具的进化来源多样，包括了互联网技术(如HTTP和XML)，集成技术(例如message busses、translation technologies和connectivity等)。

流程自动化是SOA的优势体现 

    很多企业和技术人员都错误地将注意力集中在服务和如何在服务结构中提供服务上。而SOA真正的价值是作为一种业务自动化工具，软件和系统是用于提高业务和企业效率的，因此可以根据企业的业务和活动来定义。对SOA来说，我们的注意力不应当集中在服务上，应该更关注流程，以及如何改进这些流程。

SOA架构可能会非常复杂

    从某种角度看，SOA架构可以非常简单。例如，开发一个业务流程或定义服务都是非常富有逻辑性的工作，而且比较简单。然而，如果想更好地利用数据和服务，情况则可能复杂得多。例如，让我们来设计一个订单服务，用户可以使用这个服务在系统里创建订单，这非常简单。但是如果你希望把订单数据和其他服务的数据关联起来，情况又会如何?如果所有的服务分享一个共同的数据源，也许你可以绕过服务层，并生成报告。但是，如果一些数据在自用的服务中，而另一些数据在以前遗留下来的主机系统中，其他一些数据在商业应用(例如SAP)中，把这些数据集中到一起就会变成一项非常复杂的工作。

深入理解业务流程和业务数据变化

    因为SOA专注于业务流程，所以理解和这些业务流程相关的数据就变得非常重要。要能够用一种标准的方法来描述这些信息，让每一个参与到这个流程里的人都能够理解这些数据所包含的信息内容。对于那些目前还没有信息结构或者只有非常有限的信息结构的大型企业来说，这个问题在实施过程中可能会带来很大的障碍。因为大型企业有很多数据，所以通常建议采用渐进式的方法来定义这些信息结构，而不是采用一步到位的方式。这就意味着你不需要花四年时间来定义完整的数据模型，只需要在服务开发过程中，花少量的时间来定义相关的数据就可以了。随着各项服务的实施，相关的信息结构就会被逐步完善起来。