用于组播支持的方法和装置的制作方法

专利名称：用于组播支持的方法和装置的制作方法
技术领域：
本发明通常涉及一种企业消息系统，尤其涉及一种用于从单一消息资源同时提供多种服务质量的系统和方法。
背景技术：
作为由位于加利福尼亚州Palo Alto城的Sun Microsystem股份有限公司开发的JavaTM2平台，企业版(“J2EE”)的组成部分的Java消息服务(“JMS”)应用程序接口(API)是一种在访问企业消息系统上有用的软件接口。JMS通过定义了由几个主要企业消息产品支持的通用企业消息AIP，提供了使得应用程序能够异步发送和接收数据的能力。JMS同时支持消息队列和基于预定的消息。计算机技术领域技术人员熟知的组件(企业Java beans)使用JMS API来同步或异步发送和接收企业消息。
JMS API不提供点到点同步消息递送和通知。其它的消息系统能够提供作为实现可靠应用的机制的同步传递，或者可以在未接收到消息时向客户提供递送通知。在另一方面，而JMS API不利用诸如递送通知的系统消息。所有的通知都必须在应用层上执行。
而且，JMS不提供真正的组播服务，JMS只提供简单的“回应”(Acknowledge)模式，其允许用户预定特定的“题目”，或诸如由主题排列或分组的消息。JMS不提供用于规定选择标准的能力或过滤掉本地-产生的消息。组播对于队列用户或持续用户是不支持的。而且，组播本身是基于一个不可靠的协议以至能够丢失消息。使用JMS API“一次性”的发送消息意味着丢失的消息不能再被恢复。这对于某些用户来说是所不期望的。
在现有技术的其他同步阵列系统中，通常需要用于对列和可靠的传输的API。这些系统通常需要持续去队列，以便能够获得所有来临的消息。如果一个用户希望同时接收组播业务，需要使用不同的API。在这样的一种原始状态，需要读取套接字(socket)，随后排队，再读取套接字，再排队等。系统需要能够同时应付这两者，自己进行多路服用和分时。开发者也需要理解和用两个不同的API编程。即使当开发者不需要在操作系统层上进行原始组播，通常开发者要用定制的应用程序接口来限定系统。如果期望接收不同服务质量，总之需要切换应用程序接口。
因此期望能开发出一种消息系统，该系统能利用组播的优点，但同时向那些不希望丢失消息的用户提供改进的可靠性。
还期望开发出能够不需要单独的应用程序接口的这样一种消息系统。

发明内容
本发明包括一种用于从单一的数据流提供两种服务质量的系统和方法。使用一个存储空间为系统的每个用户存储第一服务质量选择和/或一个第二服务质量选择。根据用户的服务质量选择，为每个用户对系统的处理器进行编程以控制数据流和/或任何数据流上的消息。该系统包含用于从处理器接收数据流和向存储的所选择的第一服务质量的每个用户组播数据流的组播装置。系统还包含设备，诸如点到点设备，用于从处理器接收数据流和保证存储的所选择的第二服务质量被存储的每个用户接收到数据流和/或消息。


图1是根据本发明的实施例的演示用于每个用户的点到点的服务质量的系统图；图2是根据本发明的实施例的演示用于每个用户的组播服务质量的系统图；图3是根据本发明的实施例的演示上面两种服务质量的图；图4是根据本发明的实施例的演示上面两种服务质量的系统图；图5是根据本发明的实施例的演示上面两种服务质量的系统图；
图6是根据本发明的实施例的示出消息处理步骤的流程图。
具体实施例方式
本发明克服了现有技术的消息系统的许多缺点。现有技术的消息系统，诸如JMS API，通常建立要广播的信息源。这些系统的用户向这个源发布信息，其随后被用于广播。而这种方法的源和发布是非常不可靠的。如果用户不希望丢失消息，需要由这些系统的用户来开发和实施自己的重发方案。
作为替代，根据本发明的系统能够发送消息到将进行组播的服务器。该服务器不仅能提供如上所述的不可靠的组播服务，而且能够提供可靠的服务。这些服务能够同时操作或者顺序操作，并且能够对于每个消息替换服务。和现有技术的系统不同，这样一种系统不是被单独被配置为组播或可靠源，而是通过同样的信道提供这两种服务。
在本发明的实施例中，用户可以指定用于要由该用户发送或接收的消息的服务质量(“QoS”)。系统的每个用户可以具有相关的属性，所述属性之一是服务质量。对于选择较高服务质量的用户，可以提供附加的信息，诸如发送消息以通知那些用户消息将被组播。某些用户可能配置或容许可组播的源，而其他的订户可能期望可靠性而不希望丢失消息。根据本发明的实施例的系统实际上从单一的源向两组用户提供不同服务质量。对于不管哪种QoS的用户来说这种双重服务可能都是完全透明的。
图1示出了根据本发明的系统100，其中每个用户118、120、122和124选择了可靠服务质量。在这种情况下利用一个点到点的协议。在图1中，发送方102沿着数据流104向系统服务器106发送单一消息108。系统服务器106把消息108发送给网络112，网络112把消息114发送给用户A118，用户A118选择通过可靠服务质量接收该消息。用户A118向网络112回送响应116，网络112向系统服务器106递送一个接收的回应110。系统服务器106对于用户B120、用户C122和用户D124执行相同的步骤。对于多个用户可以顺序，并列或同时执行这些步骤，这些步骤也可以在用户间以适当的顺序执行。
图2示出了相同的系统100，其中每个用户118、120、122和124选择了一个较快但较不可靠的服务质量。在这种情况下利用了一个组播协议。在图2中，发送方102沿着数据流104向系统服务器106发送单一消息。系统服务器106向网络112发送单一消息126，网络112递送消息114到选择了通过较不可靠服务质量接收消息的用户A118、用户B120、用户C122和用户D124。对于这种服务质量，用户118、120、122和124不发送需由系统服务器106接收的响应。每个用户可以在大约相同的时间接收到所述消息，但不保证获得该消息。
在图3中，发送方102再次沿着数据流104向系统服务器106发送一个单一消息。系统服务器106查看诸如用于临时存储的易失性和实时存储器的存储空间142，以确定哪些用户选择了可靠服务质量而那些用户选择了较不可靠的服务质量。
对于用户A118和用户C122来说，系统服务器106向网络112送出单一消息130，网络112向用户A118和用户C122递送消息136。用户A118和用户C122选择了由较不可靠的服务质量来接收消息。对于这种服务质量，用户A118和用户C122不发送需要由系统服务器106接收的回应。用户A118和用户C122可以在大约相同的时间接收消息136，但不保证它们能得到消息。
系统服务器106还向网络112发送消息132，网络112把消息138递送到用户B120。用户B120选择了使用可靠服务质量接收消息。用户B120向网络112返回一个响应140，所述网络112向系统服务器106递送接收回应134。系统服务器106还经历用于用户D124的可靠处理。
图4示出了根据本发明的一个实施例的另一个系统200。发送方202沿着数据流204向系统处理器206发送单一消息。系统处理器206查找诸如临时存储的实时或易失性存储器的存储空间230，以确定哪些用户选择了可靠服务质量而哪些用户选择了较不可靠的服务质量。对于用户A214和用户C218，系统处理器206向组播装置210发送单一的消息208，组播装置210向用户A214和用户C218递送消息212。用户A214和用户C218选择了由较不可靠的服务质量来接收消息。对于这种服务质量，用户A214和用户C218不发送回应。用户A214和用户C218可以在大约相同的时间接收消息212，但不保证它们能得到消息212。
系统处理器206还向点到点装置224发送消息222，点到点装置224把消息226递送到用户B216。用户B216选择了使用可靠服务质量接收消息。用户B216然后向点到点装置224返回一个响应228。点到点装置224还经历用于用户D220的点到点的处理。当实施组播和点到点分布时，组播可以在点对点之前，之后或同时被初始化或调度。用于两种分布方法的单独任务能够竞争资源，并且可以以任何顺序和/或同时被执行。
图5示出了相同的系统200，除了此时用户B216选择了用两种服务质量接收消息。例如，当用户希望快速接收消息，诸如使用不可靠的QoS，但同时又希望保证他们能接收到所有的消息时，可能是合适的，从而也请求通过可靠的QoS发送消息。对于用户A214、用户B216和用户C218，系统处理器206向组播装置210发送单一消息208，组播装置210向选择了通过较不可靠服务质量来接收消息的用户A214、用户B216和用户C218递送消息232。系统处理器206还向点对点装置224发送消息222，点对点装置224向选择了通过可靠服务质量接收消息的用户B216和用户D220递送消息226。用户B216仅仅为可靠服务向点对点装置224返回响应228。
对于图1和图4中的系统，都可以使用图6所示的根据本发明的过程300。在所述处理中，为系统的每个用户，或至少选择了从发送方302接收消息的每个用户存储第一和/或第二服务质量选择。根据每个用户的服务质量的选择304向每个用户转发在数据流上接收的消息。对于选择了第一服务质量选择的用户，在大约相同的时间306向每个这样的用户组播所述消息。对于选择了第二服务质量选择的用户，单独向每个这样的用户发送所述消息，并保证每个用户接收到消息308。
之所以某些用户更喜欢组播方式的一个原因在于全面可靠的服务有某些固有的缺陷(penalty)。一个这样的缺陷涉及整个系统性能的降低。系统的整体性能可能会降低。全面的可靠服务和组播相比通常是既慢又不具有较大的扩展性(scalability)。在组播时，不管有多少订户存在，消息只被发送一次。组播消息能够经由一个诸如onMessage的例程(routine)被递送。用户能够在他们的组播对话中创建客户，并且为这些客户注册监听程序(listener)。来自客户的消息随后可以如同其他异步消息一样在会话中串行排列。
另一个优选组播方式的原因基于某些应用对于递送时间的延迟非常敏感的事实。对于不同的接收机获得消息的顺序的应用也可能会敏感。比另一个接收机较迟得到消息可能是大的不利。而比另一个接收机早得到消息可能是大的好处。当使用组播时，这些应用和接收机在大约相同的时间得到消息，所以基本不存在延迟和/或次序的问题。
在可靠的情况下，可能需要联系，然后等待每个订户。当使用可靠系统时，调节到(scale to)大的数量可能并不实用，由于服务可能需要一次握手来保证所有的订户都接收到了数据。如果这种做法被用于足够大的数量的用户，系统可能无法跟上繁重的消息负荷。
根据本发明的实施例的系统通过向用户提供QoS选择避免了这些问题。具有要广播的消息的用户或服务器可能只需要向系统发送每个消息一次。系统对于这种消息能够处理两种服务质量。一个实施例把用户清单划分为两组，其中为每种服务质量划分一组。这些组可能以任何适合的存储方式被维持，诸如在用于临时存储的易失性或实时存储器中或在需要更多持久存储的系统或应用程序的系统数据库中。
所述系统还能够进行客户端过滤，而不是服务器端过滤。这能够通过把服务器的某些功能移到客户来改善系统的性能。过滤能够在消息被送给应用前通过诸如JMS在客户端进行。当过滤被在客户端进行时，是由JMS而不是由应用来控制过滤。在点对点递送的情况下，过滤也能够由JMS在服务器端进行。当消息通过不管是那个QoS来到客户端，客户或用户总可以在那时选择来过滤掉所述消息。可以使用各种用于消息过滤的方法，诸如已知的和在如上所述，JMS API允许用户指定握手的层级，诸如使用“回应”模式的层级。在回应模式中，用户可以选择回应所有，某些来到的消息或不回应任何来临消息。对于用户来说回应模式是一个开关，而能够使用监听程序来接收消息。当组播被设置成“不回应”模式时，有可能不需要在实际上改变接收消息的方法。每次还是向客户传递一个消息，因此为了接收消息而不需要回应，基本上什么都不需要做。
在现有技术中，可能需要改变程序的应用程序接口，以便改变QoS。一个客户可能具有优选组播的订户和优选更可靠服务的订户，但最好不必创造和管理两个应用程序接口，以便适应两个组的订户。
在根据本发明的系统中，用户可以简单地设置一个参数，并使用期待的QoS接收消息。在这个系统中，对于组播的订户有执行的线程。所述执行的线程可以包括在后台代表用户监听的程序。当消息来组播流时，消息可以象通常的JMS消息一样被封装，并被递送给监听程序。不管何时消息来临，监听程序都能被激发，诸如通过回叫。
对于可靠的订户，服务器可以直接调用客户。在这种情况下，服务器可以直接把消息交给客户，随后将消息封装并将其也递送给监听程序。两种消息都可以进入监听程序。可以使用诸如小的“扑捉(grab back)”程序来捕捉消息并将它们交给客户。用这种方式，所述消息对于客户来说看起来是相同的。
为用户可以在服务上建立一个永久性的监听程序。无论何时消息来临，它都可以被放到由用户设置的规则的监听程序的队列。执行的线程可以持续监听输入流或套接，把任何接收到的消息放到队列中。在JMS意义上来说，存在单一顺序的进入的消息流，或“会话”。在JMS意义上来说，会话是通过指定“回应”模式创造的组播会话。
在会话中，用户可以以多个输入流表达自己的兴趣。如果所有这些流都是组播流，可能只有一个套接和只有一个线程在监听那个套接。当接收到消息时，可以用使用户能够区分消息来源的方式把所述消息递送给用户。为了具有多个监听的线程，用户还可以创建多个会话。事实上，用户对于每个题目可以具有一个专用的线程。如果用户这样选择，每个线程驻留(reside)在一个专用套接上。
如果用户具有多来源的信息，用户可以选择监听全部，并随后进行挑选。用户还可以选择只监听一个或两个来源，每个来源可以被配置为使用一个单独的介质。用户可以选择在一个套接或“组播组”上建立几个题目，如果用户仅感兴趣一个题目，有可能需要丢弃所有向用户来临的其他题目。
当处理一个消息时，有可能丢失另一个消息。系统可能能够告诉用户丢失了消息，在内部，每个消息都可以用序列号来标签。如果JMS检测到丢失了一个消息，它可以报告这里存在一个序列空缺。
组播协议也不能保证次序。如果接收的消息次序出错，这可以以一个序列空缺检测和报告。序列空缺通过向诸如ExceptionListener的故障监听程序递送一个诸如SequenceGapException的故障来报告。如果所述会话没有诸如可以由setExceptionLister()方法设置的故障监听程序，则可能不报告序列空缺。
在一种序列空缺的类型中，无法取回数据。在第二种序列空缺的类型中，用户可能接收长的信息流，所以在消息的中间的一个信息分组可能会丢失，导致损坏的消息。在根据本发明的一个实施例中，这种消息的第一分组包含诸如消息的来源、消息的长度、消息的识别符，首标属性等和消息有关的信息。可以要求初始分组以向用户报告这种消息的一些或全部。
每个来临的消息还可以用信息来标签，从而有可能知道消息来自哪个信息流。来自不同信息流的消息并非真正相互竞争，所以不会在业务量变得繁忙时互相终止。然而，在以太网上可能会出现物理问题。服务器可以为最近的消息保持缓冲区，从而当这些消息丢失时服务器可以请求这些消息。
例如，系统可能会使用例程或方法来通过丢弃较新的消息，诸如KeepOld方法来保护信息流。这对于在能够更有效地在单一流中处理消息的应用程序来说是所期望的。系统还可能使用诸如KeepNew的例程或方法来通过丢弃较旧的消息来保护较新的信息流。这对于能够更有效地处理重复但是包含更及时的消息的应用程序来说是所期望的。
基于用于每个组播消息的处理量，客户端可能很容易就跟不上。在这种场景下，消息可能在客户端堆积起来。可以添加诸如MessageMaximum的新属性来限制给定能有突出的会话的未处理消息的数量。对于组播对话，一旦客户端达到了最大消息的门限就可以丢弃消息。消息最大的有效值可能是例如-1和/或在1到231-1的范围以内。值-1指示对于在会话中可以积累的未处理的消息的数量没有限制。
当作为超过最大消息值得结果丢弃消息时，可以根据定义的标准，诸如可能包含在方法或参数中例如超限overrun政策或OverrunPolicy的标准来丢弃这些消息。用于OverrunPolicy的有效值可能是例如‘KeepOld’和‘KeepNew’。通过连接factories最大消息和OverrunPolicy都可以被配置，而且都能使用例如在类中的诸如weblogic.jms.extension.WLSession的方法基于每次会话被覆盖。前述的关于本发明的优选实施例的描述被提供用于说明和描述的目的，而不是意味着用来把本发明穷尽或限制于所公开的精确形式。显然，对于本领域的技术人员来说很多修改和变动都是显然的。挑选和说明这些实施例是用来最好地解释本发明和实际引用，从而使得本领域的其他技术人员能够更好地理解本发明，以用于各种实施例和进行适合于特定用途的各种修改。本发明的范围由所附权力要求及其等同所限定。
权利要求
1.用于从单一数据流提供两种服务质量的系统，包括(a)存储空间，用于存储至少第一服务质量选择和第二服务质量选择之一，所述第一服务质量选择和第二服务质量选择用于多个用户的每一个；(b)处理器，其被编程用于根据用户所选择的服务质量为每个用户引导数据流；(c)组播装置，用于从所述处理器接收数据流，并向对于存储在所述存储空间的第一服务质量选择的每个用户组播所述数据流；(d)点对点设备，其从所述处理器接收数据流，并保证对于存储在所述存储空间的第二服务质量选择的每个用户接收所述数据流。
2.如权利要求1所述的系统，还包括适用于监听在数据流中向系统的一个用户发送的信息的监听程序。
3.如权利要求1所述的系统，还包括用于向处理器提供关于两种质量服务指令的单一API。
4.如权利要求1所述的系统，还包括用于选择组播服务质量的每个用户的执行线程，所述执行线程代表用户监听组播流中的消息并将该消息递送给用户。
5.如权利要求1所述的系统，还包括用于每个监听程序的队列，其允许用户接收关于两种质量服务的消息。
6.如权利要求1所述的系统，其中，所述存储空间可以存储每个用户对于多个数据流的多个单独选择。
7.如权利要求1所述的系统，还包括过滤设备，其允许用户过滤掉数据流中的某些消息。
8.用于允许用户选择一种服务质量以用于消息递送的方法，包括(a)为系统的每个用户存储至少第一服务质量选择和第二服务质量选择之一；(b)使用单一AIP处理在数据流上接收的每个消息并根据用户的服务质量的选择把消息转发给每个用户；(c)向选择了第一服务质量的每个用户组播消息；(d)向选择了第二服务质量的每个用户直接发送消息并保证所述用户接收到消息。
9.如权利要求8所述的方法，还包括用两种服务质量中的任一种过滤由用户接收的消息的步骤。
10.如权利要求8所述的方法，还包括代表用户为每个用户提供用于监听消息的监听程序的步骤。
11.如权利要求8所述的方法，还包括通过两种服务质量中的任一种对送出给用户的消息排队以便逐个向用户发送的步骤。
12.如权利要求8所述的方法，还包括使用序列号给每个消息加标签以便用户能够识别消息是否被丢失的步骤。
13.如权利要求8所述的方法，还包括给每个消息加标签以便用户能够识别所接收的每个消息来自哪个数据流的步骤。
14.如权利要求9所述的方法，还包括允许用户选择要用于过滤的过滤标准的步骤。
15.一种用于从单一数据流提供两种服务质量的方法，包括(a)为多个用户中的每个存储至少第一服务质量选择和第二服务质量选择之一；(b)根据用户的服务质量选择把在数据流上接收的每个消息转发给每个用户；(c)向选择了第一服务质量的每个用户组播所述消息；(d)向选择了第二服务质量的每个用户直接发送消息并保证所述用户接收消息。
16.如权利要求15所述的方法，还包括通过两种服务质量中的任一种过滤由用户接收的消息的步骤。
17.如权利要求15所述的方法，还包括代表用户为每个用户提供用于监听消息的监听程序的步骤。
18.如权利要求15所述的方法，还包括通过两种服务质量中的任一种对发送给用户的消息排队以便逐个向用户发送的步骤。
19.如权利要求15所述的方法，还包括使用序列号给每个消息加标签，以便用户能够识别消息是否被丢失的步骤。
20.如权利要求15所述的方法，还包括给每个消息加标签，以便用户能够识别所接收的每个消息来自哪个数据流的步骤。
21.一种计算机可读介质，包括(a)装置，用于为系统的每个用户存储至少第一服务质量选择和第二服务质量选择之一；(b)装置，用于使用单一的API处理在数据流上接收的每个消息并根据用户的服务质量选择向每个用户转发所述消息；(c)装置，其向选择了第一服务质量的每个用户组播所述消息；(d)装置，其向选择了第二服务质量的每个用户直接发送消息，并保证所述用户接收到消息。
22.一种由服务器计算机执行的计算机程序产品，用于允许用户选择用于消息递送的服务质量，包括(a)计算机代码，用于为系统的每个用户存储至少第一服务质量选择和第二服务质量选择之一；(b)计算机代码，用于使用单一的API处理在数据流上接收的每个消息，并根据用户的服务质量选择向每个用户转发所述消息；(c)计算机代码，其向选择了第一服务质量的每个用户组播所述消息；(d)计算机代码，其向选择了第二服务质量的每个用户直接发送消息，并保证所述用户接收到消息。
23.一种用于允许用户选择用于消息递送的服务质量的系统，包括(a)装置，用于为系统的每个用户存储至少第一服务质量选择和第二服务质量选择之一；(b)装置，用于使用单一的API处理在数据流上接收的每个消息并根据用户的服务质量选择向每个用户转发所述消息；(c)装置，用于向选择了第一服务质量的每个用户组播所述消息；(d)装置，用于向选择了第二服务质量的每个用户直接发送消息并保证所述用户接收到消息。
24.一种计算机系统，包括处理器；由所述处理器执行的目标代码，所述目标代码被配置来(a)为系统的每个用户存储至少第一服务质量选择和第二服务质量选择之一；(b)根据用户的服务质量选择，用单一的API对在数据流上接收的每个消息进行处理，并将所述消息转发给每个用户；(c)向选择了第一服务质量的每个用户组播所述消息；(d)向选择了第二服务质量的每个用户直接发送消息，并保证所述用户接收到消息。
全文摘要
本发明公开了一种系统，其允许单一消息被发送给两组用户，每组用户选择不同服务质量。对于一组用户(216，220)，可以使用点对点协议(224)发送消息，以保证每个用户接收到该消息。对于另一组(214，218)，可以使用组播(210)发送所述消息，从而在那个组中的每个用户在大约相同的时间接收到所述消息。这两种服务质量都用单一的应用程序接口(API)处理。
文档编号H04L12/56GK1549979SQ02817048
公开日2004年11月24日 申请日期2002年7月15日 优先权日2001年7月16日
发明者常新光, 斯蒂芬·扎克韦加, 扎克韦加 申请人:Bea系统公司