Migrating from 0.4 to easysoa v1.0

A. Mapping old HTTP Proxy monitoring API to new RegistryApi :

for all (Node) :

• title => also build soaname out of it
• description => description IF USEFUL ONLY

Other infos may come from :

• GLOBAL to service/impl/endpoint : ex. name, endpoint & wsdl URLs...
• STRUCTURE within service/impl/endpoint i.e. operations (and their methods / in & out messages & content types). Defining structure may be guided by extracting it from live or recorded exchanges, but it's truly a service definition job that is separate from mere monit disco, where the endpoint's service is not necessarily known yet. Therefore it's a separate feature that the user has to use explicitly & supervise, and will be added LATER.
• AGGREGATION of message info along this structure, ex. callcount (possibly per operation). OPT interesting message info is extracted and recorded as SQLDirectories (like EndpointState), and aggregated on queries (has to be done by counting query results) or LATER in a cached/stored (on service/... ?) manner that is refreshed on service/... change.
• PROBE configuration ex. subproject / Phase, user of the probe, process/component...

old Service to new SoaNodeInformation of type endpoint

• GLOBAL fileUrl => rdi:url for the WSDL URL, endp:url for the endpoint URL
• STRUCTURE contentTypeIn/Out => iserv:operationIn/outContentType for each operation (TODO define them for endpoint & refactor ? or even impl ??) and REST ONLY restinfo:accepts/contentType
• STRUCTURE httpMethod => for now within serviceimpl:operations/operationName for JAXRS impls, LATER better for iserv (& endpoint)
• STRUCTURE - parentUrl (used for structuring a REST service, which is not supported anymore since rarely useful, but would now go with iserv:operations)
• AGGREGATION - callcount (& PROBE participants ?) => out OPT to state notif, their aggregation can also be copied on endpoint ; participants was filled from web disco only, now it could also come from the "user" monit disco probe configuration parameter
• PROBE + rdi:timestamp/probe
• PROBE + OPT probe component(s)

old Api has been removed. It was used for structuring a REST service, which is not supported anymore since rarely useful. To support its features :

• sourceUrl => LATER add an OperationNode to structure iserv:operations
• application => if it's the same as AppliImpl then see there, else LATER as a Component gathering several services

old AppliImpl to new SoaNodeInformation of type component with component:category = "application"

• url => nothing more than an extracted URL that should be common to its services.
• appliName => also build SOA name out of it.
• uiUrl => was merely extracted out of URL. LATER maybe add a FunctionalInterface doctype or meta to the model.
• server => was not used (though could be extracted from URL). LATER see again when updating runtime management features.
• sourcesUrl => was not used. Now somehow platform:deliverableRepositoryUrl and deltype:repositoryUrl.
• standard => was not used. Now platform:serviceLanguage & impl:technology.
• technology => was not used. Now platform:serviceRuntime & endpoint:serviceRuntime.

B. Mapping old easysoa-registry-api-remote API to new RegistryApi :

for all (old EasySOADoctype) :

• see above mapping
• discoveryTypeBrowsing/Monitoring/Import/Design
• archiPath/LocalName => Components of various types encompassing InformationServices, LATER also as computed archiPath starting with actor
• environment => endp:enviromnent

old Service to new InformationService and endpoint :

• see above mapping
• wsdlNamespace/ServiceName => wsdlinfo:wsdlServiceName, but even more important is wsdlinfo:wsdlPortTypeName (extracted from WSDL by Resource Update framework)
• referenceService(Origin) => split now among an impl/endpoint's expected InformationService, iserv/impl/endpoint versioning + diff and LATER to be updated global comparison between environments
• isValidated/validationState(validatorName, validationLog) => split now among an impl/endpoint's matching (or not) InformationService, iserv/impl/endpoint diff between versions and LATER to be updated global comparison/validation between environments
• lightUrl => LATER URL to scaffolder, built from (ExchangeRecordSet)Samples registered on the iserv/endpoint
• fileUrl => split now among endp:url & rdi:url (usually endp:url + "?wsdl") on iserv/endoint, LATER on all (WsdlInterface/Policy)Resources

old ServiceReference to new (Java)Service/EndpointConsumption :

• refId/Url => consumedClass/Interface(Location), LATER also on endpoint

old Api :

• see above mapping
• protocols => platform:serviceLanguage & impl:technology or platform:serviceProtocol endpoint:serviceProtocol ?

old AppliImpl to new SoaNodeInformation of type component with component:category = "application" :

• see above mapping
• provider => Actor, iserv:providerActor etc.
• designDocumentName/Source => RequirementsDocument and especially TODO
• runtimeServer => platform:appServerRuntime and endpoint:appServerRuntime, LATER see again when updating runtime management features.
• deployableProvider => Now platform:deliverableRepositoryUrl and deltype:repositoryUrl
• deployables(deployableId/Name/Version) => del:dependencies, LATER see again when updating runtime management features.
• lifeCycleStatus

old Workspace to new subproject (Phase) of SoaNodeInformation

• referencedEnvironment, isValidated/validationLog => LATER 1. aggregated indicators of validation of its SOA elements and 2. to be updated global comparison/validation between environments