Oslo and the DSL Toolkit
I’ve received a number of questions concerning the relationship of Oslo to the Visual Studio DSL Toolkit. Comments have varied from the sublime (see David Ing’s comment on his blog “My best guess is that the DSL Toolkit is research road kill in front of the big Oslo truck and that VSTS Architecture Edition was just about a necessary cycle too early” ) to the ridiculous. Since I’ve been a founder member of both projects, I thought I’d try to start the discussion with a few comments of my own.
Firstly, it’s true that the two efforts are built on different technology stacks – the DSL Toolkit works on file-based artifacts (schemas, model instances, etc.) and produces graphical and forms-based tools that run as add-ins to Visual Studio – dramatically simplifying the task of creating tools hosted via VS extensibility.
On the other hand, Oslo is based on an underlying SQL database. Quadrant depends on the underlying database for both the data it is processing and its own configuration data. In other words, Quadrant’s equivalent of the DSL Tools’ domain modeling language and the shape and shape mapping languages is MSchema. Concrete textual languages are of course defined in MGrammar.
Despite these differences, two things need to be made really clear:
1. Both the Oslo and the DSL Toolkit have grown from a common belief in the role DSLs can play in the development lifecycle. Not just during development, but DSLs that help record Business Objectives, Business Processes and Entities, System Architectures, Software components and connections, Deployment Information, Data Center Configuration, and System Management to name just some of the lifecycle stages. This is a shared vision, well documented elsewhere, though each project has focused on a different aspect initially. The DSL Toolkit builds great graphical (box and line) tools that run in Visual Studio and may be translated into code-based artifacts. Oslo is focused on textual and graphical developer experiences around models that initially represent code and configuration that “completes” the underlying frameworks that are part of the application platform – in other words – models that are mostly executable by the underlying servers and frameworks (e.g. WF, WCF, and Identity Services).
2. Both products have a lifecycle in front of them. The two teams, already aligned around vision, are working together to bridge differences over releases. Would it have been nice to have gone dark for a period while we resolved these technology stack issues and re-emerged with a fully aligned set of technologies? You bet – but such a strategy rarely ends with the right thing being built for customers. Ideas we are tossing around include (a) storing DSL Toolkit artifacts (including those created with the emerging UML tools from VSTA) in the Oslo Repository, (b) using MSchema as the domain language for the DSL Toolkit, and (c) converging on a single way to specify concrete DSL syntax whether it is graphical or textual. Sadly, I can’t give dates at this point.
Stuart Kent is the architect for DSL Tools. If you take a look at Stuart’s blog, you’ll find the latest blog entry where he responds to the same questions from his point of view.