REVIEW: Building for the Cloud with Force.com and Eclipse
REVIEW: Building for the Cloud with Force.com and Eclipse
About two years ago, Salesforce.com introduced its Force.com offering,
through which the software-as-a-service giant invited developers to create
cloud-based applications that would run on Salesforce.com's own infrastructure.
I must say that when I first heard about Salesforce.com's efforts to allow
development for the cloud through its own Force.com site, I was a bit skeptical
about the initiative. However, as I started to use the tools and feel my way
around, my doubts gave way to intrigue.
Salesforce.com has assembled a somewhat overwhelming array of development
tools for the service, enough to ensure that developers of various skill levels
and tool persuasions should find a fit path to developing a Force.com
application. I found options spanning from filling out form-based applications
through a Web interface to writing raw code right from my desktop.
Among the numerous tools provided along with this service is a powerful plug-in
for building Force.com applications right from within the Eclipse IDE
(integrated development environment), which I recently put to the test. All
told, Force.com is a very promising addition to Salesforce's line of services
and well worth further evaluation, particularly for organizations already using
Salesforce applications.
Force.com and Eclipse
I focused on the Force.com IDE, an Eclipse
plug-in that enables developers to work from their desktops as they develop
software for deployment on Force.com servers-an approach that reminded me of
the Amazon AWS Toolkit for Eclipse that I reviewed not too long ago. As with
that Amazon plug-in and most other Eclipse plug-ins I've tested, installation
of the Force.com IDE was a snap. The version
of the plug-in I tested didn't yet support the latest Eclipse release, Version
3.5, but since Eclipse lives inside its own isolated directory on my computer,
I had no trouble maintaining simultaneous 3.5 and 3.4 installations.
Development for the Force.com platform is a bit unusual compared with
traditional Eclipse development in that almost all aspects of the development
actually take place on the Force.com servers. As such, when I created a new
Force.com project in Eclipse, I was asked to provide my Force.com credentials,
which were freely available through the Force.com developer site. As I worked
in Eclipse, my code was compiled not on my local machine, but on the remote
Force.com servers. Likewise, when I tested and ran the code, it all took place
remotely. Yet, I found the integration rather seamless and got the feeling that
the code I was working with could have been running locally.
Yet Another Language: Apex
Yet Another Language: Apex
Development for Force.com requires programmers to use a new language called
Apex, which runs on top of the Apex framework. The Apex framework is
fundamental to the Salesforce.com servers and is not new to Force.com-it's been
part of Salesforce.com for several years. At first, I was a little concerned
when I heard that the development would require the use of a new language.
Fortunately, the language has traditional C-style syntax and looks very similar
to Java and C#, so I felt quite at home using it.
However, Apex does differ from C# and Java in certain respects, as conceptually
it behaves similar to a database language, such as T-SQL or PL/SQL. Apex
includes database constructs such as data select statements, transaction
support and triggers. Salesforce has done a beautiful job of integrating data
access right into the language, which is something I've longed for more than
once in my programming career. Take a look at the Apex developer site for more
information.
Because Apex code runs on multitenant servers that are in the cloud, it's vital
that the code doesn't get out of control, thereby hogging resources and causing
other problems on the platform. With that in mind, the Apex language was built
to be monitored by what Salesforce calls a "governor." If you're familiar with
.NET managed code or the Java run-time,
think of either of those on steroids. The governor carefully manages and
monitors the running code-not just its data aspects, but all aspects, including
loops and other control structures, to keep it within isolated boundaries. The
documentation refers to Apex as a "virtual, virtual machine," which seems
fitting.
Other Features
The Eclipse plug-in is certainly full-featured. One particularly cool feature
is for running "anonymous" code right on the remote server, on the fly. Most
developers have probably done this kind of thing before in other languages
(albeit in a locally run debugger) when the developer inspects an object, calls
a member function right in the inspector, and watches the code run right then
and there. Similarly, with the "Execute Anonymous" pane that the Force.com plug-in
provides for Eclipse, I could execute code on the fly on the server and see the
results right in a Results text box.
The Apex language includes support for unit testing, and the Eclipse plug-in
supports this as well. By creating unit tests right in my classes, I could
easily test out my classes on the remote server from within Eclipse. Another
interesting feature is the Schema Explorer, which allows developers to browse
and inspect their database model on the server, graphically, right from within
Eclipse.
The Force.com development site is huge, and the Eclipse plug-in is only one
small piece of it. For those who aren't keen on writing code, the site makes
available various designers that can be used to piece together an entire
application right on the Website. The resulting application will run on the
Force.com cloud as a set of Web pages. There are other design tools available
for building Force.com applications that run inside Adobe Flash or Adobe Air
run-times.
What's more, Force.com applications can be readily integrated with other cloud
services providers, including Amazon's Web Services, Google's App Engine and
Facebook. There are tool kits that work together with Java, as well as .NET.
And there are plenty of developer-contributed libraries (such as AJAX
support), as well as stand-alone tools such as a data explorer.
