CN101635726B

CN101635726B - C/s架构中服务端和客户端的业务执行方法及系统

Info

Publication number: CN101635726B
Application number: CN200910167153.4A
Authority: CN
Inventors: 袁浩
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2009-08-26
Filing date: 2009-08-26
Publication date: 2012-07-04
Anticipated expiration: 2029-08-26
Also published as: RU2554570C2; US20120144387A1; CN101635726A; US8732694B2; RU2012108556A; WO2011023020A1

Abstract

本发明公开了一种C/S架构中服务端和客户端的业务执行方法及系统，服务端的业务执行方法包括步骤：服务端在业务执行过程中执行到预先设置的用户决策点时，中断业务执行并向客户端发起用户决策请求，所述用户决策请求包含请求用户决策所述用户决策点后业务执行行为的信息；在接收到客户端对用户决策请求所作出的用户决策信息后，根据用户决策信息与业务执行规则的对应关系，确定出接收的用户决策信息对应的业务执行行为，并按该确定出的业务执行行为执行业务。本发明使在C/S架构中，可以根据软件需求或用户需要由客户干预或影响服务端的业务执行行为或流程的目的。

Description

C/S架构中服务端和客户端的业务执行方法及系统

技术领域

本发明涉及通信和计算机软件领域的进程间通信技术，具体涉及一种C/S(Client/Server)架构中服务端和客户端的业务执行方法及系统。

背景技术

C/S(Client/Server)架构在网络开发中经常用到。C/S架构，即被所熟知的客户端和服务端架构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到客户端和服务端，使软件系统架构更加清晰，更易于维护和升级。通常的，在C/S架构中，客户端与服务端的业务执行方法为：服务端一旦被启动，就随时等待响应客户端发来的业务执行请求；客户端负责界面显示和与用户交互，当用户需要对服务端发出操作请求来执行业务时，客户端根据用户请求向服务端其发出业务执行请求，并等待接收从服务端发来的执行过程信息或执行结果信息；服务端负责接收和执行客户端发来的业务执行请求，根据业务执行请求进行业务执行，执行完成后向客户端反馈业务执行结果。

一般来说，服务端在根据接收的业务执行请求执行业务的过程中，客户端无法再对服务端的业务执行过程施加干预。在通常情况下，这并不影响使用C/S架构来满足客户端的业务需求，但也有例外。在一些软件需求中，可能会要求用户可以通过客户端干预服务端的业务执行，比如：用户可能希望根据服务端业务执行到一定阶段后出现的不同情况决定服务端后续的业务执行行为或执行流程。在这种情况下就需要一种客户端干预服务端执行的方法，达到用户通过客户端可以干预或影响服务端业务执行行为或流程的目的。

发明内容

本发明提供一种C/S(Client/Server)架构中服务端和客户端的业务执行方法及系统，用以解决现有技术中C/S架构中用户不能根据需求通过客户端干预或影响服务端业务执行行为或流程问题。

本发明提供了一种C/S架构中服务端的业务执行方法，包括步骤：

服务端在业务执行过程中执行到预先设置的用户决策点时，中断业务执行并向客户端发起用户决策请求，所述用户决策请求包含请求用户决策所述用户决策点后业务执行行为的信息；

在接收到客户端对用户决策请求所作出的用户决策信息后，根据用户决策信息与业务执行规则的对应关系，确定出接收的用户决策信息对应的业务执行行为，并按该确定出的业务执行行为执行业务。

本发明还提供了一种C/S架构中客户端的业务执行方法，包括步骤：

接收来自用户的业务执行请求并将其发送到服务端，请求服务端开始业务执行；

在业务执行过程中接收来自服务端的信息，在所述信息为用户决策请求时，提示用户需要决策并等待用户对用户决策请求的响应，所述用户决策请求包含请求用户决策后续业务执行行为的信息；

接收用户对所述用户决策请求所作出的用户决策信息，客户端将该用户决策信息发送到服务端。

本发明还提供了一种C/S架构中服务端和客户端的业务执行系统，该系统包括：

客户端业务执行单元，用于向服务端发起业务执行请求，在接收到来自服务端的用户决策请求时，提示用户需要决策并等待用户对用户决策请求的响应，并将用户对所述用户决策请求所作出的用户决策信息发送到服务端；

服务端业务执行单元，用于在接收来自客户端的业务执行请求后开始执行业务，在业务执行过程中执行到预先设置的用户决策点时，中断业务执行并向客户端发起用户决策请求，在接收到客户端对用户决策请求所作出的用户决策信息后，根据用户决策信息确定用户决策点后的业务执行行为。

本发明有益效果如下：服务端的业务执行流程中设置用户决策点，用户可以在用户决策点进行决策，根据该决策来改变后续的业务执行行为或流程，实现了客户端干预或影响服务端的业务执行行为或流程的目的。

附图说明

图1为本发明C/S架构中服务端的业务执行方法流程图；

图2为本发明C/S架构中客户端的业务执行方法流程图；

图3为本发明实施例一中服务端业务执行单元的结构图；

图4为本发明实施例一中客户端业务执行单元的结构图；

图5为本发明实施例二中C/S架构中客户端的业务执行方法流程图；

图6为本发明实施例二中C/S架构中服务端的业务执行方法流程图。

具体实施方式

本发明所提供C/S架构中服务端的业务执行方法，如图1，包括步骤：S101，服务端在业务执行过程中执行到预先设置的用户决策点时，中断业务执行并向客户端发起用户决策请求，所述用户决策请求包含请求用户决策所述用户决策点后业务执行行为的信息；S102，在接收到客户端对用户决策请求所作出的用户决策信息后，根据用户决策信息与业务执行规则的对应关系，确定出接收的用户决策信息对应的业务执行行为，并按该确定出的业务执行行为执行业务。如图2所示，为本发明所提供的C/S架构中客户端的业务执行方法，包括步骤：S201，接收来自用户的业务执行请求并将其发送到服务端，请求服务端开始业务执行；S202，在业务执行过程中接收来自服务端的信息，在所述信息为用户决策请求时，提示用户需要决策并等待用户对用户决策请求的响应，所述用户决策请求包含请求用户决策后续业务执行行为的信息；S203，接收用户对所述用户决策请求响应所作出的用户决策信息，客户端将该用户决策信息发送到服务端。由于采用C/S架构，优选客户端用户需求主动向服务端发起业务执行请求；服务端启动后利用事件循环来监控来自客户端的信息，在该信息为业务执行请求时开始业务执行；服务端在业务执行开始到结束过程中反馈业务执行状态信息到客户端。客户端接收到在来自服务端的业务执行状态信息时，通过界面返回给用户。

本发明所提供的C/S架构中服务端和客户端的业务执行系统包括：客户端业务执行单元，用于向服务端发起业务执行请求，在接收到来自服务端的用户决策请求时，提示用户需要决策并等待用户对用户决策请求的响应，并将用户对所述用户决策请求所作出的用户决策信息发送到服务端；服务端业务执行单元，用于在接收来自客户端的业务执行请求后开始执行业务，在业务执行过程中执行到预先设置的用户决策点时，中断业务执行并向客户端发起用户决策请求，在接收到客户端对用户决策请求所作出的用户决策信息后，根据用户决策信息确定用户决策点后的业务执行行为。

如图3所示为本实施例中服务端业务执行单元的结构图，该服务端业务执行单元包括：301，决策点设置单元，用于设置服务端在业务执行过程中需要用户进行决策的用户决策点；用于在接收到客户端对用户决策请求所作出的用户决策信息后，根据用户决策信息与业务执行规则的对应关系，确定出接收的用户决策信息对应的业务执行行为，并按该确定出的业务执行行为执行业务。如图4所示为本实施例中客户端业务执行单元的结构图，该客户端业务执行单元包括：业务执行请求单元401，用于根据用户需求向服务端发起业务执行请求，请求服务端开始业务执行；接收单元402，用于在业务执行过程中接收来自服务端的信息；请求决策单元403，用于在接收的信息为用户决策请求时，提示用户需要决策并等待用户对用户决策请求的响应；发送单元404，用于将用户对所述用户决策请求响应后所得到用户决策信息发送到服务端。

具体实施时用户决策点可以由服务端根据业务执行情况设定或由客户端配置，若由服务端根据业务执行情况设定，如在检测到业务执行存在安全风险时设定用户决策点，请求用户决策后续的业务是否执行，这种方式灵活性比较高；若由客户端配置业务执行流程的用户决策点，则更能满足客户的需要，灵活性相对较差一些。上述用户决策请求可以包含请求用户作出选择的若干个不同的标志位信息，不同的标志位信息在业务执行规则中对应不同的业务执行行为；用户决策信息为所选择的一个标志位信息。因此服务端可以根据接收的标志位信息按业务执行规则来确定用户决策点后的业务执行行为并执行。当然，本发明的用户决策请求不限于上述形式，可以是传递请求用户决策后续业务执行行为的任何其它形式，本发明所提出的方法及系统适用于C/S架构，不管是具有C/S架构的网络系统，还是具有C/S架构的软件系统。

依照本发明的实施例一，C/S架构中客户端和服务端的业务执行方法中，服务端和客户在程序中采用不同类型的消息来表示上述业务执行请求、用户决策信息、业务执行状态信息及用户决策请求。

在客户端和服务端的业务执行过程中，客户端向服务端发送的消息是分类，包括：A1，业务执行请求消息，该消息表示业务执行请求，即表示用户希望服务端来执行什么业务；A2，用户决策消息，该消息表示用户决策信息，即表示用户对服务端发送的用户决策请求的响应。

服务端向客户端发送的消息也是分类的，包括：B1，业务执行状态消息，该消息表示业务执行状态信息，即表示服务端在根据用户发送的业务执行请求进行业务执行的业务执行结果或中间状态信息的反馈，可以反馈用户的业务执行请求是否成功执行或执行到什么阶段；业务执行状态消息还可以更细化的分为提示消息、警告消息、错误消息、进度消息和针对不同的业务执行请求对应的事件响应消息；B2，用户决策请求消息，该消息表示用户决策请求，即表示服务端执行到预先设置的用户决策点时，需要用户来决策后续的业务执行动作或流程。

本实施例中客户端和服务端之间通过消息通道来传递上述不同类型的消息，消息通道可以是socket、管道、消息队列或其他进程间通信的载体。

所谓socket通常也称作″套接字″，用于描述IP地址和端口，是一个通信链的句柄。应用程序通常通过″套接字″向网络发出请求或者应答网络请求。客户端随机申请一个socket，网络系统为之分配一个socket号(后面称client_sock)；服务端拥有全局公认的socket(后称server_sock)，任何客户端都可以向它发出连接请求和信息请求。具体为：服务端，使用server_sock监听指定的端口，端口可以随意指定，等待客户端连接请求，与客户端连接后，会话产生；在完成会话后，关闭连接。客户端，使用client_sock对网络上服务端的端口发出连接请求，一旦连接成功，打开会话；会话完成后，关闭client_sock。

管道(pipe)是用于进程间通信的共享内存区域。一个进程向管道写入信息，而另外一个进程从管道读取信息。

消息是在两台计算机间传送的数据单位。消息被发送到队列中。消息队列是在消息的传输过程中保存消息的容器，消息队列主要目的是提供路由并保证消息的传递。

本实施例中客户端向服务端发送的消息结构和服务端向客户端发送的消息结构可以单独定义或是统一到一种结构中。

本实施例中服务端和客户端在程序中利用事件循环来进行消息监管。客户端利用第三事件循环监控来自用户的表示业务执行请求的消息及表示用户决策信息的消息，即第三事件循环监控客户端端界面上的用户事件；第四事件循环用于监控来自服务端的表示用户决策请求的消息及表示业务执行状态信息的消息，即第四事件循环是监控消息通道的。本实施例中将客户端监控消息通道的第四事件循环称为CL1。由于客户端的事件循环既要监控界面用户事件，又要监控消息通道，涉及到第三事件和第四事件循环的融合问题，本实施例中采用第三事件循环充当主事件循环，采用事件驱动的监控方式，第四事件循环采用定时查询的方式。

在服务端，第一事件循环用于监控来自客户端表示业务执行请求的消息，本实施例中将服务端的这层消息通道监控称为SL1，服务端根据接收到的不同的业务执行请求消息，调用不同的处理函数，执行不同的业务行为或流程；第二事件循环用于监控来自客户端表示用户决策信息的消息，本实施例中将服务端这层监控称为SL2。在C/S架构中服务端和客户端的业务执行方法中，SL1持续循环监控服务端与客户端间的消息通道，在监控到表示业务执行请求的消息后服务端开始业务执行，在业务执行过程中在执行到用户决策点时，发现需要用户参与决策，中断业务执行并向客户端发起用户决策请求消息，等待客户端对用户决策请求的响应，同时将事件循环SL1阻塞并开启事件循环SL2，监控消息通道；客户端利用第四事件循环监控到服务端发来的用户决策请求消息后，弹出询问界面，等待用户响应；客户端的第三事件循环捕捉到用户响应(用户决策消息)时，通过消息通道向服务端发送用户决策消息；服务端的事件循环SL2监控到用户决策消息后，服务端根据用户决策信息按所述规则执行相应的业务，并退出和销毁事件循环SL2，恢复事件循环SL1。等待客户端发来的业务执行请求消息。

本实施例中服务端的事件循环SL1或事件循环SL2循环原则上可以接收客户端所有通过消息通道发到服务端的消息，但在此处，事件循环SL1被设计成只接收业务执行请求消息的，如果收到用户决策消息，直接丢弃，事件循环SL1是一直存在的，直到服务端进程终止。本实施例事件循环SL2被设计成只接收用户决策消息的，如果收到业务执行请求消息，直接丢弃，事件循环SL2在服务端收到用户决策消息后，会被退出和销毁。

通过本实施例中的方法用户通过客户端可以干预或影响服务端的业务执行行为或流程。服务端在根据业务执行请求来进行业务执行的过程中，当执行到用户决策点时，向客户端发送用户决策请求消息，同时在用户决策点起一事件循环，监控消息通道，等待用户决策消息，实现了客户端干预或影响服务端的业务执行行为或流程的目的。

本实施例的上述方法并不限于操作系统平台或使用环境，只要操作系统支持进程间通信，均可使用该方法；也不局限于一对一C/S架构，也适用于通过在服务端对不同的客户端业务执行请求启动不同的线程来服务即可扩展的多对一C/S架构。

依照本发明的实施例二，C/S架构中客户端和服务端的业务执行方法中，以linux平台智能手机上软件包安装业务执行为例，所有软件包被放置于一网络服务器上，并有一配置文件表明所有软件的相关信息，包括软件包名、版本号、MD5(Message-digest Algorithm 5，信息-摘要算法)值等，手机终端上的包管理程序会下载这个配置文件获得所有软件包信息。手机终端上的包管理程序是基于C/S架构的，客户端图形界面基于gtk+开发包，服务端采用C语言实现，客户端和服务端之间的消息通道的载体选用socket。客户端和服务端采用一对一模型，但本领域技术人员应该明白本发明并不限于上述特点业务执行，C/S架构也不局限于一对一模型。消息通道的载体也不局限于socket方式。

上述MD5用于确保信息传输。MD5最广泛被用于各种软件的密码认证和钥匙识别上。通俗的讲就是所说的序列号完整一致。常常在某些软件下载站点的某软件信息中看到其MD5值，它的作用就在于可以在下载该软件后，对下载回来的文件用专门的软件(如Windows MD5 Check等)做一次MD5校验，以确保获得的文件与该站点提供的文件为同一文件。

如图5所示，本实施例C/S架构中客户端的业务执行方法包括以下步骤：

S501：定义客户端和服务端之间传递消息所采用的消息结构体，

本实施例采用客户端向服务端发送的消息和服务端向客户端发送的消息采用相同结构的原则，统一为Message_t，程序如下：

该结构有两个成员变量，type是一个枚举变量，表示消息的分类，具体来说就是，当客户端向服务端发送消息时，表示业务执行请求消息、用户决策消息；当服务端向客户端发送消息时，表示用户决策请求消息、业务执行状态消息等。content是一个结构体，表示消息携带的具体内容。

S502，客户端启动后，创建socket通道，得到client_sock，client_sock连接到服务端，这样客户端和服务端之间的消息通道就建立了。

S503，定义第三事件循环实现界面监控，因此客户端可以通过监控界面的第三事件循环，获得用户动作(即捕获业务执行请求消息和用户决策消息)，发送到服务端；

S504，客户端添加定时器，定义利用第四事件循环实现socket端口上的数据读取，第四事件循环采用定时读取的方法，监控消息通道的第四事件循环，具体采用定时读取的方法，示例代码是：

gtk_timeout_add(500，get_pending_message，NULL)，

get_pending_message函数的功能是读取socket上服务端发来的消息(包括用户决策请求消息和业务执行状态消息)，并根据消息的分类调用不同的处理函数，如在监控到用户决策请求消息后，弹出界面请求用户作出决策，在监控到业务执行状态消息时，通过界面反馈给用户；

S505，在上述步骤的基础上，当客户端的用户有某种特定的需求时，首先通过第三事件循环捕获业务执行请求信息，并将该业务执行请求信息发送到网络服务器，此时，网络服务器作为服务端，手机作为客户端，同时利用第四事件循环监控消息通道，对于本实施例中业务执行请求为请求安装的消息，当用户在手机选中一软件包，请求网络服务器安装时，手机向网络服务器发送请求安装的消息，网络服务器接收到该请求后将软件包下载到本地(即手机)开始安装时，由于手机终端上的包管理程序是基于C/S架构的，所以在软件包的安装过程中，用户界面作为客户端，后台的包安装程序为服务端；

S506，在第四事件循环监控到用户决策请求消息后，弹出对话框或字符界面请求用户决策，利用第三事件循环获得用户决策信息后发送到服务端；

S507，在第四事件循环监控到业务执行状态消息后，通过界面反馈给用户。如反馈下载成功或下载失败的业务执行结果给用户。

如图6所示，本实施例C/S架构中服务端的业务执行方法包括以下步骤：

S601：定义客户端和服务端之间传递消息所采用的消息结构体，本实施例采用客户端向服务端发送的消息和服务端向客户端发送的消息采用相同结构的原则，统一为Message_t，具体同上述步骤S501中所述。

S602，启动服务端后，以一个众所周知或客户端可以查到的名字建立socket通道。

S603，绑定并侦听步骤S602建立的socket通道；

S604，在侦听客户端的连接请求后，得到一个连接后的socket标识server_sock；

S605，定义利用事件循环来监控server_sock，这里事件循环的示例代码是通过一个while(wait_message())循环实现的，wait_message函数的功能是读取socket上客户端发来的消息并根据消息的分类调用不同的处理函数；这里具体定义第一事件循环监控来自客户端的业务执行请求消息，定义第二事件循环监控来自客户端的用户决策消息；

S606，在上述步骤的基础上，当客户端的用户有某种特定的需求时，首先通过第一事件循环捕获业务执行请求消息，根据业务执行请求消息开始业务执行；如在未安装软件包之前，手机作为客户端，网络服务器作为服务端，网络服务器接收到来自手机的请求安装的消息后，会开始执行把该软件包从网络服务器下载到本地的业务，将软件包从网络服务器下载到本地后开始安装，由于手机终端上的包管理程序是基于C/S架构的，所以在软件包的安装过程中，用户界面作为客户端，后台的包安装程序为服务端；

S607，在执行到用户决策点时，暂时中断业务执行，即将第一事件循环挂起，发送用户决策请求到客户端，开启第二事件循环来监控来自客户端的用户决策信息，如在将软件包从网络服务器下载到本地后开始安装后，后台的包安装程序作为服务端检测软件包的MD5值是否与网络服务器上配置文件中的是否一致，如果一致，表示该软件包没有被第三方改动过，可以放心安装；如果不一致，表示该软件包可能被第三方改动过，存在安全风险，这时服务端的业务执行需要用户决策，服务端发送用户决策请求消息到客户端，同时在此处调用wait_message函数，开启第二事件循环，等待用户响应。本实施例中服务端根据业务执行情况，检测软件包安装的安全，若存在安全风险，则设置用户决策点中断业务并请求用户决策是否安装，若没有安全风险，则不设置用户决策点中断业务而直接进行安装。本实施例中用户决策请求包含请求用户作出选择的两个不同的标志位信息，其中一个标志位信息在业务执行规则中对应继续软件包的业务执行行为，另一个标志位信息在业务执行规则中对应不进行软件包安装的业务执行行为；

S608，在第二事件循环监控到server_sock有数据时，读取并转化为Message_t消息结构，解析消息内容得到用户决策信息，在本实施例中用户决策信息为所选择的一个标志位信息，服务端根据收到的用户决策，确定后续的业务执行行为，并退出第二事件循环，重新回到第一事件循环中。至此，本次客户端干预服务端执行的流程结束。当再需要客户端干预服务端执行时，重复步骤S607和S608。

上述服务端在业务执行过程中，可以返回业务执行状态信息到客户端。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种C/S架构中服务端的业务执行方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，

所述用户决策请求包含请求用户作出选择的若干个不同的标志位信息，不同的标志位信息在业务执行规则中对应不同的业务执行行为；

所述用户决策信息为所选择的一个标志位信息。

3.根据权利要求1或2所述的方法，其特征在于，

所述用户决策点由服务端根据业务执行情况设定或由客户端配置。

4.如权利要求1所述的方法，其特征在于，

该方法应用于手机上C/S架构软件包的安装，在软件包的安装过程中，用户界面作为客户端，后台的软件包安装程序为服务端；

服务端在软件包的安装过程中根据业务执行情况，检测软件包安装的安全，若存在安全风险，则设置用户决策点中断业务执行并向客户端发送用户决策请求，由客户端提示用户决策是否安装，服务端在接收到客户端发送的是否安装的用户决策信息后确定是否继续进行软件包的安装。

5.一种C/S架构中客户端的业务执行方法，其特征在于，包括：

6.如权利要求5所述的方法，其特征在于，

在软件包的安装过程中，在客户端接收到服务端由于检测到安全风险而发送的用户决策请求后，客户端提示用户需要决策是否继续进行软件包安装并等待用户所作出的用户决策信息，将用户决策信息发送到服务端。

7.一种C/S架构中服务端和客户端的业务执行系统，其特征在于，包括：

8.如权利要求7所述的系统，其特征在于，所述服务端业务执行单元包括：

决策点设置单元，用于设置服务端在业务执行过程中需要用户进行决策的用户决策点；

决策请求发起单元，用于服务端在业务执行过程中执行到预先设置的用户决策点时，中断业务执行并向客户端发起用户决策请求，所述用户决策请求包含请求用户决策所述用户决策点后业务执行行为的信息；

执行单元，用于在接收到客户端对用户决策请求所作出的用户决策信息后，根据用户决策信息与业务执行规则的对应关系，确定出接收的用户决策信息对应的业务执行行为，并按该确定出的业务执行行为执行业务。

9.如权利要求8所述的系统，其特征在于，

所述决策点设置单元包括服务端设置单元或客户端设置单元，

所述服务端设置单元，用于在业务执行流程中由服务端根据业务执行情况设定用户决策点；

所述客户端设置单元，用于在业务执行流程中由客户端配置用户决策点。

10.如权利要求7或8所述的系统，其特征在于，所述客户端业务执行单元包括：

业务执行请求单元，用于根据用户需求向服务端发起业务执行请求，请求服务端开始业务执行；

接收单元，用于在业务执行过程中接收来自服务端的信息；

请求决策单元，用于在接收的信息为用户决策请求时，提示用户需要决策并等待用户对用户决策请求的响应，用户决策请求包含请求用户决策后续业务执行行为的信息；

发送单元，用于将用户对所述用户决策请求所作出的用户决策信息发送到服务端。

11.如权利要求7所述的系统，其特征在于，

该系统应用于手机上C/S架构软件包的安装，在软件包的安装过程中，用户界面作为客户端，后台的软件包安装程序为服务端；

所述服务端业务执行单元，在软件包的安装过程中根据服务端的业务执行情况，检测软件包安装的安全，若存在安全风险，则设置用户决策点中断业务执行并向客户端发送用户决策请求，由客户端提示用户决策是否安装，在接收到客户端发送的是否安装的用户决策信息后确定是否继续进行软件包的安装；

所述客户端业务执行单元，在接收到服务端由于检测到安全风险而发送的用户决策请求后，客户端提示用户需要决策是否继续进行软件包安装并等待用户所作出的用户决策信息，将用户决策信息发送到服务端。