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.


Other stories you might like

  • DigitalOcean sets sail for serverless seas with Functions feature
    Might be something for those who find AWS, Azure, GCP overly complex

    DigitalOcean dipped its toes in the serverless seas Tuesday with the launch of a Functions service it's positioning as a developer-friendly alternative to Amazon Web Services Lambda, Microsoft Azure Functions, and Google Cloud Functions.

    The platform enables developers to deploy blocks or snippets of code without concern for the underlying infrastructure, hence the name serverless. However, according to DigitalOcean Chief Product Officer Gabe Monroy, most serverless platforms are challenging to use and require developers to rewrite their apps for the new architecture. The ultimate goal being to structure, or restructure, an application into bits of code that only run when events occur, without having to provision servers and stand up and leave running a full stack.

    "Competing solutions are not doing a great job at meeting developers where they are with workloads that are already running today," Monroy told The Register.

    Continue reading
  • Patch now: Zoom chat messages can infect PCs, Macs, phones with malware
    Google Project Zero blows lid off bug involving that old chestnut: XML parsing

    Zoom has fixed a security flaw in its video-conferencing software that a miscreant could exploit with chat messages to potentially execute malicious code on a victim's device.

    The bug, tracked as CVE-2022-22787, received a CVSS severity score of 5.9 out of 10, making it a medium-severity vulnerability. It affects Zoom Client for Meetings running on Android, iOS, Linux, macOS and Windows systems before version 5.10.0, and users should download the latest version of the software to protect against this arbitrary remote-code-execution vulnerability.

    The upshot is that someone who can send you chat messages could cause your vulnerable Zoom client app to install malicious code, such as malware and spyware, from an arbitrary server. Exploiting this is a bit involved, so crooks may not jump on it, but you should still update your app.

    Continue reading
  • Google says it would release its photorealistic DALL-E 2 rival – but this AI is too prejudiced for you to use
    It has this weird habit of drawing stereotyped White people, team admit

    DALL·E 2 may have to cede its throne as the most impressive image-generating AI to Google, which has revealed its own text-to-image model called Imagen.

    Like OpenAI's DALL·E 2, Google's system outputs images of stuff based on written prompts from users. Ask it for a vulture flying off with a laptop in its claws and you'll perhaps get just that, all generated on the fly.

    A quick glance at Imagen's website shows off some of the pictures it's created (and Google has carefully curated), such as a blue jay perched on a pile of macarons, a robot couple enjoying wine in front of the Eiffel Tower, or Imagen's own name sprouting from a book. According to the team, "human raters exceedingly prefer Imagen over all other models in both image-text alignment and image fidelity," but they would say that, wouldn't they.

    Continue reading

Biting the hand that feeds IT © 1998–2022