coupled, asynchronous Service interactions. At the very least, a BPM solution must be used in conjunction with a loosely coupled integration approach to make the business processes runtime activities that coordinate integration. Thus, by itself, BPM solutions are not sufficient to meet SOA requirements. Service-oriented integration The service-oriented integration (SOI) approach uses the architectural guiding principles of Services orientation to construct an ecosystem of Services that business users can dynamically combine and compose into higher-level processes that meet continuously evolving and changing business requirements. SOI approaches transcend brittle, tightly coupled EAI and Business-to-business integration approaches by mandating a separation of the consumer of each Service from the producer of that Service, thus enforcing the critical aspect of loose coupling that is required to allow an integration scenario to evolve automatically to meet business requirements. SOI provides no guidance on how to build the right Services to meet current business requirements, nor does it provide a means to execute Services in the most effective, scalable manner to guarantee long-running interactions. Enterprise standards support ESBs implement standardized interfaces for communication, connectivity, transformation, security, and portability. Supported standards include: JMS for communication, web services, Java EE, and .NET for connectivity to various systems, XSLT and X-query for transformation, LDAP, TLS for security. Modern ESB implementations typically support development in multiple languages. This, combined with the inherently portable ESB infrastructure, makes the ESB a true multi-language, multiplatform enterprise backbone and an ideal foundation for an SOAIF. Fault tolerance, scalability and reliability Several modern ESBs implement a symmetric, distributed architecture in which peer-messaging servers run on multiple nodes of an enterprise network, providing a highly scalable, reliable distributed messaging platform with no single point of failure. Modern ESB architectures combine the benefits of centralized control with distributed, parallel data flow, giving application developers the ultimate flexibility in defining the network topology of choice to route data directly and optimally between services. Ensuring that data flowing between services does not always have to traverse a central point in the network optimizes peer-to-peer network performance. For instance, if one has a process that requires data exchanges between New York and Boston, as well as between San Francisco and Los Angeles, then the two flows of data don’t necessarily have to traverse a messaging hub located in Chicago (which is often the case in most enterprise or cross-enterprise deployments). Instead, efficiency dictates setting up direct data flow connections