3 模块间通信的标准化

    在信息系统设计开发中，对于数据流和数据字典中格式的最终实现是由于系统开发时采用的开发工具与系统模型相关。在实际的应用中，由于对内部数据格式没有统一的规定，不同的ERP系统，或者同一ERP系统不同版本的内部交换格式都可能是不同的，这样就对系统的整合及二次开发带来一定的难度。

    虽然在不同的语言中，也存在各自的数据交换语言，比如Ajax技术中就采用JSON作为其数据交换的标准。由于Ajax使用的JavaScript是一种脚本语言，脚本语言较低的效率和缺少XML解释器使得Ajax放弃了对XML的选择而转向了简洁的JSON，虽然JSON在数据格式和使用上都比XML简洁，然而JSON专注于JavaScript方面的数据交换，缺乏语言的兼容性，而且JSON不是一个标准化的格式，稳定性和安全性都不能很好地保证，所以在普及方面还是有很多的问题。

    类似的技术是ADO.Net采用了XML作为数据交换的中间格式，XML作为数据交换的统一格式为其实现跨数据库提供了基础。由于ADO技术只是作为一种跨数据库的数据操作方式而设计，对于数据含义的统一和解释并不是必要的。同时，在新一代的数据库存储技术中，XML已成为新的数据库存储格式，XML在Web应用中也起到了举足轻重的作用。而在桌面应用中，XML也已成为很好的数据存储格式。XML作为新一代的数据存储标准，XML着眼于数据存储及数据的呈现，作为下一代的网络语言XML是成功的。然而在语义统一方面，XML并没有做出相应的规定，不能作为模块间通信的数据交换语言。

    4 如何使用ebXML消除数据差异

    消除模块间的信息交换格式不统一的问题，成熟的ebXML似乎是一个可行的解决方案。由于ebXML在设计之初就是为了统一不同系统间的通信格式，作为系统内部数据交换的统一格式，也是非常合适的。

    在系统设计时，系统设计人员就根据需要对系统做出系统设计，数据字典和数据流是其中重要的一部分，合理高效的数据流是好的信息系统的基础，在信息系统试运行期间，针对用户变化的需求有时可能要对数据做出一定的修改和完善，如何在变化的需求中保持系统的稳健性是信息系统设计开发者需要考虑的一个问题。在系统模块直接访问数据的开发方式下，一旦某个数据流需要做出修改，涉及的模块都要做出相应的修改。而利用ebXML将数据流进行对象化封装是一个比较好的解决方案。

    在ebXML的实施中，不同系统的的差异由ebXML注册中心来消除，不同含义的XML信息通过在注册处查找对方的定义来实现转换，对于不同的数据信息也可以采用类似的处理办法来进行转换，我们可以在ERP系统与数据库之间加入EDI翻译层作为ERP系统与数据库交互的中介，系统中各个模块间的数据流可以在EDI翻译层定义，所有的数据相关定义存储在EDI翻译层，ERP的各个模块不再直接对数据库进行操作，在系统模块请求的时候，只是向EDI翻译层发出数据流请求，而EDI翻译层将根据系统设计时预定义的数据流格式，从数据库获得并转换为XML格式报文返回给ERP系统（参见图1）。

    而对于外部系统的数据操作同样由EDI翻译层来消除差异性，在不同的ERP系统互联的时候，首先要在EDI翻译层对对方的数据流和数据字典做出对应的数据解释，即将对方的数据流和自己的数据库对应起来。在不同系统间通信时，如果需要外部数据，则对EDI翻译层发出数据请求，己方的EDI翻译层收到后将请求转发给被请求方的EDI翻译层，对方的EDI翻译层收到后则根据定义数据格式做出反应和处理，然后将要求的数据返回给发送方的EDI翻译层，己方的EDI翻译层再把数据返回给ERP模块，这样完成整个数据处理过程（参见图2）。即在全局方面，EDI翻译层也可以作为ebXML的端点来实现；在内部系统中，EDI翻译层又是ebXML的本地化的实现。所以在具体实施中，EDI翻译层并不与ebXML冲突，两者可以很好地结合在一起。