围绕着SOA（Service-Oriented Architecture，面向服务架构）有很多的误解。本文揭开了SOA的各种谜团，并介绍了执行这个服务架构会对你的工作有哪些帮助。
1：SOA不仅仅是一种技术方法
成功实施的SOA不仅仅是一种技术架构，理解这一点非常重要。事实上，SOA是关于业务流程建模的，而且并不总是由技术组件直接支持的。从根本上来说，服务可以由技术组件提供，但是业务流程本身比支持它的服务更为重要。
SOA作为一项技术仅仅扮演推动者的角色，然而技术并不能直接提供价值。服务并不需要象EJB或.NET组件那样从编写代码开始。SOA技术应当是其他效果的推动者，例如改进和扩大重复使用，对于业务流程变化的更好响应和业务流程的更好结合等等。
2：SOA并不意味着网络服务
很多技术人员都不理解为什么SOA并不一定意味着网络服务。网络服务可能是SOA策略中的一部分，但并不是必要条件。包含HTTP在内的其他标准协议都可以定义服务。更重要的是，应该把重点放在业务过程的需求及其服务上，而不是易于实施的技术上。通常情况下，服务的前后件关系能够决定其执行条件。
例如，对于那些与核心业务处理相关的服务来说，采用网络服务的方式可能是有害的，因为在SOAP/HTTP协议上确保业务处理安全非常困难。而且，很多服务可能会需要异步操作。在这种情况下，基于队列和频道的消息系统可能更适用于服务传送的实施。当然，有效载荷和界面仍然可以使用XML。
3：利用现有架构实现SOA
很多企业都发现他们可以利用现有基础架构实现SOA，这令他们非常吃惊。例如，.NET和J2EE平台都支持开发网络服务，支持解析和生成XML以及包括MSMQ或JMS在内的消息系统通信。
关于SOA经常出现的一些误解主要集中在流程管理和自动化层面。但是，很多公司都已经投资了企业应用集成（Enterprise Application Integration，EAI）技术。很多EAI工具都能够在流程自动化和管理层上运行，他们可以从现有的或者建立在.NET/J2EE平台上的应用软件访问服务。
4：SOA是一种进化方法
SOA不是一种刚刚出现的、全新的解决方案。实际上，SOA是一种结构和技术上的自然进化过程。系统结构处于持续不断的调整发展之中，以便能更好地和业务相适应。设计人员和企业很早就意识到将技术和业务流程相结合的价值，这样做能够充分利用技术资源，更好地支持业务。
SOA技术的一部分是由企业结构理论发展而来的，这个理论已经出现了很长时间了。企业结构可以衡量技术，而且更重要的是，它能够透视整个企业中的业务和流程，分析其中的关系，为技术决策提供依据。SOA工具的进化来源多种多样，包括互联网技术（如HTTP和XML），集成技术（如Mbus、Translation Technologies和Connectivity等）。
5：流程自动化是SOA的主要优势
许多企业和技术人员都错误地将注意力集中在服务授权和服务提供方面。不幸的是，这并不是问题的重点。SOA真正的价值是作为一种业务自动化工具。最终，软件和系统是用于提高业务和企业效率的，因此可以根据企业的业务和活动来定义。对SOA来说，我们的注意力不应当集中在服务上，而是应该更关注流程，以及如何改进流程。
当然，服务是支持流程所必须的。但是与提高工作效率、改进工作目标相比，服务是第二位的。为了服务而服务的想法是没有价值的。
6：SOA架构非常复杂
从某种角度看，SOA架构可以非常简单。例如，开发一个业务流程或者定义服务都是非常富有逻辑性的工作，而且比较简单。然而，如果想更好地利用数据和服务，SOA就可能复杂得多。
例如，一个订单服务，要求是用户可以通过它在系统里创建订单，这非常简单。但是如果你希望把订单数据和其他服务的数据关联起来，情况又会如何？如果所有的服务共享同一个数据源，也许你可以绕过服务层，生成报告。但是，如果一些数据在自用的服务中，另一些数据在以前遗留下来主机系统中，其他一些数据在商业应用（例如SAP）中，把这些数据关联起来就会变成一项非常复杂的工作。
7：SOA需要对业务数据的深入理解
因为SOA专注于业务流程，所以理解与业务流程相关的数据就变得非常重要。例如，订单流程就有一些关键性数据：订单、客户、运输、发票、付款和收据等信息。其关键环节是用一种标准的方法来描述这些信息，让每一个参与到这个流程里的人都能够理解数据所包含的信息内容。
对于已经有了信息结构的企业来说，这也许并不是大问题。但是对于目前还没有信息结构或者信息结构有限的大型企业来说，这个问题就可能会是实施SOA的障碍。因为大型企业有大量的数据，所以通常建议采用渐进式的方法来定义这些信息结构，而不提倡一步到位。这就意味着你不需要花四年的时间来定义完整的数据模型，你只需要在服务开发过程中，花少量的时间定义相关的数据就可以了。随着各项服务的实施，相关的信息结构就会被逐步完善起来。
8：服务既可以简单，也可以复杂
对服务的定义可能非常困难。在一些情况下，所需服务是显而易见的。在这种情况下，定义服务就非常简单。例如，一个定位客户的服务可能只要采用一些标准来发现客户，然后将标准客户记录反馈给服务的用户就可以了。
然而，服务也可能非常复杂。这意味着“超级服务”可能需要提供一个标准界面，如同客户定位服务一样。但在上一个例子中，假设所有用户信息都存储在同一个库中，这就方便了服务的查找。如果有些客户信息在某台主机中，另一些在SAP中，其他的一些则散布在其他的应用中，而还有一部分存储在Oracle数据库中，那么情况会怎样？假设我们已经建立了服务界面可以在每个系统中定位用户。换句话说，我们已经从主机、SAP、其他应用或者Oracle数据库中已经定义了用户服务。我们的新定位客户服务就能够使用所有这些现有的服务来定位客户了。现在，因为我们需要调用其他服务，这就变成了一项复合式服务。当一个自动化流程模型扩展成一项服务的时候，也可能成为复合式服务。
9：SOA中的自动化可用于多层
服务结构中经常被忽略的一点是自动化可以作用于不同层上。很多SOA架构仅仅将目光锁定在一个层上。自动化至少能在SOA两个主要层面得以应用。
首先，也是最明显的一个方面是业务流程层。当流程设计好了之后，实现自动化的各个步骤就关联起来。因为这些流程通常是基于日常业务的，它们通常需要与人之间的交互作用。在与人交互流程上实现自动化是自动化的主要方面。
另一个最重要的自动化层是非人类交互，或者叫系统交互。在过去几年中，集成工具在这一领域内大显身手。但是系统间的自动化提高了流程的整体效率。
在这些层上使用不同的工具也非常重要。必须考虑到与人交互之间的各种问题，这比系统或应用间的交互更为重要。
10：服务应当符合界面标准
对于服务来说，采用标准化的方式进行通信是非常重要的。在SOA世界里，通信是由两部分组成。首先是用于通信服务的网络协议。这就好比人们日常使用的通信媒介。例如，如果你想和你的老板沟通，最好的办法是了解他是喜欢接到你的电话还是电子邮件。
第二个部分是通信的数据或语言。如果你使用HTTP或JMS作为通信机制，你必须使用同样的语言。例如，如果你的老板说法语而你说英语的话，你们之间的沟通就很容易出问题。服务通常使用的语言是XML，但不全是。服务需要的数据应该被清晰地定义，这样服务提供者和使用者就能够有效地进行沟通。
网友评论