Inside the Salesforce Apex language

Salesforce.com's Apex programming language has been hailed by some as a significant milestone in short history of Web on demand applications. But at this point it is still of form of vaporware that hasn't yet been unleashed on the 20,000 AppExchange developers. My colleague Steve Gillmor and I talked to Parker Harris, salesforce.com co-founder and head of technology, about the Apex rollout and what makes it special.

Harris said that the language is part of the Winter '07 release that was just released, but is only accessible for internal use by salesforce.com developers. Public beta testing of the language will begin in Q1 of next year, working with key partners. He expects the beta cycle to be short, given that internal developers already feel comfortable with the quality of Apex, with general release slated for the spring of 2007. 

Harris doesn't expect the learning curve for developers to be a problem. "They have to get used to a new language," Harris said. "It's no big transition if they are accustomed to a database language and Java syntax. If they are not database developers, some of the concepts will be new."

Harris noted that the Apex language isn't for creating user interfaces. Currently, an AJAX toolkit can be used to create UIs. "We need to build a pretty radical UI layer for building UIs that we would run, which aren’t built in AJAX. We are starting to talk about it. It's the next problem to solve," Harris said. 

The most significant aspect of Apex is that database transactions can span multiple statements, Harris said. The additional functionality adds the database transaction layer to the data model, which is essential for building sophisticated ERP applications, such as inventory management and even a general ledger. This contradicts what NetSuite CEO Zach Nelson said earlier today about salesforce.com lacking a transaction engine. "Through Web services today, you have a compensating transaction, such as 'undo what I just did,' but no concept of making calls and committing transactions. We can have the power of the database transaction layer in Apex, virtualizing access to the Oracle engine," Harris said.

Part of the work to be finished before releasing Apex is making sure it doesn't blow up under the stress of thousands of custom programmers pushing its limits. "The key to Apex is compiling down to byte code. We can watch the code as it is running, and thus control the number of database statements in an Apex call and control loop iterations, for example," Harris said.

If a program violates preset limits, Apex will throw up an error message, Harris said. "All of this is in code, and we are working with ourselves and partners on seeing how rate limits should be triggered. We want to make sure the limits are just right so no one ever hits it, unless it is done maliciously." Salesforce has an Eclipse plug-in and can catch compiler errors. The next step, according to Harris, is stepping though code. "We are working on how that looks," he  added. "We don’t want to leave database transactions open while we are stepping through code. We need to take that transaction and dehydrate it on the app server. Debugging and stepping through the code plugged into our server is sky is hard problem to solve."

Harris expects Apex to reduce the server load, compared to the AppExchange APIs calling external Web services, and believes that the companies scale-out infrastructure will be able to handle the load as more transactions hit the servers.

The biggest hurdle for Apex will be cultural, convincing CIOs at larger companies bought into traditional ERP software that it's time for a change. "It will be a multiyear story," Bruce Richardson of AMR Research told me. "AppExchange was easy, a first step toward do-it-yourself software, which is threatening to CIOs. Now, they need to show some cost models that compare traditional ERP to the on demand model, which could offer 10 to 100 times cost savings. A challenge is how do you get the message out to frustrated end users who want innovation and find that IT is the bottleneck."