public sealed class WebMethodAttribute : Attribute

　　那么，如果我们需要将一个属性也发布成一个Web方法，该如何做呢?在讨论这个问题之前，先来看看为什么我们需要发布属性为一个Web方法?因为有人可能会这么告诉你，你可以把你的属性改写成两个对应的getXXXXX/setXXXXX方法来分别发布成WebMethod。哦，是的，这么做看似可以达到目的，但是这样做损害了我们的接口定义，使得我们无法享受属性为我们所带来的快乐(请不要问我是什么快乐)，其实最重要的一个原因就是无法完成对接口的实现了，此话怎讲?且看下面代码(C#):

　　public interface IDataService

　　{

　　// 该属性指示当前使用的是什么数据库系统(例如:MS-SQLServer、Orcale、IBM-DB2 等等)

　　int DataProvider

　　{

　　get;

　　}

　　// 该方法执行一段指定的SQL脚本，并返回其结果集

　　System.Data.DataSet Execute(String sqlText);

　　// 该方法将指定的数据集保存到数据库中

　　void Update(System.Data.DataSet dataSet);

　　}

　　现在我们写一个 WebService 其需要实现 IDataService 接口，必须在该 WebService 中包含并发布该属性。这时我们该怎么办?呵呵，且看

　　public class DataService : System.Web.Services.WebSerbice, IDataService

　　{

　　...

　　public int DataProvider

　　{

　　[WebMethod(MessageName="GetDataProvider")]

　　get

　　{

　　...

　　}

　　}

　　[WebMethod()]

　　public System.Data.DataSet Execute(String sqlText)

　　{

　　...

　　}

　　}

　　OK，大家看到了，将一个方法发布成Web方法是在其函数体前指定 WebMethod 属性，而属性则是在其get或set器之前指定 WebMethod 属性，如果不指定属性的 MessageName 属性值，则发布的属性的Web方法名将被置为get_XXXXX和set_XXXXX。

　　在使用VS.net生成的 WebService 代理类(通过添加Web引用，Reference.cs)中的成员都是方法，因此需要手动修改代理类中的相关方法为属性，例如上例的本地代理类的相关代码看起来是这样的:

　　[System.Web.Services.Protocols.SoapDocumentMethodAttribute(... ...)]

　　[return: System.Xml.Serialization.XmlElementAttribute("GetDataProviderResult")]

　　public int GetDataProvider()

　　{

　　object[] results = this.Invoke("GetDataProvider", new object[0]);

　　return (int)results[0];

　　}

　　那么，你只需将该方法的主体部分大概改成这个样子即可:

　　public int GetDataProvider

　　{

　　[System.Web.Services.Protocols.SoapDocumentMethodAttribute(... ...)]

　　[return: System.Xml.Serialization.XmlElementAttribute("GetDataProviderResult")]

　　get

　　{

　　object[] results = this.Invoke("GetDataProvider", new object[0]);

　　return (int)results[0];

　　}

　　}

　　当有支持者确认了一个调查，在开始就 进行测试并且采用敏捷原则比直到最后的开发阶段才测试更有好处，我们暂且不管这些，我们先把关于何时把测试引入到你具体的工程中去的讨论搁置一边，让我们关注一下如何进行测试。

　　测试决不是一个简单的东西，有很多不同的测试类型可以应用在软件上。依据测试的复杂性和领域 ，即使专业的团队——QA团队——可以被雇来完成特定的任务，但是是为了特定的目定，我们将会关注两种类型的测试，他们都相对容易的开发:单元测试和压力测试。

　　单元测试是指通过预先定义的一些列数据集合来验证一个服务的既定目的的过程，这个数据集合是用来模拟显示世界的用法从而能够及时的方式来探测到缺陷。当为你的服务进行单元测试的时候， 在服务被发布为正是的产品以前你可以把他们看成安全保护网，因为你能够在实际数据流在这个系统运行之前使用这些预先的数据集合来测试你的服务的逻辑。

　　另外一个单元测试为你的开发带来的那些好处在当你的系统开始用上了一段时间之后就会更加突出了。因为演化的服务意味着底层逻辑的修改，这些修改可能会破坏服务本来被希望忙足的一些具体的使用设定。尽管如此，通过现有的单元测试套件，并且保证一直保持同这些测试的一致，保护任何使用你服务的依赖部分免受在以后可能新的修订中带来的任何破坏

　　实际的单元测试的进行很大程度上依赖于编程语言或者你使用来部署你的服务的平台，但是更加可能的情况是为了能更容易的进行测试的步步为营，确认和部署，将会通过一个特定的框架来完成这些 ——换一句话说就是， 自动化的进行所有的能够使得单元测试成为必需的过程。

　　在所有的最流行的单元测试的框架中有:Java的JUnit 和.NET的Unit Testing Framework ，Unit Testing Framework 构成了Visual Studio的一部分。对于深度的解释他们的框架或者其他的一些单元测试套件将不会在本文中讨论，但是列表1.1展示的就是一个Java支持的服务的Junit测试是怎样的。

　　列表1.1 对Java类构成的Web Services的Junit单元测试

import junit.framework.*;
public class PayrollTest extends TestCase {
    private Payroll basePayroll;
    private Employee accountingE;
    public PayrollTest(String type) {
        super(type);
    }
   protected void setUp() {
 // Initialize Payroll object
        basePayroll = new Payroll();
  // Generate employee, assign to payroll
        accountingE = new Employee("John Smith", 5743.00);
        basePayroll.addEmployee(accountingE);
    }
    protected void tearDown() {
 // Reinitialize Payroll object
        basePayroll = null;
    }
    public void testAddEmployee() {
        Employee contractE = new Employee("Auditor", 2843.00);
        basePayroll.addEmployee(contractE);
         double totalPayroll = accountingE.getSalary() + contractE.getSalary();
        assertEquals(totalPayroll, basePayroll.getTotal(), 0.0);
         assertEquals(2, basePayroll.countEmployees());
    }
    public void testEmptyPayroll() {
        basePayroll.emptyPayroll();   
        assertTrue(basePayroll.emptyPayroll());
    }
       public void testEliminateEmployee() throws EmployeeNotFound {
        basePayroll.eliminateEmployee(accountingE);
        assertEquals(0, basePayroll.countEmployees());
        assertEquals(0.0, basePayroll.getTotal(), 0.0);
    }
     public static Test suite() {
        TestSuite suite = new TestSuite(PayrollTest.class);
 return suite;
     }
    public static void main(String args[]) {
        junit.textui.TestRunner.run(suite());
    }
 }

　　这个测试列表表示的是对两个将会用来构成决定薪水册的数据的Web service进行测试的一个例子。请注意Payroll和Employee类的实例是如何创建的，它们都会被后面的testXXX()命名的方法来操纵。一旦被这些方法操作，请注意看到是通过不同的以assertXXX()命名的Junit方法来调用的。

　　用来调用预先定义的数据块的不同的断言方法的参数在底层的服务类之间传递，在这些类上进行同所期望的值进行比对，这个比对是在当测试框架给出一个错误或者返回一个正确的执行的时候进行。

　　单元测试是用来验证一个服务逻辑的完整性，重点测试是用来决定一个服务在一个特定的用户附载的时候应该具有什么样的行为，它是一个可以帮助决定对一个服务的基础架构的适当支持的过程，这些基础架构包括如硬件能力，应用程序配置和可以获得的网络带宽，以及其他的东西。

　　一个可以帮助你进行压力测试的工具是JMeter ，它是一个由Apache组织开发的一个开源项目。尽管Jmeter是基于java的，它可以产生SOAP和XMLRPC类型的请求，有效地发挥一个Web services客户端的功能，来压力测试任何服务端的部署。图1.1展示的是一个使用这个工具进行的在SOAP/XML-RPC服务上的附载测试。

　　图1.1:Jmeter对Web services的压力测试

　　在Jmeter中创建上述的压力测试的过程如下:

　　1. 在Jmeter的主界面，将你的鼠标移动到Test Plan按钮上并点击右键。从弹出的菜单中选择:Add – Thread Group。Thread Group按钮将会被创建。

　　2.定位在Thread Group按钮上左边的窗体中将会显示不同的参数。参数Number of threads 表示的是你的压力测试将会对你的服务仿效的请求的数。

　　3.下一步，当鼠标在Thread Group按钮上点击右键，从弹出的菜单中选择:Add – Sampler – SOAP/XML-RPC Request。SOAP/XML-RPC请求按钮将会被创建。

　　4.鼠标定位在SOAP/XML-RPC请求按钮，左边的窗体中将会显示不同的参数。有关于你的Web service的URL的介绍，以及你希望发出的每一个请求的载荷。

　　5.当鼠标在SOAP/XML-RPC请求按钮上时，点击右键，从弹出的菜单中选择:Add – Listener – Monitor Results，和Add – Listener – View Results。两个显示压力测试结果的按钮将会生成。注意:如果需要，你可以添加更多的监听者，这是Jmeter进行压力测试结果的表示术语。

　　6.保存你的测试，并从最高层的菜单中选择Run-Start选项开始你的压力测试。

　　7.最后移动你的鼠标到每一个不同的Listener按钮上， 观察你在对你的Web service进行压力测试时获得的性能参数。

　　和单元测试框架相类似的本质，解释Jmeter的许多复杂——或者任何其他压力测试工具的这方面的问题——将会超出本文的范围，但是Jmeter提供了全面可理解的并可自由获取的文档来解释不同的压力测试功能。

　　我们总结我们对在Web services环境下单元测试和压力测试的认识，这是在很多的测试过程中你可以在你的面向服务设计中的两个方法，从而能够确保你的部署的完整性和可测量性

•          面向服务强调逻辑处理单元（服务）之间的松耦合。虽然面向对象支持可重用、松耦合的编程程序，但它主要基于预定义的依赖类，产生和逻辑处理单元（对象）的紧耦合。

•         面向服务鼓励粗粒度接口（服务描述），因此每个通讯单元（消息）都包含完成给定任务所需的尽可能多的信息。面向对象编程完全支持细粒度接口（APIs），因此通讯单元（RPC或本地API调用）能执行各种大小的任务。

•          面向服务期望逻辑处理单元（服务）的范围可以较大。面向对象中的逻辑处理单元（对象）趋向于在一定范围内更小和更加明确。

•          面向服务促进逻辑处理单元（服务）未知行为的创建，那是由智能通讯单元（消息）所引起的行为。面向对象鼓励逻辑处理和数据的绑定，产生非常智能的单元（对象）。

•          面向服务更多采用逻辑处理单元（服务）进行设计并进可能保持无状态。面向对象鼓励数据和逻辑的绑定，因此产生有状态单元（对象）。（然而，近来更多的基于组件的设计方法背离了这种趋势）

•          面向服务支持逻辑处理单元（服务）的松耦合组合。面向对象也支持组合但趋向于继承自逻辑处理单元（对象），那会导致依赖紧耦合。

当然，面向服务还欠缺很多面向对象已有的概念和理论。下表提供了一般的面向对象原则与已经讨论过的面向服务的原则的比较。 

可以看到，面向对象和面向服务并非竞争者。面向服务显然在不少方面是以面向对象为基础，当前典型的面向服务的解决方案将由服务（遵循面向服务的原则）和面向对象的组件构成。在合理的设计中，每个原则都能被适当地处理并能相互补充。

1  可从企业外部访问 B2B协议

2  随时可用

3  粗粒度服务接口

4 分级，粗粒度的服务比细粒度的服务重用性差，所以要采用不同的粒度等级来创建服务。

 在服务分级方面，须注意服务层的公开服务通常由后台系统（BES's）或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。

5  松散耦合

 服务接口作为与服务实现分离的实体而存在。大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和异步协议实现。

 当客户调用消息类Web服务时，客户通常会发送的是一个完整的文档（如采购订单），而非一组离散的参数。

6  可重用的服务及服务接口设计管理

7  标准化的接口

 Web服务使应用功能得以通过标准化接口（WSDL）提供，并可基于标准化传输方式（HTTP和JMS）、采用标准化协议（SOAP）进行调用。

8  支持各种消息模式

 无状态的消息、有状态的消息、等幂消息

9  精确定义的服务接口

 总之，SOA可以看作是B/S模型、XML/Web Service技术之后的自然延伸。SOA将能够帮助我们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，

它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。