关于 XML/EDI Web Service 小介绍

XML/EDI 系统的设计

总体框架

  该 XML/EDI 系统分为四个层次:

  第一层是提供 Web Service 的服务提供者,它包括服务提供者所能提供的所有服务(主要是与数据库之间的交互以及复杂功能的实现)
  第二层是收集 Web Service 的服务代理,它主要收集所有的 Web Service 并对外发布,服务代理可以通过 Internet 或 Intranet 向服务中心发送远程调用信息,这些信息吧请求内容以 XML 数据格式表示且采用基于 HTTP 等通用 Internet 协议之上的 SOAP 协议来传输
  第三层是客户端程序,调用 Web Service 的服务请求者,这一层的内容是根据客户端返回的 XML 数据在服务代理中寻找合适的 Web Service 来对数据进行处理,并且提供最终客户端服务界面
  第四层是最终客户端,它主要把最终用户在界面上表达的信息组合成符合统一的 Schema 要求的 XML 数据流,终端对象所能看到的具体的 EDI 界面是由针对不同用户的服务请求者来提供。
  其中第一层至第三层可以由相应的服务机构来提供智能并进行维护。

  1) 四层机构使得各类功能间具有明确的划分,其中的 Web Service 有很好的可重用性
  2) 传输的数据都是 XML 数据流,统一的数据格式使得基于 Web Service 的 XML/EDI 能够得到更加广泛的应用
  3) 由于所有的层次之间都是通过 SOAP 协议进行数据传输,所以 XML/EDI 系统可以面向不同终端提供服务,包括电脑、手机等等。

功能模块设计

  从具体业务来说, XML/EDI 分为商务数据维护、订货和发货三部分。商务数据维护部分负责对本系统中用到的所有数据的维护,包括商家信息维护、商品货架信息维护和商品信息维护等等。
  以商品信息维护为例,这部分主要为批发商提供了商品录入、商品信息文件上传、商品信息修改和删除等功能。 当商品录入时,批发商可以利用浏览器按照界面上所提供的信息点击或作适当输入。按照预定的 Schema 编写的商品信息文件可以直接上传到服务提供者那里,系统自动从中抽取信息保存到相应的库中。
  订货部分包括零售商与批发商订立销售合同,以及零售商向批发商发出订单。其中的主要流程为:批发商先向零售商发出价目表,零售商如果不同意其中的报价,可以和批发商进行讨价还价,直到双方达成一致,形成合同,今后双方的交易都将按照合同进行,除非订立了新的合同。当零售商门店发现有某些商品将要短缺时,就向零售商发送订货请求。如果批发商拥有零售商提出的商品数量,则形成订单,如果没有,则不形成订单。当然,一般情况下零售商会订购多件商品,如果订购过程中部分商品的数量不足,那么双方仍可以对其他数量足够的商品形成订单。发货部分包括批发商在按照订单发出相应货物后向零售商发出发货预订单,零售商在验证后向批发商发出到货实绩单,批发商据此结算交易费用。其中需要按照订单的信息向货架查询库存信息,把出货商品信息列入出货指示数据中,同时修改库存信息。当商品到达批发商都可以要求打印有关单据,这些单据涉及的数据都长期保存在信息库中,以便以后查阅。

3 系统具体实现

  对应于详细设计的要求,系统主要分为数据库的实现,Web Service 程序,Web Service 请求程序,以及最终用户看到的 EDI 界面的实现。
  数据库的实现是整个系统的基础部分,所有 Web Service 的操作大多都是在数据库的基础上进行的。系统中的数据库主要包括五个方面的数据:标准商品数据、交易关系数据、商品货架数据、订单数据和批发信息数据。
  Web Service 是系统的第一层,也就是 EDI 系统所能实现的所有对外服务,对本系统来说,一般涉及对数据库的操作。以商品录入数据库为例,该 Web Service 向外的接口是 XML 数据流,当相应的 Web Service 被调用时,从客户端传来的 XML 数据流被按照事先统一好的 Schema 文档格式解析,其中的各个商品字段被分离出来,按照关系数据库的格式存入数据库。
  Web Service 请求程序处于系统的第二层,在整个系统中起到承上启下的作用。这一层接收从 EDI 界面传过来的商家信息,再调用相应的 Web Service 对信息进行处理并将处理结果反馈到 EDI 界面上。仍以商品录入为例,不管是单个商品录入也好,还是商品文件上传也好,到达这一层的时候都是以 XML 数据流的格式存在的,当接收到数据流后,该层先对 XML 文件进行 Schema 检验,符合 Schema 文档定义的 XML 数据流就交给 Web Service 处理,如不符合 Schema 文档定义,就反馈错误信息。
  EDI 界面在用户看来和普通的HTML 网页一样,但在实现过程中却是以 .NET 里面的 ASP.NET 制作的。不同之处在于 ASP.NET 里提供了大量的 Web 组件,可以很方便地构造一个美观的页面,而且还提供多种编程语言对数据进行处理,而不局限于 VBScript 和 JavaScript 。以单个商品输入为例,页面提供商品类别、商品名和商品数量的填写框架,由用户输入信息,再由客户端程序形成 XML 文件。

Visual.NET 里实现方法,其 Service Requester 端:

 1 string temps = xmlFile.ReadToEnd();
 2 XmlDocument doc = new XmlDocument();
 3 doc.LoadXml(temps);
 4 
 5 string p = CommShow.SaveFile(doc.InnerXml);
 6 
 7 // 请求 Web Service 端的服务
 8 // 在Service Provider 端:
 9 
10 XmlDocument xmldoc = new XmlDocument();
11 xmldoc.LoadXml(CommodityXml);
View Code

  可以看到,在 Visual.NET 中避免了客户端 Post 和 Get 的选择,因为在 SOAP 协议中传输的都是统一的 XML 文档;而且Web Service 端的服务可以被多个 Service Requester 端调用,降低了系统的维护代价,这样在以后开发类似系统的时候,Web Service 部分就可以进行重用。
  就内部机制而言,通过使用 Web Service 技术,使得数据收集的嵌入代码能够方便地适应各种需要使用该平台的软件,能够方便地兼容各种平台的软件。同时,通过利用开放的 Web Service 接入,可以将该平台部署在 Internet 上,为软件的广大使用者提供 Bug 和性能参数的反馈,帮助软件开发商即时和准确的修正软件错误,调整软件性能。



此文仅供自己参考

转载于:https://www.cnblogs.com/zgyskc/p/5039661.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值