To do this we use the Force.com platform's Visualforce markup language. Visualforce uses HTML-like tags (actually, more similar to Java Server Faces) to produce different visual constructs. In our case we need to display the return value from our getAccountBalance service in such a way that the user is unaware that the balance is being provided from an external web service.

The following is the Visualforce used on our Financial Account page to show the Account Balance:

<apex:page standardController="Financial_Account__c" extensions="AccountServiceController">
   <apex:pageBlock >
       <apex:pageBlockSection columns="2" >
           <apex:pageBlockSectionItem >
               <apex:outputLabel value="Account Balance"></apex:outputLabel>
           </apex:pageBlockSectionItem>
           <apex:pageBlockSectionItem >
               <div id="AccountBalance">{!AccountBalance}</div>                
           </apex:pageBlockSectionItem>            
       </apex:pageBlockSection>
       <apex:pageBlockSection columns="2" >
       </apex:pageBlockSection>
   </apex:pageBlock>
</apex:page>

The Visualforce tags define a two column table for the label 'Account Balance' and the variable {!AccountBalance}.

Visualforce automatically calls the get method defined in current controller: getAccountBalance. This method invokes the external web service and returns the AccountBalance value for display to the user in real-time. This is the secret sauce of the mashup. While standard controllers pull data directly from Force.com standard and custom objects, we need an account balance that isn't available in the cloud. Instead we integrate with an on-premise Web Service to provide the needed sensitive information. For this we need to utilize an Apex controller extension.

The Force.com Application Controller Layer

The user interface layer has a nice separation of "View" from "Control". This section looks at how to flesh out the controller layer to invoke our web service so that the appropriate data can be displayed.

Notice that the <apex:page> includes the extensions property. This property identifies a controller (the C an MVC) extension called AccountServiceController. This is where we extend the behavior of the standard Visualforce controller for the Financial_Account__c object by adding the capability to retrieve an account balance through integration with an external web service. The following is a complete listing of the Apex class:

global class AccountServiceController {
   Financial_Account__c account;
   String balance ='';    
   // controller
   public AccountServiceController(ApexPages.StandardController stdController) {
       this.account = (Financial_Account__c)stdController.getRecord();        
   }
   //get and set accountbalance
   public String getAccountBalance() {
       String accountNumber = [Select Account_Number__c from Financial_Account__c where Id=:account.Id].Name;
       //Invoke service
       balance = showBalance(accountNumber);
       return balance;
   }
   public void setAccountBalance(String balance) {
       this.balance = balance;
   }
   //Invoke the web service callout  
   static String showBalance(String accountNumber) {
       String accountBalance = '';
       //call Authentication Call out          
       String isValid = AuthenticationCallout();
       System.debug('Auth Result '+ isValid);
       if(isValid == 'true'){
           AccountService.AccountServicePort stub = new AccountService.AccountServicePort();
           stub.setApexTest(testFlag);                    
           accountBalance = stub.getAccountBalance(accountNumber);         
       }
       return accountBalance;
   }
   //Authentication callout (cheap - use two-way SSL for real)
   public static string AuthenticationCallout (){
       HttpRequest req = new HttpRequest();               
 req.setEndpoint('https://aptaria.com:9081/HttpAuthentication/Authenticate');
       req.setMethod('POST');
       req.setBody('username=admin&password=admin123');
       Http http = new Http();
       String result = '';
// Make a real callout since we are not running a test
       HttpResponse res = http.send(req);
       System.debug('Authenticateresult'+res.getHeader('authValid'));
       result = res.getHeader('authValid');
return result;
   }
}

Visualforce automatically call the getAccountBalance method when it attempts to perform variable substitution for the {!AccountBalance} element. This method identifies the AccountNumber from page context using SOQL and calls the showBalance method. The showBalance method first authenticates to the external web service using simple authentication. In a real implementation, you'll want to use a stronger form of integration -- something like two-way SSL for example.

Once authenticated, the method then invokes the AccountService methods auto generated when we imported the WSDL file to invoke the external web service and retrieve the given account's balance. Visualforce then displays the returned account balance to the user transparently, as if the data resided in the cloud.

Pulling It All Together

Our on-premise account balance service is available and Web Service enabled with Apache Axis. Force.com platform network security settings have been configured to allow outbound Web Service callouts to this critical service. The WSDL has been loaded into our application enabling our app to easily invoke our external web service. The Visualforce on our Account page has been modified to pull the account balance using a controller extension. This controller extension has been coded to invoke the code auto generated from our WSDL to call our external AccountBalance Web Service.

When the user logs into our Wealth Management App and navigates to the Financial Account page for a given account number (10001002, for example), the following screen appears:

The key point here is that the account balance for account 10001002 ($12,345.68) appears no differently from the other data about this account page (although there is a slight delay before this field appears because of network latency). The user is unaware that this data is being served from an outside resource. The integration pattern mashup provides seamless and transparent access to this sensitive data.

Additional Integration Scenarios

The demo above focuses on the outbound Web Service invocation use-case, but other scenarios are equally critical to a successful cloud-source strategy. This application can be used to execute an account transfer use-case by invoking a service that updates data in an on-premise application. You can use the built-in Force.com trigger and workflow functionality to perform this whenever data changes, or use the code scheduler to time such transfers at particular periods of the day or week etc.

Conversely, an on-premise application can access business logic and data in an application built on the Force.com platform through inbound integration. To enable this capability one simply adds the webservice keyword to any Apex method - the Force.com stack handles the rest of what it takes to get the web service up. For example, on-premise infrastructure may invoke a Force.com web service to return the total number of accounts available in a Force.com org. Once this Apex method has been web service enabled, one can use the Force.com platform to easily generate its corresponding WSDL file, which can be loaded into external infrastructure for easy integration with your cloud app.

A common use for integration with Force.com is to synchronize data between two complimentary enterprise systems. Many organizations use Salesforce.com for CRM and another application such as SAP or Oracle Applications for ERP. It is critical that these two enterprise systems properly synchronize their Account data. Integration is commonly used for this purpose. As new customers are closed through the Salesforce.com CRM system a web service callout can be used to notify downstream ERP systems for fulfillment and support. Conversely, customers are frequently added directly into ERP systems. In this case the ERP system can notify your app on Force.com of the new Accounts via inbound web service calls.

Other integration scenarios include using email services (sending or consuming emails from trusted sources), and of course invoking HTTP-based service instead of the SOAP ones used in this article.

Summary

This article explores how to integrate the Force.com platform with on-premise Java infrastructure. We have shown how a mashup can be used to seamlessly and securely leverage data and logic from on-premise Java services by integrating them directly into a Force.com application, and sketched other integration techniques.

The Force.com platform offers tremendous capabilities to seamlessly integrate your cloud sourced applications into your enterprise. Applications built on the Force.com platform can easily produce or consume data and services for your existing applications. More developer resources can be found on Developer Force at http://developer.force.com.