package com.mybank.xfire.example;

import java.text.NumberFormat;
import java.text.DecimalFormat;

/** *//** XFire WebServices sample implementation class. 
*/
public class BankingService implements IBankingService {
    
    //Default constructor.
    public BankingService(){    
    }
    
    /** *//** Transfers fund from one account to another.
    */
    public String transferFunds(
        String fromAccount, String toAccount, double amount, String currency){
        
        String statusMessage = "";
                      
        //Call business objects and other components to get the job done.
        //Then create a status message and return.
        try {
            NumberFormat formatter = new DecimalFormat("###,###,###,###.00");       
            statusMessage = "COMPLETED: " + currency + " " + formatter.format(amount)+ 
            " was successfully transferred from A/C# " + fromAccount + " to A/C# " + toAccount;
        } catch (Exception e){
            statusMessage = "BankingService.transferFunds(): EXCEPTION: " + e.toString();
        }
        return statusMessage;
    }
    
}

package com.mybank.xfire.example;

public interface IBankingService {  

    public String transferFunds(
        String fromAccount, String toAccount, double amount, String currency);
        
}

在实际实现中，这样一个方法可能包括各种类型的复杂调用、查询和处理操作。但是我们的示例代码已经最小化了，以至于我们可以集中精力在主要目标上：把这个方法发布为Web Services。

你可以看到BankingService是一个普通的Java类，没有任何代码告诉我们它将会在Web Services中使用。好的，这里我们不需要增加任何东西。我们所有的工作都在部署描述符里完成。

Web应用的部署描述符

在Java 中，Web应用程序通常需要至少一个部署描述符（叫做web.xml）对其进行配置。XFire本身是一个基于servlet的应用程序。因此，我们需要增加必要的引用到描述符文件中。然后我们还必须配置将要创建的Web Services。我们使用一个称为services.xml的新文件来完成这件事。

web.xml
首先，修改web.xml。我们需要增加下面的XFire servlet相关的条目：

   <servlet>
        <servlet-name>XFireServlet</servlet-name>
        <display-name>XFire Servlet</display-name>
        <servlet-class>org.codehaus.xfire.transport.http.XfireConfigurableServlet
         </servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>XFireServlet</servlet-name>
        <url-pattern>/servlet/XFireServlet/*</url-pattern>
    </servlet-mapping>
    
    <servlet-mapping>
        <servlet-name>XFireServlet</servlet-name>
        <url-pattern>/services/*</url-pattern>
    </servlet-mapping>

services.xml
现在我们不得不说一下我们的Web Services的由什么组成的了。这由一个叫做services.xml的文件完成，它存放在META-INF/xfire目录下，而这整个目录放在 WEB-INF/classes文件夹中，它在Web应用程序的标准类路径中。这里是services.xml中的基本配置条目：

<beans xmlns="http://xfire.codehaus.org/config/1.0">
  
  <service>
    <name>Banking</name>
    <namespace>mybank</namespace>
    <serviceClass>com.mybank.xfire.example.IBankingService</serviceClass>
    <implementationClass>com.mybank.xfire.example.BankingService</implementationClass>
  </service>  
  
</beans>

   /**//* Call the Web service
    *
    */
    public String callWebService(
        String fromAccount, String toAccount, double amount, String currency) 
        throws MalformedURLException, Exception {
        
        //Create a metadata of the service      
        Service serviceModel = new ObjectServiceFactory().create(IBankingService.class);        
        log.debug("callSoapServiceLocal(): got service model." );
   
        //Create a proxy for the deployed service
        XFire xfire = XFireFactory.newInstance().getXFire();
        XFireProxyFactory factory = new XFireProxyFactory(xfire);      
    
        String serviceUrl = "http://localhost:8080/websvc/services/Banking";
        
        IBankingService client = null;
        try {
            client = (IBankingService) factory.create(serviceModel, serviceUrl);
        } catch (MalformedURLException e) {
            log.error("WsClient.callWebService(): EXCEPTION: " + e.toString());
        }    
               
        //Invoke the service
        String serviceResponse = "";
        try { 
            serviceResponse = client.transferFunds(fromAccount, toAccount, amount, currency);
       } catch (Exception e){
            log.error("WsClient.callWebService(): EXCEPTION: " + e.toString());                 
            serviceResponse = e.toString();
        }        
        log.debug("WsClient.callWebService(): status=" + serviceResponse);              

        //Return the response
        return serviceResponse;
    }  

这个代码是如何工作的呢？我来解释一下：首先，我们创建一个服务模型，它包含服务的说明——换句话说，就是服务的元数据。我们使用XFire的ObjectServiceFactory从IBankingService.class接口创建这个模型。

接着，为XFire获得一个代理工厂对象，它包含了常规的代码，也相当地简单和易懂。这一步中没有任何特定应用的东西。从这个proxyFactory，使用服务模型和服务端点URL（用来获得WSDL），我们可以得到一个服务的本地代理。

就是它了。这个代理就是实际的客户端。现在，我们可以调用它的transferFunds()方法来得到我们需要的Web Service。
一旦示例应用发布并启动，就可以尝试servlet URL：
http://localhost:8080/websvc/ws。

这个Servlet使用默认参数来调用Web Service和显示接收到的响应。页面的最后两行应该读取：
Response Received
COMPLETED: CDN$ 500.00 was successfully transferred from A/C# 11111-01234 to A/C# 99999-05678

现在你可以确定Web Service已经发布并且在运行中了。

为了尝试不同的输入值，你可以使用完整的URL，例如：
http://localhost:8080/websvc/ws?from=11-2345&to=77-9876&amt=250.00&cur=EUR。

基本的Web Services开发步骤清单

这个清单总结了将一个Java方法发布为Web Service所必须的步骤：
1、        检查Java类的方法和默认构造函数确保为public
2、        增加XFire servlet相关条目到web.xml中
3、        创建services.xml，把它放到WEB-INF/classes/META-INF/xfire目录下
4、        增加XFire和第三方包到你的Web应用的WEB-INF/lib文件夹中

这就是所有需要的步骤，是的，相当简单。

XFire的其他高级特性

XFire的使用可能比较简单，但是在特性和功能性上，它却占据着领导者的位置。下面是它的高级特性：
-- -本地数据绑定支持POJOs（plain-old Java objects）、XMLBeans、JAXB（Java Architecture for XML Binding）、Castor等等。数据绑定说明了Web Services的XML请求和映射到Java对象的XML响应。
---使用StAX（Streaming API for XML）处理XML文档。同DOM的基于树和SAX的事件驱动的处理方式相比，StAX使用了拉（pull）机制，它使处理更快速，内存效率更高。
---支持多种传输协议，如HTTP、JMS（Java Message Service）和JVM内部传输。
---嵌入式，这是XFire的核心功能之一。你可以把这个SOAP引擎嵌入到你的应用中，完全隐藏所有XFire特定引用，同样所有配置都是程序驱动。
---丰富的API，它使XFire可高度自定义，允许开发者在不同的阶段截获请求，并且对他们进行处理。
-- -兼容最新的标准例如SOAP1.1（没有加密远程工程调用，或者RPC）和1.2、WSDL1.1、the Web Services Interoperability Organization’s Basic Profile 1.0、Web Services Addressing和WS-Security。

最重要的是，XFire属于新一代Web Services引擎。不仅仅是营销用语，“新一代”有一些重要的意义。Apache Axis是第一代Java语言的Web Services引擎，已经成为了所有后来工具的参考标准。在过去的几年里，Axis以及这些其它的工具已经在很多生产环境中进行了实地测试。从中得出的一个关键的问题就是Web Services并不最适合RPC类型的通信。对于性能和效率，面向文档的消息形式是最好的方式。但是Apache Axis和很多其他的Web Services引擎都被设计成了面向RPC的（尽管它们支持文档形式）。现在，整个行业正在开发新一代的SOAP引擎，设计为面向文档的。Apache 已经宣布结束旧版本的Axis引擎开发，现在专注于Axis2，现在它的预发布版本是0.95。XFire在今年的2月份发布了它的第一个产品版本（1.0）。它的下一个版本（1.1）仅仅在几个星期之后就进行了发布。

性能

Web Services需要消耗很多资源，但是性能方面它们不是那么引人注目。XFire打破了这种趋势。它消耗更少的内存（部分因为 StAX的使用），但是表现却比多数可比较的SOAP引擎出色。你可以在资源中提供的链接中看到比较的结果。
此外，XFire还提供了各种方法来进一步优化性能。一个方法是使用JVM内置传输（in-JVM transport）。如果你知道Web Services和客户端运行在同一个JVM上，你可以选择使用本地传输，它可以大幅提升性能。在示例中的客户端代码，看以下指定服务端点URL的这行：
String serviceUrl = "http://localhost:8080/websvc/services/Banking";
替换为
String serviceUrl = "xfire.local://Banking";

你会看到性能上的明显提高，因为它绕过了整个网络层。

局限性

XFire有些重要的局限性你应该清楚：
-- -开发Web Services的好的实践是从WSDL开始。大部分的SOAP引擎提供了从WSDL生成服务stub的工具。XFire也提供了这样一个工具。但是它是基于注释（annotations-based）的，因此需要J2SE5.0。对于仍坚持使用J2SE1.4.x的人来说，它不是一个令人拍手叫好的工具，因为我们有很多其他方式来编写客户端，一个就是文章中演示的方式。
---附件支持，它将会包含在未来发行的版本中。
---易于学习的用户向导。XFire团队在这个方面还有很多工作需要做。

结论

Java 当前的趋势是简化技术的使用。因此，我们正看到一波基于POJO的开发成就。同时，面向服务架构（SOA，Services-oriented architecture）和Web Services已经变成了当前行业的热点话题。XFire正是在这种情况下产生的。它能够使POJO发布为最少的Web Services，而只需要付出最小化的努力。从而，它使希望使用这项技术的初级开发者的学习曲线变得平缓。同时，由于它兼容最新标准和提供了丰富的 API，XFire为高级用户提供了更多的大好机会。

关于作者
Shahid Ahmed是一个软件架构师，如今在美国一家主要的无线运行商作咨询工作。他在22年前开始开发软件，当时Kaypro、Osborne、Apple II和TRS-80s统治着整个地球。在过去的7年里，他更多的精力集中于Java。他现在的工作包括SOA、Web Services、消息、POJO、Spring、Ajax等等。Shahid是一个软件热衷者，每天都在奋斗以求在技术的迷恋和社会生活的热爱之间寻找平衡点。

资源：
Matrix Java社区:http://www.matrix.org.cn
下载本文中的示例应用：http://www.javaworld.com/javaworld/jw-05-2006/xfire/jw-0501-xfire.zip
Web Services架构:http://www.w3.org/TR/ws-arch/
WSDL2.0（原来提议为WSDL1.2，现在重新命名了）：第一部分：核心语言（W3C Candidate Recommendation 27 March 2006）

引自:http://www.matrix.org.cn/resource/article/2006-09-24/XFire_6bd1061c-4bc6-11db-978f-43b3336b7e51.html

什么是面向服务的体系结构（SOA）？

面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。 松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧 耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

虽 然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。

然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。

Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操 作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新 供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。

此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。

最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。

我可以用面向服务的体系结构做什么？

对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。

下 面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商 和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。

另一种形式是内部改变， 在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store） 的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但 是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。

为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。

垂 直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或 删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。

正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变 需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经 有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。

构成 SOA 的技术是什么？

SOA 本身是应该如何将软件组织在一起的抽象概念。它依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安全性、策略管理、可靠消息传递以及会计系统的支持，从而有效地工作。您还可以通过分 布式事务处理和分布式软件状态管理来进一步地改善它。

SOA 服务和 Web 服务之间的区别在于设计。SOA 概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的 区别。而另一方面，Web 服务在需要交互的服务之间如何传递消息有具体的指导原则；从战术上实现 SOA 模型是通过 HTTP 传递的 SOAP 消息中最常见的 SOA 模型。因而，从本质上讲，Web 是实现 SOA 的具体方式之一。

尽 管我们觉得 Web 服务是实现 SOA 的最好方式，但是 SOA 并不局限于 Web 服务。其他使用 WSDL 直接实现服务接口并且通过 XML 消息进行通信的协议也可以包括在 SOA 之中。正如在别处指出的，CORBA 和 IBM 的 MQ 系统通过使用能够处理 WSDL 的新特征也可以参与到 SOA 中来。如果两个服务需要交换数据，那么它们还会需要使用相同的消息传递协议，但是数据接口允许相同的信息交换。

既为了建立所有这些信息的适当控制，又为了应用安全性、策略、可靠性以及会计方面的要求，在 SOA 体系结构的框架中加入了一个新的软件对象。这个对象就是企业服务总线（Enterprise Service Bus，ESB）， 它使用许多可能的消息传递协议来负责适当的控制、流甚至还可能是服务之间所有消息的传输。虽然 ESB 并不是绝对必需的，但它却是在 SOA 中正确管理您的业务流程至关重要的组件。ESB 本身可以是单个引擎，甚至还可以是由许多同级和下级 ESB 组成的分布式系统，这些 ESB 一起工作，以保持 SOA 系统的运行。在概念上，它是从早期比如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发机制发展而来的。

从 开发人员的角度来说，他们使用的工具必须知道 SOA 的能力，并允许开发人员有效地使用 SOA 对象。这将设计 SOA 模型、开发服务和服务对象以及测试 SOA 应用程序这些过程包括进来并组成一个整体。因而，开发人员的工作必须为面向服务的应用程序设计/开发（Service-Oriented Application Design/Development，SOAD）做好准备。

SOA 与其他技术的关系如何？

SOA 可以与许多其他技术结合在一起使用，然而，组件的封装和聚合在其中扮演着重要的角色。如前所述，SOA 可以是一个简单对象、复杂对象、对象的集合、包含许多对象的流程、包含其他流程的流程，甚至还可以是输出单一结果的应用程序的整体集合。在服务之外，它可 以看作是单个实体，但是在其自身中，它可以具有任何级别的复杂性（如果必要的话）。出于性能方面的考虑，大多数 SOA 服务并没有下降到单一对象的粒度，并且更适合于大中型组件。

除了可能离不开 XML 和 WSDL 之外，SOA 并不是特定于语言的。可以用任何编程语言来实现服务，只要这种编程语言可以生成服务并且可以与 WSDL 结合在一起使用就可以了。SOAP 本身并不是绝对需要的，但它是通用的消息传递系统。因此，可以使用几乎任何一种编程语言和支持 WSDL 的平台来实现 SOA 中的成员服务。

基 于通用对象请求代理体系结构（Common Object Broker Request Architecture，CORBA）的应用程序有许多组件必须连接到 SOA 中。虽然 CORBA 中的接口描述语言（Interface Description Language，IDL）在概念上类似于 WSDL，但它不是严格的，因而首先需要将其映射到 WSDL。另外，需要使用更高级的 SOA 协议（比如用于流程和策略管理的协议），而不是 CORBA 中的类似的概念。请记住，这是 CORBA 组件（表示为服务）需要与 SOA 服务交互的情况；在 CORBA 模型中，所有的独立子集仍然可以像以前一样工作。

由对象管理组 （Object Management Group）提出并在许多 IBM Rational 产品中得以实现的模型驱动体系结构在一个更抽象的层次上与 SOA 的概念具有很强的相关性。MDA 基于这样的概念，任何软件流程都可以定义为模型甚至是元模型（即模型的模型），然后可以将这些模型和元模型转换成应用程序的实际组件。因此，MDA 创建了一个模型，这个模型先编译成软件应用程序，而软件应用程序接着又编译成可执行程序，这样就可以在平台上运行了。MDA 并不区分服务和对象这两个概念，但是它确实允许模型由其他子集模型本身组成，这类似于 BPEL（SOA 的一个核心组件）中的流程聚合的概念。

SOA 和 Web 服务是独立于编程语言的，但 Java 是主要的开发语言之一。可以使用定义良好的 Java 接口以及各种协议丰富的 Java 实现为正在构建这个模型的开发人员提供了优势。Java 在此担当了开发每个服务的功能、管理数据对象和与其他在逻辑上封装在服务内的对象进行交互的角色。

SOA 与 Web 的另一个重要的关系是自主计算和网格计算的概念。自主计算的概念应用于管理分布式服务体系结构的范围，具体来说，就是帮助维护策略和服务级协议以及 SOA 系统的总稳定性。

另 外，网格计算可以以两个级别与 SOA 系统一起使用。网格是分布式计算的一种形式，它利用分布式特性和服务之间的交互来为 SOA 应用程序提供计算支持。在这种情况下，网格起到了框架的作用，其中实现了一些或所有单独的服务。因此，SOA 应用程序可以是网格服务的消费者。

在 另一方面，网格本身也可以构建在 SOA 之上。在这种情况下，每个操作系统服务都是构成整个 SOA 应用程序的成员，而 SOA 应用程序就是网格本身。因此，单独的网格组件既可以使用 Web 服务进行通信，又可以以 SOA 的方式进行交互。总而言之，网格系统可以是 SOA 本身，也可以提供服务来在其上构建应用程序级 SOA 模型。

我可以如何构建SOA系统？

利用 SOA 的好处不仅是一个软件开发流程，而且还是一个业务开发流程。采用 SOA 有四个层次，您的实现可以跨越从创建特定的软件服务到将您的业务模型全面转换到按需系统的过程。要获得进一步的信息，您应该阅读这一部分的末尾列出的文章 “The Four levels of SOA Adoption” 。

第一个层次是最简单的，因为它只需创建单独的服务。在这一部分列出的 “SOA 新手入门 ” 中对此进行了详细解释，并且提供了更多的资源。

在第二个层次中，您不仅可以创建服务，而且可以开始将业务功能集成到 SOA 中。这涉及多个层次的集成，其中包括应用程序集成、信息集成、流程集成和整个系统集成。 Migrating to a Service-Oriented Architecture 是一篇重要的文章，介绍了这个层次中的问题。

第三个层次涉及将您的企业 IT 基础设施转换到 SOA 模型，而采用 SOA 的第四个层次集中于转换您的业务模型，以使之成为按需就绪的模型。

从 IT 专业人员的角度来看（与业务层相比），要创建 SOA 应用程序，您通常将经历四个阶段：构建、部署、使用和管理。在构建阶段中，您可以定义业务模型或流程、软件模型和 SOA 模型。之后，您就可以创建一组服务，这组服务可以与已发布的通用接口一起重用。

在部署阶段，您提取创建的服务，并把它们放在一个可执行、可管理的环境之中。在使用阶段，您根据前面所讲的 SOA 和软件模型来装配应用程序，并且测试其软件质量以及非功能性需求，比如性能、可伸缩性等等。应用程序现在已经准备完毕并且可用于用户。最后的管理阶段是一个长期的过程，在这个阶段中，您可以监控并管理安全性和使用，以及在许多与您可能已经为 SOA 制订好的服务级协定或策略相对应的方面比较其性能。

这些是 SOA 的生命周期的概念阶段。为了使对应于这些阶段的实际工作角色具体化，有许多角色需要加入到 SOA 应用程序的创建之中。这些角色可能从事相同的工作，也可能跨多个团队成员甚至多个团队。在 Rational Unified Process （ RUP ）中所划分的角色非常好地表达了角色概念。

RUP 角色包括项目经理、分析员、架构师、建模人员、开发人员、测试人员以及部署和操作人员。 SOA 几乎完全照搬了这种角色划分方法，惟一不同之处在于， SOA 建模人员角色的工作是提取概念性软件模型，并且根据 IT 基础设施的 SOA 模型和资源来对其进行测试。开发人员角色还可以包括二级角色像装配人员（在使用阶段），装配人员的角色是提取单独的服务，并且根据定义好的模型构建实际的 SOA 应用程序。不管是显式的还是隐式的，这些角色都存在于支持 SOA 的企业之中。


个人体会：

    SOA 的松耦合特性能够适应业务需求的灵活性，当服务内部结构及实现发生改变时它能够继续存在从而降低了软件二次开发的成本。 SOA 就好比是一个服务中介将不同系统、不同平台上的操作通过它联系起来，而实现各种服务和数据的交互，满足市场快速变化的需求.

定义SOA
如 果您想实施SOA，首先要牢记的一点就是IT部门必须对SOA有明确的理解和定义。您可以试着询问5位IT专家，看看他们心目中的SOA到底是什么。您很 有可能会听到五种完全不同的答案。这主要是因为架构技术的发展速度太快，没有人能精确地说明最新的SOA定义究竟是什么。
但这并不是什么问题。即使IT行业无法在定义方面达成共识，也并不影响SOA的整体发展。但是，您的IT部门内部必须要达成共识，确定SOA对您所在企业的确切意义。
建议您对有关SOA的一些权威文献进行研究，并且总结出一套适合自身需求的SOA理论。您也可以咨询一些该领域的专家，让他们根据您公司的特殊需求来定义一套专有的架构。
最为关键的一点是，您的公司必须拥有一套能够自我发展的SOA定义。IT部门中的每一个人都必须充分理解这套定义，并尽全力支持这种新的架构形式。

员工培训
对许多企业而言，SOA与传统架构有着天壤之别。传统架构侧重的是各种应用间紧密连接的接口，因此员工要想理解SOA就必须经历一段艰苦的学习过程。而通过合理的培训和教育，您可以减轻员工的这种学习压力，更加自信地为SOA的实施做好准备。
建议您采用自上至下的培训顺序。首先，对高级管理人员进行培训，让他们了解SOA的基本要点，以及部署SOA后企业可能获得的利益与优势。
在完成高级管理层的培训后，接下来可以对下一级业务主管开展SOA方面的教育工作。他们不仅需要理解SOA的总体目标，还要深入理解具体实践中遇到的细节，并且需要明确知道SOA是怎样实施的。
最后，您还需要对构建和部署SOA的人员进行具体培训。这种渐进式的培训应该解决一些特定的技术问题，为企业平稳过渡到SOA架构提供有效保障。当然，这一阶段培训的工作量和精力投入都是最大的。
需要提醒您的是，早期培训并不一定会带来彻底的成功。SOA的概念对于许多IT专家来说仍然非常陌生，即便他们对其他架构研究得相当透彻，面对SOA也会显得有些不知所措。
想要理解新的规范总是很困难的。未来主义学者Joel Barker将这种症状称作“规范效应”。他解释说，多数人所感知的世界都有一定的边界。当新的理论试图对这种边界发起挑战时，人们很可能会表现出抗拒的态度，因为这些新的理论与他们原有的信仰显得格格不入。
想征服规范效应，管理层的支持和全面深入的培训必不可少。但是，千万不能灰心。员工完全可以通过再培训来接受这些新概念，在这方面已经有很多成功的先例。

建立SOA管委会
SOA的最终目标是开发出一套灵活的架构，并能够通过一个通用接口将各种离散的异型应用集成在一起。要实现这一目标，就必须设计和开发一些独立于应用的服务，并且使整个企业都能访问和共享这些服务。

为了保证独立应用和服务复用过程中企业的应用重点不发生偏移，企业有必要建立一个SOA的管制委员会。许多SOA文献和实践者将这种组织称为集成能力中心（Integration Competency Center，ICC）
在建立ICC时，有一些关键组件是必须预先考虑到的。当您在确定该中心的参与者时，应确保企业中的每个相关部门（包括IT和业务部门），都派出了掌握实权的人员参加进来。
要记住，此举的目的是减少可能出现的应用孤岛，并且提供充分的资产复用能力。因此，只有企业中所有部门都参与进来后，也就是建立一个“检查与平衡”的体系之后，这些目标才拥有实现的可能。
管理者可以委派最优秀、最机智的助理参加这个管委会，确保他们经过良好的培训，成为精通SOA的专家级人物。请注意，高级管理人员必须理解小组成员参与SOA管委会的重要性，并且愿意重新分配工作任务，使管委会的工作能够被优先处理。

学着“眼高手低”
最 后一点，也是重要的，即在实施SOA的初期不要过于热情了。因为这是一项长期工作。历史证明，在IT行业中使用轰炸式的工作方法很难奏效。小规模的渐进式 发展成功的几率却高许多，因为这种变化更易于管理。幸运的是，事实证明，渐进式的方法在实施SOA的过程中非常有效，因为这种架构允许企业一次实施一项服 务。
在开始时，可以选择一些相对比较简单的功能，也就是说风险较低、但仍然比较重要的功能。例如，从多个系统中提取和合并客户信息的功能就可以当作早期尝试的不错范例。您可以围绕该功能开发一套服务，并为整个企业提供支持。
然后，您可以开始“脱钩”不同系统中的功能，使之不再依赖点到点的接口，而是将其重新定向至全新的共享式服务。
从小处着手可以帮助您的企业在部署重大服务前进行一些初步的测试，并且对流程加以细化。例如，您可以将财务应用重新定向，让它们使用一个通用的接口。另外，这种初步的测试还能监测出企业对SOA的准备情况，以及在新架构下的应变能力

引言

目前，关于由 Service-oriented Architectures（SOA）和它的 Web 服务实现所表现的时机有许多传言 -- 有一些是有事实根据的，但是一些却没有什么事实依据。分析家已经预言，博学者已经声称，教授已经讲演，公司已经匆忙的卖他们的产品，作为 SOA 产品 -- 经常失去 SOA 不是一个产品的要点。它是业务和 IT 之间的桥梁，通过一系列使用一些设计原则、模式和技术的依赖于业务的 IT 服务来实现。

ZDNet 最近报道说，“Gartner 预言到了 2008 年，至少 60% 的企业将使用 SOA 作为创建任务苛刻的应用程序和过程的“指导原则”。

开发和实现 SOA 有很大的需求。因此如果 SOA 不仅仅和产品和帮助实现它的标准相关（比如通过 Web 服务），那么为了实现 SOA 你还需要什么附加的元素吗？ 基于服务的建模需要其他的行为和构件，这些在传统的基于对象的分析和设计（OOAD）中是不存在的。“ 基于服务的分析和设计的元素”这篇文章描述了一些最初的原因，解释了为什么你需要 OOAD 之外更多的内容。它同样描述了业务流程管理或企业架构（EA）和 OOAD 为什么不是管理分析和设计的适当手段。同样，在 IBM Redbook 中名为 “ 模式：Service-Oriented Architecture 和 Web Services”的文章中，我举例说明了基于服务的建模方法的主要活动。

然而，你还需要重视一些额外的重要的需要考虑的事项。首先，目前的 OOAD 方法没有定位 SOA 三个重要的元素： 服务， 流，和实现服务的 组件。你同样需要可以明确定位鉴别、制定和实现服务所需的技术和过程，它们的流程和组合，以及实现和确保所需服务质量的企业级组件。

第 二，需要进行范例的替换，以便更好的区分 SOA 的两个关键角色之间的截然不同的需求：服务提供者和服务消费者。第三，假设为一个企业或者业务线构建的应用程序，现在必须被提升到一个供应链中使用，并且 公开给合作伙伴，这些合作伙伴可能组合、联合和封装应用程序到一个新的应用程序中。这是服务生态系统或者服务价值网的概念。

这 是仅从“分布式对象”的一个微小的进步。它是关于通过网络作用创造的价值：例如，当合作伙伴利用了 Amazon.com 与 Google 搜索的联合，并且与 eBay 服务结合在一起，来构建他们自己的混合解决方案。或者当旅行社深入到机票预订系统，并且与汽车租赁公司以及宾馆相互协调，更新他们的记录并且将旅行计划发 送到你的电子档案中。无论什么样的应用程序，你如果想成功地创建 SOA，需要的都不仅仅是好的工具和标准。你需要一些规范的步骤来支持你的 SOA 生命周期；用来分析、设计、实现服务、流程和组件的技术。因此，对于任何对企业应用程序开发感兴趣的人来讲，理解基于服务的建模和架构中包含的细节步骤是 非常重要的。

在我详细描述这些步骤以前，我们首先应理解你打算要做什么： 什么是 SOA，以及它看起来像是什么？在 定义了 SOA 后面的概念和观点以后，我将描述 SOA 的层和你如何去记录每个层中的关键架构决策，这些层帮助你为 SOA 构建蓝图，这些 SOA 正是那些你试图同一系列实现了 SOA 服务、流程和组件集成以及出现的项目、业务线、企业级成果和价值链所需要的。

回页首

Service-Oriented Architecture：概念模型

这 个概念基于一种架构样式，该样式在三个主要参与者之间定义了交互模型：服务提供者，公布服务描述并且实现服务，服务消费者，他既可以使用统一资源标记符 （URI）来直接使用服务描述，也可以在服务注册中心来查找服务描述并且绑定和调用服务。服务代理提供和维护服务注册中心，然而现在并没有通用公共注册中 心。

图 1 是一个显示了这些关系的元模型。

回页首

架构样式和原理

定义 SOA 的架构样式描述了一系列模式和指导方针来创建 松耦合，依赖业务的服务，由于描述、实现和绑定之间关系的分离，为新业务迹象和机会提供了空前的灵活性。

SOA 是企业级的 IT 架构，用来按需连接资源。在 SOA 中，资源对于价值网、企业、业务线内的参与者时可用的（典型的是在一个企业内或多个企业之间跨越多个应用程序）。它由一系列依赖业务的 IT 服务组成，这些服务共同满足了组织的业务流程和目标。你可以将这些服务设计成合成的应用程序并且通过标准协议来调用它们，如下面的 图 2所示。

服务是一种有具体服务描述的软件资源（可发现）。服务消费者可以搜索、绑定和调用服务描述。服务提供者实现服务描述的功能并且向服务消费者提供所需的服务质量。理论上服务应该统一由公布的方针来管理，并且因此支持动态的 可配置架构样式。

灵活的业务通过灵活的 IT 系统可以实现，主要通过接口、实现和 SOA 提供的绑定（协议）的分离，基于新业务需求，允许在及时给定的点延期 选择服务提供者，（功能和非功能（例如，性能、安全、可伸缩性等）需求）。

你可以在内部业务单元之间或者在业务伙伴之间的价值链之间以 不规则的实现模式来 重用此服务。不规则的实现引用了架构样式的能力来在他的交互模型中通过合成的方式来应用与参与者关联的模式和角色。你可以在架构中的一层上应用它，也可以 在贯穿企业架构的多个层上来应用它。在项目之间，它可以通过统一的、概念上可升级的方式在价值链内部的业务单元和业务伙伴之间。

回页首

上下文

在本文中，我介绍了鉴定、指定和实现的高级别的行为和一些基于服务建模的构件。基于服务的建模是基于服务的分析和设计（SOAD）过程，来建模、分析、设计和生产依赖业务分析、过程和目标的 SOA。

首先我将看一下你想要构建什么，也就是 SOA 和它的层。接下来我将通过讨论创建 SOA 所需主要的活动和技术来描述如何构建 SOA。

作为一个示例，我们假设你正在开发一个项目，并且目标是将一部分具有自服务帐目系统的银行业务线移植到 SOA上。

为了移植到 SOA，你需要一些超出服务建模的附加元素。它们包括：

• 采用和成熟模型。在 SOA 和 Web 服务的采用上你的企业处在那个成熟的相对级别上？采用的每个不同的级别都与它自己的唯一的要求。
• 评估。你有一些领导者吗？你已经涉足 Web 服务了吗？作为结果的架构好到什么程度？你应该继续维持同样的方向吗？这将衡量企业 SOA 吗？你已经考虑了所有应该考虑的事情了吗？
• 策略和规划活动。你如何规划到 SOA 的移植？你需要考虑的步骤、工具、方法、技术、标准和培训是什么？你的路线图和远景是什么？你如何达到目的？计划是什么？
• 管理方法。现有的 API 和能力是否应该变成服务？如果不是，哪个是符合条件的？每个服务都应该以通过某种方式为业务带来价值为目的来创建。你如何样毫无妨碍的来管理这些过程？
• 实行最佳实践。什么是可靠和经过测试的方式来实现安全，确保性能，遵从互操作性标准，设计来作改变？

上 面的关于移植到 SOA 和实现以后附加活动的讨论应该得到它们自己的文章，本系列中我将在随后的列中接触到这个。目前，让我们假设你为项目定义了范围，并且决定了集中在什么地 方：已经定义了一个焦点，用来将现有的系统或服务转化到一系列新的系统和服务。现在你可以开始基于服务建模来构建你的基于服务的架构。

回页首

SOA 的一个架构模板

SOA 的一个抽象观点将它描述为与业务过程结合在一起的合成服务的部分分层架构。 图 3 呈现了这种类型的架构。

服 务和组建之间的关系是，企业级的组件（大粒度的企业或者业务线组件）实现该服务并且负责提供它们的功能和维持它们的服务质量。通过组合这些公开的服务到合 成的应用程序，就可以支持业务过程流。综合的架构通过使用 Enterprise Service Bus（ESB）支持这些服务、组件和流程的路由、中介和转化。为了服务质量和非功能性的需求，必须监视和管理已经部署的服务。

对于每一层，你都必须做设计和架构决定。因此，为了帮助用文件说明你的 SOA，你可能应该创建文档，由每个层相应的部分所组成。

这里是为你的 SOA 架构文档设计的模板：

1. 范围 <此架构适用于企业的哪个领域>
2. 操作系统层
1. 打包的应用程序
2. 自定义应用程序
3. 架构决策
3. 企业组件层
1. 企业组件支持的功能范围
2. <这个企业组件支持业务领域、目标和过程>
3. 关于控制的决策
1. <作为这个客户端组织内部企业组件来选择某物的标准>
4. 架构决策
4. 服务层
1. 服务分类表
2. 架构决策
5. 业务过程和合成层
1. 业务过程可以表现为舞蹈编排（choreographies）
2. 架构决策
1. <哪一个过程需要编排在舞蹈编排里面以及哪一个镶嵌在应用程序里面？>
6. 访问或者表现层
1. <证明这层中 Web 服务和 SOA 的含意；即便要。例如，在用户接口级别上调用 Web 服务的 portlet 的使用，以及在此层机能上的含意。>
7. 集成层
1. <包含 ESB 因素>
1. <我们如何确保使用服务的客户端系统级的一致性（SLA）和服务质量（QoS）？>
2. 安全问题和决策
3. 性能问题和决策
4. 技术和标准的局限性以及决策
5. 服务的监控和管理
1. 描述和决策

层 1：操作系统层。本层包含现有的自定义构建的应用程序，也叫做 遗留系统，包含现有的 CRM 和 ERP 打包应用程序，以及 较旧的基于对象的系统实现，还有业务智能应用程序。SOA 的复合层架构可以利用现有的系统并且用基于服务的集成技术来集成它们。

层 2：企业组件层。本层由那些负责实现功能和保持公开服务 QoS 的企业组件组成。这些特殊的组件是企业和业务单元级支持的企业资产的受管理和控制的集合。 同企业范围资产一样，他们通过架构最佳实践应用程序来负责确保 SLAs 的一致。大多数情况下，本层使用基于容器的技术，比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。

层 3：服务层。业务选择来支持和公开的服务处在这一层。它们可以被 发现或 者直接静态绑定，接下来被调用，或者可能的话，编排到合成服务中。这个服务公开层同样提供了获取企业范围组件，业务单元特定组件，以及有些情况下，特定项 目组建的机制，并且以服务描述的形式具体化了他们的接口子集。因此，企业组件使用它们接口提供的功能在运行时提供服务实现。在这一层的接口公开为一个服务 描述，在这层中他们被公开以提供使用。他们可以独立存在或者作为合成服务。

层 4：业务过程合成或编排层。第三层中公开 的服务的合成和编排在这一层中被定义。通过配合、编排，服务被绑定成一个流程，并且从而作为单独的应用程序而共同作用。这些应用程序支持特殊的用例和业务 过程。这里，可视的流程合成工具，比如 IBM® WebSphere® Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用来设计应用程序流程。

层 5：访问或表现层。尽管这一层经常超出了 围绕 SOA 讨论的范围，但是它却变得越来越有意义。在这里我描述它因为标准越来越集中，比如用于 Remote Portlets Version 2.0 的 Web 服务和其他技术，这些技术追求在应用程序接口或者表现层来利用 Web 服务。你可以把它作为将来的层用来满足将来的解决方案的需求。注意到以下这两点是非常重要的：SOA 将用户接口从组件中分离出来；最终你需要提供从访问路线到服务或者合成服务的端到端解决方案。

层 6：集成（ESB）。这一层使服务可以集成，通过引入一系列可靠的性能的集合，比如智能路由，协议中介和其他转化机制，经常被描述为 ESB（参阅 参考资料）。Web Services Description Language（WSDL）制定了绑定，其包含提供服务的地址。另一方面，ESB 为集成提供了位置独立机制。

层 7：QoS。这 一层提供了监视，管理和维持诸如安全，性能和可用性等 QoS 的能力。这是一个通过 sense-and-respond 机制和监测 SOA 应用程序健康的工具来进行的后台处理过程，包括 WS-Management 和其他相关协议的所有的重要的标准实现以及为 SOA 实现服务质量的标准。

回页首

通过什么步骤来进行基于服务的建模和架构

本节描述了如何利用遗留的投资，来 联合自顶向下的，业务驱动的手段和自底向上的手段。

基于服务的建模手段提供了建模、分析、设计技术和活动来定义 SOA 的基础。它通过在 SOA 的每一层定义元素以及在每一层作严格的架构决策来起到帮助作用。它通过联合服务鉴别的自顶向下、业务驱动方式和通过利用遗留资产和系统引导服务鉴别来实现这一点。

这样，高级别的业务过程功能性为大粒度的服务更加的具体化。小粒度的服务 -- 这些可以帮助实现高级别的服务 -- 通过检查遗留功能性和决定如何创建适配器、封装器，或者组合遗留系统来具体化系统内经常调用的期望功能性可以来鉴别。

最后，使用 针对服务的建模，你使用 跨部分手 段来削减候选的可能已经被确定的服务的绝对数量。一个比较明智的手段应该是首先按照自顶向下来做，接下来进行目标服务建模，最后是自底向上的现有资产的遗 留分析。消息是：你将项目的范围定义至一个可管理、实现的集合越快，你就能更快的通过聚焦在关键服务来公开组成 SOA 基础的服务描述来实现价值。

这个功能性业务需求和遗留系统中现有投资利用的结合，为那些想要快速赢得和移植他们的企业到一个现代的 SOA 的组织提供了有效的解决方案。通过基于服务的集成的软件应用程序的联合因此变得具备可能性。

基于服务的集成是 Enterprise Application Integration（EAI）的一个进化，在 EAI 中，所有的连接通过位置透明的 ESB 概念被基于标准的链接替换，并提供了一系列灵活的路由、中介和转化能力。

回页首

基于服务的建模：服务的分析和设计

迄今为止，我已经通过描述 SOA 设定了阶段。我同样展示了要想构建 SOA，你需要在你 SOA 的每个层中做关键架构决策，并且你的设计必须反映一系列依赖业务的服务和关于他们如何通过编排来合成到应用程序的决策。

与对象不同，你在 SOA 中需要考虑两个观点；他们是服务消费者和服务提供者。服务代理目前不是主流，并且在后面的部分终将被涉及到。

SOA 的设计策略并不从“自底向上”开始，这是 Web 基于服务途径常有的事情。你必须记住，SOA 更加有战略意义，并更加依赖于业务。Web 服务是 SOA 的巧妙实现。许多关键的活动和决策存在不仅仅影响集成架构，而且还影响企业和应用程序架构。他们包含两个 图 4 中描述的消费者和提供者的活动.

图 4显 示了通过提供者和消费者的每个角色来管理的活动。注意，提供者的活动是消费者活动的父集（例如，提供者同样参与服务鉴别、分类等）。在许多情况下，角色的 区别来自如下的事实，消费者指定他们想要的服务，经常的搜索它，并且一旦他们确信和他们寻找的服务规范相匹配，并且是由服务提供者提供，他们就会根据需要 绑定和调用服务。提供者需要依次发布他们想要支持的服务；即在功能方面，更重要的是在消费者所需的 QoS 方面。这个在消费者和提供者之间的隐含的契约可能在 SLA 方面成熟为明确的契约；自动的或者通过业务和合法区域来处理。

上面描述的活动可以被描述为在基于服务的建模和架构方法内流动，如下面的 图 5 所示。

基于服务的建模和架构过程包含三个主要的步骤：服务，组件和流程（典型地，服务的编排）的鉴别，指定和实现。

Service 鉴别

这个过程由域分解、现有资产分析和目标服务建模的自顶向下、自底向上、中间向外技术的联合组成。在 自顶向下视图中，业务用例的蓝图提供了业务服务的规范。这个自顶向下的过程作为 域分解来被引用，域分解由业务领域到它的功能区域和子系统的分解组成，包含它的流程或过程分解成过程、自过程和高级别业务用例。很多情况下，这些用例是公开在企业边缘的业务服务，或者在贯穿业务线企业边界内所用的非常好的候选。

在过程的 从下到上的部分或者 现有系统分析中，现有的系统被分析和选择作为可行的候选，来为支持业务过程的底层服务功能性实现提供低消耗的解决方案。在这个过程中，你分析和利用了来自遗留和打包应用程序的 API、事务和模块。在有些情况下，为了支持服务的功能重新模块化现有的资产需要遗留系统的组件化。

中间向外视图由 目标服务建模组成，来验证和发现自顶向下或自底向上的服务鉴别手段中没有捕捉到的其他服务。它将服务连结到目标和子目标、关键性能指示和尺度。

服务分级和分类

这 个活动在服务被指定时开始。将服务分级为服务层次是非常重要的，反映了服务的复合或者不规则的本性：服务可以也应该由良好粒度的组建和服务组成，分级帮助 决定合成和分层，以及基于层次的相互依赖服务的协同构建。同样，它帮助减轻服务增值综合症，这种症状中，越来越多的小粒度的服务被定义、设计和部署，却缺 乏控制，导致了主要的性能、可伸缩性和管理问题。更加重要的是，服务增值未能提供服务，这些服务对业务是非常有用的。

子系统分析

这 个活动获取上面域分解过程中发现的子系统，并且指定子系统之间的相互依赖和流程。它同样将域分解过程中鉴别的用例作为子系统接口上公开的服务。子系统的分 析包含创建对象模型来表现内部工作方式，以及所包含的公开服务并且实现它们的子系统设计。这时，“子系统”的设计结构将实现为大粒度组件实现构造，在下面 的活动中实现服务。

组件指定

在下面的主要活动中，实现服务的组件的细节将指定：

• 数据
• 规则
• 服务
• 可配置概要
• 变更

服务分配

服务分配包括分派服务到目前鉴别的子系统。这些子系统具有实现了他们所公布的功能的企业组件。你经常会简单化假定，子系统同企业组件有一对一的联系。 结构化组件在你使用模式来构造 企业组件时会通过以下几点的联合的形式出现：

• 中介体
• Facade
• 规则对象
• 可配置概要
• 工厂

服务实现

这 个步骤指出实现给定服务的软件必须被选择或者自定义构建。其他可用的选项包括使用 Web 服务来集成、转化、订阅和外购不同功能。在这个步骤中，你决定哪个遗留系统模块用来实现给定的服务，以及哪个服务将从基础来构建。服务的其他实现决策不同 于业务功能包括：服务的安全、管理和监视。

事实上，项目趋向于利用任意数量的相应的努力来满足关闭的机会窗口。因此，我推荐并行的管理三个流。

自顶向下的域分解（过程建模和分解，基于变更的分析，方针和业务规则分析，领域特定行为建模（使用语法和图表））是同供组件化（模块化）和服务公开候选的现有遗留资产的分析并行控制。为了获得项目背后的业务意图和使服务同业务意图密切合作，目标服务建模可以来控制。

回页首

结束语

本 文中，我以基于服务架构、它的层和架构决策的相关类型的基础知识来开始。接下来，我通过一种方法，描写了基于服务建模的活动，以及从服务消费者和提供者角 度来看活动的重要性（服务代理将在后面的文章中涉及到）。这种方式为决定基于服务架构的三个基础方面提供了在分析和设计活动方面详细的指导：服务，流程和 实现服务的组件。我还描述了一个模板，你可以用它来在 SOA 的每个层上为你的架构进行决策。

我提到了，对于服务鉴别，自顶向下、自底向上和跨部分、目标模型分析三种手段的结合非常重要。接下来我关注了一下服务指定和实现的主要活动。

这一系列的下一篇文章中，我将应用该方法到帐户管理的空领域中，并且用例子来描述每个步骤。除鉴别、指定和实现之外，我还将讨论基于服务建模手段的其余活动，包含用来支持完整的 SOA 生命周期的部署、监视、管理和控制。

致谢

作 者希望象下面这些尊敬的同事和朋友致谢，感谢他们宝贵的建议和反馈（无特定顺序）：Luba Cherbakov，Kerrie Holley，George Galambos，Sugandh Mehta，David Janson，Shankar Kalyana，Ed Calunzinski，Abdul Allam，Peter Holm，Krishnan Ramachandran，Jenny Ang，Jonathan Adams，Sunil Dube，Ralph Wiest，Olaf Zimmerman，Emily Plachy，Kathy Yglesias-Reece，以及 David Mott。

回页首

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 阅读这篇文章“ 面向服务的分析与设计原理”，（developerWorks，2004 年 6 月）获取关于 SOA 项目的学科间建模手段的信息。
  
  
• 阅读“ 模式：基于服务的架构和 Web 服务”红皮书，SG24-6303-00，2004 年 4 月，Endrei M.， et al。
  
  
• 访问 WebServices.Org ™ 来查找关于 Goal-oriented approach to enterprise component identification and specification 的更多信息，Communications of the ACM，2002 年 10 月，K. Levi，A. Arsanjani。
  
  
• 获取 Ali Arsanjani，James J. Alpigini 和 Hussein Zedan 所著的 Externalizing Component Manners to Achieve Greater Maintainability through a Highly Re-Configurable Architectural Style。Proceedings of the ICSM: 628-. IEEE Press 2002。
  
  
• 访问 Ali Arsanjani 的模式和最佳实践网站来获取 The Enterprise Component Pattern 的更多信息，proceedings of pattern languages of programming 2000。
  
  
• 阅读 Patterns: Implementing an SOA with the Enterprise Service Bus“红 皮书，SG24-6346-00，August 2004，Martin Keen，Susan Bishop，Alan Hopkins，Sven Milinski， Chris Nott， Rick Robinson， Jonathan Adams， Paul Verschueren。
  
  
• 使用 快速启动 Web 服务访问 Web 服务知识、工具和技能，它提供了最新的基于 Java 的软件开发工具和来自 IBM 的中间件（试用版），以及在线教程和文章和在线技术论坛。
  
  
• 通过参与 developerWorks blogs 来加入到 developerWorks 社区。
  
  
• 访问 Developer Bookstore 以获取综合性的技术图书列表，其中包括数以百计的 Web 服务主题。
  
  
• 想获取更多信息吗？developerWorks 的 SOA 与 Web 服务专区拥有许多提供信息的文章和关于如何开发 Web 服务应用程序的入门级、中级的和高级教程。

最初的面向服务的体系结构（Service-Oriented Architecture，SOA） 的实现项目的经验表明，诸如面向对象的分析与设计（Object-Oriented Analysis and Design，OOAD）、企业体系结构（Enterprise Architecture，EA）框架和业务流程建模（Business Process Modeling，BPM）这样的现有开发流程和表示法仅仅涵盖了支持目前出现在 SOA 中的体系结构模式所需的部分要求。

在 Info World 最近的访谈（请参见 参考资料）中，Grady Booch 宣称“像对问题的良好抽象和良好的分离这样的工程基础决不会过时”，不过，他也指出“还是有现实的机会提升抽象的级别。过去的经验表明，必须将抽象的级别提升到公司处理的 业务领域，从而将整个企业 IT 前景都纳入考虑的范畴。

正如 Mark Colan 在文章 “面向服务的体系结构扩展 Web 服务的前景，第 1 部分”中介绍的，SOA 是一种新兴的企业结构形式，可以用于设计下一代企业应用程序。SOA 方法在有力地加强已经制定的良好通用软件体系结构原则（如信息隐藏、模块化和问题分离）的同时，还增添了一些其他的主题，例如服务编排、服务库和服务总线中间件模式。

需要结构化方法或 分析与设计方法来设计高质量的 SOA。因为现有的方法中没有一种能够满足程序设计人员对最新的 SOA 项目的要求，所以他们建议将已经形成的良好实践（如 OOAD、EA 和 BPM）中的原理组合起来，并且使用根据需要创新的原理来对其加以补充。

引言

面向服务的体系结构（SOA）和 Web 服务的基本观念是成为我们日常语言的一部分，并可看作是适于设计现代企业应用程序的体系结构形式。在这种背景下， 什么构成好的服务这个基本问题就成为确保成功实现 SOA 的关键。

像 面向对象的分析与设计（Object-Oriented Analysis and Design，OOAD）、 企业体系结构（Enterprise Architecture，EA）框架和 业务流程建模（Business Process Modeling，BPM）这样的现有建模规则为我们提供了高质量的实践，可以长期帮助标识和定义体系结构内的适当抽象。然而经验表明，这些实践各自单独应用时达不到要求。

在本文中，我们将研究 OOAD、EA 和 BPM 中的适当原理。我们还将推动对混合方法的需求，这种方法把所有这些规则中的原理与许多独特的新原理组合起来。这样得到的交叉学科 OOAD 方法使成功地进行 SOA 开发更容易，我们称之为 面向服务的分析与设计（Service-Oriented Analysis and Design，SOAD），它还有待正式定义。我们还只是刚刚跨入 SOAD 的殿堂。

回页首

面向服务的概念

在发现新的商机或威胁的预期下，SOA 体系结构形式旨在提供企业业务解决方案，这些业务解决方案可以 按需扩展或改变。SOA 解决方案由可重用的服务组成，带有定义良好且符合标准的已发布接口。SOA 提供了一种机制，通过这种机制，可以集成现有的遗留应用程序，而不管它们的平台或语言。

从概念上讲，SOA 中有三个主要的抽象级别：

• 操作：代表单个逻辑工作单元（LUW）的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA 操作可以直接与面向对象 (OO) 的方法相比。它们都有特定的结构化接口，并且返回结构化的响应。完全同方法一样，特定操作的执行可能涉及调用附加的操作。
• 服务：代表操作的逻辑分组。例如，如果我们将 CustomerProfiling视为服务，则 按照电话号码查找客户、 按照名称和邮政编码列出顾客和 保存新客户的数据就代表相关的操作。
• 业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。业务流程的例子有： 接纳新员工、 出售产品或服务和 完成订单。

  在 SOA 术语中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程 编排。典型的情况是调用已编排服务来响应业务事件。

回页首

为什么 BPM、EA 和 OOAD 还不够？

早期的 SOA 实现项目经验表明，诸如 OOAD、EA 和 BPM 这样的现有开发流程和表示法仅仅涵盖支持 SOA 范式所需的部分要求。SOA 方法在加强已经制定的良好通用软件体系结构原则（如信息隐藏、模块化和问题分离）的同时，还增添了附加的主题，例如， 服务编排、 服务库和 服务总线中间件模式，在建模时需要对它们给予特别的关注。

图 1展示了现有的 EA、BPM 和 OOAD 建模方法的主要应用领域，也是我们随后讨论 SOAD 的出发点。图中的水平轴表示 项目生命周期阶段；垂直轴表示不同抽象层或 领域之间的区别，而建模活动通常就是在其上进行的。

SOA 的远景是相当容易理解的，因为它的技术基础众所周知。例如，在任何 SOA 工作中，应用通用的软件体系结构原则和 OO 技术都是一个有效的开端。然而，正如我们已经提到的，早期采用者最常询问的问题是如何标识正确的服务。如前所述，OOAD、EA 和 BPM 在各自独立地应用时不能提供满意的答案，而这正是我们现在要说明的。

在由 Booch 和 Jacobson撰 写的开创性的书（大约 10 年前出版的）中介绍的 OOAD 方法在定义 SOA 方面提供了非常好的起点。同样地，虽然许多年来在体系结构层次中应用 OOAD 技术和统一建模语言（Unified Modeling Language，UML）表示法是一个常见的实践，但是 OOAD 还是与像类和单独的对象实例这样的微观层次的抽象有关。由于每个问题域常常都创建单独的用况模型，因此，应用程序开发项目，这个企业的大方向在许多情况下 变得模糊。此外，由于种种原因，用况模型并不总是与其对等的 BPM 保持同步。

诸如 Treasury 企业体系结构框架（Treasury Enterprise Architecture Framework，TEAF）、 面向特征的领域分析（Feature-Oriented Domain Analysis，FODA）和 Zachman这样的 EA 方法都将城市规划级的观点加在解决方案体系结构之上，但是并没有解决如何找到易于重用且具有持久性的高质量企业抽象的问题。

虽然 BPM 方法（如 BPMI）在功能工作单元之上提供了端到端视图，但是它们通常都没有触及体系结构和实现领域。例如，在像 用于 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL）这样的语言出现之前，BPM 表示法缺少操作语义。此外，我们还看到了许多流程建模与开发活动彼此分离的情况。

最后，现有的规则中没有一个可以解决如何为 SOA 启用 现有的应用程序的问题；大部分时间都采用自顶向下流程。现有的系统通常都存放有大量的重要数据和业务逻辑，并且不能简单地加以替代。因此，为了研究包装和重构策略，必须对这些系统进行自底向上的分析。因此，对现有应用程序的考虑会将我们带到中间相遇的流程。

由于这些原因的存在，所以需要混合 SOAD 建模方法。这种方法以最佳的方式组合了 OOAD、BPM 和 EA 中的原理，并且融入了一些具有创新性的原理。 图 2展示了这种新的方法的 SOAD 资源（原理和技术）：

EA

将企业应用程序和 IT 基础设施发展成 SOA 可能是一个大的负担，会影响多个业务线和组织单元。因此，需要应用 EA 框架和参考体系结构（如 开放组织体系结构框架（The Open Group Architecture Framework，TOGAF））以及 Zachman，以努力实现单独的解决方案之间体系结构的一致性。

根 据过去的经验，大多数现有的 EA 框架都在一个或多个方面有限制。例如，如果主要的问题是表示技术设备的低级构块如何在宏观层次互连，则无法获得业务层流程或服务视图。然而，在 SOA 的背景下，这种考虑问题的方式必须转换为以表示业务服务的逻辑构件为中心，并且集中于定义服务之间的接口和 服务级协定（Service Level Agreements，SLA）。

此外，许多企业级参考体系结构和框架是相当普通的，并没有触及设计领域。这样的高级体系结构无法为架构师和开发人员提供具体的战术意见，并且常常导致企业体系结构和解决方案体系结构之间出现根本性的分歧。

SOAD 必须帮助 SOA 架构师定义服务前景的整体业务级视图。这是当今的 EA 框架所无法提供的，它们需要未来特定于 SOA 的增强； 按需操作系统（On Demand Operating Environment，ODOE）是 IBM 针对这种趋势制定的主要战略。

BPM

BPM 是一个不完整的规则，其中有许多不同的形式、表示法和资源。另一种常用的技术是定义表示概念性流程流的 事件驱动流程链，正如 Barker 和 Longman所定义的。这第二种技术使用了不同于 UML 的表示法。

此 外，还有许多专用方法（如 BPM 技术）可能被咨询公司和企业资源规划（Enterprise Resource Planning，ERP）软件包厂商视为具有竞争优势。ARIS Implementation Platform 就是这样的产品的一个例子。其他的方法包括： Line of Visibility Enterprise Modeling(LOVEM) 和 IBM 的组件业务建模（Component Business Modeling，CBM）战略。

最近的趋势是定义表示可执行流模型（如 用于 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL））的标准方法。BPEL 将流程的范围从分析扩展到实现。这样的可执行模型引发了一系列的新问题，其中包括：

• 哪些方面应该用 BPEL 描述，哪些方面应该用 WSDL 描述？流程模型和传统的编程模型之间的区别在什么地方？
• 如何将非功能性要求和服务质量特征这样的方面加入模型之中？
• 同更传统的编码（例如在 J2EE 中）相比，在 BPEL 引擎的编程语言扩展中执行多少逻辑？
• 如何评定可执行流程模型的质量，其应用的最佳实践是什么？
• 什么工作角色进行 BPEL 流管理；是业务专家（分析人员），还是开发角色（软件架构师）？

必须利用所有现有的 BPM 方法作为 SOAD 的起点；然而，必须使用流程模型中用于驱动 候选服务和它们的操作的附加技术来对其加以补充。此外，SOAD 中的流程建模必须与设计层用况建模保持同步，并且必须给出与 BPEL 有关的问题的答案。

OO 范式与面向服务 (SO) 范式

OO 分析是一种非常强大且广为赞誉的方法，同样，SOAD 应该尽可能多地利用 OO 分析技术。要将 OO 分析成功地应用于 SOA 项目，您就必须一次分析多个系统。用况模型必须继续扮演重要的角色。然而，SOAD 必须主要是 流程，而不是 用户驱动的。因此，SOAD 需要 BPM 和用况建模活动之间的强链接。

在 设计层， OO 的目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的应用程序。对象是软件构造，其行为就像它们建模的真实世界的实体。例如，顾客 (Customer) 将有名称和联系信息，并且还可能有一个或多个与之相关的帐户对象。从 OO 的角度看，每件事情都是对象。

OO的基本原则是：

• 封装：软件对象就是包含模拟真实世界的对象的物理属性（数据）和功能（行为）的离散包。例如，帐户对象保持收支平衡并且包含平衡中的借贷机制。
• 信息隐藏：结构良好的对象有简单的接口，并且不向外界显漏任何内部机制。真实世界信息隐藏的例子是，您不需要详细了解汽车的工作原理就能够驾驶它。
• 类和实例： 类是定义特定类型的软件对象具有什么类型的属性和行为的模板，而 实例是具有这些属性值的个别对象。创建类的新实例称为 实例化。利用生物学进行类比，人就是一个类。所有的人都具有一些属性，比如身高、体重、头发和眼睛颜色等等。我们中的每个人都是这个类 HumanBeing 的实例，具有一些特定的身高、体重以及其他的属性值。类是一直存在的，而实例具有有限的生命周期。
• 关联和继承： 在 OO 中，表达类和对象之间的关联的能力是一个关键的概念；继承是关联的强形式，用于表达有关系：按照同样的方式，生物物种由这样的层次构成：界 (Kingdom)、门 (Phylum)、纲 (Class)、目 (Order)、科 (Family)、类 (Genus)、种 (Species)。我们常常发现软件对象的自然层次。例如，当您创建一个财务应用程序实体时，您可能需要构造像 经常帐户（CheckingAccount） 、 储蓄帐户（SavingsAccount） 和 贷款帐户（LoanAccount） 这样的对象。如果您看得更仔细一点（请参见 图 3），您将发现这些类共享许多属性，比如都有收支平衡帐户、借方帐户和贷方帐户等等
  图 3. UML 类继承示例
  
  与其重复定义和管理这些属性的代码，不如创建一个通用的 帐户（Account） 类，该类具有现金收支平衡并且可以处理借贷事务。所有其他的类都是这个 帐户（Account） 对象的专门形式。例如， 贷款帐户（LoanAccount） 将在零和某个约定的最大值之间具有负平衡，而 储蓄帐户（SavingsAccount） 将具有负平衡，并且将展示增加利息的行为，等等。
• 消息传递：为了完成一些有用的工作，软件对象需要相互通信。它们通过相互发送消息来这样做。例如，假定我们想将 $1000 从经常帐户转到储蓄帐户，要达到此目的，可以将带有参数 $1000 的 借消息发送到 经常帐户（CheckingAccount） 实例，并且将相应的 贷消息发送到 储蓄帐户（SavingsAccount） 实例。当实例接收消息时，它执行相应的功能，称为 方法，它有与消息相同的名称。
• 多态：这个术语描述两个或两个以上的类接受相同的消息但是以不同的方式进行实现的情况。例如， 自由经常帐户（FreeCheckingAccount） 实例和 经常帐户（CheckingAccount） 实例将响应 借 ($100) 消息，但是 自由经常帐户（FreeCheckingAccount） 实例将正好 $1000 记入它的帐户平衡的借方，而 经常帐户（CheckingAccount） 实例将 $1000 加上交易费记入它的帐户平衡的借方。

OO 支持应用程序分析、设计和开发的完整生命周期：

• OOAD试图找到最优的对象和最自然的类继承来实现它们。
• OO 开发集中于应用程序的渐进式开发，每次实现一个业务场景或用况。像 IBM WebSphere Studio Application Developer 这样的工具有助于开发人员快速地构造和测试 OO 应用程序。
• OO 运行时环境，例如由 Java 虚拟机提供的，提供应用程序服务（如垃圾收集（删除因使用它们的对象已经被丢弃而不再使用的资源））以及框架（如 J2EE）来为驻留在不同的服务器上的对象提供相互通信的机制。

目前与 SO 有关的 OO 设计实践的主要问题在于，它的粒度级别集中在类级，对于业务服务建模来说，这样的抽象级别太低了。诸如继承这样的强关联产生了相关方之间一定程度的 紧耦合（因而具有依赖性）。与此相反，SO 范式试图通过 松耦合来促进灵活性和敏捷性。目前，在 SOA 中还没有服务 实例的跨平台继承支持和一流的表示法来避免需要处理服务生命周期维护管理问题（如远程垃圾收集）。

这 些考虑事项使 OO 难以与 SO 体系结构样式直接保持一致。然而，对于设计已定义的服务中的底层类和组件结构，OO 仍然是一种有价值的方法。此外，许多 OOAD 技术（例如类、责任、协作（CRC）卡）也可以用于服务建模（如果它们提升到更高层次的抽象的话）。在本文后面，我们将回过头来讨论这一点。

图 4展示了可见性层次和 OO、 面向组件和 SO 设计提供的重点之间的对应关系。它还展示了在 SOA 和 SOAD 背景中它们之间的相互关系。

至于表示法，统一建模语言（Unified Modeling Language，UML）——通过一些附加的定型（Stereotype）和概要加以增强——自然成为 SOAD 的重要基础。

在使用 Rational Unified Process (RUP)—— 被认为是支持迭代软件开发的分析与设计的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要价值。然而，RUP 以 OOAD 的原则为基础，因而使其不容易与 SOA 设计保持一致。从 RUP 的角度来看，系统的体系结构是其通过已定义接口交互的主要组件的体系结构。此外，这些组件还由逐渐减小到类级粒度的更小组件组成。相反，在 SOA 中，系统的体系结构通常包括满足普通 业务服务需要的无状态、全封装且自描述的服务组成，它更接近于映射到 BPM，如 图 5所示。

这些服务可能包括许多协作或编排服务。这并没有排除 RUP 采用的 OO 观点，而是在其上实现了另一个抽象层。这个超层的作用是封装作为正式的跨层接口结构中的 RUP 构件（ 软件服务）设计的组件。

回页首

SOAD 原理

在这一部分中，我们将更详细地描述 SOAD 的需求，并且开始确定它的主题和原理。目的是将关于这个主题的讨论引到进一步的设计工作。进一步的工作无疑需要形式化 SOAD 方法。

SOAD 必须提供什么？

已经为 SOAD 确定了下列需求：

• 正如任何其他的项目和方法一样，必须正式（至少半正式）地定义 流程和 表示法。通过选择和组合 OOAD、BPM 和 EA 原理，就可以在需要时确定额外的原理。
• 必须有结构化的方法来概念化服务：
  • OOAD 为我们提供了应用程序层上的类和对象，而 BPM 具有事件驱动的流程模型。SOAD 需要将它们结合在一起。
  • 方法不再是面向用况的，而是由业务事件和流程驱动的。用况建模是在更低的层次上作为第二步进行的。
  • 方法包括语法、语义和策略。这就需要特别的组合、语义代理和运行时发现。
• SOAD 必须提供定义良好的品质因素和最佳实践（例如回答粒度问题）。必须回答 BPEL 提出的角色问题。例如，谁为哪部分工作负责：是开发人员、架构师，还是分析人员？
• SOAD 活动还必须回答这样的问题：什么 不是好的服务？例如：不可重用的任何东西都不可能成为好的一流 SOA 成员（即服务）。另一个例子就是带有挑战性的非功能要求的嵌入式实时系统，它们不能承受任何 XML 处理开销。
• SOAD 必须易于进行端到端建模，并且有全面的工具支持。假如 SOA 给业务带来了灵活性和敏捷性，就应该对从企业到体系结构和应用程序设计领域产生的支持方法有相同的期望。

品质因素

一些通用原则或品质因素已经确定，并且可以作为 SOAD 中的设计基准：

• 构思良好的服务给业务带来了灵活性和敏捷性；它们通过松散耦合、封装和信息隐藏使重构更加容易。
• 设计良好的服务是有意义的，并且不只适用于企业应用程序；服务之间的依赖性减到最少，并且是显式声明的。
• 服务抽象是内聚、完整和一致的；例如，在设计服务和它们的操作签名时应该考虑 创建（Create）、 读取（Read）、 更新（Update）、 删除（Delete）和 搜索（Search）(CRUDS) 隐喻。
• 常常声明的假定是，服务是无状态的（例如非对话式的）；为了要求服务在特定的问题域和上下文中是无状态的，将削弱这种声明。
• 领域专家无需深奥的专业知识就可以理解服务命名。
• 在 SOA 中，所有的服务都遵循相同的设计体系（通过模式和模板连接的）和交互模式；底层体系结构形式可以容易地标识（例如在体系结构复审期间）。
• 服务和服务使用者的开发除了领域知识之外只需要基本的编程语言技能；中间件专业知识只有少数的专业人员才需要，在理想的情况下，这种知识是为工具和运行时厂商所用，而不是为制作像 SOA 这样的企业应用程序的公司所用。

服务标识和定义

自顶向下的业务级建模技术（如 CBM）可以为 SOA 建模活动提供起点。但是正如我们在前面提到的，SOA 实现很少是在全新的项目中开始的；创建 SOA 解决方案几乎总需要涉及集成现有的遗留系统，方法是将它们分解成服务、操作、业务流程和业务规则（同时参见 图 6）：

• 将现有的应用程序和厂商软件包分解成表示相关操作组的离散服务集（自底向上方法）。
• 从应用程序中将业务流程和规则抽象为由业务编排模型管理的单独 BPM。

所有的 OOAD 都同标识和定义服务有关；但是还需要具有更高层的观点。此外，当 SOA 致力于比经典开发项目层次更高的开发时，就有了发挥其他创造性思维的空间。

直接和间接业务分析
通过项目相关人员的会谈和 CBM 来进行 BPM 和 直接需求分析是一个容易理解且非常合适的标识候选服务的方法。

过去的经验表明，这条主要的途径应该通过补充 间接技 术来加以改进。在选择候选服务时，产品经理和其他业务领导应该进行协商。例如，什么是计划付款和开票模型？应该商议假定使用正在构建中的系统的企业的组织 结构图。建议还考虑一下非 SOA 项目中任何现有的用况模型。用于对正在构造的系统进行营销介绍的术语是另一个很好的关于服务操作候选者的来源（特别是动词，很少关注营销动词！）。

域分解
在 Endrei中定义的域分解、子系统分析、目标模型创建和相关技术是 SOA 流程构造方法或 服务概念化框架（它是基于 Levi and Arsanjani先前完成的工作构建的）最有希望的提议。来自 SEI的 FODA 工作也为这方面的讨论做出了贡献。

服务粒度
选择正确的抽象级别是服务建模的一个关键问题。您常常会听到 进行粗粒度建模的建议。这有点过于简单化了。您应该将其改为在不损失或损害相关性、一致性和完整性的情况下 尽可能地进行粗粒度建模。在任何 SOA 中，都有细粒度服务抽象的空间（假定有业务要求的话）。由于 SOA 并不等同于 Web 服务和 SOAP，因此可以使用不同的协议绑定来访问抽象级别不同的服务。另一种选择就是将一些相关的服务捆绑成粗粒度的服务定义，这是门面模式的变种。

命名约定
应该定义企业命名模式（XML 名称空间、Java 包名、Internet 域）。简单的例子就是始终用名词来命名服务，而用动词来命名操作。这种最佳实践来源于 OOAD 空间。

第一类 SOAD 原理

除了组合 OOAD、BPM 和 EA 技术之外，还有几个重要的 SOAD 概念和方面有待充实：

• 服务分类和聚合
• 策略和方面
• 中间相遇流程
• 语义代理
• 服务获取和知识代理

服务分类和聚合
服务有不同的用法和用途；例如，软件服务可以不同于业务服务（如前面的 图 5所示）。此外，还可以将原子服务编排成级别更高、功能齐全的服务。

服务组合可以通过可执行模型（如 BPEL 建模的模型）来加以简化；这是传统的建模工具和方法不能处理的事情。

策略和方面
服务具有语法、语义和 QoS 特征，所有这些都必须进行建模；正式的接口契约必须涵盖的比 Web 服务描述语言（Web Services Description Language，WSDL）的多。因此， Web 服务策略（WS-Policy） 框架是一个重要的相关规范。

除了已经制定的良好 体系结构可跟踪性原则之外， 业务可跟踪性也是一个理想的品质：应该有可能将所有的运行时构件直接与非技术领域专家可以理解的语言联系起来。这对于直接在业务和服务层公开的抽象非常重要。Sarbanes-Oxley (SOX) 法案（请参阅来自 Astor的文章）是需要这种业务可跟踪性的业务驱动程序的一个例子。

流程：中间相遇
在真实世界中，并没有全新的项目，必须始终考虑遗留系统（ 遗留系统是现有系统的同义词）。因此，需要 中间相遇的方法，而不是单纯的自顶向下或自底向上的流程。

在 设计取决于现有的 IT 环境而不是现在和将来的业务需要的情况下，自底向上的方法往往会导致不好的业务服务抽象。而自顶向下的方法可能会产生不足的非功能性需求特征，并且损害其 他的体系结构品质因素（例如因域模型中缺乏标准化而导致的性能问题），另外，也会在服务和组件中产生不匹配的不良问题。

服务获取和知识代理
这是一个知识管理和生命周期问题：如何成功地准备好服务并且使其在概念化之后可以重用？

应该将重用看作是标识和定义服务最主要的推动标准之一。如果组件（或服务）不可能重用，就不无法将其作为服务进行部署。它可以连接到另一个与企业体系结构相关的服务，但是不能单独作为一个服务而存在。

然而，即使从开始就计划好了重用，还必须形式化服务获取流程。由多个使用者使用服务是明确的 SOA 设计目标。构建时服务注册中心（例如企业 UDDI 目录）可能能够解决部分问题。

回页首

示例：汽车工作订单

汽车工作订单（Automotive Work Order）描述了一家汽车维修公司管理其顾客运营的流程。我们将通过这个领域中的问题来阐述 SOAD 的观点。

工作订单代表汽车服务公司和顾客之间的约定，以进行一系列例行维修或应急维修，例如例行 50,000 英里服务，更换刹车片或轮胎，或者换油。

业务场景（如 图 7所示）如下：

• 当顾客打电话预约时创建工作订单。
• 为每个计划的维修活动或操作创建一个独立的工作订单项，其中包括需要使用的零件、备件和劳务的详细情况。
• 在安排预约之前确保所有必需的零件都有库存。
• 需要为每个工作订单项安排具有适当的装备的维修间以及具备适当的条件的机器。
• 计算估计的总成本，接着顾客认可该预约；或者方案终止，随即取消工作订单。
• 在预约之前，立即在选定的维修间装配必需的零件、备件、工具和设备。
• 当顾客到达时，进行计划的活动以及在检查交通工具时显得有必要的任何其他活动。
• 记录所用的零件和备件的实际价值以及劳务。
• 在完成所有的维修时计算总费用。
• 创建发票并且将其交给顾客。

如果您将此作为一个独立的应用程序从头开始创建，您就可能创建一组如 图 8所示的类。

如果您将工作订单构造为一个 OO 应用程序，这些软件对象将包含所有必需的业务规则，并且理解应该遵循的业务流程。

然而，这种方法在实践方面存在着一些缺点：

• 许多步骤涉及与现有遗留系统和数据库（例如帐单编制、日程安排以及库存系统）的连接，它们不可能遵循 OO 范式进行设计（在这样的情况下，应用适配器或仲裁器会有所帮助）。
• 为了使系统尽可能地灵活，将一些规则外化是有帮助的，这样就可以在不更改代码的情况下修改流程或工作流。例如像下面这样的规则：
  • 标准的 24,000 英里服务包括四公升油。只是在使用四升以上的油或顾客要求优质油（如合成油）时才应该收取额外的邮费。
  • 在遗留应用程序中有一套工业标准为普通汽车维修活动进行劳务估价。除非维修人员收取的费用超过该估价的 X% 并且报告产生差别的有根据的原因，否则顾客就应该支付标准的劳务费。
  • 如果超过估价的 Y% 以上，就应该联系顾客以进行确认。

SOAD 为这些问题提供了极好的解决方案。由于它基于相关的行为对服务进行分组，而不是进行封装（行为及数据），所以这组服务与业务对象略有不同。

例 如，您可能将工作订单（Work Order）和工作订单项（Work Order Item）一起分到工作订单服务（Work Order Services），并且创建日程安排（Scheduling）、目录（Catalog）和库存（Inventory）服务。另外，因为没有服务实例，所 以没有与服务之间的关系等价的东西。工作订单的服务模型可能看起来如 图 9所示。

与 OO 范式不同，这个模型并不表示功能系统。既没有考虑流，也没有描述业务事件或规则。在 SOA 范式中，在服务外面维护的业务流程编排决定了执行服务调用的顺序和时间。

从概念上讲，从第一次顾客联系到完成工作和帐单支付的整个业务表示单个宏观层次的工作单元，并具有数天到数周不等的生命周期。毕竟，从企业的角度来看，工作单元会产生收入。

然而，实际出现的情况是在一段相对长的时间内单独发生的一系列集中活动，例如，定义活动、安排预约、选择零件和备件、进行维修活动等等。在 IT 系统中，没有实际的 流程会持续几分钟以上；事件之间的业务流程状态以数据的形式保存在数据库中。

这种类型的流程可以用状态转换模型（例如 UML 中可用的）很好地进行表示。 图 10显示了用有限状态机（finite-state machine）方法如何对业务流进行建模的示例。它是在业务流程进行时工作订单的状态如何改变的高级视图。

业务流程编排集中于状态之间的这些转变。单独的操作永久地记录相关的状态改变。

图 11显示了部分编排的示例，其中包括 图 10所示的业务场景中的步骤 1 到 5（例如，顾客定义他们的交通工作所需的工作，并且安排预约以进行实施）。

回页首

总结和展望

在 本文中，我们已经讨论和激发了对创新的中间相遇的方法的需求，这种方法搭建了业务和 IT 之间的桥梁，并且支持 SOA 项目的分析和设计阶段。我们还提议将这种新的交叉学科的 SOAD 方法作为一个整体的建模规则，它以现在构建良好且广为赞誉的 OOAD、EA、和 BPM 为基础。

在详细定义 SOAD 表示法和流程的同时，还确定了关键的原理，比如服务概念化（或标识）、服务分类或聚合、策略和方面、中间相遇流程、语义代理和服务获取（以供重用）。

SOAD 需要增强现有的软件开发方法，进一步提高企业应用程序开发项目的可用性和适用性。随着时间的推移，还将发展相关的最佳实践。

我们还认识到，UML 在流程的表示法选择方面将继续占支配地位；可能需要进行增强以满足更广泛的 SOAD 的要求。

完成 SOAD 方法的下一步就是定义所需的端到端流程和表示法，复审活动中的角色和它们的责任，并且继续检查所提议的方法在项目中的有效性。

回页首

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 请访问 IEE Xplore 站点以获得由 Ali Arsanjani 撰写的 A Domain-Language Approach to Designing Dynamic Enterprise Component based Architectures to Support Business Services。
  
  
• 要获得更多关于 Sarbanes-Oxley and Web Services的信息，请访问 SYS-CON 站点。
  
  
• 在 Amazon.com 上获得由 Barker 和 Longman 撰写的 CASE Method - Function and Process Modeling。
  
  
• 在 Addison Wesley 站点获得由 Grady Booch 撰写的 Object-Oriented Analysis and Design with Applications。
  
  
• 在 BPMI.org 上查阅 Business Process Management Initiative。
  
  
• 阅读 面向服务的体系结构扩展 Web 服务的前景，第 1 部分（ developerWorks，2004 年 4 月）。
  
  
• 阅读 Endrei M. 等撰写的 Patterns: Service-oriented Architecture and Web Services 红皮书（SG24-6303-00，2004 年 4 月，Endrei M.）。
  
  
• 在 Carnegie Mellon University Software Engineering Institute (SEI) 站点上学习更多关于 Feature-Oriented Domain Analysis的知识。
  
  
• 访问 InfoWorld.com 以获得更多关于 Interview with Grady Booch的信息。
  
  
• 阅读 Object-Oriented Software Design : A Use Case Driven Approach。
  
  
• 查阅由 Ali Arsanjani 撰写的 A goal-driven approach to enterprise component identification and specification。
  
  
• 阅读由 F. Leymann、D. Roller 和 M.T. Schmidt 撰写的 Web Services and Business Process Management（IBM Systems Journal，2002 年第 2 期第 41 卷）。
  
  
• 了解更多关于 Rational Unified Process (RUP)的信息。
  
  
• 要获得更多关于 Treasury Enterprise Architecture Framework (TEAF)的信息，请访问 Software.org 站点。
  
  
• 访问 Open Group 站点以获得更多关于 The Open Group Architecture Framework (TOGAF)Version 8.1 的信息。
  
  
• 获得关于 Web 服务策略框架的信息： Web 服务策略（WS-Policy）框架。
  
  
• 了解更多关于 IBM 的 on demand Operating Environment的信息。
  
  
• 在 Zifa.com 查阅关于用于企业体系结构的 Zachman 框架的信息。
  
  
• 在 Developer Bookstore购买涉及各种各样的技术主题的打折书。
  

回页首

作者简介

		Olaf Zimmermann 是 IBM worldwide Applied Web Services 组的顾问 IT 构架师。他在分布式计算、面向服务体系结构、Web 服务/XML 和 J2EE 方面颇有专长。在过去的几年里，Olaf 指导了大量与 Web 服务有关的交流项目，包括几本产品参考书。他是 Springer 教科书 Perspectives on Web Services（ISBN 3-540-00914-0）的作者。他还参与了几本 IBM ITSO 红皮书（比如 Web Services Wizardry with WebSphere Studio Application Developer（SG24 -6292-00））的写作。Olaf 从 1994 年开始就与 IBM 合作，涉及的领域非常广泛，其中包括产品开发、技术预售咨询、教学以及系统集成。Olaf 在位于德国 Braunschweig 的 Technical University 获得计算机科学学位。您可以通过 ozimmer@de.ibm.com与他联系。

		Pal Krogdahl 是一名解决方案架构师，在 IGS 的 IBM Business Consulting Services（位于瑞典）工作。他从 1998 年开始就职于 IBM，涉及了多个领域，比如软件开发、售前技术咨询和解决方案体系结构。他擅长的领域包括分布式计算、中间件和应用程序服务体系结构，主要集中在 EAI 和 SOA。Pal 最近撰写了一些范围广泛的文章，探讨的主题有基于 SOA 的 EA、以及它们与 IBM 用于电子商务和按需操作系统环境的模式的关系。到目前为止，他已经完成了 IBM International Technical Support Organization 的一些高级培训，在该组织中，他同人合著了一些与 WebSphere 有关的红皮书，这些红皮书主要集中在 Web 服务和 SOA 方面，例如 Patterns: Service-Oriented Architecture and Web Services(ISBN 073845317X)。在过去的 18 个月里，他一直在向 IBM 内外的技术人员介绍 Web 服务和基于 SOA 的按需操作环境的实现方面的知识。您可以通过 pal.krogdahl@se.ibm.com与他联系。

		Clive Gee 是一名高级解决方案架构师，工作在 IBM Enterprise Integration Services 部。他于 1976 年加入 IBM Europe 并于 1997 年调到 IBM US。1990 年，作为创立 IBM European Object Technology Practice 的一员，他是 IBM 中第一位 OO 的支持者。从那以后，他获得了领导企业 OO 交流项目的大量实践经验，涉及多个行业（如公用事业、金融业、运输业、零售业和电信业）的复杂系统集成和应用程序开发。目前，他正忙于为一个重要的美国客 户配置部署 SOA 解决方案。Clive 从苏格兰的 University of Stirling 大学获得理论物理博士学位。您可以通过 clive@us.ibm.com与他联系。

　　基于SOAP侦听的SOA消息监控是构建高效SOA安全性解决方案基础的一种手段。SOAP侦听

　　图1 一个用于监控SOAP消息的SOAP拦截器用作这个SOA中的安全性基础。SOAP拦截器分析它监控的SOAP消息的标题头中包含的用户身份，并将其与保存在现有安全性基础架构中的名称相比较。结果就是对SOAP消息发送方和接收方进行了身份验证和授权。

　 　就是在web服务消费者和web服务之间来回传递的SOAP消息的路径中放入一个叫做“SOAP拦截器”的特殊软件块。因为其分类、监控、复制和转发包 含大量数据的SOAP消息的能力，SOAP拦截器可以在SOA安全性方面发挥重大作用。如图7所示，一个SOA安全性解决方案“监视”着到达web服务的 SOAP调用消息和对这些服务调用的响应。当它“看见”一条消息时，SOA安全性解决方案就会进行检查，以确保发出请求的实体是经过身份验证和授权可以使 用web服务的。SOA安全性解决方案通过检查SOAP消息标题头中包含的数据实现了这一点。

　　在大多数情况下，SOA安全性解决方案是 对现有安全性解决方案的扩展，而现有安全性解决方案是在迁移到SOA之前为保护整个企业而部署的。因此，SOA安全性解决方案很可能不得不与现有安全性基 础架构进行连接和通信。如图7所示，SOA中的用户身份验证和授权发生在基于企业的授权用户数据库检查用户证书的时候。侦听SOAP消息，并把消息标题头 中列出的用户与保存在现有安全性基础架构中的用户进行比较，便可实现身份验证和授权。

SAML和联邦身份验证

　　当需要 对企业外部的SOA用户进行身份验证和授权时，又会怎么样呢？SOA的开放性使得上述情况比以往任何时候都更可能出现。您可能会面临这样一个难题：在一组 在现有安全性基础架构中没有记录的用户中，搞清楚每个用户的身份。为了解决保护第三方过程中固有的安全性问题，SOA安全性解决方案可以使用联邦身份验 证。联邦身份验证是这样一个过程：通过这个过程，多方可以达成一致，使用一组给定的标准来对一组指定的用户进行身份验证。联邦身份验证方法的使用者可以创 建一个联邦身份管理系统(Federated Identity Management System)，这是一个已验证用户的库。SOA安全性解决方案可以通过检查联邦身份管理系统来对某个用户进行身份验证。换句话说，一些相互通信的系统的 “联邦”，可以一致同意某个用户是合法的。

　　在某些情况下，身份验证过程会导致在SOA安全性解决方案中创建安全断言标记语言 （Security Assertion Markup Language，SAML）断言，用于以一种可为用户调用的web服务所接受的方式表达用户的真实性。SAML是一种基于XML的标准，它为以标准方式 描述安全性信息提供了一个框架。WS-Security是迄今为止得到认可的安全性标准集合的总称。许多SOA安全性解决方案都利用了这些新兴的安全性标 准。如图8所示，SOA安全性解决方案可以侦听SOAP消息，然后使其经过一个对用户进行身份验证的过程。接下来，SOA安全性解决方案把SOAP消息传 递给目的web服务，但是会附加上一个SAML断言。注意：SAML断言不依赖于联邦身份验证过程。

　 　图2 要在SOA安全性中使用联邦身份验证，SOAP拦截器必须把传入的SOAP消息转发给安全性解决方案，该安全性解决方案再把SOAP消息标题头中包含的用 户身份与联邦身份验证数据库中列出的用户进行匹配。如果匹配成功，SOA安全性解决方案就会创建一个安全“断言”，内容是用户已经在安全断言标记语言文档 中通过了身份验证，该文档是在SOAP消息到达它要调用的web服务时附加给该SOAP消息的。

应用程序代理

　　一种非 常有效的保护核心系统的方法是避免让任何人访问驻留平台的服务。可以通过为SOA中的web服务部署一个代理做到这一点。如图9所示，一个受保护的代理可 以代表实际的web服务接收所有web服务请求，并对其做出响应，从而保护web服务免遭恶意的侵害。代理方法的另一个好处在于，它能够减轻企业安全性基 础架构的负担。代理可以降低网络流量，具体方法是集中管理和缓存对web服务请求的身份验证和授权，而不是每次用户想调用web服务时，就在网络上使用大 量消息对该用户进行身份验证和授权。代理还在消息中插入了身份验证和授权SAML断言，从而消除了实际web服务直接查询安全性系统的需要。

契约管理

　 　在下一章中，我们将花大量时间来讲述这个主题，但是作为主要的SOA管理问题之一，契约管理同样在SOA安全性中起着举足轻重的作用。契约就是用于管理 web服务使用情况的一组规则。例如，某个契约可能会规定，某个特定用户有权每天调用某个特定的web服务十次。而且在调用过程中，服务水平必须满足特定 的参数，比如一秒钟的响应时间。

　　在安全性方面，契约有助于确定SOA是否运行正常，或者由于违反安全性规则而误用。如图10所示， SOA拦截器把web服务请求和响应数据发送给SOA安全性解决方案，然后该SOA安全性解决方案再确定是否满足契约。如果某个安全性问题（比如DoS攻 击）使web服务的速度降低到契约规定的服务水平以下，SOA安全性解决方案就会警告管理方有问题存在。当然，一次足够严重的攻击可以导致整个网络崩溃， 但是安全性解决方案至少可以发出有问题存在的通知。

　　图3 通过处理SOAP消息流量，降低企业安全性基础架构的负担，并保护web服务免于误用，web服务代理有助于保护SOA。

　　图4 SOA安全性解决方案监控服务水平，并在安全性问题导致web服务降低到契约规定的服务水平以下时发出警告。

证书、密钥和加密

　 　这些年来，IT领域先后出现了很多消息级的安全性技术，包括密码术。现在，也可以对SOA应用这些技术。这些过程，包括数字签名、证书、密钥和加密，都 可用来保护SOA。在这里我声明一点：对于这4种安全性技术中的每一种，都可以写出一本甚至是好几本著作。请把本节看作是对与SOA相关的基于加密的安全 性的一个概述。

　　如果希望让SOA拥有健壮的安全性，保证web服务的用户都可以得到适当的身份验证，而未经身份验证的人无法读取在 web服务及调用它们的应用程序之间往返的信息，那么无疑需要对SOA安全性解决方案应用功能强大的公钥/私钥加密工具。密钥是一个具有某种特殊的数学特 性的大数（数百个数位）。尽管形式和大小各不相同，但密钥都有一个基本属性，即，可以与另一个密钥进行惟一关联。也就是说，当一个密钥遇到其惟一的匹配密 钥时，双方都会说，“哦，就是你了，我惟一的匹配…不会再有其他的什么人了。”

　　惟一的密钥对具有如下两个基本功能：

• 因为它们是惟一的，所以它们是非常强大的身份验证工具。
• 由于它们的数学特性，它们可用于创建经过不可测知的过程进行加密的惟一消息，这些消息只能被拥有惟一的匹配密钥对的用户所读取。

　 　下面讲述当两个用户想交换加密信息时的工作原理：用户A创建一个惟一的密钥对。然后，他在自己的系统中隐藏其中的一个密钥（“私钥”），却把另一个密钥 （“公钥”）发送到用户B可访问的网络上某处。然后，用户B使用公钥来加密他想要发送给用户A的信息。实际过程涉及到大量让我想一想就头痛的数学知识，但 是基本上，公钥和消息数据是通过一个加密算法来运作的，该加密算法生成一个没有私钥不可能打开的加密文件。接下来，用户B把经过加密的消息发送给用户A， 而用户A则使用最初隐藏的私钥来对加密数据进行解密。结果，用户A是世界上惟一一个能够解密这些加密数据的人，因为（只有）他拥有与用户B的公钥匹配的惟 一私钥。

　　现在，如果您像我一样爱刨根问底，您可能会想，但是用户A如何知道用户B真的是用户B呢？如果某位黑客侵入到用户B的系统中， 并找到了他使用的公钥，那怎么办呢？为了回答这个有效性问题，人们使用了大量实体来确保特定用户的真实性，并授予他们证明其真实性的数字证书。这些实体叫 做certificate authority (认证机构，CA)。CA的一个著名例子是VeriSign，它提供用于电子商务事务的证书。

　 　使用密钥、加密和证书来实现保密性和身份验证的SOA安全性解决方案如图11所示。在我们的制造商例子中，供应商系统想发送一条SOAP消息给制造商的 web服务。为了做到这一点，制造商必须首先发送一个公钥给CA。然后，供应商系统从CA请求一个证书。供应商收到的证书包含与制造商系统中存在的私钥相 匹配的公钥。然后，供应商使用证书的公钥加密其消息，然后再把消息发送给制造商。然而，和前面的例子一样，SOA安全性解决方案侦听消息，并使用CA检查 证书的有效性。这可以验证供应商的身份。只有在通过身份验证之后，加密后的SOAP消息才能被发送给制造商。SOAP消息到达之后，制造商就使用它的私钥 对消息进行解密和处理。

　　如果您觉得这听起来更多地像是在发送消息，那么您想得没错。就像在IT的其他领域中一样，SOA中的安全性会带 来大量“开销”。在到达目的地之前，每条消息都必须经过好几个地方。证书文件可能会很大，从而给网络造成很大的负担，而且整个过程往往会降低性能。但是遗 憾的是，它仍然是必不可少的。

XML加密

　　 图 5 在安全性SOA中使用公钥/私钥加密和证书的步进式过程

　　 图字：

1. 制造商将公钥发送给认证机构，并将私钥隐藏在自己的域中
2. 供应商从认证机构请求包含制造商公钥的证书
3. 供应商向制造商发送使用公钥进行加密并包含证书的消息
4. SOA安全性解决方案向认证机构发送证书，以便对供应商进行身份验证
5. SOA安全性解决方案向制造商发送使用私钥进行加密的SOAP消息

　 　为了保留SOA的开放性，同时制订严格的消息级的安全性标准，您很可能想在加密时使用XML。当SOA安全性解决方案使用密钥对消息进行加密时，它会把 消息转换为一段经过加密的XML。消息是XML格式的，但是内容并不可见，因为使用加密算法将其隐藏起来了。这样做的好处在于，接收消息的系统可以把它当 作XML来接收、解密和处理，而不依赖于定制或专有的消息传递标准。这样我们就获得了安全性，同时系统仍然基于开放标准。

数字签名

　 　数字签名是另一种消息级的安全性形式，它是证书、密钥和加密等安全性方法的变体。数字签名就是附加给SOAP消息的证明真实性的数学语句。数字签名是一 个基于密钥的数（同样是一个非常大的数），它对您的身份和消息内容进行惟一的处理，具体方法是对两组数据（密钥和消息）运行一个特殊的算法。举一个简单的 例子，如果您的消息是“hello”而密钥是12345，算法将处理这两种输入——单词“hello”的数值和密钥数12345——并生成第三个数，这第 三个数就是数字签名。当接收系统获得消息和附加的数字签名时，它可以使用密钥来验证以下内容：

• 您是消息的真正创建者（身份验证），
• SOAP消息在传输过程中没有改变。

　 　如果消息被改变了，那么惟一的数字签名将不再与密钥和用于创建密钥的原始消息相匹配。数字签名和先前描述的完整加密过程之间的区别在于，如果使用数字签 名，不必对整条消息进行加密。因此，系统的性能得到了提升。只要您不介意别人可以看到您的纯文本格式的消息，那么数字签名就可以为SOA提供高度的数据安 全性和完整性。

　　签名可以是一个不可否认性（nonrepudiation）组成部分，该特性是一个需要在SOA环境中解决的安全性重要 方面。不可否认性是指一个组织的一种能力：验证发生了特定的处理，并从而不给发送方提供否定进行了处理的机会。例如，如果您针对某种商品下了一份电子订 单，而该订单并没有以某种方式（比如使用数字签名）进行验证，那么对方就有可能否认收到该订单。如果批发商的系统提供不可否认性，那么批发商就可以肯定该 订单已经送达。

重放攻击保护和审计

　　最后，SOA安全性解决方案应该提供一种用于跟踪SOAP请求的工具，从而降低 DoS攻击带来损害的可能性。通常，跟踪特性将监控SOAP消息的发送方及其创建时间。在某些情况下，SOA安全性解决方案将使用一个惟一的识别码给 SOAP消息打上印记。如果解决方案被设置为阻塞复制消息，那么同一条消息是不可能被发送两次的。消除这种可能性有助于降低黑客使用复制请求淹没SOA的 可能性，这是DoS攻击中常用的一种手法。

　　审计是SOAP消息跟踪功能的进一步发展。如果SOA安全性解决方案被配置为跟踪消息，那么 它应该能够生成特定时期中SOA消息流量的使用日志和审计报告。审计有很多用途，但是在安全性领域中，它用于记录所发生的事情，以便研究安全性问题并诊断 潜在的安全漏洞。这类日志已经成为实现管理目标（比如对Sarbanes-Oxley法案的服从）所必不可少的。

明智的管理人员所给出的忠告：不要让安全性吓倒了您

　 　SOA安全性是一个很大的主题。我可以就这个主题写一本书。（事实上，这是一个不错的主意…）在本章中，我的目的是提供一个概述，好让您可以评估自己对 这个主题所掌握的信息。如果您是一位企业主管，我的建议是，要避免被安全性问题吓倒。人们很容易被安全性吓倒，安全人员也不例外，这阻止了他们做些实际工 作以消除对于安全性问题的恐惧。实际上，我本来可以提出一个您正在考虑的IT解决方案，并让您了解到围绕该解决方案的大量安全性噩梦，这些噩梦足以使您远 离该解决方案。

　　相反，我建议您寻求安全性方面的高质量建议，并探讨企业中已经实施了哪些。如果您这样做，那么您的企业就很可能会拥有一 个（或一些）相当健壮的安全性系统。实施SOA的难点在于如何把现有的安全措施扩展成为由SOA构成的web服务。许多SOA安全性解决方案的设计目的就 是为了与现有的安全功能有效互连。如果实现的话，安全性风险可能稍微易于管理一些，而您也可以继续实施您的计划了。

结束语

　 　安全性是SOA中的一个焦点问题，因为SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互。身份验证和授权在这个环境中变得更加富 于挑战性。在未受保护的SOA中，想要阻止web服务的未授权使用实际上是不可能的；未授权用户可以非常轻松地访问web服务。Web服务不具备跟踪谁在 使用它们或者谁被允许使用它们的固有功能。无法阻止不必要的监听和消息侦听。未受保护的SOA让黑客有机会监听SOAP消息并看到私密信息。此外，在未受 保护的SOA中，侦听SOAP消息并（出于危害和欺骗的目的）重新发送消息或转换消息内容要相对容易一些。

　　由于SOA架构的开放性本 质，您无法保护SOA中未知的第三方。第二级和第三级用户（例如您的合作伙伴的合作伙伴）是可以访问未受保护的SOA的。因此，未受保护的SOA很容易超 负荷运转。如果没有访问控制，未受保护的SOA很容易被来自黑客的大量SOAP消息所“淹没”。结果可能导致DoS攻击损害系统的正常功能。最后，您还没 有处理记录。未受保护的SOA无法跟踪其用户或消息。因此，没有可用于研究安全性问题或诊断安全性漏洞的可审计使用记录。

　　存在一些可以 解决所有这些问题的预打包和定制的SOA安全性解决方案。在分析SOA安全性需求时，可以考虑实现一个支持SOAP消息监控、联邦身份验证、应用程序代 理、契约管理、证书、密钥和加密以及审计记录的SOA安全性解决方案。这个清单似乎很长，但是事实上，如果缺少其中任何一项，SOA的所有优点都可能遭到 破坏。

　　SOAP消息监控利用了一个SOAP拦截器模型，以便在将SOAP消息从调用系统发送给web服务时对其进行侦听和监控。 SOAP消息监控是SOA安全性的基础，因为它让安全性解决方案能够停止和分析每条消息，以进行用户身份验证和授权。为了保护第三方，安全性解决方案可以 利用联邦身份验证。应该通过一个联邦身份验证过程提供对系统中的用户进行身份验证的能力。最终将获得一个为web服务的用户提供可信身份验证的SAML断 言。

　　Web服务应用程序代理在实际的web服务中接收和处理SOAP请求，从而对安全性有所帮助。它可以使所有的用户都远离实际的服务。代理不仅可以减轻网络的负载，还可以为SOA提供一个额外的安全性层。

　　契约管理是另一项对安全性有所帮助的SOA管理特性。契约确立了谁有权使用web服务以及何时可以使用它。契约通过消除非契约方的使用，提高了SOA的安全性。

　 　对于一个真正安全的SOA来说，证书、密钥和加密同样是必不可少的。最健壮的SOA安全性都源于实现了使用来自认证机构的私钥/公钥进行身份验证的加密 消息传递。XML加密允许web服务用户发送保留XML格式的加密SOAP消息。因此，系统实现了安全性，但却仍然基于标准。数字签名是加密模型的一种变 体，它使得web服务的用户可以创建一个惟一确认的数字“签名”，其用途有二：验证用户身份和确保消息数据的完整性。

　　最后，为了跟踪SOA的使用，有必要采用可以保存所有SOAP消息请求和响应的动态审计日志的SOA安全性解决方案。审计日志对于在SOA中研究安全性问题和诊断安全性漏洞，以及实现管理规章服从性，都是必需的。

面向服务的 体系结构（SOA）表示您可以如何使用 Web 服务的大图景。Web 服务规范定义了实现服务以及与它们的交互所需要的细节。然而，面向服务的体系结构（SOA）是一种用于构建分布式系统的方法，采用 SOA 这种方法构建的分布式应用程序可以将功能作为服务交付给终端用户，也可以构建其他的服务。面向服务的体系结构（SOA）可以基于 Web 服务，但是它可能改为使用其他的技术来代替。在使用面向服务的体系结构（SOA）设计分布式应用程序时，您可以将 Web 服务的使用从简单的客户端-服务器模型扩展成任意复杂的系统。

因而，单个的软件资产成为开发其他应用程序的基本构件。您可以通过与新的代码 和遗留代码一起使用的共同交互方式来减少系统的复杂性（CBDi 的 Lawrence Wilkes 开玩笑说，面向服务的体系结构（SOA）可以代表“节省我们的资产（Save Our Assets）”）。有一种标准的方法可以用于表示这些软件资产和与它们交互；现在人们关注的重点已经转移到基于这些构件的应用程序装配上来了。

虽 然在这里讨论的是用于业务应用程序的面向服务的体系结构（SOA），但是面向服务的体系结构（SOA）同样也可以用于其他的分布式系统，比如网格计算和高 级 Web 服务规范（例如，Web 服务分布式管理（WS-DistributedManagement）、Web 服务信任（WS-Trust）以及 UDDI）。

什么是服务？

在 面向服务的体系结构（SOA）中，服务（service）是封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致 的状态向另一个状态的转变。用于实现特定服务的流程并不重要，只要它响应您的命令并为您的请求提供高质量的服务就可以了。

通过定义的通信协 议，可以调用服务来强调互操作性和位置透明性。一个服务表现为一个软件组件，因为从服务请求者的角度来看，它看起来就像是一个自包含的函数。然而，实际 上，服务的实现可能包括在一个企业内部的不同计算机上或者许多业务合作伙伴拥有的计算机上执行的很多步骤。就封装的软件而言，服务可能是一个组件，也可能 不是一个组件。如同类对象，请求者应用程序能够将服务看作是一个整体。

Web 服务是以使用 SOAP 消息（它是用像 HTTP 这样的标准协议上的 WSDL 来描述的）的调用为基础的。使用 Web 服务的最佳实践就是与外部的业务伙伴通信。

松耦合

服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务请求者往往通过消息调用操作——请求消息和响应——而不是通过使用 API 和文件格式。

这 个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码（例如， COBOL）的实现完全用基于 Java 语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的，只要新代码支持相同的消息模式。

明确定义的接口

服务交互必须是明确定义的。Web 服务描述语言（Web services Description Language，WSDL）是受到广泛支持的方法，用于描述服务请求者所要求的绑定到服务提供者的细节。服务描述的重点在于与下面几部分交互所用的操作：

服务
调用操作的消息
构造这种消息的细节
关于向何处发送用于构造这种消息的处理细节的消息的信息
WSDL 不包括服务实现的任何技术细节。服务请求者不知道也不关心服务究竟是由 Java 代码、C#、COBOL，还是由某种其他的程序设计语言编写的。它可以描述使用 HTTP 的 SOAP 调用。由于它的扩展机制，它也可以定义其他类型的交互，比如通过 JMS 提交的 XML 内容、直接方法调用、由管理遗留代码的适配器处理的调用（CICS），等等。

WSDL 的通用定义允许开发工具创建各种各样类型的交互的通过接口，同时隐藏它是如何由应用程序代码调用服务的细节。例如，如果服务是以多种交互类型公开的， Web 服务调用框架（Web Services Invocation Framework，WSIF）通过允许运行时决定调用高质量服务的最优方法来使用这种能力。

无状态的服务设计

服 务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时，它们最好 定义成通用业务流程、函数和数据模型，而不是实现构件（比如会话密钥）。当然，请求者应用程序需要服务调用之间的持久状态，但是这不应该与服务提供者分 开。

这里有一个定义会话的错误方法的示例：

Requester: “What is Bruce’s checking account balance?"
Provider: “$x"
Requester: “And what is his credit limit?"
Provider: “$y"
 

提供者被要求记住请求之间 Bruce 的帐号，这就在服务实现中引入了复杂性。无状态的服务设计将重新定义会话，如下所示：

Requester: “What is Bruce’s checking account balance?"
Provider: “$x"
Requester: “What is Bruce’s credit limit?"
Provider: “$y"
 

服务粒度

操 作的粒度是一项重要的设计要点。对于外部的消耗推荐使用粗粒度的接口，而细粒度的接口可能用于企业内部。粗粒度接口可能是特定服务的完整处理，例如 SubmitPurchaseOrder，在这里消息包括定义订购单所需的所有业务信息。细粒度接口可能具有用于以下方法的不同操作： CreateNewPurchaseOrder、SetShippingAddress、AddItem，等等。

虽然细粒度的接口为请 求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗粒度接口保证服务 请求者将以一致的方式使用服务。面向服务的体系结构（SOA）不要求使用粗粒度接口，但是推荐使用它们作为外部集成的最佳实践。服务编排可以用来创建运行 由细粒度操作组成的业务流程的粗粒度接口。

服务质量需要考虑的问题

面 向服务的体系结构（SOA）设计将跨越计算机系统，并且还可能跨越企业边界。您不得不考虑在使用 Internet 时安全性功能和需求以及如何链接伙伴的安全域。Internet 协议并不是为可靠性（有保证的提交和提交的顺序）而设计，但是您不得不确保消息被提交并被处理一次。当这不可能时，请求者必须知道请求并没有被处理。

例如，您可能需要考虑您所部署服务的度量、可靠性以及响应时间，以便确保它们在承诺的范围之内。当您设计使用来自其他业务伙伴的服务的系统时，您就不得不考虑面向服务的管理来以协作方式管理伙伴之间的服务。

　　面向服务的 架构是一种IT策略，它将企业应用程序中包含的分散功能组织为可互操作的基于标准的服务，这些服务可按照业务需求快速组合和重用。只有平衡了企业的长期目 标与短期需求，SOA的益处才会显现出来。通过在开始采用SOA时就指定一组组织、资金、操作、设计和交付准则，就可保持这一平衡。但“大爆炸”式的方法 是不可取的，应按照循序渐进的学习曲线，选择一种往复渐进的方式来部署架构更改，这非常重要。大体而言，SOA路线图就提供了这样一种往复渐进的方式，使 您随着进展得出(重新得出)您的企业的独有规划。

您的SOA路线图应包含3个关键特征:

　　成熟:SOA路线图应该是不 断融入经验和教训的“活动文档”。SOA路线图成熟时，您的SOA行动也就以一种可控的方式达到了一个更为精妙的级别。SOA路线图的创建应该从评估企业 当前在SOA方面的能力和要求开始。此过程可使用 BEA的在线自我评估工具 做为起点。

　　作用域:完整的SOA路线图应包含6个域(如 图1所示)。这6个域之间有明确的界限，但是仍相互关联、相互依赖。各个域的执行情况是企业级SOA行动成功的基石。SOA路线图应清晰地定义SOA行动 的边界，并确定一个实现SOA目标的明晰、灵活的时限。这些目标应该被分散到多个易于管理的阶段中，随后便可以以一种往复渐进的方式实现。

　　质量:通过在各里程碑处使用一个“学习与调整”的过程，同时采用往复渐进的方式，您的路线图将在整个SOA行动中保持相关性。为确保SOA路线图的质量，应在所有涉众之间进行沟通及确认，并向各方征求反馈意见。

　　图1. BEA域模型

构建SOA路线图的步骤

　　SOA路线图的开发共分4个阶段:SOA规划、SOA成熟度评估、SOA前景展望和SOA路线图定义。

SOA规划

　　这一阶段组织并定义SOA行动。涉众通过通信和简报等方式参与此过程，并设置一致通过的优先级和参数。由于此阶段牵涉到整个企业的员工，因此清晰、充分的沟通非常重要。在此阶段中，要完成的任务包括:

• 　　定义SOA的作用域。
• 　　确定与其他IT行动的边界并建立合作。
• 　　适当地展示SOA的业务论证。
• 　　展示现有业务行动与未来业务行动的衔接关系。

SOA成熟度评估

　 　在SOA成熟度评估阶段，要为当前所处状态建立一个度量标准。此时将定义当前已经实现、可作为SOA起点的服务和功能，并确定出可作为基础项目的项目。 团队应通过一系列访问调查和问卷调查查看各域——分析、制定基准并验证各域的现状。使用BEA的域模型组织检查如下各方面:

• 　　业务策略与过程:对业务策略与过程进行自顶而下的查看。
• 　　架构:评审当前架构、策略和标准。
• 　　成本与收益:概述现有成本构成与收益情况。
• 　　构造块:对现有服务、过程、工具和技术进行分析。
• 　　项目与应用:评审现有系统以及未完成的和已规划好的项目。
• 　　组织与管理:对现有管理结构和策略进行分析。

SOA前景展望

　　在这一阶段中，团队通过专题研讨会来确定并定义要求的“预期”状态，并确保举办整个企业范围内的联合讨论。

• 　　业务策略与过程:SOA前景展望与业务策略与过程的关联。
• 　　架构:导向原则、需求、策略、标准和参考架构。
• 　　成本与收益:指标和测量要求。
• 　　构造块:共享的服务基础架构需求及标准化的工具。
• 　　项目与应用:对项目与应用的SOA映射。
• 　　组织与管理:管理并遵循结构与策略。

SOA路线图定义

　　从这一阶段起，着手定义SOA路线图。应该根据前三个阶段所收集的信息，对企业的SOA目标和适当的时限进行彻底的差距分析(gap analysis)。近期事件要详细，而较远的事件要灵活——以便在前进中融入所得到的经验教训。

• 　　业务策略与过程:按业务价值排列机会。
• 　　架构:近期、中期、长期参考架构路线图。
• 　　成本与收益:未来指标、成本构成及收益情况的路线图。
• 　　构造块:将共享服务战略和标准化进程列入优先地位。
• 　　项目与应用:项目与应用的影响。
• 　　组织与管理:提出的管理结构与策略。

　　SOA路线图应该是不断融入经验和教训的“活动文档”。SOA路线图成熟时，您的SOA行动也就以一种可控的方式达到了一个更为精妙的级别(如图2所示)。

　　图2. SOA“学习与调整”路线图

结束语

　　我希望通过本文使您在脑海中形成一个创建自己的SOA路线图的框架，文中还说明了“为什么路线图对SOA行动如此重要?”。路线图就是说明开发内容、开发时间、部署所开发内容的一份指南。对于SOA的顺利部署而言，路线图是最为强大的工具。

      传统的Web（HTML/HTTP）技术有效的解决了人与信息系统的交互和沟通问题，极大的促进了B2C模式的发展。WEB服务(XML/SOAP/WSDL）技术则是要有效的解决信息系统之间的交互和沟通问题，促进B2B/EAI/CB2C的发展。SOA（面向服务的体系)则是采用面向服务的商业建模技术和WEB服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。WEB服务和SOA的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。

 　 对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费或者客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用。NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。

一、SOA具有的特性

　　SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL， Web Services DesCRiption Language）是用于描述服务的标准语言。

　　SOA 服务用消息进行通信，该消息通常使用XML Schema来定义（也叫做XSD， XML Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。

　　在一个企业内部，SOA服务通过一个扮演目录列表（DIrECtory liSTing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， UniverSAl Description， Definition， and Integration）是服务登记的标准。

　　每项SOA服务都有一个与之相关的服务品质（QOS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。

二、SOA三大基本特征

      1 独立的功能实体

      在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。

      SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

      2 大数据量低频率访问

      对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客 户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在 Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。

      3 基于文本的消息传递

      由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。

      此外，对于一个服务来说，Internet与局域网最大的一个区别就是在Internet上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。

三、面向服务架构（SOA）的原则

      SOA的强大和灵活性将给企业带来巨大的好处。如果某组织将其IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值， 那么，这些服务的顾客（可能在公司内部，也可能是公司的某个业务伙伴）就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现 并绑定可用的服务，那么在这些服务背后的IT系统能够提供更大的灵活性。
但是，要得到种强大和灵活性，需要有一种实现架构的新方法，这是一项艰巨的任务。企业架构设计师必须要变成“面向服务的架构设计师”，不仅要理解SOA，还要理解SOA的实践。在架构实践和最后得到的架构结果之间的区别非常微妙，也非常关键。本文将讨论SOA的实践，即：面向架构的设计师在构建SOA时必须要做的事情。

      SOA的原则

      SOA是一种企业架构，因此，它是从企业的需求开始的。但是，SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更 快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个业务敏捷的架构意味着创建这样一个IT架构，它可以满足当前还未知 的业务需求。

      要满足这种业务敏捷性，SOA的实践必须遵循以下原则：

      * 业务驱动服务，服务驱动技术

      从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。

      * 业务敏捷是基本的业务需求

      SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。

      * 一个成功的SOA总在变化之中

      SOA工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。 对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。如下文所写的，SOA的基础还是一些类似的架构准则。

      SOA基础

      在IT行业有两个越来越普遍的发展方向，一个是架构方面的，一个是方法学方面的，面向服务的架构设计师可以从中有所收获。第一个就是MDA（模型驱动架构），由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML（也是由OMG提出）的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和Use Cases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。

      MDA的核心就在于在设计阶段系统就已经完全描述，这样，在创建系统的时候，几乎就没有错误解释的可能，模型也就可以直接生成代码。但MDA有一些局限 性：首先，MDA假设在创建模型之前，业务需求已经全部描述，而这一点，在当前典型的动态业务环境中几乎是不可能的。第二，MDA没有一个反馈机制。如果 开发人员对模型有需要改动的地方，并没有提供给他们这么一个途径。

      SOA的另一个基础是敏捷方法（AM），其中非常有名的方法是极限编程（XP）。象XP这样的AM提供了在需求未知或者多变的环境中创建软件系统的过程。XP要求在开发团队中 要有一个用户代表，他帮助书写测试来指导开发人员的日常工作。开发团队中的所有成员都参与到设计之中，并且设计要尽量小并且非形式化。AM的目标是仅仅创 建用户想要的，而不是在一些形式化模型上耗费工作量。AM的核心思想就在于其敏捷性－处理需求变更的敏捷性。AM的主要弱点是其规模上的限制，例如，XP 在一个小团队和中型项目中效果不错，但是当项目规模增大时，如果没有一个一致的清晰的计划，项目成员很难把握项目中的方方面面。

      从表面看来，MDA和AM似乎是相对立的－MDA假定需求是固定的，而AM恰恰相反。MDA的中心是形式化的模型，而AM恰恰要避开它们。但是，我们还是决定冒险把这些不同方法中的一些元素提取出来，放入到一个一致的架构实践中。

      在SOA中有三个抽象层次，按照SOA的第一条准则：业务驱动服务、服务驱动技术。AM将业务模型直接和实践连接起来，表现在平台相关的模型之中。MDA 并没有把业务模型和平台无关模型分开来，而是把平台无关模型做为起点。SOA必须连接这些模型，或者说抽象层次，得到单一的架构方法。我们将从五个视图的架构实现方法来实现这个连接。

      SOA的五视图实现方法

      企业架构设计师发现他们的职业非常有竞争力并且值得骄傲，因为他们要从很多方面来通盘考虑IT系统。Kruchten（RUP的开发负责人）将这些方面提取出来，在应用到SOA时，我们称为五视图实现方法（five-view approach）。

      四个方框表示对一个架构的不同审视方法，分别代表不同的涉众（stakeholder）。弟五个视图，use-cASe视图涵盖了其它视图，在架构中扮演的是一个特殊的角色。部署视图将软件映射到底层平台和相关硬件上，是系统部署人员对架构的视图；实现视图描述了软件代码的组织，是从开发人员角度出发的视图；业务分析人员则利用过程视图进行工作，它描述的是软件系统的运行时特性。最后，逻辑视图表示的是用户的功能需求。在SOA中，面向服务的架构必须能够以use-case视图中的用例将用户连接到服务，将服务连接到底层的技术。

      为了表示面向对象的 架构是如何工作在这些视图之上，让我们将他们置于SOA元模型的上下文之中。SOA中两个领域存在重叠：由业务模型和服务模型表示的业务领域和由服务模型 及平台相关模型表示的技术领域（两个领域共享服务模型）。业务用户通过逻辑视图和过程视图处理粗粒度的业务服务，根据变化的业务需求，按照需要将它们安排 在过程之中。另一方面，技术专家的工作是创建并维护服务和地层技术之间的抽象层。表示这些服务的中间模型，起到的是轴心的作用，业务以它为中心进行。

      SOA元模型从MDA中继承平台无关模型和平台相关模型，但是添加了AM和用户交互以及敏捷的反馈这两部分，后者通过椭圆之间的双向箭头来表现。类似地，元模型通过引入由中心的服务模型提供的中间层抽象解决了AM在伸缩性方面的问题。这样，服务模型中的任何需求的变化，都会反映到用户每天的业务处理中。同样，由于底层技术是模型驱动的，技术专家也可以根据这些变化的需求迅速而有效地作出应变。

      SOA实践和过去解决企业架构传统方式的不同之处就在于其对敏捷性的支持。如前所说，SOA的第三条原则就在于它总在变化之中。这种恒在的变化性环境是SOA实践的基石。如图所示，涉众（stakeholders，译者注：RUP中也有这个词，表示软件开发中涉及到的各种角色如：用户、设计人员、开发人员乃至测试人员等等。）在一个必需的基础上影响到整个架构的变化。在当技术专家在每天的日常工作中不断对变化的业务需求作出响应的这种情况下，设计阶段和运行阶段之间的界限变得模糊起来，很难清晰地分离这两个阶段。

      剩下的部分

      我们已经为面向服务的架构提供了一个高层次的框架，其中MDA和AM的元素帮助工具的使用者来创建和维护SOA。但是，SOA中还缺少一些内容－那就是软件开发商和专业的服务组织必需提供的。理想情况下，开发商必需提供面向服务的业务流程、工作流以 及服务的协调工具和服务；另外，能够以一种敏捷的、平台无关的方式充分反映业务服务的建模工具也是必须的；技术专家必须配备可以从模型中自动生成代码，并 在代码变化时更新模型的工具，最后，开发商必须提供支持SOA的软件，帮助面向服务的架构设计师以一种可信并且可伸缩的方式创建位于服务和底层技术之间的 抽象层次。幸运的是，这方面的产品即将上市。

      另外，最重要的就是贯穿本文的自顶而下的SOA实现方法了。今天关于Web services的大部分思考都是自底而上的：“这是如何创建Web services的方法，现在，我们来使用它们集成吧”，对Web services技术的这种方法是伟大的第一步，因为它可以惊人地降低集成的开销，这是现在的技术管理人员最乐意见到的了。但当经济进一步发展，IT走出 低谷，企业会寻求IT的帮助来提高组织战略意义上的核心价值。使用面向服务的架构，IT可以提供给企业实现业务敏捷性的这样一个框架。

四、为什么选择面向服务架构（SOA）？

　 　不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构 （application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（orGAnic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。

　　如图1的例子所示，一个使用SOA的企业，可以使用一组现有的应用来创建一个供应链复合应用（supply chain composite application），这些现有的应用通过标准接口来提供功能。

　　Figure 1. Supply chain application. Click on thumbnail to view full-sized image.

　　服务架构

　　为了实现SOA，企业需要一个服务架构，图2显示了一个例子：

　　Figure 2. A sample service architecture. Click on thumbnail to view full-sized image.

　 　在图2中， 服务消费者（service consumer）可以通过发送消息来调用服务。这些消息由一个服务总线（service bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎（business rules engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（BIlling），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。

五、面向服务架构（SOA）基础结构

　　要运行，管理SOA应用程序，企业需要SOA基础，这是SOA平台的一个部分。SOA基础必须支持所有的相关标准，和需要的运行时容器。图3所示的是一个典型的SOA基础结构。接下来的章节将逐一讨论该结构的每个部分。

　　Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.

　　SOAP， WSDL， UDDI

　 　WSDL，UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服 务提供者之间传送消息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表（registry） 查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。

　　WS-I Basic Profile

　　WS-I Basic Profile，由Web服务互用性组织（Web Services Interoperability Organization）提供，是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程序来测试服务在不同平台和技术上的互用性。

　　J2EE 和 .Net

　　尽管J2EE和。NET平台是开发SOA应用程序常用的平台，但SOA不仅限于此。像J2EE这类平台，不仅为开发者自然而然地参与到SOA中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。新的规范，例如 JAXB（Java API for XML Binding），用于将XML文档定位到Java类；JAXR（Java API for XML Registry）用来规范对UDDI注册表（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用来调用远程服务，这使得开发和部署可移植于标准J2EE容器的Web服务变得容易，与此同时，实现了跨平台（如。NET） 的服务互用。

　　服务品质

　　在企业中，关键任务系统（MISsion-critical system，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。比如，电话系统对于一个电话 促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。）用来解决高级需求，例如安全性，可靠性，事物。当一个企业开始采用服务架构作为工具来进 行开发和部署应用的时候，基本的Web服务规范，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。正如前面所提到的，这些需求也称作服务品质 （QoS，quality of services）。与QoS相关的众多规范已经由一些标准化组织（standaRDSBOdies）提出，像W3C（World WIDE Web Consortium）和OASIS（the Organization for the Advancement of Structured InfORMation Standards）。下面的部分将会讨论一些QoS服务和相关标准。

　　安全

　 　Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换， 消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准，例如，SAML（as Security Assertion Markup Language）来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定。

      可靠

　 　在典型的SOA 环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”（ once-and-only-once delivery），“最多传送一次”（ at-most-once delivery），“重复消息过滤”（duplicate message elimination），“保证消息传送”（guaranteed message delivery）等特性消息的发送和确认，在关键任务系统（mission-critical systems）中变得十分重要。WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标准。这些标准现在都由OASIS负责。

　　策略

　 　服务提供者有时候会要求服务消费者与某种策略通信。比如，服务提供商可能会要求消费者提供Kerberos安全标示，才能取得某项服务。这些要求被定义 为策略断言（policy assertions）。一项策略可能会包含多个断言。WS-Policy用来标准化服务消费者和服务提供者之间的策略通信。

　　控制

　　当企业着手于服务架构时，服务可以用来整合数据仓库（silos of data），应用程序，以及组件。整合应用意味着例如异步通信，并行处理，数据转换，以及校正等进程请求必须被标准化。在SOA中，进程是使用一组离散的 服务创建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。WSBPEL目前也由OASIS负责。

　　管理

　　随着企业服务的增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要。WSDM（Web Services for Distributed Management）规定了任何根据WSDM实现的服务都可以由一个WSDM适应（WSDM-compliant）的管理方案来管理。

　　其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-COOrdination 和 WS-Transaction 標準中描述， 這些都是OASIS 的工作。

六、SOA 不是Web服务

　 　在理解SOA和Web服务的关系上，经常发生混淆。根据2003年4月的Gartner报道，Yefim V. Natis就这个问题是这样解释的：“Web服务是技术规范，而SOA是设计原则。特别是Web服务中的WSDL，是一个SOA配套的接口定义标准：这是 Web服务和SOA的根本联系。”从本质上来说，SOA是一种架构模式，而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。用 Web服务来实现SOA的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软件商支持越来越多的Web服务规范，你会取得更好的通用性。

七、面向服务架构（SOA）的优势

　 　SOA的概念并非什么新东西，SOA不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现SOA的平台或应用程序。SOA伴随着无处不在的标 准，为企业的现有资产或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创建应用；SOA能够使客户或服务消费者免予服务实现的改变所带来的 影响；SOA能够升级单个服务或服务消费者而无需重写整个应用，也无需保留已经不再适用于新需求的现有系统。总而言之，SOA以借助现有的应用来组合产生 新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程。

八、采用服务驱动型方法的企业体验着以下业务和 IT 好处 

      面向服务架构的业务好处

      效率： 将业务流程从 " 烟囱 " 状的、重复的流程向维护成本较低的高度利用、共享服务应用转变。
      响应： 迅速适应和传送关键业务服务来满足市场需求，为客户、雇员和合作伙伴更高水准的服务。
      适应性： 更高效地转入转出让整个业务变得复杂性和难度更小，达到节约时间和资金的目的。

      面向服务架构的 IT 好处

      复杂性降低： 基于标准的兼容性，与点到点的集成相比降低了复杂性。
      重用增加： 通过重用以前开发和部署的共享服务，实现了更有效的应用程序 / 项目开发和交付。
      遗留集成： 用作可重用服务的遗留应用程序降低了维护和集成的成本。
      如今的服务驱动型企业都在体验着开发的高效率，服务的高可靠性和服务的高质量，以最大限度获得业务机会所带来的这些好处。

九、SOA在国际市场上反响强烈

      自2004年初业界推出SOA后，Bea、IBM、ORACLE、微软等业界巨头纷纷发布自己的SOA战略，建议用户在进行企业IT建设时考虑SOA。

      ZapThink调研公司在最近发表的一份报告中预测，到2006年，基于SOA架构(面向服务的架构)的中间件产品将成为网络化商业系统的主要设计思路，其中70％的商业企业公司将使用SOA架构。

      按照Gartner的预测，到2008年，SOA将成为占有绝对优势的软件工程实践方法，它将结束传统的整体软件体系架构长达40年的统治地位。届时，将有60％的商业公司在进行商业IT建设时会转向SOA。

      IDC预测到 2007年，包括软件、服务和硬件在内的SOA市场将达到210亿美元，其中商业企业方面的市场将达到120亿美元。

      综上所述SOA已经成为大势所趋，有着广阔的市场空间和巨大的发展潜力；而在商业企业中的应用，将成为SOA未来发展的一大亮点。

      SOA已经引起国内商业企业的重视

      国内基于SOA架构Web服务目前还是集中在一些企业内部，而国内一些有影响的行业用户正在搭建其核心业务系统，比如商业领域的流通行业和销售行业的大集 中正在起步。因此当商业企业需要更好地服务客户，需要更好地与上、下游合作伙伴协同工作，并且自己内部的核心业务之间也需要协同工作时，基于SOA架构中 间件产品就会为这类新的业务应用提供理想的底座，这种新的应用被称作面向服务的业务应用。

      现在，很多商业企业都准备在2006年内开始规划使用这些基于SOA架构的应用，可想而知，这些SOA架构的中间件产品将在两年内迅速发展，并在五年内在整个IT行业内获得广泛应用。

      商业企业信息化存在的问题

      商业企业信息系统多数处于封闭运行的状态，企业之间、企业与上游供应商、下游消费者之间信息不对称。商业企业之间无法形成协同效应。信息系统即无法满足消 费者的综合需求也无法达到企业间的商务协同自动化和智能化的需求。信息化的经济效益难以有效发挥。同时信息化标准不健全，如电子交换接口标准、业务流程协 同标准；流通中的票证、单据格式标准；电子数据交换所必须的结构化数据标准等。

     采用传统的系统架构技术和传统的EAI和B2Bi技术则存在系统封闭、厂商依赖性强、耦合度高、重用性差，扩展性差、无法和上下游企业的系统建立统一的接 口等问题。而采用SOA 技术则可以有效解决上述问题，由于SOA基于HTTP/SOAP/WSDL等开放式技术，对于特定厂商产品依赖性小；系统开放、互操作性强，可以建立统一 的WEB服务用于和不同的上下游企业信息系统实现供应链协同。由于SOA的松耦合特性、比较符合集团和各下属机构的商业关系，业务流程整合和项目协调的阻 力会有效降低。

      SOA以服务为基本单元，更加贴近于企业的商业活动，业务梳理和建模的复杂度会有效降低，重用性也会有效提高。另外采用SOA，企业IT系统所提供的服务 会更容易扩展、组合和变更，符合该集团目前业务发展变化较快的特点，可以有效的降低该集团IT系统的长期拥有总体成本。我们将该集团公司作为一个试点，推 进SOA技术的运用，来有效解决上述问题。

      “协同商务”的新经济时代即将到来

      采用SOA技术最终将使得各个商业企业之间、各个关联的经济实体之间实现高效实时的联接，使得整个产业链实现自动化的协同商务，将会有力的提高商业企业的 应变能力，转变现有的商业运作模式，转变经济增长的方式。SOA技术将促进信息系统在商业企业贸易活动中的全面渗入和发展，对于简单的贸易活动，将会由信 息系统自动化实现；对于复杂的贸易活动，信息系统将会为企业管理人员提供足够的决策信息并可以高效的执行决策。SOA技术的应用将会全面提高商务的自动 化、智能化和实时化水平。

      采用SOA技术实现协同商务可以提高城市范围内商流、物流、资金流和信息流的运行效率，扩大北京市商业企业整体规模效益，加强商业企业的整体对外竞争力， 拉动经济增长，降低企业运营成本，推动城市流通信息技术创新体系的建立，提高北京市流通现代化水平，促进城市管理现代化和城市社会经济信息化的进程。

      采用SOA技术可以将将物流企业、物业企业、商业企业、消费者整体整合在一起，对供应链关联企业、物流企业以及网上支付体系、安全认证体系等环境建设具有明显的带动作用，有利于促进支撑环境协同发展。

      促进商业企业信息化标准的制定，完善政府职能

      采用SOA技术为信息系统的沟通提供了技术基础，而随着SOA在商业企业的应用，必将促进统一的商业领域电子商务行业标准的发展和制定，对促进国家商业企业信息标准体系的建立和完善具有重要支撑作用。

      SOA技术为政府对商业经济的运行状况提供了实时监测和指导的技术可能性，将从根本上改变政府对社会经济的管理方式。

      基于SOA的协同商务带来的最直接的好处就是由于贸易范围的空前扩大而产生的全球贸易活动的大幅度增加，因而提高了贸易环节中大多数角色的交易量，因此， 全球范围的经济形势将向一个良好的增长趋势发展。它还可以扩大地方商业企业整体规模效益，加强商业企业的业务整合和商业协同效应，提高商业企业的整体对外 竞争力，通过协同商务有效降低企业运营成本，推动城市流通信息技术创新体系的建立，提高地方的流通现代化水平，促进城市管理现代化和城市社会经济信息化的 进程。

      SOA在商业企业的应用可以将物流企业、物业企业、商业企业、消费者整体整合在一起，对供应链关联企业、物流企业以及网上支付体系、安全认证体系等环境建 设具有明显的带动作用，可推动信息化各环节的全面应用与发展，有利于促进产业链和支撑环境协同发展，从而也创造了更多的就业机会和社会财富。

      信息产业是知识经济的核心和主要的推动力，而企业信息化又是目前信息产业中最具前途的发展趋势，因此说企业信息化的发展，必将直接或间接地推动知识经济的 浪潮。这种知识经济有着大量的无形成本和高附加值，在东南亚金融危机的同时，高科技给美国带来的是"高增长速度、高就业率、低通货膨胀率"。这也是我国在 宣传知识经济的热潮中应注意的一个真正有价值的切入点。

      SOA技术由于其前所未有的信息系统整合与自动协同能力，成为继互联网以来又一个革命性的技术，将会把目前基于WEB/互联网的知识经济推进到一个前所未有的新阶段。

十、SOA 企业考虑事项

      服务驱动型企业在对客户、合作伙伴和雇员的高效化服务方面得到了优化 -- 并加速了业务服务响应时间。然而，成为服务驱动型企业，需要的不仅仅是产品的部署。对实现服务驱动型架构感兴趣的企业将希望能与一个有经验的 SOA 提供商合作，它提供的服务可以保护企业在业务和 IT 方面的投入，他们考虑到了以下几个方面： 

      业务战略： 组织需要明确驱动关键业务流程的业务战略，它将用于成形 SOA 的框架。一旦识别出业务问题，就可以用一种一致的、可复用的方法对其进行定义，并实现解决方案。在这个关键的基础阶段，业务通常需要与一个拥有开发 SOA 业务战略经验、并能共享横向和纵向市场最佳实践的提供商进行合作。
      体系结构： 为了解决方案快速和动态的交付，企业必须开发一种允许装配组件和服务的体系结构框架。通过与有经验的 SOA 提供商合作，企业可以获得相应的参考案例，以快速搭建一个关注复用、避免 " 烟囱 " （ stovepipe ）式应用程序和 IT 资源 " 孤岛 " 的体系结构。此外，有经验的 SOA 提供商还可以帮助企业对项目的易管理性进行设计。

      构建模块： 不管是对体系结构还是对编程模型来说， SOA 都是是思考构建软件模型的一种优秀方式。与 SOA 提供商进行合作能让组织能够识别可在 SOA 实现中使用或重用的构建模块代码、服务、应用程序和组件。与有经验的 SOA 提供商进行合作还有一个好处，企业可以获得对构造组件、企业域（ domains ）、服务和规范数据模型的参考经验。

      项目和应用程序： SOA 创造了一种在更强大、更灵活的编程模式中搭建应用程序的新方法。与 SOA 提供商合作的企业可以更好地识别将被合并到 SOA 结构体系中的现存的和正在使用的应用程序。有经验的 SOA 提供商还将引导项目基础架构的搭建，并对正在进行中的项目提供有效的管理。
成本和收益： 在一个 SOA 项目中，开发和维护成本将大大削减，。有经验的 SOA 提供商可以帮助企业构造 SOA 基金模式，并构建 " 行动案例 " ，包括评估基础构造成本和效益、实现项目的最佳投资回报（ ROI ）以及开发商务案例。

      组织和统辖： 组织需要为新的面向服务的 IT 组织识别角色和职责，并优化经验集便于以后使用。有经验的 SOA 提供商可以帮助企业实现这些目标，同时组织一个有效的设计 " 复用工厂 " （ Reuse Factory ），帮助定义统辖模式，并最终保证客户满意。

前言
    如果数据库系统（ database systems）像受人尊敬的智者讲述的条理清晰的故事，那么工作流（workflow）就像一群乳臭未干的小子在大谈各自的“哲理”。之所以这样讲，我是想指出，工作流系统 （workflow management systems）还处于技术发展曲线（ technology hype curve）上的初级阶段。在这个领域我们将面临一个激动人心的阶段。为了描述这一点，可以将工作流和关系数据库系统（RDBMS）做一个对比。当在软件开发团队中谈论RDBMS时，大部分人会有一个清晰的概念，在你和他们交流的时候，人们会通过轻微的点头表示认可或理解你所说的。可当使用工作流术语讨论工作流时，他们会摇头表示不同意，因为每个人对工作流术语都有不同的理解。
    

Figure 1: Workflow vs. RDBMS positioned in the hype-curve 

    导致形成这种状况的原因之一，是在工作流中使用了过多的概念。在这个领域中的大量规范和工具没有一个是相似的。当然，它们相互之间有重叠并且会相互参考引证。
    在介绍工作流时有一个话题必须包括，那就是工作流和业务流程管理（BPM）的关系。术语“工作流”通常描述人与计算机系统的一系列相关交互。在开发人员中，工作流经常被提及。有时，工作流的意思是指一些不同的UI界面。业务流程管理的范围比较广，相比之下工作流多半局限于技术领域。业务流程管理还从管理人员的角度涉及了非技术问题，比如分析、组织的效率。
   
    在本文中，我首先解释什么是工作流管理系统，然后介绍业务流程管理的优点。接下来描述一下为什么工作流市场乍看起来如此混乱。本文给出的主要结论是：选择工作流系统是想用工作流系统的公司，将要面对的最困难的事情。为此，本文的核心部分描述了一个流程定义（process definition）的四个层次，为你选择工作流提供一个基础。本文还用中立的语言描述了工作流和BPM的通用概念。最后，给出了一些规范和工具的指导性描述。
   
什么是工作流管理系统（WFMS）
定义:
    工作流系统是以规格化的流程描述作为输入的软件组件,它维护流程的运行状态,并在人和应用之间分派活动。
   
    为了后面的描述，我们先定义一些基本的术语：流程定义（process definition）和流程实例（process instance）. 一个流程定义是一个业务流程或过程的规格化描述。一个流程实例是流程定义的一个运行实体。都目前为止，概念还比较清晰是不是？但当再深入一步时，我们就要小心使用文字了。如何阐述流程中的步骤，现在还没有一个统一的方式。这是各种工作流规范和工具之间主要的分歧。
   
为什么应当禁止使用术语“活动（activity）”...
    流程定义通常用一些活动表述。我认为这是导致工作流领域所有混乱的主要原因。我告诉你为什么：因为术语“活动”混淆了状态（state）和动作（action）之间的差异。在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。在流程运行时，这意味着流程引擎必须等待，直到外部参与者通知工作流管理系统指定的状态完成了。比如，等待可进一步运行的认可。动作是在流程运行过程中，工作流系统为响应指定事件（event）运行的一段程序逻辑（programming logic）。当流程运行过程中指定的事件发生时，工作流系统启动并执行这些动作。比如，当状态分配给一个参与者时，发一封Email。你也能看出，状态和动作是如此不同，因此使用同样的术语去描述这些概念是一个坏习惯。我的建议是避免使用术语“活动”，使用“状态”或者“动作”代替它。
    
    工作流系统另一个重要的职责是维护每一个流程运行的上下文信息。 流程上下文变量（process context variable），或简称变量，是与流程实例相关的变量。如，休假申请的开始日期、数据库中一条记录的键值、文档管理系统中一篇文档的索引等。通常在流程定义中声明这些变量，然后在流程实例生成时，这些流程变量被实例化。所有成熟的工作流管理系统都支持定制的变量类型。
   
目标领域（Target usage）
    使用工作流管理系统的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构（heterogeneous）应用和数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订单、支付、资源计划等等。让我们称这些系统为专门应用（ dedicated applications）。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流系统的第一种使用方式就是：结合所有的专门应用，使用工作流系统构建一个EAI平台。
   
    工作流系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。对于专注于ISO 或者CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化（如使用基于Web的应用）。
   
    工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用（不重复发明轮子）和应用软件的可维护性。
   
The case for workflow
    对于引入工作流的组织，能够在软件开发和业务两个层次受益。
   
方便开发
    工作流管理系统能够简化企业级软件开发甚至维护。
   
    降低开发风险 - 通过使用状态和动作这样的术语，业务分析师和开发人员使用同一种语言交谈。这样开发人员就不必将用户需求转化成软件设计了。
    实现的集中统一 -业务流程经常变化，使用工作流系统的最大好处是：业务流程的实现代码，不再是散落在各种各样的系统中 。
    加快应用开发 - 你的软件不用再关注流程的参与者，开发起来更快，代码更容易维护。
    业务流程管理 (BPM)
    在自动化业务流程之前，分析并将它们规格化是一件艰苦但会有很好回报的工作。e-workflow.org对于分析流程能够带了的益处有不错的阐述：
   
    提高效率 - 许多流程在自动化过程中会去除一些不必要的步骤
    较好的流程控制 - 通过标准的工作方法和跟踪审计，提高了业务流程的管理
    改进客户服务 - 因为流程的一致性，提高了对客户响应的可预见性
    灵活 - 跨越流程的软件控制，使流程可以按照业务的需要重新设计。
    业务流程改进 - 对流程的关注，使它们趋向于流畅和简单
    我认为他们还遗漏了一个使用工作流系统最重要的因数：提高对迭代开发的支持。如果软件中业务流程部分不容易更改，组织就会花很大的精力在开发前的业务流程分析中，希望一次成功。但可悲的是，在任何软件项目开发中，这都很少能实现。工作流系统使得新业务流程很容易部署，业务流程相关的软件可以一种迭代的方式开发，因此使用工作流系统使开发更有效、风险更低。
   
缺失的一环（Missing link）
    我确实认为工作流系统是企业应用开发中缺失的一环。将企业业务流程逻辑在企业级软件中实现的缺省方式是分散的。这意味着业务流程逻辑散布在各种系统中，如 EJB、数据库触发器、消息代理等等。这样得到的软件难于维护，结果，企业只能将改变业务流程软件作为最后的选择。他们经常能够做的是，改变流程以适应软件。上述问题也适用于采用大型外部ERP软件包的企业。进一步，假设我们认识到这个问题，并打算将一个流程相关的代码都集中起来。对于一个流程来说这很不错，但当你要实现多个流程时，你会看到管理状态和流程变量的代码被到处复制。最后，我们会整理这些代码放到一个集中的库中。好，...这就是一个工作流管理系统了，不用费心自己来实现，你可以从本文后面的列表中选择一个。 

    一个工作流管理系统以流程定义作为输入。在这里，可以将流程定义看作UML活动图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报价、...之后，工作流系统负责维护这些流程定义的执行状态和上下文。为此，需要通知工作流系统状态的变化。运行流程的状态变化可以记录下来，以备监控管理。
    
  

Figure 2: Interfaces of a WFMS 

    定义   工作流系统的定义接口使流程开发人员能够部署流程定义。注意，这里的“流程开发人员”可以是业务分析师和软件开发人员的组合。 圈套（Pitfall）
    许多工作流管理系统的开发商想使你相信，通过使用他们的图形化流程开发工具，只要业务分析师就可以生成流程定义。这种幻想源于“编程很难”这样的事实。开发商的销售人员喜欢说“看，你不用写一行代码”。不用写代码是好事，可大部分开发商在这点上走的太远，忽略了在某些场合提供一种将代码集成到流程定义中的机制是很适合的。在将工作流系统作为EAI平台时，必须在流程中集成代码。开发流程定义需要业务分析师和软件开发人员的合作。一个好的图形流程设计工具应该能够支持这种合作。   
    
    执行   执行接口使用户和系统可以操作流程实例。流程实例是流程定义的执行。流程定义的控制流通过状态机描述。执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态结束了。
    应用   应用接口代表了由工作流系统发起的工作流系统和外部系统之间的交互。当一个用户或系统操作一个流程实例的运行时，会生成一些事件（如一个迁移的执行）。流程定义中可以指定一段响应一个事件的可执行代码逻辑，这段代码和组织内外部的其他系统打交道。
    监控   管理人员通过监控接口获得流程运行的确切数据。有时，运行日志也可用于审计。
    这些是WfMC参考模型（reference model of the WfMC）中定义的五个接口中的四个。

流程定义的四个层次
    在下面这部分，我尝试回答这样的问题“什么是流程定义包括的内容？”。这是从各种规范和工具所使用模型的原则和概念中总结得来的，反映了大部分模型中通用的基本思想。流程定义的内容可以分为四个不同的层次：状态（state）、上下文（context）、程序逻辑（programming logic）和用户界面（UI）。

状态层
    所有状态和控制流的表述，都属于业务流程的状态层。标准编程语言中的控制流来源于Von Neuman体系。控制流定义了必须被执行的指令的顺序，控制流由我们书写的命令、if语句、循环语句等确定。在业务流程中的控制流基本与此一致。但在业务流程中不是使用命令而是使用状态作为基本元素。
   
    在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。状态的意思就像“现在X系统或某某人必须作某些事，在此等待直到参与者通知这些任务已完成”。状态定义了一种对外部提供结果的依赖。状态典型的例子是批准步骤（step）。
   
    流程定义中的状态也指定了执行依赖于哪个参与者。在活动图中，泳道（swimlanes）的标注代表这些参与者的名字。工作流系统使用这些信息构建任务列表，这是一般工作流系统都有的功能。如前所述，参与者可以是人也可以是系统。对于需要人参与的状态，工作流系统必须在运行时计算出具体的个人。这样的计算使工作流系统必须依赖于组织结构信息。关于这方面的一篇非常有趣的文章是在further reading section提到的“工作流应用中的组织管理”（ Organizational Management in Workflow Applications）。
   
    流程定义的控制流包含一组状态和它们之间的关系。状态之间的逻辑关系描述了哪些执行路径可以同时执行，那些不可以。同步执行路径用分叉（forks）和联合（joins）建模，异步执行路径用判断（decisions）和合并（ merges）建模。注意在大多数模型中，在每个状态之前都有一个隐式合并。
   
    UML活动图经常被用来做业务流程建模。作为一种直观和通用的表达，活动图在图形表述上有一个主要问题，就是没有区分状态和动作，它们都用活动来表示。缺少这种区分（导致状态概念的缺失）是学术派对UML活动图的主要批评。UML活动图的第二个问题是在UML2.0版中引入的。当多个迁移（transitions）到达一个活动时，以前的版本规定这是一个缺省合并（merge），在2.0版中规定这是一个需要同步的缺省联合（join）。在我看来，UML活动图的图形部分仍旧可以用来对业务流程状态层次建模，只要使用时对两条构建语义作如下的变化：
   
    在用图形表述业务流程时，只建模状态层（状态和控制流），不要包括动作。这意味着图形中的矩形都是状态而不是活动
    如果多个迁移到达一个状态，缺省定义为不需要同步的合并（merges）
    在流程运行过程中，工作流系统用一个令牌（token）作为指针跟踪流程的状态。这相当于Von Neuman体系中的程序计数器。当令牌到达一个状态时，它被分配给工作流系统等待的外部参与者。外部参与者可以是个人、组织或者计算机系统。我们定义流程运行的执行人或系统为“参与者”（actor）。只有在工作流系统将令牌分配给一个参与者时，才需要访问组织结构信息。工作流系统通过分配令牌构建任务列表。
   
上下文层
    流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。流程开发人员可以使用流程变量存储跨越流程实例整个生命周期的数据。一些工作流管理系统有固定数目的数据类型，另一些你可以定义自己的数据类型。
   
    注意变量也可以用来存放引用（ references）。一个变量可以引用如数据库中的记录、网络上的文件。什么时候使用引用，取决于使用引用数据的其他应用。
   
    和流程变量相关的另一个令人感兴趣的方面是：工作流系统如何将数据转化为信息。工作流是用于组织内部跨越各种异构系统实现任务和数据协同的。对于业务流程中人工执行的任务，工作流系统负责从其他相关系统，如SAP、数据库、CRM系统、文档管理系统收集数据。在业务流程的每一个人工步骤，只有相关联的数据项被从异构系统中收集和计算。通过这种方式，从不同系统来的数据被转换并展现为信息。
   
程序逻辑层
    如前所述，动作是在流程运行过程中，工作流系统响应指定的事件（event）执行的一段程序逻辑（programming logic）。程序逻辑可以是二进制或源代码形式的、用任何语言或脚本编写的软件。程序逻辑层是所有这些软件片断和关于在什么事件发生时调用它们的信息的组合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERP系统中拿数据和更新数据库。
   
用户界面层
    一个参与者通过向流程变量中填充数据的事件，来触发结束一个状态。比如，在请假的例子中，老板提供“同意”或“不同意”数据到流程中。某些工作流系统允许指定哪些数据可以填充到流程中，以及它们如何在流程变量中存储。通过这些信息，可以生成从用户收集信息的UI表单。基于流程定义生成用户提交表单的Web 应用例子，可以访问the jBpm online demo。

工作流全景
    可执行流程与工作流管理系统的比较（Executional processes versus a WFMS）
    当前在BPM领域中，关于可执行业务流程的规范有趋向于统一集中的趋势。 XLANG, WSFL 和BPML合并为基于交互（消息交换）的BPEL。BPEL在面向服务体系结构(SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声明。BPEL规定了一套XML语法，这套语法可以看作一种编程语言，用来描述包括对WSDL定义的服务调用的控制流。
   
    在可执行业务流程和基于状态的工作流管理系统所使用的方法中，我注意到了三点主要的区别：
   
    基于状态与面向消息：基于状态的工作流系统以状态（或者活动）概念为中心。工作流引擎维护状态并计算从一个状态到另一个状态的迁移。另一方面，像BPEL 这样的可执行流程以对输入消息响应的定义为中心。一组这些响应外加其他信息（other bells and whistles）可以看作一个业务流程。这也解释了为什么BPEL可以看作是对基于状态的工作流系统的某些方面的补充。一个响应输入消息的BPEL onMessage事件处理器，可以在工作流状态之间的迁移中执行。
    流程实例ID与消息相关处理：可执行业务流程的复杂性之一来自消息相关性的处理。流程描述的一部分必须说明BPEL引擎如何从输入消息中确定具体流程的标识。这必须基于输入消息的一个数据项。而工作流系统在每个流程实例生成同时生成了实例ID，客户端在后续调用引擎API时使用这个ID。
    工作流引擎API与抽象服务端点（endpoint）：工作流系统提供一组集中的API，客户端通过调用API完成与所有流程实例的交互。在可执行业务流程中，每个流程表现为一个服务。这意味着对于每个流程定义都有一个不同的访问点。
    学术界
    学术界对工作流的研究可以回溯到上个世纪七十年代。在当前，研究领域趋向于认为petr 网是所有流程定义语言之母。关于petri网已有大量先进的分析技术，去年在 2003 conference on Business Process Management上我有幸会晤了Petri教授。对于大部分人能够访问和理解的有关Petyri网最好的研究之一是工作流模式(workflow patterns)。工作流模式比较了大量的工作流管理系统并以petri网的术语表述了通用流程建模概念。
    开放源代码项目
    最后我们看看真实世界中的工作流管理系统。选择一个工作流管理系统是一件困难的事情，但有选择总比没有选择好。:-) 本文阐述工作流基本概念的目的之一，就是使你能够作更好的选择。但我也意识到，对于现在的软件架构师来说，选择工作流系统是一件最具挑战性的工作。
   
    下面的列表来源于三个地方：my previous article, the list of Carlos E Perez, 和 list by Topicus.
   
    jBpm - jBpm是本文作者编写的一个灵活可扩展的工作流管理系统。作为jBpm运行时server输入的业务流程使用简单强大的语言表达并打包在流程档案中。 jBmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组 J2SE组件，可以作为J2EE应用集群部署。
    OpenEbXML - OpenebXML项目致力于提供一个ebXML框架，主要支持不久将由 UN/CEFACT和OASIS发布的ebXML规范2.0版。
    Werkflow - Werkflow是一个灵活可扩展的基于流程和状态的工作流引擎。它的目标是满足可以想象的所有工作流程，从企业级的业务流程到小范围的用户交互流程。通过使用可插拔和分层结构，可以方便地容纳各种工作流语义。
    OSWorkflow - OSWorkflow最独到之处是绝对的灵活。
    wfmOpen - WfMOpen是WfMC和OMG中所谓工作流设施（workflow facility） (工作流引擎)的J2EE实现。工作流通过扩展的XPDL描述。
    OFBiz - OFBiz工作流引擎基于WfMC和OMG的规范，使用XPDL作为流程定义语言。
    ObjectWeb Bonita - Bonita是一个符合WfMC规范、灵活的协同工作流系统。对于各种动作如流程概念建模、定义、实例化、流程控制和用户交互等提供了全面的集成图形工具。 100% 基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。基于活动预测模型的第三代工作流引擎。
    Bigbross Bossa -速度非常快、轻量级的引擎，使用富有表达能力的Petri网定义工作流，不要求关系数据库，使用简单，能和Java应用集成。事实上，它是按嵌入式设计的。
    XFlow - XFlow运行于EJB和servlet容器中。
    Taverna - Taverna项目的目标是提供一种语言和软件工具，方便在eScience中使用工作流和分布计算技术。
    Enhydra Shark - Shark完全基于WfMC和OMG标准，使用 XPDL作为工作流定义语言。流程和活动的存储使用Enhydra DODS。
    PowerFolder - PowerFolder包括开发人员使用的studio，管理环境和一个运行时引擎。
    Breeze - Breeze一个轻量级、跨平台、基于组件的工作流引擎原型。
    Open Business Engine - Open Business Engine是一个开放源码的Java工作流引擎，支持WfMC规范，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE为活动的运行提供了一个可控的集中环境。OBE主要基于J2EE实现。
    OpenWFE - OpenWFE是一个开放源码的Java工作流引擎。 它包括可升级的三个组件：引擎、工作列表和Web界面。它的流程定义语言虽然使用XML格式，其灵感来源于 Scheme，一种Lisp方言。
    Freefluo - Freefluo是一个使用Web Service的工作流协同工具，可以处理WSDL的Web Service调用。支持两种XML格式的工作流语言：IBM的WSFL和XScufl。Freefluo非常灵活，它的核心是不与任何工作流语言或执行架构关联的可重用协同框架。 Freefluo包括可执行使用WSFL一个子集描述的工作流的运行库。
    ZBuilder - ZBuilder3是第二代工作流开发管理系统，也是一个开放源码产品。它为不同的工作流引擎和工作流定义了一组标准的JMX管理接口。
    Twister - Twister的目标是提供新一代、易集成、应用Java领域中最新成果、面向B2B的工作流解决方案。流程引擎基于BPEL业务流程规范和Web Service标准。
    Con:cern - con:cern工作流引擎基于扩展的案例（case）处理方法，流程由一组具有前后条件的活动组成。

商业软件提供商

工具目录
    http://dmoz.org/Computers/Software/Workflow/Products/
    A collection of links to tools for modelling business processes and workflows maintained by Bart-Jan Hommes at TU Delft, the Netherlands. 

规范
    Michael zur Muehlen作了一个所有工作流相关规范的介绍性的幻灯片，很不错。
   
    我同意John Pyke 和 Wil van der Aalst 的观点：工作流标准还处于制定阶段。现在存在大量相互丛叠的规范。
   
    在我看来，导致规范如此之多而同时每个规范的应用又很有限的原因是，在工作流最基础概念上大家达成的共识很少。工作流是最容易让你感到心烦的话题，因为工作流本身的概念会和其他相关概念和技术混淆在一起。可以举一个具体的例子，比如说工作流完全是对Web Service的补充。你可以通过暴露接口以Web Service的方式访问一个工作流管理系统，但是不能假定总是必须通过Web Service接口访问工作流系统接口。一些规范造成了这样的假设。除了Web Service，其他容易混淆的概念和技术包括：Email、流程之间的通讯、Web应用和组织结构。
   
    在工作流领域第一个致力于标准化工作的是Workflow Management Coalition (WfMC)，开始于 1993。 WfMC发布的参考模型很不错，它定义了工作流管理系统和其他相关部分之间的接口。WfMC的另一项成果是XPDL规范。 XPDL定义了描述工作流声明部分（declarative part）的XML结构。我个人认为，参考模型和XPDL是目前最好的规范。
   
    JSR 207: Java的流程定义 -是由Java Community Process (JCP) 发起，如何在J2EE应用服务器中实现业务流程自动化的标准。其基本模型是定义一个特殊类型的ejb session bean，作为一个业务流程的接口。JSR207标准化一组XML元标记（meta tags）作为JSR175元数据的一部分。JSR207 将session bean和元数据作为ejb容器的输入，然后生成绑定方法的代码，这些方法在元数据中描述。此规范还处于初级阶段，没有发布任何内容。专家小组成立于 March 2003.
    WfMCs XPDL - WfMC是由约300家成员参加的组织，基于参考模型定义了一系列的标准。参考模型用用例（use case）的形式描述了工作流系统和其他相关部分之间的关系。XPDL是WfMC制定的描述业务流程控制流（control flow ）的XML格式规范。
    ebXMLs BPSS - ebXML是协同流程的相关标准集，主要关注不同公司流程之间的通讯。可以看作EDI的继承者。 ebXML是由OASIS和UN/CEFACT联合发起。 BPSS 是ebXML的规范，其中的概念和本文阐述的很接近。
    BPMIs BPML & WSCI - (Intalio, Sun, SAP, ...)BPMI 也定义了一个规范 (BPMN) ，描述如何将“可执行”业务流程可视化的表现。
    BPEL - (Microsoft, BEA, IBM, SAP & Siebel) BPEL由一系列基于消息交换的规范（ XLANG, WSFL, BPML）产生。还有一个将此规范引入到Java的提案: BPELJ。此规范描述如何处理输入的消息，而不是对流程状态进行建模。就像本文提到的，它不是一个关于业务流程规格化定义的规范。简单的说，可以将它看作XML形式的编程语言，提供将WSDL-Services组合成控制流的能力。顾名思义，此规范重点在（也不只限于）Web Service。
    OMGs Workflow management facility - 基于WfMC规范，定义如何向CORBA转换。
    UML - UML定义了建模和设计软件系统的9类图。每类图包括可视化的表示和语义。其中活动图的目的就是要可视化的表现业务流程。注意到在一个流程定义包含四个层次的内容，我想指出的是：一个流程定义包含的内容远远多于它的可视化部分。UML只涉及了可视化部分。
    RosettaNet - RosettaNet主要定义了一组 Partner Interface Processes (PIP). 一个 PIP 描述了一个有两个交易参与者、包括消息格式的流程。
    UBL - The Universal Business Language (UBL)定义了用于不同组织间通讯的XML文档标准库。可以看作是对ebXML的补充，因为ebXML只定义了建立组织间流程的基础。此规范的竞争对手是 RosettaNet标准中的一个子集。
    结论
    我在本文中指出工作流市场还属于年轻而又混乱（young and wild）的阶段，但已经有可靠的工具存在了:
   
    到目前，像J2EE和.NET这样成熟的集成平台才可用。在这样一个平台上运行工作流管理系统才能真正发挥工作流系统的附加价值。这也是为什么只有在今天，工作流系统才被重新发现。
    在 The case for workflow一节，我们介绍了引入工作流管理系统，是如何同时在技术和业务上带来投资回报的。
    工作流在技术发展曲线的位置表明，BPM和工作流中使用的概念还需要明确。
    “开放源代码项目”和“商业软件提供商”列表中的工具，可以让你获得工作流和业务流程管理的益处。
    从以上所有这些中能得到的结论是：
   
    规范还没有成熟，没有标准被大范围采用
    对于现在想应用BPM的公司来讲，比较工作流系统是一个极其困难的挑战
    尽管标准化工作慢了一拍，可好的工作流管理系统还是有的。这对于已经在挑选工作流系统的组织来说是一个好消息。
    我希望本文能够激发你对工作流的兴趣并且能够为你进行有效的对比提供正确的背景知识。

Bugzilla： 版本 2.18 （http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.18.tar.gz）
汉化包：2.18rc3-cn-0.9 （http://heanet.dl.sourceforge.net/sourceforge/bugzilla-cn/bugzilla-2.18rc3-cn-0.9.rar）-不需要,似乎不兼容

My SQL Database： 版本 4.1.10 （http://dev.mysql.com/get/Downloads/MySQL-4.1/mysql-4.1.10-win32.zip/from/http://mysql.ihostunit.com/）

ActivePerl：版本 5.8.6.811 （http://downloads.activestate.com/ActivePerl/Windows/5.8/ActivePerl-5.8.6.811-MSWin32-x86-122208.msi）-据说这个版本有bug,但是似乎也没什么大碍.

Perl Modules：（http://landfill.bugzilla.org/ppm）

sendmail：（http://download.ebugs.org/download/bugzilla/mailer.rar）

Apache：版本 2.0.53 （http://archive.apache.org/dist/httpd/binaries/win32/apache_2.0.53-win32-x86-no_ssl.msi）

二、相关软件的安装

安装mysql。
将Mysql默认安装到C:\Mysql是一个很不错的主意，因为在Bugzilla的Checksetup.pl中默认Mysql安装在C:\mysql，如果您安装到了其他目录，那么安装时需要对该文件进行手工修改，指定Mysql的安装路径。对于Mysql的安装，一路点击下一步即可。
安装完成后，手动运行C:\mysql\bin\winmysqladmin.exe文件，它会自动将mysql数据库注册为服务并启动。此操作仅需运行一次，因为Mysql注册的服务为自动类型，所以每次计算机启动时均会自动运行。
然后，我们需要mysql中创建Bugzilla的用户以及数据库，主要三条命令为：
a、建立数据库bugs
create database bugs;

b、建立用户bugs，密码为空，对Bugs数据库具有一定权限
GRANT SELECT,INSERT,UPDATE,DELETE,INDEX,ALTER,CREATE, LOCK TABLES,DROP,REFERENCES ON bugs.* TO bugs@localhost IDENTIFIED BY '';

c、从 mysql 数据库授权表中重新装载权限。
FLUSH PRIVILEGES

执行过程如下图：（这里我们建立的数据库名为Bugs，数据库用户名为Bugs，密码为空）

1. 

注意：刚刚建立的数据库的超级用户为root，没有密码，你可以安装mysqlcc在图形界面中更改密码，也可以使用SQL语句“UPDATE user SET password = password('new_password') WHERE user = 'root';”来更改密码。

安装Activeperl。
Activeperl的安装很简单，一路点击Next即可，它会自动安装到C:\perl目录。同时在系统变量Path中增加自己的 C:\perl\bin路径信息。

Apache的配置
对于 Apache 服务器，此步骤稍微复杂一点，需要手工配置文本文件：C:\Program Files\Apache Group\Apache2\conf\httpd.conf

1、增加 cgi 和 pl 的执行，只需要在配置文件中增加如下二行
AddHandler cgi-script .cgi
AddHandler cgi-script .pl

2、增加默认文档，在文档中查找DirectoryIndex index.html index.html.var一行，在后面添加index.cgi，即更改为：DirectoryIndex index.html index.html.var index.cgi

3、增加虚拟目录映射，并设置目录权限。增加下列几行，这里默认Bugzilla文件目录位于C:\Buzilla，别名为bugzilla，注意：在配置文件中是使用“/”而不是“\”
Alias /bugzilla "D:/Bugzilla/"
<Directory "D:/Bugzilla/">
#
# Possible values for the Options directive are "None", "All",
# or any combination of:
#   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important.  Please see
# http://httpd.apache.org/docs-2.0/mod/core.html#options
# for more information.
#
    Options Indexes FollowSymLinks ExecCGI

#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
#   Options FileInfo AuthConfig Limit
#
    AllowOverride All

#
# Controls who can get stuff from this server.
#
    Order allow,deny
    Allow from all

#
# Tell Apache to use Perl to execute .cgi
#
    ScriptInterpreterSource Registry-Strict
</Directory>

AddHandler cgi-script .cgi

DirectoryIndex index.html index.html.var index.cgi

#
# The location and format of the access logfile (Common Logfile Format).
# If you do not define any access logfiles within a <VirtualHost>
# container, they will be logged here.  Contrariwise, if you *do*
# define per-<VirtualHost> access logfiles, transactions will be
# logged therein and *not* in this file.
#
#CustomLog logs/access.log common

设置完成后，重新启动 Apache 服务器设置即可生效。

Perl脚本的安装以及Bugzilla的初步配置。
Bugzilla为我们准备了一个很好的脚本文件checksetup.pl来进行配置，我们随时可以运行chekcsetup.pl文件来进行服务器配置而不会对Bugzilla系统造成任何影响。
运行该脚本的方法是，在命令行下进入Bugzilla的主目录，键入：perl checksetup.pl，运行后，该脚本会给出系统所缺的各种元素乃至获取办法。
初次运行的时候，系统首先会验证perl模块是否足够，一般会缺少比较多的perl模块。如果我们是单独下载的每个perl模块进行安装，则需要使用ppm install <perl模块名.ppd> 进行。
如果是使用本文中所提供的压缩包进行安装的，那么一切变得很简单，只需要双击运行Install.bat文件，此批处理文件会自动调用ppm安装好运行所需要的perl模块。

当插件安装完后，再次运行perl checksetup.pl，系统会生成localconfig文件，此文件是包含了Bugzilla的一些配置信息，如果您的mysql安装到C:\mysql，所创建的数据库名称为bugs 数据库用户为bugs，密码为空，那么不需要对localconfig文件进行任何修改，否则需要对localconfig的相应条目进行修改。
修改好localconfig文件，再次运行 perl checksetup.pl，如果不出意外的话，会顺利编译模板，然后建立数据库，最后提示输入超级用户信箱、用户姓名以及口令。输入后，Bugzilla 基本安装完成，可以从 web 上来进行访问了。

让Bugzilla界面运行起来！
当我们使用 web 页面浏览http://127.0.0.1/bugzilla/时，意外的发现出错了。
如果是 IIS ，可能的信息为：
CGI Error
The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:
Can't open perl script "C:\bugzilla\index.cgi": Permission denied
如果是 Apache ，可能的错误信息为标准的 500 号内部错误：
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
More information about this error may be available in the server error log.
…
Apache/2.0.48 (Win32) Server at 127.0.0.1 Port 80>

虽然提示信息不同，但是二者出错原因是类似的，对于IIS，是因为perl脚本的第一句中不支持 -wT 参数，将所有的 -wT 替换成 -w 即可
即：将 #!/usr/bin/perl –wT 替换为：将 #!/usr/bin/perl –w

对于Apache服务器，是因为Apache找不到perl文件的路径，因此将.cgi和.pl的顶部的perl路径由/use/bin/perl 替换成C:/perl/bin/perl即可。
即：将 #!/usr/bin/perl 替换为：#!C:/perl/bin/perl

作为一个通用的解决方法，可以将所有的#!/usr/bin/perl –wT和#!/usr/bin/perl –w替换成#!C:/perl/bin/perl

修改后，再次浏览http://127.0.0.1/bugzilla/，OK！我们可以看到Bugzilla的主界面了。

实现Bugzilla的Email发送功能。
因为Bugzilla更大程度是基于unix的，其发送邮件部分功能是直接调用unix下的sendmail来实现的，这就给在windows下运行造成了很大难度。对此，Bugzilla的官方文档给出的办法是将Sendmail部分用perl的Net::Smtp模块来代替。但是在最新的Bugzilla版本中，一共有11个文件需要修改，且各地代码修改方式均有所不同，且目前大部分smtp服务器均需要认证才能发信，将信箱密码写在程序源码中毕竟不是一个好办法，基于以上种种原因，我们自己编程实现了windows下的 sendmail，基本能够完成unix下sendmail的功能。我们需要做的是用新sendmail的路径替换旧有的sendmail路径就可以了。
如：sendmail位于bugzilla目录下的mailer目录下，我们就可以使用“|Mailer/sendmail”替换“|/usr/lib/sendmail”。
除此以外，还要将contrib\bug_email.pl中的“| /usr/sbin/sendmail”替换成“|Mailer/sendmail”， contrib\mysqld-watcher.pl 中的“/usr/lib/sendmail”替换成“Mailer/sendmail”

替换完成后，我们要运行BugMailer.exe进行配置，输入SMTP服务器的地址、端口号以及发信认证相关信息就可以了。配置后，会在当前目录产生配置文件BugMailer.ini，当发送邮件时，如果产生错误，详细信息会产生在当前目录的BugMailer.log文件中。

对于Bugzilla，还有5个文件并不是使用配置中所输入的信箱进行发信的，而是使用了固定的用户“bugzilla-admin-daemon”、“bugzilla-request-daemon”来进行发送，而某些需要SMTP认证的邮件服务器是不允许验证用户使用其他人的名称进行发送的，所以需要手工将其替换成BugMailer.exe中输入的邮件地址。
包含以下几个文件
template\en\default\account\cancel-token.txt.tmpl
template\en\default\account\password\forgotten-password.txt.tmpl
template\en\default\account\email\change-new.txt.tmpl
template\en\default\account\email\change-old.txt.tmpl
template\en\default\request\email.txt.tmpl

至此Bugzilla的邮件发送功能基本完成，同时，Bugzilla也已基本安装完成，下一步就是以超级用户登录对 bugzilla进行配置了。

三、补充说明

对于Bugzilla的安装，比较麻烦的就是安装Perl模块及对Bugzilla源文件的修改。安装过程的要点是不断的运行perl checksetup.pl脚本，随时根据里面提示的信息进行相关操作就可以了。

记得修改Email的头信息的编码为GB2312.这个和语言包相关.而且MySQL最好使用gb2312的编码,和Apache的default charset一致.

参考文献：
Installing Bugzilla on Microsoft Windowshttp://ebugs.org/bugzilla/2.php

Bugzilla 应用(2)——Bugzilla 的安装

The SOAP tool Apache Axis offers a lot of features which require the use of a deployment descriptor. This reference describes all the elements and attributes which can be used in a WSDD deployment descriptor.

Elements

All Elements belong to the http://xml.apache.org/axis/wsdd/ namespace.

• beanMapping
• chain
• deployment
• documentation
• endpointURL
• fault
• globalConfiguration
• handler
• handlerInfo
• handlerInfoChain
• header
• namespace
• operation
• parameter (configuration parameter)
• parameter (operation parameter)
• requestFlow
• responseFlow
• role
• service
• transport
• typeMapping
• undeployment
• wsdlFile