Enterprise applications are often built as service-oriented architectures, where the individual services are designed to perform specific functions and interact with each other by means of well-defined APIs (Application Programming Interfaces). The architecture of an enterprise application evolves over time, in order to adapt to changing business requirements. This evolution might require changes to the APIs offered by services, which can be achieved through appropriate API refactorings.
Previous studies on API refactoring focused on the effects on API definitions, with general considerations on related forces and smells. So far, instead, the development strategy for realising these refactorings has received little attention. This paper addresses exactly this aspect.
We introduce a conceptual framework for the implementation of API refactorings. Our framework elicits that there are important trade-offs and choices, which significantly affect the efficiency, maintainability, and isolation properties of the resulting architecture. We validate our framework by implementing several refactorings that introduce established API patterns with different choices, which illustrates the guiding principles offered by our framework. Our work also elicits, for the first time, how certain programming language features can reduce friction in applying API refactoring and open up more architectural choices.
Context: Refactoring is recognized as an effective practice to maintain evolving software systems. For software libraries, we study how library developers refactor their Application Programming Interfaces (APIs), especially when it impacts client users by breaking an API of the library. Objective: Our work aims to understand how clients that use a library API are affected by refactoring activities. We target popular libraries that potentially impact more library client users. Method: We distinguish between library APIs based on their client-usage (refereed to as client-used APIs) in order to u…
From Custom Logic to APIs: Understanding and Recommending API Replacement Refactorings
School of Computer Science and Technology, Beijing Institute of Technology（北京理工大学计算机科学与技术学院）；School of Computer Software, Tianjin University（天津大学计算机学院）
With the growth of the open-source data science community, both the number of data science libraries and the number of versions for the same library are increasing rapidly. To match the evolving APIs from those libraries, open-source organizations often have to exert manual effort to refactor the APIs used in the code base. Moreover, due to the abundance of similar open-source libraries, data scientists working on a certain application may have an abundance of libraries to choose, maintain and migrate between. The manual refactoring between APIs is a tedious and error-prone task. Although rece…
The ability to independently deploy parts of a software system is one of the cornerstones of modern software development, and allows for these parts to evolve independently and at different speeds. A major challenge of such independent deployment, however, is to ensure that despite their individual evolution, the interfaces between interacting parts remain compatible. This is especially important for enterprise software systems, which are often highly integrated and based on heterogenous IT infrastructures. Although several approaches for interface evolution have been proposed, many of these r…
Widespread adoption of agile project management, independent delivery with microservices, and automated deployment with DevOps has tremendously speedup the systems development. The real game-changer is continuous integration (CI), continuous delivery, and continuous deployment (CD). Organizations can do multiple releases a day, shortening the test, release, and deployment cycles from weeks to minutes. Maturity of container technologies like Docker and container orchestration platforms like Kubernetes has promoted microservices architecture, especially in the cloud-native developments. Various …
In this article, we examine how security applies to Service Oriented Architecture (SOA). Before we discuss security for SOA, lets take a step back and examine what SOA is. SOA is an architectural approach which involves applications being exposed as "services". Originally, services in SOA were associated with a stack of technologies which included SOAP, WSDL, and UDDI. This article addresses the defects of traditional enterprise application integration by combining service oriented-architecture and web service technology. Application integration is then simplified to development and integratio…
Microservices are becoming the defacto design choice for software architecture. It involves partitioning the software components into finer modules such that the development can happen independently. It also provides natural benefits when deployed on the cloud since resources can be allocated dynamically to necessary components based on demand. Therefore, enterprises as part of their journey to cloud, are increasingly looking to refactor their monolith application into one or more candidate microservices; wherein each service contains a group of software entities (e.g., classes) that are respo…
Nowadays, web services play a major role in the development of enterprise applications. Many such applications are now developed using a service-oriented architecture (SOA), where microservices is one of its most popular kind. A RESTful web service will provide data via an API over the network using HTTP, possibly interacting with databases and other web services. Testing a RESTful API poses challenges, as inputs/outputs are sequences of HTTP requests/responses to a remote server. Many approaches in the literature do black-box testing, as the tested API is a remote service whose code is not av…
