用于使爪哇小服务程序与异步消息结合的系统的制作方法

文档序号:6431639阅读:164来源:国知局
专利名称:用于使爪哇小服务程序与异步消息结合的系统的制作方法
技术领域
本发明总的涉及应用和事务服务器,特别涉及用于支持消息排队和具有多重执行队列的线程的系统。
交叉引用本申请涉及2001年10月5日提交的申请号为60/327,543的临时申请“SYSTEM FOR APPLICATION SERVER MESSAGING WITH MULTIPLEDISPATCH POOLS(用于与多重调度池进行消息接发的应用服务器的系统)”和2002年10月3日提交的申请号为____、发明人为Adam Messinger和Don Ferguson的实用新型专利申请“SYSTEM FOR APPLICATION SERVERMESSAGING WITH MULTIPLE DISPATCH POOLS(用于与多重调度池进行消息接发的应用服务器的系统)”,通过引用将这两个申请都合并于此。
背景技术
Java 2平台企业版(J2EE)规范定义了一种用于开发多层企业应用程序的现行标准。J2EE提供了一种设计、开发、组装以及调配(deployment)企业应用程序的基于组件的途径,其既减小了成本,又允许集中设计和实现。J2EE平台为开发者提供了多层分布式应用模型、重新使用组件的能力、统一的安全模型以及灵活的事务控制。其不但可以提供能比以前更快地进行销售的革新的用户解决方案,而且所得到的独立于平台的、基于组件的J2EE解决方案并不受任何一个厂商的产品和应用程序接口(API)的约束。
J2EE规范定义了下述种类的组件应用客户机组件;企业Java豆(EJB,Enterprise JavaBean);小服务程序(servlet)和Java服务器页面(JSP)(也称为网络组件);以及小程序(applet)。多层分布式应用模型意味着根据功能将应用逻辑划分为多个组件,而多个不同的应用组件可以组成同一个或不同服务器上的J2EE应用程序。应用组件实际安装在哪里取决于该应用组件属于多层J2EE环境中的哪一层。图1中描绘了这些层。如其中所示,应用服务器层104用于开发EJB容器和/或诸如servlet、JSP、以及html页面的显示(presentation)容器114。而这些又用作客户机层102与后端层106之间的接口,其中在客户机层102调配客户机108和客户机应用程序,而后断层106用于容纳诸如企业资源计划(ERP)系统的企业或遗留(legacy)应用程序。
客户机层——其可以是浏览器、基于Java的程序或其它客户机层内运行的网络激活编程环境,既可在公司防火墙之内也可在公司防火墙之外。
应用服务器层——通常这一层容纳显示逻辑和业务逻辑的组合,以支持客户机请求。显示逻辑通过JSP页面和显示HTML页面的servlet支持,而业务逻辑通过远程方法调用(RMI)对象和EJB 112支持。EJB依赖于事务、生命周期、状态管理、资源共享、安全性等的容器环境,其一起组成豆(bean)执行的运行时间环境。
后端层——这一般是现有应用程序和数据存储的组合。由于其可能包括诸如企业资源计划(ERP)、主机事务处理、数据库系统以及其它遗留信息系统的系统,所以其也被称为企业信息系统(EIS)层。
由于J2EE应用程序的组件分离地、并且经常在不同的器件上运行,所以需要有客户机和应用服务器层代码查找并引用其它代码和资源的方式。客户机和应用程序代码可以例如使用Java命名和目录接口(JNDI)116来查找用户定义的诸如企业豆的对象,以及诸如Java数据库连接器(JDBC)数据资源对象的位置和消息连接的环境条目,而所述位置又用于查找后端层中的资源。
可以在调配时间在网络和企业豆组件上配置诸如安全性和事务管理的应用程序行为。这一调配时间特征使应用逻辑与可能随组装而改变的配置设置分离开来。J2EE安全模型让开发者配置网络或企业豆组件,使得仅由授权用户访问系统资源。例如,网络组件可以配置为提示输入用户名和密码。企业豆组件可以配置为只有特定组中的人员才可以调用其方法中的某些种类。或者,servlet组件可以配置为其一些方法可以被每个人访问,而一些方法仅被一个组织中某些有特权的人访问。相同的servlet组件可以对另一个环境配置为所有方法都可以被每个人访问,或者所有方法都只能被选定的少数人访问。
一些应用服务器,例如BEA系统公司,San Jose,Caiifomia的WebLogic服务器产品,使用访问控制表(ACL)机制,其允许对服务器上运行的组件的利用进行精细控制。利用ACL,开发者可以在Java方法级定义哪个用户或哪组用户可以或不可以执行什么。这一ACL机制覆盖了在应用服务器上运行的任何内容,除了在EJB规范中定义了其自身的访问控制机制的EJB之外。安全领域允许管理员从现有授权或授权系统中引入信息到ACL。
Java Servletservlet是扩展网络服务器的功能性的程序。servlet接收来自客户机的请求,动态产生响应(可能查询数据库以满足该请求),然后向客户机发送包含HTML或XML文件的响应。servlet与CGI类似,但是因为servlet使用Java类和流,所以通常更容易编写。因为servlet被编译为Java字节代码,并且在运行时间servlet实例保持在存储器中,所以其执行更快,每个客户机请求产生一个新线程。servlet使得以动态方式产生数据给HTTP响应流更加容易。每个客户机请求作为新连接执行,因此请求之间的流控制并不容易。为此,会话管理维持特定客户机在请求间的状态。在一些应用服务器中,servlet使用HTTP会话对象来保存其在方法请求之间的状态。为了排除故障,这一对象可以在集群的环境中复制。
Java服务器页面JSP页面是基于文本的、用于开发servlet的显示中心(presentation-centric)方式。JSP页面提供servlet的所有优点,当其与JavaBean类合并时,提供一种使内容和显示逻辑保持分离的容易的方式。JSP页面和servlet都比公共网关接口(CGI)更理想,这是因为其是独立于平台的,并且使用较少的开销。JSP页面可以与JavaBean类一同使用,来定义用于建立由具有相似外观和感觉的页面组成的网站的网络模板。JavaBean类执行数据呈现(rendering),因此模板中没有Java代码。这意味着模板可以由HTML编辑器维持。使用JSP页面的、简单的基于网络的应用程序可以用于使用自定义标记或小脚本(scriptlet)取代JavaBean类来将内容绑定到应用逻辑上。自定义标记被插入标记库中,而标记库被引入到JSP页面中。scriptlet是直接嵌入JSP页面的小Java代码段。
Java消息接发服务(JMS)JMS是用于支持Java程序之间的消息交换的J2EE机制。即Java如何支持异步通信,其中发送者和接收者不需要彼此了解,因此可以独立操作。JMS当前支持两种消息接发模型点对点——其基于消息队列。在这种模型中,消息产生者将消息发送到队列中。消息用户可以将其自身附在队列上以倾听消息。当消息到达队列时,用户将其从队列中取出,并对其响应。消息可以仅发送到一个队列,并仅由一个用户使用。用户具有过滤消息以指定其想要的确切消息类型的选项。
出版和定购——其允许产生者向一个主题、并向该主题的所有注册用户发送消息,以检索这些消息。在这种情况下,许多用户可以接收相同的消息。
现有ServletAPI的一个问题是完全同步的编程模型。在将请求调度到特定的线程之后,调用适当的servlet的服务()方法。当该服务()方法返回时,发送响应。这是一种简单的编程模型,其适于许多类型的工作,但是在发送响应之前必须发生异步事件的情况下不是最优的,因为运行servlet的线程必须阻塞到该事件发生为止。

发明内容
本发明提供了一种用于异步穿线的系统和方法,其允许服务()方法在准备好发送请求之前返回(从而允许释放线程)。这样,当以后发生异步事件时,可以完成和发送响应。这一机制的示例使用是结合servlet使用JMS。
根据本发明,当执行servlet时开始该过程。servlet建立部分响应,但是通常需要更多数据来完成该响应。在servlet等待的同时,其将请求数据的JMS消息排入队列,并在包含所需数据的JMS消息到达时,将响应对象设置在可能发现其的地方旁边。在这一点上,servlet可以返回,但是还不会发送响应。在稍后的时间点,当数据经由例如JMS到达时,检索对应的响应对象。然后可以产生剩余的响应。当响应完成时,可以将其明确地发送给客户机。
这一特征还可以通过使用JSP标记库而获得。利用标记,JSP页面创作者指定什么工作应在异步时间之前进行,而哪个工作应该在异步事件之后进行。这一特征与JSP上下文机制结合,以确保其在异步事件之后恢复,并且不受干扰地继续处理。


图1展示了可以利用本发明的J2EE兼容体系结构。
图2展示了根据本发明实施例的具有异步线程池的穿线策略。
图3展示了同步穿线处理的图。
图4展示了使用传统方法处理的单个HTTP请求的生命周期。
图5展示了使用异步消息接发处理的单个HTTP请求的生命周期。
图6展示了使用传统方法处理的多个HTTP请求的生命周期。
图7展示了使用异步消息接发处理的多个HTTP请求的生命周期。
具体实施例方式
经过广泛地描述,本发明提供了一种允许异步穿线的系统和方法。本发明可以并入允许经由应用程序接口(API)访问servlet的应用服务器系统,或并入受益于异步穿线的其它系统中。
典型的Servlet API是完全同步的。在将请求调度给线程之后,调用适当的servlet的服务()方法。当该服务()方法返回时,发送响应。这种简单的编程模型适于许多类型的工作,但是在发送响应之前必须发生异步事件的情况下不是最优的,因为运行servlet的线程必须阻塞到该事件发生为止。
在一个实施例中,本发明提供了Servlet API的扩展,其允许服务()方法在准备好发送请求之前返回(从而允许释放线程)。这样,当以后发生异步事件时,可以完成和发送响应。这一机制的一个示例使用是结合servlet使用JMS。
在这一实施例中,当执行servlet时,其建立部分响应,但是通常需要更多数据来完成该响应。servelt将请求数据的JMS消息排入队列,并在包含所需数据的JMS消息到达时,将响应对象设置在可能发现其的地方旁边。在这一点上,servlet可以返回,但是还不会发送响应。稍后,当请求的数据经由JMS到达时,检索响应对象。然后可以产生剩余的响应。当完成时,可以明确地发送给客户机。
本发明主要设计用于应用、事务以及消息接发服务器,例如BEA系统公司提供的WebLogic系列产品。典型服务器设计的核心是穿线模型,即分配线程执行工作请求的策略。当servlet请求到达服务器时,将其调度给线程。这一线程负责执行被请求的servlet。服务器采用使用两个线程池、即异步池(通常称为读取线程)和同步池(称为执行线程)的穿线模型。池的这种组合允许开发者或管理员有效地给请求设定优先级,同时容许执行阻塞操作的用户代码。
图2展示了根据本发明实施例的穿线策略机制206。异步线程池208等待用于异步读取结果的异步输入机制202(多路复用器(muxer))变得可用。一旦有结果可用,来自池中的线程查看消息,并通过进行适当的回叫来调度该消息。调度回叫通常将要求由同步线程池进行后面处理的请求排入队列。然而,某些非阻塞的有优先级的请求在回叫中被直接服务。通过积极地接受输入,在低优先级的请求212运行的同时,高优先级的请求214不等待被读取。由于这些线程应该从不阻塞,所以通常其数量较少,可能每个CPU只有一个。
同步线程池210等待请求的队列204。一旦有请求可用,来自池中的线程从队列中取出请求,对其进行处理,并发出结果216。在处理请求的同时,线程可以执行代码,例如发出结果,这导致线程阻塞。所以,应该调节线程数,以使得每个CPU中总有一个线程处于可运行状态。在2001年10月5日提交的申请号为60/327,543、发明人为Adam Messinger、题为“SYSTEM FORAPPLICATION SERVER MESSAGING WITH MULTIPLE DISPATCH POOLS(用于与多重调度池进行消息接发的应用服务器的系统)”的临时申请和2002年10月3日提交的申请号为____、发明人为Adam Messinger和DonFerguson、题为“SYSTEM FOR APPLICATION SERVER MESSAGING WITHMULTIPLE DISPATCH POOLS(用于与多重调度池进行消息接发的应用服务器的系统)”的实用新型专利申请中更详细的描述了该调度策略。
图3展示了传统同步消息响应机制。如图中所示,将来自客户机应用程序302的请求,例如网络浏览器应用程序,经由servlet 304发送到应用服务器。该请求可以是超文本传输协议(http)请求306的形式,对此客户机通常期望超文本标记语言(html)响应308。在同步模型中,线程执行servlet,然后当servlet的执行完成时立即向客户机发送响应。这一方案的问题在于在servlet的整个执行中消耗了执行线程。如果servlet正在执行可能因等待其它数据而阻塞的任务,则这可以表示服务器资源的浪费。
图4图解了客户机访问服务器资源的典型系统生命周期。如图4所示,HTTP客户机402访问servlet 408,其通常在远程网络服务器上运行。对本领域技术人员而言显而易见的是,尽管这里为了说明目的示出了HTTP客户机,但是本发明不限于此,而是可以使用其它类型的客户机应用程序。如图4中的生命周期图所示,HTTP客户经由servlet容器404访问servlet。servlet容器负责接收HTTP请求410,并将其传送给servlet 408进行处理。处理这一HTTP请求的许多操作在servlet响应级406发生。如图4所示,随着时间沿页面垂直地增加,该过程以由响应处理器406处理的对servlet的init(初始化)调用412继续。然后servlet容器将service(服务)请求414传送给servlet以例如检索或更新数据。这样的系统典型地用于电子商务环境,其中客户机应用程序设计为检索目录列表,例如搜索飞行时间的结果等。servlet通常通过将输出416写到servlet响应处理器中来响应请求。经常为了缓冲和优化的目的而需要这一步骤。当servlet容器随后请求将响应返回到客户机时,其向响应处理器发送send(发送)请求418,而响应处理器向servlet容器返回sendresponse(发送响应)420。然后将该响应作为HTTP响应422发送给客户机。
图5图解了可以根据本发明的实施例使用的类似生命周期。如图5所示,再次使用HTTP客户机502访问远程服务器、服务器资源或servlet 508。HTTP请求510由向servlet响应处理器506发布init请求512的servlet容器504处理。然而此时,当service请求514被发送到servlet处理时,servlet立即返回516到响应处理器。这一即时返回释放了响应处理器以处理随后的请求,因为其不需要为了处理那些请求而等待servlet积极地返回数据。在一段时间t520之后,当servlet具有要返回给该请求的适当的数据时,其向响应处理器发送send信号518,然后响应处理器向servlet容器发送send response 522。和前面一样,后续的HTTP响应524被发送到客户机。
作为上述过程的一部分,servlet设置响应代码,直到其具有其它内容要发送,这有效地负责远离容器级的响应,并将其至于servlet级。在实践中,可以将servlet等待发布send响应的时间量定义为某个任意量,或者可以作为异步消息的结果执行,例如作为接收指示已有信息可用于发送给客户机的JMS消息的结果。这种类型的处理在例如用户在等待搜索结果时通常经历延迟时间的电子商务网站中很有用。当根据本发明执行处理时,不是只具有冻结的屏幕,而是用户可以接收一些项目信息,而随着servlet发现适当的数据并将其返回,其它项目被一件一件地返回。同时,servlet响应处理器可用于处理其它客户机请求。立即返回的数据的类型以及以后返回的类型可以由开发者指定。
图6和图7更详细地图解了本发明的操作,因为其可以应用来服务多个请求。如图6所示,当未使用异步消息接发时,必须以按顺序的方式处理来自客户机的后续请求。因此,例如在图6中,在处理来自客户机B 403的第二个HTTP请求430之前,来自客户机A的第一个HTTP请求410由servlet容器404和servlet响应处理器406处理,并被完全处理。总体的结果是花费两倍时间来处理来自两个客户机的HTTP请求。如果不以这种按顺序的方式处理请求,则非常有可能有一个或多个请求会产生对其它请求的积压(backlog),使得用户将经历处理的延迟。
图7图解了根据本发明实施例的机制的生命周期,其中使用异步消息接发,以异步方式来处理来自单个客户机的多个请求和/或来自多个客户机的请求,从而可以在不同的线程中运行处理。如图7所示,第一HTTP客户机A 502和第二HTTP客户机B 503使用上述机制来访问servlet资源508。根据这一实施例,当在servlet容器接收到第一个HTTP请求A 510时,由响应处理器使用init A调用512来进行处理,然后将其作为service请求514传送到servlet508。Servlet立即返回516到servlet响应处理器,其然后释放响应处理器以处理其它请求。如图7所示,第二个HTTP请求B作为init B调用532由servlet响应处理器立即处理,并作为service请求534传送给servlet以进行处理。Servlet再次立即返回536。以这种方式交织消息减少了处理两个请求的总时间,并允许servlet在有信息变得可用时或者如果有信息变得可用,将信息返回给客户机。例如,如图7所示,当servlet发现响应请求A所需的消息时,其向servlet容器返回send response A信号522,以作为HTTP响应A524发送到客户机。第二个send response B信号542和HTTP响应B 544以相同的方式进行处理。
实现在支持网络上文件的异步发送的平台上,文件servlet可以由快速文件servlet取代。这种类型的servlet的实现要求加入对servlet的异步响应,下面将对此进行描述。
同步和异步响应当来自远程客户机的servlet请求被服务时,经常需要响应。这一响应可以是同步的,即其由处理该请求的同一个线程发送,或者是异步的,即其以后在不同的线程中发送。这一分析是从服务器的角度进行的。从客户机的角度来说,哪种类型的响应可以或不可以因等待而阻塞取决于如何进行远程请求。
当前大多数请求是以同步方式处理的。当servlet请求被服务时,在服务线程可以移到另一个请求之前,必须完成所有处理。这一同步模型是由RMI和servlet规范所规定的。传统上这样做的原因是写入异步代码非常困难,从而易于出错。
有一些情况下,以异步方式响应请求的能力对节约线程非常有益。在服务器需要对外部资源进行一次或多次长运行请求或服务器需要在处理请求的同时等待一些条件的情况下,通常是这样的。这种情况的一个例子是从当前为空的JMS队列中出列的客户机请求。在同步模型中,为请求服务的线程阻塞,直到队列中有要返回客户机的消息。在异步模型中,线程可以将该请求放在一边,而继续为其它请求进行服务。当消息被放入队列中时,可以发现该请求,并且将响应发送给客户机。本发明允许服务器支持对RMI和servlet请求的异步响应。
Servelet特定的servlet可以在其调配描述符中声明为异步。当异步servlet的服务方法返回时,不再对那个请求采取行动。servlet负责在某处存储该请求,从而在发生其它行为之后,该请求可以被检索,并发送响应。在此点上,必须对将要涌向流中的请求调用特定的发送()方法,将该请求记入日志,并且如果其保持有效连接,则用多路复用器登记界面以接收更多数据。创建以下执行是重要的,即确保资源通过使长运行请求超时而适当被释放,由此释放资源以进行无用数据收集和其它清除。
JSP还可以通过使用JSP标记库以相似的方式支持异步模型。这些标记库由http开发者/页面创作者用来指定网页中哪个部分应在异步事件之前执行而哪个部分应在异步事件之后执行。标记库使得创作者能够访问应该在异步事件发生和JSP页面执行应该恢复时被通知到的对象。
当使用标记库时,页面的执行上下文可以在登记异步事件之前自动存储。以这种方式,有可能使JSP创作者隐藏许多异步编程的细节。JSP不需要关心状态维持。任何标准范围(页面、请求、会话或应用程序)中存储的状态将按其使用同步JSP时采用的方式继续工作。
前面对本发明的描述是为了说明和描述的目的而提供的。其并不打算穷尽,或将本发明限定为所公开的精确形式。显然,许多修改和变更对本领域技术人员是显而易见的。选用和描述实施例是为了最佳地说明本发明的原理及其实践应用,从而使本领域技术人员能够明白本发明适用于预想的特定用途的不同的实施例和各种修改。期望本发明的范围由所附权利要求及其等价物限定。
权利要求
1.用于在爪哇小服务程序和小服务程序处理器之间进行异步消息接发的系统,包括服务器,包括小服务程序和小服务程序响应处理器;HTTP接口,用于从HTTP客户机接收请求,并向HTTP客户机发送响应;并且其中来自客户的请求允许小服务程序立即返回一定的响应数据,并且设置响应代码用于后续的响应。
2.如权利要求1所述的系统,其中所述小服务程序后续响应由响应命令触发,以发送额外的响应数据。
3.如权利要求2所述的系统,其中所述响应命令是JMS消息。
4.如权利要求1所述的系统,其中小服务程序和小服务程序响应处理器的机能经由JSP标记库对用户公开。
5.如权利要求4所述的系统,其中所述JSP标记库用于指示哪个HTTP响应数据应该立即返回,而哪个响应数据应该以后返回。
6.如权利要求4所述的系统,还包括对JSP执行上下文的支持。
7.一种用于在爪哇小服务程序和小服务程序处理器之间进行异步消息接发的方法,包括以下步骤从HTTP客户机接收访问小服务程序资源的请求;以及异步响应所述请求,其中来自客户的请求允许小服务程序立即返回一定的响应数据,并且设置响应代码用于后续的响应。
8.如权利要求7所述的方法,其中所述小服务程序后续响应由响应命令触发,以发送额外的响应数据。
9.如权利要求8所述的方法,其中所述响应命令是JMS消息。
10.如权利要求7所述的方法,其中小服务程序和小服务程序响应处理器的机能经由JSP标记库对用户公开。
11.如权利要求10所述的方法,其中所述JSP标记库用于指示哪个HTTP响应数据应该立即返回,而哪个响应数据应该以后返回。
12.如权利要求10所述的方法,还包括对JSP执行上下文的支持。
全文摘要
在使用小服务程序的传统服务器中,当把HTTP客户机(502)请求调度给线程时,调用适当的小服务程序(508)的服务方法。当该服务方法返回时,发送响应。在可以发送响应之前必须发生异步事件的情况下,这不是最佳的,因为运行该小服务程序的线程必须阻塞到该事件发生为止。本发明提供了这种请求的异步处理。在一个实施例中,本发明提供了小服务程序API的扩展,其允许服务器方法返回,从而在准备好发送请求之前释放线程。这样,当异步事件在以后发生时,可以完成和发送响应。
文档编号G06F9/46GK1639703SQ02822993
公开日2005年7月13日 申请日期2002年10月4日 优先权日2001年10月5日
发明者亚当·梅辛杰, 萨姆·普拉拉, 戴夫·布朗 申请人:Bea系统公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1