DEx in the Cloud

DEx is the Open Travel Development Experience Extended tool created by the community to support model driven development in Travel. For a little more background on both we suggest you read Why_ODM and watch the videos on DEx.
DEx is used by several members behind their firewall to leverage the 2.0 common model to create both .xsd and swagger artifacts for their ongoing migration from SOAP to REST. Others just download the schema OpenTravel publishes with releases but they are missing all the advantages of model driven development when it comes to developing microservices. Still others take a look at the 2.0 library and can’t make any sense of it.
The feedback we get regarding the 2.0 library and DEx tool is a follows:

• For most, what they were expecting to see when given access to the library was something akin to an API collection. At least the messages, if not actual API definitions. What they got was a hierarchical model and could not sort out how to view that as an API. There are sample messages, but those are limited and don’t show everything in the model.
• DEx is an opensource java tool which immediately presents a problem by violating company security rules. DEx is coded to use a JavaFX interface to run on a windows or Linux desktop, not as a web app.  It’s also a bit cranky to get running.  There is intent to overhaul DEx to be not only browser based, but more of a plugin to tools like visual studio. But for now, it’s not exactly user friendly.  

The OpenTravel Architecture Committee has proposed the following to address some of these issues in the short term.

The summary is to support the ability of any user with access to the library to set up a Linux instance in the cloud to run DEx. DEx, along with other tools (TBD) would be preloaded and captured as a machine image. On AWS for example, you would fire up an EC2 instance and be able to access a DEx AMI where everything is already set up. You could do several things like look at existing sample messages, modify locally existing service (resource) definitions, and create OAS 3.0 output. You could also make local changes to the business objects, define new services, etc. All extensions of the model could be saved locally and could be captured in your own AMI for later use.  The other tools we may add are mock services to make it easy to try the examples created in the same instance.

This addresses the issue of anyone wanting to see sample messages instead of a model to quickly get what they want. If the existing sample messages don’t meet your needs, you can define new messages. DEx is running outside of any firewall so there are no security issues. This doesn’t fix everything but makes it easier to play with DEx and the 2.0 model to better understand what they can do.

We’d like some feedback on this approach. What issues do you have had with OTA 2.0 and/or DEx and does this address them? Will this function make it more likely that you would use 2.0 in your efforts to create JSON/REST based APIs? Based on a better understanding of 2.0, would you be interested in joining a workgroup to expand the common model? Please use the contact form for feedback, https://opentravel.org/contact-us/ . If anyone wants to talk about this proposal, let us know!

A beta version of this is now available for anyone to try out. See DEx AWS AMI Instructions.