This post summarizes our work “API2MoL: Automating the building of bridges between APIs and Model-Driven Engineering” co-authored by myself, Frédéric Jouault, Jordi Cabot and Jesús García Molina.
APIs are a very important part of any software application/service. Therefore, integration with existing APIs is a key aspect in the development (or reverse engineering) of any software artefact. As such, model-based development needs to provide adequate mechanisms to represent APIs (and their use) as models and to provide bridges between the model of an API and the API code so that models can be transformed into running code interacting with the API and the other way around.
Ideally, and given the extension and complexity of APIs, these tasks should be as automatic as possible. Here, it is where API2MoL comes to play. API2MoL is a tool to integrate APIs with the model realm, thus facilitating the use of APIs in model-based applications. API2MoL allows creating bridges between both technical spaces (what we call apiware and modelware). Such bridges support the following tasks: i) obtaining model elements from the API elements (injection process) and ii) generating API elements from model elements (extraction process). To illustrate how a bridge is defined, the following figure shows the apiware and modelware technical spaces arranged according to the well-known metamodel levels.
As can be seen, a bridge is defined at level M2, where mappings between (Java, so far) classes and metamodel elements are specified, whereas the execution of a bridge is performed at level M1, where Java objects are injected into / extracted from model elements. The tool incorporates a DSL to define bridges between APIs and metamodels helping developers to specify how to obtain the model elements from the API and how to generate the API elements from the model.
Since APIs are normally big and some huge, the definition of both the metamodel and mapping definitions can be a hard task. To deal with this situation, API2MoL also provides a bootstrapping process that, given an API, automatically generates its metamodel and a first set of mapping definitions between the new metamodel and the API classes. If necessary, the designer can then complement the results using the above-mentioned DSL.
We believe API2MoL is very useful in several application scenarios. Just to mention some of them, API2MoL facilitates API evolution and comparison, complements existing methods for code-generation and reverse-engineering (where until now, interaction with external APIs was ignored and had to be manually added), on-the-fly reengineering (by manipulating API objects at run-time, e.g., to automatically change the GUIs based on user preferences), models at run-time (models could be automatically synchronized with the code and evolve at the same time the code does), data exchange/aggregation (API2MoL could be used to facilitate the interoperability between two or more APIs in order to enable data exchange between them), etc. Generally speaking, API2MoL provides the necessary tools to easily integrate our model-based application/process with Java-based APIs, where such integration can be unidirectional (inject or extract) or bidirectional (inject and extract).