Show simple item record  

dc.contributor.authorSchweppe, Heinz
dc.contributor.authorHinze, Annika
dc.contributor.authorFaensen, Daniel
dc.coverage.spatialConference held at Prague, Czech Republicen_NZ
dc.date.accessioned2008-11-20T03:55:36Z
dc.date.available2008-11-20T03:55:36Z
dc.date.issued2000
dc.identifier.citationSchweppe, H., Hinze, A. & Faensen, D. (2000). Database systems as middleware- event, notifications, messages. In Proceedings of the East-European Conference on Advances in Databases and Information Systems Held Jointly with International Conference on Database Systems for Advanced Applications: Current Issues in Databases and Information Systems. September 05 - 08, 2000(pp. 21-22). Berlin: Springer.en_US
dc.identifier.urihttps://hdl.handle.net/10289/1421
dc.description.abstractDatabase systems have been traditionally used as integration tools. Data integration was the primary goal of first generation systems. After relational technology had become a mature base for application development, new architectures where developed for the tight integration of data, procedures and all kinds of processing. This phase of DBS research and development was dominated by object-oriented database management and specific architectures like Starburst [HaCH 1990], which had a strong impact on current object-relational technology. The ubiquitous computer network has added another facet to the usage of DBS as an integration tool. In distributed environment, middleware aims at making distribution transparent. Corba or RMI are well-known examples. The call-oriented style of communication has been complemented by message-oriented, event-driven interaction of independent programs. System processes use this type of communication for decades. However, it is not well known as a mechanism on the application level - despite the fact that it has been employed for quite some time, e.g. in workflow systems [LeRo 2000]. The event-driven message passing paradigm becomes more and more important for highly distributed applications. Many kinds of interactions between applications follow a common pattern: n inde-pendent providers submit their output as messages, which in turn will be consumed asynchronously by m consumer applications. As opposed to call-level interaction, providers and consumers may or may not know each others identity. In a stock ticker application for example, there is no reason why providers should know the identity of consumers.en_US
dc.language.isoen
dc.publisherSpringer, Berlinen_US
dc.relation.urihttp://www.springerlink.com/content/xbmgt7n6yu7v35ge/?p=e44466a3a0954c98b153397e886c0d0a&pi=1en_US
dc.sourceADBIS-DASFAA 2000en_NZ
dc.subjectcomputer scienceen_US
dc.subjectdatabase systemen_US
dc.titleDatabase systems as middleware- event, notifications, messagesen_US
dc.typeConference Contributionen_US
dc.identifier.doi10.1007/3-540-44472-6_2en_US
dc.relation.isPartOfEast-European Conference on Advances Iin Databases Aand Information Systems / International Conference on Database Systems for Advanced Applicationsen_NZ
pubs.begin-page21en_NZ
pubs.elements-id15786
pubs.end-page22en_NZ
pubs.finish-date2000-09-08en_NZ
pubs.place-of-publicationGermanyen_NZ
pubs.start-date2000-09-05en_NZ
pubs.volumeLNCS 1884en_NZ


Files in this item

FilesSizeFormatView

There are no files associated with this item.

This item appears in the following Collection(s)

Show simple item record