TIBCO

An enterprise service bus (ESB) is the key to unlocking value from active business data. Essentially a shared superhighway for data, messages, and events to travel on, it enables systems and applications to communicate and work together.

Connecting systems and applications to a common, bus-based backbone, real-time information can circulate across the environment. Data is instantly available and can be accessed, consumed, and acted on by any system, application, or business processes on the network.

Events happening across the environment can also be made available – providing the visibility and awareness critical to engaging with activity in real time. By including traffic enterprise-wide, you can be more aware of when opportunities and threats emerge and respond with greater precision and control.

Any component can be connected, ejected, or modified without impacting the performance of others. Automatic routing and transforming messages between components ensures data arrives in the proper usable format.

Used as a foundation for a service-oriented architecture (SOA), [TIBCO ESB solution, currently ActiveMatrix] can also help expose valuable data and functionality trapped in application siloes and enable them for reuse. Grid-based architecture provides the capacity to quickly configure load balancing and fault tolerance for high availability and uniform lifecycle management of all services independent of technology.

TIBCO ActiveMatrix® Service Bus is a lightweight enterprise service bus (ESB) that mediates the communication between applications and services by routing and transforming disparate data formats and transport protocols.

It supports rapid development, near-zero coding, and low maintenance. Its standards-based platform reduces complexity and increases flexibility and reuse by replacing hard-coded service dependencies with configuration.

Highly scalable, its elastic backbone can also reliably support high availability requirements, enabling you to quickly onboard services from third-party environments or a TIBCO-based infrastructure.

http://www.tibco.com/products/automation/application-integration/enterprise-service-bus/activematrix-service-bus/default.jsp

Progress Software (formerly Sonic Solutions)

A service oriented architecture (SOA) will change the way you integrate and manage information assets. With a SOA infrastructure, old systems and applications are no longer lost investments – they can be reconfigured as modular services and made available throughout your enterprise.

Having an enterprise service bus (ESB) makes it easy to enjoy the key benefits of a SOA infrastructure, which are maximum flexibility and simplified management. As an added bonus, the enterprise service bus also also makes it easier to reduce the cost of IT investments by better enabling older or legacy systems to be reused.

Moreover, because the ESB primary function is to connect people, processes, and systems with the right information at the right time with greater performance and high availability, the ESB is therefore a fundamental building block for advanced Responsive Business Integration (RBI) architectures.

RBI enhances and complements application development with modular components that enable design for continuous change. And with an intelligent, policy-driven ESB infrastructure to underpin RBI agility, enterprise organizations stand a far better chance of realizing the many benefits of a successful SOA.

Providing flexible integration of distributed services and applications within an SOA, the Sonic ESB distributed architecture combines independently scalable integration services, intelligent routing, and an enterprise messaging backbone. Customers use Sonic ESB to reduce process cycle time, gather and disseminate information, and reliably respond to business conditions as they occur.

Sonic ESB enables the creation of federated services by allowing architects to more easily manage the SOA from any point. Hard-wired dependencies are eliminated through configurable service interaction, so it’s easier to deploy projects initially and – without need for disruptive re-programming – allow them to scale and evolve, extending their value throughout the organization.

Sonic ESB allows all resources to be readily connected and made broadly available across the enterprise – Web services, J2EE applications, legacy message brokers, and more. By making these federated services available for dynamically-configured interaction with other services, Sonic ESB allows the organization to bring IT resources into better alignment with organizational requirements.

An ESB is an infrastructure platform that fills critical interoperability gaps left open in state-of-the-art standards. More importantly, it enables interoperability across dissimilar standards which often exist in modern computing environments. Along the way, it brings a higher level of robustness to the infrastructure necessary to meet the mission-critical performance, reliability and scalability needed by contemporary enterprises.

In the SOA logic chain, interoperability is the predicate to agility and reuse. However, ‘true’ interoperability must be assessed on multiple dimensions, all of which must be in alignment between services if genuine interoperability is to occur. These dimensions of alignment fall into four broad categories: Functional, Structural, Behavioral and Performance.

For a consumer service to use a particular provider service, it must be aligned on the functional requirements. The provider must do what the consumer wants, whether it’s computing a price, looking up a customer, updating and order or responding to an event of interest. While the functionality is up to the service, there are other considerations which may or may not be handled by the service itself.

Structural

 

• . Structural or systemic, alignment might be thought of as aligning the ‘pin-outs’ of an interface. If the pins between a printer and the PC don’t match, the printer won’t print, even if your PC is perfectly capable of driving a serial printer. In SOA, this type of alignment is manifest in the protocols and formats employed by the consumer and provider services. They must align precisely or interoperability will not occur, even if the provider delivers the correct function.

Behavioral.

 

• Behavorial alignment extends to more intangible notions such as semantics and interaction. With respect to semantics, a consumer service may request a ‘customer’ business object, but the provider service produces business objects called ‘party’ and types the object with an attribute enumerated as customer, vendor, partner, supplier, etc. While the provider is capable of producing the desired information, and the ‘pins are in alignment’, the interpretation of the produced result may or may not be natively intelligible by the consumer because the semantics are different. Similarly, with respect to interaction, there may be a consumer that wants to ‘inquire’ for customers when needed, while there may be a provider service that wants to ‘publish’ customer business objects each time one is created or updated. Although all other aspects of interoperability may be in alignment, if one wants to ask for customers and another wants to broadcast them on particular events, there still won’t be interoperability because the behavior of dialog is out of alignment.

•

Performance encompasses issues beyond direct interoperability; these are considerations having to do with Quality-of-Service (QoS) and Quality-of-Protection (QoP), or simply the entire realm of service-level and security-policy. Alignment here is equally critical. If a provider service was built to handle 2 requests per second with 1 second response time, consumers must be aligned with that service-level expectation or realistic production interoperability cannot be achieved. Likewise, if a provider service was deployed with the expectation that it would only be consumed by internal services, and was then inadvertently exposed for consumption by a public audience, it would be out of alignment with expected security policy.

The point to all of this is that real-world interoperability is only possible when all aspects of alignment are achieved. However, the choice of where to implement the last three of these categorical considerations is critical to the question of reuse. While the functional aspects of interoperability indeed rest entirely with the services themselves, if the services also take on the responsibility for structural, behavioral and performance related concerns, reuse erodes rapidly and the chain of logic supporting SOA unravels.

If services were left to ‘fend for themselves’ on all these points they would either come up short on support for requirements essential to certain contexts or they would become increasingly bulky . Moreover, the services would be more costly to develop, operate and maintain and would lead to duplication of those capabilities across multiple services with inconsistencies between them.

On the other hand, services that indeed delegate all these considerations entirely to common infrastructure, become inherently more reusable across more contexts and thus become more agile and manageable at scale—preserving the SOA chain of logic. ESB is this common infrastructure onto which a service can delegate mediation of these concerns. Simply put, ESB is a mediation layer for enterprise SOA whose express purpose is to mediate differences in structural, behavioral and performance characteristics between services.

ESB extends the basic idea of abstraction between participants (providers and consumers) to enterprise scale. ESB permits services (consumers and providers) to interact in a loosely-coupled manner; more so than if they were simply connected point-to-point using the most contemporary loose-coupled standard protocols, like WebServices or Java Message Service, alone. This enables services, and the processes that use them, to change over time, at a faster rate and to a much greater degree, without affecting other services or processes around them.

This is the foundation for agility.

http://www.progress.com/docs/campaign/books/soa_right_way_hvervoort_chapter.pdf

Oracle (from an Oracle Service Bus stand point)

Oracle Service Bus transforms complex and brittle architectures into agile integration networks by connecting, mediating, and managing interactions between services and applications. Oracle Service Bus delivers low-cost, standards-based integration for mission critical SOA environments where extreme performance and scalability are requirements.

Oracle Service Bus 11g extends the performance and scalability leadership of Oracle SOA Suite 11g and Oracle API Management.

Oracle Service Bus 11g introduces new capabilities such as Service Result Cache, RESTful API, and improved performance and availability for organizations using enterprise datacenters, as well as mobile and cloud environments.

 http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html