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 (http://www.eclipse.org/buckminster/), 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.

---

That naming process can, if required, specify details such as the version number of a component. This information will usually incorporate the RMAP – Resource Map – a URL or similar reference identifying the possible libraries or repositories where that component can be found. If that target component is itself constructed from other components, the RMAP will also list the repositories where all the components can be found.

The RMAP also allows developers to define specific search paths through the developers' local and wider resources, if required. This allows them, for example, to set a path that starts with their own repository if they have one, then the team's repository, and so on out through corporate repositories and onto external public sources such as the Eclipse CVS respository. Buckminster is able to work with most forms of repository, ranging from databases and file systems at one end through to CVS, SVN or Maven repositories at the other. The key is that Buckminster is equipped with a component reader relevant to that source.

There are a couple of specification concepts which govern the components themselves and the way they are materialised. The Component Specification (CSPEC) is a file containing all the metadata about that component, such as its dependencies upon other components. If the components are Eclipse generated, for example plug-ins, then this file will normally be generated automatically by Buckminster. There is a variant on CSPEC, known as CSPEX, which is used when the specification needs to be manually written.

The Materialisation Specification (MSPEC) controls the way in which downloaded components materialise into specific folder or directories on a target computer. For example, it can accommodate the way in which a component may need to download slightly differently to the workstations of a development team, depending upon the type of workstation – Windows or Linux for example – individuals favour.

The BOM is the Bills Of Materials of a component. It is generated automatically by Buckminster and contains a complete list of everything needed to materialise the component, including the locations and versions. It can also be used as a publishable entity so that all consumers of a component or service get exactly the same instances of the components specified, selected from the same repositories.

This ensures that consumers get the specified service or application that has been set down for them rather than the first located example of any version of a named component. It can also mean that different user communities can be specified with different versions of the same components, a capability that can be vital to different implementation applications where issues such as corporate governance or compliance to legislative or operation rules form a core part of business policy.

Using the Eclipse version numbering, Buckminster is still at Version 0.1.0 and is only expected to get to Version 0.4.0 over the next 12 months. So it is still some way from being a viable tool for any but the early adopters amongst the developer community.

But as greater usability, support for a wider range of component models and support for more languages is added it can be expected to get closer to being a tool that makes the development applications and services a more flexible and faster task. Developers thinking of joining that early adopter community can download the latest build of Buckminster here (http://www.eclipse.org/buckminster/downloads.html). ®

Related stories

Europa heralds total Eclipse (14 June 2007)
http://www.theregister.co.uk/2007/06/14/eclipse_europa_launch/