a messaging system 100 , according to the present invention , is shown in fig1 . a messaging system is a system for the storage , management , and retrieval of messages . a message is a piece of data created and posted by a sender and intended for one or more recipients . the messaging system of fig1 has two layers : the core layer 101 and the services layer 103 . the core layer provides core messaging facilities , such as message routing 102 , event dispatch 104 , transactional mediation 106 and multiple , possibly heterogeneous data stores 108 : for depositing and retrieving message contents ; for managing user folders ; for representing and managing the semi - structured nature of messages ; and for maintaining information about users and user groups . in addition , the core layer consists of a submission server 110 that can receive messages from sending clients , and an access server 112 that provides access to messages for a receiving client . the services layer includes a variety of services built upon the basic functionality of the core layer . examples of such services , shown in fig1 include traditional e - mail 114 , folder management for declaratively specified folders 116 , user - specific alerting services 118 , and so on . the fundamental entity in a messaging system that supports electronic mail is the message . a message consists of ( i ) one or more header fields , like ‘ to ’, ‘ date ’, ‘ subject ’ and ‘ from ’, some of whose values are structured , and some of whose values are unstructured and ( ii ) a body , which is typically unstructured . for conceptual simplicity , we model a message as a set of attribute / value pairs , one for each header field in the message , and one for the entire content ( both header and body ) of the message . additional attribute / value pairs may also be associated with messages . messages are typically sent to users , or user groups , and these are part of our conceptual model as well . users and user groups are also naturally modeled as a set of attribute / value pairs . for example , a user can be modeled by specifying values for attributes such as ‘ givenname ’ and ‘ e - mail ’. user groups may have attributes for their name , for specifying membership in the group , and so on . messages sent to users or user groups get deposited in mailboxes or folders , and users access their messages by examining folders . a folder can be viewed as consisting of a set of messages , as well as a set of sub - folders . a folder has attributes as well , such as its date of creation , the number of messages in it currently , and so on . often , attribute / value pairs need to be associated not just with individual messaging entities , but with relationships between messaging entities . for example , a message can be deposited in multiple folders , and when a message is read in a folder , replied to , or deleted from a folder , this fact can be recorded as the value of a “ per - message , per - folder ” attribute . such attributes are not restricted to a predetermined set either . the message router 102 , shown in fig1 accepts messages from the submission server 110 and either forwards them to an external mail system or to the appropriate component ( s ) of the storage system . typically , the appropriate components will be a message store for the message itself , a folder store for the intended recipient &# 39 ; s “ inbox ”, and zero or more additional attribute stores . the message router function is traditionally performed by a “ message transfer agent ”( mta ). messaging entities , which we require to have unique identifiers , the various relationships between the entities , and the attribute / value pairs associated with these entities and relationships , are uniformly represented in one or more attribute stores . every store in the network is modeled as an “ attribute store ”, which maintains a relationship between one or more identifiers and a set of attributes . the basic access functions supported are to return identifiers matching a specified attribute value and to return all attributes given an identifier key . this simple model is used as the common denominator to tie multiple heterogeneous stores into a single framework via a common , generic application programming interface ( api ). a message store maintains the value of the most important attribute of a message , namely its content . the message content is treated as an arbitrary stream of bits by the message store : semantics are the provenance of higher level services . when a new message for a local recipient arrives in the messaging system , the message is passed to a message store where it is stored , given a message identifier , and then “ exposed ” through the transaction manager to any core services that may wish to extract and index message attributes . finally , a message arrival event is signaled outside the core layer for consumption by services interested in this event . the term folder is used in our system to refer to sets of messages , and sub - folders , that have been organized for convenience of access by a user . a user may specify multiple folders as a way of classifying messages . in contrast with traditional folders , however , a folder in our system typically contains only the message identifiers of its messages . this design has several benefits . since the folder store does not have to handle large messages or store complex message types , it can be quite light - weight . the separation of the message store from the folder store is also crucial for permitting late binding of message content to folders . our messaging system assumes the availability of a directory facility , with information describing user entities , which are generally end - users or user groups , but could also represent network devices ( e . g ., printers ), or services ( such as newsgroups and mailing lists ). user entities in the directory have attributes , some of which are mandatory while others are optional . the directory provides access to its entity attributes using the lightweight directory access protocol ( ldap ) standard . the majority of the attributes to be stored in a messaging system tend to be fairly simple and quite numerous , including flags that indicate message state , and so forth . all such attributes are managed by a default attribute store . while “ special ” attributes , such as message content or full - text indices , may be more effectively stored in appropriate specialized stores , the default store provides at least one simple way of storing any attribute at all . the messaging system described here includes multiple attribute stores , with individual stores implemented in very different ways . a typical configuration should be expected to have at least an ldap directory , a file system , and an rdbms . in general , these system components differ with respect to their apis , their capabilities , and their performance characteristics . to manage such implementation components , a “ transactional mediator ” is used as a “ wrapper ” around each system component . a transactional mediator serves the needs of api conformance and query optimization . in addition , each transactional mediator provides transactional support to ensure consistency in the presence of concurrent activity and to facilitate recovery in the presence of failures . an event is a detectable change of state in the messaging system of the present invention . for example , a message being added to , or deleted from , a folder is an event ; the creation of a new folder is an event ; and so on . in the present invention , events are a mechanism used by the core layer to notify the services of the upper layer that something of interest has happened . upper layer services may then execute actions in response to events , such as logging of accounting information for billing purposes . an event dispatcher is employed by the messaging system described in the present invention . the event dispatcher accepts event descriptions from the core components , called suppliers , and delivers corresponding event notifications to services interested in these events or combinations of these events , called consumers . ith the event dispatcher , an event supplier specifies the kinds of events it will supply , while a consumer specifies the kinds of events it is interested in . when an event is handed to the event dispatcher by a supplier , the dispatcher delivers an event notification to only interested consumers avoiding wastage of important shared resources , such as network bandwidth . a data flow diagram of event - driven messaging , implemented in the messaging system 100 , is shown in fig2 . messaging entities 202 includes fundamental objects that are handled and maintained by the messaging system , such as messages , mailboxes , folders , attributes , etc . the values of each of these messaging entities at a given time , taken together , is the state 204 of the messaging system at that time . the state 204 of the messaging system is managed by event suppliers 206 , which are core components that examine and manipulate the values of the messaging entities . the event suppliers 206 detect changes in the state of the messaging system and generate events based on the detected changes . event suppliers 206 transmit event announcements 208 to event manager 210 based on the generated events . for each received event announcement 208 , event manager 210 generates the appropriate event notifications 212 and transmits the event notifications 212 to the appropriate event consumers 214 . an event consumer is a software program or routine that responds to event notifications . upon receiving an event notification , the notified event consumers 214 may examine and manipulate messaging entities 202 , in order to implement the desired services . the event manager 210 , of fig2 is illustrated in more detail in fig3 . event manager 210 includes an event dispatcher 222 and a notification registry 224 . event announcements 208 generated by suppliers are received by the event dispatcher 222 . the event dispatcher then uses the notification registry 224 in order to notify the interested event consumers . notification registry 224 includes a plurality of event / notification entries 226 a - z . each entry 226 includes a field specifying the event or combination of events to which the entry corresponds and one or more fields specifying the event consumers that are to be notified upon occurrence of the specified event or combination of events . based on the received events , event dispatcher 222 selects the appropriate entries in the registry and generates appropriate notifications 212 . the messaging system of the present invention includes one or more messaging servers 250 , shown in fig4 . messaging server 250 includes central processing unit ( cpu ) 252 , which is connected to input device 254 , output device 256 , network interface 258 and memory 260 . cpu 252 may comprise a microprocessor , for example , an intel pentium processor , or cpu 252 may comprise a mini - computer or mainframe processor . input device 254 allows input information to be entered and may comprise a keyboard , a mouse , a floppy disk drive , a tape drive , and / or other removable media drive or interchange device . output device 256 allows the output of provisioning information generated by messaging server 250 and typically comprises a high - speed printer . network interface 258 couples messaging server 250 to communications network 259 and allows an alternate path for input or output of information . communications network 259 may be , for example , a local or wide area network , the public switched telephone network , or the internet . network interface 258 may comprise a conventional modem or a local / wide area network adapter , depending upon communications network 259 . memory 260 may include devices such as random access memory or read only memory , which store data and instructions for execution by cpu 252 . memory 260 may also include devices such as magnetic disk drives , optical disk drives and tape drives , which store data and program instructions used by the present invention . memory 260 includes messaging entities 262 , event supplier programs 264 , event manager program 266 , notification registry 268 , event consumer programs 270 and operating system 272 . messaging entities block 262 includes storage for messages , mailboxes , folders , attributes , etc . event supplier programs 264 comprises program instructions that are executed by cpu 252 , and which implement core services which detect changes in the state of the messaging system and generate events based on the detected changes . event manager program 266 comprises program instructions that are executed by cpu 252 , and which receives event announcements , generates the appropriate event notifications and transmits the event notifications to the appropriate event consumers . notification registry 268 is used by event manager program 268 to notify the interested event consumers . event consumer programs 270 comprise program instructions that are executed by cpu 252 , which may examine and manipulate the messaging entities , in order to implement the desired services . a flow diagram of an event - driven messaging process , implemented in messaging system 100 , is shown in fig5 . the process begins with step 302 , in which event suppliers 206 , which are existing services or core components that examine and manipulate the values of the messaging entities , detect and generate a state change or a time - based event . two categories of events are generated in the messaging system of the present invention : time - based and state - based . time - based events are generated with the passage of time . for example , a message may have an expiration time of “ 2 : 00 : 00 p . m ., oct . 18 , 1997 ”. this expiration time is recorded at a time - based alarm generation facility at the time the message is entered into the system . when this time arrives , an event is generated by the alarm generator , and it may be consumed by a garbage collection service . periodic events ( e . g ., events generate once per month ) are also supported . state - change events are generated when a change in the state of the system is detected by the core software layers , i . e ., a new message is received , a message is read , a folder is accessed or updated , a message is deleted , etc . a folder management service can maintain correct contents for a declaratively - specified folder by registering for new mail events and other relevant state - change events . in step 304 , event suppliers 206 transmit an event announcement including an identifier of the generated event to event manager 210 . the event announcement includes information relating to the context of the generated event . this context contains enough information to allow services to both identify the particular entity ( message , folder , etc .) involved in the event and also to access the entity in question for retrieving more information , if needed . in step 306 , event manager 210 looks up the identified event in notification registry 224 , determines the consumers that are interested in that event and generates event notifications for those consumers . the event notifications include the context information of the event , which is passed to the event consumers . the interested event consumers are those that are specified in the event / notification entries in notification registry 224 . in step 308 the event notifications are transmitted to the interested event consumers . in step 310 , the notified event consumer programs are invoked and executed in order to implement the desired services . the event mechanism employed in the messaging system of the present invention is general - purpose , and it is more powerful than the event facilities supported by existing electronic mail systems . finally , this event notification mechanism is different from the event - condition - action mechanism provided by active database management systems , in that the actions executed are not internal to the “ database ”, but rather invoked at a higher layer service . examples of types of events that are generated by the core layer of the system include : message arrival : this event is generated when a new message is received by the submission server , which is shown as box 110 in fig1 . message delivery : this event is generated when a new message is delivered to a mailbox . message queuing : this event is generated when a message has to be queued and forwarded by the message routing box 102 , shown in fig1 to an external messaging system or another instance of our system . message movement : this event is generated when a message is copied from one folder to another or moved from one folder to another one . message state change : this event is generated when the state of a message changes . for example , when a message is read , deleted , or replied , a state change event is generated . folder deletion : this event is generated when an existing folder is deleted . folder rename : this event is generated when an existing folder is renamed . folder access : this event is generated when a folder is being opened or closed . the motivation behind the architecture of the core described thus far is to facilitate the construction of services on top of this core . these messaging services and features are of direct utility to an end - user . examples of such services include the following : implementing traditional internet e - mail service is easy , as the core directly supports most of the required functionality . the e - mail service consists of three components ; user registration , sending messages , and folder access . during registration , the e - mail service creates an entry in a directory containing the recipient &# 39 ; s mail - id and associated ( user ) information . in addition the core creates a ( mailbox ) folder for the user . messages are sent using an smtp client . the message router 102 shown in fig1 stores the message in the message store , and the e - mail service updates each recipient &# 39 ; s folder with the identifier of the new message . messages are accessed using standard clients , say pop 3 , at which time message identifiers are dereferenced by the access server 112 , and actual message bodies are shipped to the client . whereas the contents of traditional message folders are enumerated explicitly by the owner , a “ declaratively specified folder ” is defined by the predicate that the corresponding messages should satisfy . examples of folder definitions include : ( 1 ) the set of all messages from an enumerated or declaratively specified set of individuals , ( 2 ) the set of all messages received by the user in the past week , ( 3 ) the set of all messages explicitly tagged by the user as being about some particular topic , and so on . the folder management service is responsible for both creating and manipulating declarative folders on behalf of users and , also , for computing their contents upon user access . to improve the performance of access , the service may materialize and maintain folders in the folder store . the maintenance of folders may be either immediate , upon receipt of new messages by the messaging system , or deferred , upon access of the folder or some other policy used , e . g ., once a day . the folder management service is driven by events generated by the core components of the system . in particular , the service registers with the event dispatcher to receive notifications about message arrivals , message attribute modifications , folder access and folder modifications , among other events . upon message arrival , the folder management service receives a notification that includes the message identifier and the recipient ( s ) of the message . if any recipient uses declaratively specified folders , the service may choose either to immediately examine the message or to store the notification for future processing . upon folder access , the folder management service receives a notification which includes the identifier of the folder . if the folder is defined declaratively , the service takes responsibility to bring the folder contents up to date with respect to any past updates that affect the folder in question . an alerting service causes an alert to be sent to some or all of the recipients of a new message . the alerting service is “ driven ” by newly arrived message events , and it receives the list of recipients as part of the notification about the new message . then , it locates the user profiles for recipients that have registered to be alerted and carries out the actions specified in these profiles . possible actions include paging , faxing , automated phone calls , and pop - up message windows . although specific embodiments of the present invention have been described , it will be understood by those of skill in the art that there are other embodiments that are equivalent to the described embodiments . accordingly , it is to be understood that the invention is not to be limited by the specific illustrated embodiments , but only by the scope of the appended claims .