中国移动渠道协同系统的设计与实现.docx
《中国移动渠道协同系统的设计与实现.docx》由会员分享，可在线阅读，更多相关《中国移动渠道协同系统的设计与实现.docx（51页珍藏版）》请在冰豆网上搜索。
中国移动渠道协同系统的设计与实现
中国移动渠道协同系统的设计与实现
近几年，相伴着电信业的迅猛进展，国内移动运营商间的竞争日趋猛烈，为了取得行业竞争优势，移动运营商们采取的重要手段之一是提高面向客户方面的服务质量。
中国移动渠道协同系统是中国移动客服系统的组成部分，客服系统旨在提高客户服务的效率和用户的中意度，渠道协同系统的服务宗旨也在于此。
渠道是中国移动面向客户进行销售和服务的载体，各种渠道的集合构成中国移动营销服务网（例如客服渠道、营业厅渠道、短信渠道、宽带渠道、无线音讯互动服务渠道、网厅渠道等）。
本文依照中国移动湖南分公司客服系统的现状分析，为了实现各个渠道之间协同工作以提高客户的感知度和中意度，设计此渠道协同系统。
本文采纳面向对象的思想，以统一建模语言为分析设计工具，对渠道协同任务处理过程中的相关业务进行详细的需求分析，依照需求和系统特点采纳标准有效的软件设计架构来完成系统需求任务。
系统的要紧功能包括业务要求接入治理、随隐秘码服务、协同调度治理、规那么治理以及流程公布。
系统采纳B／S架构模式，功能上采纳多层次的软件功能架构，技术上基于MVC基础的Spring框架，以Java为编程语言，利用XML配置以及DAO、Hibernate等相关技术实现了渠道系统之间协同工作的业务要求，渠道协同系统通过WebService方式向外部渠道系统提供服务。
本文详细描述了系统的设计过程，包括系统类结构设计和数据库设计，从各个层面展现渠道协同系统的开发研究过程。
渠道协同系统的突出特点是处理的协同业务流程复杂纷繁，分支众多，同时业务流程多变，随时有添加协同业务流程实例的需求，针对这种特点，渠道协同采纳工作流引擎技术处理业务流程，同时提供GUI配置界面，方便开发人员和非开发人员进行业务流程的公布和业务决策规那么的制定。
这种体系架构大大提高了系统处理业务流程的吞吐量和执行效率，幸免了大量逻辑判定的存在；增强了系统的可爱护性。
该系统应用后收到了良好的成效，不仅提高了移动客户服务方的客户中意度，同时全面提升了移动的品牌阻碍力，有效的坚持了老用户和争取了新用户入网，在一定程度上拓展了移动增值服务的市场。
第1章绪论
1．1系统开发背景
中国移动通信集团公司（简称〝中国移动"）于2000年4月20日成立，注册资本518亿元人民币，中国移动全资拥有中国移动（香港）集团，由其控股的中国移动（简称〝上市公司〞）在国内31个省（自治区、直辖市）和香港专门行政区设立全资子公司，并在香港和纽约上市。
目前，中国移动是中国在境外上市公司中市值最大的公司之一，也是全球市值最大的通信公司。
中国移动要紧经营移动话音、数据、IP和多媒体业务，并具有运算机互联网国际联网单位经营权和国际出入口局业务经营权。
除提供差不多话音业务外，还提供、数据、IP等多种增值业务，拥有〝全球通"、〝神州行"、〝动感地带’’等闻名客户品牌。
随着中国移动的进展壮大，对移动使用的客服系统也提出了更高的要求，逐步加大对用户的服务项目，提升移动运营商的市场价值。
目前，移动增值服务成为移动通信的新的利润增长点，要紧类型包括短消息、小区广播、WAP应用、多媒体消息和语音信箱等。
短消息业务近年来在中国进展迅速，取得惊人成绩并有望进一步拓展潜力；小区广播处于起步时期；另外，多媒体短消息服务成为热点同时正在推出。
近年来，全球各运营商在语音业务方面的竞争日趋猛烈，话音通信的利润空间日益缩小，移动通信网络的单位客户平均收益（ARPU）正在逐年下降。
ARPU的下降，意味着收益的减少和投资回收期的延长，这关于投资兴建新一代移动通信网络的运营商来说，无疑是一个挑战。
以后庞大的移动增值服务市场潜力，吸引了大量的服务提供商跳入洪流，一试身手。
现时期，移动增值服务五大类基础业务进展得如火如荼，预示着一个新的服务经济时代差不多到来，以后的体验经济时代亦杏帘在望。
究其本质，服务的核心存在形状是应用，高性价比的应用需要开放的软件系统平台承载，这将促使在以后的移动增值服务领域中，运算体系与通讯体系在无线网络环境下的完美统一。
因此，加强这些渠道的协作能力，将有力推动移动增值服务市场的进展。
中国移动渠道协同系统是中国移动客服系统的组成部分，渠道是中国移动面向客户进行销售和服务的载体，各种渠道的集合构成中国移动营销服务网（例如客服渠道、营业厅渠道、短信渠道、网厅渠道等等）。
随着移动的进展壮大，面对庞大的使用移动产品的用户群，如何更好的对在网用户进行维系和挽留，提升用户群的中意率，加强服务成效，减少失散用户群，争取竞争对手用户，需要各个渠道之间的协同工作。
因此渠道协同系统就应运而生了。
1．2研究现状
目前，中国移动各个渠道系统之间差不多上独立工作的，存在着专门多的问题。
比如在湖南地区移动服务存在着的问题：
问题一，顾客通过营销中心外呼业务介绍或者朋友介绍等途径对某项业务产生爱好，因此打给移动客服要求办理，有些业务客服系统能够直截了当办理，但有些业务只能到营业厅办理，现在客服话务员会要求客户去营业厅办理，客户到营业厅之后，营业厅人员并不明白该客户要办理什么业务，只能通过询问客户需要办理什么业务得知，如此造成客户感知专门不行，同时使得营销部门的营销成效严峻打折扣。
问题二，营销中心通过号码10086外呼向目标客户进行营销推广，或是因欠费提醒。
但因客户没有接到而未完成，客户回来看到手机上有10086来电显示，并回拨查询来电缘故（用户回拨10086直截了当连接到移动客服），客服接到后，不明白客户来电缘故（客服方面不明白营销中心外呼需要向客户推销什么），而无法给客户一个中意的答复，造成客户对客服产生负面印象，也使得营销成效大打折扣。
在营销、终端资源预约等方面也存在类似情形。
这就要求建设渠道协同系统来完善这些问题。
1．3本文的要紧工作
本文要紧对渠道协同系统的设计和实现进行描述，分析了系统开发的背景及业务场景，采纳典型的软件设计方法进行系统的设计，要紧分需求分析时期、系统架构设计、详细设计和实现几个步骤，论文对这几个时期分别进行描述，在各个环节上展现系统的设计和开发过程，对系统的技术难点即协同调度处理过程和重点功能进行了更一步的表达，更深层次的展现开发研究的过程，并通过实现部分描述系统功能实现情形。
具体内容分以下几个部分：
1、背景分析，渠道协同系统是中国移动客服系统的组成部分，渠道是中国移动面向客户进行销售和服务的载体，这部分分析了目前各个渠道系统之间没有实现协同工作的现状，由此猎取渠道协同的需求；
2、需求分析，该部分将功能性需求分为了几个部分进行详细的阐述，并通过UML建模的方式对需求进行分析描述；
3、系统设计，对渠道协同系统的软件体系架构和系统功能结构进行设计，以需求分析作为依据，将系统所采纳的技术架构和功能架构用UML包图和序列图等进行详细的描述；
4、详细设计，设计系统实现的类组织结构，分析系统业务信息以及调用关系，对业务建立实体类，并类和类之间的联系，分析业务要求信息和业务处理过程，进行数据库表设计；
5、系统实现，整合各个实现框架，通过xml配置参数，利用工作流引擎实现业务预约的流程，以及环节配置和流程公布的方法和过程。
1．4本文的组织结构
第l章绪论，第一描述了系统开发背景和研究现状，其次描述了本文的要紧工作。
第2章需求分析与猎取，第一对业务进行总体描述，其次描述本系统的目标和需要解决的问题，最后对需求分析按照功能需求和非功能需求两个类别进行描述。
第3章是系统概要设计，第一阐述了系统的软件架构设计，阐述系统所使用的技术；其次，详细描述了系统功能架构的设计。
第4章是系统的详细设计部分，要紧描述了类结构设计和数据库的详细设计。
第5章要紧描述了系统的实现和测试，针对系统实现过程中的要紧流程配置和解决的技术问题进行了阐述。
第6章总结与展望部分，对本文进行了总结，并对下一步的工作进行了展望。
第2章需求分析与猎取
2．1总体系统描述
移动用户接触的渠道有：
客服、营业厅、短信、网厅等。
渠道协同系统对用户不可见，系统外部关系图如图：
渠道协同与CRM（即营业系统）核心业务逻辑关系：
渠道协同向营业系统核心组件转发其他渠道的服务要求协同，营业系统核心业务组件处理服务要求；同时营业系统核心业务逻辑也能够向渠道协同申请其他渠道的协同处理，共同完成客户服务处理逻辑。
渠道协同与RBOSS（即账务系统）核心业务逻辑关系：
渠道协同向账务系统核心组件转发其他渠道的服务要求协同，账务系统核心业务组件处理服务要求；同时账务系统核心业务逻辑也能够向渠道协同申请其他渠道的协同处理，共同完成客户服务处理逻辑。
渠道协同与统一接口平台关系：
统一接口平台向渠道协同申请业务协同处理，渠道协同系统负责协同的拆分，转发及跟踪治理。
系统框架图如图：
系统描述：
规那么元数据治理：
规那么元数据是对协同规那么参考因素的定义，包括元数据类型定义，取值约束，取值来源等；元数据是协同处理的数据基础。
协同规那么治理：
协同规那么治理实现协同处理规那么、流程节点、动作、执行路径等相关协同策略信息的治理。
在渠道协同治理中使用工作流引擎来实现协同规那么的治理。
协同调度：
协同调度是渠道协同的执行引擎，支持异步和同步处理两种模式。
负载均衡治理：
渠道协同系统实时收集各电子渠道业务处理量和性能指标（排队量、业务处理量、处理时长）及体会负载情形分析信息进行渠道业务转发，实现跨渠道的业务负载均衡。
要求转发：
业务要求转发内容包含客户通过渠道提交的业务要求，以及营业系统中的市场营销、销售、客户服务功能域发起的业务要求。
转发的方式支持异步、同步两种处理模式。
随机服务密码治理：
随机服务密码治理功能使渠道协同系统各电子渠道和实体渠道提供的一项基础服务功能，要紧是通过快速的短信方式协助其他渠道快速猎取随隐秘码。
随隐秘码功能支持密码生成，密码验证，密码有效期治理等。
预约治理：
预约治理功能是客户通过电子渠道申请到实体渠道的预约服务。
通过与实体营业厅的排队系统的接口，可为客户提供快速业务办理通道。
业务协同治理：
业务协同治理是指将业务处理流程分解，由渠道协同负责渠道／跨渠道接触调度来完成客户服务功能；业务协同治理典型的应用有业务办理短信通知，客户二次确认等。
协同内容治理：
要紧实现服务转发或业务协同时各渠道之间的内容的转换，生成，加工等。
接口治理：
接口治理完成协同调度逻辑与相关渠道和营业系统核心业务逻辑之间的交互；交互接口要求是同步调用接口。
渠道协同总体需求如下：
1．接收各个渠道的跨渠道业务要求信息；
2．针对不同的业务要求信息进行转发或处理；
3．对业务协同流程进行监控；
4．提供同步的随隐秘码服务。
2．2系统目标和解决的问题
渠道协同系统要实现与渠道基础平台的连接，实现客户接触过程中的连接、监控、专门等治理与操纵，并依照客户或业务需要实现跨渠道的业务要求接收、拆分、发送、监控功能。
协同调度依照协同逻辑对来自各渠道和营业系统内部的协同要求进行解析、分解成各渠道的协同任务及其执行策略，并依照渠道特性对协同任务进行封装后发给渠道执行。
如以下图所示：
当一个协同任务产生时，渠道协同系统依照业务情形进行协同处理，比如业务预约那个案例，如以下图所示，渠道协同系统要达到如此的功能。
业务预约场景中，渠道协同作为一个信息记录和转发的中心，有效的将多个渠道在业务办理流程中串接起来，为实现闭环化的服务能力提供了技术可能。
另外，渠道协同系统要对协同处理过程进行监控，针对专门情形做出反应，或告知用户或进行相关的处理，同时用户可查询到协同处理状态。
渠道协同系统本身要有一定的健壮性，对多变的业务规那么的现状有较高的适应性。
2．3系统需求分析
软件开发的目标是在预算内按时开发符合客户真正需要的高质量软件。
需求分析要紧通过建立模型的方式来描述用户的需求，为客户、开发方等不同参与方提供一个交流的渠道。
这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。
用户需求的分析与用户需求的猎取有着相似的步骤，区别在于分析用户需求时使用模型，以猎取用户更明确的需求。
分析用户的需求，需要执行以下活动。
通过建立图形，描述系统的整体结构。
渠道协同功能结构图差不多如下：
渠道协同系统按功能分可分为业务要求接入治理、规那么治理、随机服务密码、协同调度处理、流程公布五个功能模块。
2．3．1系统功能性需求
系统的核心功能大致分为：
接入。
要紧实现将接收到的协同要求以一定的数据格式储存在系统中；
要求处理。
要紧实现将渠道要求分解成各个系统能够独立施工的子任务，并与之交互。
然后回写处理结果（假如有需要进行回写的话）；
要求回复。
依照各个协同渠道的处理结果，向源要求系统发送处理结果。
系统总体状态图如下：
详细分析系统的需求能够归纳为以下几个方面：
1．接入治理
完成来自其他渠道的协同要求接收，并形成协同要求实例。
在渠道协同中，所有交互用到的数据都要满足元数据要求，因此从协同要求接口中接收到的要求数据，都转换为元数据格式，然后储存到业务要求数据表。
每个协同要求实例数据都以统一的〝数据语言’’（元数据）进行表达，形成〝数据池〞。
因此在处理过程中各环节都能够从访问数据池中的数据。
为了幸免错误的要求进入渠道协同平台，在接收要求的时候，还会进行如下逻辑判定：
（1）权限认证：
为欲接入的渠道配置一定的权限（如认证密码等）。
权限以及渠道信息储备在数据库表里，建议认证密码以密文的方式传入。
（2）冲突检查：
为幸免重复的业务要求，渠道协同应该提供冲突检查的功能。
将其设置为数据库表里的一个字段，在冲突检查的时候结合数据库表里的相关字段来进行验证。
业务流程如下：
2．协同调度处理
协同调度完成协同要求的分解及调度功能。
这部分是渠道协同的核心功能，除了协同要求的分解之外，还有分解后的协同任务与各渠道交互的功能。
协同调度治理完成两大部分的功能：
（1）协同要求分解及协同
通过建模的过程将协同要求进行分解，并通过分解后的各个环节来完成各个协同任务的协同功能。
（2）协同任务处理
在流程中的各个环节，都完成对应的协同任务。
在渠道协同中，能够通过自动的方式将协同任务发送到其他渠道进行处理，也支持通过手工的方式完成协同任务处理。
对接收到的协同要求处理过程大致如下：
在接收到协同要求之后，依照流程模板适用规那么，匹配到正确的流程模板，并通过工作流引擎的接口，创建流程实例，并开始进行调度。
协同逻辑是在流程模板上实现的，在匹配流程模板的过程确实是选择分解规那么的过程。
每环节的协同任务处理是需要依照各个业务逻辑来实现的，在渠道协同中环节执行功能定义确实是配置每个环节处理协同任务所需要执行的功能。
另外，协同要求的元数据适配也是在协同调度过程中完成的。
在每个环节的协同任务开始处理之前，由系统依照数据提取组件来猎取该环节配置的元数据，并爱护到协同要求的数据池中。
业务流程如下：
关于渠道协同平台来说，预约服务治理也是一种专门的渠道协同服务要求治理，渠道协同平台只是按照需要将如此的要求转发给相应的渠道平台即可。
下面将通过预约服务作为特例讲述一下协同调度处理的过程：
预约是指客户通过各个渠道申请预定服务或资源等，并由电信运营商在预约保留期内提供此项服务的过程。
预约服务涉及多个渠道，工作人员的协同工作；
预约服务治理在渠道协同的处理模式上属于异步处理模式。
在预约服务治理流程中，针对预约任务的执行，工作流引擎负责预约业务流程的执行操纵。
流程描述如下：
（1）渠道协同系统接收预约要求，依照预约要求的处理规那么，生成预约处理任务单。
（2）协同调度进行执行任务类，调用规那么配置接口，启动预约执行流程，工作流引擎开始执行业务流程。
（3）工作流引擎向资源配置模块发送资源配置要求，等待资源分配。
（4）资源配置模块完成分配后，调用渠道协同预约资源确认接口，触发流程连续执行。
（5）工作流引擎触发生成预约编号，并发送预约办理短信。
（6）客户依照预约短信到营业前台进行业务办理，输入预约编号，查询预约信息后进行相关业务办理。
业务办理成功后调用渠道协同预约成功接口，触发渠道协同预约流程连续执行。
（7）回写预约任务单执行状态。
业务流程：
3．随隐秘码治理
随隐秘码服务是一种同步的协同业务要求，按照上述业务流程处理接口。
随机服务密码治理功能是渠道协同系统提供的基础功能，系统功能包括服务密码的生成治理，随机服务密码的有效期治理，服务密码的验证治理等功能。
平台接收到随机服务密码生成要求后，生成一条记录到数据库表，其有效时长通过系统参数配置。
随隐秘码生成后需要通过短信网关将短信发送给密码发送给用户。
随隐秘码验证步骤如下：
（1）接收到随隐秘码验证要求：
（2）依照输入参数猎取系统中的随隐秘码；
（3）判定随隐秘码是否过期，假设过期，转5；
（4）验证密码是否正确；
（5）向短信网关发送密码验证结果。
业务流程：
4．治理规那么
〔1〕环节参数配置
流程模板公布之后，通过触发渠道协同系统流程公布回调接口，储存流程模板信息和模板相关的环节信息。
通过配置信息，能够通过模板名找到与之对应的环节，通过可视化的配置，对每一环节进行规那么配置（即配置每个环节的调用接口和对应参数）
（2）元数据治理
元数据治理要紧是针对渠道协同中涉及到的参数进行治理，此功能目的要紧是爱护系统中参数一致性，保证各个渠道在协同工作时的参数一致。
（3）协同决策规那么治理
协同决策规那么要紧是对接入进来的业务要求适配相应的流程模板。
要制定出匹配规那么即协同决策规那么，以业务要求的相关字段匹配不同的流程模板，也即配置渠道和业务要求对应的模板。
要紧功能有：
渠道协同决策规那么的配置（增加，修改，删除）、渠道协同决策规那么的查询。
5．流程公布
渠道协同系统提供图形化的公布流程方法，如此使得开发和爱护变得简单，非开发人员也能够制定业务流程，通过流程公布工具公布业务流程并进行参数配置，使整个系统更加灵活，公布流程的过程如以下图：
使用渠道协同来实现协同业务将变得更为简单。
大致需要实现下面的几项工作即可：
（1）制定协同要求处理流程
使用jbpm提供的建模工具，依照协同业务要求，制定协同要求处理流程。
因为这是图形化的工具，因此使用起来专门简单。
（2）开发各环节与渠道交互的组件
编写各环节协同任务处理组件，即环节与各渠道交互接口组件，在该组件中完成本环节的协同任务处理。
（3）定制协同要求规那么数据
包括配置各环节使用的元数据、各环节执行的组件、流程模板的适用规那么
上述3个步骤，只有第2个步骤是需要开发的，其他步骤都能够通过配置完成。
2．3．2系统非功能性需求
非功能性需求分为几个方面：
1．性能方面。
响应时刻。
分日常交互类、日常查询类、批量处理分别考虑。
日常交互指传统的大量交互业务，以及一次完成多笔业务处理的交易，日常交互类业务具有较高的响应要求。
查询类业务如查询业务处理状态、查询业务规那么信息等。
查询业务由于受到查询的复杂程度、查询的数据量大小等因素的阻碍，需要依照具体情形而定，给出一个参考范畴。
批处理业务如批处理业务转发等业务处理，该类业务处理复杂、操作数据量大、处理时刻长。
响应时刻指标包括：
平均响应时刻参考值（秒）、峰值响应时刻参考值（秒）。
吞吐量。
系统交易量的估算。
指标有年交易笔数（笔／年）、高峰期交易笔数（笔／天）。
数据储备量。
每年的数据储备容量及以后几年该数量的预期（增长）值。
指标包括累计储备容量、年增长。
2．系统可靠性：
渠道协同系统应该满足7×24小时都能够使用，客户在任意时刻发出的协同要求都能够及时处理；
3．可扩展性：
可实现负载均衡；日后假设信息量较大，那么系统可相应增加服务器实现扩展。
同时针对一些业务上的扩展，系统要有专门强的适应性，或者能通过低成本的改造达到要求。
第3章系统设计
3．1系统技术架构
客服系统是采纳MVC（Model．View-Controller）模式。
MVC的要紧思想是把应用程序划分为三部分，其中M代表模型Model，V代表视图View，C代表操纵器Controller。
分层的目的是增加代码的重用率，减少数据表达，数据描述和应用操作的耦合度，同时也使得软件可爱护性、可修复性、可扩展性、灵活性以及封装性大大提高。
MVC设计模式告诉我们，把应用的模型按一定的规那么抽取出来，抽取的层次专门重要。
抽象与具体不能隔得太远，也不能太近。
MVC并没有提供模型的设计方法，而只告诉你应该组织治理这些模型，以便于模型的重构和提高重用性。
〝
MVC设计模式由三部分组成。
1．模型（Model）：
封装数据和所有基于对这些数据的操作，也确实是业务流程状态的处理以及业务规那么的制定。
业务流程的处理过程对其它层来说是黑箱操作，模型同意视图要求的数据，并返回最终的处理结果。
业务模型的设计能够说是MVC的核心。
2．视图（View）：
封装对数据的显示，即用户界面。
MVC设计模式关于视图的处理仅限于视图上数据的采集和处理，以及用户的要求，而不包括在视图上的业务流的处理。
业务流程的处理交予模型（Model）处理。
3．操纵器（Controller）：
封装外界作用于模型的操作和对数据流向的操纵等。
划分操纵层的作用也专门明显，它清晰地告诉你它选择什么样的模型，选择什么样的视图，以完成什么样的用户要求。
操纵层并不做任何的数据处理。
例如，用户点击一个连接操纵层接收要求后，并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么反映到这些变化。
因此，不管何时发生了何种数据变化，操纵器都会将变化通知视图导致显示的更新。
这实际上是一种模型的变化一种传播机制。
渠道协同系统是客服系统的一部分，要紧是向外提供相应的渠道协同的服务（即要紧实现模型部分），因此它的视图和操纵放在各个渠道系统去实现，比如在营业前台的处理界面上嵌入渠道协同要求信息录入界面，工作人员录入信息后，调用渠道协同系统的相应的服务，启动渠道协同的业务流程。
该业务流程完成后，返回给各个渠道系统相关信息。
本文将不再表达在各个渠道系统嵌入的渠道协同的界面以及操纵模块的设计与实现。
渠道协同系统采纳Spring框架、Webservice组件和Hibernate框架整合的框架模型，另外又整合到里面去规那么引擎和工作流引擎，以达到业务需求。
Spring框架的功能能够用在任何J2EE服务器中，大多数功能也适用于不受治理的环境。
Spring的核心要点是：
支持不绑定到特定J2EE服务的可重用业务和数据访问对象。
毫无疑问，如此的对象能够在不同J2EE环境（Web或EJB）、独立应用程序、测试环境之间重用。
简单来说，Spring是一个轻量级的操纵反转（IOC）和面向切面（AOP）的容器框架，它的目标是为J2EE应用提供了全方位的整合框架，在Spring框架下实现多个子框架的组合，这些子框架之间能够彼此独立，也能够使用其它的框架方案加以代替，Spring期望为企业应用提供一站式的解决方案。
Hibernate是采纳ORM模式实现数据持久层的一个优秀的Java组件，它提供．强大、高效的将Java对象进行持久化操作的服务。
利用Hibemate，开发人员可方便地按照Java对象的结构进行持久化层的开发，并能够使用Hibernate所提供
HQL（HibernateQueryLangage，Hibernate查询语言）完成Java对象和关系型数库之间的转换和操作。
WebService是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得WebService能与其他兼容的组件进行互操作。
它能够使用标准的互联网协议，像超文本传输协议和XML，将功能表达在互联网和企业内部网上。
WebService平台是一套标准，它定义了应用程序如何在Web上实现互操作性。
从表面上看，W
升级会员 