Component based software environments use granules of software (referred to as “components” or “component instances”) to perform basic functions. In object oriented architectures, a component instance may be constructed from one or more object instances. The functional granularity offered by a plurality of different components provides a platform for developing a multitude of more comprehensive tasks. Some examples of component based architectures include Java 2 Enterprise Edition (J2EE), Common Object Request Broker Architecture (CORBA), Component Object Model (COM) and Distributed Component Object Model (DCOM) among others.
A container is a type of software platform that largely defines the operating environment of the software components that it “contains”. The platform or operating environment defined by a container is usually at least partially defined by a set of “services”. For example, in the case of a J2EE container, the layer of services offered by the J2EE container include a Java Naming and Directory Interface (JNDI) service, Java Database Connectivity (JDBC) service and a Java Messaging Service (JMS) among others.
FIG. 1 shows an exemplary implementation of a physical machine 101 (e.g., a computer) having a plurality of containers 103_1 through 103_Z. Each container 103_1 through 103_Z is depicted as containing its own respective application software programs 106_1 through 106_J and 107_1 through 107_K that, in the case of a component based environment are each constructed from their own respective component instance(s).
For example, in the case of J2EE EJB containers, application programs are made of one or more Enterprise Java Bean (EJB) component instances, or, in the case of J2EE web containers, application programs are made of one or more Java servlet component instances and/or Java Server Pages (JSPs) (for Web containers). A Java servlet is used to support the invocation of functional task(s) called from a web page (such as a JSP) that has been downloaded to a client computer. A web page is a text document typically written in a markup language (such as HTML or XML).
Each container 103_1 through 103_Z is depicted as having its own associated layer of services 104_1 through 104_Z. A messaging service 105_1 through 105_Z is depicted as being associated with each container's respective layer of services 104_1 through 104_Z. In component based architectures, a messaging service is a body of software (“program code”) that is responsible for the delivery of a message to the component to which the message has been sent. As such, messaging service 105_1 is responsible for the delivery of messages to applications 106_1 through 106_J, and, messaging service 105_Z is responsible for the delivery of messages to applications 107_1 through 107_K.
The applications observed in FIG. 1 may receive messages, for instance, as a consequence of component-to-component messaging (e.g., a first component invokes a method performed by a second component), or, web page to component messaging. In the case of J2EE, the messaging services 104_1 through 104_Z correspond to instances of the Java Messaging Service (JMS). Note that each messaging service 105_1 through 105_Z may be different instances of the same program code. Each messaging service instance may also support the sending of messages from the applications of its respective container to destinations residing outside its respective container.
A pertinent feature of an operational messaging service is its performance (e.g., how quickly it can deliver messages to the proper recipients) as measured against the resources its consumes. In the case of messaging services 105_1 through 105_Z, their ability to quickly deliver messages to their respective recipient applications (“consumers”) depends on where the messages are located at the time the messages are to be forwarded from the service to the application. Specifically, message delivery will be much faster if the message is “cached” within the physical machine's memory 102 rather than being persisted in a persistence layer. The persistence layer may, for instance, include one or more remote databases 109 (or simply remote database 109) that stores persisted versions of received messages. Remote database 109 is assumed to be communicatively coupled to physical machine 109 either directly or through a network.
Because the physical memory 102 of the machine is limited, and because other more important (or equally important) software functions consume the physical memory's resources, the amount 108 of physical memory that is made available for the message service instances 105_1 through 105_Z is limited to some percentage of the computing system's overall amount of memory. Thus, there exists the challenge of trying to ensure that messages are cached rather than persisted when needed for delivery to a consumer in cases where the amount of memory allocated to the message service for caching is insufficient to store all messages waiting to be delivered to their respective consumer.
USPTO Backgrounds
USPTO Backgrounds