A Linear Logic approach to RESTful web service modelling and composition

A thesis submitted to the University of Bedfordshire in partial fulfilment of the requirements for the degree of Doctor of PhilosophyRESTful Web Services are gaining increasing attention from both the service and the Web communities. The rising number of services being implemented and made available on the Web is creating a demand for modelling techniques that can abstract REST design from the implementation in order better to specify, analyse and implement large-scale RESTful Web systems. It can also help by providing suitable RESTful Web Service composition methods which can reduce costs by effi ciently re-using the large number of services that are already available and by exploiting existing services for complex business purposes. This research considers RESTful Web Services as state transition systems and proposes a novel Linear Logic based approach, the first of its kind, for both the modelling and the composition of RESTful Web Services. The thesis demonstrates the capabilities of resource-sensitive Linear Logic for modelling five key REST constraints and proposes a two-stage approach to service composition involving Linear Logic theorem proving and proof-as-process based on the π-calculus. Whereas previous approaches have focused on each aspect of the composition of RESTful Web Services individually (e.g. execution or high-level modelling), this work bridges the gap between abstract formal modelling and application-level execution in an efficient and effective way. The approach not only ensures the completeness and correctness of the resulting composed services but also produces their process models naturally, providing the possibility to translate them into executable business languages. Furthermore, the research encodes the proposed modelling and composition method into the Coq proof assistant, which enables both the Linear Logic theorem proving and the π-calculus extraction to be conducted semi-automatically. The feasibility and versatility studies performed in two disparate user scenarios (shopping and biomedical service composition) show that the proposed method provides a good level of scalability when the numbers of services and resources grow

Rule-based Programming of User Agents for Linked Data

While current Semantic Web languages and technologies are well-suited for accessing and integrating static data, methods and technologies for the handling of dynamic aspects – required in many modern web environments – are largely missing. We propose to use Abstract State Machines (ASMs) as the formal basis for dealing with changes in Linked Data, which is the combination of the Resource Description Framework (RDF) with the Hypertext Transfer Protocol (HTTP). We provide a synthesis of ASMs and Linked Data and show how the combination aligns with the relevant specifications such as the Request/Response communication in HTTP, the guidelines for updating resource state in the Linked Data Platform (LDP) specification, and the formal grounding of RDF in model theory. Based on the formalisation of Linked Data resources that change state over time, we present the syntax and operational semantics of a small rule-based language to specify user agents that use HTTP to interact with Linked Data as the interface to the environment. We show the feasibility of the approach in an evaluation involving the specification of automation in a Smart Building scenario, where the presented approach serves as a theoretical foundation

Correct-by-Construction Web Service Architecture

Abstract—Service-Oriented Computing aims to facilitate devel-opment of large-scale applications out of loosely coupled services. The service architecture sets the framework for achieving cohe-rence and interoperability despite service autonomy and the hete-rogeneity in data representation and protocols. Service-Oriented Architectures are based on standardized service contracts, in order to infuse characteristic properties (stateless interactions, atomicity etc). However, contracts cannot ensure correctness of services if essential operational details are overlooked, as is usually the case. We introduce a modeling framework for the specification of Web Service architectures, in terms of formal operational semantics. Our approach aims to enable rigorous design of Web Services, based on the Behaviour Interaction Priorities (BIP) component framework and the principles of correctness-by-construction. We provide executable BIP models for SOAP-based and RESTful Web Services and for a service ar-chitecture with session replication. The architectures are treated as reusable design artifacts that may be composed, such that their characteristic properties are preserved

Automatic tests generation for Restful Apis

Tese de mestrado, Engenharia Informática (Engenharia de Software), Universidade de Lisboa, Faculdade de Ciências, 2017A programação de serviços web que fornecem interfaces aplicacionais que seguem os princípios do estilo arquitetural REST (Representational State Transfer) [38], designadas em inglês por RESTful APIs, e de aplicações cliente deste tipo de serviços é actualmente muito popular [63]. Por exemplo, aplicações como Twitter, Instagram, Youtube, Uber e Gitlab, fornecem acesso programático às suas aplicações cliente através deste tipo de APIs (Application Programming Interfaces). Isto acontece porque o uso deste tipo de APIs, quando comparado com as tradicionais interfaces de serviços web baseados em SOAP (Simple Object Access Protocol), simplificam grandemente o desenvolvimento das aplicações cliente. Mais recentemente, com o advento da arquitetura baseada em microserviços, o desenho de aplicações como conjuntos de serviços tornou-se muito comum, alavancando ainda mais a utilização das APIs REST [35]. O desenvolvimento eficaz de aplicações cliente deste tipo de serviços exige que as suas interfaces estejam bem documentadas. Apesar de iniciativas importantes como a Open API Specification [11], focadas na criação e promoção de um formato aberto para a descrição de APIs REST, o suporte à descrição deste tipo de APIs é atualmente extremamente limitado e incide, sobretudo, na estrutura e representações dos dados trocados entre clientes e fornecedores. De forma a ultrapassar as limitações existentes e suportar também a descrição de aspetos semânticos subjacentes às APIs REST, desenhámos e implementámos a linguagem HEADREST que permite especificar cada um dos seus serviços individualmente, num estilo reminescente dos triplos de Hoare [50], os quais designamos simplesmente por asserções e utilizando tipos de refinamento [45]. HEADREST é uma linguagem que inclui elementos para superar as limitações das abordagens existentes. O objetivo de HEADREST não é estender a Open API Specification, mas antes identificar primitivas que permitam aumentar o seu poder expressivo e demonstrar que é possível explorar estas descrições para avançar o estado da arte no que diz respeito à programação e testes de APIs REST. Normalmente, as regras de negócio de APIs REST esperam que os seus clientes enviem valores que respeitem alguma expressão lógica, por exemplo, um número de contribuinte. De forma a suportar esse requisito, HEADREST suporta tipos de refinamento que refinem um tipo base (booleano, inteiro, string ou array) perante uma fórmula. Em APIs REST, o estado da API consiste no conjunto de recursos que existem em algum instante temporal. Assim sendo, as asserções subdividem-se em um método (a ação a realizar), um URI (Uniform Resource Identifier) Template [46], uma pré-condição e uma pós-condição. Enquanto que a pré-condição especifica o estado no qual a asserção é válida, além de refinar os dados a enviar no pedido para a API, a pós-condição especifica o estado resultante da execução do pedido enviado e os dados de resposta produzidos pela API. Uma asserção descreve então que se um pedido para a execução de uma certa ação (por exemplo, POST [39]) sobre uma expansão do URI Template da asserção inclui dados que satisfazem a pré-condição, sendo que a ação é desenrolada num estado que satisfaz a pré-condição, então a resposta e o estado resultante satisfazem a pós-condição. De forma a descrever um estado esperado da API são usadas variáveis de recurso que representam recursos de um certo tipo. Usando estas variáveis de recurso e quantificadores existenciais ou universais é possível escrever as pré-condições ou pós-condições que descrevem o estado esperado. No geral, HEADREST suporta expressões lógicas, aritméticas e relacionais, predicados sobre arrays, além de acesso a propriedades de objetos bem como de entradas de arrays e, um predicado para verificar se uma dada string está no universo de uma expressão regular. Através do uso continuado de HEADREST, usando um estudo de caso desenvolvido para suportar o presente trabalho, foram adicionados construtores derivados da sintaxe base que reduzem a quantidade de código a escrever, bem como os potenciais erros subjacentes. De forma a facilitar a especificação de APIs REST em HEADREST desenvolvemos um plug-in para o Eclipse de modo a permitir a validação sintáctica e semântica. A implementação da linguagem foi feita utilizando a framework Xtext que permite o desenvolvimento de novas linguagens e plug-ins para o Eclipse. Podemos dividir a implementação em três partes: escrita da gramática, implementação de um mecanismo para verificar se todas variáveis de uma especificação estão devidamente declaradas e implementação do sistema de tipos. O nosso sistema de tipos é bidirecional, existindo duas relações de tipificação: uma de verificação de tipos; e outra de síntese de tipos. A verificação se um dado tipo é subtipo de outro tipo é feita de forma semântica [43] recorrendo a um SMT (Satisfiability Modulo Theories), nomeadamente Z3 [32]. Para tal baseamo-nos no trabalho de Bierman et al. [26], sendo que modificámos a axiomatização para o Z3 apresentada nesse trabalho de forma a contemplar os construtores da nossa linguagem. No futuro, espera-se conseguir gerar stubs servidor e SDKs (Software Development Kits) cliente a partir de especificações descritas usando HEADREST e verificar estaticamente código cliente e servidor de encontro a especificações HEADREST. Além disso, pretende-se integrar na linguagem questões de segurança em contexto REST, nomeadamente em termos de autenticação e de confidencialidade. Um dos usos possíveis desta linguagem é a geração e execução automática de testes. Para tal explorámos duas metodologias de testes diferentes. Ambas as metodologias apresentam como ponto comum a avaliação de uma asserção que é feita através do uso do Z3 para gerar pedidos que satisfaçam a pré-condição e inclui a verificação da pós-condição a partir da resposta obtida. A primeira metodologia envolve construir uma árvore de classificação [47] para cada asserção da especificação e usando um critério de cobertura, atualmente Minimum Coverage, gerar variações da pré-condição da asserção em questão. Estas variações exploram mudanças de certos elementos da linguagem (por exemplo, disjunções) tentando manter a satisfiabilidade da expressão. Por exemplo, uma disjunção e1 V e2 pode ser substituída por uma de três formas alternativas: e1 ^ e2, ¬e1 ^ e2 ou e1 ^ ¬e2. Esta metodologia exige que o testador especifique para cada caso de teste gerado o contexto no qual a nova asserção é satisfazível. Esse contexto é composto por uma sequência de outras asserções da especificação que são avaliadas antes de avaliar a própria asserção. A segunda metodologia tenta avaliar uma sequência aleatória de asserções de tamanho N. Para tal, a cada momento uma asserção é escolhida do conjunto de asserções da especificação. De forma a melhorar esta seleção pontuamos cada asserção é escolhida asserção que possua uma maior pontuação cuja pré-condição seja satisfazível. Repetimos este procedimento N vezes, podendo ainda repetir o algoritmo completo M vezes. A pontuação dada às asserções considera se uma dada asserção já foi avaliada alguma vez (Assertion Coverage), se um dado par de asserções, que finaliza na asserção em questão, já foi avaliado de forma consecutiva (Assertion Pair Coverage), o impacto que o método da asserção tem sobre a API (por exemplo, um POST bem sucedido tem maior impacto do que um POST mal sucedido). Em caso de empate, as asserções em questão são ordenadas de forma aleatória, sendo que é possível especificar a semente do gerador de números aleatórios de forma a que o teste de sequência seja determinista, podendo ser repetido mais tarde. Além disso, incluímos ainda um algoritmo adaptado do trabalho de Chakrabarti et al. [30] que verifica se uma dada API respeita a restrição do REST Hypermedia As The Engine of Application State. Este algoritmo pode ser executado após a avaliação de qualquer asserção, sendo que quando usado em conjunção com o teste de sequência permite identificar operações que fazem com que a API deixe de respeitar esse princípio. Da avaliação à primeira metodologia concluiu-se que esta tem o potencial de produzir um número elevado de casos de testes, apesar de que o testador tem de indicar para cada um desses casos de teste uma lista de asserções que devem ser avaliadas antes de avaliar o caso de teste propriamente dito. Da metodologia de teste da sequência aleatória de asserções concluiu-se que o uso de uma função que pontua asserções a cada instante da sequência conduz sempre a melhores resultados, podendo revelar até 101% mais cobertura ao nível de asserções ou pares de asserções, do que se for apenas usada uma ordenação aleatória das asserções. Além disso, através da função de pontuação obtivemos para o estudo de caso 99.27% de cobertura de pares de asserções enquanto que para as mesmas condições, a versão sem a função de pontuação apenas obteve 56.16%.The programming of web services that provide APIs (Application Programming Interfaces) that adhere to the REST (Representational State Transfer) architectural style is nowadays extremely popular. For instance, applications like Gitlab and Youtube, provide programmatic access to their client applications through this type of APIs. The main reason for this is that traditional alternatives like SOAP (Simple Object Access Protocol) revealed an increased complexity when compared to REST. The effective development of client applications that use RESTful API require that their interfaces must be well documented. There are several languages that tackle this question but rarely solve it at a semantic level. Even those are unable to express complex business rules. This work presents a new language based on Hoare triples (an assertion) and refinement types to precisely express complex business rules through logical expressions as well as to express the relations between requests and responses. Using this language we implemented a testing tool that makes available two testing methodologies. The first builds a Classification Tree based on the precondition of an assertion and generates tests cases from that. The tester adds context information necessary to initialize the server state under which the precondition is satisfiable. The second tests an API using random sequences of tests that adaptively choose an assertion among several candidates in such a way that the coverage of individual assertions and pairs of assertions is higher than pure random sequence testing. The evaluation concluded that the first has the potential of generating a high number of test cases, however the work effort of the tester is also high. In terms of the second, in our study case, we found that adaptively choosing assertions may lead up to 101% more coverage than randomly choosing assertions. Also, the adaptive version achieved 99.27% of coverage of pairs of assertions against 56.16% of coverage obtained with the pure random version

Proceedings of the First Karlsruhe Service Summit Workshop - Advances in Service Research, Karlsruhe, Germany, February 2015 (KIT Scientific Reports ; 7692)

Since April 2008 KSRI fosters interdisciplinary research in order to support and advance the progress in the service domain. KSRI brings together academia and industry while serving as a European research hub with respect to service science. For KSS2015 Research Workshop, we invited submissions of theoretical and empirical research dealing with the relevant topics in the context of services including energy, mobility, health care, social collaboration, and web technologies

Behaviour on Linked Data - Specification, Monitoring, and Execution

People, organisations, and machines around the globe make use of web technologies to communicate. For instance, 4.16 bn people with access to the internet made 4.6 bn pages on the web accessible using the transfer protocol HTTP, organisations such as Amazon built ecosystems around the HTTP-based access to their businesses under the headline RESTful APIs, and the Linking Open Data movement has put billions of facts on the web available in the data model RDF via HTTP. Moreover, under the headline Web of Things, people use RDF and HTTP to access sensors and actuators on the Internet of Things. The necessary communication requires interoperable systems at a truly global scale, for which web technologies provide the necessary standards regarding the transfer and the representation of data: the HTTP protocol specifies how to transfer messages, besides defining the semantics of sending/receiving different types of messages, and the RDF family of languages specifies how to represent the data in the messages, besides providing means to elaborate the semantics of the data in the messages. The combination of HTTP and RDF -together with the shared assumption of HTTP and RDF to use URIs as identifiers- is called Linked Data. While the representation of static data in the context of Linked Data has been formally grounded in mathematical logic, a formal treatment of dynamics and behaviour on Linked Data is largely missing. We regard behaviour in this context as the way in which a system (e.g. a user agent or server) works, and this behaviour manifests itself in dynamic data. Using a formal treatment of behaviour on Linked Data, we could specify applications that use or provide Linked Data in a way that allows for formal analysis (e.g. expressivity, validation, verification). Using an experimental treatment of behaviour, or a treatment of the behaviour\u27s manifestation in dynamic data, we could better design the handling of Linked Data in applications. Hence, in this thesis, we investigate the notion of behaviour in the context of Linked Data. Specifically, we investigate the research question of how to capture the dynamics of Linked Data to inform the design of applications. The first contribution is a corpus that we built and analysed to monitor dynamic Linked Data on the web to study the update behaviour. We provide an extensive analysis to set up a long-term study of the dynamics of Linked Data on the web. We analyse data from the long-term study for dynamics on the level of accessing changing documents and on the level of changes within the documents. The second contribution is a model of computation for Linked Data that allows for expressing executable specifications of application behaviour. We provide a mapping from the conceptual foundations of the standards around Linked Data to Abstract State Machines, a Turing-complete model of computation rooted in mathematical logic. The third contribution is a workflow ontology and corresponding operational semantics to specify applications that execute and monitor behaviour in the context of Linked Data. Our approach allows for monitoring and executing behaviour specified in workflow models and respects the assumptions of the standards and practices around Linked Data. We evaluate our findings using the experimental corpus of dynamic Linked Data on the web and a synthetic benchmark from the Internet of Things, specifically the domain of building automation

A REST Model for High Throughput Scheduling in Computational Grids

Current grid computing architectures have been based on cluster management and batch queuing systems, extended to a distributed, federated domain. These have shown shortcomings in terms of scalability, stability, and modularity. To address these problems, this dissertation applies architectural styles from the Internet and Web to the domain of generic computational grids. Using the REST style, a flexible model for grid resource interaction is developed which removes the need for any centralised services or specific protocols, thereby allowing a range of implementations and layering of further functionality. The context for resource interaction is a generalisation and formalisation of the Condor ClassAd match-making mechanism. This set theoretic model is described in depth, including the advantages and features which it realises. This RESTful style is also motivated by operational experience with existing grid infrastructures, and the design, operation, and performance of a proto-RESTful grid middleware package named DIRAC. This package was designed to provide for the LHCb particle physics experiment's âﾜoff-lineâ computational infrastructure, and was first exercised during a 6 month data challenge which utilised over 670 years of CPU time and produced 98 TB of data through 300,000 tasks executed at computing centres around the world. The design of DIRAC and performance measures from the data challenge are reported. The main contribution of this work is the development of a REST model for grid resource interaction. In particular, it allows resource templating for scheduling queues which provide a novel distributed and scalable approach to resource scheduling on the grid