Explore chapters and articles related to this topic
Data Serialization and Deserialization
Published in Hossam Fattah, LTE™ Cellular Narrowband Internet of Things (NB-IoT), 2021
JSON stands for JavaScript Object Notation. JSON is a human-readable and writable data format. It is easy for machines to parse and generate it. JSON is a text format that is language independent which means it can be used in a programming language like C/C++ or Java [23]. It also can be used with Arduino. These properties make JSON an ideal data-interchange language especially to the cloud and with web servers. JSON format is built using the following two structures: A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.
Common Standards in Cloud Computing
Published in John W. Rittinghouse, James F. Ransome, Cloud Computing, 2017
John W. Rittinghouse, James F. Ransome
Even though JSON was intended as a data serialization format, its design as a subset of the JavaScript language poses security concerns. The use of a JavaScript interpreter to dynamically execute JSON text as JavaS- cript can expose a program to bad or even malicious script. JSON is also subject to cross-site request forgery attacks. This can allow JSON-encoded data to be evaluated in the context of a malicious page, possibly divulging passwords or other sensitive data. This is only a problem if the server depends on the browser’s Same Origin Policy to block the delivery of the data in the case of an improper request. When the server determines the propriety of the request, there is no problem because it will only output data if the request is valid. Cookies are not adequate for determining whether a request is authorized and valid. The use of cookies is subject to cross-site request forgery and should be avoided with JSON. As you can see, JSON was built for simple tasks and can be useful, but there is some risk involved in using it—especially given the alternative solutions available today.
Semantic Interoperability of Long-Tail Geoscience Resources over the Web
Published in Ashok N. Srivastava, Ramakrishna Nemani, Karsten Steinhaeuser, Large-Scale Machine Learning in the Earth Sciences, 2017
Mostafa M. Elag, Praveen Kumar, Luigi Marini, Scott D. Peckham, Rui Liu
Web services were introduced to characterize machine-to-machine communication built over HTTP [28]. A set of standards has been developed by the World Wide Web Consortium (W3C) working groups over time to describe machine processable formats and communications protocols such as the Web Services Description Language (WSDL) and the Simple Object Access Protocol (SOAP). Over time, some of these standards have fallen out of popularity because of their complexity and have been replaced by simpler software architecture styles such as Representational State Transfer (REST); conceptually it is built upon the same principles of HTTP and provides methods to facilitate the development of Web services. Most RESTFul web services are written as plain HTTP services using eXtensible Markup Language (XML) or JavaScript Object Notation (JSON) for content representation. XML was developed by the W3C for data exchange over the Web [29]. It is a flexible, self-describing markup language format and provides a hierarchical syntax structure for encoding data and their relationships. However, using XML can produce syntactic heterogeneity because data can be organized in many different ways. JSON is a lightweight interchange format native to the Web, easy for both humans and machines to read and write. Although Web application programming interface (API) can refer to both types, over time it is becoming synonymous with the RESTFul approach. Both RESTFul and API use simple protocols, but they have shortcomings in self-description methods, and built-in ways to support interoperation among services. Today many resources are available through Web API, but the format in which these resources are made available and described varies greatly.
Designing interoperable telehealth platforms: bridging IoT devices with cloud infrastructures
Published in Enterprise Information Systems, 2020
Kostas M. Tsiouris, Dimitrios Gatsios, Vassilios Tsakanikas, Athanasios A. Pardalis, Ioannis Kouris, Thelma Androutsou, Marilena Tarousi, Natasa Vujnovic Sedlar, Iason Somarakis, Fariba Mostajeran, Nenad Filipovic, Harm op den Akker, Dimitrios D. Koutsouris, Dimitrios I. Fotiadis
The Orion Context Broker is used to create and manage the entire lifecycle of context information, which consists of unique entities and their respective attributes, allowing any part of the platform to push and get updates, queries, registrations and subscriptions. Orion implements the Publisher-Subscriber pattern, which enables an application to announce events to multiple interested consumers asynchronously, without coupling the sender(s) to the receiver(s). This process is presented in Figure 3. Asynchronous messaging is an effective way to decouple senders from consumers, and avoid blocking the sender to wait for a response. However, using a dedicated message queue for each consumer does not effectively scale with many consumers. Also, some of the consumers might be interested in only a subset of the information. Data to be exchanged is formatted in JSON objects. JSON is the abbreviation for ‘JavaScript Object Notation’ which is designed to exchange data as a standard format. It is a simple text-based and lightweight data standard, which is intended for human-readable data exchange. More technical details regarding the communication protocol are presented in the Appendix.
iSDS: a self-configurable software-defined storage system for enterprise
Published in Enterprise Information Systems, 2018
Wen-Shyen Eric Chen, Chun-Fang Huang, Ming-Jen Huang
An example of JSON output from the long-term prediction is shown in Figure 13. JSON format is not only machine readable but also easier for human comprehension. In this exemplified output, the values of the properties ‘manager_id’, ‘analysis_type’ and ‘metrics’ represent the identification number of iSDS, the long-term prediction type and read IOPS of performance metrics, respectively. The next is a list of read IOPS prediction. Each item in the list represents a predictive value of the long-term prediction of read IOPS. The property ‘storage_id’ is the identification of a storage pool or a storage volume. The property ‘prediction_index’ stores a number that represents the time order of long-term prediction. The property ‘prediction’ stores the predictive values of read IOPS.
The potential of semantic paradigm in warehousing of big data
Published in Automatika, 2019
Marina Ptiček, Boris Vrdoljak, Marko Gulić
Document stores (also called document-oriented databases) are the most adopted NoSQL paradigm. They store data in forms of documents, i.e. sets of key-value pairs, where the key part of the data is the metadata (“name tag”) of its value part. Documents bear great similarity to XML documents for being self-describing and having hierarchy concept – the basic difference is that a JSON document is shorter and easier to read and write. Documents in a document store are grouped in collections. Comparing document and relational storage paradigms conceptually, most often conceptual mapping is that a collection corresponds to a table (relation), a document to a tuple, keys to column (attribute) names, and values to values stored in cells.