<\/a>AsyncAPI metamodel<\/p><\/div>\n
Generating code to easily process messages from an AsyncAPI specification<\/h2>\n
Additionally, the prototype is able to generate Java code supporting the creation and serialization of JSON-based message payloads according to the modeled AsyncAPI, including nested JSON objects. No support for arrays is provided yet at this point, however. The excerpt below shows an example of an AsyncAPI specification supported by the prototype:<\/p>\n
{\r\n \"asyncapi\": \"1.2.0\",\r\n \"info\": {\r\n \"title\": \"Sample AsyncAPI specification\",\r\n \"version\": \"0.1.0\",\r\n },\r\n \"servers\": [\r\n {\r\n \"url\": \"broker.url:{port}\",\r\n \"scheme\": \"mqtt\",\r\n \"description\": \"This is an example description\",\r\n \"variables\": {\r\n \"port\": {\r\n \"default\": \"1883\",\r\n \"enum\": [ \"1883\", \"8883\" ]\r\n }\r\n }\r\n }\r\n ],\r\n \"topics\": {\r\n \"messages\/device2controller\": {\r\n \"publish\": { \"$ref\" : \"#\/components\/messages\/request\u201c }\r\n }\r\n }\r\n},\r\n\"components\": {\r\n \"schemas\": {\r\n \"protocol_version\": {\r\n \"title\": \"Protocol version\",\r\n \"type\": \"integer\",\r\n \"default\": 2,\r\n \"x-friendly-name\": \"ProtocolVersion\"\r\n },\r\n \"id\": {\r\n \"title\": \"ID\",\r\n \"type\": \"string\",\r\n \"format\": \"XXXXXX YY ZZZZZZ W\"\r\n },\r\n \"status\": {\r\n \"title\": \"Status\",\r\n \"type\": \"string\",\r\n \"enum\": [\"OK\", \"ERROR\"],\r\n \"x-friendly-name\" : \"Status\"\r\n },\r\n \"environment\": {\r\n \"title\": \"Environment\",\r\n \"type\": \"string\",\r\n \"enum\": [\"DEV\", \"STAG\",\"PROD\" ],\r\n \"x-friendly-name\" : \"Environment\"\r\n }\r\n },\r\n \"messages\" : {\r\n \"request\" : {\r\n \"summary\" : \"Request connectivity.\",\r\n \"description\": \"Request connectivity when status changes\",\r\n \"payload\": {\r\n \"type\": \"object\",\r\n \"properties\": {\r\n \"P\": { \"$ref\": \"#\/components\/schemas\/protocol_version\" },\r\n \"ID\": { \"$ref\": \"#\/components\/schemas\/id\" },\r\n \"E\": { \"$ref\": \"#\/components\/schemas\/environment\" },\r\n \"M\": {\r\n \"x-friendly-name\" : \"Message\",\r\n \"properties\": {\r\n \"S\": { \"$ref\": \"#\/components\/schemas\/status\" },\r\n \"C\": {\r\n \"title\": \"Content\",\r\n \"type\": \"string\",\r\n \"x-friendly-name\": \"Content\"\r\n }\r\n }\r\n }\r\n }\r\n }\r\n }\r\n }\r\n}\r\n\r\n<\/pre>\nA specification like the above, allows generating messages as follows:<\/p>\n
package tests;\r\nimport messages.device2controller.Request;\r\nimport messages.device2controller.Request.Payload.Environment;\r\nimport messages.device2controller.Request.Payload.Message;\r\nimport messages.device2controller.Request.Payload.PayloadBuilder;\r\nimport messages.device2controller.Request.Payload.Message.Status;\r\n\r\npublic class Test {\r\n\r\n public static void main(String[] args) {\r\n\r\n PayloadBuilder builder = Request.payloadBuilder();\r\n \r\n Request.Payload payload = builder\r\n .withProtocolVersion(2)\r\n .withEnvironment(Environment.DEV)\r\n .withID(\"id\")\r\n .withMessage(\r\n Message.newBuilder()\r\n .withStatus(Status.OK)\r\n .withContent(\"Content\")\r\n .build()\r\n ).build();\r\n \r\n System.out.println(payload.toJson(true));\r\n System.out.println(Request.Payload.fromJson(payload.toJson()).toJson(true));\r\n }\r\n}\r\n\r\n<\/pre>\nThe code generated by our toolkit also allows to easily publish the messages built as explained above, and to subscribe to them using the servers configured in the AsyncAPI specification. Check our online documentation for an example!<\/a><\/p>\nGenerating a new AsyncAPI from an Ecore model<\/h2>\n
Until now, we assumed that either you already had an AsyncAPI file to import or you would be using our AsyncAPI editor to create one. In fact, there is a third alternative: take an existing Ecore model you already have available and generate an skeleton AsyncAPI specification from it<\/strong>.<\/p>\nThe generator will create a reusable JSON Schema for each domain class. Channels will be created out of annotated EClasses. Moreover, hosts information can also be specified via EAnnotations.<\/p>\n
Besides its limitations, obtaining a JSON-based representation of an\u00a0Ecore model<\/i>\u00a0poses several advantages:<\/p>\n\n- allows developers and architects to create a working AsyncAPI<\/i>\u00a0definition without requiring deep knowledge of the specification while<\/li>\n
- keeps the modeling environment simple and manageable; and<\/li>\n
- allows staying compliant with the AsyncAPI Specification<\/i>\u00a0for those unfamiliar with modeling (iv) also enabling experienced developers and architects to refine and complete details of the architecture that cannot be captured using Ecore in an easy way<\/li>\n<\/ul>\n
In order to integrate data models in the proposed development workflow, we have defined both the\u00a0Ecore to AsyncAPI<\/i>\u00a0model-to-model (M2M) and the\u00a0AsyncAPI to JSON<\/i> M2T transformations.<\/p>\nEcore representation of the IoTBox example<\/p><\/div>\n
\n<\/span>","protected":false},"excerpt":{"rendered":"AsyncAPI allows you to define Message-Driven and event-driven APIs in a machine-readable format. Our AsyncAPI toolkit helps you to model and create AsyncAPI specifications and automatically generate code from them. <\/p>\n","protected":false},"author":9,"featured_media":7294,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"off","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[24,20,412,208,18],"tags":[734,266,825,824,148,547,416],"hashtags":[],"_links":{"self":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/posts\/7292"}],"collection":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/comments?post=7292"}],"version-history":[{"count":0,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/posts\/7292\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/media\/7294"}],"wp:attachment":[{"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/media?parent=7292"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/categories?post=7292"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/tags?post=7292"},{"taxonomy":"hashtags","embeddable":true,"href":"https:\/\/modeling-languages.com\/wp-json\/wp\/v2\/hashtags?post=7292"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}