在SOA的实施过程中，理念上的指导，技术流程上的建议将会很好的帮助你更清楚的了解SOA，也能更明确的看到跟随而来的巨大收益……

　　在经过这几年的发展和演变，SOA已经是愈发的深入到了整个行业之中，但是即便如此，依然是存在着很多的误解。在SOA的实施过程中，一些理念上的指导，技术流程上的建议将会很好的帮助你更清楚的了解到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专注于业务流程，所以理解和这些业务流程相关的数据就变得非常重要。要能够用一种标准的方法来描述这些信息，让每一个参与到这个流程里的人都能够理解这些数据所包含的信息内容。对于那些目前还没有信息结构或者只有非常有限的信息结构的大型企业来说，这个问题在实施过程中可能会带来很大的障碍。因为大型企业有很多数据，所以通常建议采用渐进式的方法来定义这些信息结构，而不是采用一步到位的方式。这就意味着你不需要花四年时间来定义完整的数据模型，只需要在服务开发过程中，花少量的时间来定义相关的数据就可以了。随着各项服务的实施，相关的信息结构就会被逐步完善起来。

　　简单或复合式的服务

　　在一些情况下，所需要的服务非常显而易见，在这种情况下服务非常简单。然而，服务也可能非常复杂。这意味着“超级服务”可能提供一个标准界面，就如同我们的客户定位服务一样。如果所有的用户信息都存储在同一个库中，这就方便了服务的查找。但如果有些客户信息在某台主机中，另一些在SAP中，其他的一些则散布在其他的应用中，而还有一部分存储在Oracle数据库中，那么情况会怎样?假设我们已经从主机、SAP、其他应用或者Oracle数据库中定位了这名客户，我们的新定位客户服务就能够使用所有这些现有的服务来定位客户了。现在， 因为我们的服务需要调用其他服务，这就变成了一项复合式服务。当一个自动化流程模型扩展成一项服务的时候，也可能成为复合式服务。

　　SOA中的自动化包含了多个层次范围

　　自动化可以在几个层上发生，很多SOA架构仅将目光锁定在一个层上，而自动化通常至少应用于SOA解决方案中的两个方面。

　　首先，也是最明显的一个方面是业务流程层。流程设计好了以后，其中的步骤就被连接起来，实现了自动化。因为这些流程通常是基于日常业务的，它们常常会需要和人进行交互。而另一个方面是非人类交互，或者叫系统交互。在过去几年中，集成工具在这一领域内大显身手。但是系统间的自动化提高了流程的整体效率，与人交互之间的各种问题比系统或应用间的交互更为重要。

　　服务应当符合统一标准

　　对于服务来说，采用标准化的方式进行通信是非常重要的。在SOA世界里，通信是由两部分组成的：首先是网络协议，例如，如果你想和你的老板沟通，最好的办法是了解他更愿意通过电话还是电子邮件;第二个部分是数据或语言，如果你使用HTTP或JMS作为通信机制，那么你必须使用同样的语言。例如，如果你的老板说法语而你说英语的话，你们之间的沟通就很容易出问题。服务需要的数据应该被清晰地定义，这样服务提供者和使用者就能够有效地进行沟通。

　　可以将服务外包

　　服务不同于产品，它的优点在于你不需要自己管理，也不需要象采购产品那样全盘购买。而服务是可以外包的，这意味着当你需要向某个政府部门提交合法性文档的时候，你并不一定需要自己完成它，很多不同的公司都在为各行各业提供服务。通过使用外包服务，你可以将精力集中在SOA策略最重要的核心部分——流程。

　　外包的缺点在于如果你的竞争对手也采用了同样的服务，你的竞争优势就会被削弱。另一个问题是性能，外部网络提供的服务对于你的业务流程来说，性能上会比内部服务差一些。

　　可以使用现有的系统或应用来建设服务

　　很多企业在考虑SOA的时候忽略了现有的系统，诸如主机应用等等，这是错误的。事实上，SOA的一个主要优点在于它允许企业重复利用主机和以前遗留下来的系统资源，因为核心业务逻辑和数据通常是存在于以前遗留下来的专用系统中。当然，主机并不是惟一遗留下来的数据源，小型机系统，例如AS/400、VAX或HP3000都可以用某种方式被服务激活。有很多不同的工具可以与这些专用系统进行通信，并将它们作为标准服务。

　　性能是SOA系统首要问题

　　在典型的SOA环境中，应用是相互独立的，将不同应用中的数据关联起来非常困难。而这对决策支持和报告系统来说意义重大，最大限度地提高性能的关键在于理解哪些应用或系统性能对业务来说最重要，一旦确认了哪些流程是重要的，你可以集中精力，在必要的领域内提高和改善性能。

　　SOA实施由四个部分构成

　　成功的SOA实施计划应该包含四个主要的组成部分，第一部分定义业务流程，明确为了支持业务流程需要哪些服务，哪些数据与此相关;第二部分是SOA结构和模式，这一部分制定规则，描述服务如何定义及实施，说明通用实施和使用模式，制定开发服务过程中应该遵循的原则和标准;第三部分是SOA基础架构，这一部分包括支持开发和实施服务及业务流程所需要的网络、服务器、存储、信息工具、集成工具和流程自动化工具等等;第四部分是SOA开发程序，这个程序确定了服务开发和流程实施的优先顺序，指导整个项目，产生新的服务和流程。

　　SOA实施的艰难路程

　　尽管它是一种进化的技术，尽管目前已经可以找到很多关于SOA的知识，但是因为种种原因，建立服务架构仍然非常困难。其中最直接的原因在于SOA需要高度沟通，而且要求整个企业都为变革做好准备。变化带来的问题解决之后，可能又会出现技术问题，包括建立合适的服务和消费模式，在技术方面培训并发展团队，逐步调整企业结构以适应SOA发展模式。尽管SOA技术组件可以在独立的环境中进行测试，但SOA覆盖整个企业，因此需要在服务架构的管理和控制计划方面多下工夫。
　　
　　SOA的发展壮大已是一个不争的事实。通过这些基本的要点你应该能够对SOA的定义和实施有了较为清楚和正确的认识。