What is there to know about Buckminster?
Background
What is Buckminster?
Why does Buckminster exist?
What is the history of the Buckminster Project?
What exactly is Component Configuration Management?
What is the scope and ambition of the Buckminster Project?
How does Buckminster relate to The Frameworx Project?
Functionality Scope
What functional units does Buckminster comprise?
What exactly does Buckminster do?
What is OUTSIDE the scope of the Buckminster project?
What products or technologies are most comparable to Buckminster?
Technology
What are the key technologies on which Buckminster depends?
What external components or systems does Buckminster require?
What SCM products does Buckminster support?
Benefits
Who is Buckminster for?
What are Buckminster's key benefits?
Legal and Stuff
How is Buckminster licensed?
Why is the Project called "Buckminster"?
Contact Project Owner
What is Buckminster?
Buckminster is a set of frameworks and tools for
automating build, assemble & deploy (BA&D) development
processes in large, complex or distributed component-based development
projects. Buckminster allows development organizations to define
fine-grained "production lines" for the various stages in software
production - for example, unit testing, integration testing, field
deployment, staged migration, etc. - and to automate the execution of
the relevant BA&D processes.
Why does Buckminster exist?
Manual execution of BA&D processes is hugely
resource-intensive in large and/or distributed development
organizations. The burden expands exponentially with the size and
complexity of the development organization and component base and as
the frequency of system change increases. In the past, resource costs
associated with BA&D processes have acted as a check on the ability
of development organizations to respond to changing technical, market
or customer requirements. Moreover, BA&D overhead has made true
component-based development costly to the point of impracticality,
forcing development organizations to collapse componentized code bases
back into monolithic structures.
Existing IDEs and source code management (SCM) systems
take a fragmented approach to managing BA&D processes in
component-based development, leaving ISVs and large development
organizations to either smith their own tools or do without.
Buckminster exists to address these problems. Its goal
is to achieve manageable reuse of software in distributed development
environments where components originate in diverse, independent and
frequently changing code streams.
What is the history of the Buckminster Project?
Buckminster results from well over a decade of
developing component-based systems in multi-site environments and a
deep interest in software configuration management. Initially, we just
set out to solve the typical process problems we encountered working
with monolithic code bases' patch problems, lengthy builds, version
incompatibilities, difficulties tracing bugs and design flaws.
Perhaps because we assigned more senior architectural
resources to the problem, or perhaps because we just developed a
"passion" for process perfection (or both), we went farther and deeper
with these issues than the typical development organization. Software
CM products generally did a poor job when it came to managing code
bases comprising merging component streams. So we essentially built our
own component configuration management (CCM) domain' comprising some
code and lots of process-on top of the leading commercial CM product.
The real breakthrough was when we started a venture in
early 2000 to build a platform for next-generation software production
that has evolved into The Frameworx Project. We wanted to simplify and
rationalize the process of producing and changing applications that
were a specialization of a more generic set of functional components.
For example, this would allow an application vendor to deeply customize
its application for individual customers without having to manage each
customer as a separate code base. Similarly, an ISV could swap out
components in a SOA in a controlled fashion, without undue disruption
to its installed base.
We realized that the investment we had made in
automating our own internal development processes - sophisticated
BA&D frameworks, software CM and a heavy investment in our own CCM
- provided the blueprint of the solution. Buckminster is essentially a
further generalization and productization of that investment.
What exactly is Component Configuration Management?
Component Configuration Management (CCM) is traditional configuration management interwoven with component-based thinking.
Service-oriented (or component-based) development
requires version and configuration control not just of individual
files, as in traditional CM, but also of the components - structured
groupings of files - comprising the larger product or system.
Components undergo repeated transformations or "state changes"
throughout the development and maintenance lifecycle. The larger system
or product is repeatedly reassembled and deployed as components are
transformed. The result is configuration complexity and organizational
and operational overhead.
The CCM discipline addresses this complexity by
promoting recurrent values of architectural quality, reuse &
repeatability, flexibility and scalability.
What is the scope and ambition of the Buckminster Project?
The Buckminster Project's mission is to create open source frameworks and tools that:
-
complement the existing IDE and software CM domains
-
to support an integrated, comprehensive and low-overhead approach to BA&D aspects of software production
-
providing support for large, distributed development
organizations producing complex and frequently changing component-based
systems.
How does Buckminster relate to The Frameworx Project?
Buckminster has no technical dependencies on other
components originating in the Frameworx Project, and can be used to
build, assemble and deploy nearly any multi-component system.
However, the objective of the Frameworx Project is to
develop frameworks and tools for producing service-oriented
applications. So true SOA and BA&D efficiently are inseparable in
practice. Service-oriented architecture implies fine-grained
componentization, which is impractical without BA&D efficiency.
What functional units does Buckminster comprise?
Buckminster currently comprises two key functional
elements which work together to automate complex, distributed
component-based BA&D processes.
The first is the Assembly Manager (AM) framework, an
elaborated build tool that implements component CM ideas and processes
and uses the Ant tool
for the build-related tasks. The key concept in AM is an "assembly
line" approach to maintaining a stepwise build process, with support
for persistent and reusable component states after each step. The AM
framework is intended to support automation of nearly any conceivable
BA&D process, from unit test to staged production migration.
The second functional element is Component Configuration
Broker (CCB), which is essentially an intelligent repository of
versioned component dependencies and compatibilities used to generate
valid configurations of components (i.e. those that are known or tested
to result in buildable and fully function systems). Configuration
Broker manages the complexity that arises when assembling frequently
changing, n-dimensional component streams, typically from multiple
sources, into one or more production configurations.
What exactly does Buckminster do?
Following is a summary list of the basic functionality Buckminster can support:
Assembly Manager
-
Concise handling of configuration descriptions
AM has a succinct, extendable and very flexible way to describe a given
mix of components. It can describe use of volatile component mixes
directly in a file system, as stable/unstable versions of components
residing in an SCM tool, or as highly secure components available
through the web.
-
Version control tool integration
AM can help extract components from an SCM tool based on the configuration description.
-
Unique assembly line paradigm
AM can manage a build/transformation of many components through an
"assembly line", or sequence of steps. The process can be stopped after
any step and restarted a different time or site, without loss of
component state or other context. (One example would be a continuous
process that pauses when an installation CD is burned and resumes when
field installation begins.) Moreover, tracking information can be
recorded to help backtracking in case of later problems.
-
Minimized component coupling
Components follow simple rules that control their behavior. They can
express dependencies, and be assured that AM will run them separately
in the correct order. By adherence to build rules, and support for
build instructions by external reference, components remain
location-independent. This allows the user/AM to switch states in the
background - for example, to present a pre-built state instead of a
source state. This cuts build times, and makes repeatability much more
achievable.
Component Configuration Broker
-
Registration of existing component states
CCB will allow independent third parties to register the availability
of any number of component states. Much information can be extracted
automatically from the states themselves (such as raw dependencies,
backtracking information, etc.), but other pertinent information can be
added and maintained over time (for example, observed version
compatibility/incompatibility).
-
· Queryable component state database
Registered states can be searched for through any available
information, e.g. through a functional perspective or a content
perspective.
-
"What-if" analysis support
After finding a state having some specified characteristic, the system
can generate a suggested state configuration based on available data.
The user can edit the suggestion and immediately see the consequences
of the changes - for example, new/removed dependencies,
possible/impossible.
What is OUTSIDE the scope of the Buckminster project?
Buckminster does not try to be a traditional SCM tool.
For almost all version-handling, Buckminster relies on the user having
a regular SCM tool available for that function, as well as an
established process to follow.
However, there are a few exceptions:
-
AM can help extract components from the CM system based on information in the configuration description.
-
Buckminster defines a specialized secure component
state format called CSAR that offers functionality for persisting a
component state.
What products or technologies are most comparable to Buckminster?
A large number of both commercial and open source build
tools are available. These are narrower in scope and ambition than
Buckminster. (Buckminster's Assembly Manager is based on the best-known
Java build tool, Ant).
A newer tool, Maven, raises the abstraction level above that of the typical build tool, and adds development process management support.
However, we believe that Buckminster is more ambitious
in architectural and functional scope and extensibility - for example,
its concept of configurable "assembly lines", persistable component
states and the coupling of CCB and AM - and will in many cases be more
adaptable for larger scale development projects.
What are the key technologies on which Buckminster depends?
Buckminster is implemented in Java, and thus depends on
a Java environment - with JDK 1.4 currently required as a minimum.
Buckminster runs on both Windows and Unix platforms, and though
untested, should also run on Linux and in any other Java environment.
Important to note is that AM has NO dependency on any specific
implementation technology (i.e. language) for the components on which
it operates.
Buckminster embeds two other open source projects: Ant, as the build engine; and Log4j,
for internal logging purposes. Depending on Ant tasks used, builds may
have other dependencies. On Unix, and in some cases on Windows, a
standard Perl installation is required for purposes of startup wrappers.
What external components or systems does Buckminster require?
Depending on viewpoint, Buckminster requires a lot...or a little.
First, Buckminster requires some effort from users to
become truly useful, although it is possible to start off small &
simple. A detailed understanding is required in order to design and
produce reusable components and create relevant assembly lines, etc.
Although not a formal dependency, use of some SCM system
will be essential to attaining practical benefits from Buckminster in
any significant development effort.
What SCM products does Buckminster support?
Assembly Manager uses a plug-in implementation of a
'RepositoryHandler' interface for SCM system integration. Currently, AM
comes with handlers for a plain file system or CVS, as well as its own
specialized CSAR (Component State Archives) version/state storage
system.
In the future, handlers for other systems, such as
Subversion, Perforce and ClearCase (Basic and UCM), will be provided.
(We have removed our own internally deployed ClearCase
implementation for the public release of AM.) Specialized handlers may
be needed for development organizations with proprietary wrappers
around CM systems that would otherwise be supported, although such
handlers generally should be straightforward to write.
Who is Buckminster for?
Buckminster was designed for large or complex
development projects, measured in terms of number of developers, number
of development sites, number of production installations, size of the
component base and frequency and degree of component change. In theory,
anyone could use it, although the benefits to individual developers or
quick one-off development projects would probably not justify the
effort.
Note that our definition of "large or complex" is
qualitative, rather than tied to any specific numeric thresholds. The
best litmus test for whether Buckminster is a fit is whether the
development organization believes that BA&D process efficiency is
an issue. If it is, then we would hope that Buckminster can help.
How is Buckminster licensed?
Buckminster, like other software initiated within The
Frameworx Project, is available under "Apache-style" (BSD-based)
licensing.
Why is the project called "Buckminster"?
Like other projects originated by the Frameworx Project,
Buckminster is named after a "famous dead architect". In Buckminster's
case, this is R. Buckminster Fuller, an architect, engineer and
visionary best known for inventing the geodesic dome. In contrast to
conventional architects, Fuller was more interested in structural
efficiency, mass-producibility and utility than aesthetics. We felt
that this best fit the scope and vision of the Buckminster Project.
"When I'm working on a problem, I never
think about beauty. I think only how to solve the problem. But when I
have finished, if the solution is not beautiful, I know it is wrong."
R. Buckminster Fuller.
For more on Buckminster Fuller, see www.bfi.org.
|
