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 defined the following to address some of these issues.

Your personal DEx

Any user with access to the library to set up their own Linux instance in the cloud to run DEx. DEx, along with other tools (Git, VS, Slack, etc.) is preloaded and captured as a machine image. On AWS for example, you can 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.

There is also an option to run an AWS workspace. This is very similar to the EC2/AMI method above but you don’t need to mess with the set up and running of an EC2 instance, just use this virtual desktop. This is available in a few flavors. AWS supports workspaces using the concept of an Image and a Bundle. The Image is all the apps and files, including DEx, captured as an image. A Bundle defines the operating environment such as CPU, memory and disk size. While anyone can use the Image given permission, a Bundle can only be created by an AWS account ID. It is owned by the ID as it implies a cost. Hence options are:

1. Request access to the Image and create your own bundle attached to your ID. Note there are options from AWS to build a bundle that would be free for a limited time. After any such free period, the runtime costs will be reflected on your AWS invoice.
2. Request to use a Workspace and bundle provided by OpenTravel. The bundle would belong to the OpenTravel account ID. The form to ask for a workspace will include the request for you to use Donorbox to contribute to cover the workspace costs.  OpenTravel is a nonprofit and has no other means to pay for AWS runtime costs.
3. If, for example, you are forming a workgroup and want to team to have a common setup for DEx, you may want to create a shared bundle just for the team. This again could be on a private AWS ID or OpenTravel, we’ll help you sort that out.

This addresses the issue of anyone wanting to see sample messages instead of a model to 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.

The choice on how you approach this, your own EC2 or a variation on Workspaces, would be largely up to your situation. If you are working for a company that already has an AWS account (and you have access to the ID), a workspace where you ask for the shared Image and create your own bundle is probably best. If you do not have access to an AWS account ID and rather not set up your own account, using the OpenTravel bundle (AWS account) is probably best. Just help us out covering the cost while you need to use it. If you are setting up access for a larger team and can manage most everything yourself, then the EC2 may be a good fit. As for a use case such as a workgroup adding to the OTM 2.0 model, using the OpenTravel bundle (AWS account) may be more stable. This way everyone has the same configuration, fewer variables to cause issues.

Please use the contact form for questions or other feedback, https://opentravel.org/contact-us/ . If anyone wants to talk about DEx in the cloud, let us know!

Access the request form at DEx AWS AMI Instructions.