Joe Aiello is the kind of customer Salesforce.com can appreciate. He is the director of corporate systems for Fios, Inc., which helps attorneys gather electronic data as evidence in court cases. Aiello came to the Portland, Oregon, company with a background in Oracle-a company that is almost synonymous with build-it-yourself relational database applications. And so understandably, he was at first skeptical of Salesforce.com's hosted, on-demand approach-in which the technology resides on Salesforce.com's server, not yours. "But when I took off my technology hat and put on my business hat, their approach made sense."

The approach makes even more sense now that Salesforce.com has announced a procedural language, called Apex. Scheduled for beta testing in the first quarter of 2007, Apex will allow developers to further customize the technology by attaching business logic to buttons, tabs and other interface elements, as well as entirely new applications.

"Apex will allow us to remove some of the Access databases and spreadsheets that are now floating around our organization," Aiello says. Fios has licensed Salesforce.com for about two years, with about 100 employees accessing it, and Aiello has already extended the Salesforce technology to meet specific needs within Fios's sales cycle. His team has built a human resource application based on Salesforce.com resources, as well as integrated Salesforce with its workflow and VOiP systems. The last of these projects took less than a week to complete. But some data requiring additional business logic has had to reside on Fios's servers.

"With Apex, we will be able to add procedural code and run it on their servers. And I can assume that Salesforce will take responsibility to ensure that this code is secure, scalable and upgradeable. If as a result we can make more information more visible across the enterprise, it's a win-win."

Another customer, Eric Hoffert, CEO of ShareMethods, says that the main advantage of Apex is its server-side operation. "Today, you execute SOQL from the client side, via say Ajax, Java, or JavaScript. But that approach has limitations because you may have to update the code with new releases of the software. Now, Salesforce.com will ensure that Apex business logic will always be operational from one release to another." The payoff, he says, is in lower maintenance costs along with "an ease of adding features in a highly scalable way."

Hoffert also anticipates better performance because multiple transaction operations can be executed simultaneously on the server side. He notes that the advantages of Apex will remain largely on the back-end: data manipulation remains Salesforce.com's strength. ShareMethods will still handle its own user interface with a combination of Ajax, Dynamic HTML, and JavaServer Pages. "Apex gives us the power to extend the interface by attaching customizable business logic. For example, buttons and graphics can be linked to complex transactional logic needed for different Salesforce.com customers."

Hoffert's company was formed with Salesforce.com in mind. Hoffert and his colleagues previously worked for a Salesforce.com customer, were impressed by the technology, and went out on their own. Their product, ShareMethods, helps companies manage sales and marketing documents from a single location, becoming one of the first on-demand applications to be listed on AppExchange. Hoffert says that Apex is the latest in a series of technologies to give more control to developers. ShareMethods has used these refinements to add a series of upgrades, including document links for retrieving additional information, single sign-on, and customized tabs. These features, along with custom fields, "have been a journey toward more increasing customization."

Saleforce.com has been passing more customization control to developers for some time now, most prominently with the company's Sforce Object Query Language (SOQL) and other elements of its API. Resulting applications are listed on Salesforce.com's AppExchange online marketplace.

I began my conversation with Adam Gross, Salesforce.com's vice president of developer marketing, by asking about what the Apex language adds to the company's development platform. But first, a note on terminology. Rather than licensing software, Salesforce.com licenses "on-demand" services, which it hosts on its own servers.

The company also talks about a multi-tenant model, in which a single on-demand database serves multiple "tenants," keeping each customer's data separate from the others. "When a customer signs up for Salesforce.com, we don't roll out a whole new server stack just for them," Gross says. "Instead, their account occupies a virtual instance of that application. This is exactly how Google, Amazon and eBay work. Multi-tenant application has been built specifically to be offered on the Web as an on-demand environment, with all of the provisioning and application characteristics that are commensurate with that."

How did your development platform work before you introduced the Apex language?

One of our key technical innovations has been the ability to build your own application on a multi-tenant platform. So even though it is a shared environment, you can still create your own data model, with your own objects, which are analogous to database tables, and your own tabs. As a result, you can build an application that represents any kind of business data process. It could be in an add-on to a CRM [customer relations management] application, or an asset tracking application-it could be anything. But the key is that you have a data-centric application analogous to what can you create with a database tool. You can create the database structure, as well as the corresponding forms that make up the user interface. Being able to do that on demand has been a big technical innovation.

Part of this model is that it's free. Anybody can go to our developer website, sign up for a free account, create an application and post it to AppExchange, all without paying us anything.

In customizing applications, where does the Salesforce Object Query Language come in?

SOQL is a subset of our platform capabilities, specifically our Web services API. Obviously, having an API to all the application-related data-whether it's a Salesforce CRM application or one that you create for yourself-is very important both for integration and application development purposes.

So the idea is that you then create an application in Java, JavaScript, or .Net, then use the API to invoke the appropriate SOQL queries?

The application development model is a little more nuanced than that. There are actually two pieces of it. One is what is technically known as declarative application development model, where you are configuring the application, not actually coding it. In this configuration process, you are telling Salesforce about the data model and other characteristics of the application. You might specify that you want a job object with a field called "job description." Then you might have a candidate object that represents somebody applying for that job, which you then relate to that job object, just as you would in a database. All of this is done just as you would set up a database, creating the fields and tables and other parts of the structure.

Then optionally, you can choose to use the API to build more advanced functionality. A classic example would be something like a Google map in a mash-up: using the job object to plot the location of all those jobs on a Google map. One way to do that is using JavaScript and other parts of Ajax to make a query to the Salesforce API, extract the information about jobs, and then use the corresponding Google map API to plot those jobs on the map.

How long has this development infrastructure been in existence?

Various pieces have been available for the past year and some longer than that. But there's one piece of this puzzle has been missing, both on Salesforce and in any other on-demand environment: the ability to create your own procedural business logic, as you would do with a programming language. Let's say that a job object moves from the recruiting stage to actually getting hired. I then want to automatically create a new hiring object. Based on the job requirements, I might want to automatically assign a laptop resource, or, if they are a developer, a desktop machine. We are now in the realm of business logic, the kind thing that is routine in a procedural language.

What Apex provides is an analogous capability, but one that runs entirely on demand, in a multi-tenant environment. The benefit for a developer is that I can represent complex business logic without having to worry about the operational considerations. I never have to deploy a server. And whether it is one user or a 100,000, I never have to worry about the scale. What makes this so technically interesting is that a lot of people didn't think you could have a programming language that runs in a multi-tenant on-demand model.

Was that a challenge to develop?

Absolutely. It was a huge technical innovation. Consider what happens, for example, if you run a piece of code that says "retrieve a billion records" or puts itself in an infinite loop? A few lines of code can potentially impact the entire physical operation of the system well beyond your virtual account. So the key technical innovation is allowing you to create code, while governing the execution of that code so that it can't do anything either intentionally or unintentionally malicious.

In some ways, Apex resembles Java and .Net code, which don't compile down to assembly language. Rather, the compilation process is intermediated by a virtual machine. That has a number of advantages. A garbage collection function means you don't have to worry about memory management. And because you translate down into bytecode, you can be executing a SPARC instruction set or a PowerPC instruction set.

We do something similar but we also govern the execution of the code on top of that virtual machine. And I use the word virtual machine here metaphorically. You can think of it as a "virtual virtual machine." That's an additional layer of abstraction, but there's always more abstraction involved in managing the benefits of multi-tenancy. And we've had to invent this. Conventional PC operating systems don't know anything about multi-tenancy. If you call up Oracle or Microsoft, there's no product you can buy from them that know anything about multi-tenancy. This was a huge challenge and an amazing piece of intellectual property. And now we've applied multi-tenancy to the business logic programming layer.

Does Apex handle the user interface as well?

Apex is for data manipulation and business logic-it's for creating business logic, not for creating interfaces. In any good programming model, you separate the representation of the business logic from the representation of the user interface. With Apex, you can, if you like, create your own user interface through a combination of HTML and Ajax. But the degree to which you want to modify things is up to you. We have a default user interface that we render based on what we know. So that if you create a jobs object, we know what an edit page for those objects looks like-because we have all the metadata. So we provide that automatically. But if you prefer to build your own UI in something like Ajax, you can do that too. The same thing is true of the Apex code itself. You don't need use Apex code to build an application, only if you want to express the kind of business logic that I've described.

If you scan the blogs, people are asking why you didn't you just go with Java. Why yet another programming language?

There are really three reasons. One is that Java isn't multi-tenant and we need multi-tenancy-it's an absolute requirement. We can't do what we're doing without it.

Secondly, we are actually trying to do much less than what Java does. I can build a video game in Java. [Sun CEO Jonathan Schwartz] will tell me about all the great video games I can write for my cellphone. He'll tell me about how I can run the robot on Mars in Java, and how I can build a vending machine operating system in Java. Those are all fantastic things, which Apex can't do, with imaging APIs and other libraries that we don't offer because they aren't applicable. However, when it comes to creating business logic for an on-demand business application, that is something we can do. It's much more narrowly scoped.

The third reason is we wanted to create a tight interaction between Apex code and the rest of the system. We wanted to be able to instrument the code so we know what it is doing, so that we can control its execution in a different way than Java executes. We also wanted to be able to bind the code and its operations to the rest of the system in an explicit way. For example, in that jobs application example, perhaps I'm referencing the job type field in my Apex code while somebody else it trying to delete that field entirely. Here, the system knows that field is being used. That's not true for Java-it doesn't work that way, nor does .Net. At the same time, we're not just out to create things for the sake of something new. So procedures like for/while loops will look the same as in Java.

Would it be fair to characterize Apex as Java-like or PL/SQL-like?

It's Java-like in syntax and PL/SQL-like in capability.

Are you concerned about programmer learning curves or do you figure the similarities between Apex and Java make it an easy migration?

Developer ease-of-use is paramount to us, so we want to make things as straightforward as possible. We have a long track record of that with our APIs and with SOQL, as well. SOQL isn't SQL, because SQL doesn't do exactly what we need, but we've tried to make SOQL as much like SQL as possible because people are familiar with it.

What kinds of applications do you expect now that you weren't seeing before?

We're going to see applications that are much deeper in a given area. We've had HR [human resource] applications, but not that could handle things like provisioning employees. We also think we will see a broader range of applications, because while we have played in areas like HR, finance and project management, we haven't played in the back office. We haven't been able to create things like order management applications because they require very sophisticated transactional business logic. For example, if I create an order, I need business logic to determine what happens if the item isn't in inventory.

Salesforce competes against some big companies-including Oracle and SAP-who are all about business logic. Is Apex a way for you to compete more head-on?

We still have a very different vision for how businesses are going to use the Internet than do companies like SAP and Oracle. Namely, that on-demand computing will increasingly be the rule, not the exception to how companies build and run their applications.

People have argued that for some time, but these companies are still in business.

People have argued that for a long, long time. People have argued that on-demand computing will be fine for small companies, but won't even touch the largest ones. We've proved them wrong on that. Now they are saying it will be fine for just for CRM, and we're beginning to prove them wrong on that. So now they're saying it's fine for other applications, but not for ERP [enterprise resource planning] or custom applications. And that's why for those companies, all roads lead to software.

Those companies really took notice of Apex because they didn't think this was technically possible. One analyst called Apex the equivalent of the hydrogen car. Imagine if all of a sudden one day some new automaker said we have the hydrogen car. That's kind of what we did with Apex. People said it isn't possible; we said: here it is.

Sidebar: Some thoughts from the "Software Heretic"

While Salesforce.com customers hadn't yet gotten their hands on Apex at the time of this writing, many were following the announcement closely, including consultant Brian Rozmierski, who tracks the developer side of the company on his Salesforce Heretic blog. The following exchange took place via email:

Among the people you talk with, what's driving interest in Apex?

Many of the people I speak with are eager to get their hands on Apex to automate many of the manual processes they do now, or to reduce, or eliminate the need for external processes to be running to do these tasks via the existing API.

For some time now, one of the major limitations of the Salesforce.com platform was its closed-off nature. For example, with most on-premise database-driven applications, the administrator gets some raw access to the underlying database. From that level a careful DBA [database administrator] could add triggers or other database-level hooks to accomplish other tasks. But there are plenty of real-world examples of what has not been possible in the Salesforce.com world pre-Apex. For example, when a sales opportunity is closed and won, say you want to change the account type to read "Customer" instead of "Prospect." To accomplish that today, a workflow event has to fire in Salesforce.com creating a task that must be manually completed by a user. Or you can write a program via the API to run at certain intervals checking for updates. With the release of Apex this is now automatically possible in real time.

Apex will also provide trigger-like functionality in combination with outbound messaging, such as the ability for Salesforce.com to call out to your server when certain events occur. And data validation can be done before a record is committed to the database. Integration between Salesforce.com and other packages or internal systems can be done in near real time, instead of on an arbitrary delay.

Is Apex a response to the Salesforce.com community's request for a procedural language interface?

I wouldn't characterize the community as wanting a procedural language interface per se. But people have long asked on multiple occasions for the ability to run our code on the platform directly. I believe that the more technically inclined in the community saw this as a long-term item, because the concept of running code in a multi-tenant application is, well, daring to say the least. Preventing run-away code and resource hogging are significant challenges to overcome. As a language, Apex looks impressive, and as a technology even more so-however the devil is in the details. Apex triggers and outbound messaging finally complete a long-missing set of features that have been a thorn in the side of administrators. Many, including myself, are quite optimistic about Apex's possibilities and are eager to get our hands on it and get coding.

Do you think Apex will primarily be used internally within companies, or will this broaden AppExchange, or both?

One can't answer this question without talking about the SFDC marketing and PR departments. If there's one thing SFDC does almost universally well-it's pervasive marketing. I have publicly called the AppExhange a "grand experiment" and I fully expect the PR machine at SFDC to be running at 110 percent as partners ready Apex applications and integrations. For those SFDC customers that have an internal IT department, I fully expect many of them to begin using Apex (and/or related features) as soon as they are available. However, smaller companies who don't have someone with programming experience will not likely be able to take advantage of these features. This leaves an opportunity for SFDC's professional services, as well as outside consultants/programmers.

Any sense of the impact the kinds of applications Apex will enable?

I fully expect to see reports of productivity increases, data validation benefits, and streamlining all across the board. Some enterprising customers will use Apex to enable targeted marketing and other interesting things. But most importantly, I believe Apex will empower the administrator to finally control the data, not be controlled by it.

On your blog, you've had some thoughts about vendor lock-in regarding Apex, namely that some non-portability is inevitable, even if with Java (because of the use of APIs). But you also suggested that the SFDC community would be better served if the Ajax spec were submitted to a standards body. Have I got that right?

My response to the vendor lock-in argument was really more of a slap-in-the-face wake-up-call. At the time, there were a number of messages and blog entries about whether there was, or was not, lock-in with varying vendors in the CRM space. My point is that while lock-in is inevitable, the degree of lock-in is variable. Each of the major players in the on-demand space has different schemas for the data, different APIs, and differing nomenclatures. All of these add up to some degree of lock-in. If you decide to leave one vendor for another you will have to convert your data, integrations, and retrain staff as part of the change.

Of course I'd like to see the SFDC API and Apex submitted to a standards body. Doing so, and allowing others to implement the API calls and Apex language will create more competition and force further innovation in the space.

Any other thoughts for Software Design readers?

While I've generally been upbeat about Apex, in it's features and potential, I wouldn't be me if I didn't take a good look at the other side: It's not here yet. Though I haven't had a chance to confirm it, there are blogs about discussing January 12th, as the release date for winter '07. This would, essentially, mean it has been almost a year since the last significant release from Salesforce.com. (Summer '06 was, honestly, a joke as releases go. It should have been an unnamed patch and been done with it.) So I remain somewhat skeptical, as there is a history of features that are what I would call "incomplete," meaning they have exceptions in their usage that wouldn't be generally anticipated. For example, formula fields cannot access the activity date in an event or task. Also remember that Apex will be in beta with the release of winter '07. It's likely users won't get their hands on it for some time after the release.