LiquidML: A Web Modeling Language Supporting Fast Metamodel Evolution

LiquidML: A Web Modeling Language Supporting Fast Metamodel Evolution Esteban Robles Luna1, Julián A. García-García3, Gustavo Rossi1, 2, José Matías Rivero1, 2, Francisco Domínguez Mayo3 and María José Escalona3 1LIFIA, Facultad de Informática, UNLP, La Plata, Argentina 2Conicet, Caba, Argentina 3Web Engineering and Early Testing Group, University of Seville, Seville, Spain Keywords: Evolution, Model-based Development, Self-reflective, Web Development. Abstract: Model Driven development approaches are being adopted by the software industry due to a core set of benefits such as raising the level of abstraction and reducing coding errors. However, their underlying modelling languages tend to be quite rigid, making their evolution hard, specifically when the corresponding metamodel do not support primitives and/or functionalities required in specific business domains. In this work, we present an approach for fast evolution of the modelling language that is “self reflective”, allowing modellers to abstract new language concepts from the primitives. The main advantage of our approach is that it provides zero application downtime and automatic tool evolution. As a consequence, applications created with our approach are able to adapt quicker to the business needs than those based on traditional Web modelling languages. We compare our approach with existing modelling languages in a case study providing a proof of its ability to adapt faster than to new business needs. 1 INTRODUCTION During the last couple of years a myriad of Technologies and Languages (T&L) have been developed to simplify and speed up the process of Web application development and maintenance. These T&L range from development frameworks such as GWT (GWT, 2016), JQuery (JQuery, 2016) to non-relational databases such as MongoDB including tools that help you monitor the running application (to keep the application running 24x7) such as New relic (New Relic, 2016). Most of these T&Ls have been developed in the industry and are based on coding activities while only a few domain specific languages (DSL) for Web application development (Ceri et al, 2000; Escalona et al, 2008; García-García et al, 2014) have been developed in the Academia and have real world application (Escalona et al, 2013). These Web DSLs are generally based on MDE (Model-Driven Engineering) (Schmidt, 2006) or MDD (Model- Driven Development) (Pastor et al, 2008) and thus require a model to code transformation in order to obtain a running application. In addition to these T&L, the industry has shifted from traditional cascade development approaches to agile practices. Through constant communication between stakeholders and software reusability and adaptability to change, these practices have reduced software development costs. The necessity for quick changes has surged due to the huge number of applications that makes harder to acquire and withhold users active in the Web site. As a consequence, the ability to make small but effective changes in a matter of 1 to 3 days became increasingly important and affects the decision of which T&Ls to be used. A clear example of this issue is the introduction of A/B testing techniques to help with the analysis of which design version of a new feature will be implemented in full. To achieve it, each version of the feature is partially implemented and presented in a production environment while usage data is recorded. Afterwards, a usage analysis report is generated, making the choice of which design suits better (e.g. makes the users more active or improves user retention) a simpler decision. Then the design must be implemented in full within the next couple of days. 318 Luna, E., García-García, J., Rossi, G., Rivero, J., Mayo, F. and Escalona, M. LiquidML: A Web Modeling Language Supporting Fast Metamodel Evolution. In Proceedings of the 12th International Conference on Web Information Systems and Technologies (WEBIST 2016) - Volume 1, pages 318-326 ISBN: 978-989-758-186-1 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved In this context, a common problem that these DSL share is their inability to evolve fast as the underlying business requirements change, e.g. introducing new modelling primitives for accelerating the implementation of a project with tight deadlines when fine-grain business-related requirements arise. In those cases, where the current metamodel does not support the desired functionality, a set of activities needs to be performed in the development environment to adapt to it, including: Extend the metamodel with new concepts; Extend the transformation engine to derive the desired code; Perform a full round of tests of the new functionality; Adapt the tooling to add the new elements in the user interface; Deploy the new version into modelers’ machines. Depending on the metamodel change, these activities can take an amount of time that a project might not tolerate. A workaround to this problem can be achieved if the modeling environment supports hooks where modelers can introduce pieces of programming code that are taken into account during code derivation (Ceri et al, 2000). However, if that workaround needs to be applied to multiple model elements, it can be time consuming and error prone – implying also a violation of model’s abstraction, which is one of the primary advantages of using a Model-Driven process. Our approach overcomes this problem by allowing modelers to “abstract” concepts from existing models following a modeling by example approach. That is, when an aspect of the application can be captured in a reusable concept, the implementation environment allows modelers to select the elements from the models and abstract a new concept that gets automatically integrated in the language. Additionally, the approach takes care of the whole development lifecycle by including the new concept in the derived application and thus minifying the hassle of evolving the metamodel. In this paper we present the runtime environment and the implementation of our model-based approach that minifies the difficulties of metamodel evolution. The theoretical foundation of our proposal is described in (Robles et al, 2014) and it is named LiquidML. LiquidML allows building applications that can be modeled using the message-passing paradigm (Hohpe et al, 2003). We present the approach using a simple Web application where a weather component needs to be introduced into the language primitives. Rest of the paper is structured as follows: in Section 2 we present the LiquidML environment, describing its primitives and its ability to abstract new concepts. We provide details about how these aspects are translated into a production environment by presenting the LiquidML’s runtime environment in Section 3. We introduce part of the implementation in Section 4. Finally in Section 5 we describe some related work and in Section 6 we present some conclusions and future work. 2 LiquidML In the following subsections we introduce the LiquidML modeling environment. 2.1 Overview LiquidML (Robles et al, 2014) is a modeling language that allows modelers to create applications based on the message passing paradigm (Hohpe et al, 2003). There are many different subtypes of applications that can be built using LiquidML including Web and Integration applications. This work focuses on the Web aspects of LiquidML and as a consequence we will emphasize the relationship between LiquidML, other modeling languages such as WebML and NDT (Escalona et al, 2008; García- García et al, 2014) and the actual Web Application. Applications models built with “conventional” approaches (e.g. WebML) are transformed into code that is run inside a Web container such as Apache Tomcat or a PHP server. The basic primitives in these languages abstract high level entities such as Web page, domain objects and usual behaviors such Figure 1: WebRatio model for an E-Commerce application. LiquidML: A Web Modeling Language Supporting Fast Metamodel Evolution 319 as navigation. As an example, consider the WebML model of Fig. 1 that describes a simplified E- Commerce application that has 2 pages: the “Home” and the “Detail”. The boxes inside the pages are instances of model elements that allow listing the Products and allows to see the actual details of a specific one. In addition, the other box allows computing a ranking for the product to be displayed, e.g. “Ranked #2 in Computers”. As will be shown in the following subsections, LiquidML has a finer grained metamodel that focuses on the basic concepts of model passing languages such as message, message source, processor and router (Hohpe et al, 2003). Thus from a level of abstraction point of view, LiquidML seems to be closer to the level of abstraction of code that to the elements in WebML. Also, the focus of LiquidML is completely behavioral, whereas WebML is structural; for instance, the arrows between the elements do not imply a sequence of evaluation but connections such as hyperlinks. From a development process perspective, LiquidML models can be either derived semiautomatically from high-level models such as WebML and NDT or they can be created manually using a LiquidML editor (Robles et al, 2014). When manipulated, some higher-level concepts can be abstracted as modelers discover them and thus the development metamodel gets enriched interactively within the process (Sect. 2.4). Similar to what happens in the lifecycle when using “traditional” model-driven approaches, a Build/Snapshot is created and then it gets deployed into a server that is capable of running/interpreting the Web Application. 2.2 Basic Concepts Our main motivation to develop LiquidML has been the lack of behavioral expressiveness in existing Web modeling languages. As a consequence, transforming the behavioral aspects of a Web application (e.g. in WebML) becomes cumbersome and usually extra notations need to be added to (graphically) represent a new expected behavior. Additionally, the high level (and mostly structural) nature of these languages completely hides the way in which lower level Web requests are processed (e.g. in which sequence) by just ignoring them, thus hindering important spots for introducing performance improvements, for instance, to obtain better application scalability. LiquidML provides a way of representing the behavioral aspects for applications that can be modeled using the message passing paradigm such as Web Applications and thus enables to refine such important and low-level aspects. A LiquidML model is a composition of Flows; each Flow describes a sequence of steps that need to be applied to the current Web request (called a Message in LiquidML) to obtain a proper response. A Message has a payload (body) and a list of properties while each step is visually identified by an icon and constitutes an Element of the Flow. Communication between Elements occurs by means of message interchanges. The way in which messages are moved from one Element to another is defined by the Connections between them. We have categorized the Elements using the categories found in (Hohpe et al, 2003) and every element has a different icon that represents it: Message Source A message source is responsible for creating instances of messages based on different conditions. There can be many different types of message sources, for instance one of the HTTP message source listens for incoming requests and generating Messages from them. Another example is the Queue message source that listens to a Data queue and creates a new message when the queue is filled. Some other message sources include:  Cron message source: Creates a message every time a Cron expression to true.  FTP message source: Creates a message for each file that is read from a remote FTP server.  File message source: Creates a message for each file that is read from the local file system. Processor A processor may transform, execute or just read information from a message by changing or reading the message’s payload and properties. There is a wide variety of processors though the most common one is the ScriptingProcessor that allows modeller to write scripting code for custom complex logic. Some other common processors are:  Log processor: it reads information from the message and generates log information based on its configuration.  Select SQL processor: it uses a Select SQL statement to fetch information from a database and sets the list of rows recovered into the message payload.  Change SQL processor: it executes an Insert/Update/Delete statement in a database and stores the number of affected rows in a APMDWE 2016 - International Workshop on Avanced practices in Model-Driven Web Engineering 320 property configured by the modeller.  Dust processor: it converts the message payload using a dust template into processed HTML that can be rendered in a Web browser.  JSON transformer: it transforms the message payload into a JSON object.  XML transformer: it transforms the message payload into a XML document using an XSLT definition.  Mapping transformer: it transforms the message payload into a Map/Dictionary using the configured keys and expressions. Router It moves the message between Elements depending on its type and conditions. For instance, a ChoiceRouter routes the message to a specific Element of its list based on a Boolean condition.  Choice router: Behaves in the same way as a “switch” statement in a procedural programming language. It evaluates the conditions of each of the choice connections in sequence and the first one that evaluates to true is the one that gets activated: the element that the connection reaches is the next one to be evaluated.  All router: it creates a copy of the current message sending it to all the “all connections” evaluating them in parallel and collecting the results.  Wiretap router: it creates a copy of the message and sends it in async way to the wire tap connection. It is an implementation of the EIP (Enterprise Integration Patterns).  Chain router: The chain router evaluates each of the chain connections in sequence. After evaluating the 1st chain connection, the result is passed to the 2nd connection and so on until all the chain connections are exhausted. Connections It describes a relationship between 2 elements. The most common connection is the “Next in chain” which specifies that after the “source” element processes the message, then the “target” element will be the next to process the message. The complete list of connections is:  Next in chain: It describes a sequence between a source element and a target element. The source element can have only 1 next in chain connection while the target element may have multiple.  Choice connection: Choice connections have a configurable condition and the source element can only be a choice router though the target element can be any kind of element. The choice router may have multiple choice connections.  All connection: Similar to choice connections, all connections only apply to source all routers though the target element can be of any kind. The all router may have multiple all connections.  Wiretap connection: It only applies to wiretap routers and a wiretap router can only have 1 wire tap connection that is connected to any kind of element.  Chain connection: Similar to choice connections, chain connections only apply to source chain routers though the target element can be of any kind. The chain router may have multiple chain connections. To exemplify the concepts, we present a Flow for the product’s detail page of an E-commerce web application (Fig. 2). The Element with no incoming arrow represents the Message source listener that will receive incoming requests – in this case, it will receive HTTP request and will transform them into Messages. The Element connected to the Message source named “Route path” is a ChoiceRouter, which behaves like a choice/switch statement and it will route the message to the “Get info” processor if the request comes to a URL starting with “/product/*”. The “Get info” is another router that gets information in parallel from multiple sources. It Figure 2: Product details flow. LiquidML: A Web Modeling Language Supporting Fast Metamodel Evolution 321 obtains the product info from the DB: (“Get product info”) and triggers the computation of the product’s rank, which involves two database queries (“Get user reputation” and “Get product reviews”) and a Processor that computes the rank from this information (“Compute product rank”). Finally, the information gets composed (“Compose data”) and used for rendering a Web page in the “Render template” processor. In the following subsection we present the actual metaclasses, templates and the Abstraction class in LiquidML. The components in the models described in Fig. 2 show how a traditional Web page can be splitted in atomic steps, which allows to model and optimize fine-grain aspects of the application. The cost of having such low-level modelling language (in comparison to classic model-based Web development approaches) is compensated with the possibility of easily grouping its components in more abstract elements at modelling time. 2.3 Abstracting Concepts from Examples When developing applications with models, sometimes a desire business feature requires having a flexible general model that is not always available. For instance, in the E-commerce application, we may want to present and change the behavior of the application based on the weather conditions where the user is located. This functionality was not natively included in LiquidML’s language and as a consequence a workaround is needed to implement it. Therefore the modelers are able to come with a solution that integrates a sequence of processors to perform the external API calls to, for instance, the OpenWeather API (Open weather map, 2006). Basically, by making an IP to City mapping and then looking up for that city in the API we are able to get the information needed for our recommendation systems. This solution works fine for one specific flow; however, the E-Commerce application is composed by a set of Applications where each may contain multiple flows. In several of these flows we may have to use Weather information and applying this workaround everywhere is clearly not a feasible solution. Following the same approach that code based environments provide, in LiquidML we have the ability to encapsulate and abstract a new concept from a subgraph. So, modelers are able to select the elements to be abstracted, click the “Abstract” button and the environment automatically reconfigures the Flow with the new abstracted element. The environment then creates an instance of the Abstraction metaclass as shown in the next section 2.4 Models and Templates LiquidML allows abstracting new metamodel concepts from LiquidML application models. For achieving this, our approach uses a set of template classes that configure the parts of the abstraction (Fig. 3). A special metaclass is required in the metamodel to capture the new abstracted concepts; we call this class Abstraction. A new instance of the Abstraction class is created when a concept is captured (Section 2.3). The instance of the Abstraction class knows how to instantiate its internal pieces since it reference the list of templates to configure each of them (Fig. 3). The primitives of the language are instantiated by looking into the metamodel implementation and its configuration. To achieve the instantiation, we use a set of template classes that may have a one to one correspondence with the meta classes, however the instances of the template classes are one per model instance while the meta classes are one per concept. Templates are either Simple or Composite; simple templates have a list of properties to configure the instance and composite elements know how they are composed. 2.5 Evolution Process Once the Abstraction instance is created a set of activities is performed automatically to evolve the development environment and the application under development. The 1st step is to block the user interaction with the flow under development and checks that the elements selected formed a single connected subgraph with a root element (an element that does not have an incoming arrow). This is because the semantics of message passing require an initial element to delegate the behavior. Once the validation is performed, the abstraction and templates instances are created. The abstraction is set a default icon and the modeler can input a name for the abstraction. The 3rd step is to remove the elements from the flow under development, creating a template that refers to the new abstraction and hooking up the incoming/outcoming arrows to the abstraction created. APMDWE 2016 - International Workshop on Avanced practices in Model-Driven Web Engineering 322 3 RUNTIME ENVIRONMENT As aforementioned, flows define the behavioral part of the Web application. On the contrary to all MDWE approaches, we decided to interpret rather than to derive the code of a Web application. Strong cons and pros of both approaches can be found in (Mellor et al, 2002) and in many informal discussions (The Enterprise Architect, 2016; Executable models, 2016; Webratio, 2016); however, we do not expect to find a definite answer to this matter but rather present the advantages we found for Web application development in our model based approach. It is true that at a first sight, code-generation seems to be the right option, however interpretation gives us an opportunity to easily modify the behavior in a dynamic way. As our behavioral models (Flows) are rather simple, the interpreter algorithm is quite simple too. We present a simplified version of the algorithm using a Java-based pseudocode in the next lines: the interpreter works when messages are received (event driven (Hohpe et al, 2003)) on Message sources (e.g. an HTTP message source) (line 1). It finds the next element (currentElement) that will handle the message (line 3 and 6) and evaluates it using the message content (line 4). An evaluation returns a Message instance that could be the same as the previous one or a new one depending on the Element intent (data transformation, routing, etc.) and it is passed to the next Element until we run out of Elements (line 3). 1. OnMessageReceived(MessageSource msgSource, 2. Message message): { 3. Element currentElement = interpreter.getNextInChain(msgSource); 4. while (currentElement != null) { 5. interpreter.evaluate(currentElement, message); 6. currentElement = interpreter.getNextInChain(currentElement);}} A special case is handled by the interpreter (line 5) when currentElement is an Abstraction. In that case, we follow the same approach as any other programming language behaves by using a stack as Abstraction is basically composed of more primitive elements that may include other processors or Abstractions. So processing an Abstraction is processing its internal subflow starting from the initial element. Interpretation happens while engineers are building the application and when the application is run in every other deployment environment (QA, Staging, Production). Once the models satisfy the requirements, the deployment process to a specific Figure 3: LiquidML models, templates and instances. LiquidML: A Web Modeling Language Supporting Fast Metamodel Evolution 323 Figure 4: Sending messages to specific model elements. environment occurs. The deployment is an automatic process where a copy of the models is moved to the servers where they can start receiving messages. As aforementioned, unforeseen problems may appear in a production environment; thus in the following subsection, we present two tools to help diagnosing problems while our models are running. 4 IMPLEMENTATION The aforementioned concepts have been implemented in an environment that allows modellers to create applications based on the message-passing paradigm. The environment is completely Web based and to the best of our knowledge, the first one to additionally implement the Modelling as a Service paradigm (Toffetti 2012). One clear advantage of our implementation is that allows modellers to debug the application under development at the model level. In Fig 4 we show how modelers are allowed to send messages to specific model elements. The LiquidML environment is composed of 2 main applications that can be instantiated multiple times and run in a cluster: an editor and servers. The editor is instantiated in multiple machines running behind a load balancer in Amazon EC2 though it can be installed in any local servers. A brief description of each application is the following: LiquidML editor, which allows defining the applications, modelling Flows and deploying them to LiquidML servers and It also, allows modelers to abstract new concepts from existing models; and LiquidML server, which is responsible for holding the application definitions, the LiquidML interpreter (Robles et al, 2014) and notifying the editor about how applications are running. In addition, it regularly checks if it has any pending deployments and if so, it fetches the Application and automatically deploys it. Both the editor and the server have been built using open source technologies of the J2EE stack. We have used Spring and Hibernate for basic service and ORM mapping, Spring MVC and Twitter bootstrap for UI and Jersey for the LiquidML API. As part of this development, we have built the CupDraw framework for building Web diagram editors, which is publicly available. For the technical readers, we invite them to visit the LiquidML site http://www.liquidml.com and check the project’s source code and the demonstration videos; especially the one demonstrating the “abstraction” feature. A complete version of the Editor without pruning any of the menus and toolbars can be seen in the LiquidML site. 5 RELATED WORK In (Blair et al, 2009) the idea of holding models at runtime to perform runtime changes is presented. The approach focuses in the representation of the actual requirements as models while the application is running. The applications built under the models@runtime paradigm are from a different domain and seems to have less sophisticated business requirements than a Web application. On the other hand, LiquidML uses models@runtime to have a live representation of how the application is constituted and as a consequence it can be manipulated to be able to abstract new concepts. Approaches oriented to allow evolving metamodels and co-evolve its models have been studied recently (Cicchetti et al, 2008, Hoisl et al, 2014). They are similar to LiquidML in the need of adding some extra primitives that are not supported by the language. However, in LiquidML anything that could be written with a Scripting processor (> 95% of the cases) can be done with no downtime APMDWE 2016 - International Workshop on Avanced practices in Model-Driven Web Engineering 324 and the tool is evolved automatically within the abstraction process. The main problem solved by our approach comes from applying model driven techniques to industry applications that require time constraints. As a consequence and due to the rigid features of traditional metamodeling approaches (like Eclipse Modeling Framework (EMF, 2016)), we have to discard it as a solution for making an easy to evolve environment. 6 CONCLUSIONS In this paper, we have presented the LiquidML, a Web modelling language that supports the fast evolution of its metamodel and supporting tools. By capturing the abstraction concept, which references the templates to configure its parts, we are able to build concepts from existing model solutions following a modelling by example approach which mimics with the approach use to build frameworks from existing pieces of code. The environment is fully functional, and is the first one to implement the modelling as a service approach, so it is fully reproducible and available for researchers, engineers and modellers to experiment. The LiquidML language is formally defined and we do not expect to see much changes in that regards, however the implementation environment still needs some improvement regarding its usability such as allowing modellers to change icons, input and output parameters (implicit right now), documentation and the release process of new abstractions to the community. From a conceptual point of view, models do not provide a way of being tested, so we plan to formalize a testing framework that will allow modellers to test flows and provide tools such as flow coverage which will give confidence to modellers when releasing a new version of the application. Finally, we plan to include a “concepts” market where people can consume concepts that a different modeller team are using and thus creating a community around LiquidML. ACKNOWLEDGEMENTS This research has been supported by MeGUS project (TIN2013-46928-C3-3-R) of the Ministerio de Ciencia e Innovación (Ministry of Science and Innovation, Spain, TIN2013-46928-C3-3-R). REFERENCES Blair G., Bencomo N., France R. B., "Models@ run.time," Computer, vol. 42, no. 10, pp. 22-27, October, 2009. Ceri S, Fraternali P, Bongio A. Web Modeling Language (WebML): a modeling language for designing Web sites. Comput. Networks, vol.33, pp.137–157, 2000. Cicchetti A., Di Ruscio D., Eramo R., and Pierantonio A. Automating Co-evolution in Model-Driven Engineering. In Proceedings of the 2008 12th International IEEE Enterprise Distributed Object Computing Conference. IEEE Computer Society, Washington, DC, USA, 222-231. EMF. Website: http://www.eclipse.org/modeling/emf. Last access: 2016. Escalona M.J. and Aragon G., “NDT. A Model-Driven Approach for Web Requirements,” IEEE Trans. Softw. Eng., vol. 34, no. 3, pp. 377–390, May 2008. Escalona MJ, Garcia-Garcia JA, Mas F, Oliva M, Valle C. Applying model-driven paradigm: CALIPSOneo experience. Conference on Advanced Information Systems Engineering 2013, vol.1017, pp. 25-32. 2013. Executable models vs code-generation vs model interpretation. Website: modeling-languages.com/ executable-models-vs-code-generation-vs-model- inter pretation-2/. Last access: 2016. García-García J.A., MJ Escalona, F Domínguez-Mayo, A. Salido. “NDT-Suite: A metodological tool solution in the Model-Driven Engineering Paradigm”. DOI: 10.4236/jsea.2014.74022. 2014. GWT. Development toolkit. Website: www.gwtproject. org. Last access: 2016. Hohpe G. and Woolf B., Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, 2003, p. 736. Hoisl B., Hidaka S., Hu Z., Towards Co-Evolution in Model-driven Development via Bidirectional Higher- Order Transformation. 2nd International Conference on Model-Driven Engineering and Software Development (MODELSWARD) 2014. Mellor SJ, Balcer M. Executable UML: A Foundation for Model-Driven Architectures. Addison-Wesley Longman Publishing, Inc., Boston, MA, USA. 2002. New Relic. Website: www.newrelic.com. Last access 2016. Open weather map. Website: openweathermap.org. Last access: 2016. Pastor O, España S, Panach JI, Aquino, N. Model-driven development. Informatik-Spektrum, 31(5), 394-407. 2008. The Enterprise Architect. Website: http://www. theenterprisearchitect.eu/archive/ 2010/ 06/ 28/ modeldriven-development-code- generation- or- modelinter pretation. Last access: 2016. Toffetti G. Web engineering for cloud computing (web engineering forecast: cloudy with a chance of opportunities). In Proceedings of the 12th international conference on Current Trends in Web Engineering. Springer-Verlag, Berlin, Heidelberg, 5- 19 2012. LiquidML: A Web Modeling Language Supporting Fast Metamodel Evolution 325 Robles E, Rivero JM, Urbieta M, Cabot J. Improving the scalability of Web applications with runtime transformations” in Proceedings of the 14th International Conference in Web Engineering. 2014. Wimmer M, Schauerhuber A, Kargl H. On the Integration of Web Modeling Languages: Preliminary Results and Future Challenges. Proceedings of the 3rd International Workshop on Model-Driven Web Engineering, 2007. Webratio. Website: blog.webratio.com. Last access: 2016. JQuery. Website: https://jquery.com/. Last access: 2016. Schmidt DC. Model-Driven Engineering. IEEE Computer, Computer Society, vol. 39, no. 2, pp. 25-31, 2006. APMDWE 2016 - International Workshop on Avanced practices in Model-Driven Web Engineering 326