Software is now increasingly provided as a service; in other words, it is now offered as a hosted application that users access through Web browsers. Many companies see this as an effective way of outsourcing some of their IT requirements. However, they face an increasing number of integration issues as part of this strategy. Many are turning to ESBs for a solution.

As the use of Software as a Service (SaaS) increases, there is a growing realization that companies making use of SaaS applications need to integrate them within their overall IT infrastructure. This means that data needs to flow between the SaaS applications and their other IT systems. SaaS providers typically provide programmatic interfaces to facilitate this.
From the SaaS providers' perspective, there is a danger that the overhead of achieving such integrations could take away from the core values of the SaaS model. The SaaS model offers no installation overhead and is typically priced on a per-user basis. Customers can choose to start with a small number of users and scale up as demand increases. However, the need for integration with other applications can be seen as an upfront cost. It can also delay initial adoption of the software and replace the favorable first impressions of the intuitive browser-based user interfaces with a discussion on reconciling disparate document formats. In addition to providing their core software on demand, SaaS providers are now finding it necessary to provide integration solutions consistent with their on-demand model.

There are a number of different ways in which SaaS providers are addressing these integration tasks. In most cases, the first step is to provide public APIs through which their services can be assessed programmatically. These are typically provided either as Web services (SOAP messages described by WSDL) or through REST style interfaces. In both cases, this means the exchange of XML documents over an HTTP transport. These technologies can be used universally and ensure that regardless of the nature of the customers' IT environment, the technologies will be able to build applications that can make use of the interfaces. In some cases, client-side libraries are also provided for particular environments to further reduce the overhead for customers building integrations.
Even so, SaaS providers are finding that customers' tolerance for integration projects is very low, particularly where claims that "software is dead" have been made. In short, expectations are high and customers are getting more demanding. There are, of course, precedents for satisfying such customer expectations. A number of years ago, I was involved in a project with a leading investment bank. The goal was to reduce costs and increase efficiency by allowing their brokers to submit trade instructions online. One of the defining characteristics of this project was the level of assistance and encouragement that brokers needed in moving to the new online system. After all, the major cost savings would benefit the bank and were not of immediate concern to the brokers.

The bank created a new Web-based front end to allow trade instructions to be entered online. This included a feature to allow batches of trade instructions to be uploaded in files. To facilitate rapid client integration, the bank needed to make it as simple as possible for clients to submit their trade instructions. Rather than mandating a single file format, which would require clients to transform their data before submitting it, the bank allowed clients to submit their trade instructions electronically using their existing in-house file formats. A variety of text formats including CSV and Swift were commonly used by the brokers in this scenario.
At the same time, the bank wanted to encourage a number of clients who where still submitting trade instructions via fax to move online. This was very convenient for the clients so they were reluctant to change, but it involved the overhead of manual re-entry for the bank. Manual re-entry can be error prone and the need for interventions to fix errors drove the costs higher. The use of Excel spreadsheets by the client was very popular in this scenario, so a solution that allowed the spreadsheets to be uploaded rather than faxed was an easy transition for the clients.

As shown in Figure 1, Web-based front ends were created for a number of the bank's back-end systems through the bank's secure Web portal. An Enterprise Service Bus (ESB) was used to provide a Web services interface to which data could be submitted. The ESB was also used to host data transformations that converted from each broker's file formats to the bank's canonical format. The ESB would validate the incoming documents, transform them, and automatically route the data to the correct back-end system. This mechanism could also be accessed by uploading files through the Web portal. In most cases, this was the mechanism preferred by users.

Why was the decision taken to host these integrations? In this case, the logic is very clear. The brokerage firms had relatively little IT infrastructure and didn't have IT staff on hand to start developing Web service clients. The savings provided by eliminating the overhead of data re-entry and the increased efficiency by which new brokers could be integrated justified the cost of developing and maintaining the integrations. Hosting the integrations on the ESB provided a very clean way to isolate this task from the core functions, and allowed them to be managed separately. Good old fashioned customer service was also a factor; solving the integration problem as part of the service provided to brokers gave the bank an advantage over the competition.

Now, let's fast forward to 2007 and take a look at the work the industry is doing with SaaS providers. For the investment bank, the decision to host integrations was straightforward. For today's SaaS providers, similar factors can come into play. In these situations, a similar architecture diagram can be drawn (see Figure 2). These days it's common for the core functionality to be exposed using REST interfaces. An AJAX-enhanced user interface exposes this functionality to the user. The Web services interface sits alongside this, providing document interfaces to the functionality. Hosted integrations can be provided through the use of mediation services that sit in front of the Web service interfaces. These mediations focus on the task of data transformation and of supporting the variety of transports that a customer may need to use - HTTP of course, but also e-mail and FTP.

Hosting integrations is not the only option available to SaaS providers. Customers may be willing to host these integrations themselves. However, they expect assistance in the creation of these integrations and may expect an integration solution to be provided. SaaS providers engage with customers to educate them on the use of their document formats and, in some cases, also develop the data transformations. ESBs are finding a new use as a quick and convenient way to host integrations delivered to customers. ESBs provide the connectivity necessary to extract data from customers' existing systems. They can then use Web services technologies to create secure and reliable links to the SaaS provider. The use of an ESB on the client side also serves as an elegant way to support the two-way exchange of asynchronous messages in situations where the SaaS provider needs to push messages toward the client.

The Web services technology used to facilitate these integrations makes it possible for them to be hosted by a third party. However, the introduction of a third party into these relationships remains an issue as customers or providers may be reluctant to do this. For this reason, the majority of integrations are either hosted on the client side, or by a service provider.

The SaaS use case represents a change in the traditional way in which ESBs are used. An ESB for SaaS needs additional features over and above those of a vanilla ESB.
•  Multi-tenanting support is fundamental to the SaaS model, but good support for it is not available in many ESBs. Hosting integrations on behalf of customers requires that data generated as a result of the messages flowing through the ESB is segmented on a per customer basis. This applies to a whole variety of information stored in log files, activity reporting, and data stored in databases. The segmentation of data in databases also applies to languages such as WS-BPEL, which are heavily dependant on the persistence of data. The SaaS provider may need to make this data available to their customers in order to provide the same level of visibility into their integration solutions as they do for their core services.
•  Scalability and performance requirements for SaaS are typically more demanding than within the enterprise environment. The ability to deploy within a clustered environment is now a must.
•  Productivity tools are vital. It must be possible to create integration solutions quickly for customers. Within the enterprise, integration tasks might have been viewed as one-off projects. For the SaaS provider, they are now a normal part of providing access to their systems to each new customer.
•  The software license model for the ESB needs to be consistent with the on-demand or per-user billing model for the SaaS provider.
•  The ability to deploy client-side instances of the ESB is also important as the SaaS provider may not want to host all the integrations. For this scenario, ease of installation and maintenance is vital as is the need to work within a wide variety of IT environments.

In summary, SaaS providers are finding that in order to satisfy their customers' needs and expectations, they must actively engage in solving the issue of integration. Many are turning to ESBs to assist them in achieving this, either as a means to host integrations or to deliver solutions to their customers.