数据元

1 存储过程 创建用于存储数据元的桶，可以选择数据元所驻留的地区（目前来说，选择东京、新加坡会快些，美国本土更便宜），上传数据元到桶，进行持久化存储。另外，可以对上传的数据元及桶进行访问控制、加密等设置。每个AWS账户可以创建多个用户，用户可以对所拥有的数据进行上述权限控制。 目前可存储的你内容有： (1)多媒体、音乐、图片 (2)视频监控文件 (3)医疗系统的档案、资料 (4)静态网站资料 2 管理 通过AWS管理控制台对数据进行控制。AWS控制台类似于EC2的web控制界面，或者通过API接口(Java、.Net)、REST接口编程实现。 3 S3功能简述 (1)创建桶、删除桶 (2)写入、读取、删除数据元，每个数据元的大小从1byte到5Tbyte (3)根据用户密钥，查询桶信息及数据元信息 (4)选择数据所存储的地区，东京 or 新加坡 or 其他 (5)数据元的权限设置，可以向指定的用户开放，加密等 (6)使用基于REST和SOAP接口，提供JAVA，net的SDK (7)便于添加其他功能，默认的下载协议是HTTP (8)提供AWS管理平台，对数据进行管理 (9)在进行存储或者检索数据时，对数据进行校验和计算，验证是否损坏 (10)去冗余存储，用户可以自定义一些文件，比如缩略图、转码媒体等，使得这些文件的存储冗余副本数目低于标准的冗余副本数目 (11)数据源的访问日志记录

一、 模式 国内电子病历系统的开发不外 2 种模式： C/S 模式和 B/S 模式，其中 C/S 模式一般是以开放的文字编辑器为基础进行开发，而 B/S 一般采用页面填写模式，也有采用 OCX 控件模式（这种模式其实也是一种 C/S ）。 两种模式各有优劣，从我个人角度讲，更趋向于 C/S （这里是指三层结构的 C/S ），理由如下： 1、 B/S 相对于 C/S 最大优势在于客户端免维护，其实 C/S 做好了，也可以实现自动升级和客户端免维护，我以前在某地区做的医保系统，采用三层结构，广域网上 1000 多个 C/S 客户端，一样免维护。 2、 C/S 具有更好的界面操作性，尤其是能够实现更复杂的界面操作动作，能在一定程度上较好实现自然语言输入与结构化处理。 B/S 由于受编辑器功能限制，在文字间相互操作、数据元、各种提示、绘图处理等方面都存在一定的欠缺。 3、 C/S 具有更直观的界面，实现所见即所得模式的书写，而 B/S 不采用控件很难做到。 4、 C/S 具有更好的效率，尤其是在处理和展示大量数据量时， C/S 优势更明显。 B/S 模式受服务器和浏览器限制，展示大量数据时效率直线下降。我们曾经试过 IE 同时显示 1000 条记录时，速度慢得让人无法忍受。 当然具体采用哪种模式，还需要看自己的产品路线及技术沉淀，最好与 HIS 采用相同模式。由于 B/S

几乎所有的需要在卡片和终端之间传送的数据都是TLV格式的. PBOC文档里并没有对TLV编码细节做具体说明, 而EMV的手册里虽有叙述，但并不详细. 我下面就要很详细的分析TLV的编码格式并给出相应的TLV解码的伪代码. TLV是tag, length和value的缩写.一个基本的数据元就包括上面三个域. Tag唯一标识该数据元, length是value域的长度. Value就是数据本身了. 举个例子, 下面是一个tlv格式的AID（应用标识符）字节串”9F0607A0000000031010”, 其中9F06是tag, 07是长度, A0000000031010就是AID本身的值了. 对于程序编写人员来说，我们关心的是，如果有类似上面这样的一串TLV编码的字节串从卡片传过来, 怎么样从中提取我们想要的数据. 这就牵扯出TLV解码的问题了. 其中BER-TLV编码是ISO定义一种规范, 然后到了PBOC/EMV里被简化了, 哪里被简化了呢?举一个例子, tag域在ISO里可以有多个字节, 而PBOC/EMV里规定只用前两个字节. 我下面要讲的TLV解码就是基于PBOC/EMV的简化版本. 首先看一下tag域是怎样编码的. Tag域占最多占两个字节. 编码规则如下面两幅图： <图1> <图2> 解释一下这两幅图. 第一个图是第一个字节的编码规则. b8和b7两位标识tag所属类别.