Added a main method to webservice.App that launches the webserver and backing service in the same VM connected using loopback bus. Useful for initial local testing.

Added capability to specify REST method in service model and automatically generate http request parameters from the InMessage of the Operation.
Nested entities cannot be supplied as query params since embedded fields do not support the createFromRawJson. Users would have to use POST method in these cases.

Added support to generate HTML Test page for the service - to be able to quickly test the service Apis.

Non-functional refactor for code cleanup, efficiency and a step towards supporting zero garbage implementation. Upgrade to X 3.4.68 or higher required.

Refactored web app functionality to generate AbstractWebApp and allow users to extend and customize behavior of the web service.

Added exception handling in Web App to return proper http response.

Refactored the lifecycle of HTTP server, embedded by the service's web app's App.java, to follow the same lifecycle as the app itself.

Eagle comments in the ADM and ASM models to be aggregated into the generated WebApp and integrated with a REST API documentation tool so that my comments eventually self document the REST API. This story should do the following:
Added support for documentation of an ASM model just like one can document an ADM model.
Enhanced ASM code generator to document the REST endpoints using documentation in the ADM and ASM models
Integrated with Swagger to auto-document and provide the ability to test the REST API

Prior to this release, a user had to invoke open() on an Eagle service client before issuing service requests. This story enhances the client to automatically invoke open() when the first service request is issued.

Prior to this release, all service requests issued on an Eagle service client completed synchronously i.e. the thread invoking the request method blocks and waits for the response to come back before returning to the caller. This release implements the capability to do asynchronous request-reply. To perform asynchronous request-reply, the user would invoke the OperationRequestAsync method (newly generated in this release) which is the async request method corresponding to the synchronous OperationRequest method (generated prior to this release). The method would send the request and immediately return to the caller. To asynchronously receive the response for the request, the client should provide the object containing @EventHandler methods to handle the response messages to the Client constructor. This would result in the response messages being asynchronously dispatched to the registered handlers. The OperationRequest methods continue to be generated for synchronously request-reply invocation of service methods.