CRM applications expose business services and workflows as Web services. Business services are functions that take input and return output while performing business logic (usually acting upon a set of CRM business objects). Workflows are similar to business processes and follow a sequential execution of steps. A step can be an invocation of a business service or input from the CRM event framework (such as an order create event, which can start a workflow), or an invocation of a CRM scripting service. Internal CRM business objects are typically not exposed as Web services, because interactions at that layer are too fine-grained and have a number of interdependencies. Working with business objects requires an understanding of the relationship between objects (for example, object opportunity is related to contact and activity, while contact is related to account, and account is related to product), rendering it unsuitable for SOA. As a result, a higher level of abstraction (business services) is preferred. Commonly, a Java API can access business objects (and for other interfaces). In addition to Web services and Java, most CRM systems support messaging interfaces such as the Java Message Service (JMS).

Using Web service interfaces, CRM applications also provide tools and wizards to help create bidirectional-process-based integrations (inbound to and outbound from CRM applications).

In an outbound integration, CRM invokes an external application such as BPEL. This is a common use case in which the order (after capture in CRM) is passed to back-end ERP for fulfillment, with BPEL as the middleware layer.

Since CRM invokes an external service endpoint, it must consume the external endpoint Web Services Description Language (WSDL). In this case, the endpoint is a BPEL process. As mentioned earlier, every BPEL process is a Web service, and capturing the WSDL is straightforward. Many CRM applications provide wizards that allow users to import external WSDLs and automatically generate the integration objects and Web service proxy that will be used to invoke BPEL.

The CRM developer then uses a CRM workflow to tie the data to be passed to the BPEL process. In this case, sending order information to ERP can be accomplished by placing a submit button on the customer-facing order UI, thereby kicking off a workflow when the button is pressed. The workflow uses an out-of-the-box CRM business service to extract the order information, then runs through a set of steps (including mapping from the CRM internal data model to integration objects), and finally invokes the Web service proxy that was generated when the BPEL-process WSDL was consumed. The proxy delivers the integration-object-based payload to BPEL, which then processes the order and runs the enterprise-wide, order management business process that integrates with the back-end ERP.

Inbound integration to CRM, such as external applications calling a CRM Web service, is simpler. The CRM admin console, which is a Web-based UI, provides mechanisms to expose business services and workflows as Web services. This generates a physical WSDL file that can be saved and consumed by external applications such as BPEL to invoke a CRM Web service. On the tooling side, CRM applications provide both desktop and browser-based tools to import and export WSDL, define input and output parameters, create schemas for exchanged objects, and autogenerate a number of artifacts required to tie the Web service calls to internal elements.

Figure 3 provides a list of order management services exposed by a CRM application, and Figure 4 shows these order management services inside a CRM admin console.

Each of these services is based on an internal business-service or a workflow implementation. Figure 4 exposes the details of ports and operations for order service within the order management component. Most CRM services have a common set of operations, such as insert, delete, query by ID, and query by example.

In summary, most CRM technology stacks provide capabilities for bidirectional Web services interactions. In addition, they support Web Services Security (WSS) and allow the invocations to be secured. Together, these present a formidable set of capabilities on which to build distributed service-enabled and process-centric solutions.

Implementing a SOA-Based Solution for Order Management
In this section, we investigate how best to integrate and orchestrate a robust set of CRM services using SOA infrastructure products such as BPEL and ESB.

A heterogeneous order management solution interacts across multiple applications. Figure 5 provides a component interaction view, which has been color-coded to indicate the application (CRM, ERP, or both) they reside in. A number of variations are possible, and Figure 5 highlights the complexity of interactions.

Customers can order via multiple channels, including Web, call center, and other devices. An order submission initiates a number of interactions between components, as indicated by the green lines. These interactions can be bidirectional, synchronous, and asynchronous, and can also be processed in real time or in batches. Order validation and policy enforcements require that the components are called in a specific sequence. The back-end service invocation sequence will vary based on actual user clicks from the UI. Key components that require integration and orchestration include pricing, catalog, configurator, customer data, product data, fulfillment, and invoicing, as well as the human operators who work with each of these systems.

Such a complex problem is best handled by a layered architecture. To capture multichannel customer interactions, a robust, Java-based application development framework is used in the user-interaction layer. BPEL is deployed to integrate people and processes, and ESB is put in place to provide granular Web services across diverse back-end applications. This converts application-proprietary APIs to Web services (using adapters) and aggregates low-level, fine-grained services into higher-level, coarse-grained services that can be consumed by business processes. The end goal is to create a layered architecture as shown in Figure 6.

• SOA & Cloud Computing To Intersect This Week at SOA World