Saturday, September 11, 2010 assembles an array of development tools for is a very promising addition to Salesforce’s line of services and is well worth further evaluation

About two year s ago, introduced its offering, through which the software-as-a-service giant invited developers to create cloud-based applications that would run on’s own infrastructure. When I fi rst learned about’s efforts to allow development for the cloud through its own 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. has assembled an almost overwhelming array of development tools for the service— enough to ensure that developers of various skill levels and tool persuasions should find a suitable path to developing a application. I found options that ranged from filling out form-based applications through a Web interface to writing raw code right from my desktop. All told, is a very promising addition to Salesforce’s line of services and is well worth further evaluation, particularly for organizations already using the company’s applications. and Eclipse
Among the numerous tools provided with this service is a powerful plug-in for building applications from within the Eclipse IDE (integrated development environment), which I recently put to the test. I focused on the IDE, an Eclipse plug-in that enables developers to work from their desktops as they develop software for deployment on servers. It’s an approach that reminded me of the Amazon AWS Toolkit for Eclipse that I recently reviewed. As with that Amazon plug-in—and most other Eclipse plug-ins I’ve tested—installation of the 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 platform is a bit unusual compared with traditional Eclipse development because almost all aspects of the development take place on the servers. Therefore, when I created a new project in Eclipse, I was asked to provide my credentials, which were freely available through the developer site. As I worked in Eclipse, my code was compiled not on my local machine, but on the remote servers. Likewise, when I tested and ran the code, it all took place remotely. Yet, I found the integration seamless and felt as if the code I was working with could have been running locally.

Yet another language: Apex
Development for requires programmers to use a new language called Apex, which runs on top of the Apex framework. This framework is fundamental to the servers and is not new to It’s been part of 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 at home using it.

However, Apex does differ from C# and Java in certain respects: 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 fullfeatured. 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 plug-in provides for Eclipse, I could execute code on the fly on the server and see the results 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 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, from within Eclipse.

The 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 cloud as a set of Web pages. There are other design tools available for building applications that run inside Adobe Flash or Adobe Air run-times.

What’s more, applications can be readily integrated with other providers’ cloud services, 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.

Source of Information : eWeek February 15 2010

No comments: