 |
|
 |
 |
|
|
 
Rich Unger's BlogDomain Specific Language for Cloud ComputingPosted by richunger on September 25, 2008 at 08:09 PM | Comments (8)Domain Specific Language for Cloud ComputingWhen Java programmers first learn about Apex, often their first reaction is, "why build another language?" At first glance, it appears to be a blatant attempt at lock-in. Apex is (dare we say it?) proprietary. The honest truth is that Apex was developed for purely technical reasons. Salesforce.com could have implemented a Java layer to be its platform, or (*shudder*) as an XML schema. (For the record, that was never even seriously contemplated). Certainly both approaches would have resulted in being perceived as more "open". But, lots of things that Apex takes care of for you at a language level would have to be done in libraries, and with a lot less type checking. Instead, we went the route that required the least work on the part of our customers to get their work done. We chose to make a DSL.
So, what's the domain? Well, it turns out that, on a cloud platform, you can make all kinds of assumptions that general purpose programming languages can't.
There is only one database in the world.Database operations don't have to establish a connection (much less manage a connection pool). Also, the object-relational mapping is built into the language. It's even statically typed. Let's say you want the first and last names of all your contacts. In Java, there are many ways to set this up, depending on whether you're using JPA, straight JDBC, entity beans, etc. In general, you must to at least these four things:
In Apex, you'd do just do #4:
Contact[] mycontacts = [select firstname, lastname from Contact];
for (Contact c : mycontacts) {
System.debug(c.firstname + ' ' + c.lastname);
}
That's it. You could even shorten this by putting the query right into the for loop. The language knows how to connect to the DB. There's no configuration involved. I'm not hiding any XML files. Contact is a standard data type. If you wanted a custom data type, you'd configure that through the Salesforce.com UI (no coding). Adding the new type to the DB automatically configures the O-R mapping. Furthermore, if you tried: Account[] myaccounts = [select firstname, lastname from Contact]; ...it wouldn't even compile. Static typing right on down to the query. Try that by passing strings into Jdbc!
There is only one way to expose a web serviceJava can scope methods to be either public, protected, default, or private. Apex has one additional method scope, called webservice:
global class Dictionary {
webservice String getDefinition(String word) {
return "42"; // the meaning of everything
}
}
Saving this class, and doing nothing else, causes there to be a SOAP service deployed on salesforce.com. We also have a javascript library that makes invoking this webservice as easy as making a function call. Yes, it's really that simple. This just blew me away the first time I saw it. It can be this simple because, in this domain, there's conventions for how and where services are deployed, and how clients are authenticated.
Triggers are functions, not objectsThe most common use case for a programming language in our platform is to write database triggers. Triggers are functions, and modeling them as objects just to shoehorn an OO paradigm into this domain is counterproductive. An example of an Apex trigger is:
trigger Foo on Contact(before insert, before update) {
for (Contact c : Trigger.new) {
c.bestFriend = 'Rich Unger';
}
}
In Java, this would have to be something like:
class Foo implements Trigger<Contact> {
public Set
I repeat, this is the most common use case right now. So, triggers are a high-level concept in Apex, on par with classes. That's the beauty of domain specific languages. You take the most important concepts in the domain, and you give them keywords and top-level constructs.
Circling back to opennessOkay, So having a domain specific language is useful. It makes the user more productive. It's still proprietary, right? Well, yes. If you decide to use the Force.com platform and Apex, you're making a tradeoff, gaining speed and convenience and losing the ability to port your application to a self-hosted or competing cloud platform easily. However, this is because you're not writing most of the application yourself, anyway. You're really just customizing and adding to Salesforce.com's existing CRM app. It's not a tradeoff that will appeal to everybody, but for an IT department writing custom intranet apps, or a company that needs CRM and has requirements beyond the vanilla install, it seems like a pretty tempting prospect. After all, the truth is that any custom app developement is an investment in your vendor. You can limit your exposure to lock-in in two ways. You can use only open source software and self host everything. That way, if you change vendors, you just need a new vendor who's familiar with your chosen platform and can learn your code. There will be some cost in bringing that new vendor up to speed, which you attempt to minimize by using as much open, standardized technology as possible. The other way is just to do as little coding as possible in the first place. So long as you have easy access to your data, you can always reimplement. Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
