Measuring the understandability of WSDL specifications, web service understanding degree approach and system

Web Services (WS) are fundamental software artifacts for building service oriented applications and they are usually reused by others. Therefore they must be analyzed and comprehended for maintenance tasks: identification of critical parts, bug fixing, adaptation and improvement. In this article, WSDLUD a method aimed at measuring a priori the understanding degree (UD) of WSDL (Web Service Description Language) descriptions is presented. In order to compute UD several criteria useful to measure the understanding’s complexity of WSDL descriptions must be defined. These criteria are used by LSP (Logic Scoring of Preference), a multicriteria evaluation method, for producing a Global Preference value that indicates the satisfaction level of the WSDL description regarding the evaluation focus, in this case, the understanding degree. All the criteria information required by LSP is extracted from WSDL descriptions by using static analysis techniques and processed by specific algorithms which allow gathering semantic information. This process allows to obtain a priori information about the comprehension difficulty which proves our research hypotheses that states that it is possible to compute the understanding degree of a WSDL description.info:eu-repo/semantics/publishedVersio

WHAT’S IN A SERVICE? SPECIFYING THE BUSINESS SEMANTICS OF SOFTWARE SERVICES

The success of the service-oriented computing (SOC) paradigm considerably depends on the ability of service consumers to distinguish between published services and choose the ones best suited for a development project. Current SOC standards primarily give information about technical service properties such as the programming interface and the binding information. This enables designers to analyze the technical compatibility of services with the rest of the system. On the basis of such technical information, it is difficult to assess which business semantics a service actually implements and whether it is suited to satisfy functional requirements, however. In this paper, we therefore propose the WS-Functionality language which allows providers to specify the business semantics of software services in business terms. In a design science approach, we firstly describe how conceptual models, which contain business terms and relationships between them, can be used to specify the business semantics of services. Building upon this solution concept, we present the language constructs of WS-Functionality and show a prototypic implementation as proof-of-concept. In a controlled experiment, we were able to support our claim that the information provided with WS-Functionality enhances the ability of service consumers to analyze the business semantics of services and judge whether it satisfies existing functional requirements

A Business Model for Managing SOA Initiatives

Para obter os benefícios corporativos com a implantação de uma abordagem SOA, não é suficiente tratar características técnicas. Uma estratégia alinhada ao negócio deve ser considerada como base para as atividades de implementação, validação, desenvolvimento e gestão de serviços. Um caso de negócio, um modelo de referência e uma arquitetura da organização devem ser estabelecidos. Este trabalho propõe objetivos, papéis e processos para governança SOA do ponto de vista da Arquitetura de Tecnologia de Informação. Os processos foram avaliados por especialistas na área de SOA que argumentam que adotariam os mesmos para a governança SOA em suas organizações

BoSDL: An Approach to Describe the Business Logic of Software Services in Domain-Specific Terms

Modular SaaS platforms that can flexibly be configured with software services, microservices, and the advent of the API economy provide new opportunities to realize even highly customized solutions in the cloud. The success of such endeavors depends on the ability of consumers to discriminate between offered services and choose those best fulfilling the requirements, though. To facilitate the assessment of services against functional requirements, this article proposes the Business-Oriented Service Description Language (BoSDL). It consists of: (1) a meta-model with rules to describe the business logic, that is, the functionality of a software service from a business-oriented perspective; (2) a textual presentation format based on English natural language; (3) a graphical notation based on the UML. Findings from a controlled experiment indicate that, compared to the state of the art, the information provided with the BoSDL enhances the ability of consumers to judge if software services satisfy existing functional requirements

Evaluation of a methodology for migration of the database layer to the cloud based on an eScience case study

In the last years Cloud computing has become popular among IT organizations. Applications and data can be designed to be run on the Cloud, and can also be partially or completely migrated to the Cloud. The application can be separated into 3 layers: the presentation layer, the business logic layer and the data layer. The data layer can further be separated into 2 sub-layers: the data access layer and the database layer. Migration tasks are applied on these layers. In order to benefit from the Cloud technology, migrating the data layer or the business logic layer or both of them into the Cloud is required. For the migration there are different migrating scenarios and patterns. The migrating methodologies are different cross different providers. During the migration procedure different problems may occur. The types, causes, and solutions of these problems may also be different. Identifying the properties of these problems and comparing the migrating methodologies are important to the Cloud users. In this thesis we migrate both the data layer and business logic layer of a Scientific Workflow System to the Cloud. The migration scenario "Cloud Bursting" is considered. Several quantitative and qualitative metrics chosen from an ISO/ICE standard are introduced and are used to define the properties of the migrating methodologies. Two migrating methodologies are applied, one is the methodology of Bachmann, the other one is the methodology of Amazon. The required refactoring of the application architecture is investigated and the needed modifications are recorded and explained. Data of the metrics of the two migrating methodologies are collected, compared, and discussed

An analysis of frequent ways of making undiscoverable Web Service descriptions

The ever increasing number of publicly available Web Services makes standardcompliant service registries one of the essential tools to service-oriented application developers. Previous works have shown that the descriptiveness of published service descriptions is important from the point of view of the algorithms that support service discovery using this kind of registries as well as human developers, who have the final word on which discovered service is more appropriate. This paper presents a catalog of frequent bad practices in the creation of Web Service descriptions that attempt against their chances of being discovered, along with novel practical solutions to them.Additionally, the paper presents empirical evaluations that corroborated the benefits of the proposed solutions. These anti-patterns will help service publishers avoid common discoverability problems and improve existing service descriptions.Sociedad Argentina de Informática e Investigación Operativ

A filtering engine for large conceptual schemas

Postprint (published version

Security and Usability in the HeadREST Language

Tese de mestrado, Engenharia Informática (Arquitectura, Sistemas e Redes de Computadores) Universidade de Lisboa, Faculdade de Ciências, 2020Actualmente, observa-se o crescimento contínuo de serviços web, sem sinais de abrandar. As trocas de informação com estes serviços seguem diferentes padrões. De entre os muitos padrões utilizados, destaca-se o REST (REpresentational State Transfer). O REST é um estilo arquitectural muito utilizado actualmente. Neste estilo arquitectural as operações e propriedades do protocolo HTTP, sobre o qual o World Wide Web funciona, são aproveitadas para realizar as interacções de clientes com serviços web. Em REST, o elemento basilar são os recursos, que correspondem a pedaços de informação que podem ser referenciados por um identificador. Cada recurso tem uma, ou várias, representações, que podem ter diferentes formatos, e que podem mudar na sequência de operações executadas sobre o mesmo. Um serviço web que adere ao estilo arquitectural REST é chamado de serviço REST. Para programar clientes de um serviço REST é fundamental que esteja disponível uma boa documentação da sua API, com especificações claras das suas operações e dos dados trocados nestas operações entre os clientes e o serviço. No desenvolvimento deste tipo de serviços são utilizadas linguagens de descrição de interfaces, tal como a OpenAPI Specification, o RAML ou a API Blueprint. Estas linguagens permitem especificar formalmente as operações suportadas por um serviço REST e oferecem a capacidade de documentar os dados que são trocados durante as interacções com o serviço. Apesar da sua popularidade, estas linguagens de especificação têm um poder expressivo limitado. Uma das limitações é que não terem capacidade para descrever com precisão o comportamento das diferentes operações. Numa tentativa de endereçar estas limitações, tem vindo a ser desenvolvida a linguagem HeadREST. A linguagem tem um sistema de tipos refinados que permite restringir os valores admissíveis de um tipo, e portanto descrever com mais rigor os tipos dos dados trocados num serviço REST. Para permitir especificar com precisão as operações de um serviço REST, a linguagem HeadREST dispõe de asserções. Estas asserções, semelhantes aos triplos de Hoare, são compostas por uma pré-condição, um URI template da operação e uma pós-condição. As asserções especificam que, quando a pré-condição é satisfeita, a execução da operação estabelece a pós-condição. Devido ao sistema de tipos refinados não é possível resolver através de regras sintácticas as relações de subtipagem. Para endereçar esta situação foi tomada a decisão de utilizar um procedimento semântico para tratar destas situações. A relação de subtipagem é transformada em fórmulas lógicas de primeira ordem, que são depois dadas a um SMT solver para as resolver. Apesar do seu grande poder expressivo, o HeadREST, como linguagem de especificação, está longe de ser perfeita. Um dos problemas mais importantes está relacionado com a sua usabilidade. Apesar da linguagem permitir descrever operações com grande rigor e detalhe, isso é feito à custa de asserções bastante complexas que são não só difíceis de escrever correctamente, como de compreender. Muitas das linguagens de especificação de serviços REST oferecem, mesmo que de forma limitada, uma forma de expressar o que o serviço exige em termos de autenticação e/ou autorização. Existem vários tipos de autenticação e autorização que podem ser usados para restringir acesso a recursos em serviços REST, por exemplo, API keys, Tokens, http authentication&HTTP digest, OAuth 2.0, OpenID Connect. Para além disto, cada serviço REST pode tomar abordagens diferentes em relação a políticas de autorização. Este trabalho endereçou estes dois problemas e pretendeu contribuir com soluções que os ajudassem a resolver. Para o problema de usabilidade, a solução concebida passou pela criação de extensões para a linguagem com ênfase em expressões derivadas. A linguagem foi estendida com: (i) iteradores quantificados que permitem expressar melhor propriedades sobre arrays, (ii) interpolação para permitir criar Strings a partir de URIs de uma forma mais simples e directa, (iii) um operador de extracção que permite aceder à representação de um recurso se esta for única e finalmente, (iv) funções que permitem abstrair expressões repetidas de uma forma mais flexível (apenas as funções não são derivadas). A abordagem para endereçar a especificação de políticas de segurança em APIs REST assentou na adição (i) de um novo tipo Principal, correspondente às entidades autenticadas e (ii) de uma função não-interpretada principalof capturando o Principal autenticado por um valor usado na autenticação. A linguagem foi estendida com a definição de funções não-interpretadas, para permitir que sejam feitas associações entre o tipo Principal e outros dados que possam vir de diferentes fontes (representações, templates de URIs, corpo dos pedidos, etc.), dando assim a possibilidade de especificar os diferentes tipos de políticas de segurança usadas em serviços REST. A avaliação das soluções propostas foi realizada de diferentes formas. Foi realizado um estudo com utilizadores envolvendo a resposta a um questionário com perguntas sobre a linguagem HeadREST antes e depois das extensões e foi feito um estudo quantitativo a comparar o impacto das extensões em termos de métricas de complexidade das especificações e no desempenho do validador. Para avaliar as extensões referentes à segurança foram realizados alguns casos de estudo, envolvendo a especificação parcial de alguns serviços REST do "mundo-real". Foi ainda explorado o impacto que as extensões introduzidas na linguagem têm nas ferramentas que actualmente fazem parte do ecossistema HeadREST: (i) a ferramenta HeadREST-RTester, que permite testar automaticamente a conformidade da implementação de um serviço REST contra uma especificação HeadREST da sua API, (ii) a ferramenta HeadREST-Codegen, que faz a geração de código, e (iii) a linguagem SafeRestScript, uma linguagem de script em que é realizada estaticamente a validação das chamadas a serviços REST cujas APIs tenham sido especificadas com HeadREST. A linguagem HeadREST possui um validador, um plug-in para o IDE Eclipse e uma versão headless para ser utilizada no terminal.The RESTful services are still today the most popular type of web services. Communication between these services and their clients happens through their RESTful APIs and, to correctly use the services, good documentation of their APIs is paramount. With the purpose of facilitating the specification of web APIs, different Interface Definition Languages (IDLs) have been developed. However, they tend to be quite limited and impose severe restrictions in what can be described. As a consequence, many important properties can only be written in natural language. HeadREST is a specification language of RESTful APIs that poses itself as a solution to the limitations faced by other IDLs. The language has an expressive type system via refinement types and supports the description of service endpoints through assertions that, among other things, allow to express relations between the information transmitted in a request and the response. HeadREST, like other IDLs, is however not without its limitations and issues. This thesis addresses the problems that currently affect the usability of HeadREST and also its lack of expressiveness for specifying security properties of RESTful APIs. The proposed solution encompasses (i) an extension of HeadREST with new specification primitives that can improve the degree of usability of the language and (ii) an ortogonal extension of HeadREST with specification primitives that support the description of authentication and authorisation policies for RESTful APIs. The evaluation of the proposed solution, performed through a user study, a quantitative analysis and the development of case studies, indicates that the primitives targeting the usability issues indeed improve usability of the language and that HeadREST become able to capture dynamic, state-based dependencies that exist in the access control policies that can be found in RESTful APIs

Comparing Enterprise Architecture Frameworks – A Case Study at the Estonian Rescue Board

Igal organisatsioonil on strateegilised eesmärgid, mida ta soovib saavutada. Ilma tervikliku arhitektuurita, mis kombineerib kõik erinevad elemendid - äriprotsessid, infosüsteemid, andmevood ja platvormid -, ei saa olla kindel, kas või kuidas viivad investeeringud eemärkide täitmisele. Kuna ühegi Eesti riigiasutuse kohta ei ole teadaolevalt selleteemalist uurimust tehtud, valiti selles magistritöös juhtumiuuringu näiteks Päästeamet. Magistritöös antakse esmalt süstemaatiline ülevaade erialasest kirjandusest eesmärgiga leida sobivad organisatsiooni arhitektuuri raamistikud ning kriteeriumid raamistike võrdleva analüüsi läbiviimiseks ja edasiseks hindamiseks Päästeameti näitel. Valitud allikate põhjal vastatakse uurimisküsimustele. See aitas tuvastada seitse ettevõtte arhitektuuri raamistikku, mida hinnati ja jättis alles kolm raamistikku edasiseks rakendamiseks: The Open Group Architecture Framework (TOGAF), The Federal Enterprise Architecture Framework (FEAF), Service-Oriented Architecture (SOA). Seejärel modelleeritakse juhtumiuuringus erinevaid raamistikke kasutades detailselt 2-3 teenust ning viiakse kirjanduse ülevaates kirjeldatud kriteeriumite abil läbi hindamine ja arutelu Päästeameti töötajatega. Juhtumiuuring ja kohapealne kohtumine päästeametis seadsid ettevõtte organisatsioonide arendamiseks organisatsiooni arhitektuuri raamistikud jaoks kõige olulisemad kaks peamist asjaolu: organiseerida arhitektuur seisukohtadesse, mis on organisatsiooni infoküsimuste struktuuri alamhulk ja mõista, kuidas organisatsiooni eesmärgid on toetatud. Töö tulemus on heaks aluseks organisatsiooni arhitektuuri edasisele arendamisele Päästeametis ja teistes Eesti riigiasutustes.Every organisation has strategic goals it wants to achieve, and if it does not have an architecture combining all different elements such as business processes, enabling information systems, data flows and platforms, it will not be sure which investments will lead to achieving which objectives. Since there has not been any research like this performed for Estonian Government Organisations, the Estonian Rescue Board is taken as an example for conducting a case study. A systematic literature review is performed, for identifying Enterprise Architecture Frameworks, criteria for performing a comparative analysis of the framework as well as for the further evaluation at the Estonian Rescue Board. The identified final papers are analysed in order to answer the Research Questions (RQ). This helped to identify seven Enterprise Architecture Frameworks, which were evaluated and left only three frameworks for further implementation: The Open Group Architecture Framework (TOGAF), The Federal Enterprise Architecture Framework (FEAF), Service-Oriented Architecture (SOA). In the case study, the selected frameworks are modelled, showing 2 or 3 services in details, with further evaluation and discussion of them during the meeting at the Rescue Board, following the criteria, which are described in the literature review. Case study and on-site meeting at the Rescue Board set two main things to be the most vital while developing Enterprise Architecture Framework in the organisation: organising architecture into views that are subsets of the organisation information architecture and understanding how the goals in the organisation are supported. This can be a good backbone for further developing Enterprise Architecture in the Rescue Board, and other Estonian Government Organisations in general