We now live in an information society where increasingly large volumes of data are exchanged between networked nodes in distributed systems. Recent years have seen a multitude of dierent serialization frameworks released to efficiently handle all this information while minimizing developer effort. One such format is Google Protocol Buers, which has gained additional code generation support for a wide variety of programming languages from third-party developers. Ada is a widely used programming language in safety-critical systems today. However, it lacks support for Protocol Buffers. This limits the use of Protocol Buffers at companies like Saab, where Ada is the language of choice for many systems. To amend this situation Ada code generation support for Protocol Buffers has been developed. The developed solution supports a majority of Protocol Buffers' language constructs, extensions being a notable exception. To evaluate the developed solution, an artificial benchmark was constructed and a comparison was made with GNATColl.JSON. Although the benchmark was artificial, data used by the benchmark followed the same format as an existing radar system. The benchmark showed that if serialization performance is a limiting factor for the radar system, it could potentially receive a significant speed boost from a substitution of serialization framework. Results from the benchmark reveal that Protocol Buffers is about 6 to 8 times faster in a combined serialization/deserialization performance comparison. In addition, the change of serialization format has the added benefit of reducing size of serialized objects by approximately 45%.

Monitoring of computer networks is central to ensuring that they function as intended, with solutions based on SNMP being used since the inception of the protocol. SNMP is however increasingly being challenged by solutions that, instead of requiring a request-response message flow, simply send information to a central collector at predefined intervals. These solutions are often based on Protobuf and gRPC, which are supported and promoted by equipment manufacturers such as Cisco, Huawei, and Juniper. Two models exist for monitoring. The pull model used by SNMP where requests are sent out in order to retrieve data, has historically been widely used. The push model, where data is sent at predefined intervals without a preceding request, is used by the implementations using Protobuf and gRPC. There is a perceived need to understand which model more efficiently uses bandwidth and the monitored system’s memory and processing resources. The purpose of the thesis is to compare two monitoring solutions, one being SNMP, and one based on Protobuf and gRPC. This is done to determine if one solution makes more efficient use of bandwidth and the system resources available to the network equipment. This could aid those who operate networks or develop monitoring software in determining how to implement their solutions. The study is conducted as a case study, where two routers manufactured by Cisco and Huawei were used to gather data about the bandwidth, memory, and CPU utilisation of the two solutions. The results of the measurements show that when retrieving information about objects that have 1-byte values SNMP was the better performer. When objects with larger values were retrieved SNMP performed best until 26 objects were retrieved per message. Above this point the combination of Protobuf and gRPC performed better, resulting in fewer bytes being sent for a given number of objects. No impact on the memory and CPU utilisation in the routers was shown. / Övervakning av nätverk är av yttersta vikt för att säkerställa att de fungerar som tänkt. Lösningar baserade på SNMP har använts sen protokollet kom till. SNMP utmanas mer och mer av lösningar som, istället för att använda ett meddelandeflöde baserat på fråga-svar, helt enkelt sänder information till en insamlande enhet i fördefinierade intervall. Dessa lösningar baseras ofta på Protobuf och gRPC, vilka stöds och propageras för av bland andra utrustningstillverkarna Cisco, Huawei, och Juniper. Två modeller för övervakning finns. Pull-modellen där frågor skickas ut för att hämta data, används av SNMP och har historiskt sett använts i stor skala. Push- modellen, där data skickas i fördefinierade intervall utan föregående fråga, används av lösningar som använder Protobuf och gRPC. Det finns ett behov av att förstå vilken modell som på ett mer effektivt sätt använder bandbredd och de övervakade systemens minnes- och processorresurser. Syftet med denna rapport är att jämföra två övervakningslösningar. SNMP är den ena lösningen, och den andra lösningen är baserad på Protobuf och gRPC. Detta i syfte att utröna om endera lösning på ett mer effektivt sätt använder bandbredd och systemresurser i nätverksutrustning. Detta kan hjälpa nätverksoperatörer och utvecklare av mjukvara för övervakning att avgöra hur dessa bör implementeras. För att besvara detta används en fallstudie, där två routrar tillverkade av Cisco och Huawei används för att samla in data om de två lösningarnas användning av bandbredd, minne, och processorkraft. Mätningarnas resultat visade att när objekt vars värde var 1 byte hämtades så presterade SNMP bättre. När objekt vars värden var större hämtades presterade SNMP bäst tills 26 objekt hämtades per meddelande. Därefter presterade kombinationen Protobuf och gRPC bättre, och krävde färre bytes för att skicka information om ett givet antal objekt. Ingen påverkan på minnes- eller processoranvändningen i routrarna påvisades av mätresultaten.

Detta arbete bidrar till val av serialiseringsformat. Val av serialiseringsformat är kritiskt för webbapplikationer som sänder och tar emot omfattande datamängder eftersom det påverkar reduceringen av datastorlek, samt hur snabbt en klient och server kan processa denna data. Arbetet utvärderar de binära serialiseringsformaten Protocol Buffers och FlatBuffers i webbaserade geografiska informationssystem. Tidigare forskning har förutsett att Flatbuffers borde vara effektivare än Protocol Buffers, men det saknas vetenskapliga belägg. Experiment genomfördes där serialiseringsformaten testades i programmeringsspråket Go, med kommunikationsprotokollen HTTP och WebSocket, samt där nätverkshastigheten var begränsad till 800, 200, 50 Mbit/s. Experimentet påvisade att det inte spelar det någon roll vilket serialiseringsformat som används när nätverkshastigheten är begränsad till 800 Mbit/s, och att Protocol Buffers presterade bättre när nätverkshastigheten är begränsad till 200 och 50 Mbit/s. Framtida arbeten kan öka kunskapen om serialiseringsformatens beteende i olika nätverkshastigheter och utvecklingsmiljöer, samt implementera renderingsverktyg utifrån schemafilerna i detta arbete.

Land use change has an impact on regional sustainability which can be assessed using social, economic and environmental indicators. Stakeholder engagement tools provide a platform that can demonstrate the possible future impacts land use change may have to better inform stakeholder groups of the impact of policy changes or plausible climatic variations. To date some engagement tools are difficult to use or understand and lack user interaction whilst other tools demonstrate model environments with a tightly coupled user interface, resulting in poor performance. The research and development described herein relates to the development and testing of a visualisation engine for rendering the output of an Agent Based Model (ABM) as a 3D Virtual Environment via a loosely-coupled data driven communications protocol called Protocol Buffers. The tool, named Rural Sustainability Visualisation Tool (R.S.V.T) is primarily aimed to enhance nonexpert knowledge and understanding of the effects of land use change, driven by farmer decision making, on the sustainability of a region. Communication protocols are evaluated and Protocol Buffers, a binarybased communications protocol is selected, based on speed of object serialization and data transfer, to pass message from the ABM to the 3D Virtual Environment. Early comparative testing of R.S.V.T and its 2D counterpart RepastS shows R.S.V.T and its loosely-coupled approach offers an increase in performance when rendering land use scenes. The flexibility of Protocol Buffer’s and MongoDB are also shown to have positive performance implications for storing and running of loosely-coupled model simulations. A 3D graphics Application Programming Interface (API), commonly used in the development of computer games technology is selected to develop the Virtual Environment. Multiple visualisation methods, designed to enhance stakeholder engagement and understanding, are developed and tested to determine their suitability in both user preference and information retrieval. The application of a prototype is demonstrated using a case study based in the Lunan catchment in Scotland, which has water quality and biodiversity issues due to intense agriculture. The region is modelled using three scenario storylines that broadly describe plausible futures. Business as Might Be Usual (BAMBU), Growth Applied Strategy (GRAS) and the Sustainable European Development Goal (SEDG) are the applied scenarios. The performance of the tool is assessed and it is found that R.S.V.T can run faster than its 2D equivalent when loosely coupled with a 3D Virtual Environment. The 3D Virtual Environment and its associated visualisation methods are assessed using non-expert stakeholder groups and it is shown that 3D ABM output is generally preferred to 2D ABM output. Insights are also gained into the most appropriate visualisation techniques for agricultural landscapes. Finally, the benefit of taking a loosely-coupled approach to the visualisation of model data is demonstrated through the performance of Protocol Buffers during testing, showing it is capable of transferring large amounts of model data to a bespoke visual front-end.

As the demand for better and faster applications increase every year, so does the demand for new communication systems between computers. Today, a common method for computers and software systems to exchange information is the use of REST APIs, but there are cases where more efficient solutions are needed. In such cases, RPC can provide a solution. There are many RPC libraries to choose from, but gRPC is the most widely used today. gRPC is said to offer faster and more efficient communication than conventional web-based API calls. The problem investigated in this thesis is that there are few available resources demonstrating how this performance difference translates into request throughput on a server. The purpose of the study is to benchmark the difference in request throughput for conventional API calls (REST) and gRPC. This was done with the goal of providing a basis for making better decisions regarding the choice of communication infrastructure between applications. A qualitative research method with support of quantitative data was used to evaluate the results. REST and gRPC servers were implemented in three programming languages. A benchmarking client was implemented in order to benchmark the servers and measure request throughput. The benchmarks were conducted on a local network between two hosts. The results indicate that gRPC performs better than REST for larger message payloads in terms of request throughput. REST initially outperforms gRPC for small payloads but falls behind as the payload size increases. The result can be beneficial for software developers and other stakeholders who strive to make informed decisions regarding communication infrastructure when developing and maintaining applications at scale. / Eftersom efterfrågan på bättre och snabbare applikationer ökar varje år, så ökar även behovet av nya kommunikationssystem mellan datorer. Idag är det vanligt att datorer och programvara utbyter information genom användning av APIer, men det finns fall där mer effektiva lösningar behövs. I sådana fall kan RPC erbjuda en lösning. Det finns många olika RPC-bibliotek att välja mellan, men gRPC är det mest använda idag. gRPC sägs erbjuda snabbare och mer effektiv kommunikation än konventionella webbaserade API-anrop. Problemet som undersöks i denna avhandling är att det finns få tillgängliga resurser som visar hur denna prestandaskillnad översätts till genomströmning av förfrågningar på en server. Syftet med studien är att mäta skillnaden i genomströmning av förfrågningar för konventionella API-anrop (REST) och gRPC. Detta gjordes med målet att ge en grund för att fatta bättre beslut om val av kommunikationsinfrastruktur mellan applikationer. En kvalitativ forskningsmetod med stöd av kvantitativa data användes för att utvärdera resultaten. REST- och gRPC-servrar implementerades i tre programmeringsspråk. En benchmarking-klient implementerades för att mäta servrarnas prestanda och genomströmning av förfrågningar. Mätningarna genomfördes i ett lokalt nätverk mellan två datorer. Resultaten visar att gRPC presterar bättre än REST för större meddelanden när det gäller genomströmning av förfrågningar. REST presterade initialt bättre än gRPC för små meddelanden, men faller efter när meddelandestorleken ökar. Resultatet kan vara fördelaktig för programutvecklare och andra intressenter som strävar efter att fatta informerade beslut gällande kommunikationsinfrastruktur vid utveckling och underhållning av applikationer i större skala.

Att flera datorer används för att gemensamt lösa problem är inte någonting nytt. Det finns många distribuerade system i bruk och många olika lösningar för hur dessa ska kommunicera med varandra. Vissa använder sig av meddelande-orienterade lager för kommunikation vilket det finns väldigt många implementationer av. RabbitMQ är ett exempel där att kommunikation går genom en (eller ett kluster av) central nod och kommunicerar med hjälp av protokollet Advanced Message Queue Protocol, AMQP. I en helt annan kategori finns ZeroMQ som inte definierar någon central nod för all kommunikation att passera utan peer to peer är istället möjlig vilket innebär snabbare responstider men försvårar hur olika klienter hittar till varandra. Det bloggindexerande företaget Twingly kör idag med ett distribuerat system som använder flera olika kösystem för att koordinera ut arbete till de olika datorerna. De vill kolla närmare på hur de kan bygga sitt system med hjälp av meddelande-orienterade lager. Resultatet av arbetet är att RabbitMQ innebär mindre komponenter att hålla reda på vilket innebär att koden blir mindre komplex. Det som kommer gratis med att använda RabbitMQ är just att klienterna inte behöver känna till varandra utan endast behöver känna till RabbitMQ-servern. Nackdelen är att RabbitMQ-servern kommer bli en flaskhals för systemet. ZeroMQ är däremot friare att implementera den funktionalitet man själv behöver vilket är till fördel i de fall tid och pengar finns för att skapa ett eget system byggt ovanpå ZeroMQ. För Twingly som vill ha ett system inom en snar framtid är RabbitMQ ett bättre val av dessa två alternativ.

The accelerating progress in network speeds and computing power permitted the architectural design paradigm to shift from monolithic applications to microservices. The industry moved from single-core and multi-threads, code-heavy applications, running on giant machines 24/7 to smaller machines, multi-cores single threads where computing power and memory consumption are managed very critically. With the advent of this novel approach to designing systems, traditional multi-tier applications have been broken down into hundreds of microservices that can be easily moved around, start, and stop quickly. In this context, scaling assumed a new meaning, rather than scaling up by adding more resources or computing power, now systems are scaled dynamically by adding more microservices instances. This contribution proposes a theoretical study and a practical experiment to investigate, compare and outline the performance improvements aid by the implementation of Protocol Buffers, Google's language-neutral, binary-based representational data interchange format over traditional text-based serialization formats in a modern, Cloud-Native, REST-based Java Microservice architecture. Findings are presented showing promising results regarding the implementation of Protobuf, with a significant reduction in response time (25.1% faster in the best-case scenario) and smaller payload size (72.28% better in the best-case scenario) when compared to traditional textual serialization formats while literature revealed out-of-the-box mechanisms for message versioning with backward compatibility.

Service-oriented computing is a popular technology that facilitates the development of large-scale distributed systems. However, the modular composition and flexible coordination of such applications still remains challenging for the following reasons: 1) the services are provided as loosely coupled black boxes that only expose their interfaces to the environment; 2) interacting services are not usually known in advance: web services are dynamically chosen to fulfil certain roles and are often replaced by services with a similar functionality; 3) the nature of the service-based application is decentralised. Loose coupling of web services is often lost when it comes to the construction of an application from services. The reason is that the object-oriented paradigm, which is widely used in the implementation of web services, does not provide a mechanism for service interface self-tuning. As a result, it negatively impacts upon the interoperability of web services. In this dissertation we present a formal method for automatic service configuration in the presence of subtyping, polymorphism, and flow inheritance. This is a challenging problem. On the one hand, the interface description language must be flexible enough to maintain service compatibility in various contexts without any modification to the service itself. On the other hand, the composition of interfaces in a distributed environment must be provably consistent. Our method is based on constraint satisfaction and Boolean satisfiability. First, we define a language for specifying service interfaces in a generic form, which is compatible with a variety of contexts. The language provides support for parametric polymorphism, Boolean variables, which are used to control dependencies between any elements of interface collections, and flow inheritance using extensible records and variants. We implemented the method as a constraint satisfaction solver. In addition to this, we present a protocol for interface configuration. It specifies a sequence of steps that leads to the generation of context-specific service libraries from generic services. Furthermore, we developed a toolchain that performs a complete interface configuration for services written in C++. We integrated support for flexible interface objects (i.e. objects that can be transferred in the application along with their structural description). Although the protocol relies solely on interfaces and does not take behaviour concerns into account, it is capable of finding discrepancies between input and output interfaces for simple stateful services, which only perform message synchronisation. Two running examples (a three buyers use-case and an image processing application) are used along the way to illustrate our approach. Our results seem to be useful for service providers that run their services in the cloud. The reason is twofold. Firstly, interfaces and the code behind them can be generic as long as they are sufficiently configurable. No communication between service designers is necessary in order to ensure consistency in the design. Instead, the interface correspondence in the application is ensured by the constraint satisfaction algorithm, which we have already designed. Secondly, the configuration and compilation of every service are separated from the rest of the application. This prevents source code leaks in proprietary software which is running in the cloud.

Geographic Information Systems and Network Information Systems are important tools for our society, used for handling geographic spatial data and large information networks. It is therefore important to make sure such tools are of high quality. GIS/NIS applications typically deal with a lot of data, possibly resulting in heavy loads of network traffic. This work aims to evaluate two different communications protocols and serialization formats for client-server communications efficiency in GIS/NIS applications. Specifically, these are HTTP/1.1, HTTP/2, Java Object Serialization and Google's Protocol Buffers. They were each implemented directly into a commercial GIS/NIS environment and evaluated by measuring two signature server calls in the system. Metrics that were examined are call duration, HTTP overhead size and HTTP payload size. The results suggest that HTTP/2 and Google's Protocol Buffers outperform HTTP/1.1 and Java Object Serialization respectively. An 87% decrease in HTTP overhead size was achieved when switching from HTTP/1.1 to HTTP/2. The HTTP payload size is also shown to decrease with the use of Protocol Buffers rather than Java Object Serialization, especially for communications where data consist of many different object types. Concerning call duration, the results suggest that the choice of communications protocol is more significant than the choice of serialization format for communications containing little data, while the opposite is true for communications containing much data. / Geografiska informationssystem och nätverksinformationssystem är viktiga redskap för vårt samhälle, vilka används för hantering av geografisk data och stora informationsnätverk. Det är därför viktigt att se till att sådana system är av hög kvalitet. GIS/NIS-applikationer behandlar vanligtvis stora mängder data, vilket kan resultera i mycket nätverkstrafik. I det här arbetet utvärderas två olika kommunikationsprotokoll och serialiseringsformat för kommunikationseffektivitet mellan klient och server i GIS/NIS-applikationer. Specifikt är dessa HTTP/1.1, HTTP/2, Java Objektserialisering och Googles Protocol Buffers. De implementerades var och en i en kommersiell GIS/NIS-miljö och utvärderades genom mätningar av två signaturanrop i systemet. De aspekter som observerades är kommunikationstiden, mängden HTTP-overhead och mängden HTTP-payload. Resultaten tyder på att HTTP/2 och Googles Protocol Buffers presterar bättre än HTTP/1.1 respektive Java Objektserialisering. En 87% minskning av mängden HTTP overhead uppnåddes då HTTP/1.1 ersattes med HTTP/2. En minskning av mängden HTTP payload observeras också med användning av Protocol Buffers snarare än Java Objektserialisering, särskilt för kommunikationer där data innehåller många olika objekttyper. Gällande kommunikationstiden tyder resultaten på att valet av kommunikationsprotokoll påverkar mer än valet av serialiseringsformat för kommunikationer med små mängder data, medan motsatsen gäller för kommunikationer med mycket data.