互联网协同运输管理系统 需求分析说明书v20.doc

互联网协同运输管理系统需求分析说明书v2.0浙江汇智科技有限公司2007年8月18目 录一、项目背景31、问题的提出32、解决方法53、项目可行性64、开发内容8二、系统整体架构91、系统架构92、关键技术解决12三、开发功能211、运营支持系统212、业务应用系统243、客户服务系统33互联网协同运输管理系统需求分析说明书v2.0 2007/8/18一、项目背景1、问题的提出中国经济连续二十几年高速增长，GDP也已经翻了2翻以上，2006年更达到前所未有的亿元，其中全国社会物流总额达59.6万亿元，物流业增加值为1.41万亿元，宏观环境形势喜人，物流产业蕴藏着巨大商机。伴随中国经济高速增长的物流业，也于二十世纪九十年代在中华大地如火如荼地发展起来，进入二十一世纪，物流业发展迎来了黄金时期，进入了发展加速时期。面对国内物流大发展，仿佛中国已经跨入现代物流先进国家行列，果真如此吗？划分传统物流与现代物流主要标志是察看物流信息化程度，现代物流依托于现代经济，而现代社会却是信息社会，产业托起物流是定论，现代物流即建立在信息技术基础上，传统物流即传统货运建立在信息化程度不高的前工业社会，所以信息化便成了传统物流与现代物流的分界点。现代经济社会物资流通目的为了产生增值及增值服务，根据客户需求使得产品产生空间上位移，从而使得产品得到增值。物流便应运而生，依托于现代信息技术，物流除满足客户需要获取一定利润报酬，物流还为客户提供多功能、多角度增值服务，如信息、配送、包装、流通加工、产品回收再利用等，中国物流亦因此模式而生。现代物流依托于信息技术，没有高度发达的信息技术，就不能称真正意义上的物流，因为发达的信息技术依赖公司的管理水准、公司理念，反映出公司的人员素质，同时决定公司服务水准，最后便在物流集成上显真功夫。横览中国物流企业，在2001年在册物流企业有60万之众，如今有百万之众，都列为第三方物流，内质比较能称上合格的第三方物流企业为数不超百家，究其原因在于信息化深入程度决定物流企业服务水准高低，从而将绝大部分物流企业拒之于第三方物流企业门外，称为准第三方物流。中国的第三方物流企业形态上像第三方，内核上却在从事传统货运、运输、仓储等低等业务，根本无法从事集成工作，如VMI、分货架式配送、JIT或CRP传统物流公司无法做到。中国物流企业则表现为“散、乱、差、小、低”，即网点散、管理混乱、服务质量差、规模小、服务层次低，因而当下提供的物流服务比较有限，主要集中在分销物流，担负着运输、仓储、配送三种功能，兼些在途包装功能，属于简单、低级、无附加值的服务，如供应物流、生产物流及目前国家大力加强环保即将形成市场的废品回收再利用物流均无物流企业涉猎其中，所以极大欠缺信息、流通加工、包装、运输仓储配送一体化、咨询服务、物流集成等功能。诚然如此，然而社会物流需求未降反升，物流需求方不仅为农产品、企业、商贸、政府，目前更多迹象表明民间物流需求已形成巨大洪流，推动着物流业前行，很多快递及物流企业开始介入民间物流市场，瓜分这一市场。民间物流需方多是家庭、个体、个人，是弱势群体，他们因货量少、发货频次低、交易额小等因素，使他们陌生供方市场，与供方市场隔离开来，经常因很多物流企业不诚信使他们吃哑巴亏，投诉无门。如何甄选合格供应商、以公道价格发货、保证双方交易安全等等，便是民间物流需求方向业界、社会、政府发出最强烈的呼声。再则，少部分物流企业有自己的信息系统，由于当初开发时未考虑到今后扩展及与上下游客户的对接，无法实现从ECR-EOS-QR-VMI-JIT/VMI，通过EDI进入企业ERP系统过程信息系统自动转变，所以不能给上下游企业提供增值链上服务和附加值服务。同时国内物流软件品牌比较分散，技术上也缺乏标准化知道，软件供应商对于物流业的了解还不很深入，造成供应商重技术开发，轻业务应用的偏向。不仅使好多功能束之高阁，或不适用于物流企业，还使得不同物流软件间很难实现数据对接，更难言数据交互。所以说，面对这样的客户需求，为解决供应链上的如何更加快速有效的将发货人（供应商）的产品运到接受人，势必对承运商(或第三方物流公司)提出了更高要求，若还是采用传统的方法与手段，根本就不能满足实际的需求了。那么，我们总结一下，传统运输存在哪些问题呢？（1）经营分散和企业的集约化，规模化程度较低（2）服务质量问题较为严重（3）运输组织与经营技术以及理念落后（4）运输装备和设施落后（5）政策导向不明确和政府管理方式与手段不适应发展的需要（6）信息技术手段落后，无法实现协同工作2、解决方法因此，传统物流必须提升管理、更新观念、转变政府管理方式、形成现代传统运输。有鉴于此，新华物流网络有限公司提出了基于下一代互联网技术，第四方物流提供ASP平台技术软件构想，开发“物流电子商务及互联网SCM平台”，简称“一网两台”，利用物流电子商务平台给供需上方创造盈利机会，通过互联网SCM平台实现物流服务，达到节能、增效目的。 “一网两台”中“一网”指新华物流网，“两台”指物流电子商务平台和互联网SCM平台(即互联网供应链管理平台)。供需双方通过物流电子商务发布各自商务讯息，寻找物流合作伙伴，进行商务沟通，完成第一次商务后的现金交割（由第三方管理现金），实现物流过程（即物体发生空间位移），给需方售后服务，及事后彼此信用评判，服务完成后费用转移。其中亮点将目前流行的KPI考核体系网络化，用公共信息栏形式向所有物流供需方公开，让供需方信用度曝光于网络公共平台，让民意监督行业行风，迫使供方和需方改进工作，努力提高服务水平，从而促进整个行业的诚信度不断提高。在多次完成合作任务后，供方和需方将慎重选择那些诚信度高，能力强的企业作为自己的供方和客户，不断累积，做长合作链，完成甄选任务，进入结盟状态的互联网SCM平台。另外，在能确保供应链长期稳定和有效性假设前提后，建立供应链模型，确立业务发生模式，选择业务功能，如CRM、运输管理、仓储管理、配送管理、包装、流通加工、装卸搬运和信息功能，通过业务发生模式带动控制模式的启动，从而实现诸如ECREOSQRVMIJIT/CRP等诸多技术，满足更多客户要求。“一网两台”优点明显：通过平台为物流供应商提供费用低廉、功能强大、不断升级版物流管理系统，解决中小物流企业信息化程度低的问题。通过伙伴的加入，消除面向单个企业物流管理软件不能进行数据交互的障碍，顺利实施不同网点、不同物流企业间网络协同，产生网络化联动，实现网络化、规模化运作。运用集成技术集成物流各系统，利用数据共享优点顺利实现各模块间数据交互，使得界面更加友好，工作量大为减轻。强势企业介入组建供应链，不但能保持供应链长期稳定，能平衡各方利益，还规模化运作，推动产业链优化，发挥强集聚效应。利用电子商务平台，为供需方提供交流场所，整合资源，减少交易成本，社会效应明显；通过第三方担保使交易更加安全，保证供需方利益；诚信体系建立，推动企业加快建立诚信步伐，也迫使各方提高管理水平和服务质量，以确保企业信用。3、项目可行性新华物流网络有限公司提出了基于下一代互联网技术，第四方物流提供ASP平台技术软件构想，开发“物流电子商务及互联网SCM平台”是具有很强的现实意义与社会效益的。在管理、技术、经济效益与社会效益方面都是可行的。1）、从物流管理角度看项目可行性我们已建立和掌握运输的最佳实践，最佳运输实践对于供应链的无缝连接起到非常重要的作用。最佳运输实践主要指良好的运输控制和集中运输管理；建立一个核心运输计划；制订正确合同条款；撰写运输状态报告并使订单、运输可视化；不断改进运作程序；实施准确的货物成本配置和成本报告；进行运输成本分析等。电子商务平台的成员之间对共同利益的理解将进一步提高，保证一定的开放性，进行信息共享，供应链各方认识到互联网协同运输管理是供应链活动中的重要部分，成员之间遇到问题相互帮助，相互理解，工作努力并相互协调，进行合作；相互信任，利益共享等。2）、从信息技术角度看项目可行性互联网协同运输的成功离不开先进的信息技术，它可以保证数据传输真实，减少交易成本和风险。信息技术是互联网协同运输管理的神经系统，对于提高运输运作效率，保证了资金、物资和信息的高效有序流动和交互起着至关重要的作用。而互联网技术、软件技术、数据库技术等已非常成熟，目前WEB2.0应用已经进入人们的日常生活。开发基于互联网的SCM管理平台，技术时机已经成熟。3）、从社会效益与经济效益看项目可行性2006年全国社会物流总额达59.6万亿元，物流业增加值为1.41万亿元，从这里可以看出，物流业的巨大商机。若是此电子商务平台与SCM管理平台研发成功，必将是物流业的一个典范，他将对物流行业产生深远的影响，因为在些平台上可以实现多方协作，资源共享，改善服务质量，规范管理，降低运输成本，提升客户满意度等等好处，社会效益明显。新华物流的“一网二台”是一个电子商务平台，也是一个SCM管理平台，若是运输、物流企业能体会到此网，能给自己带来管理上规范，服务能力的提升，成本的下降，那么必将带来物流业管理的革命，就会体会到使用此平台带来的各种好处，那么，新华物流网络也将在这个平台租用中，收到可观的经济效益。可以简单做个估算，若是全国的10%的物流公司能租用这个平台，新华物流网络公司将获得丰厚的回报。4）、可能存在的主要障碍互联网协同运输管理在实际运作上可能会遇到困难，并可能会经常运作实施效果不理想或运作失败。其主要的障碍包括传统管理思想和体制的禁锢，仍采用传统的方法运作和进行成本核算；成员之间对供应链的视野仍停留在自己一方，而没有从供应链整体看待；每次谈判过程要花大量时间和经历，因此供应链各方过于注重各自利益或对互联网协同运输管理的预期期望过大，信息传递的不准确等。总之，互联网协同运输管理无论从技术、从管理、从实践角度都是可以实现的，作为供应链运输管理中的一种崭新的思想，若供应链中的各方建立一种“共赢”的合作伙伴关系，站在供应链战略的高度实施互联网协同运输管理的话，一定能获得成功。我们相信这种能降低整个供应链成本的先进的管理思想与管理手段，一定也必将成为现代物流的主要管理手段。4、开发内容1)、本项目全部完成分四个阶段第一阶段形成面向从事物流业的专业运输公司、货代公司及个体户的TMS系统（即互联网协同运输管理系统）。第二阶段形成面向社会资源优化配置的电子商务交易系统。第三阶段形成面向生产制造业、商贸企业以及从事物流的供应商的供应链管理系统。第四阶段将电子商务交易平台与供应链管理平台结合，形成一网两台。2)、目前的开发工作互联网协同运输管理系统应涵盖基本表单（统计台帐）、报表、订单管理、车辆调度、运价管理、车辆在途跟踪、回单管理、账款结算等运输中全面涉及数据方面的工作和自有车辆档案管理及会员管理。3)、功能要约基本操作功能：软件实现的操作层面基本功能要求有基本数据录入、添加、查询、删除、修改、保存、打印、更新、统计。实现功能：软件实现运营，管理层面以及创新功能要求数据库共享、硬件共享、数据独享，解决离线、在线同步数据保存及传输问题，嵌入交互式聊天工具，网点互动的网络协同，及时通信及短信功能。二、系统整体架构互联网协同运输管理系统为服务商提供对外业务服务、对外业务管理、对外业务监控等功能；为服务商提供面向其最终用户的访问基础平台：因此互联网协同运输管理系统需要提供以下服务： 完善的用户认证管理，保证系统的安全、可靠； 负载均衡管理，有效保证运营效率； 用户管理: 对用户的基本信息，用户的业务订购等进行管理； 产品和服务管理:提供业务申请、业务审批、业务开通、业务信息查询等； 计费结算: 提供计费、结算，方便业务的灵活开展； 提供高安全性：实现信息交换与共享的同时保证各系统中的信息的安全； 提供基于工作流的协同管理 提供基于Web的营业支撑与管理系统； 良好的扩展性； 数据管理、备份、维护 提供离线版1、系统架构保证互联网协同运输管理系统有效运营效率，必须首先解决用户认证及资源负载均衡问题。从职责角度，1台服务器担任平台共享的“用户数据库服务器”（即中心数据服务器），负责存储所有用户的个人资料；而其它服务器则承担了“认证服务器”、“监控服务器”、“短信服务器”、 “即时通讯服务器”、“WEB应用服务器”和“数据库服务器”等6类不同的工作。所示图如下：25互联网协同运输管理系统主要有三种角色用户平台运营商：负责平台的运营与维护，为服务实施商和最终客户提供周到的服务。服务实施商：负责服务实施的整体管理。最终客户：提交服务请求并获取需要的服务。说明：1）、平台运营商、服务实施商(承运商或第三方物流公司)、客户，提交自己的帐号、密码及验证码，认证服务器开始验证该帐号、密码、验证码的有效性，如果确认信息无误，则系统进入资源分配服务。2）、资源分配服务器根据短信服务器群、即时通讯服务器群、WEB服务器群、数据库服务器（包括数据库帐号）的当前资源占用情况或配置情况，分配指定服务器资源。3）、根据RBAC模型中所描述的，根据该帐号在业务系统中的角色与权限读取相应的功能模块。4）、一旦帐号退出业务系统，系统自动调用资源收回服务，释放服务器资源。如果帐号没有正常退出或长时间没有业务操作情况，系统也自动调用资源收回服务，释放服务器资源。2、关键技术解决(一)从软件角度看，单数据源和多数据源的问题，下面我们来看看实现方法和各自的利弊（1）、单数据源A 单库多表型：数据库服务器上有一个数据库；1、对于每个用户各自的信息都会有其单独的表集合；例如：用户A的单据信息表为（Table_A），则用户B的单据信息表为（Table_B）；2、数据库中会有相应的公共表，来实现信息的共享；优点：这样的操作的优点是每个用户都有自己单独的表，它们能共享数据源或连接池，效率更高，提高数据的访问速度,能更好的结合离线公办,同时数据安全方面也能相应的增强； 同时也可以通过共用的表来存放共享信息，和其他客户（用户）进行数据的通讯，从而使得功能实现和资源得到更好的结合，使得系统在相同的条件下达到最大最好的功能；缺点：在编程实现的时候可能会相应的复杂些；某个客户在访问他自己私有的信息时,系统要从某个表取得相应的信息,来判断他应该来访问哪个表；B 单库单表型：所有客户的数据都存放在一个数据库的同一套表中， 在部分表中增加标示字段，表明该记录是属于哪个客户的。具体哪些表中要增加标示字段当然要看具体的需求，不过大部分表示实体对象的表中都需要加。在很多查询条件中都需要包括这个标示字段。即使是用户自定义的查询，系统也需要在查询条件中加入该字段；优点：编程操作上相应会简单，系统不需要分析当前用户应该要访问哪个表,在数据库源的管理上也会相应的简单些；缺点：在数据库的处理和数据安全方面不如”单库多表型”；按照这样的设计, 很多数据表都需要加入客户表示字段，很多查询都需要包括该字段，会比较麻烦。如果有遗漏，特别是查询条件中遗漏该字段，就会造成一个客户看到另一个客户的数据。另外，需要在系统的安全性方面做比较细致的设计。比如，某个功能通过在URL中包含某个实体的关键字以查询该实体的信息，或对该实体进行操作。在普通应用中后台只需要根据关键字查出该实体即可。但是在Web应用中，就必须额外判定该实体是否属于当前登录用户，或者要在查询中条件中加入客户标示；（2）、多数据源这个方法和”单库多表型”的操作思想基本上是一致,就是系统有多个库，其中某个库是共用的，存放一些公用的信息；然后为每个客户建立一个数据库，来存放其独立的信息；优点：不同客户的数据物理分离，安全性比较好。除了获取数据库连接部分的程序以外，其它程序和普通应用没有两样。不同客户的数据可以放置在不同的数据库服务器中，分担数据库服务器的负荷, 能提高数据的访问速度。缺点：在编程实现的时候可能会相应的复杂些；同时一个数据库服务器上搭建很多数据库会增加数据库服务器的负担，降低其性能；数据库连接的利用效率不高。在系统这边来说，则是数据源或连接池很多，但每一个的利用效率都不高。在数据库服务器这边仍然会有很多连接，因为每个数据源或连接池都需要保持一定数量的可用连接。这样通过连接池共享数据库连接而减少总连接数的好处被大大削弱了；另外如果需要增加客户时，需要在应用服务器中配制新的数据源，或者修改应用自己的数据库连接池配制。某些情况下可能无法作到在应用不中断的情况下使这些配制生效。结论：库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块或用户对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。(二) 对单条记录的并发问题的处理方法。业务逻辑的实现过程中，往往需要保证数据访问的排他性。如在金融系统的日终结算处理中，我们希望针对某个 cut-off 时间点的数据进行处理，而不希望在结算进行过程中（可能是几秒种，也可能是几个小时），数据再发生变化。1）、并发概率现在市面上针对PC机的软件开发，主要以两种结构为主：一种为C/S结构；一种为B/S结构。而两种结构各有利弊，在这里就不详细描述。这里主要就其使用方式进行说明一下，两种结构都针对用户进行实现的，用户登陆后再根据其权限、角色进行相关的可执行操作。WEB程序的访问量是相当大的，这可能也是客户主要考虑并发性的因素。下面就该问题进行描述。用户注册并确定审核后，即成为平台的正式使用者，用户的注册信息都将被保存，并根据注册情况分配相应的角色及权限。用户登录后，可发布修改删除的个人信息、发布修改删除自己的公共信息等，WEB网站上的信息均是某个用户进行发布的（不包括后台管理信息），这些信息是不允许其他用户进行修改、删除的。后台管理用户只可对记录的非信息部分进行编辑操作，如审核、删除等。2）、并发的可能情况：A、不同用户对于同一条记录的操作如：前台用户读出并开始修改自己的发布信息但还没有提交，后台的管理用户觉得该条被前台用户已经打开的信息有问题而在后台进行了审核删除操作，当前台用户进行提交他的修改时，将会获得“您的该条信息已被删除”相似的信息；如果前台用户对该条记录进行修改提交，而同时后台管理用户对该条记录进行删除提交，在WEB网站上看是同时的，但最终都将反应到数据库里，如果反应到数据库里有先后顺序，一种情况是修改失败、删除成功，一种情况是修改成功、删除成功；如果反应到数据库里也是同时，数据库会根据其内部的冲突处理机制进行辨别谁先谁后，从而最终的结果将是一样的刚才描述的两种情况。这里说明一点：对于前台用户发布的信息，前台用户所编辑的字段与后台用户所编辑的字段总是不一样的，以保证用户信息的自主性及权利。否则将影响网站的使用。B、 同用户或者说具有相同某条记录操作权限的用户对于同一条记录的操作如：有一条记录，某用户A在前台打开该记录并进行操作，同时用户B在前台亦打开该记录并进行操作，并同时进行提交。当然我们会在用户的设置上进行一些处理，但如果是业务需要并一定会具有这种情况发生的时候。与第一点具有相同的处理机制，同样在前台是同时提交的，反应到数据库里，如果有先后顺序，将根据顺序处理，处理的结果将被反应至前台；如果数据库里也是同时到达，数据库会根据其内部机制进行辨别操作，亦是同样的结果。3）、可行的方案我们就需要通过一些机制来处理单条数据并发的问题，即在某个操作过程中有些数据不会被外界修改。这样的机制，在这里，也就是所谓的“锁”，即给我们选定的目标数据上锁，使其无法被其他程序修改。通常来讲，锁可以分为两种：悲观锁(Pessimistic Locking）和乐观锁(Optimistic Locking)。悲观锁(Pessimistic Locking) 悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能 真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。 一个典型的倚赖数据库的悲观锁调用： select * from account where name=Erica for update 这条 sql 语句锁定了 account 表中所有符合检索条件(name=Erica)的记录。 本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录，所有的修改请求将等待直到事务提交或回滚。而在Oracle中有for update nowait关键字，当发现数据被别的session for update nowait锁定中的时候，就会迅速返回ORA-00054错误，内容是资源正忙, 但指定以 NOWAIT 方式获取资源。所以在程序中我们可以采用nowait方式迅速判断当前数据是否被锁定中，如果锁定中的话，就要采取相应的业务措施进行处理。乐观锁(Optimistic Locking)对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本(Version)记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个version字段来实现。相读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。 1 操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50 （ $100-$50 ）。 2 在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。 3 操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。 4 操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为2，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。 这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A的操作结果的可能。从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员 A 和操作员 B 操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。结论总之，介绍了数据库的锁定机制，究竟是悲观锁好还是乐观锁好，其实也是不一定的，跟开发的技术、应用的场景和具体的需求都有关系。在Oracle中悲观锁还是很不错的，而且从开始的时候就把数据锁定。免除了后面的很多冲突处理。不过悲观锁需要保持一个Oracle连接，在我们常见的B/S应用中，特别是数据先取得，然后让用户再更新，再返回提交这种流程来说，悲观锁是不大可能的。首先是因为B/S应用中，一般是利用一个连接池，在两次Http Request请求都是不同的数据库Connection。而且也不能锁定一个数据太长时间，否则人人都这么锁定，应用很容易进入死锁状态，这个时候就要采用乐观锁了。(三) 多用户的角色及权限的实现方法。用户的角色及权限的控制需要根据项目的实际情况和具体架构来定，在维护性、灵活性、完整性等N 多个方案之间比较权衡，选择符合的方案。对于在企业环境中的访问控制方法，一般有三种： 1、自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLS)。 2、强制型访问控制方法。用于多层次安全级别的军事应用。 3、基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。 根据本项目的特点，优先选用基于角色的用户访问控制(RBAC)。访问控制系统可以为应用系统建立一个高安全强度， 更易维护管理， 扩展能力极强的访问控制环境，并能够有效的控制管理的复杂性，提供标准化和可以不断延伸授权平台。访问控制系统的体系结构设计保证了用户能按照应用规模和数量快速地建立访问控制体系。 完全基于策略思想设计的权限管理控制系统作为构建访问控制体系的基石， 它能使用户已建立的访问控制体系不断满足演化的应用权限需求，如支持新应用、支持新的权限、增加用户数量、增加用户类型、增加策略数量等。本系统在用户访问控制管理中将引入角色的概念， 即在系统中提供若干个角色，每个角色的权限可以任意定制，在每一个角色下可以包含若干个用户，用户只能够使用本角色允许使用的系统功能，对用户无权使用的系统功能可以设置其状态为不可见或隐藏。管理员可以首先分配好各个角色的权限，然后将系统的用户分配到各个不同角色中，即可以完成用户权限的设定，而不用逐个的去设定用户的使用权限。角色的概念 在现实生活中经常提到某人扮演了什么角色。在基于用户角色的用户权限管理中，角色与实际的角色概念有所不同。在这里角色可以看作是一组操作的集合，不同的角色具有不同的操作集，这些操作有系统管理员分配给角色。用户的授权是通过授予用户一个角色来实现的，即赋予用户一个角色，一个用户可以承担不同的角色，从而实现授权的灵活性。只要某用户属于某个角色那么他就具备这个角色的所有操作许可，即该角色所拥有的权限。用户与角色是多对多的关系。即一个用户可以属于多个角色之中，一个角色可以包括多个用户。RBAC模型构件分析 图 RBAC 模型我们对该模型定义如下： U，R， P，S：用户；角色，权限，会话； PAP*R：权限分配，多对多的关系； UAU*R：用户分配，多对多关系； User:S-U,每一个会话 s 对应单一用户 user(s)的映射； Roles:会话 s 到角色集合role(s) r|(user(s),r)PA 显而易见：该模型由三个实体组成，分别是：用户（U）、角色（R）、权限(P)。其中用户指自然人；角色就是组织内部一件工作的功能或工作的头衔，表示该角色成员所授予的职责的许可，系统中拥有权限的用户可以执行相应的操作。 用户与角色之间以及角色与权限之间用双双箭头相连表示用户角色分配 UA和角色权限分配 PA关系都是多对多的关系，即一个用户可以拥有多个角色，一个角色也可被多个用户所拥有。同样的，一个角色拥有多个权限，一个权限能被多个角色所拥有。用户建立会话从而对资源进行存取，每个会话 S 将一个用户与他所对应的角色集中的一部分建立映射关系，这个角色会话子集称为会话激活的角色集。于是，在这次会话中，用户可以执行的操作就是该会话激活的角色集对应的权限所允许的操作。RBAC特点及应用优势 RBAC几大特点 （1）访问权限与角色相关联，不同的角色有不同的权限。用户以什么样的角色对资源进行访问，决定了用户拥有的权限以及可执行何种操作。 （2）角色继承。角色之间可能有互相重叠的职责和权力，属于不同角色的用户可能需要执行一些相同的操作。RBAC 采用角色继承的概念，如角色 2 继承角色 1，那么管理员在定义角色 2时就可以只设定不同于角色1 的属性及访问权限，避免了重复定义。 （3）最小权限原则，即指用户所拥有的权力不能超过他执行工作时所需的权限。实现最小特权原则，需要分清用户的工作职责，确定完成该工作的最小权限集，然后把用户限制在这个权限结合的范围之内。一定的角色就确定了其工作职责，而角色所能完成的事物蕴涵了其完成工作所需的最小权限。 用户要访问信息首先必须具有相应的角色， 用户无法饶过角色直接访问信息。 （4）职责分离。一般职责分离有两种方式：静态和动态。 （5）角色容量。在一个特定的时间段内，有一些角色只能有一定人数的用户占用。在创建新的角色时应该指定角色的容量。 RBAC应用优势最突出的优点在于系统管理员能够按照不同的安全政策划分不同的角色，执行特定的任务。一个系统建立起来后主要的管理工作即为授权或取消用户的角色。 用户的职责变化时只需要改变角色即可改变其权限；当组织功能变化或演进时，则只需删除角色的旧功能，增加新功能，或定义新角色，而不必更新每一个用户的权限设置。这极大的简化了授权管理，使对信息资源的访问控制能更好地适应特定单位的安全策略。 RBAC 另一优势体现在为系统管理员提供了一种比较抽象的、 与企业通常业务管理性类 似的访问控制层次。通过定义、建立不同的角色、角色的继承关系、角色之间的联系以及相 应的限制、管理员可动态或静态地规范用户的行为。在本项目中，各个功能模块中的操作可以定义为各个独立的权限集合中的元素，于是各个模块其实就成了各自独立的权限集合，平台超级管理员可以预先定义好包含不同权限集合的用户角色，比如平台超级管理员可以将平台上公共信息平台的添加、删除、修改和查询等权限赋予平台公共信息管理员这个角色；而在平台上租用应用服务的公司的管理员用户角色就拥有对公司部门的订制权限，下属用户帐号的管理操作权限等等。系统中的各级管理员就可以将预先定义好的用户角色再分配各自的下级用户帐号，比如下订单员工的帐号就赋予下订单的系统角色，分管信息的帐号就分配以信息管理员的角色。这里不同的帐号也可以分配相同的用户角色以方便完成任务，上级的管理员则是拥有下属用户的所有角色权限。这样通过基于角色的访问控制（RBAC）实现本平台中多用户角色权限的访问控制。一个安全的网络需要可靠的访问控制作保障。在网络规模变大、用户增多、需求更复杂 的情况下，传统的访问控制已经不能满足许多企业或组织的安全需要，基于角色的访问控制（RBAC）便明显地显示出其优越性。基于角色的访问控制可以很好的解决资源库项目的访问控制，为系统开发提供了一套有力的工具，还为用户评估系统提供了标准。(四) 关于大型应用平台高并发量的技术处理。负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。 负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，根据我们接触过的一些解决方法，其中有两个架构可以选择。硬件四层交换 第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。第四层交换功能就象是虚IP，指向物理服务器。这些业务在物理服务器基础上，需要复杂的载量平衡算法。这种硬件投入费用很高因此我们不提倡。软件交换 知道了硬件四层交换机的原理，软件交换也就应运而生，它的解决方案实现的原理一致。通过配置表及相关的服务（实时收集必要的信息）选择合适的服务器来处理业务，同时提供了灵活的配置和管理功能，可以同时满足多种应用需求，这对于平台的扩展性及分布式的系统来说必不可少。因此我们建议用软件交换方式，并已设计相应算法。(五) 互联网协同运输管理系统中主要解决以下几种协同1、运单协同：“协同方”协同过来的“协同运单”，自动转入业务应用系统中的“运单管理”模块。2、车辆跟踪协同：协同给“协同方”的“协同运单”的跟踪信息、货损货差情况，自动输入业务应用系统中的“车辆跟踪”管理及“货损货差”管理模块。3、财务结算协同：协同双方发生的财务情况，自动输入协同双方“财务结算”管理模块。4、短信系统和即时通迅软件为协同双方的沟通进一步提供了方便。要协方 受协方三、开发功能在介绍功能之前，先说明以下几点：a、数据还原（针对业务应用平台）在业务操作过程中，数据之间有一定的关链性。因此在数据还原功能上受一定的限制。如“运单管理”中的“运单协同”模块，当运单向协同方发出协同申请，如果协同方接受该协同之后，则该运单不能进行还原操作。该功能直接体现在操作界面上。b、 “查询”子模块在所有界面上有涉及到查询功能的，我们统一调用“复合查询”子模块，进行查询条件的设置，提交“完成确定”按钮进行查询操作。c、 功能菜单”调用在运营支持系统和业务应用系统中，操作人员的“功能菜单”根据该用户的角色情况进行配置与优化。d、 基本操作在运营支持系统和业务应用系统中，如果没有特珠说明，则提供的基本操作有：“添加”、“修改”、“删除”、“查询”、“部分导出”、“全部导出”、“还原”等操作功能。从使用平台的三种角色出发，互联网协同运输管理系统主要有三个系统组成。1、运营支持系统(一)、操作对象：运营支持系统的使用对象是平台运营商。(二)、功能模块1、用户角色管理；根据运营商的业务需求来划分角色，并指定相应的权限。角色有：平台管理角色(最高角色)+定义的角色。操作功能：基本操作。2、用户帐号权限管理；根据用户在运营支持系统中所管理的业务，给定相应的角色。操作功能：基本操作。3、会员管理；l 会员在线注册：用户通过运营支持系统的在线申请，提交真实信息。l 会员审核：运营商通过对这些信息的真实性情况进行调查，如果确认信息无误，则开通使用。l 会员信息管理：运营商对会员(会员公司)的基本信息进行管理。操作功能：“修改”、“删除”、“停用”、“查询”、“部分导出”、“全部导出”、“还原”等操作。l 会员业务查看：运营商对会员(会员公司)的业务情况进行查看。对会员经营情况的查看过程与操作自己业务的情况一致，主要区别是只能查看，不能对其进行数据的更新。l 会员密码初始化：运营商对会员的密码进行初始化。该工作主要在会员忘记了密码且需要我们初始化的情况下进行。操作功能： 密码初始化。l 会员子网点配置：运营商根据会员(会员公司)提交的申请，对会员(会员公司)的网点情况进行配置，最终体现在运营商对会员的收费情况，另一方面是会员(会员公司)对子网点经营情况的查看。对子网点经营情况的查看过程与操作自己业务的情况一致，主要区别是只能查看，不能对其进行数据的更新。操作功能：基本操作。l 会员业务角色查看：运营商可以查看会员(公司)业务角色配置情况。l 业务帐号权限查看：运营商可以查看会员(会员公司)业务帐号的权限。l 会员组管理：运营商为了方便对会员(会员公司)进行管理，根据一定的性质对会员(会员公司)进行分类，方便分析与管理，如发短信。操作功能：基本操作。4、短信管理；l 发送短信：运营商发送相关信息给会员(会员公司)，如交会员费用、系统升级等。操作功能：“发送”。l 历史短信：运营商可以查看单位短信发送情况，方便对短信费用的情况进行了解，便于分析与管理。操作功能：“查询”、“部分导出”、“全部导出”。l 短信余额：运营商可以查看单位短信余额情况，便于及时充值。5、即时通讯；l 好友管理：好友管理是为即时通讯服务的。提供了双方及时交流的方便。运营商的好友来源于会员帐号及自己添加的会员(会员公司)业务帐号。操作功能：基本操作。6、交流沟通系统；l 交流信息管理：运营商可以管理会员或客户提交的信息，及时了解相关情况。操作功能：基本操作。l 回复信息：运营商可以根据会员或客户提交的信息进行回复操作。操作功能：“回复”。l 审核发布：运营商根据会员(包括客户)提交的信息情况进行整理，然后发布到会员的业务应用系统中，方便用户查看。操作功能：“发布”。l 栏目管理：交流沟通系统根据实际运营中的情况开辟多个栏目，方便对信息的分类管理。操作功能：基本操作。7、费用管理；l 费用提醒：针对运营商主要有两种费用的提醒。第一种是会员费用到期提醒、第二种是短信费用预交提醒。这两种费用的提醒也分别在业务应该系统及即时通讯中体现（针对运营支持系统中的会员帐号）。操作功能：查询、部分导出、全部导出操作。l 历史费用：查看所有会员上交的会员费用及短信费用。l 费用充值：指会员费用或短信预交费用的充值。操作功能：基本操作。l 短信余额：查看会员短信余额情况，方便及时通知或进行充值。8、会员帐号；l 帐号信息：运营商帐号可以查看自己的帐号情况。操作功能：“修改”、“还原”。l 修改密码：运营商帐号可以修改自己的密码。操作功能：“修改”。9、基础数据维护；l 默认业务角色定义：运营商定义默认业务角色，并指定相应的权限，会员可以根据自己的业务需要重新调整角色。操作功能：基本操作。l 费用计算公式：目前运营支持系统主要有两种会员：第一种是物流公司，第二种社会车辆。因此会员费用也有所不同。一、 如果会员在平台上没有子网点且是物流公司，则他的会员费用是一个基础金额。二、 如果会员在平台上没有子网点且是社会车辆，则他的会员费用也是一个基础金额，但金额与物流公司所交金额是不一样。三、 如果该会员在平台上有子网点，则他的会员费用为：会员费=基础金额+子网点数*基数。操作功能：“修改”、“还原”。10、基础数据维护；l 自动备份设置：运营商通过定义策略或通过服务程序在指定的时间内自动备份数据库。l 数据库备份：运营商进入运营支持系统随时对数据库进行备份。操作功能：“备份”、“删除”。l 数据库还原：如果运营平台的数据库遭到人为的破坏，运营商则通过“数据库还原”功能，把数据库恢复到正确数据的某一时刻。操作功能：“还原数据库”。2、业务应用系统(一)、操作对象：业务应该系统的使用对象是服务实施商（承运商或第三方物流公司）。(二)、业务流程： (三)、功能模块： 1、业务角色管理；根据会员(会员公司)的业务需求来划分业务角色，并指定相应的权限。业务角色有：单位管理角色(会员最高角色)+定义的角色。操作功能：基本操作。2、业务帐号权限管理；根据用户在业务应用系统中所起的作用及工作职责，给定相应的业务角色。操作功能：基本操作。3、业务管理；(一)、运单管理1、 运单管理运单管理：运单管理是服务实施商管理运单及运单货物明细的地方。这里特别要说明一下的是，为了增加系统的安全，在帐号处理上我们提供了假帐号机制，保证真实数据的外漏。根据运单来源，把运单分为以下三种。操作功能：“添加”、“修改”、“删除”、“查询”、“部分导出”、“全部导出”、“还原”、“添加线路”、“发送协同”、“接受协同”、“确定承运” 、“运单导入”。1)、合同客户运单合同客户运单是与服务实施商有业务往来，而达成一致协议的运单。该客户的相关资料保存在平台中，由该服务实施商进行管理。2)、非合同客户运单非合同客户运单是与服务实施商临时有业务往来客户的运单。该客户的相关资料没有保存在平台中。3)、平台协同运单平台协同运单是平台上另一服务实施商发达过来的运单。服务实施商在接受协同方发过来的“平台协同运单”时，“平台协同运单”的信息及货物明细情况自动转入运单管理中。2、 运单分理在运输过程中存在短驳和中转等情况，因此对运单要进行分理操作。这里要特别提一下的是，事实上在运单管理中添加路线的时候就已经对运单进行分理，操作者只须对其作一些相应的数据补充即可。操作功能：“添加”、“修改”、“删除”、“查询”、“部分导出”、“全部导出”、“还原”、“添加线路”、发送协同“、“接受协同”、“确定承运”。在下面中所提到的运单也就是分理运单，两者没什么实质性区别。3、 运单协同在对运单进行分理后，马上要确定协同方或承运方，如果对方确定协同或承运，则进行确认操作。操作功能：“添加”、“修改”、“删除”、“查询”、“部分导出”、“全部导出”、“还原”、“添加线路”、“发送协同”、“接受协同”、“确定承运”。协同方的确定操作：我们(A方)向接受方(B方)发送运单协同时，我们的状态为“已发送”，如果接受方选择了“同意”协同，则我们的状态为“已确定”，这时确定“协同方”工作完成。承运方的确定操作：我们 (A方)打电话向承运商(B方)，详细讲述运单承运信息（或发传真等方式），如果承运商接受运单的承运，则该运单改为“已确定”，这时确定“承运方”工作完成。(二)、虚拟配车1、 虚拟配车运单在确定“协同方或承运方”后开始进行虚拟配车，虚拟配车将分理后的运单安排到虚拟的车辆上。（如果确认的是协同方式，则不需要“虚拟配车”）。虚拟配车主要记录虚拟配车上的货物、价格、承运商、车牌等信息，如果信息正确且承运方确认承运，则把虚拟配车的状态改为“配载确定”状态，虚拟配车工作完成。操作功能：“添加”、“修改”、“删除”、“查询”、“部分