Salesforce.com initiated a platform called Force.com as its foray into the cloud computing platform market. It helps commercial software developers create cloud-based applications based on Salesforce.com’s development environment. In addition, applications developed with Force.com’s tools can also make the most of the CRM applications.
At the heart of this platform is the multi-tenancy architecture. This suggests that applications made with Force.com assume that users will share a single physical circumstances. However, those circumstances and the application code integrateded those circumstances are isolated from each other.
The Force.com platform is centered around a development stack that includes the following parts:.
Metadata architecture: Salesforce.com required a metadata architecture to support its multi-tenancy approach. Salesforce.com considers this metadata stack as the core of its distinction in the market. The metadata layer is complicated and consists of an application server called Resin, a high-performance XML application server.
Service delivery infrastructure: Salesforce.com’s cloud distribution infrastructure is based upon its handled and secure data center environment. This is the same infrastructure made use of to manage its CRM customers.
Database as a service: The database is built on top of the metadata services. The data services provide information security by enabling customers to proclaim validation rules (such as confirming that an account number stands). It allows consumers to develop personalized objects and fields. The customer isn’t really accountable for database tuning, backup, or upgrades, due to the fact that of the cloud infrastructure.
Integration as a service: At the center of Force.com’s integration capabilities is a Web services Application Programming Interface (API). This API permits customers to gain access to data stored in a Force.com application because it supports industry-standard SOAP Web services.
Logic as a service: This is a set of automated workflow services. A built-in workflow engine includes services such as task creation, record assignment, and other event-triggered services. Clients can use a Salesforce.com programming language (called Apex) as a way to extend the application by writing new code.
User interface as a service: Force.com provides two ways of building or customizing user interfaces:.
A builder to change the application layout and Visualforce.
A framework for building user interfaces for both personal and public clouds.
Developers can utilize conventional Web development tools including HTML, AJAX, and Adobe Flex.
Development as a service: Development tools include the Metadata API, an IDE (Integrated Development Environment), a development sandbox (a separate development space for developers), and a service called Code Share for building cloud-based applications.
AppExchange marketplace: This site enables vendors that have used the Salesforce.com interfaces. It is, in essence, a channel for partners to offer into the installed base.
Like numerous Platform as a Service suppliers, Salesforce.com allows independent software vendors (ISVs) and commercial developers to join their Force.com program without any startup costs. If a developer is selling to existing Salesforce.com customers through AppExchange, there’s no expense to the ISV. Nevertheless, if an ISV sells an application to a brand-new customer that isn’t utilizing Salesforce.com, there is an embedded license charge of $15 per user per month.
Most specialists will argue that cloud computing is the future of software and that application development will end up being far easier as a result. We agree with this assessment and begin our exploration of cloud development with the Force.com platform supplied by Salesforce.com. Below are couple of benefits and disadvantages connecting to development on the Force.com platform.
Advantages
1 – Quick access to Salesforce’s existing 82,400 company user base (which has money to spend) through the AppExchange (only a $300 listing cost).
2 – Piggy back off Salesforce’s powerful existing performance, including:.
-User management and authentication.
-Administrative user interface.
-Reporting and analytics.
-Dynamic API.
-Toolkits and integrations for other languages and platforms.
3 – PaaS offering allows you not to worry about server maintenance or architecture.
4 – Governor limits and test code coverage enforce some degree of best practice.
5 – Security, both because of code review and because of high degree of control on the platform (see # 2).
6 – Java-like syntax speeds learning curve for new developers.
7 – Native “Visualforce” elements allow quick and easy information output.
8 – Active community. Lots of information out there and active participation from Salesforce personnel.
9 – Object metadata can be leveraged for effective functionality.
10 – Actively under development (Big things underway with VMForce).
Disadvantages
1 – APEX is not a completely featured language.
-Lots of things you might wish existed aren’t.
– You will have to port them yourself or make outbound webservice calls.
2 – Hard to know if you will truly make money.
-Hard to impossible to find revenue numbers for the AppExchange.
-Per-user licensing creates a pretty linear margin on license fees (as opposed to potentially exponential on a metered system like GAE or EC2).
– Data based pricing makes it pricy for folks with great deals of data.
3 – Debugging can be extremely slow:.
– No real debugger.
– Places where you don’t even have a debug log (not made it possible for, in a managed package, reached the limit, or weird errors that don’t leave an entry).
– Unfixed bugs or quirks on the platform that you wouldn’t expect (i.e. undocumented differences between commandLink and commandButton).
4 – Ideaexchange and other reporting tools tend to be admin focused.
and geared towards new features, not fixes or better developer tools.
5 – Governor limits sometimes make sense, but at other times they can be very difficult and prevent what would be best practice. Very easy to get in a place where you are trapped by a governor limit and very hard to know ahead of time whether or not any given practice you will take there (unless you already have a great deal of time playing “evade the governor restriction” ). These are doubly a trouble when it comes to test coverage.
6 – Developer tools continue to be somewhat doing not have (even though the Force.com IDE runs in Eclipse you can’t use many of the Java focused extensions and build time is slow).
Summary
Part of the need below is understanding where PaaS is today, and the truth is that while PaaS as a service beyond IaaS, while developing quickly, is not yet a platform prepared for development of huge enterprise ready apps. It is fine for extensions of existing technology, however beware if you attempt for a lot more than this. This does not reflect poorly on Salesforce.com as they have been pushing the envelope on what is possible with all the force available to them. There are at the moment very many useful and potentially profitable things that can be done with the platform and if you have the time and resources, I strongly suggest doing them (or at least getting your feet wet while waiting for things to develop further).
