There is a lot of talk now about Domain Specific Languages and their use to simplify the delivery of software. There are many reasons why DSL’s are getting attention, but the primary driver is simply that the world is full of generic languages which are being used to solve increasingly specific problems… over and over again. A part of this movement stems from a strange dichotomy that has arisen over decades now in the Software Modeling space. The basic idea is that for some, the software model is a way of communicating and documenting business requirements. For this set of people, the model is most useful for abstracting out the most fundamental pieces of the business requirements. Since the business abstraction is focused at the business concepts, it is not well suited for generating software.
There are others who are charged with building software who have correctly identified that using a Model to represent their core programming concepts can allow them to write code generators, packagers, and other automation frameworks that make the work of creating and more importantly changing software a lot easier. For this group, modeling is a way of abstracting out the most fundamental pieces of the software solution. These two groups have some overlapping requirements, but many other competing requirements. And so the DSL has been created to solve a few problems.
- A DSL that is geared towards business concepts can minimize the learning curve of the business user who is reviewing the models
- A DSL that is geared towards software concepts can be more easily used to generate software artifacts and deployable and runnable solutions.
And so we can pretty easily recognize the difference now between Business Modeling and Software modeling. In Software Modeling, we are modeling our finished good… our product… our actual technology. This is similar to the automotive designer using technology to “model” the design of a car. The trick though, is that building cars would only be marginally less expensive and faster if that advanced “model” was still built through a completely manual process. The second ingredient in the optimization of the delivery is the shop floor automation. The ability to replicate a design using components and robotics is imperative.
The Four Levels of Reuse and Optimization (Production Line Semantics)
Common Source (Share the Blueprint)
In its simplest form, reuse is achieved be replicating code that has already been written. In this case, a developer must find code that performs a similar task or achieves a similar goal, and then they basically copy and paste the raw code. The drawbacks to this approach are pretty well understood.
- Finding the code can be hard
- Dependencies are difficult to maintain and follow
- Reuse is one time only, unidirectional
Common Binary (Share the Parts)
The next level of reuse is achieved by componentizing the production, and sharing the same parts. In this case, the code is created and compiled into a module that performs some specific function(s) and then that module is replicated and shared in many final form applications. The benefit to this approach is that when a new version of the code becomes available, it can be updated by introducing the updated module to the final form application. The drawbacks of finding these modules, dealing with their dependencies, and sometimes dealing with their lack of backwards compatibility still exist. This is the state of the open source modules which are incorporated into so many applications and services.
SOA (Share the Car)
The next level of reuse delivers a single instance of a commodity which can be shared by all users. The common runtime level of reuse assumes that capacity can be expanded as the number of users grows. There can still be challenges finding the right service to use, and sometimes you may need to switch between services, but as long as the contract is not broken, the service can update itself without requiring redistribution and reincorporation. Another benefit of the shared runtime approach is that it is easier to enforce rules consistently. If a new rule is made, it can be applied to all consumers of the service at the same time. The limitations in this approach are merely dealing with the special cases, the variations, and the capacity of a single shared system. This model is employed by SOA infrastructures to provide shared services which can then be incorporated into coarse grained solutions and services.
Robotic Generation (Automate the Plant)
The highest level of reuse incorporates the best of each of the other levels while diminishing their drawbacks. In this case, you still use shared libraries, and you still use shared services, but rather than building the rest of the application by hand, you automate that production by creating a robot who builds each car the same way, every time. In this case, it is not only the original design, the component parts, or even the resulting creation that is reused, but also the creation process itself. Automating the plant lets people focus on the selection of the reusable parts, and the design work for creating new and powerful solutions. When a new design or part is available, the robot is updated with the new design and the new parts, and the new final form creations are now consistently created in less time. It is the automation combined with componentized parts and reusable services that achieves the goal of allowing the human workers to focus on creativity problem solving rather than the repetitive tasks of daily construction.
Since we aren’t building cars, we do have to ask ourselves, what is it that we are building then. What are the software “things” that we want to build automatically. And so enters the runtime framework. Most runtime frameworks like Spring, Seam, and Ruby were written with the same goal, to simplify the process of building software. In many cases, the design premise is to keep the code small and to achieve interesting things with the code through configuration. Configuration is taking on a far greater role in the delivery of software. Whether it’s the attributes you pass to your JSF tag or the attributes you put in your Spring configuration, or even the annotations you put in your code, all of it represents externalized configuration of some existing code. In software as in politics, power = corruption (let’s call it complexity). Absolute power (broad languages and modeling platforms) are complex… Absolutely. And so as the proliferation of software configuration points grows, so too does the complexity of creating and managing those configurations. To combat this, vendors are producing tooling aimed at assisting developers in their efforts to visualize and manage their software projects. Many runtime frameworks are in effect becoming DSL’s in that their syntactical concepts are becoming models of software concepts like “beans” or “services”, etc.
Skyway’s software offering is geared at defining a generic DSL for Web Applications and Services and surrounding that DSL with advanced visual tooling and pluggable Runtime generation frameworks. We believe that Software Modeling is ready to stand on its own, separate and apart from Business Modeling and that while developers are embracing new standards and frameworks, that they are also interested in using code generation frameworks like EMF to build out large portions of their code, configuration, and deployments. Our goal is to extend the EMF paradigm to Service and Web Application development and standard Enterprise Applications.
……talking about our $40,000 
This means that all RIAs and individual Web Services built using Skyway are deployed to run in the Spring Framework. We have been certified by 
