CN101409717A - 协议无关的soa系统和业务处理方法 - Google Patents

Abstract

本发明提供了一种协议无关的SOA系统，包括客户端和服务器端，其中：客户端包括：编程代理，用于接收业务信息和配置的协议；协议选择器，用于根据所述配置的协议确定所使用的协议；协议客户端，用于采用所确定的协议实现客户端代理，以传递包含所述业务信息的信息；服务器端包括：协议服务器端，用于采用所确定的协议实现服务器端代理，以传递包含所述业务信息的信息；业务处理器，用于处理所接收的业务信息。还相应提供了一种协议无关的SOA的业务处理方法。使用本发明，可以实现SOA架构的服务和协议无关。

Description

协议无关的SOA系统和业务处理方法

技术领域

本发明涉及一种SOA技术领域，特别是指一种协议无关的SOA系统和业务处理方法。

背景技术

SOA是一种粗粒度、松耦合服务的架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用服务组件进行分布式部署、组合和使用。并且服务之间可通过简单、精确、标准的协议和接口定义语言进行通信与互操作，不涉及底层编程接口和通信模型。理想的是平台中将各种功能以粗粒度的服务表示出来，每种服务都能清晰地表示其技术或业务价值，在应用实现过程中，可以通过对服务的动态组装来适应用业务需求的动态变化。

企业服务总线ESB(Enterprise Service Bus)是SOA架构的一个支柱技术。它是一种开放的、基于标准的消息处理机制，通过简单的标准适配器和接口，来完成粗粒度应用(比如服务)和其他组件之间的互操作。作为一种消息代理架构它提供消息队列系统，使用诸如SOAP或JMS(Java Message Service)等标准技术来实现。一般地，ESB的主要功能包括：通信和消息处理、服务交互和安全性控制、服务质量和服务级别管理、建模、管理和自治、基础架构等。

例如目前通常采用远程调用(Remoting)，实现两个应用程序之间对象的通信流程是：首先，客户端通过远程调用系统，访问通道以获得服务端对象，再通过代理解析为客户端对象。这可以实现以服务的方式来发布服务器端对象。也就是说远程对象代码可以在服务器上运行，然后客户端再通过远程调用系统连接服务器，获得该服务对象并通过序列化在客户端运行。这样通过获得服务器端对象的引用来实现远程调用的目的，也就实现了客户端和服务器端有关对象的松散耦合。

但是目前常用的系统或方法，并不能真正实现松散耦合的粗粒度应用服务组件的分布式部署。例如所使用的协议发生改变或者SOA的系统中使用了多个不同平台甚至多个协议的话，传统的系统和方法是不能胜任的。例如需要提供的端口号和通道类型等信息将随着协议的变化而发生变化，而这些是和服务绑定在一起的。如果可以将协议和服务相分离，即实现服务和协议无关的话，将有效提高代码复用性，并使得服务的开发人员只需专注于服务的业务模型等业务上的开发，从而降低开发难度。

发明内容

有鉴于此，本发明的主要目的在于提供一种协议无关的SOA系统和业务处理方法，以实现SOA架构的服务和协议无关。

本发明提供了协议无关的SOA系统，包括客户端和服务器端，其中：

客户端包括：

编程代理302，用于接收业务信息和配置的协议；

协议选择器304，用于根据所述配置的协议确定所使用的协议；

协议客户端306，用于采用所确定的协议实现客户端代理，以实现传递包括所述业务信息的信息；

服务器端包括：

协议服务器端308，用于采用所确定的协议实现服务器端代理，以实现传递包括所述业务信息的信息；

业务处理器310，用于处理所接收的业务信息。

由上可以看出，通过编程代理302和协议选择器304在服务实现代理之前，还根据配置的协议确定将采用的协议。通过增加协议选择过程实现具体的服务和协议相分离，即实现服务和协议的无关。而协议的两端保证了分布式服务的通信。最后由服务器的业务处理器310完成业务逻辑的执行，最终达到了分布式服务架构的目的。

优选的是，所述协议客户端306包括：

代理实现选择器3062，用于选取代理实现；

代理实现库3064，用于提供包括对应不同协议的不同代理实现；

客户端代理3066，用于采用所选取的对应所确定的协议的代理实现，实现客户端代理。

由上可以看出，代理实现库3064中具体的代理实现描述了对应协议的实现细节，从而客户端代理3066可以建立用于在客户端的通信的代理，例如伪装实现所述客户端代理所需的包含业务信息的远程对象，并向本地提供与远程对象相同的接口。

优选的是，所述协议客户端(306)还包括：客户端接口3068，用于将包含所述业务信息的信息的格式进行标准化。

由上可以看出，客户端接口3068实现了在协议两端交互的信息的格式标准化。

优选的是，所述业务处理器310包括：

业务操作3102，用于读取业务信息；

业务接口3106，用于提供调用业务逻辑的接口；

业务逻辑实现3108，用于根据所述业务逻辑的接口调用业务逻辑处理所读取的业务信息。

由上可以看出，业务逻辑实现3108提供了具体的业务逻辑的实现并完成了业务信息的处理。从而完成了服务在服务器上的实现。

优选的是，所述业务处理器310还包括：

业务逻辑实现选择器3104，用于选择所要调用的业务逻辑。

由上可以看出，对于一个方法有多个业务逻辑实现的情况，利用业务逻辑实现选择器3104可以完成对业务逻辑的选择。这样对于客户端的应用程序不需要考虑具体实现，而只需要提供方法名就可以了。而且因为真正的处理选择在服务器端，还可以实现在服务器端对业务信息处理的集中控制。

本发明还公开了协议无关的SOA的业务处理方法，包括客户端和服务器端的处理，其中：

客户端的处理包括：

A，接收业务信息和配置的协议；

B，根据配置的协议确定所使用的协议；

C，采用所确定的协议实现客户端代理，实现传递包括所述业务信息的信息；

服务器端的处理包括：

D，采用所确定的协议实现服务器端代理，实现传递包括所述业务信息的信息；

E，处理所接收的业务信息。

由上可以看出，经过上面的步骤实现了客户端的服务的业务逻辑在服务器端的实现。其中步骤A和步骤B在步骤C之前，即在服务实现代理之前，首先根据配置的协议确定将采用的协议。通过增加协议选择过程实现具体的服务和协议相分离，即实现服务和协议的无关。而步骤C和步骤D在协议的两端保证了分布式服务的通信。最后由步骤E完成服务在服务器上的业务逻辑的实现，最终达到了分布式服务架构的目的。

优选的是，所述步骤C包括：

C1，选取代理实现；

C2，读取所选取的包括对应协议的代理实现；

C3，采用所选取的对应协议的代理实现，实现客户端代理。

由上可以看出，步骤C1和步骤C2为确定的协议和服务选择和读取具体的描述了代理实现细节的代理实现。而由步骤C3完成代理在客户端的完整实现。

优选的是，所述步骤C所述传递前还包括：将所要传递的包含所述业务信息的信息的格式进行标准化处理。。

由上可以看出，实现了在协议两端信息交换格式的标准化。

优选的是，步骤E中处理所接收的业务信息的步骤包括：

E1，读取业务信息；

E2，确定调用业务逻辑的接口；

E3，根据所述业务逻辑的接口调用业务逻辑处理所读取的业务信息。

由上可以看出，远程对象是业务信息的载体，步骤E1完成业务信息的读取后，由步骤E2和E3完成服务在服务器端的业务逻辑的具体实现。

优选的是，所述步骤E1和E2之间还包括：选择所要调用的业务逻辑；

由上可以看出，对于一个方法有多个业务逻辑实现的情况，通过增加步骤E11可以对多个业务逻辑进行选择。这样对于客户端的应用程序不需要考虑具体实现，而只需要提供方法名就可以了。而且因为真正的处理选择在服务器端，还可以实现在服务器端对业务信息处理的集中控制。

附图说明

图1为实施例中.NET Remoting协议的示意图；

图2为实施例中WebService协议的示意图；

图3为协议无关的SOA系统300的示意图；

图4为协议客户端306和协议服务器端308的示意图；

图5为带客户端接口的实施例的协议客户端306的示意图；

图6为业务处理310的示意图；

图7为协议无关的SAO的业务处理方法的流程图；

图8为步骤708和步骤710实现通信的流程图；

图9为步骤712实现业务信息处理的流程图。

具体实施方式

通常的，Web编程模型提供使用分布式通信编程框架生成Web样式服务所需的基本框架元素。而本发明SOA系统实现了一种与底层协议和分布式对象协议无关的面向服务的编程模型。通过本发明，在如.NET的平台上，如微软(Microsoft)等公司已经提供了多种分布式协议，如WebService编程模型或.NET Remoting编程模型，和已经提供的更先进的编程模型，如Windows CommunicationFoundation以及任何将来可能出现的编程模型，这些对本发明SOA系统来说，都可以进行统一处理。本发明SOA系统实现了基于业务接口的编程模型，并且可以不修改任何已有的业务代码而使用更新的分布式对象协议或服务协议。

本发明SOA系统中，实现通信的协议客户端和协议服务器端包括：根据服务确定所采用的代理实现的代理实现选择器(ProxyLocator)、读取所确定出的代理实现的具体内容的代理实现库(Proxy Repository)、根据读取的代理实现的具体内容实现在客户端/服务器端代理的客户端代理(Proxy)和服务器端存根(Stub)。

其中，所采用的协议可以由WebService、.NET Remoting或WCF(Windows Communication Foundation)实现。下面举例说明：

如图1所示为采用.NET Remoting协议的示意图，包括：.NETRemoting代理实现选择器102(.NET Remoting Locator)、.NETRemoting代理实现库104(.NET Remoting Repository).NETRemoting的客户端代理106/服务器端存根108(.NET RemotingProxy/Stub)。

如图2所示为采用WebService协议的示意图，包括：WebService代理实现选择器202(WebService Locator)、WebService代理实现库204(WebService Repository)和具体的WebService的客户端代理206/服务器端存根208(WebService Proxy/Stub)。

同理，采用WCF协议可由WCF代理实现选择器(WCF Locator)、WCF代理实现库(WCF Repostiory)和具体的WCF的客户端代理/服务器端存根(WCF Proxy/Stub)构成。

不难理解的是，采用以上3个协议仅为举例，也可以采用其它协议构成类似的模式实现协议客户端和协议服务器端的通信，在此不一一详述。

对于本发明的协议无关的SOA系统实现编程模型时，需要首先建立业务接口(Business Interface)，然后针对这个业务接口，给出一个或多个业务逻辑实现(Strategy Implementation)。由协议无关的SOA系统提供一个公共的协议选择器(Service Locator)，然后为每个业务接口自动生成编程代理(Agent)、实现客户端接口(Client Interface)的客户端代理(Proxy)、服务器端存根(Stub)、业务操作(Business Operation)和业务逻辑选择器(StrategySelector)等。其中业务逻辑实现选择器允许修改生成的代码。在下文具体介绍SOA系统时，将陆续介绍出上面的具体内容。

下面以在客户端下订单时远程调用服务器中的业务逻辑实现编程模型为例，结合图3对协议无关的SOA系统300进行详细说明。

在本例中，客户端的应用程序描述了要为一个用户ID(CustomerID)为ABC Company的客户下订单，其订单的ID和名称(Name)分别是2345和ABC Company。该描述中需要的执行方法(Do)的具体实现，即业务逻辑的实现在服务器端。

以下是客户端应用程序的示例：

·public void TestLocal()

·{

·PlaceOrderAgent agent＝new PlaceOrderAgent()；

·agent.CustomerID＝″ABC Company″；

·OrderData data＝new OrderData()；

·data.Id＝2345；

·data.Name＝″ABC Company″；

·agent.OrderData＝data；

·object o＝agent.Do()；

·Console.WriteLine(o.ToString())；

·}

上述示例是采用C#语言的下订单程序，不难理解，也可以采用其它编程语言描述该应用程序。

对于本发明协议无关的SOA系统300，其客户端包括：

编程代理302，用于接收业务信息和配置的协议。

在本实施例中，从客户端的应用程序接收业务信息和配置的协议。接收的业务信息包括业务数据(如所述应用程序中描述的用户ID-CustomerID和订单数据-OrderData)和所调用的方法名(Do)。配置的协议是订单业务(IPlaceOrder)所属服务的所配置的协议。不难理解，如果调用多个方法，例如Do1和Do2，只需在编程代理302中添加调用的方法即可。

以下是编程代理302示例：

·//Full Generated

·public class PlaceOrderAgent：Agent

·{

·public string CustomerID{get；set；}

·public OrderData OrderData{get；set；}

·public object Do()

·{

·IPlaceOrder po＝(IPlaceOrder)ServiceLocator.GetService(typeof(IPlaceOrder))

协议选择器304，用于根据所述配置的协议确定所使用的协议。

以下是协议选择器304的示例：

Service Locator

·使用了服务定位器设计模式

·RemotingLocator，WebServiceLocator，WCFLocator

·IPlaceOrder ipo＝(IPlaceOrder)ServiceLocator.GetService(typeof(IPlaceOrder))

对于所有或单个服务可以对应一个或多个配置的协议。在本实施例中，其对应关系可以由服务开发人员或平台开发人员指定，也可以根据系统环境，如系统默认的协议进行选择。

协议客户端306，用于采用所确定的协议实现客户端代理，以实现传递包括所述业务信息的信息。

如图4所示为协议客户端306和协议服务器端308的示意图。下文将结合图4对协议的两端进行详细说明。

对于本发明协议无关的SOA系统300，其服务器端包括：

协议服务器端308，用于采用所确定的协议实现服务器端代理，以实现传递包括所述业务信息的信息。

业务处理器310，用于处理所接收的业务信息。

如图6所示为业务处理器310的示意图。下文将结合图6对业务处理器310进行详细说明。

由上可以看出，通过编程代理302和协议选择器304在选择服务的具体配置项实现代理之前，还根据配置的协议选择所采用的协议。通过增加协议选择过程实现具体的服务和协议相分离。而协议的两端保证了分布式服务的通信。最后由服务器的业务处理器310完成业务逻辑的执行，最终达到了分布式服务架构的目的。

下面结合图4对协议的两端进行详细说明，协议的两端包括协议客户端306和协议服务器端308，其中：

协议客户端306，包括：

代理实现选择器3062，用于选择代理实现。

在本实施例中包括查看并选取下文对客户端代理3066描述中的PlaceOrderRemotingProxy和PlaceOrderWSProxy。

代理实现库3064，用于提供包括对应不同协议的不同代理实现。

代理实现库中存储了不同协议的不同代理实现，例如是不同的配置文件。在本实施例中，为每个服务都预设了特定的配置文件，配置文件中包含了端口号和通道类型等代理实现细节。

客户端代理3066，用于采用所选取的对应所确定的协议的代理实现，实现客户端代理。

例如，当采用.NET Remoting客户端代理时，其示例如下：

·public class PlaceOrderRemotingProxy：MarshalByRefObject/*or RemoteClientProxy*/，IPlaceOrder

·{

·public object Do(string customerID，OrderData order)

·{

·PlaceOrder po＝new PlaceOrder()；//or otherstandard method to access server side object.

·po.CustomerID＝customerID；

·//here we transform BusinessData to BusinessEntity.

·OrderEntity entity＝new OrderEntity；

·entity.OrderID＝order.OrderID；

·...

·po.Do()；

·}

·}

又如，当采用WebService客户端代理时，其示例如下：

·public class PlaceOrderWSProxy：HttpSoapClientProxy/*or other goody*/，IPlaceOrder

·{

·public object Do(string customerID，OrderData order)

·{

·...

·return base.Invoke(new object[]{customerID，order})；

·}

·}

·生成客户端代理3066的同时也自动生成asmx格式的服务器存根，以及所有微软Web Service编程模型要求程序员手写或被开发工具自动生成，正确运行所需的代码。所述生成方法和步骤参见本申请人的申请号为2008 1 0227 043.8的中国专利申请，此处不再赘述。

在另一个实施例中，协议客户端306还包括客户端接口3068，用于提供传递信息的标准化接口。如图5所示为带客户端接口3068的实施例的协议客户端306的示意图。

客户端接口3068可以看成是方法的集合。本实施例中用C#语言中的interface来实现。在本实施例中，不同协议最终提供的信息都是预设的统一格式，在客户端接口3068进行强制转换。

以下是客户端接口3068的示例

·//Client-Server Interaction Protocol.

·public interface IPlaceOrder

·{

·Object Do(string customerID，OrderData order)；

·}

·//说明，订单数据(OrderData)不是订单实体(OrderEntity)。

由上完成了采用所确定的协议实现包括传递所述业务信息的协议客户端的代理。其中客户端接口3068为协议两端交互提供了标准化的接口。

图4中所示的协议服务器端模块308用于实现在服务器端的代理。在本实施例中作为协议的服务器端，可采用目前通用的服务器端存根。以实现例如对象的反序列化等功能。

由上可以看出，协议的两端实现了通信两端的代理机制。即实现了SOA分布式架构的通信部分。

下面结合图6对协议无关的SOA系统300的业务处理310进行详细说明。

如图6所示业务处理310包括：

业务操作3102，用于读取业务信息；

在本实施例中，读取的业务信息包括业务数据(CustomerID和OrderData)和调用的方法(Do)。

以下是业务操作3102的示例：

·//Full Generated by Business Operation Metadata

·[Service]

·public class PlaceOrder：BusinessOperation

·{

·public string CustomerID{get...；set...；}

·public OrderEntity Order{get...；set...；}

·public override object Do()

·{

·IPlaceOrderStrategy strategy＝PlaceOrderSelector.Select(this)；

·stragegy.Do(this)；

·}

·}

业务逻辑选择器3104，用于选择所要调用的业务逻辑。

在本实施例中，方法(Do)的实现有多种业务逻辑。例如对不同客户可以有不同的费用折扣率。

以下是业务逻辑选择器3104的示例：

·//Generate initial code

·public partial class PlaceOrderSelector

·{

·public static IPlaceOrderStrategy Select(PlaceOrderorder)

·{

·//please write your code here.

·}

·}

业务接口3106，用于提供调用业务逻辑的接口。

业务接口3106和客户端接口3068一样，也可以看成是方法(Do)的集合，其暴露了业务逻辑实现的接口。可以采用C#的Interface实现。

以下是服务器端业务接口3106的示例：

·public interface IPlaceOrderStrategy

·{

·object Do(PlaceOrder placeOrder)；

·}

业务逻辑实现3108，用于根据所述业务逻辑的接口调用业务逻辑处理所读取的业务信息。

在本实施例中，方法(Do)有2个订单业务逻辑(PlaceOrderStrategy)的业务逻辑实现。分别是PlaceOrderStrategy1和PlaceOrderStrategy2。

以下是PlaceOrderStrategy1的示例：

·//Generate initial code

·public partial class PlaceOrderStrategy1：IPlaceOrderStrategy

·{

·public object Do(PlaceOrder po)

·{}

·}

以下是PlaceOrderStrategy2的示例：

·//Generate initial code

·public partial class PlaceOrderStrategy2：IPlaceOrderStrategy

·{

·public object Do(PlaceOrder po)

·{}

·}

由上就完成了服务在服务器上的实现，在本实施例中即为远程对象代码在服务器上的运行。然后将运行得到的结果返回给客户端即可。以上的各个代码示例采用的是C#语言，但不难理解的是，本发明的系统也可以用其它语言实现。

下面结合附图和在客户端下订单的示例(参见系统实施例中的客户端程序示例)对协议无关的SAO业务处理方法进行详细说明。

如图7所示为协议无关的SAO业务处理方法的流程图，包括以下步骤：

步骤702，应用程序调用SOA。

对于应用程序来说，SOA的分布式服务是透明的。也就是说，虽然在本实施例中，下订单的方法(Do)的真正的业务逻辑实现是在服务器上实现的。但是对于客户端的应用程序来说，并没有什么不同。

所述方法在客户端的处理，包括：

步骤704，接收业务信息和配置的协议。

从客户端的应用程序接收到需要处理的业务信息和配置的协议。在本实施例中，业务信息包括业务数据和方法名。配置的协议是对应于服务预设的。

步骤706，根据配置的协议确定所使用的协议。

本实施例中，使用的协议可以是分布式协议任意一种，如.NETRemoting、WebService或WCF。

步骤708，采用所确定的协议实现客户端代理，实现传递包括所述业务信息的信息。

针对不同的服务，不同的协议有具体的代理实现。下文将结合图8对协议在两端的实现进行详细说明。

在服务器端，包括：

步骤710，采用所确定的协议实现服务器端的代理，实现传递包括所述业务信息的信息。

步骤712，处理所接收的业务信息。服务器端接到业务信息后，利用服务器上的业务逻辑进行处理，得到处理结果。下文将结合图9对服务器上的业务处理进行详细说明。

步骤714，返回处理结果。将处理结果返回给调用SOA的应用程序即可。

由上可以看出，步骤704和步骤706在服务的通信之前提供了协议选择。而步骤708和步骤710为具体通信的步骤。步骤712完成了服务在服务器上的实现。最终由步骤714返回结果，完整的实现了SOA的服务的分布式部署。而服务组件和具体的协议之间并没有直接绑定，对于客户端的应用程序来说，整个过程是透明的，而对于服务开发人员来说，同样的不需要考虑协议的实现。从而实现了SOA和协议的无关。

下面结合图8对实现通信的步骤708和步骤710进行详细说明。

客户端的处理步骤包括：

步骤7082，选取代理实现。对于同一个协议，不同服务可能需要不同的代理实现。在本步骤中将为服务选择具体的代理实现。在本实施例中，代理实现和服务的对应关系是预设的。可以由服务开发人员或平台开发人员指定，也可以根据平台环境进行选择。

步骤7084，读取所选取的包括对应协议的代理实现。根据选择的代理实现，读取代理实现的具体内容。本实施例中，代理实现包含了实现通信的具体细节，例如端口号和通道类型等。不难理解，代理实现可以是采用配置文件的方式，也可以是其它的可以描述通信实现细节的其它方式。

步骤7086，采用所选取的对应协议的代理实现，实现客户端代理。因为代理实现已经描述了通信的实现细节，本步骤可以完整的实现客户端的代理。还包括在客户端伪装为远程对象并向本地提供远程对象相同的接口。

在另一个实施例中，步骤7086后还包括：将传递的信息强制转化成为预设的标准格式。由此实现了协议两端交换信息格式的标准化。

服务器端的处理步骤包括；

步骤710，采用所选择的协议实现服务器端的代理。包括反序列化远程对象等通信的具体实现。

由上可以看出，步骤708的三个子步骤完成了在客户端建立通信的步骤。步骤708配合步骤710完成了协议两端之间通信的建立。

下面结合图9详细说明实现业务信息处理的步骤712的流程，包括以下步骤：

步骤7122，读取业务信息。在本实施例中，包括读取业务数据(CustomerID和OrderDate)和方法名(方法Do)等。

步骤7124，选择所要调用的业务逻辑。

对于同一个方法可以有多个实现的业务逻辑。在这里实现了业务逻辑的选择。例如在本实施例中，方法(Do)可以有2个具体的业务逻辑实现，即PlaceOrderStrategy1和PlaceOrderStrategy2，通过本步骤确定出具体所选择的业务逻辑。

步骤7126，确定调用业务逻辑的接口。接口是多个方法(Do)的集合。通过调用业务逻辑的实现接口就可以调用其中的方法(Do)。

步骤7128，根据所述业务逻辑的接口调用业务逻辑处理所读取的业务信息。

由上可以看出，经过这四个步骤完成了业务信息的整个处理过程。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种协议无关的SOA系统，其特征在于，包括客户端和服务器端，其中：

客户端包括：

编程代理(302)，用于接收业务信息和配置的协议；

协议选择器(304)，用于根据所述配置的协议确定所使用的协议；

协议客户端(306)，用于采用所确定的协议实现客户端代理，以传递包含所述业务信息的信息；

服务器端包括：

协议服务器端(308)，用于采用所确定的协议实现服务器端代理，以传递包含所述业务信息的信息；

业务处理器(310)，用于处理所接收的业务信息。

2.如权利要求1所述系统，其特征在于，所述协议客户端(306)包括：

代理实现选择器(3062)，用于选取代理实现；

代理实现库(3064)，用于提供对应不同协议的不同代理实现；

客户端代理(3066)，用于采用所选取的对应所确定的协议的代理实现，实现客户端代理。

3.如权利要求1或2所述系统，其特征在于，所述协议客户端(306)还包括：

客户端接口(3068)，用于将包含所述业务信息的信息的格式进行标准化。

4.如权利要求2所述系统，其特征在于，所述业务处理器(310)包括：

业务操作(3102)，用于读取业务信息；

业务接口(3106)，用于提供调用业务逻辑的接口；

业务逻辑实现(3108)，用于根据所述业务逻辑的接口调用业务逻辑处理所读取的业务信息。

5.如权利要求4所述系统，其特征在于，所述业务处理器(310)还包括：

业务逻辑实现选择器(3104)，用于选择所要调用的业务逻辑。

6.一种协议无关的SOA的业务处理方法，其特征在于，包括客户端和服务器端的处理，其中：

客户端的处理包括：

A，接收业务信息和配置的协议；

B，根据配置的协议确定所使用的协议；

C，采用所确定的协议实现客户端代理，传递包含所述业务信息的信息；服务器端的处理包括：

D，采用所确定的协议实现服务器端代理，传递包含所述业务信息的信息；

E，处理所接收的业务信息。

7.如权利要求6所述方法，其特征在于，步骤C所述采用所确定的协议实现客户端代理的步骤包括：

C1，选取代理实现；

C2，读取所选取的包括对应协议的代理实现；

C3，采用所读取的包括对应所确定协议的代理实现，实现客户端的代理。

8.如权利要求6或7所述方法，其特征在于，步骤C所述传递前还包括：

将所要传递的包含所述业务信息的信息的格式进行标准化处理。

9.如权利要求6所述方法，其特征在于，步骤E中处理所接收的业务信息的步骤包括：

E1，读取业务信息；

E2，确定调用业务逻辑的接口；

E3，根据所述业务逻辑的接口调用业务逻辑处理所读取的业务信息。

10.如权利要求9所述方法，其特征在于，所述步骤E1和E2之间还包括：选择所要调用的业务逻辑。

Images