基于.Net的第三方物流系统设计与实现

本栏目责任编辑：谢媛媛　ｔ　ｔ　开发研究与设计技术ｔ　基于．Ｎｅｔ的第三方物流系统设计与实现　方加来　（国防科技大学，湖南长沙４１００７３）　摘要：基于三层结构和ｗｅｂ服务的基础上，设计和实现了一个第三方物流系统。讨论了如何应用设计模式提高系统的可扩展性。　关键词：三层结构：Ｗｅｂ服务：设计模式　　。中图法分类号：ＴＰ３１９　文献标识码：Ａ　文章编号：１００９—３０４４（２００７）０９—２０７４７—０１　、　Ｄｅｓｉｇｎ　ａｎｄ　Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　ｏｆ　Ｔｈｉｒｄ　Ｐａｄｙ　Ｌｏｇｉｓｔｉｃｓ　Ｓｙｓｔｅｍ　Ｂａｓｅｄ　ｏｎ．Ｎｅｔ　ＦＡＮＧ　Ｊｉａ—ｌａｉ　（Ｎａｔｉｏｎａｌ　Ｕｎｉｖｅｒｓｉｔｙ　ｏｆＤｅｆｅｎｓｅ　Ｔｅｃｈｎｏｌｏｇｙ，Ｃｈａｎｇｓｈａ　４１００７３，Ｃｈｉｎａ）　　，Ａｂｓｔｒａｃｔ：Ｄｅｓｉｇｎ　ａｎｄ　ｉｍｐｌｅｍｅｎｔ　ａ　ｔｈｉｒｄ　ｐａｒｔｙ　ｌｏｇｉｓｔｉｃｓ　ａｐｐｌｉｃａｔｉｏｎ　ｓｙｓｔｅｍ　ｂａｓｅｄ　ｏｎ　ｔｈｒｅｅ—ｔｉｅｒ　ａｒｃｈｉｔｅｃｔＵｒｅ　ａｎｄ　ｗｅｂ　ｓｅｒｖｉｃｅｓ．Ｄｉｓｃｕｓｓ　ａｂｏｕｔ　ｈｏｗ　ｔＯ　ｉｍｐｒｏｖｅ　ｅｘｔｅｎｓｉｂｉｌｉｔｙ　ｏｆ　ｔｈｅ　ａｐｐｌｉｃａｉｔｏｎ　ｓｙｓｔｅｍ　ｗｉｔｈ　ｄｅｓｉｇｎ　ｐａｔｔｅｒｎ　ｔｅｃｈｎｏｌｏｇｉｅｓ．　Ｋｅｙ　ｗｏｒｄｓ：Ｔｈｒｅｅ－Ｔｉｅｒ　ａｒｃｈｉｔｅｃｔｕｒｅ；Ｗｅｂ　Ｓｅｒｖｉｃｅｓ；Ｄｅｓｉｎ　ｐａｔｇｔｅｒｎ　１引言　随着网络技术的高速发展，企业内部应用系统完全可以基于　网络提供更大范围的数据共享和协同工作的能力。特别是Ｗｅｂ　Ｓｅｒｖｉｃｅｓ的出现，更让系统间的互操作性得到了前所未有的提升。　数据集中存储方便共享，有利于不同模块或系统间基于数据的协　同工作。本文讨论了如何结合Ｗｉｎｄｏｗｓ客户端的强大界面展现能　力和三层结构的服务器端处理能力，设计和实现一个符合第三方　物流企业发展需要的物流信息管理系统。　必须尽可能地减少对服务器端的访问。可以在应用界面层完成的　业务逻辑校验就在客户端处理而不发送服务器请求，例如用户输　入的两个日期的大小关系。这些前端校验逻辑相对稳定，抽象成　专门前端逻辑层来处理，有利于由于用户需求变化而需要改变ＵＩ　界面控件时的代码重用。　２．１．２服务接口层　２系统总体架构的设计　２．１物流系统整体架构设计　本文描述的物流系统总体上遵循三层结构的设计原则。表示　层由客户端计算机和运行在客户端的Ｗｉｎｄｏｗｓ　Ａｐｐｌｉｃａｔｉｏｎ应用　程序组成，用于提供功能强大的物流系统操作界面。为提供更大　基于Ｗｅｂ　Ｓｅｒｖｉｃｅｓ提供统一的接口接收应用界面层的服务　请求。同时提供系统级别的通用服务，例如：用户认证，权限检查，　事务处理，审计处理等。用户登陆后，系统创建一个会话。每次客　户端提交新的请求时。都必须附带传递此次会话ＩＤ。只有已建立　会话的用户才能执行其他服务请求。服务接口层调用服务前，还　必须检验用户是否有请求此服务的权限，满足权限要求时才真正　调用对应服务程序。　２．１．３业务逻辑层　范围的数据共享和协同工作，系统采用集中式数据库结构。基于　业务逻辑共享原则和数据安全考虑。客户端应用程序不能直接访　问数据库。只能通过访问业务逻辑层提供的服务间接访问中心数　据库。业务逻辑层由应用服务器和运行在此服务器上的Ｗｅｂ　Ｓｅｒｖｉｃｅｓ服务程序构成，通过Ｗｅｂ　Ｓｅｒｖｉｃｅｓ提供开放的服务。　基于系统可扩展性可维护性的需要。在总体上遵循三层结构　的同时，我们把表示层细分为界面展现层和前端逻辑层．把业务　逻辑层细分为控制层，实体层和数据访问层。下面分别进行说明。　ｆ＆　§擅¨嶷　§　ｇ　精　控制层：提供面向服务的接口。每个接口处理不同的业务逻　辑规则。并分别调用实体层对象进行数据加工。系统绝大部分的　业务逻辑在这层实现。　实体层：业务实体的对象化。为控制层提供清晰的业务实体对象。　简单的实体往往跟数据库实体相对应，复杂的实体可能由多个数　据库实体组合而成。．　数据访问层：有时候也称为是持久层，其功能主要是负责数　据库的访问。简单的说法就是实现对数据表的Ｓｅｌｅｃｔ，Ｉｎｓｅｒｔ，Ｕｐ．　ｄａｔｅ．Ｄｅｌｅｔｅ的操作。如果要加入ＯＲＭ的元素，那么就会包括对象　冒　腔　寓博《　缸　＊翔瑶　（——　＃　自　％　Ⅱ　ｓ　☆　＆　Ｉ、　ｍ　＊　壤　珙　雷　ｎ　ｆａＨｔ　Ｉｑ　＊《　图１　系统整体框架图　＊锋　Ｉ　＃　瓣　ｉｄ　辇　避　禳　Ｆ　Ｌ＝ｊ　和数据表之间的ｍａｐｐｉｎｇ，以及对象实体的持久化。　所有的客户端都不能直接访问数据库服务器，充分保证了数　据的安全。只有应用服务器可以访问数据库服务器，它提供各种　商业应用逻辑服务。客户端访问系统的唯一途径是通过应用服务　器间访问数据库服务器，这保证了系统数据的完整性、准确性与　统一性。　考虑到全球性航运物流应用系统的实施复杂性，设计过程中　２．１．１表现层　界面展现层：采用Ｗｉｎｄｏｗｓ　Ａｐｐｌｉｃａｔｉｏｎ提供各种功能强大的　ＵＩ界面控件，例如可分组排序的表格控件，可进行联想输入的选　择控件。客户端提供的联想控件在提供功能强大数据联想输入功　能的同时．又不能无限制的从服务器端获取大量的数据进行联想　匹配。考虑网络流量问题，联想控件在居于分页技术的基础上，通　过一定的算法来进行数据缓存．从而提供给客户方便的联想输入　功能又不占用大量的网络流量。　前端逻辑层：为提高用户响应速度，同时降低网络流量，我们　收稿日期：２００７－０４－１０　非常注重数据库支持的多样性。在实际的应用过程中，一方面我　们有义务根据客户的实际情况推荐合适的数据库管理系统；另一　方面客户有权利根据自己的具体情况，如企业ｒｒ发展战略、企业　以前使用的数据库管理系统、企业未来发展的规模预计等，选择　自己认为合适的数据库管理系统。因此，在应用开发框架的设计　过程中，很有必要采用数据库隔离技术，以适应客户对采用不同　数据库管理系统的需要。　从上图我们可以看出，通过多层抽象，所有业务操作请求最　终只在数据库访问层转变成数据库操作指令，其它逻辑抽象层中　（下转第７８３页）　作者简介：方加来（１９７６一），男，福建漳州人，工程硕士，研究方向：计算机应用。　７４７　维普资讯 http://www.cqvip.com

本栏目责任编辑：谢媛媛　ｆ４）对审计服务器进行配置的函数。　３．３逐个加入其他功能块　开发研究与设计技术　时，它将该操作相关信息（用户域名，用户名，客体域名，客体名，　访问方式名）组织成一个信息包，并发送给访问控制服务器的访　问控制过程以判断该访问是否允许。如果不允许，直接返回一个　由于其他模块与访问控制过程本身没有直接的关系，属于访　问控制功能的辅助模块，其加入过程如下：　１１在数据库中创建相应的表　２１编写操作该表的函数　提示信息给用户，否则将操作请求转发给真正的执行者。　４结束语　　‘基于角色的访问控制代理是一种灵活、有效和安全的访问控　制策略，它可以根据企业和客户的不同特点，建立不同的角色关　３１将表名在客体表中进行登记　４１将函数中实现的功能（即允许对表进行的操作）抽象化为访问方　式．并在访问方式表中进行登记。　５）将３），４）中的新增数据组织成权限，登记到权限表中　６）将５）中新增的权限分配给某一角色（即登记到角色权限分　配表），现在拥有相应角色的用户都可以在下次登录时使用该权　限。　系和操作权限集，既可以管理内部用户、也可以管理远程用户，大　大地方便了系统的管理，为访问控制的安全性提供了很好的途　径。　参考文献：　『１］Ｒｏｌｅ—Ｂａｓｅｄ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ　ｂｙ　Ｄａｖｉｄ　Ｆ．　Ｆｅｒｒａｉｏｌｏ，Ｄ．　Ｒｉｃｈａｒｄ　Ｋｕｈｎ　ａｎｄ　Ｒａｍａｓｗａｍｙ　Ｃｈａｎｄｒａｍｏｕｌｉ　ｆＭ１，２００３．　『２１Ｍ　Ｊ　Ｍｏｙｅｒ，Ｍ　Ａｈａｍａｄ　Ｇｅｎｅｒａｌｉｚｅｄ　ｒｏｌｅ—ｂａｓｅｄ　ａｃｃｅｓｓ　ｃｏｎｔｒｏ１　．３．４服务器实现方案　现实现一个系统服务进程，由该进程完成数据库的启动、连　Ｉｎ：Ｐｒｏｃ　ｏｆ　ｔｈｅ　２１ｓｔ　ｉｎｔ’ｌ　Ｃｏｎｆ　ｏｎ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ｃｏｍｐｕｔｉｎｇ　Ｓｙｓ￣ｍｓ．　接、环境创建工作，并在７６８０端口进行监听客户端的访问控制请　求　这部分涉及到ｗｉｎＳｏｃｋｅｔ编程与ｗｉｎｄｏｗｓ系统服务编程两部分　知识。　３．５系统活动监视器　Ｐｈｏｅｎｉｘ：ＩＥＥＥ　Ｃｏｍｐｕｔｅｒ　Ｓｏｃｉｅｔｙ，２００１，３９１—３９８　ｆ３１乔颖，须德，戴周忠．一种基于角色访问控制（ＲＢＡＣ）的新模　型及其实现机制『ＪＪ．计算机研究与发展，２０００，３７（１）：３７—４４．　ｆ４］李孟珂，余祥宣．基于角色的访问控制技术及应用［Ｊ】．计算　机应用研究，２０００，ｌ７（１０）：４４２４７．　系统活动监视器是工作于ｗｉｎｄｏｗｓ平台的客户端程序，它需　要有能力监视用户的相关操作，当用户需要执行某种敏感操作　（上接第７４７页）　Ｌｏｇｏｕｔ．Ｒｕｎ方法分别处理用户登录，用户退出和执行用户请求服　务。服务接口层还实现了对简单的事务处理和操作审计的支持。　都不与具体数据库发生关系。而在数据库访问层中，通过配置文　件，可以自动找到相应的数据库驱动程序，将数据库映射和访问　请求转化为具体的数据库指令。　ｆ　ｉ　—　一　丽　～：　：一　一：　：一　一　Ｊ一＂－＇Ａ　数据库潍目屡　霸溶羼　控甫９璎　舅［＝｝羹接口层　坦耀群　最　图２数据访问层抽象结构　３系统的实现　第三方物流管理系统实现的是对各种物流服务的管理，包括　海运出口．海运进口，空运出口，空运进口，仓储配送，报关报检，　陆运服务等。物流服务涵盖的范围广环节多，以海运出口为例，就　图３　系统调用关系图　３．３　Ｐｒｏｘｙ的设计与实现　Ｐｒｏｘｖ是客户端调用服务接口层的代理类。它提供的调用方　法经过严格系统的测试。使用Ｐｒｏｘｙ统一管理客户端对服务接口　层的调用．很大程度上杜绝了开发过程中人为失误引起的程序错　误。　３．３　Ｆａｃｔｏｙ的设计与实现　ｒ包括如下环节：接受客户委托，订舱确认，货物出运，签发提单，运　费确认，结算。每个业务环节还有若干个业务规则，这些业务规则　对应着向客户端应用程序开放的服务。业务逻辑层必须提供统一　的调用接口，保持应用界面层和业务逻辑层的接口简单的同时，　有利于在系统实现时加人身份验证和权限检查等系统级别的功　能　另外，并不是所有的物流企业都需要用得全部的子系统，应考　虑尽量降低各子系统之问的耦合度．有利于部署时根据客户需求　只部署必须的子系统。　为了解决上述问题，本系统提出了利用Ｆａｃａｄｅ（外观）模式为　系统建立统一的接口．利用Ａｂｓｔｒａｃｔ　Ｆａｃｔｏｒｙ（抽象工厂）模式创建　依赖对象的接口从而降低耦合度，利用Ｐｒｏｘｙ（代理）模式来简化　应用客户端对业务逻辑层的访问。　３．１整体结构设计　Ｂｕｓｉｎｅｓｓ　Ｆａｃａｄｅ是业务逻辑层的唯一人口，客户端调用业务　逻辑层时必须通过参数指定调用业务逻辑层的服务名称和对应　参数。客户端使用标准的接口调用服务接口层，此工作完全交给　Ｆａｃｔｏｒｙ根据客户端的调用参数结合服务器端的配置文件，实　例化对应的业务逻辑层控制类，并调用对应的方法。当不同物流　企业对于同一业务控制类有不同的处理逻辑时，可以通过编写新　的控制类并修改服务器端配置文件的方法快速的适应这种变化　的需求。同时，使用Ｆａｃｔｏｒｙ实例化业务逻辑层控制类的做法大大　曰囝　降低了子系统之间的耦合度。　４结束语　三层结构和Ｗｅｂ　Ｓｅｒｖｉｃｅｓ已经在企业信息化过程中获得了　广泛的应用，成为开发新的软件系统的首选方式。本文在三层结　构和Ｗｅｂ　ＳｅｒｖｉｃｅＳ的基础上，利用先进的模块化设计思想，设计　和实现了基于．Ｎｅｔ的物流应用系统。系统引入了Ｆａｃａｄｅ（外观），　Ｐｒｏｘｖ（代理）和Ａｂａｓｔｒａｃｔ　Ｆａｃｔｏｙ（抽象工厂）的设计模式，使得系　ｒ统具有更大的可扩展性和可复用性。　客户端的Ｐｒｏｘｙ来处理。服务接口层根据客户端的调用参数，使用　Ｆａｃｔｏｒｙ对象根据配置信息来实例化实际的业务逻辑控制类。如图　３所示。　参考文献：　『１］Ｊｅｆｒｅｙ　Ｒｉｃｈｔｅｒ．框架设计（第２版）：ＣＬＲ　Ｖｉａ　Ｃ＃（Ｍ】．北京：清　华大学出版社，２００６．　『２］Ｇａｍｍａ　Ｅｒｉｃｈ。Ｈｅｌｍ　Ｒｉｃｈａｒｄ，Ｊｏｈｎｓｏｎ　Ｒａｌｐｈ．设计模式［Ｍ】．　北京：清华大学出版社，２００２．　『３ＩＤａｌｖｉ　Ｄｉｎａｒ，Ｇｒａｙ　Ｊｏｅ．Ｎｅｔ　ＸＭＬ高级编程【Ｍ】．北京：清华大　学出版社．２００２．　３．２　Ｂｕｓｉｎｅｓｓ　Ｆａｃａｄｅ的设计与实现　Ｂｕｉｓｎｅｓｓ　Ｆａｃａｅ通过部署在Ｗｅｂ　Ｓｅｒｄｖｉｃｅｓ上提供对外的统一　接口。所有的客户端请求都通过Ｂｕｓｉｎｅｓｓ　Ｆａｃａｄｅ接口访问业务逻　辑层，系统通过在Ｂｕｓｉｎｅｓｓ　Ｆａ？ａｄｅ中加入身份认证和权限检查很　容易就实现了具有用户的权限控制。Ｂｕｓｉｎｅｓｓ　Ｆａｃａｄｅ通过Ｌｏｇｉｎ，