Getting Started In the Cloud: Java-Based App Development on the Force.com Platform

fact sheet Vendor: Salesforce.com, Inc. (www.salesforce.com) Vendor's Information: About the Force.com Platform About Salesforce.com, Inc.

As a development platform, the cloud rocks. That's the first thing I learned taking a developer's test drive of the Force.com platform. Force.com, a cloud platform, lets you build database-driven business applications that you can deploy and update almost instantaneously on the Web--without explicitly managing users, or setting up database connections, or otherwise worrying about the software plumbing that makes up so much of a typical application.

Force.com is a cloud-based platform for application development and deployment running on the infrastructure of salesforce.com. As a developer, you can get free access to a Force.com developer edition environment by registering on developerforce. The environment is a sandbox in which you can build Force.com hosted applications—think of the environment as an instantly available online, hosted development, testing and deployment full-stack application server (though it's more than that, of course).

There are a variety of learning resources for those new to the Force.com platform available through Developer Force, including a fundamentals book, discussion boards, and a number of blogs. The Force.com Workbook is a great place to start. It's a collection of tutorials that take you from no-code application setup through deployment, going pretty deep into writing classes in Apex (Force.com's Java-like development language) along the way.

I took a test drive of the Force.com development platform, getting familiar with the programming model and building a sample application. I found a lot to like. If you're a Java developer eyeing the cloud for your next project, I think you'll find a lot to like, too.

Work in Eclipse
The Force.com IDE is an Eclipse plugin that allows you to edit applications locally and to synchronize application components between the local workspace and the Force.com platform. It includes an Apex code editor, synchronization and deployment functions, and tools for defining and running unit tests, all presented through a Force.com perspective.

In Eclipse, a Force.com project includes custom applications, database objects, Apex classes, custom tabs, and other application components. You can edit a project's settings to control how each item or type of item is synchronized between the workspace and the platform. By default, saving changes locally automatically updates files on the platform server as well, so you are essentially always working on cloud-hosted objects directly within the IDE.

Because you're working on a local copy, and have fine control over how files are copied to the server, you can easily version-control your cloud-hosted application. For example, you could use Subclipse to pull the latest files from a Subversion repository into Eclipse and then save those files to the Force.com server.

Database Objects
Force.com supports a range of development options, from no code, using built-in Force.com applications and tabs, to serving up custom data objects through a Web service API to your own Java clients using a Web Services API. At the foundation of applications created with any of these development methods is a set of database "objects" which represent your data model. You can define these objects using a set of Web-based tools, or by directly editing XML configuration files in Eclipse.

A custom object type can be thought of as a new database table, but creating a custom object goes beyond specifying a list of fields and field types. With Force.com objects, you can set validation rules, lookups, calculated fields, and even workflow declaratively, as part of the object definition.

As an example, a validation rule that guards against entering future dates looks like this (when viewed through their metadata API):

<validationRules>
<fullName>Date_Validation</fullName>
<active>true</active>
<description>No future dates.</description>
<errorConditionFormula>Date__c > TODAY()</errorConditionFormula>
<errorDisplayField>Date__c</errorDisplayField>
<errorMessage>Date cannot be in the future.</errorMessage>
</validationRules>

Force.com's declarative approach to object definition saves a lot of drudge coding. Instead, you get to use code for the fun stuff, defining the custom behaviors and business logic that describes how these data objects interact.

The database feels like a relational database, but has a few other attributes. For example, it automatically assigns an identifier to every record, and always records data such as when each record was created. It also supports a high-level abstraction of relationships. You don't play with foreign keys, but rather relate objects (this object is in a parent-child relationship with this object) and the platform can then expose this relationship in the user interface or through the query language.

Apex Code
You write triggers and classes that run on Force.com in Apex. There's an Apex editor supplied with the Force.com Eclipse plugin. Apex is a strongly-typed, specialized language with a Java-like syntax designed to run in the cloud. Apex is close enough to Java that Java developers won't notice a cognitive bump in writing Apex. Apex differs from Java mostly in that its scope is limited to the business logic layer, so you won't be doing any I/O (other than Web services and HTTP) directly in Apex. This difference is by design, as Apex is meant to be safe to run on the shared, multi-tenant Force.com platform.

This is an Apex method, designed to be called from an insert and update trigger, to enforce a complex validation rule that depends on multiple objects:

public static void areMilesAllowed(Mileage__c[] miles) {
String createdbyId = UserInfo.getUserId();
Double totalMiles = 0;
for(Mileage__c mq: [SELECT miles__c FROM Mileage__c
WHERE Date__c = TODAY
AND Mileage__c.createdById = :createdbyId
AND miles__c != null]) {
totalMiles += mq.miles__c;
}
for(Mileage__c m: miles){
totalMiles += m.miles__c;
if(totalMiles > MAX_MILES_PER_DAY)
m.addError('Mileage request exceeds daily limit:' +
MAX_MILES_PER_DAY);
}
} 

Mileage__c is a Force.com database object type, in this case a custom object that tracks travel mileage. In the example's first for loop, the list of Mileage__c records over which we're iterating is generated by inline SOQL query. SOQL is a query language, similar to SQL, but designed to support queries on Force.com data objects. Using SOQL inline in this way is a powerful construct, making it easy to work with lists of records that match query criteria.

The database is tightly integrated with the programming language. Notice that I didn't open or close any database connections, and the generic error mechanism (see the m.addError() method) ensures that if a failure is detected that the error is surfaced in whatever form is most appropriate (user interface, web services API, etc.) And I didn't need an ORM mapping layer either—that just happens.

View Options
Force.com objects form the model part of an MVC design. Depending on the level of customization you need, the appropriate view might be a Force.com tab, a Visualforce Web page, or a Java client application talking to the server through the Force.com Web Services API.

Visualforce is a set of UI components (some fairly high-level, such as record view, or data table) and a markup language in which you can mix these Visualforce components with HTML and other Web presentation technologies.

In a Visualforce UI, the standard controller for a data object presents the object based on an object ID in the URL. You can also build controller extensions in Apex code. For example, you might extend the standard controller to return a list of objects that match a given criteria (using the inline SOQL list construct as above). You could then match that list with a Visualforce data table component on the page, to display the list of records in tabular form. This is a great example of how the Force.com development platform lets you deliver a very different customer experience with relatively minor customizations at different layer in the stack.

If you're a Java developer who has used MVC frameworks such as JavaServer Faces, you'll feel right at home with Visualforce. It also lets you define your own components and so on.

Interestingly, Force.com also supports an automatically generated user interface. If you create your database model, it automatically builds a user interface around that model. Think of it as using the metadata that describes your database objects. That same metadata API is used to transport the "code" representing your application to the IDE. This makes it particularly easy to prototype applications very quickly.

Web Services
Force.com provides a SOAP Web services API that gives you access to your data objects directly from external Java code. Custom objects you create on Force.com are automatically Web-service accessible, alongside all of the standard Force.com objects.

You can generate the custom WSDL for your organization with just a few clicks using Force.com Web tools. You can then use the WSDL2Java tool from Apache Axis to generate Java proxies for your Force.com objects, so they can be used from your client code.

In addition to data objects, you can also write Web service methods in Apex, using the Apex WebService keyword. WSDL for these methods is also easily generated using Web tools, and imported into your client application in the same way.

What's nice is that you don't have to play around with Web service configuration, with installing a web service stack and so on. Just adding the keyword is enough, and the platform does the rest.

Test-Centric
By policy, the Force.com platform is committed to thorough unit testing. You must provide unit tests that cover at least 75 percent of your application before your application can be deployed to a production server. Force.com's test support is top-notch, with support directly in Apex code (the testMethod keyword and @isTest annotation), plus test runners in both the Eclipse IDE and the Web development environment, and a code coverage tool.

The testMethod keyword marks a method as a unit test. Unit tests are those methods that will be run by the test runner, and they are restricted from committing changes to the database.

Besides being good practice, the tests also ensure that your code behaves on the platform (which is multitenant, and which runs your code along with everyone else's). A new release of the platform is made every four months or so as well (adding features, etc.) and all tests are run on a new release before it's made generally available, ensuring compatibility.

What's Missing
It looks like programming on Force.com is not just about what you do, but about what you don't do too. I don't have compilers, I don't wrestle with email or web service configuration, I don't think about closing database connections, or choosing the right ORM solution—it's just all there out of the box. I also don't have to wrestle with a user management system (login, authentication etc. are all built-in), with security (built-in), reporting (built-in) or with data management (built-in). From this perspective, it is a little different from Java—all of these pains are missing—but that's not a bad thing.

See for Yourself
Force.com is a single cloud platform, but you can deliver very different classes of application on that platform, depending on your requirements. Force.com's clean separation of data, code, and presentation means you can choose where and how it makes sense to apply customization in building your application.

As a Java developer you can work at any layer, using your expertise to develop business logic in Apex, a user interface through Visualforce, or to work with Force.com through the Web service API. At any level, there's a lot to like about Force.com's approach to cloud development.

Read More: First Take on Force.com from a PHP Developer's Perspective »