Hi everyone,
I have a popular request from our users to show a list of APIs that an application provides (or in broader sense a list of integration endpoints, e.g. APIs, FTP, WS endpoints, etc.) so I wonder if anyone has already modeled this in EAS and what were the entities used for that?
Thanks
Tomas
How to model integration architecture?
Hi Tomas,
up until now, we have always recommended that APIs were modelled using the Application Provider class. This was on the basis that they effectively represent logical collections of application functionality that happen to be accessible via a programmatic interface, as opposed to a user interface.
However, based on feedback that we have received from the community, we have decided to more explicitly call out Application (Provider) Interfaces as a more specific type of Application Provider. This was partially due to the need for some additional properties (e.g. supported protocols), but also to make it easier to create views that need to clearly distinguish between typical user facing Applications and APIs. An added bonus is that anyone who has previously modelled APIs as Application Providers but would like to take advantage of the new class, within Protege, can do so by just dragging instances onto the new class (given that the new class is a sub-class of Application Provider)
This extension will form part of the next release of the Essential Meta-Model, but in the mean time, we have produced an Essential Update Pack (EUP) that can be downloaded using this link in the Essential Labs area of the Essential Project web-site (note that you may need to sign up for access to Essential Labs).
The following diagrams below describe the nature of the changes implemented by the meta-model extensions as well as examples of how integration architecture can be modelled using them.
Thanks,
Jason
up until now, we have always recommended that APIs were modelled using the Application Provider class. This was on the basis that they effectively represent logical collections of application functionality that happen to be accessible via a programmatic interface, as opposed to a user interface.
However, based on feedback that we have received from the community, we have decided to more explicitly call out Application (Provider) Interfaces as a more specific type of Application Provider. This was partially due to the need for some additional properties (e.g. supported protocols), but also to make it easier to create views that need to clearly distinguish between typical user facing Applications and APIs. An added bonus is that anyone who has previously modelled APIs as Application Providers but would like to take advantage of the new class, within Protege, can do so by just dragging instances onto the new class (given that the new class is a sub-class of Application Provider)
This extension will form part of the next release of the Essential Meta-Model, but in the mean time, we have produced an Essential Update Pack (EUP) that can be downloaded using this link in the Essential Labs area of the Essential Project web-site (note that you may need to sign up for access to Essential Labs).
The following diagrams below describe the nature of the changes implemented by the meta-model extensions as well as examples of how integration architecture can be modelled using them.
Thanks,
Jason
You do not have the required permissions to view the files attached to this post.
-
tomas_rollo
- Posts: 5
- Joined: 26 Jul 2018, 07:49
Hi Jason,
looks like I asked at the right time
Thank you for sharing the new API model, that looks nice, I will have a look at it.
Thanks
T.
looks like I asked at the right time
Thank you for sharing the new API model, that looks nice, I will have a look at it.Thanks
T.
Hi,
I'm testing moving our APIs defined as Application_Providers to the new Application_Provider_Interface, and I've noticed the standard views (eg core_al_app_provider_info_deps_model.xsl) don't use the new class (I can't find any reference to the new class in any view). As it happens we have a custom view I have amended to show them - just wanted to check the intention is to show them in a product view in the future?
Thanks
TMC
I'm testing moving our APIs defined as Application_Providers to the new Application_Provider_Interface, and I've noticed the standard views (eg core_al_app_provider_info_deps_model.xsl) don't use the new class (I can't find any reference to the new class in any view). As it happens we have a custom view I have amended to show them - just wanted to check the intention is to show them in a product view in the future?
Thanks
TMC
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi,
Yes, it is our intention to include instances of the new Application Provider Interface class in views such as the Application Dependency Model. Note that the new class is designed to model things like APIs etc. as a specific type of application, and the Views will be updated to include these in addition to the existing approach.
Jonathan
Yes, it is our intention to include instances of the new Application Provider Interface class in views such as the Application Dependency Model. Note that the new class is designed to model things like APIs etc. as a specific type of application, and the Views will be updated to include these in addition to the existing approach.
Jonathan
Essential Project Team
