Design Patterns For BIM-based Service-Oriented Architectures
Design Patterns For BIM-based Service-Oriented Architectures
Automation in Construction
journal homepage: www.elsevier.com/locate/autcon
a r t i c l e i n f o a b s t r a c t
Article history: Today Integrated Project Delivery together with Building Information Modeling is being realized as a process
Accepted 18 April 2012 of managing a project over a single shared information backbone. In the near future, Building Information
Available online 17 May 2012 Models (BIMs) will be used as unique resources for enabling seamless data level interoperability, which
will greatly facilitate the processes in the Building Life Cycle. In this context, enabling the collaborative use
Keywords:
of BIMs is becoming essential and is much required by the industry for addressing the issues associated
BIM
REST
with the poor efficiencies in Information Systems (IS) and productivity. On the other hand, in the new IS ar-
SOAP chitectures, service and resource orientation are becoming widely used, in terms of supporting collaboration
AJAX over distributed environments. This paper introduces three design patterns which will help in facilitating
Integration BIM-based information sharing over the web, and web-based collaborative use of the BIMs. The patterns
Web services were developed to formalize the approaches in interacting with the shared BIMs over the web. The first pat-
tern – BIM AJAX – explains how AJAX techniques can be used for supporting information retrieval from BIMs.
The second pattern – BIM SOAP Façade – provides a standard coarse-grained interface to reach multiple BIMs
over the web. The third pattern – RESTful BIM – elaborates on how BIM-based systems can benefit from the
REST (Resource Oriented) Architectures. The paper starts with providing an overview on Building Informa-
tion Models focusing on their characteristics and functions. Following this, the conventional approaches for
exchanging and sharing BIMs are presented. The third section elaborates on IS Integration, AJAX and Web
Services. Finally, three design patterns that have been developed are presented and discussed in detail.
© 2012 Elsevier B.V. All rights reserved.
1. Introduction and discovered [1]. Currently, the developments in Internet and soft-
ware technologies has resulted with the emergence of service-
Building Information Modeling has become a major research area oriented architectures that make it possible for distant applications
within the AEC industry for addressing the problems related to infor- to inter-operate (i.e. use the functions of other software components
mation integration and interoperability. The main reason behind the as if they were its own functions) by making use of their standard
introduction of Building Information Models (BIMs) was enabling web interfaces. The service orientation (and web services) allow
seamless exchange and sharing of information and interoperability loose coupling of applications over the web, which means several ap-
between various different applications used in the AEC industry and plications can communicate and interact with each other without the
throughout the lifecycle of the building. Currently, Building Informa- need of knowing the details of their working environment. Each of
tion Modeling is being realized as a process of managing a project these applications (or software components) which take part in
through a single shared information backbone, where BIMs (the such a web interaction as a data, component or an application service
models) act as the key resources in enabling data and information is known as a web service.
level interoperability. Currently, service-oriented architectures are becoming de-facto
Today, service and resource orientation are becoming widely used standards for web based application integration. The use of W3C's
for supporting collaboration over distributed environments. In this web services is expanding rapidly, as the need for inter-application
context, a web service can be defined as “a software component or in- communication and operability grows. Organizations can benefit from
terface designed to support machine-to-machine interaction over the service oriented architectures by integrating services developed inter-
Internet”. The web service should have a web interface described in a nally and externally to the company, along with providing a standard
machine-processable format. A service-oriented architecture can be means of communication among different software applications run-
composed with a set of interacting components (i.e. services) which ning on a variety of heterogeneous platforms through the Internet [2].
can be invoked, and whose interface descriptions can be published
1.1. The requirement for model based web services
⁎ Tel.: +90 536 434 77 37, +90 312 266 00 62; fax: +90 312 266 00 52.
E-mail addresses: [email protected], [email protected], umitisikdag@ Although today the main trend in the software industry is towards
beykent.edu.tr. enabling interoperability over web services, the AEC industry still is
0926-5805/$ – see front matter © 2012 Elsevier B.V. All rights reserved.
doi:10.1016/j.autcon.2012.04.013
60 U. Isikdag / Automation in Construction 25 (2012) 59–71
not making full use of the service-oriented architectures, as the inte- the web. The first pattern makes use of standard JavaScript/XML
gration focus of the industry is still at the data level (i.e. towards en- requests to communicate with the BIMs over the HTTP protocol,
abling integration by making use of file exchanges and shared data while the latter two make use of web-services approach to interact
stores). In contrast, the recent research in the field [2–4] addressed with the BIMs. The following section of the paper provides a summary
the importance of the use of web services in integration of AEC of the background, while the latter sections of the paper elaborate on
models (i.e. BIMs) and propose [2] the integration of service- the patterns defined.
oriented, model-driven and model-based architectures to enable effi-
cient use of AEC models/BIMs in collaborative environments. Addi- 2. Building Information Models
tionally, recent research suggests that (semantic) web services will
also play a key role in enabling semantic integration and interopera- 2.1. Definition, characteristics and functions
bility, while facilitating service-oriented model-based architectures
[5–7]. For example, Christiansson et al. [6] state that among the The Integrated Project Delivery (IPD) approach which recently
most important barriers to efficient ICT implementation in the AEC emerged in US reflects the globally shared vision of the project life-
industry are missing ontologies, both on business and Web/Internet cycle management and project delivery in the AEC industry [10].
services levels. According to Akinci et al. [5] semantic web services IPD encourages early contribution of knowledge and experience to
can serve for enabling multi-domain (CAD/GIS) interoperability at se- the project and requires proactive involvement of key participants.
mantic level. Rezgui et al. [7] mention that the AEC industry should The IPD Working Definition [11] states that Building Information
migrate from data-centric application integration to ontology-based Modeling is essential in enabling the collaboration required for
integration, and proposes inter-enterprise collaboration architectures achieving the IPD. Input from an integrated team coupled with BIM
and frameworks based on semantic web services, to enable ontology tools (to model and simulate the project) enable the design to be
based integration. In addition, recent AEC visions on ICT such as brought to a higher level of completion even before the documenta-
ROADCON [8] and Strat-CON [9] view model-based web services as tion phase commences. Thus, in IPD the project is defined and coordi-
the sine-qua-non for the future of AEC systems integration. nated to a much higher level prior to the start of construction,
To summarize, both integration approaches envisioned for the enabling more efficient construction and a shorter construction peri-
AEC industry as; i) enabling service-oriented model-based architec- od. As mentioned in Underwood and Isikdag [10], from an Integrated
tures and ii) integration based on semantic web services, relies on Project Delivery perspective Building Information Modeling can be
the web-services and service oriented architectures. Thus, based on defined as:
the recent research and recent ICT visions for AEC industry, it is ap-
“the information management process throughout the lifecycle of
parent that implementing model-based or semantic web services
a building (from conception to demolition) which mainly focuses
will be required for accomplishing (model based and semantic
on enabling and facilitating the integrated way of project flow
level) systems integration for the AEC industry in the very near
and delivery, by the collaborative use of semantically rich 3D dig-
future.
ital building models in all stages of the, project and building
lifecycle”.
1.2. The method
Although Building Information Modeling is viewed as the key en-
The study presented in this paper is focused on supporting and fa-
abler of the IPD process, Building Information Modeling goes beyond
cilitating AEC systems' interoperability through model-based web
the management of information in the IPD process in that the IPD
services. The presented research aimed to define a set of patterns
process concludes with the closeout stage following construction,
for facilitating service-oriented model-based architectures and
while the BIM process continues even beyond the demolition (dispo-
service-oriented model-based interoperability in the AEC industry.
sition) stage, i.e. as a process of knowledge management for future
The objectives behind the development of the patterns were increas-
projects. The Building Information Modeling process is unique as it
ing the efficiency in interactions with BIMs, via making use of service-
is based on digital, shared, integrated and interoperable BIMs. Thus,
oriented architectures, and by this way, enabling and supporting the
while Building Information Modeling is be defined as the process
efficient representation and visualization of BIMs (on the user-side),
and facility that enables information management, a Building Infor-
through facilitating flawless human–computer interaction regardless
mation Model can be defined as,
of user environment.
The research approach implemented involves a triangulation of “the (set of) semantically rich shared 3D digital building model(s)
literature/technology reviews and pattern development exercises. that form(s) the backbone of the Building Information Modeling
The focus of the first research stage was on re-visiting the base con- process”.
cepts related to BIMs and approaches to the sharing and exchange
of the models. The study continued with a review on the methods BIMs are known as data-rich, object-oriented, intelligent and
of systems integration. The technology review involved in the re- parametric digital representations of the facility, from which views
search covered the evaluation of technologies for establishing and and data appropriate to various users' needs can be extracted and an-
implementing service-oriented architectures. Two main architectural alyzed to generate information that can be used to make decisions
styles of service-orientation i.e. SOAP and REST were investigated and improve the process of delivering the facility [12]. Further defini-
along with AJAX technology, in the second stage. The final stage of tions of Building Information Modeling and Building Information
the research involved the definition of web-service patterns based Models (BIMs) can be found in [13,14]. In these sources Building In-
on i) AJAX, and ii) in two architectural styles that were investigated. formation Modeling is referred as a new way of creating, sharing, ex-
The first pattern – BIM AJAX – explains how AJAX techniques can changing and managing the information throughout the entire
be used for retrieving information from BIMs. The second pattern – building lifecycle.
BIM SOAP Façade – focuses on enabling interoperability through a Isikdag et al. [15] have identified the definitive characteristics of
standard web interface in an object-oriented nature. On the other Building Information Models as being; in 3D, object-oriented, com-
hand, the third pattern – RESTful BIM – concentrates on enabling in- prehensive, spatially-related, semantically-rich, and open-to-view
teroperability through a stateless web interface in a resource- derivation. Depending on the environment, Building Information
oriented nature. The three patterns presented address three different Models can have different functions such as being a Space Linker
model-based mechanisms that can be used to interact with BIMs over that links macro and micro urban spaces, an Interoperability Enabler
U. Isikdag / Automation in Construction 25 (2012) 59–71 61
which facilitates information sharing between various stakeholders the implementations in SABLE project [3], the future scenarios related
and the software applications they use, a Data Store which stores the to BIM integration tested in Open Geospatial Consortium's OWS-4 re-
building information throughout the lifecycle of a building, a Procurement search [4], SOA4BIM framework proposed [2], and open source BIM
Facilitator that facilitates several procurement related tasks in the build- Server supporting service-oriented architectures [20], clearly indicates
ing lifecycle, a Collaboration Supporter through enabling the use and man- that in the very near future, BIMs will be used within service-oriented
agement of shared building information in real-time, a Process Simulator architecture (BIM SOA) frameworks and, BIM web services will become
by facilitating the simulation of construction processes (i.e. in the nD the inevitable integration and operation requirement for the informa-
simulation space), a System Integrator which enables the integration of tion systems in the AEC industry.
several information systems across the industry, a Building Information
Service which can serve real-time on-demand building information 3. Integration, web services and AJAX
over the Internet, a Green Design Enabler that enables advanced analysis
supporting the design and construction of environment friendly/energy Systems integration can be defined as a strategic approach for
efficient buildings, and a Life Saver which facilitates key tasks in emer- binding many information systems together in order to support
gency response operations. Today, the current key standardization ef- their ability to exchange information and leverage processes in real
forts in the area of BIM are the Industry Foundation Classes (IFC; ISO time [21]. The literature review in the area of software systems inte-
PAS 16739) [16] and the CIMSteel Integration Standards 2 (CIS/2) [17]. gration highlighted two main approaches to integration [21–25]. The
first approach Information Integration allows data and information to
2.2. Sharing and exchange: the conventional methods move between source and target systems without involving the ap-
plication logic of the systems. Methods for Information Integration
A BIM is defined by its object model (i.e. the BIM schema). The object can be classified into 3 different categories as Data and Information
model of the BIM is the logical data structure (or data model) that de- Exchange methods, Data and Information Sharing methods, and
fines all entities, attributes and relationships in the BIM. The model Data Transformation methods. In Information Integration, a funda-
data is generated by an application (usually by a CAD or Building Infor- mental question for deciding on whether to exchange or share infor-
mation Modeling software) and either stored in physical files or in da- mation is “How much effort would it take to move data from the
tabases. Conventional approaches for exchanging and sharing BIMs source system to the target system?” [26]. If a few applications re-
includes the following [15,18]: quire information from the source data, then the data exchange is ad-
vised, otherwise (i.e. when numerous applications require the use of
same information) data sharing should be chosen as the integration
File exchange: Physical file exchange of BIMs is carried out by ex-
method. Transformation can be required in both exchange and shar-
changing a physical file of the BIM through the transfer of the
ing scenarios.
file either by using physical mediums (e.g. flash drive), or using If the target information system would not be able to replace the
computer networks (e.g. Intranets and Internet). The physical functionality of the source system (although it contains sufficient
file is usually generated by a CAD application and can be ex- amount of source systems' information) as the result of an Informa-
changed among various applications. The BIM physical file can tion Integration effort, then the systems should be integrated using
be an XML file or an ISO 10303 Part 21 file. For example currently Service and Application Integration methods.
IFC Part 21, CIS2 Part 21, and IFC XML physical files are exchanged Even though the AEC industry is currently focused on Information
among various CAD, Structural Analysis and HVAC software. Integration, the necessity for Service and Application Integration is con-
Application interfaces: The BIM physical file can be accessed using stantly increasing as the functionalities of CAD/BIM applications di-
verge every day and sharing data between them is not usually
an Application Programming Interface (API). This approach focus-
found sufficient to replace the functionality provided by one another.
es on data sharing rather than exchange, and generally occurs in a
Service and Application Integration allows integration through in-
two-tier architecture where one tier is formed by an API. The API
teraction of system components. Methods for Service and Application
can be proprietary for the BIM it is defined for, or it can be the Integration can be classified in 4 different categories as Remote Proce-
Standard Data Access Interface (SDAI) API (if the BIM is defined dure Calls, Messaging, Distributed Objects, and Web services and Por-
by using ISO 10303 description methods). If the physical file is tals. In parallel with the context of the paper, the following sections
an XML file then the model can be shared using the XML interfaces will elaborate on integration with web services.
(i.e. APIs supporting Document Object Model — DOM). The com- In addition to the definitions given in the previous section, a web
mercial/open source implementation of these APIs for IFC BIMs service can also be defined as “a resource that can either be invoked
are known as, IFC plug-ins, IFC add-ons, IFC Engine DLLs, IFC over the web or reached by standard web interfaces using standard-
Tools, IFC Toolboxes and so on [19]. ized messages”. Web services provide standard web based interfaces
to legacy and current applications, in order to enable them to ex-
Shared databases: Shared databases can store data that covers
change data by standard protocols and expose their functionality
many aspects of the AEC life cycle. The advantage of storing the
over the standard web based interfaces.
BIM in a shared database is that multiple applications can access He [27] indicated that two constraints exist for implementing the
the model data, and make use of the database features such as Web services: i) Interfaces must be based on Internet protocols such
query processing and business objects creation. The BIMs can be as HTTP, FTP, and SMTP and ii) Except for binary data attachments,
stored in a relational or mostly in an object database system. messages must be in XML. Two definitive characteristics of web ser-
BIM schemas can be XML schemas (XSD) or ISO 10303 EXPRESS vices are loose coupling and network transparency [28].
schemas. The database can be populated by importing a physical Loose coupling: in a traditional distributed environment computers
file of the model (i.e. an XML file or a Part 21 file), or creating en- are tightly coupled, i.e. each computer connects with others in the dis-
tity instances by using standard (i.e. ODBC) or proprietary (i.e. tributed environment through a combination of proprietary inter-
faces and network protocols. Web services in contrast, are loosely
SDAI) database interfaces. The model data can then be queried
coupled, i.e. when a piece of software has been exposed as a web ser-
using the database interfaces.
vice, it is relatively simple to move it to another computer.
Although the use of conventional methods has been encouraged for Network transparency: as web services' consumers and providers
many years and by most software vendors, recent research including send messages to each other using the open Internet protocols, web
62 U. Isikdag / Automation in Construction 25 (2012) 59–71
services offer total network transparency to those that employ them. portrays a commonly recurring structure of communicating compo-
Network transparency refers to a web service's capacity to be active nents that solves a general design problem within a particular con-
anywhere on a network or group of networks without having any text [32,33]. A pattern can be characterized as the template for a
impact on its ability to function. As each web service has its own Uni- solution a software design problem or as a defined and recognized
versal Resource Indicator (URI), web services have similar flexibility formalization of interaction between the software components for
to websites on the Internet. fostering a better software design. The use of patterns in software
Two styles of Web services exist today: SOAP and REST. SOAP is a design help software developers in design decisions, i) when they
web service style based on using Simple Object Access Protocol for ex- face commonly observed problems in the design of their new soft-
changing XML formatted messages between the networks by using Hy- ware, or ii) when they would like to introduce new ways of interac-
pertext Transfer Protocol (HTTP). REST, is an architectural style where tion between the different layers or components in their design.
the web service operates by calling various web-resources. Although design patterns for formalization of the Model-View-
Controller (MVC) type of architectures exist in the literature [34],
Simple Object Access Protocol (SOAP): Today, the SOAP has become formal architectures that support the use of model-based web ser-
the lingua franca of the web services. The principle of the SOAP is vices, is not common for the AEC industry software. Thus, once rec-
remote invocation of methods based on messages sent over the ognized, patterns explained here can aid in implementation of
web. SOAP protocol has two constraints: i) Except for binary formal architectures for model-based web services to facilitate
data attachments, messages must be carried by the SOAP and for- service-to service/application-to-service interactions within AEC
matted by the rules of it, and ii) the description (exposed inter- software.
face) of the service must be defined in Web Services Description Conventional approaches for sharing and exchanging information
Language (WSDL, i.e. the XML based language used to describe models in AEC industry, e.g. by using BIMs (as explained in the previ-
ous section) are mostly focused on exchanging a physical file between
and locate a SOAP web service).
applications and using shared central databases to perform CRUD
Representational State Transfer (REST): The terms REST and RESTful
(Create/Read/Update/Delete) operations on these models (i.e.
web services have been coined following the PhD study of Roy BIMs). Furthermore, today the use of Model Views (i.e. subsets of
Fielding [29]. As explained by Pautasso et al. [30], REST was origi- BIM defined according to needs of a specific information exchange
nally introduced as an architectural style for building large-scale scenario) is encouraged for facilitating the BIM-based information
distributed hypermedia systems. According to REST style, a web management throughout the entire lifecycle of a building.
service can be built upon resources (i.e. anything that is available Recent R&D efforts such as SABLE [3] and BIMServer [20] have
digitally over the web), their names (identified by uniform indica- shown that it is possible to use SOAP/REST style web services for ac-
tors, i.e. URIs), representations (i.e. metadata/data on the current quiring information from BIMs. Using service-oriented approaches
state of the resource) and links between the representations. The for acquiring information from BIMs will help the AEC industry appli-
cations in replacing the functionality of one another, when only shar-
principle of REST is sending remote calls to — representations of
ing data would not be sufficient (for them) to truly inter-operate (i.e.
the web-resources.
perform the function of another system as if that function is its own).
Most of the web services that are currently implemented have Although the literature in the field illustrates examples of the use
transformed from interfaces of the legacy systems. As mentioned in of shared (central) databases and SOAP style web services to obtain
Pulier and Taylor [28], exposing a web service mostly involves en- information from BIMs, there has been no efforts on formalizing the
abling the older software (or the data layer of the legacy system) to i)sharing of a distributed BIM and ii) information acquisition from
receive and respond to web message requests for its functionality. the shared BIM over the web. Although making use of distributed
Although AJAX techniques cannot be classified as an integration BIMs might seem difficult technically (i.e. as this might cause prob-
method, AJAX technology can also be used to facilitate web based in- lems regarding versioning and ownership), if managed successfully,
teractions, and the use of AJAX in retrieving BIMs over the web can it will provide significant benefits as it will, contribute to the level
accelerate the time behavior of BIM based systems. AJAX (i.e. asyn- of interoperability in AEC applications, prevent information overload
chronous JavaScript and XML) is the general name given to a group in shared databases, and enable efficient use of hardware and net-
of web development techniques mainly used on the client-side. work resources.
According to Garrett [31], AJAX incorporates, i) dynamic display and The following sections focus on three integration patterns proposed
interaction using the DOM, ii) data interchange and manipulation in this study for formalizing — BIM based web service architectures.
using XML and XSLT, iii) asynchronous data retrieval using These patterns are based on; AJAX techniques, SOAP and REST style
XMLHttpRequest and iv) JavaScript binding everything together. An web services, which currently appear as mainstream approaches. The
AJAX application eliminates the start–stop–start–stop nature of inter- first pattern suggests that the use of AJAX techniques – in interaction
action on the Web by introducing an intermediary – an Ajax engine – with and visualization of BIMs – will facilitate the communication in
between the user and the server. Instead of loading a webpage at the web-based collaborative environments. The second (SOAP style) pat-
start of the session, the browser loads an Ajax engine — written in tern explained will make it possible to efficiently manage a BIM and
JavaScript. This engine is responsible for both rendering the interface Model Views using standard set of web interfaces and messages. The
the user sees and communicating with the server on the user's behalf, third (REST style) pattern will enable the exposition of all objects in a
and allows the user's interaction with the application to happen asyn- BIM as a set of web resources and representations. This exposition will
chronously — independent of communication with the server. enable the users to acquire information directly from every object in
the BIM without the need for knowing where, how and in what form
4. The patterns the BIM is stored.
A software design pattern is identified by its two implicit roles. 4.1. BIM AJAX pattern
First, a pattern denotes a problem that usually occurs in design and
implementation of software (i.e. the requirement for the pattern) 4.1.1. The requirement and purpose
and then it describes the solution to that common problem in such Current off-the-shelf BIM visualizations on the web uses client/
a way that — it can be reused in many different situations (i.e. in server model of computing for interacting with BIMs. The current
many software development efforts). A software design pattern practice in the client/server model is using a shared database or a
U. Isikdag / Automation in Construction 25 (2012) 59–71 63
BIM (model) server for storing the model. The interaction with the the object-in-focus in the graphic model. This approach would elimi-
model is accomplished through the Call Level Interfaces (APIs) of nate the need for deployment of a BIM Server product (for the quick
the server. Some recent efforts in the area such as the open source visualizations which only require the semantic–graphic representa-
BIMServer project [20] also provide SOAP and REST interfaces for tion of the model), and furthermore will enable a rapid client–server
interacting with the Building Information Models. interaction in environments with multiple users, as the server-side
In contrast with the developments on the server-side, today the structured queries would not be required in this situation.
web-based (i.e. client side) visualization of BIMs is rarely observed as
the client-side visual representations is difficult, due to large file size 4.1.2. The pattern
of the models to be transferred to the client. First of all, sending the As illustrated in Fig. 1, according to the proposed system architec-
whole model (as a BIM physical file) to the client (for visualization pur- ture in the BIM AJAX pattern, an XML representation of a BIM (e.g. an
poses) is a very time consuming task for many of the BIMs in use (i.e. the IFCXML file), will reside in a web server. The web server in this pat-
file size of most of these models are between 10 and 50 MB). To tackle tern refers to a standard HTTP server that is capable of responding
this, the visual representation of the model (with a smaller file size) is to AJAX Requests (i.e. not to a product specifically developed for man-
usually transferred to the client as a graphics file such as a COLLADA aging BIMs). The AJAX Engine on the client-side will allow the user's
or X3D document, in fact, in this situation it is not possible to get infor- interaction with the server to happen asynchronously — independent
mation on the attributes of the objects instantly (i.e. while browsing of communication with the server. The pattern suggests that, an AJAX
through the graphics model), as this representation is only geometric Engine implemented on the client side would eliminate the need for
and do not contain semantic information. performing structured queries on the server side every time (when)
In order to get the semantic information regarding the objects in a piece of information is required regarding a building element. In-
the graphic model (such as the material of a wall) when browsing stead, the required information can easily be transferred to the client
the model (e.g. when one needs to learn the material of the wall by by AJAX technique, and provide the object description to the client
performing a mouse-over action to a wall's graphic representation), side.
a query needs to be sent to a BIM Server regarding the object in- The system designed according to the pattern would operate as
focus, and then the query results can be transferred back to the client follows. In the first stage, as a result of an HTTP GET request, the visu-
for providing this information. Although this is accepted as the opti- alization of the overall BIM will be transferred from server to the cli-
mal solution currently, this solution will require the deployment ent in the form of a graphics file (i.e. COLLADA,X3D, so on). The
and configuration of a specific product (i.e. a BIM Server) on the serv- transfer of graphics file will be rapid, as this (COLLADA,X3D) repre-
er side. In addition, within an environment of 20 collaborative users sentation of the BIM is only geometric. Then, multiple stakeholders
querying the server synchronously for getting information about dif- on the client side can explore the model's graphic representation
ferent building elements, the BIM Server can result in responding ex- asynchronously. Once a user requires semantic information regarding
tremely slow, or may stop responding. a building element (i.e. Wall), the user can interact with the model by
In order to tackle this situation, an AJAX Engine implemented on performing a mouse-over or a mouse-click action. During this interac-
the client side can interact with the XML representation of the BIM re- tion, an asynchronous XMLHttp (AJAX) request will be sent to the
siding on a standard HTTP server, to provide information regarding HTTP server, following this, the information regarding the description
of that specific building element (i.e. Material of the Wall) will be sent on the similar architectural principles. The only difference between
to the client in the form of an XML Response. The description of the them will be that the interface of the SOAP Façades will be defined
selected object will be provided to the user without reloading the in WSDL, which means that the SOAP Façades will be defined as
web page (and thus without re-transferring the graphics file from high level web services that are using low level web services (here re-
server to the client). ferred to as SOAP interfaces). These low level web services can then
This formalization of communication between the client and the interact with any type of system component including files and data-
server ensures that optimal amount of information is sent from server bases. The following summarizes implementation of the SOAP Façade
to the client in each interaction. The asynchronous way of communi- pattern into a BIM-based system architecture.
cation with the server will greatly decrease the time for getting object As seen in Fig. 3, in a system designed according to BIM SOAP Fa-
descriptions in multi-client collaborative environments, as the server çade, the main components would be the Format Conversion Service
and network capacity would not be used synchronously by all users. and the Model Server. The Format Conversion Service is a local or a
Furthermore, as the need for server-side structured queries would web level service which would be accessed via its Local API/Web
be eliminated, the performance of the server will also increase. The API from the BIM applications, or a front-end can provide the
BIM AJAX pattern will be most useful for quick visualizations, in Human–Computer Interaction (HCI) with the Format Conversion Ser-
fact, if a need for performing CRUD operations on the models (over vice. The Format Conversion Service will be used for transforming one
the web) appear, a set of formalized SOAP web services would be re- BIM file format (i.e. CAD DWG; Sketch Design Formats; CIS/2) into an-
quired to perform them. The following pattern elaborates on both other (i.e. IFC). Although many AEC applications support standard
how data transformation and these CRUD operations can be per- model formats (such as IFC), the conversion between different
formed and facilitated in SOAP based architectures. models is still a requirement (as interoperability without the need
of any data transformation is still in its early days for AEC software).
4.2. BIM SOAP Façade pattern The format conversion service can be implemented in the web server
(as an API) or as a web service. The output of the Format Conversion
4.2.1. The requirement and purpose Service would be a physical BIM file, which will then reside in a Model
Currently, BIM based collaborative tools make use of a single Server.
shared database. The use of a single shared database will not be tech- Due to problems related to ownership and management of up-
nically feasible in the foreseeable future, as this will cause informa- dates to the BIM, the storage of BIM itself as a physical file is not con-
tion overload on the shared database (where a model and multiple sidered as good practice when CRUD operations over the models
views will reside) and the overload of network traffic on the server would be performed. Thus, in this pattern it is assumed that the
side. Today, BIM applications are benefiting from shared databases, BIM will be stored/managed within a Model Server environment.
in fact, the increase of the data volume in BIMs, together with the The BIM will reside in Model Servers (i.e. data storage and manage-
need for applications to substitute each other's functions, and the ment environments where CRUD operations over BIMs can be per-
need for collaborative way of working is forcing applications to formed). The Model Views of the BIM can be generated on-the-fly/
focus on Data Transformation and Service Level Integration. An archi- on-demand and stored in the Model Server with the BIM itself, or
tectural pattern to deal with these changes should address data trans- can be stored separately as physical files. The data in BIMs and
formation and provide simple and standard web interfaces to BIM Model Views will be accessed by SOAP Interfaces for performing
applications for performing web based CRUD operations on the CRUD operations. In this pattern these SOAP interfaces are indicated
models. The pattern (BIM SOAP Façade) proposed in the following as low level web services. Finally, the SOAP Façade will act as the
sections focuses on providing the interfaces using the SOAP standard, front-ends of the SOAP interfaces, as it will provide simplified and for-
while suggesting a data transformation operation on the server side. malized methods to interact with BIMs and Model Views. SOAP Fa-
çade will help in reducing the number of SOAP interfaces that the
4.2.2. The pattern client (BIM Software) has to deal with when interacting with the
The idea of providing SOAP interfaces to Building Information models. SOAP Façades will also enable an integrated view of different
Models is not new. The aim of the SABLE project (Simple Access to information models, and BIMs/Model Views (as they can combine the
the Building Lifecycle Exchange) completed in 2006, was to provide interfaces of several information models and model views). The func-
web services, by creating and using domain specific SOAP interfaces tions declared in/exposed by the SOAP Façades will simply interact
to the IFC model [3]. In fact, BIM SOAP Façade explained in the follow- with the BIMs and Model Views to perform CRUD operations and
ing presents a novel approach for interacting with BIM by using SOAP this will eliminate the need for knowing where the BIM resides, or
interfaces. The pattern can be defined as SOAP exposition of BIM in which Model Server the BIM is stored, and furthermore, the users
physical files and databases based on the principles of Façade pattern. and client software would not need to know about the structure or
BIM SOAP Façade pattern will enable the management of distributed the schema of the BIM.
shared BIM databases by making use of SOAP web services. Before For example, a software architecture that is designed in light of
getting any further deeper into the pattern, it might be good to sum- BIM SOAP Façade Pattern will easily fulfill a SOAP request for convert-
marize the principles of the Façade pattern itself. According to the ing a CIS/2 model into an IFC Model by making use of Format Conver-
Gang of Four [32], the Façade pattern provides a unified interface to sion Service without requiring any other information (such as classes
a set of interfaces in a subsystem. As explained in Shalloway and to be queried and transferred, location of the models, how they are
Trott [35], when one needs a new (simplified) way to interact with stored and managed, etc.).
a system (resource) or needs to use a system (resource) in a particu- On the other hand, partial model mapping (e.g. regarding only the
lar way (such as using a 3D software for viewing 2D), the Façade pat- information about the columns of a steel building) can be accom-
tern can be used to build a new method of interaction with that plished by making use of SOAP interfaces and Data Access Compo-
system. Façades can be used not only to create a simpler interface in nents (i.e. the standard APIs of Model Server, or APIs developed for
terms of functions/operations, but also help in reducing the number interacting with BIMs/Model Views such as IFC toolkits or XMLDOM
of software components that a client object must deal with (Fig. 2). APIs) and the end result can be stored as a BIM or a Model View.
The BIM SOAP Façade pattern takes the principles of Façade pat- The BIM SOAP Façade pattern provides easy to use, simplified
tern one step further, i.e. to web services level, and stipulates it for mechanisms for CRUD operations and management of multiple
the BIM applications (Fig. 3). As the Façade classes are generated in BIMs over the web. The only drawback of this pattern is that as the
object-oriented systems, SOAP Façades can also be created depending SOAP interfaces will be developed in parallel with the requirements
U. Isikdag / Automation in Construction 25 (2012) 59–71 65
of the application domain, they will rarely (or never) allow for infor- developed based on the SOAP Interface of the BIMServer. The steps
mation acquisition from every – single – object in the BIM. Thus, an of the development were as follows. Firstly, the SOAP service provid-
application which requires information acquisition from every single ed by the BIMServer is registered as a reference service (Fig. 4), in
BIM object would not be able to reach this information in the SOAP order to generate the SOAP Façade.
Façade architecture, as the operations on the objects is constrained The SOAP Façade usually provides fewer methods than the origi-
by the rules defined in the Façade Interface. For example, an applica- nal BIM Web Service in a BIM Server. In this implementation, a
tion would not be able to query an IFC object based on its ID, if this single-method SOAP Façade is utilized. The single-method of the Fa-
operation is not defined in the Façade Interface. However, the RESTful çade is SetProjectName, and once invoked over the web this Façade
BIM Pattern, elaborated in the following overcomes this drawback of method sets the project name of a BIM Server project to “This is a
BIM SOAP Façade, by providing a method for information acquisition test project”. Following this step, the SOAP Façade service is imple-
from every BIM object. mented on the server-side. The WDSL of the developed SOAP Façade
The validation of the pattern has been accomplished by an imple- is illustrated in Fig. 5.
mentation that is making use of the SOAP interface provided by the In the final step of the validation exercise, the SOAP Façade service is
BIMServer [20]. In the validation exercise, a simple Microsoft Visual used within a simple user form that is used to set the project name
Studio 2010 WCF SOAP Service (that forms a SOAP Façade) is (Fig. 6). Once the user interacts with the user form the project name
will be set to “This is a test project” through the web (i.e. SOAP Façade) BIM is not possible in the SOAP Façade Pattern. Therefore, in order
method invocation. to enable this information acquisition at the object level, the client
software will need the finest-grained interface to BIM (i.e. similar to
4.3. RESTful BIM pattern a database Call Level Interface — CLI) in the web level.
In fact, developing this interface for every BIM and Model View
4.3.1. The requirement and purpose (especially when the model views are at an instance level/dynamic)
As highlighted previously, although the BIM SOAP Facade pattern will be very difficult and require specific program functions to gener-
facilitates i) the transformation of one BIM format to another, and ate SOAP interfaces, i.e. WSDLs, (i.e. covering every class of the
ii) provides a simple single coherent interface to multiple models model) on the fly. One solution to this problem is entirely changing
and views, information acquisition from every single object in the the architectural style by, leaving the SOAP approach and focusing
on the RESTful one, (i.e. a resource oriented approach for creating the databases. The recent technological developments have resulted
finest-grained web interfaces to the BIM and Model Views). This third with interfaces that make it possible to automatically map the entities
pattern, RESTful BIM, focuses on the exposition of all BIM objects as in a relational database to REST resources. Thus, today it is possible to
web resources by making use of the REST architectural style. As this automatically generate REST resources from a Model View that is re-
pattern is based on the principles of the RESTful architectures, it has siding in a relational database. This process is very straight-forward
therefore been called as the RESTful BIM. and simple using REST enablers such as sqlREST [36]. A REST enabler
for relational databases (i.e. sqlREST), once implemented, generates a
4.3.2. The pattern resource for each entity and instance.
As depicted in Fig. 7, the exposition of BIMs as REST style web ser-
vices can be accomplished by several methods.
The first method is storing BIM in a Model Server and automatical-
ly exposing every object of the model as a representation in a RESTful
Web service. This can be accomplished by making use of an API that is
capable of providing representations of the objects in the Model Serv-
er. The second method is using a REST Enabler API for providing the
representations of the instances in the Model View. In both cases,
the REST Enabler API will expose the REST representations of the ob-
jects as web resources. Currently, as nearly no off-the-shelf BIM soft-
ware that can make use of REST Services without any extra
programming effort exists, it has been chosen – not to mention –
BIM software as the consumer of the RESTful BIM Service. In the cur-
rent version of the pattern, all data acquisition from the RESTful BIM
Service is assumed to be performed over web browsers, but this situ-
ation will change in the very near future.
Although the preliminary users of the RESTful BIM are prototype
and research software currently, it is expected in the near future
that off-the-shelf BIM software will provide support for seamless in-
tegration with RESTful architectures. Exposing every BIM object as a
REST resource will provide the finest-grained interface to the BIM,
which will enable the client application to acquire information re-
garding every unique object in the BIM.
Although the use of relational databases for storing the BIM is not
a common practice, the Model Views can be stored in the relational Fig. 7. The implementation of RESTful BIM pattern.
68 U. Isikdag / Automation in Construction 25 (2012) 59–71
The RESTful/RESTish implementations in the BIM Servers provide this pattern. The developed front-end is used for consuming a RESTful
evidence, showing the concrete implementations of this pattern. Ex- Service provided by the BIMServer [20]. The front-end can connect to
amples for validating this pattern include the REST implementations any instance of a BIMServer (based on its URL) over the web. Follow-
in open source BIMServer [20], and IFC Web Server developed by ing this, by providing the Project Id and Revision Id of a specific pro-
the TU Dresden [37]. The user interface of the IFC Web Server is ject that is residing in the server, the users can acquire information
depicted in Fig. 8. regarding any class/instance of the BIM in a RESTful manner. As illus-
The tree structure representing IFC objects (i.e. IFC Object Tree) trated in Fig. 10, the result set returned as the result of REST requests
can be navigated in various levels, and in order to get information is an ISO 10303 Part 21/ASCII Text format file, which provides a list of
the user can interact with this tree structure. Once a user query is entities of the queried model.
triggered through the navigation tree, a REST style Request/Response
is generated. The response can direct the user to a downloadable set 4.4. Comparison of patterns
of queried objects (in ISO10303-P21 format) or in form of an XML
file. On the other hand the RESTish functionality of the BIMServer in- The patterns explained in this paper involves some similarities
clude information acquisition from every single object in a BIM, Im- and differences originating from the technologies they implement,
port/Export of BIMs, BIM Versioning (to view previous versions of their focus, and the architectural styles used within them. Table 1
the same model and) to explore who made what changes and provides a brief comparison of these patterns.
when. The BIMServer has a web interface where one can query the The focus of the BIM AJAX pattern is on facilitating the interactions
models in the server by using REST and SOAP styles. The latest version through the use of visual representation of the BIMs, by enabling asyn-
of the software has an integrated web based viewer that makes use of chronous information transfer from model to the client. In this pattern,
O3D to view the model in 3D inside a regular web browser. The main the transferred information would mostly be semantic. The focus of
user interface of the BIMServer is illustrated in Fig. 9. BIM SOAP Façade is providing high-level formal (pre-determined)
During this research a simple front-end was developed (Fig. 10), query interfaces to the BIM, while decoupling the model from
to validate the applicability of consuming the services mentioned in the interfaces and clients. Conversely, RESTful BIM pattern provide
low-level (i.e. object level) interfaces to the model, and facilitate the patterns offer BIM and Model View interaction mechanisms which
low-grained queries. The implementation of BIM AJAX pattern is cli- would enable this synchronization. In the BIM Ajax pattern the AJAX
ent focused (i.e. the main objective is to transfer BIM information to queries of the client is dependent on the object structure of the BIM,
the client in an asynchronous manner), while other two patterns while in latter two patterns the client queries are against interfaces
are implemented on the server side, (i.e. regardless of the client provided by the SOAP Façade and RESTful implementations. Thus
type and capabilities they will continue to function). In BIM AJAX the client/model coupling in latter two patterns is not tight.
and RESTful BIM patterns the query/interaction granularity is at the
object level (i.e. the interaction is with BIM objects), in contrast BIM 5. Conclusions
SOAP Façade pattern enables the interaction at the interface level
(i.e. the client-side queries are focused to get information from the Service and resource-oriented architectures will shape the next
SOAP Façade Interfaces, but not from the SOAP object interfaces of generation of the WWW. The common view in the software industry
Model Servers). The SOAP Façade pattern provides high-level inter- indicates that the biggest strength of the Web 2.0/3.0 will lie behind
faces developed based on rules (such as “Provide columns of 1st the service and resource oriented architectures, which will enable
floor”), while other two patterns are not rule-dependent as they seamless access to data and application services regardless of the lo-
focus on interaction with BIM objects directly. As the BIM AJAX pat- cation and the environment they operate in. In fact, the AEC industry
tern is mainly focused on direct BIM interactions, it does not support (although having internally valid reasons behind it) is still very much
single or multi model views, in addition it does not offer any mecha- focused in establishing data and process level interoperability and in-
nism for BIM and Model View synchronization, in contrast, other two tegration. For example, industry professionals and researchers are
[17] CIMsteel Integration Standards Release 2: Second Edition, http://www.cis2.org [28] E. Pulier, H. Taylor, Understanding Enterprise SOA, Manning Publications, Green-
2003(last visited on November 2010). wich, USA, 2006.
[18] R. Vanlandea, C. Nicolle, C. Cruzb, IFC and building lifecycle management, Auto- [29] R. T. Fielding Architectural styles and the design of network-based software archi-
mation in Construction 18 (1) (2008) 70–78. tectures. PhD Thesis. Dept. of Information and Computer Science, University of
[19] IFC Wiki, An Open Portal on IFC, http://www.ifcwiki.org 2010 (last visited on California, Irvine, 2000.
November 2010). [30] C. Pautasso, O. Zimmermann, F. Leymann, Restful web services vs. “big” web services:
[20] BIMServer, Open Source Building Information Modelserver Project, http://www. making the right architectural decision, in: J. Huai, R. Chen (Eds.), WWW '08: Proceed-
bimserver.org 2010(last visited on November 2010). ing of the 17th international conference on World Wide Web, 2008, pp. 805–814.
[21] D.S. Linthicum, Next Generation Application Integration: From Simple Informa- [31] J.J. Garrett, Ajax: A New Approach to Web ApplicationsAdaptivePath.com., http://
tion to Web Services, Addison-Wesley, 2003. www.adaptivepath.com/ideas/essays/archives/000385.php 2005 (last visited on
[22] T. Erl, Service-oriented Architecture: A Field Guide to Integrating XML and Web November 2010).
Services, Prentice Hall PTR, 2004. [32] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable
[23] R. Ruggiero, Integration Theory, Part 1. DM Review Magazine, http://www. Object-oriented Software, Addison-Wesley, 1995.
information-management.com/infodirect/20050812/1034584-1.html 2005 (last visit- [33] S.M. Yacoub, H.H. Ammar, Pattern Oriented Analysis and Design, Addison-Wesley,
ed on November 2010). 2003.
[24] C. Imhoff, Understanding the Three E's of Integration EAI, EII and ETL, DM Re- [34] U. Isikdag, J. Underwood, Two design patterns for facilitating Building Informa-
view Magazine, http://www.dmreview.com/issues/20050401/1023893-1. tion Model-based synchronous collaboration, Automation in Construction 19
html 2005 (last visited on November 2010). (5) (2010) 544–553.
[25] G. Hohpe, B. Woolf, Enterprise Integration Patterns: Designing, Building, and [35] A. Shalloway, J.R. Trott, Design Patterns Explained: A New Perspective on Object-
Deploying Messaging Solutions, Addison-Wesley, 2003. oriented Design, Addison-Wesley, 2002.
[26] L. Seligman, P. Mork, A. Halevy, K. Smith, M.J. Carey, K. Chen, C. Wolf, J. Madhavan, [36] sqlREST: REST Enabler for Relational Databases, http://sqlrest.sourceforge.net/
A. Kannan, D. Burdick, OpenII: an open source information integration toolkit, in: (last visited on December 2008).
A. Elmagarmid, D. Agrawal (Eds.), E-Proceedings of SIGMOD 2010, 2010, http:// [37] IFC Web Server, IFC Web Server Project, http://bci52.cib.bau.tu-dresden.de/
portal.acm.org/citation.cfm?id=1807167 (last visited on November 2010). ifcwebserver/2011(last visited on October 2011).
[27] H. He, What Is Service-Oriented ArchitectureO'REILLY XML.COM, http://www.
xml.com/pub/a/ws/2003/09/30/soa.html 2003(last visited on November 2010).