The Problem – Supporting Construction and Integration of services in a heterogeneous environment

As a subsidiary of Ebay Inc., and a leading e-commerce company supporting dozens of clients, GSI Commerce needs to support a wide variety of integrations in a heterogeneous environment.

Key to the ongoing evolution of GSI’s e-commerce platform is the ability to integrate core platform capabilities to a wide variety of service integration use cases, and to do so in a cost-efficient, scalable manner that maximizes leverage of existing platform assets while supporting the creation and adoption of new components and services. At the same time, scalability and high availability of the e-commerce platform must continue to be preserved as existing clients experience organic growth and new clients are added to the platform.

An important component of meeting these challenges is both the adoption of a standard services integration framework, and a standard services development framework. The framework must handle the reliable, scalable, and cost-effective integration of pre-existing heterogeneous services spanning clients, providers, and core platform services. That same framework needs also to support the construction of services that are both fully decoupled (logically and operationally), and also capable of handling multiple service-integration patterns, protocols, and formats. Seamless integration with Spring-managed Java components is also an important requirement.

The Solution - Mule as a Standardized Service Infrastructure

Today, GSI leverages Mule ESB Enterprise as a core integration framework, on which GSI has built a standardized service infrastructure. The initial use case involved using Mule ESB to integrate an order management system with an external Web Service. Using the premium WebSphere MQ connector available with Mule ESB Enterprise, GSI integrated an asynchronous WebSphere MQ-based service with a synchronous external Web Service, thus reliably supporting high spikes in Q4 traffic and seamlessly leveraging pre-existing integration capabilities of the existing application.

GSI takes a pragmatic approach to service development, understanding that internal service integration standards must marry with the reality of a wide spectrum of external service protocols/formats/standards that exist in the real world. Using Mule ESB, GSI can expose WebSphere MQ, COTS, or POJO component services as either REST or SOAP-based web services. In addition, external service integrations of various styles and security requirements can be exposed internally with a canonical service contract. With Mule ESB, the service teams have the freedom to choose the right approach based on the particular integration requirements, leveraging best-practice integration patterns. For example, in one use case involving security requirements, Mule acts as a proxy between a SOAP WS interface and an external WS-Security interface using Mule’s out-of-the box CXF transport.

Even in the early phases of implementation, GSI has seen significant returns from deploying Mule ESB:

“Mule has proven to be a cost effective solution – allowing us to standardize on a single service integration solution versus rolling dozens of services built several different ways,” said Jeffrey Trimm, Principal Architect, GSI Commerce. “It helps us lower our development costs and allows us to respond quicker to our clients’ needs.”

GSI’s clients demand a high standard for uptime and performance levels from GSI’s e-commerce services. In order to monitor and manage all of the distributed systems and services, Mule HQ is leveraged to get a view into key performance indicators in a central place. Over time, GSI will look to gain even more control over their services through tools like Mule Galaxy, a design-time registry/repository, and by integrating other governance tools that can manage service performance at runtime.

“We are a 24x7/365 shop where high availability is a critical requirement for us, along with scalability to volumes that start with tens and hundreds of transactions per second and grow from there” added Trimm. “So far, in terms of Mule’s performance in production, we are quite happy.”

Selecting MuleSoft

In its initial evaluation of ESB solutions, GSI considered both open source and proprietary solutions. GSI found Mule ESB attractive based on a strong match with its requirements for a service integration framework. GSI also considered Mule ESB’s maturity, having been adopted and deployed by many significant companies over a number of years.

In addition to architectural requirements, total cost of ownership (TCO) was also a factor in selecting a solution. GSI conducted a detailed cost analysis, and MuleSoft’s open source subscription model came out on top as delivering the best value. It was clear that to support their transaction volumes, GSI would need to scale horizontally. This fact effectively eliminated the proprietary options, all of which would require hefty up-front licenses in the range of tens of thousands of dollars per CPU.

Because MuleSoft’s open source model allowed GSI to download and try the product on their own, they decided to conduct a short pilot project involving several integration use cases. Within four months (including three months of actual development), GSI had proved out multiple service integration patterns and put a working service in production, declaring the pilot a success.

MuleSoft’s support offering was a primary driver in selecting the Mule ESB Enterprise subscription:

“Given the critical nature of our Mule services combined with our high availability requirements, having Platinum-level support is a key driver for us to meet our SLAs,” concluded Trimm. “What’s great about MuleSoft’s support offering is that it includes both production-time and development-time elements. In addition to support for our production environment, we find it tremendously valuable to be able to ask questions about how to use particular features or architect flows at design and development time.”