Fork me on GitHub

OfficeFloor Architecture

The OfficeFloor architecture is based on design patterns observed in an Office. While OfficeFloor respects technical design patterns, OfficeFloor looks at the evolved "real world" patterns people intuitively understand for organising information and servicing requests. This is reflected in the various Sources within OfficeFloor.

The name OfficeFloor comes from this focus.

OfficeFloor Architecture

The architecture for OfficeFloor has three distinct layers.

  1. Graphical Editors that populate the models configuring the Sources.
  2. OfficeCompiler which compiles the configured Sources into the OfficeFrame.
  3. OfficeFrame which is the runtime to execute the functionality of the Sources.

Graphical Editors

The OfficeFloor graphical editors are plugins to the Eclipse IDE. They utilise the OfficeCompiler to compile the Sources into 'types'. These 'types' are then graphically configured together by the Eclipse Plug-ins to make up the OfficeFloor configuration.

Further information can be found in the Eclipse UI module.


The OfficeCompiler loads the Sources into the OfficeFrame. It takes care of validating 'type' compatibility between the Sources so that the constructed application is type safe.

Further information can be found in the OfficeCompiler module.


The OfficeFrame is the core of the Job Based Architecture that gives OfficeFloor its flexibility and performance. It simplifies the functionality of an application into Jobs where each type of Job is executed by a particular Team.

Further information can be found in the OfficeFrame module.


Sources are the buliding blocks of OfficeFloor. The term Source is used in two ways:

  • source of an item
  • source to be compiled

The first meaning is to provide an object for use. In this sense a Source is like a javax.sql.DataSource to a java.sql.Connection.

The second meaning is to enable the Source to be compiled into a type. The ability to provide a type allows both validation and configuration of the Sources into an application.

There are different sources that provide distinct responsibilities to an application.

In building OfficeFloor web applications, WoOF (Web on OfficeFloor) provides many pre-built Sources that only require configuring. Also the automagic dependency and thread injection used by WoOF and the WoOF specific graphical editors reduce the need to understand each Source in detail.

The following table lists the Sources within OfficeFloor.

Source Description
TeamSource Provides thread pools for execution of jobs. A thread pool is known as a Team within OfficeFloor.
WorkSource Provides a grouping of tasks that contain application functionality. There may be many work types within an OfficeFloor application and each task is a job. The easiest means to understand work is to relate it to a class - the Work is the object, while the Tasks are the methods of the object.
ManagedObjectSource Provides objects that are made available to tasks. The objects are such things as java.sql.Connection, javax.jms.Message, java.nio.channels.SocketChannel (objects you would dependency inject).
SupplierSource Supplies multiple ManagedObjectSources for use. This allows grouping Managed Objects together under under simplier configuration. An example of use is integrating with Spring to supply a Managed Object for each Spring bean within a BeanFactory.
GovernanceSource Provides context for tasks to be run within. Typical use is specifying the transaction management over the tasks.
AdministratorSource Provides duties which can be weaved between tasks. This allows for Aspect style functionality to handle such things as checking access permissions before executing a series of tasks. Each duty is a job.
SectionSource Configuration of how the Work and Managed Objects are connected together. Sections may also contain other sections to break down configuration into managable encapsulated detail. Typically this is represented graphically so that all stakeholders can work together on these diagrams to ensure the requirements for the application are being met.
OfficeSource Configuration of an application. An application is known as an Office within OfficeFloor. An Office provides the details of how the Sections are connected together. It also specifies the Governance and Administration of tasks along with assigning Teams responsible to execute the respective tasks/jobs. The reason for Governance, Administration and Team assigning within the Office is to abstract this away from Sections so that the stakeholders can focus on application functionality rather than being caught up with these aspects.
OfficeFloorSource Configuration of deploying applications. It is also where this project got its name. An OfficeFloor may host many Offices where each Office is made up of many Sections. The OfficeFloor allows tuning the Offices to the hardware/network it is running on by specifying the physical Teams and Managed Object Sources of the Offices. For example, non-blocking jobs could be assigned to a single threaded Team to reduce thread contention.