Le moteur commence à appliquer le style architectural ainsi que les modèles de conception supplémentaires à chaque concept que son client a inclus. Par exemple, le moteur ajouterait à toutes les ressources spécifiées dans une entité de contrôleur qui gérera toutes les requêtes Web entrantes avec un certain type de protocole. Ensuite, il attribuerait à chacun d’eux un URI unique et des gestionnaires de représentation d’entrée/sortie d’un certain type. De plus, il concevrait un schéma de base de données d’un type suffisant pour stocker les données de la boutique en ligne envisagée, qui seront accessibles de manière uniforme au moyen d’un contrôleur de référentiel. Une fois que le moteur transforme chaque concept en lui appliquant le style architectural décrit, la boutique en ligne envisagée est formulé. Il faut cependant souligner que, de même, l’ingénieur de la maison victorienne n’a pas précisé la fabrication exacte des matériaux, le moteur ne spécifie pas non plus de technologies spécifiques à utiliser à ce stade. Au lieu de cela, il a utilisé une forme générique abstraite de chacun d’eux (un certain type de protocole, un certain type de schéma de base de données, etc.).
Comme dans le cas de la maison victorienne, l’étape suivante consiste à choisir des technologies (matériaux) spécifiques avec lesquelles le service sera construit. Dans le moteur par exemple, une combinaison possible de technologies pourrait être le framework JAXB pour gérer l’analyse et le marshaling des représentations entrantes/sortantes, le JAX-RS pour gérer les requêtes web entrantes du protocole HTTP 1.1, le Hibernate un pour gérer le schéma de base de données RDBMS de (par exemple) POSTGRESQL et le langage Java comme langage pour coder le service envisagé. Une fois que le moteur applique une technologie spécifique à chaque composant, la boutique en ligne est formulée. Bien sûr, il pourrait y avoir de nombreuses autres combinaisons de technologies qui pourraient être utilisées. D’autres clients pourraient en choisir un autre parmi ceux disponibles !
À ce stade, les générateurs de code appropriés écrivent le code logiciel réel. Une fois cela fait, le processus de construction du service de la boutique en ligne se termine. Bien sûr, comme dans le cas des maisons victoriennes, certaines ressources finiront par être entièrement mises en œuvre (pièces entièrement construites et décorées), tandis que d’autres auront besoin de quelques ajouts pour être complétées ou il peut même y avoir des ressources simples wrappers (salles vides) interconnectés avec les autres ressources du service. De telles ressources nécessiteraient l’intervention d’un développeur humain pour être achevées à peu près comme le jardin de la maison victorienne aurait besoin d’un jardinier pour y planter des fleurs, etc.
En résumé, le logiciel automatise la procédure de création de services Web. Une fois qu’il a analysé les exigences multimodales (diagrammes UML, texte semi-structuré, etc.), il tente de comprendre les besoins de son « client » afin de formuler la solution. Plus tard, il applique le style architectural pour transformer selon les préférences de l’utilisateur.
Enfin, il lance son générateur de code pour produire le code de service réel. Le point crucial à souligner une fois de plus, c’est que ce processus est automatisé. Ainsi, le client qui « a fait part de ses besoins » au moteur en fournissant son entrée multimodale, récupèrerait alors automatiquement et instantanément le service correspondant.
Ceci conclut à peu près la démonstration de la façon dont le moteur construit un service. À ce stade, de nombreuses possibilités se présentent. Quels devraient être les concepts acceptables ? Quelle devrait être la conception appliquée, etc.
