Integrate SOAPUI as dev test tool, link it to the SOA model

[mdutoo]

Why

• showcases how EasySOA adds value to third-party tools / solutions, by bringing much-needed manageability to SOAPUI confs, by linking them to the EasySOA known SOA model & services.
• more comprehensive & developer-oriented test tool (than scaffolder),
• well-known so will help buzz but also introducing (java) developers to EasySOA and making them comfortable here
• a prototype of functional integration with SOAPUI had been planned to see how far to go in such directions
• allows to address : using service use portal, where to store edited confs (like scaffolder), external tool integration (like Talend, fstudio)

  Tasks

• for an env, allow user to generate soapui conf templated by webengine, by default containing definitions (WSDLs) of all services with default request samples, and if possible default service mocks (TODO)
• study how to make it as easy as possible to use soapui on it : start an existing soapui when downloading it, or even embed it (TODO ask talend how they did it). (OK only save conf. then open it from SoapUI)
• when storing / referencing them in the model, parse it. Apply the discovery mapper algorithm to each service url in order to find to which service in the model it refers to and link it to it (similar to SCA import, will probably look like a big application providing and consuming a lot of services)
• make it possible to fork / "transition" soapui confs between envs ! (OK but process is long and unconvenient atm, TODO improve it)

  Studies

• study where to store user-edited confs (Nuxeo ? fs ? git ??) and how to refer to it in the model (soapui conf as appimpl / module ??). See also vs for other external tools (sca import and its different uses : design, runtime ; scaffolder : file system with exchangestore referenced in the model ; fstudio ; talend etc.)
• study whether mapping it to applications smaller / closer to the "actual" one is feasible / better for understanding & representation. Like splitting soapui confs in several mock client and server appimpls ? Or even having "tridimensional" or "half transparent" models with said big application's component underneath as single implementation of a lot of upper "business" components, with easy browsing using one or the other ??

[mkalam-alami]

Done a first version of the SoapUI generation:

Features

• Allows to generate a configuration from any document that contains services
• Generated configuration contains each WSDL and each of their operations

Limitations

• The WSDL parsing is done manually (with EasyWSDL), so the configuration is not as complete and accurate as the one that would be generated directly through SoapUI
• SoapUI cannot be started directly, the configuration file has to be saved on the filesystem, then imported with SoapUI

[mkalam-alami]

Done a refactoring of the SCA import form to support SoapUI configurations import.

Features

• Allows to choose a target environment
• Parses every service in the configuration file

Limitations

• No support for mocks yet
• Discovered services are not aggregated nor linked together in any way
• File is not kept in memory