The Web Services Technology and its Implications for AEC

In This Issue:

• Bentley's V8 2004 Edition
• Generative Components and Parametric Cells
• Future Directions: Web Services, .Net, PDF/E, and 3DIF
• Other Conference Highlights
• Overall Impressions

Two recent AECbytes articles made a reference to "Web Services": the product review of Meridian Project Systems' Prolog Manager, and the feature article on the IFC building model. Web Services is also fast becoming a buzzword in technology circles in general. It would be pertinent, therefore, to look at this upcoming technology in some more detail and explore its implications for the AEC industry, which is the focus of this issue of the AECbytes Newsletter.

What are Web Services?

There is no one agreed definition of the term "Web Services," as it is defined somewhat differently by the various software vendors who are providing this technology or using it in some form. The official definition of the term, as specified by the W3C, the World Wide Web Consortium—a global organization that designs, develops, promotes, and encourages standardization of Web-related technologies—is as follows:

"A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols."

This is a fairly technical definition, so let's dissect it a little to understand what it means. To start with, let's look at some of the terminology that is used. (A good resource for all Web-related terminology can be found at Webopedia).

URI (Uniform Resource Identifier) is the generic term for all types of names and addresses that refer to objects on the Web. A URI designates a specific resource on the Internet and also designates a method to access the resource. The familiar URL (Uniform Resource Locator) we use to reference a particular web page is one kind of URI.

XML (extensible markup language) is a specification similar to HTML, but which goes beyond simple document presentation to capturing data in a meaningful and structured format so that it can be exchanged between applications that need that data. XML uses user-defined tags to describe data types, and also includes mechanisms to address and associate sets of data, referred to as resources. The XML specification comes from the same source, W3C, described earlier. For more on XML and building industry XML efforts, see my Cadence AEC Tech News #54.

The Internet protocol in the Web Services definition refers primarily to SOAP (which was formerly an acronym for "Simple Object Access Protocol," but is now seen as just a name after growing into something that is no longer simple or object-access specific). SOAP is a lightweight XML-based messaging protocol, independent of any operating system, that encodes XML data as well as request and response messages before sending them over a network. Thus, while XML is used to tag the data to make it semantically meaningful, the actual process of transferring that data across a network is done using SOAP. In essence, SOAP is the glue that binds Web Services together. Other core protocols include WSDL, a specification for describing a Web Service (the service methods, message types, etc.), and UDDI, a mechanism to publish and discover Web Services.

Putting it all together and in less technical terms, Web Services is a technology that integrates different Web-based applications from different sources by allowing them to directly communicate data, semantics, and processes with each other, independent of any specific operating system or programming language, and automatically, without human intervention. The future trend in computing appears to be a move away from traditional desktop and client-server based applications towards applications that are fully developed and deployed over the Internet, that can also communicate with other Web-based applications dynamically in real-time to provide more integrated solutions to specific user tasks. Web Services is a crucial enabling technology for such applications, so we are likely to keep hearing a lot more about it in technology circles. Many of the leading high-tech companies are offering development platforms and environments that support Web Services, including Microsoft with .NET, IBM with WebSphere, BEA Systems with WebLogic, and Sun Microsystems with the Sun Java Enterprise System. (Note that the IBM, BEA, and Sun products are all based on the Java platform.)

Web Services in AEC Applications

So what does Web Services mean for the AEC industry? Considering that the technology is still relatively in its infancy, it will take a while before we see the impact of it in the applications we use to design, construct, and operate buildings. Commercial applications available today based on Web Services are relatively few, and these are mostly restricted to online project management websites. Proliance, MPS' latest enterprise-level project management application, is one of them, as mentioned in the review of MPS' Prolog Manager; Proliance's use of Web Services and the .NET platform is intended to make it easier for geographically dispersed organizations to manage multiple projects. Primavera's Evolve application for project portfolio management also uses Web Services and the .NET technology for tighter integration with Microsoft Project. Traditional desktop application vendors in the AEC field have yet to announce any specific products based on Web Services.

Since Web Services, by its very nature, promotes interoperability, it will be particularly critical to the IFC interoperability effort. As described in the recent feature on the IFC building model, a research project is underway—the IFC Model Server project in Finland—which stores the IFC model data in an Internet enabled database system. IFC compatible applications can then access this data in real time and communicate dynamically with each other, using the Web Services technology. The power of the building information model can be substantially extended with this concept. The building data will no longer just reside in a file that has to be exchanged between applications, with confusion about which is the most recent version; instead, it will be live, up-to-date building data that reflects the latest state of the model. So, for example, a change made by the architect to the building design will be immediately seen by an energy-analysis application working with the model, without a manual IFC export from the architectural application and a manual IFC import into the energy analysis application.

In a fully Web Services based AEC world, we would have no applications locally installed on our machines. Instead, we would be running all the applications we needed over the Web, and they would communicate freely with each other. Imagine this scenario. At the conceptual design stage, an architect "rents" the use of three Web-based applications from different vendors: a sketching tool, a space analysis tool, and a photorealistic visualization tool. As the architect develops the design concept in the sketching tool, the space analysis tool simultaneously shows space areas and distances in detail, by communicating directly with the sketching tool via Web Services. The architect can also immediately see a photorealistic rendering of the design concept in the third tool. At any time, the architect can call up other tools to collaborate on different aspects of the design, such as an energy analysis tool, a code checking tool, an animation tool, and so on, all by different vendors. There is no upfront cost in purchasing specific tools and dealing with all the installation and updating headaches; instead, applications can be paid for and deployed on an "as-needed" basis, allowing AEC professionals access to a much broader network of technical resources than is possible today.

Conclusions

The scenario just described might sound far-fetched and much too futuristic right now, but it is the vision behind the whole Web Services initiative. Some of the potential of this technology has been realized in industries similar to AEC, such as manufacturing. A recent report in the June 24, 2003 issue of Business Week entitled "Where Web Services Meets the Road" describes how General Motors (GM) is using Web Services to monitor information on quality, productivity, and inventory of cars and parts in its assembly plants. It is also using Web services to act as a translator between the old and new of its 3,000 different systems, saving the cost of constant upgrades. Future plans include the use of Web Services to manage parts and inventory with its suppliers, as well as download software to computers for operating cars and communicating with their owners. Many of these tasks are similar to those in the AEC industry, which can benefit from the comparable application of Web Services.

While the concept of Web Services has been in the making for several years now and was particularly hyped in the dot-com days, the speed of adoption has been hampered by security and reliability concerns, various technical issues, as well as conflicting vendor interests. Standards for any new technology are notoriously difficult to define and get unanimous acceptance for, and Web Services is no exception in this regard. However, even though the technology is still relatively in its infancy, particularly in its application to the AEC industry, it is definitely something to watch and learn about, as it can potentially transform the entire computing landscape in the future.

About the Author

Lachmi Khemlani is founder and editor of AECbytes. She has a Ph.D. in Architecture from UC Berkeley, specializing in intelligent building modeling, and consults and writes on AEC technology. She can be reached at lachmi@aecbytes.com.

Newsletters > Issue #8 > Printer-friendly format