SAGA API Extension: Information Service Navigator API

The SAGA Service Discovery API provides a way to find grid services matching particular filter

SAGA API Extension: Service Discovery API

SAGA API Extension: Service Discovery AP

In Vitro and in vivo anti-tumoral effects of the flavonoid apigenin in malignant mesothelioma

Malignant mesothelioma (MM) is a tumor arising from mesothelium. MM patients' survival is poor. The polyphenol 4',5,7,-trihydroxyflavone Apigenin (API) is a "multifunctional drug". Several studies have demonstrated API anti-tumoral effects. However, little is known on the in vitro and in vivo anti-tumoral effects of API in MM. Thus, we analyzed the in vitro effects of API on cell proliferation, cell cycle regulation, pro-survival signaling pathways, apoptosis, and autophagy of human and mouse MM cells. We evaluated the in vivo anti-tumor activities of API in mice transplanted with MM #40a cells forming ascites. API inhibited in vitro MM cells survival, increased reactive oxygen species intracellular production and induced DNA damage. API activated apoptosis but not autophagy. API-induced apoptosis was sustained by the increase of Bax/Bcl-2 ratio, increase of p53 expression, activation of both caspase 9 and caspase 8, cleavage of PARP-1, and increase of the percentage of cells in subG1 phase. API treatment affected the phosphorylation of ERK1/2, JNK and p38 MAPKs in a cell-type specific manner, inhibited AKT phosphorylation, decreased c-Jun expression and phosphorylation, and inhibited NF-κB nuclear translocation. Intraperitoneal administration of API increased the median survival of C57BL/6 mice intraperitoneally transplanted with #40a cells and reduced the risk of tumor growth. Our findings may have important implications for the design of MM treatment using API

Privacy Issues of the W3C Geolocation API

The W3C's Geolocation API may rapidly standardize the transmission of location information on the Web, but, in dealing with such sensitive information, it also raises serious privacy concerns. We analyze the manner and extent to which the current W3C Geolocation API provides mechanisms to support privacy. We propose a privacy framework for the consideration of location information and use it to evaluate the W3C Geolocation API, both the specification and its use in the wild, and recommend some modifications to the API as a result of our analysis

Google's Cloud Vision API Is Not Robust To Noise

Google has recently introduced the Cloud Vision API for image analysis. According to the demonstration website, the API "quickly classifies images into thousands of categories, detects individual objects and faces within images, and finds and reads printed words contained within images." It can be also used to "detect different types of inappropriate content from adult to violent content." In this paper, we evaluate the robustness of Google Cloud Vision API to input perturbation. In particular, we show that by adding sufficient noise to the image, the API generates completely different outputs for the noisy image, while a human observer would perceive its original content. We show that the attack is consistently successful, by performing extensive experiments on different image types, including natural images, images containing faces and images with texts. For instance, using images from ImageNet dataset, we found that adding an average of 14.25% impulse noise is enough to deceive the API. Our findings indicate the vulnerability of the API in adversarial environments. For example, an adversary can bypass an image filtering system by adding noise to inappropriate images. We then show that when a noise filter is applied on input images, the API generates mostly the same outputs for restored images as for original images. This observation suggests that cloud vision API can readily benefit from noise filtering, without the need for updating image analysis algorithms

Classification of changes in API evolution

Applications typically communicate with each other, accessing and exposing data and features by using Application Programming Interfaces (APIs). Even though API consumers expect APIs to be steady and well established, APIs are prone to continuous changes, experiencing different evolutive phases through their lifecycle. These changes are of different types, caused by different needs and are affecting consumers in different ways. In this paper, we identify and classify the changes that often happen to APIs, and investigate how all these changes are reflected in the documentation, release notes, issue tracker and API usage logs. The analysis of each step of a change, from its implementation to the impact that it has on API consumers, will help us to have a bigger picture of API evolution. Thus, we review the current state of the art in API evolution and, as a result, we define a classification framework considering both the changes that may occur to APIs and the reasons behind them. In addition, we exemplify the framework using a software platform offering a Web API, called District Health Information System (DHIS2), used collaboratively by several departments of World Health Organization (WHO).Peer ReviewedPostprint (author's final draft

Fostering SLA-Driven API Specifications

Software architecture tendencies are shifting to a microservice paradigm. In this context, RESTful APIs are being established the standard of integration. API designer often identifies two key issues to be competitive in such growing market. On the one hand, the generation of accurate documentation of the behavior and capabilities of the API to promote its usage; on the other hand, the design of a pricing plan that fits into the potential API user’s needs. Besides the increasing number of API modeling alternatives is emerging, there is a lack of proposals on the definition of flexible pricing plans usually contained in the Service Level Agreements (SLAs). In this paper we propose two different modeling techniques for the description of SLA in a RESTful API context: iAgree and SLA4OAI.Ministerio de Economía y Competitividad TIN2015-70560-RJunta de Andalucía P12-TIC-1867Ministerio de Economía y Competitividad TIN2014-53986-RED

Contracting the Facebook API

In recent years, there has been an explosive growth in the popularity of online social networks such as Facebook. In a new twist, third party developers are now able to create their own web applications which plug into Facebook and work with Facebook's "social" data, enabling the entire Facebook user base of more than 400 million active users to use such applications. These client applications can contain subtle errors that can be hard to debug if they misuse the Facebook API. In this paper we present an experience report on applying Microsoft's new code contract system for the .NET framework to the Facebook API.We wrote contracts for several classes in the Facebook API wrapper which allows Microsoft .NET developers to implement Facebook applications. We evaluated the usefulness of these contracts during implementation of a new Facebook application. Our experience indicates that having code contracts provides a better and quicker software development experience.Comment: In Proceedings TAV-WEB 2010, arXiv:1009.330