Abstract:
A method and system for message delivery in a messaging network are provided for enabling scaling. A messaging network includes a group of a plurality of queue managers, each of which includes means for carrying out a method comprising: receiving a message at a queue manager, removing at least some of the original message data to form a link message, adding a reference to the link message referring to the queue manager, sending the link message to a link message queue, and putting the original message to a local queue on the first queue manager. A link message queue may provided on each of the queue managers in the group, or single link message queue may be provided on one queue manager and accessible by the other queue managers in the group.

Description:
FIELD OF INVENTION 
       [0001]    This invention relates to the field of message delivery. In particular, the invention relates to scaling in messaging networks. 
       BACKGROUND 
       [0002]    Message delivery in messaging networks, such as clusters of queue managers, have a problem in scaling as, when load-balancing is used, a client has no control over which one of multiple queue managers a message request is put. Load-balancing is used to send messages to any one of the queue managers in a messaging network. This has the problem that a request for a specific message by another client must be made to the same queue manager otherwise the client is left hanging. 
         [0003]    This problem particularly manifests itself in the environment of HTTP (hypertext transfer protocol) in messaging. The HTTP environment traditionally relies on horizontal scaling. An HTTP client puts a message onto a queue manager on a first machine. The client had no say as to which machine their put request went to because the HTTP requests were load-balanced around the server by an edge server. A second HTTP client then does a request for the message; however, the edge server may send this request to a different queue manager and so the second HTTP client is left hanging. 
       SUMMARY 
       [0004]    According to a first aspect of the present invention there is provided a method for message delivery in a messaging network having a group of a plurality of queue managers, the method comprising: receiving a message at a first queue manager; removing at least some of the original message data to form a link message; adding a reference to the link message referring to the first queue manager; sending the link message to a link message queue; and putting the original message to a local queue on the first queue manager. 
         [0005]    The method may also include: receiving a request to retrieve a message at a second queue manager in the group; checking the local queue of the second queue manager for the message; checking the link message queue of the second queue manager and, if a link message is found: retrieving the message from the queue manager referenced in the link message. 
         [0006]    According to a second aspect of the present invention there is provided a computer software product for message delivery, the product comprising a computer-readable storage medium, storing in a computer in which program comprising computer-executable instructions are stored, which instructions, when executed by a computer, perform the following steps: receiving a message at a first queue manager; removing at least some of the original message data to form a link message; adding a reference to the link message referring to the first queue manager; sending the link message to a link message queue; and putting the original message to a local queue on the first queue manager. 
         [0007]    According to a third aspect of the present invention there is provided a computer software product for message delivery, the product comprising a computer-readable storage medium, storing in a computer in which program comprising computer-executable instructions are stored, which instructions, when executed by a computer, perform the following steps: receiving a request to retrieve a message at a queue manager in a group of queue managers; checking a local queue of the queue manager for the message; checking a link message queue of the queue manager and, if a link message is found retrieving the message from a queue manager referenced in the link message. 
         [0008]    According to a fourth aspect of the present invention there is provided a system for message delivery, comprising: a messaging network including a group of a plurality of queue managers that execute on a plurality of processors, each queue manager including a local queue; each of the queue managers including: means for creating a link message by removing at least some of the original message data from a received message and adding a reference to the link message referring to the queue manager at which the message has been received; and means for sending the link message to a link message queue accessible by all the queue managers in the group. 
         [0009]    The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]    The invention, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which: 
           [0011]      FIG. 1A  a schematic diagram of an embodiment of a system in accordance with the present invention; 
           [0012]      FIG. 1B  a schematic diagram of another embodiment of a system in accordance with the present invention; 
           [0013]      FIG. 2A  is block diagram of a further embodiment of a system in accordance with the present invention; 
           [0014]      FIG. 2B  is the block diagram of  FIG. 2A  showing a message flow in accordance with the present invention; 
           [0015]      FIG. 3  is block diagram of a yet further embodiment of a system in accordance with the present invention; 
           [0016]      FIG. 4  is a block diagram of a computer system in which the present invention may be implemented; 
           [0017]      FIG. 5  is a flow diagram of a message put process in accordance with an aspect of the present invention; and 
           [0018]      FIGS. 6A to 6C  are flow diagrams aspects of a message retrieval process in accordance with aspects of the present invention. 
       
    
    
       [0019]    It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numbers may be repeated among the figures to indicate corresponding or analogous features. 
       DETAILED DESCRIPTION 
       [0020]    In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention. 
         [0021]    Referring to  FIGS. 1A and 1B , a system  100  is provided in a messaging network having multiple horizontal messaging or queue managers  101 - 105 , for example in a cluster  106 . Queue managers  101 - 105  provide a logical container for the message queues and are responsible for transferring data to other queue managers  101 - 105  via message channels. However, other forms of message managers may be used. 
         [0022]    A message  110  put by a messaging client  111  is put to a queue  121  on one of the queue managers  101 . This queue  121  may be selected by a load-balancing mechanism  140 . 
         [0023]    A message support means  151  is provided coupled to or integral to the queue manager  101 . The support means  151  may take various forms as described further below and may be a one to one relationship between the support means  151  and a queue manager  101 , or there may be one support means  151  for multiple queue managers  101 - 105 , or there may be multiple support means  151  for a single queue manager  101 . The support means  151  generates a link message  112  to the message  110  and sends the link message  112  to a special type of queue  132 - 135  for the other horizontal queue managers  102 - 105 . The special type of queue may be referred to a cluster queue. 
         [0024]    The described system can apply to horizontally scaled messaging networks. Horizontal scaling is provided with one queue manager  101 - 105  per machine and IP spraying or name aliasing is carried out at the load-balancing mechanism  140 . The described system can also apply to vertically scaled messaging networks in which there is more than one queue manager  101 - 105  per vertically scaled machine. 
         [0025]    In one embodiment shown in  FIG. 1A , the cluster queues  132 A- 135 A for the other queue managers  102 - 105  to which the link message  112  is sent are provided on each of the cluster&#39;s queue managers  102 - 105 . The cluster queue managers  102 - 105  also have their own local queues  122 - 125 . Similarly, the first queue manager  101  may also have a cluster queue  131 A for use if a message is received to one of the other queue managers  102 - 105 . A reference  113  is made in the link message  112  as to the queue manager  101  where the message  110  actually resides. 
         [0026]    The link message  112  may be sent by the support means  151  to the cluster queues  132 A- 135 A by a put request. Alternatively, the link message  112  may be sent by the support means  151  to the cluster queues  132 A- 135 A by publishing the linked message on a (well-known) topic in a publish/subscribe manner. Each queue manager  102 - 105  subscribes on the topic and puts the message to its local cluster queue  132 A- 135 A. 
         [0027]    In another embodiment shown in  FIG. 1B , the cluster queues  131 B- 135 B for the queue managers  101 - 105  may be provided as a single queue or multiple queues  131 B- 135 B on the first queue manager  101 . The support means  151  of the other queue managers  102 - 105  have access to the cluster queue or queues  131 B- 135 B. 
         [0028]    The link message  112  contains only a subset of the original message  110 . It is preferable to reduce the size of the link message  112  in order to reduce network flow. The reference  113  in the link message  112  residing on the cluster queues  132 - 135  provides a more optimistic get scenario. 
         [0029]    When a client wishes to retrieve a message  110  by a get request, the get request is sent to any one of the queue managers  101 - 105  in the cluster  106 . The support means  151  for the queue manager  101 - 105  to which the get request has been sent, checks its local queue  121 - 125  for the message  110 . This check may be based on message header properties, or on a CorrelationID of the message  110 . 
         [0030]    If the local queue  121 - 125  on the queue manager  101 - 105  does not contain the message  110 , the support means  151  then checks the cluster queue  131 - 135  of the queue manager  101 - 105  to which the get request has been sent. Again this check may be based on message header properties, or on a CorrelationID of the message  110 . If a link message  112  to the message  110  is found on a cluster queue  131 - 135 , the reference  113  in the link message  112  can be followed to retrieve the message  112  from the queue  121 - 125  where it is on another queue manager  101 - 105 . 
         [0031]    The link message  112  may contain sufficient information for queue managers to have message selectors. Message selectors, for example in JMS (Java Message Service, Java is a trade mark of Sun Microsystems, Inc.), work on certain key attributes of a message, and therefore it may be preferable to place at least enough information in the link message  112  on the cluster queues  132 - 135  such that queue managers can make selections. This enables a specific message to be retrieved. 
         [0032]    The described system can also be extended to non-specific gets (without a selector) where the remote cluster queue(s) will always be checked for messages if none exist on the local queue. If the link message contains basic information, for example, that there is a message on a particular queue, this would enable the client to simply request any message rather than a specific message indicated by an identifier. 
         [0033]    In order to maintain performance, it is desirable to reduce the number and size of messages flowing around the messaging system. To reduce the number of messages flowing around the messaging system, the function of providing a link message  112  to the cluster queues  131 - 135  may be enabled for only particular queues and topics. An administrator may be provided to selectively enable the function of providing a link message  112  after checking the queues and topics. 
         [0034]    An embodiment of the system is described in the environment of HTTP messaging networks. Referring to  FIGS. 2A and 2B ,  FIG. 2A  shows a block diagram of an HTTP messaging network  200  and  FIG. 2B  shows the same diagram with a message flow illustrated. 
         [0035]    The HTTP messaging network  200  is shown with a first HTTP client  211  which puts a message to the messaging network and a second HTTP client  212  which wishes to get the message put by HTTP client  211 . HTTP servlets  251 ,  252  act as a communications bridge between the HTTP environment and the messaging environment. If a message has been put to a queue within a cluster of messaging managers by an HTTP client, any messaging or queue manager within that cluster should be able to see the message for easy message retrieval by HTTP clients. 
         [0036]    An edge or proxy server  240  load-balances the HTTP requests made by clients  211 ,  212  to the HTTP servlets  251 ,  252  which are connected to the queue managers  201 ,  202  to distribute requests across multiple machines  241 ,  242 . A client  211 ,  212  has no option as to which machine  241 ,  242  the put request goes to. 
         [0037]    Each machine  241 ,  242  in the HTTP messaging network  200  hosts a queue manager  201 ,  202  which provide a logical container for the message queues  221 ,  222  and are responsible for transferring data to other queue managers via message channels. 
         [0038]    The described system can apply to horizontally scaled HTTP messaging networks. In an HTTP messaging network  200 , horizontal scaling is provided with one HTTP server per machine and IP spraying or name aliasing is carried out at the edge server. The described system can also apply to vertically scaled HTTP messaging networks in which there is more than one server per machine. For example, two HTTP servers may be provided on a machine with, for example, two processors and name aliasing is done by the edge server. 
         [0039]    The HTTP messaging network function relies on all HTTP client requests passing through an instance of a HTTP servlet  251 ,  252  where the support is implemented sitting on an HTTP server in-front of a queue manager  201 ,  202 . A link message is generated to a message put onto its local queue  221 . The link message contains a subset of the information contained in the message including a reference to the location of the message. The link message may be generated by the HTTP servlet  251 ,  252  or the queue manager  201 ,  202 . 
         [0040]    The queue managers  201 ,  202  in addition to their regular queues  221 ,  222  have special queues  231 ,  232  for holding the link messages to messages on other queue manager&#39;s  201 ,  202  queues  221 ,  222 . As described in relation to  FIGS. 1A and 1B , the special queues  231 - 232  for holding the link messages may be provided on the queue manager  201  in which the message is put with access from the other queue manager  202 , or on the other queue manager  202  itself. 
         [0041]    When a message is put to a queue  221  of a queue manager  201 , a corresponding link message is placed on all other queue managers  202  that are taking part in the horizontal cluster. The link message is put or published to a special queue  232 , for example, named HTTP.CLUSTER.QUEUE. 
         [0042]    When a message is requested using HTTP, the HTTP request goes to any HTTP servlet and thus through to a queue manager connected to the HTTP servlet. Thus the request is received at any queue manager within the cluster according to whatever selection method is being used (workload balancing, round robin, etc). The HTTP servlet  252  that has the request firstly looks on its local queue  222  for the message. If it is not there, then it attempts to find the message on the special queue  232  (HTTP.CLUSTER.QUEUE). 
         [0043]    If the link message is found on the special queue  232 , the reference in the link message is followed to retrieve the full message from its queue  221  on a different queue manager  201 . 
         [0044]    Using this system means that no changes need be made to the queue managers, as the logic is all held within the HTTP servlets. It is a non-invasive way of addressing a potentially very invasive problem. It does not rely on any kind of client to queue manager affinity. 
         [0045]    Referring to  FIG. 2B , an example of this process is illustrated by numbered arrows in the figure. A message arrives (1) on a first queue manager (QM 1 )  201  (destined for a queue  221  on QM 1   201 ) via HTTP server  1   251 . QM 1   201  is part of a two queue manager cluster with a second queue manager (QM 2 )  202 . 
         [0046]    Upon receiving the message, HTTP support residing on HTTP server  1   251  strips out the original data and replaces it with a reference to its local queue manager (QM 1 )  201 . For example, an XML message that reads &lt;ORIGINALQ=“QM 1 ”&gt;. This shortened link message is put (2) on to all the HTTP.CLUSTER.QUEUES in the cluster. In this case it is put to the HTTP.CLUSTER.QUEUE  232  on QM 2   202 . The original message is then placed (3) onto the queue  221  on QM 1   201 . 
         [0047]    A request comes (4) into QM 2   202  for a message, for example, with message header properties or with a specified CorrelationID from a different client. The local queue  222  on QM 2   202  is checked (5) by HTTP support on HTTP server  2   252 . The message is not found. The HTTP server support then checks (6) its local or remote HTTP.CLUSTER.QUEUE  232  for the message link which it finds. The message link is read and HTTP server  2   252  makes a remote request (7) to QM 1   201  for the message. 
         [0048]    If another client request has come into QM 1  and picked the message from the queue before the message get request (4) to QM 2  happens then the message will not be available on QM 1  for the request (4) to pick-up. The request (4) will simply fail as normal. 
         [0049]    In another embodiment, the system is described in a non-HTTP messaging network. In a non-HTTP messaging network, a support means such as the HTTP servlet is not provided for each messaging or queue manager. Instead API crossing exits are used to intercept messages and replicate the message key information. 
         [0050]    Messaging networks, for example WebSphere MQ (WebSphere MQ is a trade mark of International Business Machines Corporation) provide a means for transforming data between different architectures and protocols, such as Big Endian to Little Endian (Endian is a trade mark of Endian S.R.L), or EBCDIC (Extended Binary Coded Decimal Interchange Code) to ASCII (American Standard Code for Information Interchange). This is accomplished through the use of message data exits. Exits are compiled applications which run on the queue manager host, and are executed by the WebSphere MQ software at the time data transformation is needed. 
         [0051]    Referring to  FIG. 3 , a messaging network  300  is shown in a non-HTTP environment. A first client  311  puts a message to the messaging network  300  and a second client  312  which wishes to get the message put by the first client  311 . 
         [0052]    An edge or proxy server  240  load-balances the message requests made by clients  311 ,  312  to the queues  321 ,  322  distributed across multiple machines  341 ,  342 . A client  311 ,  312  does not specify to which machine  341 ,  342  the put request goes to. 
         [0053]    Conventionally, a client can specify the particular queue manager, even in a scaled environment (HTTP and non HTTP). The described system works on the basis that the client does not specify the queue manager (but just the queue name) in order to allow scaling to be effective. The scaling may be horizontal or vertical. 
         [0054]    Each machine  341 ,  342  in the messaging network  300  hosts a queue manager  301 ,  302  which provide a logical container for the message queues  321 ,  322 . 
         [0055]    The messaging network function uses exits  351 ,  352  which are logic implemented in a queue manager  301 ,  302  where the support is implemented. The exits  351 ,  352  provide support to generate a link message to a message put onto its local queue  321 . The exits  351 ,  352  intercept messages and replicate the message key information in a link message. The link message contains a subset of the information contained in the message including a reference to the location of the message. 
         [0056]    The queue managers  301 ,  302  in addition to their regular queues  321 ,  322  have special queues  331 ,  332  for holding the link messages to messages on other queue manager&#39;s  301 ,  302  queues  321 ,  322 . As described in relation to  FIGS. 1A and 1B , the special queues  331 - 332  for holding the link messages may be provided on the queue manager  301  in which the message is put with access from the other queue manager  302 , or on the other queue manager  302  itself. 
         [0057]    When a message is put to a queue  321  of a queue manager  301 , a corresponding link message is generated by an exit  351 ,  352  and placed on all other queue managers  302  that are taking part in the horizontal cluster. The link message is put to a special queue  332  or published by the first queue manger  301  with a topic and received at the second queue manager  302  by that queue manager  302  subscribing to the topic using an exit or built-in to the queue manager  302  mechanism. 
         [0058]    When a message is requested, the request can be sent to any queue manager within the cluster according to whatever selection method is being used (workload balancing, round robin, etc). The exit  352  of the queue manager  302  that has the request firstly looks on its local queue  322  for the message. If it is not there, then it attempts to find the message on the special queue  332 . 
         [0059]    If the link message is found on the special queue  332 , the reference in the link message is followed to retrieve the full message from its queue  321  on a different queue manager  301 . 
         [0060]    The HTTP servlets  251 ,  252  and the exits  351 ,  352  providing the link message support may be provided in the form of a support pack for existing messaging networks. 
         [0061]    Messaging networks may be adapted for use with HTTP messages and a bridge may be provided including the described functions for message delivery and retrieval. 
         [0062]    The non-HTTP embodiment of using exits may be provided as subsequently installable code or in the product itself. 
         [0063]    There may be messaging networks including both HTTP clients and other non-HTTP clients. The first embodiment described in relation to  FIGS. 2A and 2B  solves the problem of affinity when both clients are HTTP clients. There may be a scenario in which a third party, for example, an external application, takes the original message from the queue, and places a reply onto another queue. The external application uses the same sort of logic encapsulated into an exit on each queue manager. Such that each put to a machine from the external application is registered with the entire cluster as before. 
         [0064]    The servlet logic is contained within the client connection logic (the Java Enterprise Edition (JEE) connector architecture (JCA) in a JEE connection scenario or the client connection if just a standard connection), rather than the application that uses the client connection. This enables modification to be implemented in a non-invasive manner. 
         [0065]    Management of the link messages on the special queues also has to be considered. This queue could very easily get filled up with link messages because it has a synopsis of every message delivery on every clustered queue in the HTTP cluster. Various standard timeout and clean-up policies can be employed to ensure that this is not a problem. 
         [0066]    The clean up is standard practice for messaging network administrators. It could be left to administrators to ensure that the queues get cleaned up as and when they desired, for example, when a queue was too big. 
         [0067]    The clean-up needs to take into account the fact that messages might not have actually expired yet. A solution to this problem is that the queue manager that holds the actual message publishes a “delete this message reference” to the messaging network and all the local queue managers act this out so that they clean out their copy of the reference message. This also means that each queue manager ensures that this clean up is done when each individual queue manager is not too busy. 
         [0068]    There may also be occasions when the original message times out, in which case the queue manager needs to understand that the message was a “clustered” message and then publish the “delete this message reference” to all the other queue managers. The cluster message may alternatively have the same timeout as the original message. 
         [0069]    Scalability of this special queue can also be considered such that a shadow queue mechanism is provided, for example, for every local Q 1  there is a Q 1 .CLUSTER.QUEUE. A single cluster queue may alternatively be used for multiple local or remote queues. 
         [0070]    Referring to  FIG. 4 , an exemplary system for implementing the invention includes a data processing system  400  suitable for storing and/or executing program code including at least one processor  401  coupled directly or indirectly to memory elements through a bus system  403 . The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. 
         [0071]    The memory elements may include system memory  402  in the form of read only memory (ROM)  404  and random access memory (RAM)  405 . A basic input/output system (BIOS)  406  may be stored in ROM  404 . System software  407  may be stored in RAM  405  including operating system software  408 . Software applications  410  may also be stored in RAM  405 . 
         [0072]    The system  400  may also include a primary storage means  411  such as a magnetic hard disk drive and secondary storage means  412  such as a magnetic disc drive and an optical disc drive. The drives and their associated computer-readable media provide non-volatile storage of computer-executable instructions, data structures, program modules and other data for the system  400 . Software applications may be stored on the primary and secondary storage means  411 ,  412  as well as the system memory  402 . 
         [0073]    The computing system  400  may operate in a networked environment using logical connections to one or more remote computers via a network adapter  416 . Input/output devices  413  can be coupled to the system either directly or through intervening I/O controllers. A user may enter commands and information into the system  400  through input devices such as a keyboard, pointing device, or other input devices (for example, microphone, joy stick, game pad, satellite dish, scanner, or the like). Output devices may include speakers, printers, etc. A display device  414  is also connected to system bus  403  via an interface, such as video adapter  415 . 
         [0074]    Referring to  FIG. 5 , a flow diagram  500  is shown illustrating a message put process of the described system. A put message is received  501  at a first queue manager. The original data is striped out  502  of the message and replaced with a shortened message including a reference to the first queue manager. The shortened message may optionally include sufficient information for message selections to be made. The shortened message is put  503  to a cluster queue either on each queue manager in a cluster or on a joint cluster queue at one of the queue managers. The original message is put  504  onto the local queue of the queue manager. 
         [0075]    Referring to  FIG. 6A , a flow diagram  600  is shown illustrating a message get process of the described system. A get request for a message is received  601  at a second queue manager. The local queue at the second queue manager is checked  602 . It is determined if the message is found  603 . If the message is found, the message is returned  604 . 
         [0076]    If the message is not found, the process proceeds to check  605  in the cluster queue for a shortened message. The cluster queue may be local at the second queue manager or may be remote on another queue manager. This check may include using message selectors to look for a specific message using information in the shortened message. It is determined if the shortened message is found  606 . If a shortened message relating to the requested message is not found on the cluster queue, the request fails  607 . If it is found on the cluster queue, the reference in the shortened message is followed  608  to the queue manager on which the full message is held. A remote request is made  609  to the queue manager where the full message is held. The full message is returned  610  from the local queue of the queue manager where the message is held. 
         [0077]    Referring to  FIG. 6B , a flow diagram  620  is shown illustrating a clean up process of the described system. The queue manager, to which a remote request is made for a message on its local queue, publishes  621  a delete message for the retrieved message to all queue managers in the cluster. All the queue managers in the cluster delete  622  the shortened message relating to the retrieved message from their cluster queue. 
         [0078]    Referring to  FIG. 6C , a flow diagram  630  is shown illustrating a further clean up process of the described system. The queue manager holding a message in its local queue checks  631  a message duration on the queue. It is determined  632  if the message has timed-out. If a message has not timed-out, the process loops to continue checking  631  the message. If a message has timed-out, it is determined  633  if the message was a clustered message. If not, the message is just deleted  634 . If the message was a clustered message, the queue manager publishes  635  a delete message to all queue managers in the cluster. All the queue managers in the cluster delete  636  the shortened message relating to the message from their cluster queue. The queue manager also deletes  637  the full message from its local queue. 
         [0079]    A support server alone, or as part of a messaging system, providing the link message functionality may be provided as a service to a customer over a network. 
         [0080]    Embodiments of the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In one embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. 
         [0081]    The invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus or device. 
         [0082]    The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk read only memory (CD-ROM), compact disk read/write (CD-R/W), and DVD. Improvements and modifications can be made to the foregoing without departing from the scope of the present invention.