专利名称：协议无关的soa系统和业务处理方法
技术领域：
本发明涉及一种S0A技术领域，特别是指一种协议无关的S0A 系统和业务处理方法。
背景技术：
SOA是一种粗粒度、松耦合服务的架构模型，它可以根据需求通 过网络对松散耦合的粗粒度应用服务组件进行分布式部署、组合和 使用。并且服务之间可通过简单、精确、标准的协议和接口定义语 言进行通信与互操作，不涉及底层编程接口和通信模型。理想的是 平台中将各种功能以粗粒度的服务表示出来，每种服务都能清晰地表示其技术或业务价值，在应用实现过程中，可以通过对服务的动 态组装来适应用业务需求的动态变化。企业月良务总线ESB (Enterprise Service Bus)是S0A架构的一 个支柱技术。它是一种开放的、基于标准的消息处理机制，通过筒 单的标准适配器和接口，来完成粗粒度应用(比如服务)和其他组 件之间的互操作。作为一种消息代理架构它提供消息队列系统，使 用诸如SOAP或JMS (Java Message Service)等标准技术来实现。一 般地，ESB的主要功能包括通信和消息处理、服务交互和安全性控 制、服务质量和服务级别管理、建模、管理和自治、基础架构等。例如目前通常采用远程调用(Remoting)，实现两个应用程序之 间对象的通信流程是首先，客户端通过远程调用系统，访问通道 以获得服务端对象，再通过代理解析为客户端对象。这可以实现以 服务的方式来发布服务器端对象。也就是说远程对象代码可以在服 务器上运行，然后客户端再通过远程调用系统连接服务器，获得该 服务对象并通过序列化在客户端运行。这样通过获得服务器端对象的引用来实现远程调用的目的，也就实现了客户端和服务器端有关 对象的松散耦合。但是目前常用的系统或方法，并不能真正实现松散耦合的粗粒度应用服务组件的分布式部署。例如所使用的协议发生改变或者SOA 的系统中使用了多个不同平台甚至多个协议的话，传统的系统和方 法是不能胜任的。例如需要提供的端口号和通道类型等信息将随着 协议的变化而发生变化，而这些是和服务绑定在一起的。如果可以 将协议和服务相分离，即实现服务和协议无关的话，将有效提高代 码复用性，并使得服务的开发人员只需专注于服务的业务模型等业 务上的开发，从而降低开发难度。发明内容有鉴于此，本发明的主要目的在于提供一种协议无关的S0A系统 和业务处理方法，以实现S0A架构的服务和协议无关。本发明提供了协议无关的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包括Cl,选取代理实现；C2，读取所选取的包括对应协议的代理实现；C3,采用所选取的对应协议的代理实现，实现客户端代理。由上可以看出，步骤Cl和步骤C2为确定的协议和服务选择和读取具体的描述了代理实现细节的代理实现。而由步骤C3完成代理在客户端的完整实现。优选的是，所述步骤C所述传递前还包括将所要传递的包含所述业务信息的信息的格式进行标准化处理。。由上可以看出，实现了在协议两端信息交换格式的标准化。 优选的是，步骤E中处理所接收的业务信息的步骤包括 El,读取业务信息；E2,确定调用业务逻辑的接口；E3,根据所述业务逻辑的接口调用业务逻辑处理所读取的业务信自、由上可以看出，远程对象是业务信息的载体，步骤E1完成业务 信息的读取后，由步骤E2和E3完成服务在服务器端的业务逻辑的 具体实现。优选的是，所述步骤El和E2之间还包括选择所要调用的业务 逻辑；由上可以看出，对于一个方法有多个业务逻辑实现的情况，通过 增加步骤Ell可以对多个业务逻辑进行选择。这样对于客户端的应 用程序不需要考虑具体实现，而只需要提供方法名就可以了。而且 因为真正的处理选择在服务器端，还可以实现在服务器端对业务信 息处理的集中控制。
图1为实施例中.NET Remoting协议的示意图；图2为实施例中WebService协议的示意图；图3为协议无关的S0A系统300的示意图；图4为协议客户端306和协议服务器端308的示意图；图5为带客户端接口的实施例的协议客户端306的示意图；图6为业务处理310的示意图；图7为协议无关的SA0的业务处理方法的流程图；图8为步骤708和步骤710实现通信的流程图；图9为步骤712实现业务信息处理的流程图。
具体实施方式
通常的，Web编程模型提供使用分布式通信编程框架生成Web样 式服务所需的基本框架元素。而本发明SOA系统实现了一种与底层 协议和分布式对象协议无关的面向服务的编程模型。通过本发明，在如.NET的平台上，如微软(Microsoft )等公司已经提供了多种分 布式协议，如WebService编程才莫型或.NET Remoting编程模型，和 已经才是供的更先进的编禾呈才莫型，^口 Windows Communication Foundation以及任何将来可能出现的编程模型，这些对本发明SOA 系统来说，都可以进行统一处理。本发明SOA系统实现了基于业务的分布式对象协议或服务协议。本发明SOA系统中，实现通信的协议客户端和协议服务器端包Locator)、读取所确定出的代理实现的具体内容的代理实现库 (Proxy Repository)、根据读取的代理实现的具体内容实现在客 户端/服务器端代理的客户端代理(Proxy )和服务器端存根(Stub )。其中，所采用的协议可以由WebService、 . NET Remoting或WCF (Windows Communication Foundation)实现。下面举例说明如图1所示为采用.NET Remoting协议的示意图，包括.NET Remoting代理实现选择器102 (.NET Remoting Locator) 、 .NET Remoting代理实现库104 (.NET Remoting Repository) .NET Remoting的客户端代理106/服务器端存才艮108 (.NET Remoting Proxy/Stub )。如图2所示为采用WebService协议的示意图，包括WebService 代理实现选择器202 (WebService Locator) 、 WebService代理实 现库204 (WebService Repository )和具体的WebService的客户 端代理206/服务器端存根208 (WebService Proxy/Stub)。同理，采用WCF协议可由WCF代理实现选4奪器(WCF Locator)、 WCF代理实现库(WCF Repostiory)和具体的WCF的客户端代理/服 务器端存根(WCF Proxy/Stub)构成。不难理解的是，采用以上3个协议仅为举例，也可以采用其它协 议构成类似的模式实现协议客户端和协议服务器端的通信，在此不 一一详述。对于本发明的协议无关的S0A系统实现编程模型时，需要首先建 立业务接口 (Business Interface),然后针对这个业务接口，给出 一个或多个业务逻辑实现(Strategy Implementation)。由协议无关 的SOA系统提供一个公共的协议选择器(Service Locator),然后 为每个业务接口自动生成编程代理(Agent )、实现客户端接口 (CI ient Interface )的客户端代理(Proxy )、服务器端存根(Stub )、 业务操作(Business Operation)和业务逻辑选择器(Strategy Selector)等。其中业务逻辑实现选择器允许修改生成的代码。在 下文具体介绍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. Wr i teLine (o. ToStr ing ()); }上述示例是采用CH吾言的下订单程序，不难理解，也可以采用其它编程语言描述该应用程序。对于本发明协议无关的S0A系统300,其客户端包括 编程代理302,用于接收业务信息和配置的协议。 在本实施例中，从客户端的应用程序接收业务信息和配置的协 议。接收的业务信息包括业务数据(如所述应用程序中描述的用户 ID-CustomerID和订单数据-OrderData )和所调用的方法名(Do )。 配置的协议是订单业务(IPlaceOrder )所属服务的所配置的协议。 不难理解，如果调用多个方法，例如Dol和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和协议服务器端"8,井中协议客户端306，包括代理实现选择器3062,用于选择代理实现。在本实施例中包括查看并选取下文对客户端代理3066描述中的代理实现库3064，用于提供包括对应不同协议的不同代理实现。代理实现库中存储了不同协议的不同代理实现，例如是不同的配 置文件。在本实施例中，为每个服务都预设了特定的配置文件，配 置文件中包含了端口号和通道类型等代理实现细节。客户端代理3066，用于采用所选取的对应所确定的协议的代理 实现，实现客户端代理。例如，当采用.NET Remoting客户端^理时，其示例如下 public class PlaceOrderRemotingProxy : MarshalByRefObject/* or RemoteCUentProxy */， IPlaceOrder { public object Do(string customerID， OrderData order) { PlaceOrder po = new PlaceOrder(); // or other standard method to access server side object. po. CustomerID = customerID; // here we transform BusinessData to BusinessEntity. OrderEntity entity = new OrderEntity; entity.Order ID = order.Order ID; po. Do(); J J又如，当采用WebService客户端4气理时，其示例如下 public class PlaceOrderWSProxy : HttpSoapClientProxy/* or other goody */， IPlaceOrder { public object Do (string customerID， OrderData order) { return base. Invoke (new object [] {customerlD, 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妄口 。图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 0 { IPlaceOrderStrategy strategy = PlaceOrderSelector. Select (this); stragegy. Do(this); } }业务逻辑选择器3104,用于选择所要调用的业务逻辑。 在本实施例中，方法(Do)的实现有多种业务逻辑。例如对不同 客户可以有不同的费用折扣率。以下是业务逻辑选择器3104的示例 // Generate initial code public partial class PlaceOrderSelector { public static IPlaceOrderStrategy Select (PlaceOrder order) { // please write your code here. - } }业务接口 3106,用于提供调用业务逻辑的接口。业务接口 3106和客户端接口 3068 —样，也可以看成是方法(Do)的集合，其暴露了业务逻辑实现的接口。可以采用0#的Interface 实现。以下是服务器端业务接口 3106的示例 public interface IPlaceOrderStrategy { object Do(PlaceOrder placeOrder); }业务逻辑实现3108,用于根据所述业务逻辑的接口调用业务逻 辑处理所读取的业务信息。在本实施例中，方法(Do )有2个订单业务逻辑 (PlaceOrderStrategy ) 的业务逻辑实现。分别是 PlaceOrderStrategyl和Place0rderStrategy2。以下是PlaceOrderStrategyl的示例 // Generate initial code public partial class PlaceOrderStrategyl : IPlaceOrderStrategy { public object Do (PlaceOrder po) {} }以下是Place0rderStrategy2的示例 // Generate initial code public partial class Place0rderStrategy2 : IPlaceOrderStrategy { public object Do (PlaceOrder po)由上就完成了服务在服务器上的实现，在本实施例中即为远程对 象代码在服务器上的运行。然后将运行得到的结果返回给客户端即可。以上的各个代码示例采用的是0#语言，但不难理解的是，本发明的系统也可以用其它语言实现。下面结合附图和在客户端下订单的示例(参见系统实施例中的客户端程序示例)对协议无关的SAO业务处理方法进行详细说明。如图7所示为协议无关的SAO业务处理方法的流程图，包括以下 步骤步骤702,应用程序调用S0A。对于应用程序来说，SOA的分布式服务是透明的。也就是说，虽 然在本实施例中，下订单的方法(Do)的真正的业务逻辑实现是在 服务器上实现的。但是对于客户端的应用程序来说，并没有什么不 同。所述方法在客户端的处理，包括 步骤704，接收业务信息和配置的协议。从客户端的应用程序接收到需要处理的业务信息和配置的协议。 在本实施例中，业务信息包括业务数据和方法名。配置的协议是对 应于服务预设的。步骤706，根据配置的协议确定所使用的协议。本实施例中，使用的协议可以是分布式协议任意一种，如.NET Remoting、 WebService或WCF。步骤708，采用所确定的协议实现客户端代理，实现传递包括所 述业务信息的信息。针对不同的服务，不同的协议有具体的代理实现。下文将结合图 8对协议在两端的实现进行详细说明。在服务器端，包括步骤710,采用所确定的协议实现服务器端的代理，实现传递包 括所述业务信息的信息。步骤712，处理所接收的业务信息。服务器端接到业务信息后，利用服务器上的业务逻辑进行处理，得到处理结果。下文将结合图9 对服务器上的业务处理进行详细说明。步骤714,返回处理结果。将处理结果返回给调用S0A的应用程 序即可。由上可以看出，步骤704和步骤706在服务的通信之前提供了协 议选择。而步骤708和步骤710为具体通信的步骤。步骤712完成 了服务在服务器上的实现。最终由步骤714返回结果，完整的实现 了 S0A的服务的分布式部署。而服务组件和具体的协议之间并没有 直接绑定，对于客户端的应用程序来说，整个过程是透明的，而对 于服务开发人员来说，同样的不需要考虑协议的实现。从而实现了 SOA和协议的无关。下面结合图8对实现通信的步骤708和步骤710进行详细说明。客户端的处理步骤包括步骤7082，选取代理实现。对于同一个协议，不同服务可能需 要不同的代理实现。在本步骤中将为服务选择具体的代理实现。在 本实施例中，代理实现和服务的对应关系是预设的。可以由服务开 发人员或平台开发人员指定，也可以根据平台环境进行选择。步骤7084,读取所选取的包括对应协议的代理实现。根据选择 的代理实现，读:f又代理实现的具体内容。本实施例中，代理实现包 含了实现通信的具体细节，例如端口号和通道类型等。不难理解， 代理实现可以是采用配置文件的方式，也可以是其它的可以描述通 信实现细节的其它方式。步骤7086,釆用所选取的对应协议的代理实现，实现客户端代 理。因为代理实现已经描述了通信的实现细节，本步骤可以完整的 实现客户端的代理。还包括在客户端伪装为远程对象并向本地提供 远程对象相同的4^口。在另一个实施例中，步骤7086后还包括将传递的信息强制转 化成为预设的标准格式。由此实现了协议两端交换信息格式的标准 化。服务器端的处理步骤包括；步骤710,采用所选择的协议实现服务器端的代理。包括反序列 化远程对象等通信的具体实现。由上可以看出，步骤708的三个子步骤完成了在客户端建立通信 的步骤。步骤7 08配合步骤710完成了协议两端之间通信的建立。下面结合图9详细说明实现业务信息处理的步骤712的流程，包 括以下步骤步骤7122,读取业务信息。在本实施例中，包括读取业务数据 (CustomerID和OrderDate )和方法名(方法Do)等。 步骤7124，选择所要调用的业务逻辑。对于同 一个方法可以有多个实现的业务逻辑。在这里实现了业务 逻辑的选#^。例如在本实施例中，方法(Do)可以有2个具体的业 务逻辑实现，即PlaceOrderStrategyl和Place0rderStrategy2，通 过本步骤确定出具体所选择的业务逻辑。步骤7126，确定调用业务逻辑的接口。接口是多个方法(Do) 的集合。通过调用业务逻辑的实现接口就可以调用其中的方法(Do )。步骤7128,根据所述业务逻辑的接口调用业务逻辑处理所读取 的业务信息。由上可以看出，经过这四个步骤完成了业务信息的整个处理过程。以上所述仅为本发明的较佳实施例而已，并不用以限制本发明， 凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进 等，均应包含在本发明的保护范围之内。
权利要求
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所述采用所确定的协 议实现客户端代理的步骤包括Cl,选取代理实现；C2，读取所选取的包括对应协议的代理实现；C3,采用所读取的包括对应所确定协议的代理实现，实现客户端的代理。
8. 如权利要求6或7所述方法，其特征在于，步骤C所述传递前还包括将所要传递的包含所述业务信息的信息的格式进行标准化处理。
9. 如权利要求6所述方法，其特征在于，步骤E中处理所接收的业务 信息的步骤包括El，读取业务信息；E2,确定调用业务逻辑的接口；E3，根据所述业务逻辑的接口调用业务逻辑处理所读取的业务信息。
10. 如权利要求9所述方法，其特征在于，所述步骤E1和E2之间还 包括选择所要调用的业务逻辑。
全文摘要
本发明提供了一种协议无关的SOA系统，包括客户端和服务器端，其中客户端包括编程代理，用于接收业务信息和配置的协议；协议选择器，用于根据所述配置的协议确定所使用的协议；协议客户端，用于采用所确定的协议实现客户端代理，以传递包含所述业务信息的信息；服务器端包括协议服务器端，用于采用所确定的协议实现服务器端代理，以传递包含所述业务信息的信息；业务处理器，用于处理所接收的业务信息。还相应提供了一种协议无关的SOA的业务处理方法。使用本发明，可以实现SOA架构的服务和协议无关。
文档编号H04L29/06GK101409717SQ200810227919
公开日2009年4月15日 申请日期2008年12月1日 优先权日2008年12月1日
发明者豪 方 申请人:用友软件股份有限公司