通过可定制通信信道和程序设计模型对消息的发送和接收转让专利
申请号 : CN200410031765.8
文献号 : CN1533117B
文献日 : 2010-06-02
发明人 : Y·E·克里斯腾森 , R·T·斯图吉尔 , E·B·克里斯腾森 , J·鲁伊兹-斯考格尔 , A·德加那特 , M·J·马鲁切克
申请人 : 微软公司
摘要 :
用于在消息传递架构中抽象处理层的方法、系统和计算机程序产品，以使能够对架构作出改变和提高而同时保留现有的功能。消息传递实现在消息层中被抽象，允许架构中的其他层以一种更普通的方式与消息进行互动，大大独立于消息传递。传递的范例包括命名管道、传输控制协议(TCP)、超文本传输协议(HTTP)、简单邮件传输协议(SMTP)等等。消息层上的信道层抽象消息交换实现，允许架构中的其他层以一种更普通的方式发送并接收消息，大大独立于指定实现的消息交换语义。消息交换的范例包括数据报、对话、独白、队列等等。在信道层和消息层之上，服务层抽象把消息交换实现捆绑至用户码实现的捆绑实现。
权利要求 :
1.一种在包括为处理一个或多个消息提供特定初始功能的多个处理层的消息传递架构中抽象所述多个处理层的方法，以使之后可对所述消息传递架构作出改变和提高而同时保留所述特定的初始功能，该方法包括下列步骤：在消息层中，抽象一个或多个消息传递实现，以用于所述消息传递架构中的一个或多个其他层，从而所述消息层向所述架构中的其他层提供原子的消息发送/接收抽象，以使其他层能够以某种独立于发送或接收消息所使用的特定传递协议的方式处理消息；
在所述消息层上的信道层中，抽象一个或多个消息交换实现，以用于所述消息传递架构中的一个或多个其他层，以便允许所述架构中的其他层以一种更普遍的方式发送和接收消息，大大独立于特定消息交换实现的消息交换语义；以及在所述信道层上的服务层中，抽象一个或多个捆绑实现，用于把所述一个或多个消息交换实现捆绑至与使用所述消息传递架构的一个或多个消息处理实现相对应的用户码。
2.如权利要求1所述的方法，其特征在于，所述服务层的接口至少部分地描述了使用所述消息传递架构的程序设计模型。
3.如权利要求1所述的方法，其特征在于，所述消息层抽象、信道层抽象和服务层抽象中的每一个都对应于用于所述一个或多个消息传递实现、所述一个或多个消息交换实现以及所述一个或多个捆绑实现的多个程序模块。
4.如权利要求1所述的方法，其特征在于，所述消息层抽象还抽象一个或多个端口，端口中的每一个都提供原子的消息发送/接收抽象。
5.如权利要求4所述的方法，其特征在于，所述消息传递架构包括所述一个或多个消息交换实现的一个或多个实例以及所述一个或多个消息处理实现的一个或多个实例，其中所述一个或多个捆绑实现包括一个或多个服务捆绑实现，所述一个或多个服务捆绑实现使用一个或多个服务代理实例把各个消息交换实例捆绑至对应的消息处理实例。
6.如权利要求5所述的方法，其特征在于，所述服务层抽象还抽象一服务存储器实现，该服务存储器实现管理所述一个或多个消息处理实例的物理寿命。
7.如权利要求1所述的方法，其特征在于，所述一个或多个消息交换实现包括至少下列之一(i)用于单向不相关信息传递的数据报信道，(ii)用于双向相关消息传递的对话信道，(iii)用于单向广播消息传递、包括公布/预定消息传递的独白信道，以及(iv)用于单向队列消息传递的队列信道。
说明书 :
技术领域
本发明涉及消息传递架构。更具体地说，本发明涉及在消息传递架构中抽象处理层的方法、系统以及计算机程序产品，其可以在不重新实现现有的功能的情况下进行改变和提高。
背景技术
随着许多当今的强大的网络提供的计算机之间互联性的增加，分布式处理在很大范围的应用程序中变得越来越有吸引力。然而，大多数现有的用于发展分布式应用程序的架构提供很小的灵活性，以从现有的和新兴的通信技术中进行选择的形式出现。例如，程序设计模型、消息交换语义以及消息传递趋向于紧密地结合。结果，选择其中的任何一个，经常同时指定其他的。
图1A说明了现有技术的一例，其是基于分布式组件对象模型(DCOM)的紧密结合的消息传递架构(infrastructure)100A。DCOM是组件对象模型(COM)的扩展，它允许组件既可在网络边界之内也可跨过网络边界进行通信，而COM限于单个机器内进程间的通信。期望使用DCOM的开发者接受DCOM程序设计模型130A、远程过程调用(RPC)消息交换语义120A以及对应的RPC网络连接(network connectoids)110A作为一个捆绑。
图1B说明了现有技术的另一例，其是紧密结合的消息传递架构100B。类似于图1A所示的DCOM架构，这个消息传递架构100B包括其他程序设计模型130B、其他消息交换语义120B以及其他网络连接110B。注意其他程序设计模型130B、其他消息交换语义120B以及其他网络连接110B的互锁部分121B不同于DCOM程序设计模型130A、RPC消息交换语义120A以及RPC网络连接110A的互锁部分121A。互锁部分121A和121B之间的差异说明了现有技术缺乏从现有的以及新兴的用于研发分布式应用程序的选项中进行选择的灵活性。在选择了DCOM或者一些其他的技术以及其对应的架构后，使用来自其他技术的特征并且不牺牲研发现存应用程序的成果就成了一项相当困难的任务。通常，这样技术改变或增强要求重新开始，基本上是从零开始。
因此，分离程序设计模型、消息交换语义以及消息传递表示出本技术领域内的进步。开发者能够从架构内的一个层面中的特征进行提取而不必担心在另一层面中不相关的问题。此外，开发者能从一个程序设计模型移动到另一个而不需要获悉新的架构。分离各层导致较大的复用性并鼓励了创新，因为被分离的架构中的改变和提高能够保留现有的开发成果。
图1A说明了现有技术的一例，其是基于分布式组件对象模型(DCOM)的紧密结合的消息传递架构(infrastructure)100A。DCOM是组件对象模型(COM)的扩展，它允许组件既可在网络边界之内也可跨过网络边界进行通信，而COM限于单个机器内进程间的通信。期望使用DCOM的开发者接受DCOM程序设计模型130A、远程过程调用(RPC)消息交换语义120A以及对应的RPC网络连接(network connectoids)110A作为一个捆绑。
图1B说明了现有技术的另一例，其是紧密结合的消息传递架构100B。类似于图1A所示的DCOM架构，这个消息传递架构100B包括其他程序设计模型130B、其他消息交换语义120B以及其他网络连接110B。注意其他程序设计模型130B、其他消息交换语义120B以及其他网络连接110B的互锁部分121B不同于DCOM程序设计模型130A、RPC消息交换语义120A以及RPC网络连接110A的互锁部分121A。互锁部分121A和121B之间的差异说明了现有技术缺乏从现有的以及新兴的用于研发分布式应用程序的选项中进行选择的灵活性。在选择了DCOM或者一些其他的技术以及其对应的架构后，使用来自其他技术的特征并且不牺牲研发现存应用程序的成果就成了一项相当困难的任务。通常，这样技术改变或增强要求重新开始，基本上是从零开始。
因此，分离程序设计模型、消息交换语义以及消息传递表示出本技术领域内的进步。开发者能够从架构内的一个层面中的特征进行提取而不必担心在另一层面中不相关的问题。此外，开发者能从一个程序设计模型移动到另一个而不需要获悉新的架构。分离各层导致较大的复用性并鼓励了创新，因为被分离的架构中的改变和提高能够保留现有的开发成果。
发明内容
本发明涉及用于在消息架构中抽象处理层的方法、系统和计算机程序产品，其后可对该架构进行改变和提高而保留现有的功能。按照本发明的示范实施例，其将在下面更完整地描述，该架构包括三个主要层：一消息层、一信道层以及一服务层。这些层中的每一个能抽象功能，因此特定实现的细节一般而言对于其它层是隐藏的。
在一个示范实施例中，消息传递实现在一消息层中被抽象，允许该架构中的其它层以一种更加普通的方式与消息进行交互，大大独立于消息传递。消息传递的例子包括命名管道、传输控制协议(TCP)、超文本传输协议(HTTP)、简单邮件传输协议(STMP)等等。消息层之上的信道层抽象消息交换实现，允许架构中的其它层以一种更普通的方式发送并接收消息，大大独立于特定消息交换实现的消息交换语义。消息交换实现的例子包括数据报、对话、独白、队列等等。在信道层和消息层上，服务层抽象捆绑实现，它把消息交换实现捆绑到使用该架构的用户码实现(例如，应用程序)上。服务层至少部分描述了一用于使用该消息传递架构的程序设计模型。
每一层的抽象都可对应于用于抽象实现的多个程序模块。消息层抽象可抽象端口，它为消息提供的原子的发送/接收抽象。对于每个抽象实现而言，架构都可包括该抽象的一特定实例，它表示在该架构中使用的实现。例如，一个信道抽象的实例可被限制在用于处理消息的服务或者用户码实现的实例。捆绑可通过用于信道和用户码实现的代理来进行。当消息通过实例和服务代理时，它们可被拦截并被进一步处理。服务层抽象可以抽象服务存储实现，它管理服务或这用户码实例的物理寿命。
本发明另外的特征和优势将在下面的描述中说明，其中部分将通过描述而变得明显，或者可以通过实现本发明而习得。本发明的特征和优势可通过附加的权利要求中指出的装置以及组合而被认识到或者被获得。本发明的这些以及其它的特征将通过以下的描述以及附加的权利要求而变得更加明显，或者可以通过按照此后的说明来实现本发明而习得。
在一个示范实施例中，消息传递实现在一消息层中被抽象，允许该架构中的其它层以一种更加普通的方式与消息进行交互，大大独立于消息传递。消息传递的例子包括命名管道、传输控制协议(TCP)、超文本传输协议(HTTP)、简单邮件传输协议(STMP)等等。消息层之上的信道层抽象消息交换实现，允许架构中的其它层以一种更普通的方式发送并接收消息，大大独立于特定消息交换实现的消息交换语义。消息交换实现的例子包括数据报、对话、独白、队列等等。在信道层和消息层上，服务层抽象捆绑实现，它把消息交换实现捆绑到使用该架构的用户码实现(例如，应用程序)上。服务层至少部分描述了一用于使用该消息传递架构的程序设计模型。
每一层的抽象都可对应于用于抽象实现的多个程序模块。消息层抽象可抽象端口，它为消息提供的原子的发送/接收抽象。对于每个抽象实现而言，架构都可包括该抽象的一特定实例，它表示在该架构中使用的实现。例如，一个信道抽象的实例可被限制在用于处理消息的服务或者用户码实现的实例。捆绑可通过用于信道和用户码实现的代理来进行。当消息通过实例和服务代理时，它们可被拦截并被进一步处理。服务层抽象可以抽象服务存储实现，它管理服务或这用户码实例的物理寿命。
本发明另外的特征和优势将在下面的描述中说明，其中部分将通过描述而变得明显，或者可以通过实现本发明而习得。本发明的特征和优势可通过附加的权利要求中指出的装置以及组合而被认识到或者被获得。本发明的这些以及其它的特征将通过以下的描述以及附加的权利要求而变得更加明显，或者可以通过按照此后的说明来实现本发明而习得。
附图说明
为了说明能够获得本发明的上述的以及其它的优势和特征的方式，将结合附图中说明的特定实施例对上述的本发明的简要说明进行更加仔细地描述。需要理解，这些附图仅仅说明本发明的典型的实施例且不能因此而理解为限制了其范围，本发明将通过下列的附图而结合附加的说明和细节来加以描述和解释：
图1A-1B说明了现有技术中紧密结合的消息传递架构的范例；
图2说明了按照本发明的消息传递架构的高级表示；
图3是示出按照本发明的消息传递架构的示范实施例的框图；
图4A-4B示出在按照本发明的消息传递架构中抽象处理层的方法的示范动作和步骤；以及
图5说明了适用于本发明的适当操作环境的示范系统。
图1A-1B说明了现有技术中紧密结合的消息传递架构的范例；
图2说明了按照本发明的消息传递架构的高级表示；
图3是示出按照本发明的消息传递架构的示范实施例的框图；
图4A-4B示出在按照本发明的消息传递架构中抽象处理层的方法的示范动作和步骤；以及
图5说明了适用于本发明的适当操作环境的示范系统。
具体实施方式
本发明包括用于在消息传递架构中抽象处理层的方法、系统以及计算机程序产品，其后可对该架构进行改变或提高而不必要重新实现现有的功能。本发明的实施例可包括一个或多个专用计算机以及/或者一个或多个通用计算机，计算机包括多种计算机硬件，将在下面详细描述。
图2说明了按照本发明的一个示范消息传递架构200的高级表示。下面结合图5提供了关于消息传递架构的示范实现的详细说明。架构200通过分层的结构(例如，该架构可被视为子系统的顺序集合，其中每个子系统都取决于前面的子系统)支持分布式程序设计。例如，在消息传递架构200中，主要层包括消息传递层210、信道层240以及服务层270。
如下面将要详细描述的，这些层中的每一个抽象特定的实现细节，使得以共同方式处理类似的事情。消息分离程序设计模型、消息交换语义和消息传递以使开发者能够从架构内的一个层面上提取特征而不必担心另一层面上不相关的问题。这样，开发者就能够，例如从一个程序设计模型移到另一个而不需要获悉新的架构。该抽象造成较大的再用性并且鼓励创新，因为在被分离的架构中进行改变和提高允许保留现有的开发成果。
底层，即消息传底层210提供端点对端点的传输或消息传递。消息传递层210支持传递扩展性，这样当实现新的传递时，新的传递可被该架构中的其它层使用。例如，消息传递层210抽象传递协议的实现，例如命名管道、传输控制协议(TCP)、超文本传输协议(HTTP)、简单邮件传输协议(TCP)等等。因此，简单地说，消息传递层210向架构中的其它层提供了原子的消息发送/接收抽象，以使其它层能够以某种独立于发送或接收消息所使用的特定传递协议的方式处理消息。
消息传递层210允许在消息离开或到达端点时对其可扩展的拦截。可扩展的拦截机制可用于实现诸如路由、过滤、策略管理和安全性这样的行为。消息层210中的端点处可用的传递和行为都能被计划性地建立或者通过配置来建立。
信道层240在消息传递层210所提供的传递抽象顶上提供消息传递抽象。信道表示端点间实现的行为以及抽象所实现的行为的对象模型。一般信道的例子包括用于单向不相关消息传递的数据报信道、用于双向相关消息传递的对话信道、用于公布/预定或单向广播消息传递的独白信道以及用于单向对列消息传递的队列信道。应用程序或者用户码通过在一端点处建立信道实例(例如，存储器中的信道对象)并发送关于那些实例的消息而使用信道。当消息到达另一端点时，应用程序或者用户码识别出在信道发送端建立的信道并建立一信道实例来参与该对话。
服务层270在信道层240和消息传递层210的顶上提供程序设计模型。应用程序的设计者一般会在服务层使用消息传递架构200。服务层程序设计模型之间通过消息分发机制、消息被发送的方式(例如，结构相对类型的方法调用)和系统类型而彼此分开。服务层270提供一个通用机制把程序设计模型捆绑到上述信道实例上。服务层270还提供了程序设计模型选择提供给开发者的特征，例如状态和寿命控制、服务管理、呼叫拦截以及同步消息分发。无论简单的还是复杂的程序设计模型都可以开发用于服务层。为了便于适当的捆绑和互用性，程序设计模型一般会定义消息传递层传输类型以及架构自身中定义并控制的类型之间的固定关系，特别是与服务层270中的应用程序或者用户码对象相对应的类型。
图3是示出按照本发明的消息传递架构300的一个示范实施例的框图。通常，消息传递架构300由用于通过所支持的程序设计模型捆绑信道实例(即，存储器中的信道抽象对象)和编码的实例的模块组成。类似于上述关于图2的描述，图3包括消息传递层310、信道层340和服务层370。图3的描述可以分成两类：消息传递架构自身以及消息传递架构所支持的程序设计模型。以下的讨论从描述消息传递架构开始，接下来转而描述一个示范的程序设计模型。尽管在图3中说明的组件可能是单数，但应该理解，在单个架构中也经常会存在多个各个组件。
三个管理器，每一层内有一个，实现了架构300所提供的大多数基本功能：消息传递层310中的端口312、信道层340中的管理器342以及服务层370中的服务管理器382。因此，图3的描述最初一般集中在这三个管理器上，然后转而更详细地讨论这三个管理器和图示的其他组件。三个管理器中的第一个，端口312，充当传递实现和架构其他部分之间的多路复用代理程序。简单而言，端口312和消息传递层310向消息传递架构300提供了原子的消息发送/接收抽象。如前面所指出的，该抽象减轻了其他层要理解与各个传递实现相关的细节的负担。而且，其他层和消息抽象交互，并把消息如何被传递的细节留给消息传递层310和端口312。
三个管理器中的第二个，即信道层340中的信道管理器342，收集消息并使其相关，可能存储它们并/或对它们排序，并一般向服务层370给出高级的信道抽象，尤其向服务管理器382和服务捆绑器372提供。类似于消息传递层310所提供的消息抽象，这里也一样，信道层340和信道管理器342所提供的信道抽象减轻了其他层需要理解与各个消息交换语义相关的细节中的负担。其他层简单地和信道抽象交互，并把怎样交换消息(例如，数据报，对话，等等)的细节留给信道层340。
三个管理器中的第三个，服务管理器382，负责把服务实例376(按照该程序设计模型的一类实现的实例)连到由信道管理器342所产生的信道实例344，其向对应的服务实例提供信道抽象的实例。服务管理器382通过服务捆绑器372将服务实例376连到信道实例344，服务捆绑器372理解特定信道和程序设计模型两者的细节。如下面将要详细描述的，服务捆绑器372与服务存储器378合作创建并注册实例。
服务管理器382和服务捆绑器372使用服务代理374将服务实例376捆绑到信道实例344，代理服务374也将在下面详细描述。一旦创建了实例，服务存储器378就从架构的其余部分中抽象它们的持久性(例如，寿命等等)和位置。流入服务实例的消息和呼叫可以被与服务管理器382注册的服务扩展392支持的编码所拦截。服务实例通过服务实例上的接口与架构进行通信，称为服务站，其实现了通常由实例所使用的功能。实例的服务站在服务存储器创建实例时被初始化(或定址)。
服务管理器382是用于创建信道并访问架构中其他组件的一组接口，并且是该架构通过其实现配置的实体。当服务管理器被创建时，它创建端口处可用的服务捆绑器、服务存储器以及服务类型，并将它们连结到该架构。如果一个端口能够处理多个服务的请求，则仅仅一单个服务管理器与该端口相关联。尽管传统的架构具有用于创建实例并管理架构协作的某些形式，然而服务管理器382间接地执行其任务，即通过这个工作委派给适合特定任务的其他模块。结果，服务管理器382像架构300的其他组件一样支持高度扩展性，而传统架构中的服务管理器趋向于直接创建实例并管理架构协作，这使得创新变得困难因为可能需要重新实现现有的功能以支持新的行为或功能。
服务捆绑器372负责管理信道实例344、服务实例376和服务存储器378之间的关系。因此，服务捆绑器372一般特别获悉每个可用的信道和程序设计模型。信道实现了服务捆绑器372把消息移入或移出信道层340所使用的特殊事件和接口。程序设计模型指定了类型间的映射关系，服务捆绑器使用上述映射关系把消息应用于方法并且将方法呼叫转换成消息。因为每个信道和程序设计模型是不同的，因此一个服务捆绑器通常支持其中的一个。因此，一个运行的端口一般与每个所支持的信道/程序模型对的一个或多个服务捆绑器相关联。
一示范程序设计模型可在网络服务定义语言(WSDL)端口类型和架构运行期间管理的类型之间建立映射。WSDL是一种XML格式，它把网络服务描述成一组能交换消息的端点。它提供了一种相对简单的机制，用于独立于基础协议(简单对象访问协议-SOAP、HTTP GET/POST等等)或编码(多用途因特网邮件扩展-MIME等等)而指定请求的基本格式。抽象操作和消息被捆绑到指定的网络协议和消息格式来定义一个端点。因此，WSDL服务是端点的集合，也称为端口。在WSDL中，端口类型描述了操作的集合。应该理解，图3说明了本发明的一个示范实施例，其中架构包括映射至WSDL的被管理的编码数据类型。然而，本发明可在多种环境中实现，并不限于那些具有被管理的编码/数据类型或WSDL端口类型的环境。
如上所指出的，服务捆绑器372在端口创建期间向服务管理器382注册。服务捆绑器与一组端口/服务类型相关联。在架构运行期间被管理的类型实现了从对于服务捆绑器唯一的接口类型继承的服务，其使服务捆绑器的类型具有唯一性。对于示范架构300而言，打开端口的相同进程同样打开了服务管理器382以及端口处所有可用的服务捆绑器372。当被打开时，服务捆绑器将他们自己连结到对应的信道管理器342。
当用户码向服务管理器382发出一呼叫以创建一信道时，服务管理器就在所注册的服务捆绑器组上进行迭代并提供每个机会来处理指定的类型。然后，服务管理器使用识别该指定类型的服务捆绑器以创建一服务实例376，将它注册到服务存储器378，并用服务代理374将该服务实例捆绑到信道示例344。类似的，当消息到达一不与现有的服务实例相关联的信道时，如果它们识别出进来的端口/服务类型，则要求附属于信道的服务捆绑器组。识别类型的服务捆绑器372被用于创建一务实例，用服务代理将其捆绑至信道实例，并接下来使进来的消息通过实例和代理流至用户码。
为了产生对新实例的请求，服务捆绑器创建一服务实例376，把它注册到服务存储器378，创建服务代理374，把信道实例344连到服务代理374以及把服务代理374连到服务实例376中的用户码，并触发信道中第一消息的流动。之后，消息从信道实例流向服务代理374，服务代理将消息转换成呼叫栈并将它们分发给相应的服务实例。类似的，呼叫从服务实例376流出流向服务代理374，服务代理374将呼叫转换成消息并通过信道实例将它们发送到它们的目的地。
传统的架构可具有一些形式的服务捆绑器，按照本发明的架构能够支持多个服务捆绑器。另外，与传统的架构相对，服务捆绑器集合作为一个整体独立于其下的信道层，也独立于服务层370中的服务存储器和程序设计模型。传统的架构趋向于在紧密分界的包中实现传递、信道、捆绑、存储以及实例功能，这通常要求在每次为了解决发展的技术和应用需要而作出提高或改变时作出显著的改变。
如上面所指出的，服务存储器378管理实例。当服务捆绑器产生创建新的服务实例的请求时，服务捆绑器就创建一实例并将该实例注册到服务存储器。在创建了实例后，服务捆绑器使用存储器来定址该实例，(初始化通常使用通信接口)，接下来该捆绑器将该信道捆绑至该地址。服务存储器378记录与实例相关的信道数量，并在没有信道附加时释放一实例。这使服务捆绑器(其看见信道关闭消息/事件以及代理实例的释放)能够参与控制逻辑实例(从架构外看到的实例)的寿命。
当捆绑器控制逻辑实例的寿命时，服务存储器378管理物理实例(存储器中真正的对象实例)的寿命。当服务存储器希望从存储器中删除一物理实例时，它会告知相关的信道以使它们将该物理实例从它所关联的服务代理374上断开。接下来，下一次向该实例应用呼叫/消息时，服务存储器就负责创建-新的实例并将它重新连接到适当的代理。
服务存储器378支持一实例状态的多种相关度。服务存储器可能把所有实例维持在存储器中从不使用断开/重连接机制。或者，服务存储器可能把所有实例维持在存储器中并且为了加强实例的无状态性而支持主动的断开/重连接机制。服务存储器可能基于机器负载、许可证发行(例如，到数据库的连接)以及/或者使用模式来支持断开/重连接，并将断开/重连接与实例的无序/编序相结合并将实例保存在交易(transact)数据库中以支持持续的、可靠的实例。服务存储器所使用的数据库可与持久信道所使用的存储器以及端口前的路由器协作，以实现实例从一个机器向另一个机器的转移。服务存储器378在无用单元收集(garbage collection)、集中组合(pooling)、管理长寿命的连接等等中是有用的。
传统架构中的服务存储器趋向于直接连接物理和逻辑实例的寿命。这两者之间的关系一般在架构中被硬编码。结果，替代很难实现而不影响系统中的其他区域。此外，由专家级用户作为扩展点的修改或随着架构发展的修改是不切实际的，假定服务存储器和架构其他部分之间是显著连接的。
如前面所指出的，服务代理374是一服务捆绑器指定类型的实例，它把特定类型的信道实例344连到特定类型的服务实例376。对于进来的呼叫而言，服务从信道宣告消息可用而产生事件，从该消息中创建适当的呼叫栈，并将其应用于该实例。对于出去的呼叫而言，服务代理374产生呼叫，将其转化成消息，如果需要的话将它通过信道实例344发送。根据方向，服务代理374看上去像类型(typed)信道(例如，从服务实例方向)以及被管理的类型代理(例如，从信道实例方向)。
除了其桥接功能以外，在使用服务代理的整个期间还实现了某些行为。例如，一个或多个服务代理可实现并发管理，限制在给定的时刻进入单个服务实例的呼叫数目。如上面关于服务存储器378所指出的，服务代理实现了断开/重连接，以使服务存储器能把物理实例寿命与逻辑实例寿命分离。应该理解，服务代理374允许服务捆绑器372和服务存储器378两者以可扩展的方式来实现行为。
除了端口312、信道管理器342以及服务管理器382以外，架构300中可以有其他管理器。这些管理器实现架构的一些或者全部级别上的行为，包括消息过滤和路由、策略交换和应用、安全性、记录以及交易服务。每一个提供扩展性的管理器定义一个扩展接口以允许其他管理器来实现该扩展性。例如，消息传递层310处的端口312提供了端口扩展，允许管理器为流过该层的流水线消息提供处理机。类似的，各个信道管理器实现扩展以允许类似服务管理器的模块钩住(hook)用于从信道中创建信道实例的消息。
服务扩展392是由服务管理器382定义的接口，其允许其他管理器挂钩连接至(hook into)由架构所支持的呼叫路径扩展点。当扩展第一次被建立时，服务管理器通过服务扩展向感兴趣的管理器传递它所知道的服务类型的反射类型信息。实现服务扩展的管理器将该反射数据和它们自己的配置相结合以建立在特定的消息/呼叫流入或流出服务实例时它们所希望做的。消息前和消息后通知由流经服务扩展的事件传递给管理器。服务扩展机制的这种扩展程度在传统的架构中是没有的。只要架构被配置成一般地支持一行为时，除了与行为相关的管理器以外，不需要修改任何有存储器或其他组件，以便将该行为引入到架构中。
服务实例376是被管理的编码服务类型的实例，其实现与端口/服务类型相关的接口，可能是通过被指定为程序设计模型一部分的包装(wrapper)来实现。通常，如下面将会详细描述的，程序设计模型的一种不同的方法是会话与关于服务类型的接口和方法相关联的方式。如图3所示的示范实施例，相对于有效的程序设计模型编写的服务类型在WSDL会话、操作和消息以及架构运行时间管理的编码接口、方法和自变量类型之间建立直接映射。架构也可以支持使用不同程序设计模型创建服务类型，这些服务类型看上去非常不同。除了由相关联的服务代理使用的接口以外，服务类型可实现其他接口以将它们自己钩接到(hook into)架构行为的其他方面。例如，一服务类型可实现特殊的接口以便钩接至一些服务存储器或者参与由服务扩展实现的一些行为。
如上所述，服务实例376一般被定址(包括对其自身唯一的服务场点的引用)。服务实例通过实现一合适的接口或通过从实现该合适接口的基础类继承而被定址。当服务捆绑器372创建一服务实例时，其使用服务存储器378来定址该实例。然后，服务存储器通过在相应的接口上设置该服务端的属性而定址该实例。该服务端属性提供对该实例架构状态的访问，包括类似于收集连接到该实例的活动信道的事情。该实例可使用状态信息以获取、审查并修改它的信道。该服务存储器也可以在它从该服务实例的活动信道增加或删除信道以使其将该信道捆绑至或从该服务实例上去捆绑时使用该状态信息。
对于图3所示的示范实施例，架构被设计以支持实现从WSDL端口直接映射至用于架构运行时间被管理的编码类型的任何程序设计模型。一示范程序设计模型使用被管理的编码属性以在WSDL类型和被管理的编码类型之间建立关联。这类程序设计模型是由属性修饰的被管理编码类，其描述了被管理的编码类和它们所实现的端口类型的WSLD合同之间的关系。实现程序设计模型的工具或者能从用合适属性修饰的被管理的编码类和接口中生成WSDL，或者能从WSDL生成用适当属性修饰的被管理的编码类和接口。其他程序设计模型可包括远程对象模型、用于描述商业进程的逻辑序列的模型，等等。因此，术语“服务”应该被广泛地解释以覆盖这些及其他程序设计模型。
一个更传统的远程对象模型，例如DCOM，能被认为具有两个接口，一个在对象客户机所使用的代理上实现，另一个在对象自身上实现。关于这两个接口的一申请方法在这类程序设计模型中通常是相同的，尽管每个接口都可能包含合适于会话的一端或另一端的架构方法。
相反，WSDL会话是双向的。其操作或是单独的消息，或是请求/应答消息对，它们可以作为会话一部分在任何方向上流动。为了支持这些操作，示范程序设计模型包括四个接口，两个服务实现接口和两个信道控制接口。会话的每一端有一服务实现接口，该服务实现接口具有会响应消息或请求而运行的编码，会话的每一端还有一信道控制接口，该信道控制接口具有将向外发送消息或请求和事件的代理方法，这些消息或请求和事件可被钩接以增加对到来的消息或请求的处理。
属性可配置管理编码类型至WSDL类型的映射细节以及为运行编码而创建的实例的质量。属性的范例包括确定实例寿命的属性，例如是否为每一消息/请求创建一新的逻辑实例或者逻辑实例的持续是否和连接维持期间同样长。属性可指定一操作是消息还是请求/应答消息对，适当地与属性和编码一起指定方法是同步的还是异步的。其他属性可控制被管理的编码类型中方法和参数的名称以及WSDL操作、消息和部分的名称之间的关系。属性可用于控制将方法呼叫到由该方法呼叫的单独部分包装组成的消息的映射，或者到由每个自变量一部分组成的多部分消息的映射。最终，属性将控制程序设计模型到文档/文字或RPC/编码的消息的映射。同样可能实现编码，要求程序设计模型传递以服务实例为基础的信道实例，但这在WSDL上无效。
本发明同样可以方法的形式描述，该方法包括功能性的步骤和/或无功能性的动作。下面是在实现本发明中可进行的动作和步骤的描述。通常，功能性的步骤以其完成的结果的形式描述发明，而非功能性的动作以用于实现一特定结果的更具体的动作来描述。尽管功能性的步骤和非功能性的动作可以特定的顺序描述或要求，本发明并不需要限于任何特定的顺序或组合的动作和/或步骤。
图4A-4B图示了按照本发明在一消息传递架构中抽象处理层的方法的示范动作和步骤。用于在消息层内抽象一个或多个消息传递实现的步骤(420)包括定义一抽象该消息传递实现的消息层接口的动作(410)。消息传递的范例包括TCP 411、HTTP 413、SMTP 415以及其他传递417。端口412是传递抽象的一个范例，其向信道层提供一原子的消息发送/接收抽象。
用于在信道层内抽象一个或多个消息交换实现的步骤(440)可包括定义一抽象一个或多个消息交换实现的信道层接口的动作(430)。消息交换实现的范例包括数据报431、对话433、独白435、队列437以及其他交换实现439。消息交换实例430或信道实例是消息交换抽象的范例。
用于在服务层中抽象一个或多个捆绑实现的步骤(490)可包括定义一抽象一个或多个捆绑实现的动作(450)，该捆绑实现将一个或多个消息交换实现捆绑至用户码或消息处理实现。按照程序设计模型451编写的用户码454作为消息处理实例452。程序设计模型A、程序设计模型B、程序设计模型C等等是程序设计模型451的范例，其分别具有相应的用户码A1、用户码A2等等，用户码B1、用户码B2等等，用户码C1、用户码C2等等，以作为消息处理实例452而运行。用于抽象一个或多个捆绑实现的步骤(490)还可包括：把消息层类型映射至服务层类型(例如，WSDL至管理编码类型)(460)；将消息处理实例捆绑至消息交换实例(例如，服务实例至信道实例)(470)；以及管理消息处理实例(例如，通过服务存储器)的物理寿命(480)。
本发明范围内的实施例也包括用于携带或具有计算机可执行的指令或保存在其上的数据结构的计算机可读媒介。这种计算机可读媒介可以是任何现有的可由通用计算机和专用计算机访问的媒介。例如但不限于，这种计算机可读媒介包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储器、磁盘存储器或其他磁盘存储设备、或任何其他媒介，其可用于以计算机可执行的指令或者数据结构来携带或保存期望的程序编码装置并可由通用计算机或者专用计算机访问。当信息通过网络或其他通信连接(可以是硬线、无线、或者是硬线和无线的组合)而传输或提供给一计算机时，该计算机将给连接视为以计算机可读媒体。这样，任何这种连接被视为一计算机可读媒体。上述的组合也包括在计算机可读媒体的范围之内。计算机可执行的指令包括，例如，使通用计算机、专用计算机或者专用处理设备执行特定功能或者功能组的指令和数据。
图5以及下面的讨论希望提供本发明可实现的合适计算环境的简要的、一般的描述。尽管并不需要，但本发明仍将以被网络环境中的计算机执行的计算机可执行指令的一般内容描述，例如程序模块。通常，程序模块包括例程、程序、对象、组件、数据结构等等，其进行特定的任务或实现特定的抽象数据类型。计算机可执行指令、相关的数据结构、以及程序模块表示用于这里所公开的方法的执行步骤的程序编码装置的范例。这些可执行指令或相关数据结构的特定序列表示用于实现这些步骤中所描述的功能的相应的动作。
熟悉本领域的人员将会明白本发明可在具有许多类型的计算机系统配置的网络计算环境中实现，包括个人计算机、手提式设备、多处理器系统、基于微处理器或可编程的消费用户电子元件、网络PC、迷你计算机、主机电脑及类似的。本发明同样可在分布式计算环境中实现，其中任务由通过一通信网络相连(通过硬线连接、无线连接、或者硬线和无线连接的组合)的本地和远程处理设备执行。在分布式计算环境中，程序模块可位于本地和远程存储储存设备中。
参考图5，用于实现本发明的一示范系统包括以传统计算机520形式出现的通用计算设备，包括处理单元521、系统存储器522以及耦合包括系统存储器522和处理单元521在内多个系统组件的系统总线523。系统总线523可以式多种类型的总线结构中的任意一种，包括存储器总线或存储器控制器、外围总线、以及使用多种总线结构中的任何一种的本地总线。系统存储器包括只读存储器(ROM)524和随机存取存储器(RAM)525。基本输入/输出系统(BIOS)526，包含帮助信息在计算机520的元件之间进行传递的基本例程，例如在起动期间可能存储在ROM 524中的。
计算机520也可包括用于从磁硬盘539上读取或写入的磁硬盘驱动器527，用于从可移动磁盘529上读取或写入的磁盘驱动器528，以及用于从诸如CD-ROM或其他光媒介的移动光盘531上读取或写入的光盘驱动器530。磁硬盘驱动器527、磁盘驱动器528和光盘驱动器530分别通过硬盘驱动器接口532、磁盘驱动器接口533和光盘驱动器接口534连接到系统总线523。驱动器以及它们的相关媒介提供用于计算机520的计算机可执行指令、数据结构、程序模块和其他数据的非易失性的存储。尽管这里描述的示范环境使用了磁硬盘539、可移动磁盘529和可移动光盘531，其他类型的用于保存数据的计算机可读媒介也可以使用，包括磁带、闪存存储卡、数字通用光盘、Bernoulli盒带、RAM、ROM及类似的。
程序编码装置包括可保存在硬盘539、磁盘529、光盘531、ROM 524或RAM525中的一个或多个程序模块，包括一操作系统535，一个或多个应用程序536，其他程序模块537，以及程序数据538。用户可通过键盘540、指向装置542、或其他输入设备(没有示出)，例如麦克风、游戏手柄、游戏板、卫星天线、扫描仪或类似的设备来输入命令和信息至计算机520。这些和其他的输入设备通常通过耦合到系统总线523的串行接口546连接到处理单元521。或者，输入设备可由其他的接口相连接，例如并行端口，游戏端口或通用串行总线(USB)。监视器547或其他显示设备也通过接口连接到系统总线523，例如视频适配器548。除了显示器，个人电脑一般包括其他外围输出设备(没有示出)，例如扬声器和打印机。
计算机520可操作于网络环境中，使用逻辑连接至一个或多个远程计算机，例如远程计算机549a和549b。远程计算机549a和549b都可以是另一个个人计算机、服务器、路由器、网络PC、对等设备或其他普通的网络节点，并一般包括上述的对于计算机520的许多或者全部的元件，尽管图5中仅图示了存储储存设备550a和550b以及它们相关的应用程序536a和536b。图5中说明的逻辑连接包括本地网络(LAN)551和广域网络(WAN)552，这里将其示出是作为反了而不是限制。这样的网络环境是办公范围或企业范围的计算机网络、内部网和互联网中常有的。
当使用LAN网络环境时，计算机520通过一网络接口或适配器553连接到本地网络551。当使用WAN网络环境时，计算机520可包括调制解调器554、无线链路，或其他用于在广域网552，例如互联网上建立通信的装置。调制解调器554，可以是内置的或者是外置的，通过串行端口接口546连接到系统总线523。在网络环境中，对于计算机520或其部分而说明的程序模块可保存在远程存储储存设备中。需要了解示出的网络连接是示范性的，而其他用于在广域网络552上建立通信的装置也可以使用。
本发明可使用其它特定的形式实现而不脱离其原理或基本特征。所描述的实施例应被认为在所有的方面只是用于说明而非限制。于是，本发明的范围是由权利要求而非上面的描述而指明。所有在权利要求或其等同的意义和范围中的改变应被认为在此范围之内。
图2说明了按照本发明的一个示范消息传递架构200的高级表示。下面结合图5提供了关于消息传递架构的示范实现的详细说明。架构200通过分层的结构(例如，该架构可被视为子系统的顺序集合，其中每个子系统都取决于前面的子系统)支持分布式程序设计。例如，在消息传递架构200中，主要层包括消息传递层210、信道层240以及服务层270。
如下面将要详细描述的，这些层中的每一个抽象特定的实现细节，使得以共同方式处理类似的事情。消息分离程序设计模型、消息交换语义和消息传递以使开发者能够从架构内的一个层面上提取特征而不必担心另一层面上不相关的问题。这样，开发者就能够，例如从一个程序设计模型移到另一个而不需要获悉新的架构。该抽象造成较大的再用性并且鼓励创新，因为在被分离的架构中进行改变和提高允许保留现有的开发成果。
底层，即消息传底层210提供端点对端点的传输或消息传递。消息传递层210支持传递扩展性，这样当实现新的传递时，新的传递可被该架构中的其它层使用。例如，消息传递层210抽象传递协议的实现，例如命名管道、传输控制协议(TCP)、超文本传输协议(HTTP)、简单邮件传输协议(TCP)等等。因此，简单地说，消息传递层210向架构中的其它层提供了原子的消息发送/接收抽象，以使其它层能够以某种独立于发送或接收消息所使用的特定传递协议的方式处理消息。
消息传递层210允许在消息离开或到达端点时对其可扩展的拦截。可扩展的拦截机制可用于实现诸如路由、过滤、策略管理和安全性这样的行为。消息层210中的端点处可用的传递和行为都能被计划性地建立或者通过配置来建立。
信道层240在消息传递层210所提供的传递抽象顶上提供消息传递抽象。信道表示端点间实现的行为以及抽象所实现的行为的对象模型。一般信道的例子包括用于单向不相关消息传递的数据报信道、用于双向相关消息传递的对话信道、用于公布/预定或单向广播消息传递的独白信道以及用于单向对列消息传递的队列信道。应用程序或者用户码通过在一端点处建立信道实例(例如，存储器中的信道对象)并发送关于那些实例的消息而使用信道。当消息到达另一端点时，应用程序或者用户码识别出在信道发送端建立的信道并建立一信道实例来参与该对话。
服务层270在信道层240和消息传递层210的顶上提供程序设计模型。应用程序的设计者一般会在服务层使用消息传递架构200。服务层程序设计模型之间通过消息分发机制、消息被发送的方式(例如，结构相对类型的方法调用)和系统类型而彼此分开。服务层270提供一个通用机制把程序设计模型捆绑到上述信道实例上。服务层270还提供了程序设计模型选择提供给开发者的特征，例如状态和寿命控制、服务管理、呼叫拦截以及同步消息分发。无论简单的还是复杂的程序设计模型都可以开发用于服务层。为了便于适当的捆绑和互用性，程序设计模型一般会定义消息传递层传输类型以及架构自身中定义并控制的类型之间的固定关系，特别是与服务层270中的应用程序或者用户码对象相对应的类型。
图3是示出按照本发明的消息传递架构300的一个示范实施例的框图。通常，消息传递架构300由用于通过所支持的程序设计模型捆绑信道实例(即，存储器中的信道抽象对象)和编码的实例的模块组成。类似于上述关于图2的描述，图3包括消息传递层310、信道层340和服务层370。图3的描述可以分成两类：消息传递架构自身以及消息传递架构所支持的程序设计模型。以下的讨论从描述消息传递架构开始，接下来转而描述一个示范的程序设计模型。尽管在图3中说明的组件可能是单数，但应该理解，在单个架构中也经常会存在多个各个组件。
三个管理器，每一层内有一个，实现了架构300所提供的大多数基本功能：消息传递层310中的端口312、信道层340中的管理器342以及服务层370中的服务管理器382。因此，图3的描述最初一般集中在这三个管理器上，然后转而更详细地讨论这三个管理器和图示的其他组件。三个管理器中的第一个，端口312，充当传递实现和架构其他部分之间的多路复用代理程序。简单而言，端口312和消息传递层310向消息传递架构300提供了原子的消息发送/接收抽象。如前面所指出的，该抽象减轻了其他层要理解与各个传递实现相关的细节的负担。而且，其他层和消息抽象交互，并把消息如何被传递的细节留给消息传递层310和端口312。
三个管理器中的第二个，即信道层340中的信道管理器342，收集消息并使其相关，可能存储它们并/或对它们排序，并一般向服务层370给出高级的信道抽象，尤其向服务管理器382和服务捆绑器372提供。类似于消息传递层310所提供的消息抽象，这里也一样，信道层340和信道管理器342所提供的信道抽象减轻了其他层需要理解与各个消息交换语义相关的细节中的负担。其他层简单地和信道抽象交互，并把怎样交换消息(例如，数据报，对话，等等)的细节留给信道层340。
三个管理器中的第三个，服务管理器382，负责把服务实例376(按照该程序设计模型的一类实现的实例)连到由信道管理器342所产生的信道实例344，其向对应的服务实例提供信道抽象的实例。服务管理器382通过服务捆绑器372将服务实例376连到信道实例344，服务捆绑器372理解特定信道和程序设计模型两者的细节。如下面将要详细描述的，服务捆绑器372与服务存储器378合作创建并注册实例。
服务管理器382和服务捆绑器372使用服务代理374将服务实例376捆绑到信道实例344，代理服务374也将在下面详细描述。一旦创建了实例，服务存储器378就从架构的其余部分中抽象它们的持久性(例如，寿命等等)和位置。流入服务实例的消息和呼叫可以被与服务管理器382注册的服务扩展392支持的编码所拦截。服务实例通过服务实例上的接口与架构进行通信，称为服务站，其实现了通常由实例所使用的功能。实例的服务站在服务存储器创建实例时被初始化(或定址)。
服务管理器382是用于创建信道并访问架构中其他组件的一组接口，并且是该架构通过其实现配置的实体。当服务管理器被创建时，它创建端口处可用的服务捆绑器、服务存储器以及服务类型，并将它们连结到该架构。如果一个端口能够处理多个服务的请求，则仅仅一单个服务管理器与该端口相关联。尽管传统的架构具有用于创建实例并管理架构协作的某些形式，然而服务管理器382间接地执行其任务，即通过这个工作委派给适合特定任务的其他模块。结果，服务管理器382像架构300的其他组件一样支持高度扩展性，而传统架构中的服务管理器趋向于直接创建实例并管理架构协作，这使得创新变得困难因为可能需要重新实现现有的功能以支持新的行为或功能。
服务捆绑器372负责管理信道实例344、服务实例376和服务存储器378之间的关系。因此，服务捆绑器372一般特别获悉每个可用的信道和程序设计模型。信道实现了服务捆绑器372把消息移入或移出信道层340所使用的特殊事件和接口。程序设计模型指定了类型间的映射关系，服务捆绑器使用上述映射关系把消息应用于方法并且将方法呼叫转换成消息。因为每个信道和程序设计模型是不同的，因此一个服务捆绑器通常支持其中的一个。因此，一个运行的端口一般与每个所支持的信道/程序模型对的一个或多个服务捆绑器相关联。
一示范程序设计模型可在网络服务定义语言(WSDL)端口类型和架构运行期间管理的类型之间建立映射。WSDL是一种XML格式，它把网络服务描述成一组能交换消息的端点。它提供了一种相对简单的机制，用于独立于基础协议(简单对象访问协议-SOAP、HTTP GET/POST等等)或编码(多用途因特网邮件扩展-MIME等等)而指定请求的基本格式。抽象操作和消息被捆绑到指定的网络协议和消息格式来定义一个端点。因此，WSDL服务是端点的集合，也称为端口。在WSDL中，端口类型描述了操作的集合。应该理解，图3说明了本发明的一个示范实施例，其中架构包括映射至WSDL的被管理的编码数据类型。然而，本发明可在多种环境中实现，并不限于那些具有被管理的编码/数据类型或WSDL端口类型的环境。
如上所指出的，服务捆绑器372在端口创建期间向服务管理器382注册。服务捆绑器与一组端口/服务类型相关联。在架构运行期间被管理的类型实现了从对于服务捆绑器唯一的接口类型继承的服务，其使服务捆绑器的类型具有唯一性。对于示范架构300而言，打开端口的相同进程同样打开了服务管理器382以及端口处所有可用的服务捆绑器372。当被打开时，服务捆绑器将他们自己连结到对应的信道管理器342。
当用户码向服务管理器382发出一呼叫以创建一信道时，服务管理器就在所注册的服务捆绑器组上进行迭代并提供每个机会来处理指定的类型。然后，服务管理器使用识别该指定类型的服务捆绑器以创建一服务实例376，将它注册到服务存储器378，并用服务代理374将该服务实例捆绑到信道示例344。类似的，当消息到达一不与现有的服务实例相关联的信道时，如果它们识别出进来的端口/服务类型，则要求附属于信道的服务捆绑器组。识别类型的服务捆绑器372被用于创建一务实例，用服务代理将其捆绑至信道实例，并接下来使进来的消息通过实例和代理流至用户码。
为了产生对新实例的请求，服务捆绑器创建一服务实例376，把它注册到服务存储器378，创建服务代理374，把信道实例344连到服务代理374以及把服务代理374连到服务实例376中的用户码，并触发信道中第一消息的流动。之后，消息从信道实例流向服务代理374，服务代理将消息转换成呼叫栈并将它们分发给相应的服务实例。类似的，呼叫从服务实例376流出流向服务代理374，服务代理374将呼叫转换成消息并通过信道实例将它们发送到它们的目的地。
传统的架构可具有一些形式的服务捆绑器，按照本发明的架构能够支持多个服务捆绑器。另外，与传统的架构相对，服务捆绑器集合作为一个整体独立于其下的信道层，也独立于服务层370中的服务存储器和程序设计模型。传统的架构趋向于在紧密分界的包中实现传递、信道、捆绑、存储以及实例功能，这通常要求在每次为了解决发展的技术和应用需要而作出提高或改变时作出显著的改变。
如上面所指出的，服务存储器378管理实例。当服务捆绑器产生创建新的服务实例的请求时，服务捆绑器就创建一实例并将该实例注册到服务存储器。在创建了实例后，服务捆绑器使用存储器来定址该实例，(初始化通常使用通信接口)，接下来该捆绑器将该信道捆绑至该地址。服务存储器378记录与实例相关的信道数量，并在没有信道附加时释放一实例。这使服务捆绑器(其看见信道关闭消息/事件以及代理实例的释放)能够参与控制逻辑实例(从架构外看到的实例)的寿命。
当捆绑器控制逻辑实例的寿命时，服务存储器378管理物理实例(存储器中真正的对象实例)的寿命。当服务存储器希望从存储器中删除一物理实例时，它会告知相关的信道以使它们将该物理实例从它所关联的服务代理374上断开。接下来，下一次向该实例应用呼叫/消息时，服务存储器就负责创建-新的实例并将它重新连接到适当的代理。
服务存储器378支持一实例状态的多种相关度。服务存储器可能把所有实例维持在存储器中从不使用断开/重连接机制。或者，服务存储器可能把所有实例维持在存储器中并且为了加强实例的无状态性而支持主动的断开/重连接机制。服务存储器可能基于机器负载、许可证发行(例如，到数据库的连接)以及/或者使用模式来支持断开/重连接，并将断开/重连接与实例的无序/编序相结合并将实例保存在交易(transact)数据库中以支持持续的、可靠的实例。服务存储器所使用的数据库可与持久信道所使用的存储器以及端口前的路由器协作，以实现实例从一个机器向另一个机器的转移。服务存储器378在无用单元收集(garbage collection)、集中组合(pooling)、管理长寿命的连接等等中是有用的。
传统架构中的服务存储器趋向于直接连接物理和逻辑实例的寿命。这两者之间的关系一般在架构中被硬编码。结果，替代很难实现而不影响系统中的其他区域。此外，由专家级用户作为扩展点的修改或随着架构发展的修改是不切实际的，假定服务存储器和架构其他部分之间是显著连接的。
如前面所指出的，服务代理374是一服务捆绑器指定类型的实例，它把特定类型的信道实例344连到特定类型的服务实例376。对于进来的呼叫而言，服务从信道宣告消息可用而产生事件，从该消息中创建适当的呼叫栈，并将其应用于该实例。对于出去的呼叫而言，服务代理374产生呼叫，将其转化成消息，如果需要的话将它通过信道实例344发送。根据方向，服务代理374看上去像类型(typed)信道(例如，从服务实例方向)以及被管理的类型代理(例如，从信道实例方向)。
除了其桥接功能以外，在使用服务代理的整个期间还实现了某些行为。例如，一个或多个服务代理可实现并发管理，限制在给定的时刻进入单个服务实例的呼叫数目。如上面关于服务存储器378所指出的，服务代理实现了断开/重连接，以使服务存储器能把物理实例寿命与逻辑实例寿命分离。应该理解，服务代理374允许服务捆绑器372和服务存储器378两者以可扩展的方式来实现行为。
除了端口312、信道管理器342以及服务管理器382以外，架构300中可以有其他管理器。这些管理器实现架构的一些或者全部级别上的行为，包括消息过滤和路由、策略交换和应用、安全性、记录以及交易服务。每一个提供扩展性的管理器定义一个扩展接口以允许其他管理器来实现该扩展性。例如，消息传递层310处的端口312提供了端口扩展，允许管理器为流过该层的流水线消息提供处理机。类似的，各个信道管理器实现扩展以允许类似服务管理器的模块钩住(hook)用于从信道中创建信道实例的消息。
服务扩展392是由服务管理器382定义的接口，其允许其他管理器挂钩连接至(hook into)由架构所支持的呼叫路径扩展点。当扩展第一次被建立时，服务管理器通过服务扩展向感兴趣的管理器传递它所知道的服务类型的反射类型信息。实现服务扩展的管理器将该反射数据和它们自己的配置相结合以建立在特定的消息/呼叫流入或流出服务实例时它们所希望做的。消息前和消息后通知由流经服务扩展的事件传递给管理器。服务扩展机制的这种扩展程度在传统的架构中是没有的。只要架构被配置成一般地支持一行为时，除了与行为相关的管理器以外，不需要修改任何有存储器或其他组件，以便将该行为引入到架构中。
服务实例376是被管理的编码服务类型的实例，其实现与端口/服务类型相关的接口，可能是通过被指定为程序设计模型一部分的包装(wrapper)来实现。通常，如下面将会详细描述的，程序设计模型的一种不同的方法是会话与关于服务类型的接口和方法相关联的方式。如图3所示的示范实施例，相对于有效的程序设计模型编写的服务类型在WSDL会话、操作和消息以及架构运行时间管理的编码接口、方法和自变量类型之间建立直接映射。架构也可以支持使用不同程序设计模型创建服务类型，这些服务类型看上去非常不同。除了由相关联的服务代理使用的接口以外，服务类型可实现其他接口以将它们自己钩接到(hook into)架构行为的其他方面。例如，一服务类型可实现特殊的接口以便钩接至一些服务存储器或者参与由服务扩展实现的一些行为。
如上所述，服务实例376一般被定址(包括对其自身唯一的服务场点的引用)。服务实例通过实现一合适的接口或通过从实现该合适接口的基础类继承而被定址。当服务捆绑器372创建一服务实例时，其使用服务存储器378来定址该实例。然后，服务存储器通过在相应的接口上设置该服务端的属性而定址该实例。该服务端属性提供对该实例架构状态的访问，包括类似于收集连接到该实例的活动信道的事情。该实例可使用状态信息以获取、审查并修改它的信道。该服务存储器也可以在它从该服务实例的活动信道增加或删除信道以使其将该信道捆绑至或从该服务实例上去捆绑时使用该状态信息。
对于图3所示的示范实施例，架构被设计以支持实现从WSDL端口直接映射至用于架构运行时间被管理的编码类型的任何程序设计模型。一示范程序设计模型使用被管理的编码属性以在WSDL类型和被管理的编码类型之间建立关联。这类程序设计模型是由属性修饰的被管理编码类，其描述了被管理的编码类和它们所实现的端口类型的WSLD合同之间的关系。实现程序设计模型的工具或者能从用合适属性修饰的被管理的编码类和接口中生成WSDL，或者能从WSDL生成用适当属性修饰的被管理的编码类和接口。其他程序设计模型可包括远程对象模型、用于描述商业进程的逻辑序列的模型，等等。因此，术语“服务”应该被广泛地解释以覆盖这些及其他程序设计模型。
一个更传统的远程对象模型，例如DCOM，能被认为具有两个接口，一个在对象客户机所使用的代理上实现，另一个在对象自身上实现。关于这两个接口的一申请方法在这类程序设计模型中通常是相同的，尽管每个接口都可能包含合适于会话的一端或另一端的架构方法。
相反，WSDL会话是双向的。其操作或是单独的消息，或是请求/应答消息对，它们可以作为会话一部分在任何方向上流动。为了支持这些操作，示范程序设计模型包括四个接口，两个服务实现接口和两个信道控制接口。会话的每一端有一服务实现接口，该服务实现接口具有会响应消息或请求而运行的编码，会话的每一端还有一信道控制接口，该信道控制接口具有将向外发送消息或请求和事件的代理方法，这些消息或请求和事件可被钩接以增加对到来的消息或请求的处理。
属性可配置管理编码类型至WSDL类型的映射细节以及为运行编码而创建的实例的质量。属性的范例包括确定实例寿命的属性，例如是否为每一消息/请求创建一新的逻辑实例或者逻辑实例的持续是否和连接维持期间同样长。属性可指定一操作是消息还是请求/应答消息对，适当地与属性和编码一起指定方法是同步的还是异步的。其他属性可控制被管理的编码类型中方法和参数的名称以及WSDL操作、消息和部分的名称之间的关系。属性可用于控制将方法呼叫到由该方法呼叫的单独部分包装组成的消息的映射，或者到由每个自变量一部分组成的多部分消息的映射。最终，属性将控制程序设计模型到文档/文字或RPC/编码的消息的映射。同样可能实现编码，要求程序设计模型传递以服务实例为基础的信道实例，但这在WSDL上无效。
本发明同样可以方法的形式描述，该方法包括功能性的步骤和/或无功能性的动作。下面是在实现本发明中可进行的动作和步骤的描述。通常，功能性的步骤以其完成的结果的形式描述发明，而非功能性的动作以用于实现一特定结果的更具体的动作来描述。尽管功能性的步骤和非功能性的动作可以特定的顺序描述或要求，本发明并不需要限于任何特定的顺序或组合的动作和/或步骤。
图4A-4B图示了按照本发明在一消息传递架构中抽象处理层的方法的示范动作和步骤。用于在消息层内抽象一个或多个消息传递实现的步骤(420)包括定义一抽象该消息传递实现的消息层接口的动作(410)。消息传递的范例包括TCP 411、HTTP 413、SMTP 415以及其他传递417。端口412是传递抽象的一个范例，其向信道层提供一原子的消息发送/接收抽象。
用于在信道层内抽象一个或多个消息交换实现的步骤(440)可包括定义一抽象一个或多个消息交换实现的信道层接口的动作(430)。消息交换实现的范例包括数据报431、对话433、独白435、队列437以及其他交换实现439。消息交换实例430或信道实例是消息交换抽象的范例。
用于在服务层中抽象一个或多个捆绑实现的步骤(490)可包括定义一抽象一个或多个捆绑实现的动作(450)，该捆绑实现将一个或多个消息交换实现捆绑至用户码或消息处理实现。按照程序设计模型451编写的用户码454作为消息处理实例452。程序设计模型A、程序设计模型B、程序设计模型C等等是程序设计模型451的范例，其分别具有相应的用户码A1、用户码A2等等，用户码B1、用户码B2等等，用户码C1、用户码C2等等，以作为消息处理实例452而运行。用于抽象一个或多个捆绑实现的步骤(490)还可包括：把消息层类型映射至服务层类型(例如，WSDL至管理编码类型)(460)；将消息处理实例捆绑至消息交换实例(例如，服务实例至信道实例)(470)；以及管理消息处理实例(例如，通过服务存储器)的物理寿命(480)。
本发明范围内的实施例也包括用于携带或具有计算机可执行的指令或保存在其上的数据结构的计算机可读媒介。这种计算机可读媒介可以是任何现有的可由通用计算机和专用计算机访问的媒介。例如但不限于，这种计算机可读媒介包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储器、磁盘存储器或其他磁盘存储设备、或任何其他媒介，其可用于以计算机可执行的指令或者数据结构来携带或保存期望的程序编码装置并可由通用计算机或者专用计算机访问。当信息通过网络或其他通信连接(可以是硬线、无线、或者是硬线和无线的组合)而传输或提供给一计算机时，该计算机将给连接视为以计算机可读媒体。这样，任何这种连接被视为一计算机可读媒体。上述的组合也包括在计算机可读媒体的范围之内。计算机可执行的指令包括，例如，使通用计算机、专用计算机或者专用处理设备执行特定功能或者功能组的指令和数据。
图5以及下面的讨论希望提供本发明可实现的合适计算环境的简要的、一般的描述。尽管并不需要，但本发明仍将以被网络环境中的计算机执行的计算机可执行指令的一般内容描述，例如程序模块。通常，程序模块包括例程、程序、对象、组件、数据结构等等，其进行特定的任务或实现特定的抽象数据类型。计算机可执行指令、相关的数据结构、以及程序模块表示用于这里所公开的方法的执行步骤的程序编码装置的范例。这些可执行指令或相关数据结构的特定序列表示用于实现这些步骤中所描述的功能的相应的动作。
熟悉本领域的人员将会明白本发明可在具有许多类型的计算机系统配置的网络计算环境中实现，包括个人计算机、手提式设备、多处理器系统、基于微处理器或可编程的消费用户电子元件、网络PC、迷你计算机、主机电脑及类似的。本发明同样可在分布式计算环境中实现，其中任务由通过一通信网络相连(通过硬线连接、无线连接、或者硬线和无线连接的组合)的本地和远程处理设备执行。在分布式计算环境中，程序模块可位于本地和远程存储储存设备中。
参考图5，用于实现本发明的一示范系统包括以传统计算机520形式出现的通用计算设备，包括处理单元521、系统存储器522以及耦合包括系统存储器522和处理单元521在内多个系统组件的系统总线523。系统总线523可以式多种类型的总线结构中的任意一种，包括存储器总线或存储器控制器、外围总线、以及使用多种总线结构中的任何一种的本地总线。系统存储器包括只读存储器(ROM)524和随机存取存储器(RAM)525。基本输入/输出系统(BIOS)526，包含帮助信息在计算机520的元件之间进行传递的基本例程，例如在起动期间可能存储在ROM 524中的。
计算机520也可包括用于从磁硬盘539上读取或写入的磁硬盘驱动器527，用于从可移动磁盘529上读取或写入的磁盘驱动器528，以及用于从诸如CD-ROM或其他光媒介的移动光盘531上读取或写入的光盘驱动器530。磁硬盘驱动器527、磁盘驱动器528和光盘驱动器530分别通过硬盘驱动器接口532、磁盘驱动器接口533和光盘驱动器接口534连接到系统总线523。驱动器以及它们的相关媒介提供用于计算机520的计算机可执行指令、数据结构、程序模块和其他数据的非易失性的存储。尽管这里描述的示范环境使用了磁硬盘539、可移动磁盘529和可移动光盘531，其他类型的用于保存数据的计算机可读媒介也可以使用，包括磁带、闪存存储卡、数字通用光盘、Bernoulli盒带、RAM、ROM及类似的。
程序编码装置包括可保存在硬盘539、磁盘529、光盘531、ROM 524或RAM525中的一个或多个程序模块，包括一操作系统535，一个或多个应用程序536，其他程序模块537，以及程序数据538。用户可通过键盘540、指向装置542、或其他输入设备(没有示出)，例如麦克风、游戏手柄、游戏板、卫星天线、扫描仪或类似的设备来输入命令和信息至计算机520。这些和其他的输入设备通常通过耦合到系统总线523的串行接口546连接到处理单元521。或者，输入设备可由其他的接口相连接，例如并行端口，游戏端口或通用串行总线(USB)。监视器547或其他显示设备也通过接口连接到系统总线523，例如视频适配器548。除了显示器，个人电脑一般包括其他外围输出设备(没有示出)，例如扬声器和打印机。
计算机520可操作于网络环境中，使用逻辑连接至一个或多个远程计算机，例如远程计算机549a和549b。远程计算机549a和549b都可以是另一个个人计算机、服务器、路由器、网络PC、对等设备或其他普通的网络节点，并一般包括上述的对于计算机520的许多或者全部的元件，尽管图5中仅图示了存储储存设备550a和550b以及它们相关的应用程序536a和536b。图5中说明的逻辑连接包括本地网络(LAN)551和广域网络(WAN)552，这里将其示出是作为反了而不是限制。这样的网络环境是办公范围或企业范围的计算机网络、内部网和互联网中常有的。
当使用LAN网络环境时，计算机520通过一网络接口或适配器553连接到本地网络551。当使用WAN网络环境时，计算机520可包括调制解调器554、无线链路，或其他用于在广域网552，例如互联网上建立通信的装置。调制解调器554，可以是内置的或者是外置的，通过串行端口接口546连接到系统总线523。在网络环境中，对于计算机520或其部分而说明的程序模块可保存在远程存储储存设备中。需要了解示出的网络连接是示范性的，而其他用于在广域网络552上建立通信的装置也可以使用。
本发明可使用其它特定的形式实现而不脱离其原理或基本特征。所描述的实施例应被认为在所有的方面只是用于说明而非限制。于是，本发明的范围是由权利要求而非上面的描述而指明。所有在权利要求或其等同的意义和范围中的改变应被认为在此范围之内。