Patent Application
20070011266
A service is a system that a consumer of the service interacts with through a set of coarse-grained messages. A service oriented application may be composed of one or more services. Each of these application services typically contains a set of entities. Entities, in general, encapsulate data and provide a rich programming model for creating, reading, updating and deleting the data owned by the service.
Services typically contain private data and public data. The private data is encapsulated in an internal entity so that, within the service, the programming model provides access to all of the data and associations contained in the internal entity, but external to the service, the internal entity is not exposed through the service interface. However, public data is encapsulated in a publicly available entity which is available to consumers of the service.
It is common for a consumer of a service to access data of an entity owned by the service. One prior way for enabling this had the consumer directly access the owning service's data store. However, direct access to the owning service's data store requires the consumer of the data to have knowledge of the technology and table structure used by the owning service to store data in its data store. Similarly, such direct access allows the consumer to potentially view and change private data within the service. This is problematic for a number of reasons, and is discouraged in applications that honor the publicly known tenets of service orientation. These are set out in an article by Don Box entitled Code Name Indigo: A Guide to Developing and Running Connected Systems with Indigo, MSDN Magazine, January 2004. Basically, allowing an external service or client to bind directly to the owning service's data (either by access to the service's private entities or by directly accessing the data store which the service stores its data in) is a technique that compromises data integrity, the autonomy, and the explicit boundaries of the service in a service oriented environment. Instead, all communication with a service should occur using standardized message exchange.
There are a variety of message exchange patterns which may occur in a service oriented environment. One of these patterns is out-only messaging. In this pattern multiple services, referred to as subscribers, subscribe to certain notifications from a given service, referred to as a publisher. At the appropriate times, that service then sends these notification messages to all interested subscribers. Uses for this message exchange pattern include synchronization subsystems, auditing subsystems, various business logic, and many others. The difficulty with utilizing this message exchange pattern today is the publisher must ensure that all appropriate out-only messages are sent, or risk corrupting or confusing any of the subscribers or subsystems using out-only messaging.
The out-only messaging pattern is very similar to the concept of eventing in many existing programming languages. Most application frameworks currently provide a way for business logic to subscribe to create, update and delete events within a service and perform local processing logic when they occur. However, when a separate service wishes to be notified about these create update and delete events, it must subscribe and be notified via messaging. One way a service subscribes and is notified of these events is defined in the WS-Eventing specification. This specification does not provide guidance on how to ensure that all internal events are properly sent as external out-only messages however
When a service holds data from another service, it becomes very important to synchronize that data with associated data in a local data store. Synchronization is the process through which data is replicated to a local data store and maintained by applying changes made to the owning service's data store to the consumer's data store. For instance, a consumer may wish to periodically synchronize data from the owning service's data store to its own local data store.
A system for providing automatic event publication relative to data owned by a service is disclosed. A service which owns data publishes internal events when data is created, updated, or deleted. These internal events are only visible by consumers on the same physical computer and running within the same process or executable. Consumers who are located remotely or in a separate process cannot subscribe to these events. Embodiments provide the ability to expose local entity create, update, and delete events as “public” events (or out-only messages) on a service contract. This allows external consumers who may be remote and even on a different platform, to subscribe and receive notifications of when data changes in the owning service.
Embodiments disclosed herein generally provide, or otherwise facilitate, ensuring that all internal events within a service are sent out correctly. This helps ensure that no data is lost or corrupted.
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, telephony systems, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention is designed to be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules are located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into the computer 110 through input devices such as a keyboard 162, a microphone 163, and a pointing device 161, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195.
The computer 110 is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110. The logical connections depicted in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
Service B also includes a plurality of entities (entity 5-entity M) that are stored in a data store 208 that is local to service B.
Service 200 can exist on one or more computer systems, such as that described above with respect to
In one example, an embodiment is used to facilitate data synchronization between services. However, it is important to note that embodiments can be used to provide automatic outgoing service messaging in any context, such as, but not limited to, synchronization subsystems, auditing subsystems, various business logic, and many other contexts. In accordance with one embodiment, subsystem 302 enlists as a local subscriber to all reference data modification events published by framework 308 within the reference service. These modification events include the creation, updating and deletion of data. When one of the reference data modification events occurs within the service that owns the reference data, distributed event subsystem component 302 preferably converts the internal event information provided by framework 308 into an appropriate outgoing message to send to one or more services that may be subscribing to Service A 204.
Distributed event subsystem 302 is illustrated in
In one example, subsystem 302 can provide an important component in the automatic synchronization between reference data and one or more local copies exposed remotely therefrom. Without subsystem 302, developers would be forced to carefully send the appropriate create, update or delete messages to all subscribing services or run the risk of corrupting the reference data on the subscribing service(s). Since reference data may be changed in many, many places throughout the system, there is a high likelihood that without subsystem 302, at least one situation would arise where a create, update or delete event message is not sent out properly or not sent out at all.
Block 508 is preferably executed as one physical transaction. In other words, the handling of the event and the placement of the outgoing message(s) on a reliable, durable message bus are performed as a single physical transaction. This helps ensure that referential data integrity is maintained (if the subscriber is storing data related to the event) and that no CUD events are lost.
The communication and generation of publisher and subscriber relationships in service oriented architectures are known. One example of a suitable inter-service messaging specification is known as the Web Services (WS) Eventing Specification, which specification is a collaboration between and among BEA Systems Inc., Computer Associates, Inc. International Business Machines Corporation, Microsoft Corporation Inc., Sun Microsystems, Inc and TIBCO Software Inc. While embodiments of the present invention can advantageously employ aspects of messaging in accordance with the WS-Eventing Specification, any suitable inter-service messaging can be used. Additionally, while publisher/subscriber relationships are known for service oriented architectures, there does exist one important modification to facilitate utilization of embodiments of the present invention. Specifically, these publisher/subscriber relationships were generally created for set periods of time, after which the relationship was automatically dissolved. However, since a given relationship is useful for an extended period of time, even when systems are restarted, it is preferred that the relationships described with respect to embodiments of the present invention be durable relationships. A durable relationship exists until the consumer no longer wishes to be subscribed to the event. The use of durable relationships ensures that such relationships continue to exist even if the owning service or subscribing service should fail and/or be restarted.
Although the present invention has been described with reference to particular embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention.
