Web接口开发的相关事项

本次任务的具体背景及要求：

• 需要将数据提供方（对方）的数据同步到本地（我方）
• 目的是在本地维护一个与数据提供方一致的本地数据库（ORACLE）
• 数据提供方提出的方案就是我方开发一个Web接口供其调用
• 数据方给出其发送数据的格式等信息，即给出了接口规范

本次任务的交互情景：

• 对于实时数据，数据方在收集后每隔十分钟调用一次接口推送过来这些数据
• 我方接口对其推送数据进行解析并入库
• 对于先前历史数据，直接以文件方式提供给我方
• 我方直接用本地程序解析后入库，不通过接口

推送数据的具体规范：

• 原始数据采用的是XML格式的文本，先后经过base64编码和DES加密，之后对方推送至我方
• 原始数据是格式化且规范的，XML共分四级，第三级标签开始代表每一次操作的表数据
• 原始数据包含CLOB和BLOB类型的数据 - 插入Oracle时要额外处理
• 原始数据包含的字段每次都是不确定的
• 一次推送包含若干原始数据段，即本地入库时对表的操作也是不确定的
• 推送的数据量可能很大，一次推送纯文本大约20MB - 构造SQL语句时要额外处理，否则SQL语句会过长（超过4000）
• 数据对应表有5张，每个表平均100个字段左右

对于历史数据：

• 数据就是一堆编码并加密了的字符串 - 对其处理与处理推送数据的逻辑差不多
• 此字符串非常长，文本大小约500MB - 在解密解码时只要加大内存限制就可以完成，但解析XML时需要SAXReader方式，dom方式的话要爆炸了
• 原始数据包含CLOB和BLOB类型的数据 - 插入Oracle时要额外处理
• 原始数据包含的字段每次都是不确定的
• 一次推送包含若干原始数据段，即本地入库时对表的操作也是不确定的

知道上述信息后我方开发接口的情况：

• 接口参数包括验证信息，和数据，就这两个参数
• 接口采用JAX-WS实现，原因是其实现比较简单且轻便，可以参照：真正的轻量级WebService框架 - 使用JAX-WS(JWS)发布WebService
• 接口任务一，DES解密并base64解码推送来的数据 — 解密方式一定要和对方的一致，这里直接用对方提供的加解密代码，并且对方告知了DES秘钥 — 解码就比较随意，base64解码都大同小异
• 接口任务二，用dom4j包来解析XML树，这里采用SAXReader的方式，原因上面说了
• 接口任务三，映射表名字段名，原始推送数据字段均为汉字，Oracle库中存的都是首字母大写
• 接口任务四，构造SQL语句，具体思想就是解析XML到第三级标签，这一级会包含所有<插入字段名>和<插入字段值>

整个流程大致如下：

image_1bunklcj6tim16li12rn1q0undf9.png-134.2kB

左边：数据推送方，不必关心其逻辑实现 右边：本地逻辑接口实现

下面是上述叙述中遇到的问题：

• 如何按原始数据中的汉语字段建立数据表
• 如何监控接口的情况也是问题，生成日志是解决之道
• 乱码问题！!服务器？编译时？原数据？UTF-8？GBK？到底是谁的锅
• 如何将原始字段快速映射成我即将将其插入到表中的对应字段
• Oracle字段的符号要求，浪费了很多时间
• 大量字段中含少量CLOB字段时，对CLOB类型的数据使用jdbc插入数据库
• 大量字段中含少量BLOB字段时，对BLOB类型的数据使用jdbc插入数据库，这个费了一番功夫
• 整明白插入时，涉及大量字段操作时，对数据的增量更新也是问题
• SQL语句如何执行，批量还是单独，这是个问题
• 程序循环过多导致Oracle连接游标数超出限制的问题

以上问题先放着，抽空再逐个分析，如果上述包括了您急需解决的问题，请@我我会尽快回复我的解决办法，或许对您会有帮助。

对于接口的传输性能：

• 开始时错误的以为历史数据也要通过接口方式调用，就对JWS发布的这个接口进行了一下测试，发现接口的极限是200M左右
• 也就是说调用接口时，传入参数的字符串大小可以为200M没问题
• 上述都是废话，正常是不允许接口传输大量数据的。