Roadmap

VNUML Roadmap: Current Limitations and New Challenges

Authors:
Fermín Galán (galan at dit.upm.es)
live document

Introduction

This document aims to analyze the current status of the VNUML project (mainly the VNUML tool itself). The new challenges that would be addressed by the project are outlined, leading to a redesign of the architecture and use cases of the tool. In some sense, this document can be seen as a "VNUML 2.0" roadmap, but the fact is that it is goes steps further VNUML when considering other node backends appart of UML, like Xen of Dynamips.

Note that VNUML was born on Januray 31st 2003 (this is the releasing date of the -unpublished- 1.0.0 version). Almost 5 years after that, now that the tool has grown in functionality and users and the current VNUML language specification (1.8) is quite stable, we think is a good time to open a discussion regarding current limitations and future working lines.

Current Limitations of VNUML

• VNUML is too coupled to UML (it even shares acronym! :). We think that UML was the right choice when VNUML was conceived, but several other strong alternatives has appared in the meanwhile (like Xen in late 2003) or are emerging nowadays (like KVM). Additionally, the VNUML language it is also suitable to describe nodes that are not implemented using virtual machines, like for example Dynamips-based router entities, or, in the extreme, even real equipment.
• Mono-host environment. Considering the way VNUML is implemented nowadays, it is mandatory that the entire scenario runs in the same physical host. This is not problematic when your scenario includes few nodes (e.g., 3, 5 or even 50).
• Un-scheduled execution of commands.
• Monolithic operations.