一个完整的接口技术解决方案（二）
发表这篇解决方案，属于非盈利目的。主要是为了让大家了解一种接口技术解决方案文档的编写格式以及让大家评审在我的这个技术解决方案中的不足之处，以便大家指出并加以改进。
转载，下载或与各种形式使用这篇文章，必须注明文章的作者，出处。
其他未尽事宜，以国家法律规定的为准！
作者：南疯
4 接口安全
4.1 接口认证
调用认证：
虽然接口双方都是存在于电信内部网络中，但是，仍不能排除接口服务被攻击、恶意调用以及非法调用等。所以，从接口调用上，必须考虑调用的认证安全问题。
u 本方案中的接口，在客户端调用服务端的时候，必须经过调用身份认证。考虑施工系统的开发平台的多样性，但同时接口服务运行平台都是Windows的情况，本方案采用Windows安全身份认证的方式。即在访问接口所在的服务的时候，都必须进行资格审查（使用Credentials发送认证信息）。
u 另外，接口采用SOAP协议，因此在接口配置上面需要屏蔽HTTP GET 和HTTP POST等其他协议。
u 在接口中审核并进行日志的记录。
u 使用最低权限的进程帐户运行 Web 服务（通过 Machine.config 中的 <processModel> 元素来配置）。
u 接口不支持动态生成WSDL,因此作为服务端，应该禁止文档协议。
u 在服务端禁用跟踪，禁用调式编译
业务用户认证：
由于接口涉及电信工程中的各个不同的业务，有获取字典、获得项目信息、发送开工报告等，所以，建立一套业务的用户认证机制是必须的。不同的用户，所具备有的授权不一样，所能执行的业务也不一样。同时，业务用户认证中的用户信息也是记录接口日志中的重要组成部分。
本方案采用的是在接口信息中包含业务认证用户信息的方式来进行认证。服务端在收到请求的时候，应先验证业务的授权用户，如果该业务用户没有执行当前业务的权限，应终止业务的执行，并给出非法用户的警告信息反馈回客户端。
一般情况下，业务认证的用户是系统中的用户。业务认证其实就是应用系统认证的组成部分。
业务认证的用户信息经过加密之后包含在要发送的信息（XML体）中，即在发送的信息中包含业务用户的信息（参见下面的数据格式说明）。
4.2 数据安全
数据的安全表现为如何保证数据在网络传输过程中不会被截获并被解析其中的内容而引起信息泄露与如何保证数据在传输的过程中的数据的完整性两个方面。
Web Service采用XML数据格式来传输信息。所以，无论是发送数据还是返回结果，都要求采用对XML数据加密之后来传输。至于采用何种方式的加密技术，本方案为了保密，只能在开发的时候由开发人员口头告知。涉及到加密技术就要涉及到加密的密钥问题。目前，外协系统和施工系统接口上有很多种类型的业务，到底是每种类型的业务采用不同的密钥，还是按分组来采用同一种密钥的方式，还是所有的业务全部采用同一种的密钥的方式，按照需求各有不同的选择。本方案采用的是最后一种的方式。密钥的发布由作为服务方来发布，由客户端获取。密钥的发布方式待定。
为了保证数据的完整性，首先：方案采用数据签名（SOAP Security Extensions: Digital Signature）。利用XML的数字签名（XML Digital Signature syntax [XML-Signature]）对SOAP进行扩展，在SOAP的头元素中定义签名属性（<SOAP-SEC:Signature>）来实现。其次：限制并验证 Web 方法输入的类型、长度、格式和范围，验证对 XML 输入数据的验证是基于已协商的架构等。
5 事务处理
事务是一组相关的任务，作为独立于其他任务的独立单元成功（提交）或失败（中止）。分布式事务是影响多个资源的事务。要提交分布式事务，所有参与者都必须保证对数据的任何更改是永久的。不论系统崩溃或是发生其他无法预料的事件，更改都必须是持久的。即使只有一个参与者无法保证这一点，整个事务也将失败，在事务范围内对数据的任何更改均将回滚。
外协系统和施工系统是处于网络之上的两个分布式接口，使用的是分布式事务。要启用分布式事务，可能需要通过网络启用 MS DTC（考虑外协平台和施工平台都是运行在Windows上），以便在使用应用了最新的 Service Pack 的较新操作系统（例如 Windows XP 或 Windows 2003）时使用分布式事务。如果启用了 Windows 防火墙（Windows XP Service Pack 2 的默认设置），必须允许 MS DTC 服务使用网络或打开 MS DTC 端口。
接口中的服务端和客户端的环境事务始终相同，客户端创建的事务上下文并应用对于服务端的当前的事务，以便对于该事务上下文是当前的。这样的事务会造成性能损失，因为可能需要继承原来的上下文，但是，这样的事务确保了在数据库操作的时候信息的完整性。接口中事务的发起总是由客户端发起的，并负责事务的提交和回滚等控制。
6 性能考虑
在接口设计的时候就应该考虑性能上面的问题，不要在事后再加入性能。同时，在项目的开发过程要反复进行测试，可以从机器的吞吐量和响应时间两个基本的指标来衡量接口的性能。接口上面的性能考虑主要从下面几个方面来优化：
u 使用一次连接，多次调用，优化连接资源。
u 对于并行的接口调用使用异步的调用方式。
u 优化线程池减少竞争。
u 考虑使用XML压缩。
u 如果不需要返回，考虑使用单工通讯的方式。
u 适当的设置（如果有代理）代理超时，页面超时，WebService超时。
u 设计"大块头"的接口减少往返。
u 基于消息的编程而不是远程过程调用(RPC) 。
u 使用XML字串作为参数。
u 尽量使用原始数据类型参数。
u 避免在调用之间维护服务器状态。
u 考虑为复杂的WebMethod提供输入校验。
u 考虑对WebMethod的结果使用缓存。
u 选择适用的大数据包传送方式。
u 避免调用本地的WebService。
7 容错处理
客户端向服务端发送数据，服务端解析数据，反馈信息给客户端，这中间的环节只要某一个环节出现问题，都会造成接口的失败。按照失败产生的环节分类，我们可以从三个方面来处理接口的失败。
u 网络连接失败：在调用接口的时候，由于网络不通，造成数据不能正常传输。这样，客户端应该能够记录发送的日志，按照一定的时间间隔重试发送。本方案定为重试发送20次，每次时间间隔2小时。如果一直发生网络不通的情况，该发送日志被保存下来，待后手工发送。所以，客户端系统应该实现手工发送数据的功能。
u 反馈错误信息：服务端在解析数据包，执行数据包业务的时候，可能会发生异常。所以，服务端应当能够捕捉异常信息，比如“非法XML格式”等，然后反馈给客户端。客户端在接受到这类的错误信息之后，应当进行日志记录，能够自动或手工分析异常的信息。
u 网络连接正常，但是无信息反馈：这种情况下，一般是服务端出现了异常，但是又没有捕捉到的情况下发生。这种情况下，客户端把这种错误当作“网络连接失败”来处理。服务端应能够实现相同数据包重新发送过来的处理机制。
