Bricklaying with Buckminster
Don't build apps, materialise them
While the basic ideas behind Service Oriented Architecture (SOA) are very attractive to both IT and business managements, and many vendors have come up with technologies and components that play important parts in gluing it all together, there is still the issue of building applications and services in an easy and timely fashion.
It is this issue that the appearance of the Buckminster Component Assembly Project, as a future part of the Eclipse development environment, is setting out to resolve.
It is still in its early stages of development, but it holds the prospect of a tool capable of assembling applications and services, as they are required, in a way worthy of that well known brand of toy plastic bricks.
One of the keys to SOA service building should be the regular and easy re-use of code components, reassembling them as and when needed to build the functionality that a business process or other task requires. That is not easy to achieve in practice.
For example, before any components are brought together there first has to be the step of actually finding them. In many systems environments there will be many component repositories that have been generated for many different reasons – the use of different languages or development tools, or just different development teams working in different locations – so tracking down and identifying the components that might be needed for a particular project is a difficult task.
Then there may be a whole set of issues related to any individual component that make its use in a project far more complex than might be expected. It may, for example, be available as different versions, or have unexpected dependencies upon other components that are not considered as part of the project. Or it may itself be constructed from components in other repositories of which the developer may have no knowledge.
The upshot of this is that the practical reuse of components can involve developers in a level of painstaking construction and detective work that would make Sherlock Holmes feel proud. This creates an environment in which what should, in theory, be a faster more reliable method of creating applications and services in practice ends up a slower and more omission and error-prone approach.
Buckminster is designed as a container for all information relevant to the creation of a new component, application, or service. That information can range from specific source code produced by a developer through to details of the repositories or libraries where other components are stored, documentation about those components and details of how the component is to be built, if that is relevant.
In other words, it contains all that is necessary for the component to be built – or "materialised" in Buckminster parlance - as and when it is required, rather than being the component itself. This initial target is as a tool for materialising components within applications, but it can also form the essential construction process for complete applications and services. This is where a "component" can be the code and components that go to construct not only a significant business process or similar functionality, but also the relevant policy-based management controls.
The key concepts in a Buckminster component are CQUERY, RMAP, CSPEC, MSPEC and BOM, all of which are XML files. CQUERY is the Component Query, which is how the developer names a component that is to be downloaded as part of the application to be materialised.
Sponsored: Are DLP and DTP still an issue?