Kazoo's CEO, Joseph Cardoza, was asked by Colliers' CIO, Jon Green, to propose a solution for a problem that had been haunting the Colliers IT department for a while.

The problem was "speed." Requesting a commercial real estate report from a computer system should never be a "Project" that requires coffee making and donuts to be consumed while waiting.

The system was ASP based and connected to MS SQL Server 2000 to query commercial real estate properties. The reporting portion of the system was just thrown together! The agents at Colliers requested that the reports be in PDF format. Well, that's good except getting there from an ASP page is not as easy as advertised.

Adobe Acrobat allows for PDF creations, but for more control over the output, format, and content, Crystal Reports was chosen to control the output because of their ability to construct the output in PDF format. At that point, we felt we were almost there, but not quite.

The COM wrapper for the Crystal engine to be called from the ASP page to do the job was "single threaded": that means if 10 agents hit the site and start printing reports, they will be worked on one at a time, causing a jam and complete dissatisfaction, especially if Agent 005 wants to print all the available properties in California. You get the picture.

We found a solution by developing a Borland Delphi-based COM server that receives the printing requests first and multithreaded them to instances of the Crystal engine. Did I mention Web services yet? Bear with me.

The solution worked, everybody felt relieved that reports were moving along, no jams, and they got the job done.

The reality of the matter was that we didn't do anything. We just fixed something that was supposed to work right from the start. The real problem was: How could we get Colliers Agents to be more productive on the go?

If I am a customer requesting knowledge of commercial real estate availability from a Colliers agent, the process is for that agent to print a log of available properties in that area and hit the road. What happens when I, the customer, have a question about a specific property that is not on the printout? What happens when I choose to change the location of the search halfway through? Do we have to go back to the office for more printouts? What a waste of time.

The goal was to spice up the current framework to allow for easy access to this information on the road. Plugging in a laptop on the road and hitting the site was not my idea of "spice up."

At the time, I wanted to use the SOAP framework built in Delphi 6 to wrap the COM requests we built into the framework and allow access to the data over HTTP from any platform or device worldwide. It was extremely easy to build this server using Delphi 6, the only commercially available SOAP framework at the time. All the SQL queries were routed straight back to the transaction server already built using COM and MTS and the responses were all driven back to the requester using SOAP (XML over HTTP).

Portable Data Access
"Okay, now that we have a solution, how are we going to apply it for data access on the road?"

We chose the PocketPC route; it was the best choice for wireless development. We bought several iPAQ 3650s, embedded VC++ for PocketPC and MS SQL for CE and started playing. We decided to use the PocketSOAP framework (www.pocketsoap.com) to provide the client code on the devices for accessing the Delphi 6 Web service we had just created. It was amazing how fast everything was put together, and it worked!

One final problem we were facing was the choice of hardware for wireless access.

When we started this project, Ricochet was still alive and was our first choice; when they went under, we had a larger problem on our hands because of two major issues:

1.   We needed something that worked as well as Ricochet, speedwise, because SOAP was not the fastest animal on the block. It was still TEXT over HTTP.

2.   It needed to be financially equivalent to operate (or even better) to get the approval for nationwide use of the technology.

Well, first there was nothing even close to Ricochet. The wireless modems that we experimented with were at least 10 times slower, unreliable, and extremely expensive to operate monthly with heavy usage.

Then we started to consider two different approaches: wireless 802.11b technology for internal use in all Colliers offices via an Access Point and Sierra Wireless AirCard 555 for external usage. It worked great!

As part of a pilot program, agents were able to retrieve property information and query their data wirelessly anywhere in the Bay Area.

Return on Investment
But we still had a major question: "How can Colliers make money out of Web services?" This is a question a lot of companies have asked, and they've fallen short of finding a business case where Web services can generate revenue.

That idea started the second phase of our project. Jon had explained to Joe and I the essence of collaboration between companies in the commercial real estate business. It was definitely different from regular real estate. Visiting company XYZ on the Web and requesting views of properties in special areas renders only properties handled, owned, or contracted by company XYZ. Bearing in mind that Colliers International is the biggest commercial real estate company in the world, a lot of other commercial real estate companies would really find it advantageous to tap into a properties inventory like Colliers'.

The original Web service was modified to allow logging, authenticating, and charging of data access to the requesting party. It was based on the same model as a regular Colliers agent, except a flag was introduced in the database to identify the agent as a competitor, which linked in another table that identified the charge per listing.

So, a potential buyer visits www.xyz.com (commercial real estate company) and requests a search of properties of a minimum of 10,000 square acres in the Alameda area. XYZ only has two listings in that area but has a contract with Colliers to access their inventory. A Web service call is made into the Colliers system to authenticate and retrieve the information. If the contract with Colliers states, for example, that each listing will cost 10 cents, the SOAP dataset returned is counted, logged, and saved.

A Linux Mirror
Just before we released the pilot program for the new system, Borland Software Corporation announced the release of Kylix 2.0, a Linux-based RAD development tool identical to Delphi. Knowing the power of Linux on the server side and its cost effectiveness, I was given the green light to experiment with mirroring the Web service solution under Kylix 2.0 for Apache hosting.

I would have liked to mention that we worked hard on this task or even contributed much to this effort, but the truth is that Kylix 2.0 did all the work. It took two hours to convert the SOAP server and that's because we had to mirror the MS SQL Server to Interbase.

Summary
It was a pleasant conversion, which almost never happens in real life. Kazoo Software continues to support Colliers' efforts to make technology a tool to make everydays tasks simple, fast, and elegant.

With the Delphi and Kylix solutions developed by Kazoo, Colliers supports its internal team with state-of-the-art applications designed for speed, flexibility, and performance.

Side Bar
About Kazoo
Founded in 2000, Kazoo is considered one of the fastest growing companies in Silicon Valley. Using its exclusive and proven consulting process, Kazoo utilizes a wide range of talents that come together to develop customized solutions that fit customers' needs. Kazoo is your partner for powerful business solutions that help your organization increase efficiency, productivity, and profitability.