China
Africa
Explore chapters and articles related to this topic
Service Deployment
Published in Krzysztof W. Kolodziej, Johan Hjelm, Local Positioning Systems, 2017
Krzysztof W. Kolodziej, Johan Hjelm
Similarly to the location service, the content service is implemented in Java and deployed as a web service on a Tomcat server running Apache SOAP, and is also a passive service. The content service itself serves as a public gateway to a MySQL database This is similar to the location service that serves as a gateway to a back-end Ekahau Positioning Engine. Communication between the service and the database is done via the MySQL Java Database Connectivity (JDBC) connector. Therefore, the content service and database can be located on totally different servers, since communication between the service and the database can be done remotely. The database makes use of the InnoDB database type, which allows for foreign key constraints and is searchable in a variety of different ways. The database contains universal resource locater (URL) references to content, which the content service returns to the application. The content service only provides references to the content; it does not deliver the content itself. This prevents the need to organize binary data, such as pictures and audio, into SOAP envelopes, and allows the actual content to be located in multiple locations. All the content is downloaded via a wireless Internet connection from a web server. The application simply gets a URL for all content it is supposed to display. A wireless network connection must be available to fetch or download the data from a URL. Outdoors on our campus there is no Wi-Fi available. Once the entire campus becomes wireless, then there will be no problem with downloading content using the same communication network. Figure 8.19 shows how the content service works.
Backward chaining inference as a database stored procedure – the experiments on real-world knowledge bases
Published in Journal of Information and Telecommunication, 2018
Tomasz Xie¸ski, Roman Simiński
If data safety is the biggest concern, the InnoDB storage engine should be taken into account because it has commit, rollback and crash-recovery capabilities. Unfortunately, as the results presented in Table 3 indicate, it also performs worst in the backward chaining inference task. The differences between the previously analysed storage engines for the smaller knowledge bases (eval416, eval1119 and bud4438) may be still considered as acceptable (as they are in the range of 4–9 s). However, results for the bud22190 knowledge base indicate a noticeable difference. The InnoDB engine needs 36 more seconds on average to return the outcome of inference. Therefore, for larger and more complex knowledge bases the usage of the InnoDB storage engine may not be even applicable.