Kirra: a technology-independent conceptual API metamodel for business applications

1

Kirra is an API metamodel for business applications. Kirra’s goal is to provide a common metamodel that can be used to expose APIs for any kind of data-centric business applications.

Some facts about Kirra:

  • it is a conceptual model for APIs, not implementations
  • it provides access to application data and operations
  • it is metadata-rich, so a generic client can discover and expose an application’s entire functionality with no previous knowledge of it
  • it is meant for business applications, so it covers typical enterprise concerns such as user roles and capabilities
  • it is technology agnostic, so it can be implemented on any programming language, API technology etc (docs to the reference implementation)
  • it is used in Cloudfier to expose model-driven applications via a Kirra-compliant REST API
  • it is used in kirra-ui, which is a generic web-based UI that renders generic but useful user-interfaces to provide access to Kirra-enabled business applications
  • it is used in kirra-java, to expose the functionality of Spring Boot-based applications.

I know of at least one other initiative with somewhat similar goals: NakedObjects, which has both Java and .Net implementations, and a REST binding.

I am looking for people interested in adopting the Kirra-style for describing applications, building tools that take advantage of it, or validate the approach and provide feedback.

Cheers!

2

Maybe you want to see what others are doing.
The Ballerina language seems to fit the bill very well for data-centric & network oriented business applications.

1 Like
3

Thanks, @cristian.vasile. The key point about Kirra is that it is not an implementation language - you still need to implement the behavior of the API using whatever approach you do today (for instance, a REST API in Ballerina). Kirra is more like an API style, which can be applied to any API technology - basically, it requires your API to provide metadata endpoints in a specific format, and data access endpoints that conform to that metadata. But how the endpoints actually do their stuff is out of scope for Kirra.

4

What would be the relationship between Kirra and OpenAPI? (for which we have a metamodel available https://modeling-languages.com/wapiml-web-api-uml/ )

5

Hi Jordi, long time no see!

There is a significant correspondence between Kirra and OpenAPI (and Kirra and RapidML), as they focus on interfaces/APIs. The primary difference is that Kirra is purely a conceptual framework, ignoring the transport protocol, and as such it is not tied to a technology, like OpenAPI and RapidML are to REST (with a strong bias towards JSON in the case of OpenAPI). You definitely could map a Kirra model to an OpenAPI and RapidML. But also to GraphQL, gRPC, ApacheThrift, Protocol Buffers, CORBA (oops, went bit too far there), or really any object/service oriented protocol, including regular objects in 3GL languages. The opposite may not be possible, because OpenAPI lacks some of the concepts supported in Kirra (could work with some custom metadata/tags). Mapping from RapidML may be easier, as it seems a little stronger on conceptual modeling than OpenAPI.

The idea of a DSL for Kirra (like you guys did for OpenAPI - btw, pretty cool!) is something I have considered for quite a bit, and it would probably increase its direct usefulness, and open interesting possibilities for interoperability. But as long as there is a metamodel clearly defined somewhere (as there is one for Kirra in Java), we already have an implicit language, only need to define mappings for a concrete syntax.

6

Sure. I get they are at different abstraction levels but I would say you’d need to provide at least a couple fo these mappings yourself. All the OpenAPI, GraphQL,… you mention have a strong userbase and (reasonably) good tools. To convince a user of the benefits of using Kirra instead, I think you should at least tell him/her that whatever he defines in Kirra will be “exported” (using whatever defaul generation options you decide) to one of the “lower-level” API standads.

I know you and me (and many here) appreciate the power of working at different abstraction levels but many users will trade this conceptual benefits for a more pragmatic approach (unfortunately, I should say)

1 Like
7

Yeah, users will need bindings of the conceptual model to concrete technologies, which hopefully tool developers would build. Those concrete technologies could be other specification-oriented languages as you suggest (such as OpenAPI and RapidML), or they could be implementation technologies themselves. I built a few bindings myself, which are in use in Cloudfier:

  1. a Java-based metamodel (link in the original post for a reference implementation)
  2. a REST-based binding in the form of a Java/JAX-RS implementation (see list of all entities in a Cloudfier app here, also part of the reference implementation.
  3. a generic client that exposes Kirra/REST applications (mentioned kirra-ui in the original post)

Ideally, other people would see usefulness in adopting the same conceptual model in their own tools (for instance, so they can get a functional UI for their backend). Alternatively, I can try to help spread it by implementing Kirra support in other peoples tools/frameworks, but that doesn’t scale (I am working on a Spring Boot-based binding now).

Thanks for comments, Jordi!

1 Like