This morning I held a short presentation to share my vision on the project. The handouts for this presentation with the title "SQLbusRT: A first glance" are available at our SourceForge project website.
You can download these handouts directly by clicking this link: SQLbusRT: A first glance
Monday, May 29, 2006
Tuesday, May 23, 2006
Support for multiple DB instances
As I mentioned in my previous post, I would change the architecture to support multiple DB instances. In fact, the change was fairly simple, as you can see in the following drawing:
As you can see, I added a copy of the complete set of components which interact with the database. In the drawing two databases are connected to the bus, but copying the components can be repeated multiple times to allow more db instances to connect to the bus.
So what are the changes in the scenario?
In the previous design, only one db subscriber requested the sensor data to put it in the database. Again, only one one db publisher was present to publish the query results onto the bus.
In this new design, multiple instances of the db subscriber are reading the sensor data from the bus. They are responsible to pass the information on to their own database that is connected to them. Every database instance has its own publisher to make the data available on the bus again. This means that in normal operation, duplicate data is sent to the bus. However, each db publisher has a different strength on the ORTE bus. Therefore, clients will only receive the data once.
In case a database fails to produce data (for instance, the db connection is broken, or the db is too busy and therefore is not able to produce the data in time) the data from the publisher with the second highest strength is read by the clients.
The great benefit of this design is that no reconnect to a database duplicate is necessary when the master database fails. The second (and third, fourth...) database instance is already up and running and even publishing its data.
As you can see, I added a copy of the complete set of components which interact with the database. In the drawing two databases are connected to the bus, but copying the components can be repeated multiple times to allow more db instances to connect to the bus.So what are the changes in the scenario?
In the previous design, only one db subscriber requested the sensor data to put it in the database. Again, only one one db publisher was present to publish the query results onto the bus.
In this new design, multiple instances of the db subscriber are reading the sensor data from the bus. They are responsible to pass the information on to their own database that is connected to them. Every database instance has its own publisher to make the data available on the bus again. This means that in normal operation, duplicate data is sent to the bus. However, each db publisher has a different strength on the ORTE bus. Therefore, clients will only receive the data once.
In case a database fails to produce data (for instance, the db connection is broken, or the db is too busy and therefore is not able to produce the data in time) the data from the publisher with the second highest strength is read by the clients.
The great benefit of this design is that no reconnect to a database duplicate is necessary when the master database fails. The second (and third, fourth...) database instance is already up and running and even publishing its data.
Conceptual architecture
In the past week a bit of collaboration with colleagues resulted in the following conceptual architecture:
You can look at the project website at sourceforge for an explanation of the different components in this diagram.
Soon (perhaps today) I'll post a new conceptual architecture, which lets multiple databases connect to the bus.
Feel free to comment on this architecture!
You can look at the project website at sourceforge for an explanation of the different components in this diagram.Soon (perhaps today) I'll post a new conceptual architecture, which lets multiple databases connect to the bus.
Feel free to comment on this architecture!
Monday, May 22, 2006
Welcome!
Welcome to my SQLbusRT blog!
My name is Bram Smulders. I recently started my final project for Imtech ICT Technical Systems in Amersfoort, the Netherlands, to finish my Masters degree at the University of Twente.
This blog will be used to keep all interested parties informed on the progress of this project.
So what is SQLbusRT?
SQLbusRT is a bus architecture with database connectivity which lets multiple publishers and subscribers exchange data meeting real time constraints. The benefit of having the database connectivity is that not only new data can be read by subscribers, also history data can be retrieved from the database, still meeting the real time constraints.
Currently the project is in a conceptual phase.
Information on this project
Besides this blog, there's also a website at SourceForge to keep you up to date on the project. You can find it at: http://sqlbusrt.sourceforge.net
The sourceforge website is the main website for this project. You'll find all the information available on this project right there. This blog however is to give you quick updates and to share thoughts with all interested parties. You can (read: you're heartily invited to) post your comments, share your thoughts and give all kinds of ideas related to the project.
Subscribe to:
Posts (Atom)