联网售票（共6篇）
联网售票 篇1
引言
随着城市轨道交通运营里程的不断增加和运营水平的日益提高, 乘客搭乘城市轨道交通出行享受到越来越便捷的出行服务。但同时也存在着车厢拥挤、换乘站换乘路线长以及购票充值不便等多种问题。为了缓解乘客购票充值进站“排长队”的问题, 文章提出了一种基于互联网的地铁售票方案。
1传统的地铁售票方案
1.1传统的自动售检票系统
自动售检票系统 (Auto Fare Collection, AFC) , 是集计算机技术、信息收集和处理技术、机械制造于一体的自动化售票、检票系统, 具有很强的智能化功能。实现轨道交通售票、检票、计费、收费、统计、清分、管理等全过程的自动处理。AFC系统主要由线网级清分系统 (ACC) 、中央级AFC系统 (LC) 、车站级AFC系统 (SC) 、车站终端设备和车票五部分组成。其中终端设备包括有车站计算机, 自动售票机, 闸机, 票房售票机, 验票机, 手持验票机等。AFC的系统组成部分及核心设备如图1所示。
1.2 AFC系统面临的问题
依照传统现有的售票方式存在着大量现金交易带来的困扰, 主要表现在三个方面: (1) 对乘客而言:高峰期间在自动售票机排队购票, 同时自动售票机还进行储值卡的充值操作, 这样对使用单程票的乘客而言, 时间成本高, 影响乘客的购票体验。再者结合实际地铁车站的建筑结构, 出现排长队的情形严重影响到正常的客流组织。 (2) 对运营方而言:日益增长的客流也加重了终端设备的保养维护工作量, 补币更换硬币钱箱过程费时费力, 时常还会遇到纸币卡币等设备故障, 频繁的处理故障也会严重影响乘客购票, 站厅乘客聚集越多也就需要更多的工作人员来辅助乘客分流, 引导乘客使用设备, 这样固然导致成本的提升。 (3) 从财务方面看, 在现金安全纸币、硬币钱箱更换移动中, 存在安全隐患故障;设备维修费用持续升高, 尤其是硬币模块的故障率升高。
2互联网售票的方案研究
2.1互联网售票方案概述
鉴于当前AFC系统面临的种种问题, 基于互联网的售票方案也渐渐地被推广, 互联网售票的方案是原有AFC系统不变, “二维码兑票系统”和“NFC手机刷卡系统”是叠加在原有系统上的子系统, 且需要分开独立建设。互联网售票方案系统结构图如图2所示。
二维码兑票系统的连接:二维码兑票服务器一端通过地铁内网连接ACC, 一端通过防火墙接入到广域网中与手机连接实现购票。在车站内布设的兑票机通过内网接入SC, 纳入车站设备统一管理中, 车站外布设的兑票机通过广域网直接连接兑票服务器。通过普通手机完成购票和支付, 并利用手机上生成的二维码, 到兑票机上扫码取票, 然后刷票乘车。
NFC手机刷卡的系统连接:NFC应用服务器一端通过地铁内网连接ACC, 一端通过防火墙接入到广域网中与手机连接实现空中购票和充次。同时, 通过专线连接第三方TSM平台, 完成在虚拟卡下载过程中SE的安全密钥操作。
2.2二维码兑票子功能
二维码技术诞生于20世纪40年代初, 但得到实际应用和迅速发展还是在近20年间已广泛应用于各类二维码应用系统。
2.2.1二维码兑票子功能的功能描述。二维码兑票功能的主要功能包括:按站点地图购票、按票价购票、数据管理、报表管理。乘客可在城市轨道交通线路站点图上选择起点站和终点站查询票价并完成购票预付, 产生车票兑换二维码;支持支付宝和微信支付等主流支付方式。乘客也可指定固定面额票价完成购票预付, 产生车票兑换二维码。订单查询、订单退款、取票记录查询、数据管理的功能描述为售卡交易数据上传、参数数据下载等;兑票系统每日对售卡交易和兑票记录进行统计结算, 并与ACC之间完成每日对账。
2.2.2关键流程。购票和兑票流程:乘客首先需使用支付宝、微信等互联网手段进行支付, 在手机上生成兑票二维码再通过兑票机换取实体单程票。购票流程如图3所示, 兑票流程如图4所示。
2.3 NFC手机刷卡子功能
2.3.1系统功能。NFC手机刷卡的主要功能有空中购票、空中充次 (可选) 、刷手机乘车、账户管理、数据管理、日结及对账管理和报表管理。乘客可按照起点站和终点站购票, 也可以通过指定固定面额票价购票, 将车票直接下载到手机中。支持支付宝和微信等。空中充次是对于地铁可售卖的计次类型的票卡, 乘客可直接使用手机对已经下载到手机中的“虚拟卡”进行充次操作。
2.3.2关键流程。购票流程:拥有NFC手机乘客的购票流程, 如图5所示。
2.3.3关键技术。NFC是Near Field Communication缩写, 即近距离无线通讯技术。NFC手机的普及也大大改变了大多数乘客的乘坐习惯。NFC手机是指带有NFC模块的手机。NFC手机可以做很多相应的应用。主要由三种应用模式, 它们分别是:卡模式、NFC模式或者点对点模式、读卡器模式;这三种工作模式适用于不同的应用场景。本方案主要使用的是卡模式。
3结束语
文章介绍了传统的地铁售票系统, 并提出了一种基于互联网的地铁售票方案, 文中着重介绍了二维码兑票和NFC刷卡。随着智能设备的快速普及, 在既有线路以及未来建设的地铁线路中的效果应该会体现出来, 目前广州、深圳等城市都展开了试点。这将是一个探索的过程, 在管理上还存在一定的探讨空间, 需进一步共同探讨第三方支付互联网进入地铁的可靠性, 制定更完善、更贴近现场实际情况的管理制度来规范整个线路的管理, 保证设备收益安全, 保证设备正常运行。
参考文献
[1]赵时.轨道交通自动售检票系统[M].同济大学出版社.
[2]邓先平, 陈凤敏.我国城市轨道交通AFC系统的现状及发展[J].都市快轨交通, 2005, 18 (3) .
[3]李宇轩.轨道交通票务清分体系的建设[J].都市快轨交通, 2007, 20 (1) .
[4]吴春波.AFC半自动售票机软件构架设计与实现[D].东华大学, 2010.
[5]王国光.自动售检票系统及关键技术研究[Z].铁道部科学研究院, 2005.
[6]高朝晖, 夏德传, 张宁, 等.轨道交通网络化AFC系统票务管理分析[J].现代城市轨道交通, 2008 (3) .
[7]Yufang ZHANG.Real-Time Database Programming of AFC System-Implementation in New York City Transit System[A].第六届交通运输领域国际学术会议论文集 (上卷) [C].2006.
联网售票 篇2
票？
在互联网购买儿童票时，可以使用同行成年人的有效身份证件信息，也可以用乘车儿童本人的有效身份证件信息。
除使用儿童本人二代居民身份证购票且乘车站、下车站都具备二代居民身份证检票条件，可以使用二代居民身份证直接通过车站自动检票机（闸机）检票进出站外，其他情形都必须在购票后、乘车前换取纸质车票。
使用同行成年人或儿童本人有效身份证件信息购买儿童票的，须提供该同行成年人或儿童本人的有效身份证件原件和订单号码；如儿童未办理居民身份证，而使用居民户口簿所载儿童的身份证号码购买儿童票的，可将居民户口簿原件或车站铁路公安制证口开具的临时身份证明作为有效身份证件，凭以换票。
联网售票 篇3
1 联网售票系统建设模式
1.1 建设资金来源
我国各省 (市、自治区) 联网售票系统建设资金主要分为三类:政府投资、客运企业或客运站投资、第三方企业投资。
1.2 系统部署模式
目前, 全国各省市不同程度地开展了道路客运联网售票系统建设, 对道路客运联网售票有一定甚至比较深入的认识和理解, 各省市及客运企业建设的联网售票系统在票务信息资源整合上, 采用的方式主要有四种:集中式、分布式、集中分布式和分布集中式。联网售票系统建设方案比较如表1所示。
集中式架构是依托网络技术, 业务数据集中管理, 应用系统集中建设, 构建全省统一的联网售票中心, 实现客运票源的集中管理和全省联网售票。集中架构对系统运行、维护和结算及多元化售票均非常有利, 但对网络要求较高。
分布式是票务信息分布式的存储在联网各客运站自身的数据库服务器中。各站售票服务器在网络上是平等, 相互没有依存关系, 最大限度的保证客运站的售票业务操作。但对于其他站售本站票, 会造成多用户同时连接本站数据库, 出现一对多连接的情况, 会影响本站售票系统性能, 适用于联网车站售票系统多样化改造不方便或难度较大的场合, 是目前用得比较多的整合方式, 但不适合多元化售票发展。
集中分布式是信息集中存储的同时也在客运站本地存储, 不因网络中断而影响本站售票业务, 多元化售票时代售点只与集中数据库相连, 不影响车站售票系统性能, 但对数据同步、信息比对要求高, 适用于同城联网或运输企业自身联网售票, 对网络通信要求高。
分布集中式是票务信息以车站分布式存储为主, 定期或不定期的将数据向中心数据库汇聚, 最大限度保证车站售票业务, 对数据统计、分析应用有利。但对数据同步、信息比对要求高, 集中数据库信息难以与车站数据库信息实时保持一致, 影响多元化售票发票。适用于以数据统计和分析应用为主要目的、联网售票量小的场合。比较适用于全自治区或全国联网售票。
1.3 项目建设管理
我国各省市联网售票系统建设管理主要分为三类:政府主导模式、政府引导、企业参与模式、市场化建设模式。
联网售票系统建设作为服务百姓的民生工程, 前期建设投入大, 回收周期长, 盈利空间小, 因此, 部分省份采用政府主导投资建设模式, 为公众出行提供更便捷的服务。
随着联网售票区域的扩展和百姓对联网售票的认可, 客运企业逐步认识到联网售票的优势, 积极支持建设联网售票系统。但系统前期投资数额较大、建设周期长、市场培育周期长、协调单位多, 一般企业很难承担如此长的回收周期。因此, 一般前期由政府协调各客运企业, 并提供部分引导资金, 进行全省联网售票系统建设。
目前, 也有部分省份采用完全市场化运营方式, 由企业负责联网售票系统的建设、维护, 一般需要在政府的监管下, 与客运企业签订系统服务协议, 通过站外售票代理费、结算手续费、广告权等收益作为主要盈利手段。
2 联网售票系统总体框架
目前, 全国各省的联网售票系统工程总体框架主要包括九个方面:基础设施层、硬件支撑层、数据资源层、应用支撑层、应用系统层、应用展现层、接口层、用户层和三大保障体系, 如图1所示。
(1) 基础设施层。基础设施层为本次工程建设提供配套的物理场所, 主要包括各省道路客运联网售票服务中心、机房建设等。
(2) 硬件支撑层。网络平台为数据资源层、应用系统层等在网络传输方面提供支撑服务, 并实现各客运信息的采集、整合、处理、分析和展现;主机及存储设备是系统运行的基础硬件系统;安全系统在已有的管理体系基础上, 完善技术体系和新建运维管理体系, 加强系统安全水平, 实现对建设的应用系统、网络系统、数据资源等进行全面的安全管理。
(3) 数据资源层。数据资源层是通过道路客运信息交换系统, 对现有客运业务数据和行业管理基础数据进行整合的基础上, 产生的基础库、业务库、主题库。三种类型数据库在数据管控体系的统一管理下, 通过对道路客运信息资源进行科学的分类组织, 采用统一的建设规范和数据交换标准, 确保信息资源在采集、处理、传输, 以及分析、管理和共享的整个流程中在各系统间顺利地交换, 以实现知识管理和决策支持的目标。数据资源层为各类应用系统的应用开发提供了数据支撑。
(4) 应用支撑层。应用支撑层为本次工程的各应用系统提供基础的、共同的应用支撑, 包括数据库管理系统、服务器操作系统、数据交换系统、应用服务器中间件、备份软件、统一权限管理平台、短信息平台等。
(5) 应用系统层。在数据资源层的基础之上, 通过对公众出行服务、企业经营和行业监管的需求进行深入分析, 基于先进的技术架构, 设计开发本次工程各类应用系统。开发客运站站务管理系统、业务管理系统、清分结算系统、客运信息监管系统等。
(6) 应用展现层。通过互联网网站、手机应用客户端、自助售票机、咨询电话、PC应用终端、代理售票点客户端、自助检票机及自助查询机等, 为公众出行提供信息和票务服务。
(7) 接口层。接口层包括统一客运信息服务接口、现有站务系统接口、外部系统接口和预留接口。统一客运信息服务接口主要实现客运数据同步与票务服务接口, 现有站务联网售票接口主要用于对现有站务系统接入联网售票系统平台, 外部系统接口主要实现联网售票系统与其他业务系统的数据交换与共享, 预留接口则为满足未来应用需求所预留接口。
(8) 用户层。主要包括五大类用户:行业管理部门、客运站、运输企业、社会公众和系统的运营机构。
(9) 三大保障体系。三大保障体系包括信息安全保障体系、标准规范保障体系、建设与运营保障体系。三大保障体系是本工程顺利建设与运行的必要条件。
3 联网售票系统功能
省域道路客运联网售票系统旨在实现异地售票、联程售票和公众信息服务, 提供统一渠道售票接口, 以及互联网、电话、代理点、自助终端和移动终端等多种订购票渠道, 方便民众出行、提高运行效率和行业监管水平, 应用先进的信息技术实现各省道路客运联动管理、决策支持和旅客出行一体化服务, 因此, 应具备以下功能模块:
(1) 数据交换管理功能模块。数据交换管理功能模块是联网售票系统进行数据交换共享的基础平台, 通过对省域客运信息资源的汇聚与管理, 形成全省道路客运联网售票数据中心。客运信息交换系统应根据交通运输部制定的数据交换标准制订统一的接口规范, 实现联网售票数据中心与客运企业、客运站以及其他业务系统间的数据交换共享。
(2) 业务管理功能模块。业务管理功能模块主要用于管理、控制和协调各类联网售票机构, 对外提供统一、可管理的联网售票服务, 为各省道路客运联网售票系统的其他管理功能提供统一监管与支撑服务。
(3) 售票服务功能模块。售票服务功能模块服务于出行公众, 各省可根据实际情况提供网络售票、代售点售票、自助终端售票、智能终端售票及电话售票等多元化的售票服务。
(4) 清分结算功能模块。清分结算功能模块是根据各省实际情况, 统一为客运站、客运企业、代售点等各参与单位提供联网售票票款的清分结算功能, 实现站站结算、站与第三方代售 (或运营) 机构的结算。清分结算功能模块一般涵盖客运经营企业、客运站、业户、代理售票点、第三方电子支付运营商、网银、保险公司等实体间的多点结算;支持公路客运市县内部同城异地、省内多级联网结算方式;支持结算周期、资费水平的动态设定;支持结算结果通过银行直接汇入相关实体账户。通过模块应用实现自动化的票务结算, 达到结算的实时性、准确性, 为各类实体之间的经营往来提供直接的技术支撑。
(5) 客运信息监测功能模块。客运信息监测功能模块主要服务各级行业管理部门, 用于真实反映全省道路客运行业的服务质量和效率, 加强对全省客运行业发展情况以及发展趋势的掌握, 实现对班线、车辆、驾驶员、经营业户以及客运站等的有效监管, 以道路客运数据中心数据资源为基础, 以大数据挖掘技术为手段, 为科学决策提供支持。
4 发展趋势
通过区域性客运联网售票系统的建设, 可以最大限度地提高公路客运体系运行效率, 实现公路行业的计算机统一管理, 基本实现职能部门对客运站的科学化管理[7,8], 同时促进各客运站经营管理的信息化、现代化, 大大降低企业的经营成本, 在为旅客提供优质服务的同时也给客运站带来可观的经济效益[9]。
随着省级联网售票中心建设与行业及应用体系的构建, 有效整合道路客运行业的基础信息与动态信息, 形成全国数据中心, 并基于全国数据中心构建网上售票服务体系和行业经济运行分析体系将成为未来发展的趋势。
摘要：近年来, 各省纷纷启动道路客运联网售票系统工程建设, 旨在利用计算机技术、互联网技术等, 有效整合省域客运基础信息与动态信息, 实现票务资源的开放共享, 丰富多元化售票方式, 更好发挥工程对公众出行、企业运营、行业监管的支撑作用。本文从建设模式、总体框架和系统功能三个方面, 对目前部分省市道路客运联网售票系统进行总结分析, 对正在建设或规划建设道路客运联网售票系统的省份有一定借鉴意义。
关键词：联网售票,建设模式,总体架构,系统功能
参考文献
[1]陈兴彪.客运线路改制, 促集约化经营[J].中国道路运输, 2000. (07)
[2]高卓民.辽宁省客运联网售票系统的技术实现[D].大连海事大学, 2012
[3]道路运输业“十二五”发展规划纲要.交通运输部, 2011.11
[4]公路水路交通运输信息化“十二五”发展规划 (交规划发[2011]192号文印发) .交通运输部.
[5]公路水路交通运输信息化“十二五”发展规划推进方案 (厅规划字[2012]12号文印发) .交通运输部
[6]省域道路客运联网售票系统工程建设指南, 2014.5
[7]曹雨.对客运管理信息化建设的思考[J].城市建设理论研究, 2012. (02)
[8]姜桦.运输车辆调度优化的研究和实现[J].物流与采购研究, 2008 (36)
汽车客运站售票员售票操作规范 篇4
1.售票前准备工作
（1）正确放置告知牌；（2）零钱摆放有序；
（3）启动计算机售票系统，输入本人工作代码，核对票号；（4）熟练地将客票装入打印机；
（5）检查售票显示和柜台对讲系统是否工作正常；（6）检查桌面摆放是否整齐。2.售票时操作规范
（1）移开告知牌，放置隐蔽处。
（2）售票时，当收到旅客票款后，应放在桌面上，完成本次售票，旅客离开窗口后，将票款放进抽屉。
（3）客票打印清晰，有差错时或客票撕断应重打，并及时销号。（4）抽屉内现金摆放有序。3.售票时语言规范
（1）讲普通话，语速适中，口齿清晰，语调亲切。正确合理使用“十字”文明用语。
（2）旅客来到售票窗口前，应面对旅客微笑,首问：“您好！请问到哪里？”旅客说明购票需求后，售票员应简单扼要地重复其乘车日期、时间，到达站和购票张数。
（3）旅客确认后，应告之旅客购票总金额。
（4）收取旅客票款时，应唱收进金额，并唱找零。（此时，计算机正在打印客票，售票员唱找零的同时，可把找零递给旅客）如果旅客所给票款正好时，应说一声“票款正好”。
（5）从打印机上撕下客票，眼看客票交待：“您购买的是*月*日*点*分，**站（到达站地名）、*张”。在将客票递给旅客的同时，提醒旅客到几号门检票乘车,再说一声“再见”。（6）售儿童票时，需问：“请问孩子（小孩）多高？”。
旅客回答其身高超过儿童票身高规定的，需及时告知旅客：“对不起，您的孩子（小孩）身高已超过购买儿童票规定，需购买全票。”
身高未超过儿童票身高规定的，需及时提醒旅客：“您的孩子（小孩）身高，按规定可以免票乘车，您还需购买儿童票吗？”旅客需要时。可回答：“好的”，旅客不需要购买，可回答：“谢谢”。
身高满足购买儿童票规定的，需及时告知旅客：“可以购买半票。”（7）售优待票时，需请旅客出示《残疾军人证》或《伤残人民警察证》。可简要地说：“请出示您的有关证件”。当核对无误后，在返还证件时应道一声“谢谢”。查验证件不符合购买优待票条件的，应及时告知旅客：“对不起，您的证件不符合购票规定，请购买全票。”
（8）发现疑似假币时，可说：“对不起，请您换一张。”旅客配合调换后应道一声“谢谢”。
4.突发事件处理
发生计算机故障、零钱用完等突发事件时，应及时将告知牌放置窗口，并向旅客解释。
5.售票结束后的工作
联网售票 篇5
6月5日, 交通运输部办公厅发布《关于进一步做好道路客运联网售票有关工作的通知》, 要求按照先省内服务、再全国联网的步骤, 有序推进省域道路客运联网售票系统和部级道路客运联网售票系统建设, 实现部、省两级系统联网运行。
2015年年底前, 首批27个省份的省域道路客运联网售票系统主体工程将完成建设, 包括数据交换管理系统、业务管理系统、售票服务系统、清分结算系统、客运信息监测系统等, 确保省级系统符合相关标准规范;完成部级系统主体工程建设, 确保部级系统具备与省级系统对接的基础条件。上海、广西、浙江、天津等未申报省级系统建设工程的省 (区、市) 要在今年9月底前启动建设工作, 并于2016年年底前完成省级系统建设。
2016年年底前, 全国道路客运联网售票系统将建设完成。按照成熟一个接入一个的原则, 逐步推进部、省两级系统的对接。基础条件较好、建设进度较快的省份在今年年内先行将省级系统接入部级系统, 其他省份要在2016年年底前将省级系统接入部级系统, 实现部、省两级系统的全面联网, 确保全国道路客运联网售票系统投入整体运营。
联网售票 篇6
本文以汽车客运联网售票系统为依托，在开发过程中采用中间件技术，使得系统软件架构变得灵活，可扩展性变强，同时也满足了采用分布式数据库技术实现多站点联网售票与调度的需求。
1 实现中间件的必要性
中间件能够将应用系统相对的独立于计算机软硬件平台，为大型分布式应用系统搭建起一个标准的平台，把企业分散的技术组合在一起，从而实现企业应用软件系统的集成。中间件具有标准的程序接口和协议，它可以使不同硬件和操作系统平台上分布式应用的数据共享和互操作。中间件在操作系统、网络和数据库之上，应用软件之下，总的用途是为处于自己上层的应用软件提供运行和开发环境，帮助用户灵活、高效的开发和集成复杂的应用软件。
2 中间件技术的作用
采用中间件主要可以实现两个方面的作用：一是实现应用程序与系统软件平台的无关性，企业的应用程序可以不加修改地跨平台运行;二是中间件提供了许多原本必须由应用程序实现的一些基础性功能，如：网络通信服务，数据库连接，事务控制，安全控制，负载平衡等。这样，在中间件之上开发企业的应用，许多功能可以利用中间件来实现，大大减少了程序开发量。
3 中间件的设计与实现
3.1 汽车客运联网售票系统的体系结构
联网售票调度系统、客运站售票系统，采用多层结构模式。即Application客户端+应用服务器(中间件)+数据库。
网上订票系统，采用多层应用结构模式，即浏览器+Web服务器+应用服务器(中间件)+数据库。
根据网上订票用户地域分布广的特点，并考虑到系统的扩展性，在设计时采用了Web架构，基于Internet/Intranet网络技术，按Web三层网络结构的要求，设计成一个集用户接口、WEB应用服务器、ORACLE数据库于一体的现代化的联网售票调度系统，以应对未来业务发展的需要。其架构模式如图1所示。
1)主要应用逻辑集成在中间层———应用服务器中;
2)商业逻辑和表示逻辑分离，使得商业逻辑可重用，可以支持多种客户端;
3)支持多种分布式通讯协议、提供完整的分布式服务;
4)跨平台、支持异构数据库;
5)提供连接池的功能，极大地缓解了大量客户请求造成的压力;
6)分布式事务处理;
7)完善的安全解决方案，保证企业商业秘密，保证用户网络支付的安全;
8)提供负载均衡的能力，使得企业应用能够适应企业不同规模的需要;
9)对Internet全面支持，适应于企业电子商务的需要。
3.2 站务应用接口
为了实现联网售票与调度，达到信息共享、综合利用的目标，各客运站通过“站务应用接口”实现联网售票与调度管理。
3.2.1 中心售票组件模型
票务处理相关业务的界面都部署在客户端，通过客户端的业务代表(MasterBusDelegate)与中心票务代理(MasterBusAgent)交互，完成业务处理申请并接收处理结果。
中心票务代理与本地票务代理(LocalBusProxy)和中心票务服务(MasterTicketManager)完成票务相关业务处理。
本地业务代理(LocalBusProxy)操作客运站数据库，完成相关的票务业务处理。本地业务代理的实现，通过J2EE应用服务器操作客运站数据库。
中心售票，需要保证中心、车站两个数据库数据的一致性。
3.2.2 本地售票组件模型
本地售票组件是运行在客运站客户端的组件，客运站通过使用本地售票组件完成售本站票和售异站票等相关票务处理业务。
票务处理相关业务的界面都部署在客户端，通过客户端的业务代表(LocalBusDelegate)与本地票务代理(LocalBusProxy)交互，完成业务处理申请并接收处理结果。
本地票务代理通过与本地票务服务(LocalTicketManager)完成售本站票;本地票务代理通过与本地票务服务和中心业务代理(MasterBusAgent)完成售异站票，在此过程中，中心业务代理通过调用异站票务代理完成售异站票。
客运站售异站票，需要保证本地、中心、异站三个数据库数据的一致性。
3.2.3 实现方法
结合上述原理，根据实际需要实现本地业务代理LocalBusProxy，我们将LocalBusProxy设计成一个符合EJB 2.0规范的无状态会话Bean，它包含了Bean类、Home类和远程接口类，用以实现所规定的各个方法。中心业务代理(MasterBusAgent)通过调用本地业务代理的这些方法，实现售票、退票、销票相关的票务处理。
在LocalBusProxy中通过调用中心业务代理(MasterBusAgent)的相关方法，实现异站售票。
1)建立本地业务代理(LocalBusProxy)
如前所述，LocalBusProxy是一个符合EJB2.0规范的无状态会话Bean，包含了Bean类、Home接口类和远程接口类三个类。
方法(Method):
·处理他站、售票点用户的售票请求sellTicketForMaster
·处理售票点用户的补票请求sellLateTicketForMaster
·本地记录售异站票信息completeSellTicket
·处理他站、售票点用户的退票请求returnTicketForMaster
·本地记录退异站票信息completeReturnTicket
·处理他站、售票点用户的取消退票请求cancelReturnTicketForMaster
·本地记录取消退异站票信息completeCancelReturnTicket
·处理他站、售票点用户的销票请求clearTicketForMaster
·本地记录销异站票信息completeClearTicket
·处理他站、售票点用户的取消销票请求cancelClearTicketForMaster
·本地记录取消销异站票信息completeCancelClearTicket
2)建立中心业务代理(MasterBusAgent)
MasterBusAgent也是一个符合EJB2.0规范的无状态会话Bean，包含了Bean类、Home接口类和远程接口类三个类。
中心业务代理负责处理客运站业务代理和中心客户端发出票务业务处理请求。
方法：
·处理售票点售票sellTicketForLocal
·处理退票returnTicketForLocal
·取消退票cancelReturnTicketForLocal
·销票(废票)处理clearTicketForLocal
·取消销票(废票)处理cancelClearTicketForLocal
4 结论
总的来说，中间件带给应用系统的不只是开发的简单、开发周期的缩短，也减少了系统的维护、运行和管理的工作量，还减少了计算机总体费用的投入。中间件作为新层次的基础软件，其重要作用是将不同时期、在不同操作系统上开发应用软件集成起来，彼此像一个天衣无缝的整体协调工作，这是操作系统、数据库管理系统本身做不了的。中间件的这一作用，在技术不断发展之后，使以往在应用软件上的劳动成果仍然物有所用，节约了大量的人力、财力投入。
摘要：如今计算机技术迅速发展,为了解决分布式环境问题,使得中间件技术受到人们广泛的关注。该文根据实际的引用环境,针对具体的应用系统——汽车客运联网售票系统设计和实现方案进行研究,并提出了基于中间件技术的技术方案,解决了汽车客运联网售票系统中的诸如:难以扩充、不易维护、异构环境下难以互操作等问题。
关键词：中间件技术,分布式环境,汽车客运联网售票系统
参考文献
[1]朱卫平,陈英.基于J2EE中间件技术的分布式系统建模[J].电脑知识与技术,2007(21):5-13.