How do we expose functionality on Force.com to be consumed by external clients in Salesforce?

This article lists a few ways of integrating Force.com using Web Services. We can distinguish between situations in order to identify the best possible way to integrate. For example, if we need to have a straightforward data exchange between a client application and Salesforce, we can go with Data Integration options like SOAP API, but in case we need to have some logic before or after the data is committed or sent out of Salesforce, we can opt for Business Logic Integration options like Apex Web Services or Apex Callouts.
Introduction
Most enterprise-level applications have a need to integrate with other applications used by the same organization. These integration usually cater to different layers, like Data, Business Logic, Presentation and Security, depending on the requirement. This helps organizations achieve greater levels of operational consistency, efficiency and quality.

This article, the first in the series Learning Salesforce Integration, outlines a few of the options available for integrating other client applications with the Force.com platform. The main focus is on Web Service integration, including both inbound and outbound to Force.com. The client application considered in this article is Oracle Siebel CRM.

Possible Ways to Integrate with Salesforce Force.com
Speaking further on the different layers and integration features available at each level for an enterprise-level application, we have:

User Interface
Business Logic
Data
User Interface Integration is one great way to surface various applications inside Salesforce with little redesign of each individual app. It provides your users a single point of entry into multiple applications. The most relevant example is Facebook Apps, which appears to be in the Facebook instance but in reality, the content is served from different application vendors.

Source: https://developer.salesforce.com/page/Integration

Business Logic Integration uses Apex Web Services for Inbound and Apex Callouts for Outbound. It typically handles a scenario where business logic is spread across several applications to implement the complete end-to-end business process. An example would be building complex logic on the data received before committing it into Salesforce.

Data Integration uses SOAP APIs and REST APIs. It typically handles data synchronization requirements, where one application in an enterprise acts as the primary source for a particular business object, like Account. It requires no coding in Salesforce, which is an advantage, but then it cannot implement any custom logic.

As mentioned earlier, our focus for the rest of this document will be on the Business Logic and Data Integration layers, which implement Web Services.

Deep Dive
Business Logic Integration helps extend the business logic present in Force.com with  outside platforms. In the case of inbound logic integration, it is handled using Apex Web Services.

Apex Web Services allow us to write logic and expose it as a web service with external applications. It gives us flexibility in adding custom logic before modifying the Force.com standard or custom objects data. We can apply project-specific business logic while exposing web services.

It requires knowledge of Apex for writing the Apex classes that expose web services to be invoked by client applications. The steps involved are:

Creating a global class that is accessible across all Apex scripts and not just the source Salesforce application. It forms the container for everything else.
Creating an inner Apex class that forms the actual request message of the WSDL. Variables that need to be accessed by the other application through the WSDL should be mentioned here.
Creating an Apex method that is exposed as the web service. It defines data mapping the inner class variables to Salesforce objects and fields, any logic that needs to be implemented and the operation to be executed, like insert, etc.
Finally, generating the WSDL from the path Setup | App Setup | Develop | Apex Classes and sharing it with the client application.
Apex Callouts enable invoking external web services that utilize SOAP, and WSDL or REST Services. This way the outbound scenario for web service integration can be handled. Two ways to generate callouts are importing the WSDL into Apex or by HTTP (RESTful) Services classes.

WSDL2Apex: Consuming the WSDL document provided by the client application automatically generates the Apex class. This Apex class handles the rest, like constructing the SOAP XML while invoking the web service, data transmission and parsing the response. You can even manipulate the HTTP Header while sending out a message.
HTTP Services: This is the other way for outbound web service integration that enables Salesforce to integrate to REST-based services. Apex classes like HTTP, HTTPRequest and HTTPResponse support the ability to initiate an HTTP request or response, develop HTTP requests and handle HTTP responses respectively.
Data Integration helps us in maintaining consistency in the application data between multiple systems that need to be in sync. One way we can achieve talking about real-time synchronization of data between systems is by using SOAP APIs, among other available options.

SOAP API lets you create, retrieve, update or delete records, such as accounts, leads and custom objects. With more than 20 different calls, SOAP API also allows you to maintain passwords, perform searches and much more. Use SOAP API in any language that supports web services. It provides two WSDLs to choose from –

Enterprise Web Services WSDL – Used for building client applications for a single Salesforce organization. The enterprise WSDL is strongly typed, which means that it contains objects and fields with specific data types. Customers who use the enterprise WSDL document must download and re-consume it whenever their organization makes a change to its custom objects or fields, or whenever they want to use a different version of the API.
Partner Web Services WSDL – Used for building client applications for multiple organizations. As a loosely typed representation of the Salesforce data model that works with name-value pairs of field names and values, instead of specific data types, it can be used to access data within any organization. The partner WSDL document only needs to be downloaded and consumed once per version of the API.
To access the current WSDLs for your organization, log into your Salesforce organization and from Setup, click Develop -> API -> Generate Enterprise/Partner WSDL. In general, the enterprise WSDL is more straightforward to use, while the partner WSDL is more flexible and dynamically adaptable to different organizations, allowing you to write a single application that can be used for multiple users and multiple organizations.

REST API provides a powerful, convenient, and simple REST-based web services interface for interacting with Salesforce. Its advantages include ease of integration and development, and it’s an excellent choice of technology for use with mobile applications and Web projects.

Security Considerations

Accessing Salesforce data or business logic via any of the above-mentioned inbound interfacing ways requires the client application to authenticate. This authentication is subject to the same security protections that are used in the Salesforce UI. Using valid credentials for the Salesforce organization being accessed, the server authenticates the credentials and, if valid, provides the client application with:

a sessionId, that must be set into the session header so that all subsequent calls to the web service are authenticated
a serverUrl, that is the end point for the client application’s web service requests
Additional security considerations include configuring profiles/permission sets with appropriate features, settings and objects enabled and assigning users to them. One such permission is API Enabled, which needs to be granted to the user for accessing the APIs.

Testing with soapUI

Using the Salesforce-generated WSDLs is not straightforward and therefore, to have a feel for the same you can opt for soapUI as a testing tool before actually getting into real application integration development. The process remains the same, i.e., importing the WSDL as a new project in soapUI and modifying the request message. But few points to remember –

Independent of the path you are following to integrate, i.e., SOAP API or Apex Web Services, there are two steps to implement the inbound integration:Obtaining the session ID and the server URL using the SOAP API login() call
Using these details to invoke the actual operation, like create() or any custom operation exposed using Apex Web Services. The session ID is to be provided in the session header section and the server URL needs to be set as the end point for the actual operation.
Structure the request message per the object and fields that need to be exchanged. For example:Creating/updating relationships using the create() API call, like creating a new Account and Contact, Account being the parent of the Contact.
Creating different unrelated object records in a single call.