I am reading  the definitive guide to SOA these days. Not a reference book indeed, does not cover the whole SOA landscape either; however, it is easy readable and contains some best practices about Aqualogic(a.k.a. oracle) ESB.

The reasons to buy/obtain/use an ESB is summarized as follows:

Loose Coupling

You might have heard that web services provide you with loose coupling between systems.This is only partially true.Web services, by the very nature of Web Services Description Language(WSDL) and XML Schema Document (XSD), can provide some loose coupling becausethey formalize a contract between the service consumer and the service provider. This is a“design by contract” model, and it does provide tangible benefits. If you’re careful, you cancreate a schema that’s platform neutral and highly reusable.

However, if you take a look at any WSDL you’ll see that the service endpoints are written into the WSDL, as you can see:

<service name=”HelloWorldService”>

<port binding=”s1:HelloWorldServiceSoapBinding”

name=”HelloWorldPortSoapPort”>

<s2:address location=”http://www.bea.com:7001/esb/Hello_World&#8221; />

</port>

</service>

By specifying a specific machine and port (or a set of machines and ports), you’re tightly coupling this service to its physical expression on a specific computer. You can use a DomainName Server (DNS) to substitute portions of the URL, and therefore direct clients into multiple machines in a server farm. However, DNS servers are woefully inadequate for this, due to their inability to understand and manage the status of the services running on these servers.

So, loose coupling isn’t achieved by WSDL or web services alone. A more robust solution is to provide some mediation layer between service clients and service producers. Such a mediation layer should also be capable of bridging transport and security technologies. For example, a service might be invoked through a traditional HTTP transport mechanism, but it can then invoke lower-level services through Java Message Service (JMS), e-mail, File Transfer Protocol (FTP), and so on. This approach is often effectively used to “wrap” older services and their transports from the newer service clients.

Location Transparency

Location transparency is a strategy to hide the physical locations of service endpoints from the service clients. Ideally a service client should have to know about a single, logical machine and port name for each service. The client shouldn’t know the actual service endpoints. This allows for greater flexibility when managing your services. You can add and remove service endpoints as needed without fear of having to recompile your service clients.

Location transparency is a strategy to hide the physical locations of service endpoints from the service clients. Ideally a service client should have to know about a single, logical machine and port name for each service. The client shouldn’t know the actual service endpoints. This allows for greater flexibility when managing your services. You can add and remove service endpoints as needed without fear of having to recompile your service clients.

Mediation

An enterprise service bus is an intermediary layer, residing between the service client and the service providers. This layer provides a great place for adding value to the architecture. An ESB is a service provider to the service clients. When clients use a service on the service bus, the service bus has the ability to perform multiple operations: it can transform the data or the schema of the messages it sends and receives, and it can intelligently route messages to various service endpoints, depending on the content of those messages.

Schema Transformation

The web service published by the service bus might use a different schema from the schema of the business service it represents. This is a vital capability, especially when used in conjunction with a canonical taxonomy or when aggregating or orchestrating other web services. It’s quite common that a service client will need to receive its data using a schema that’s significantly different from that of the service provider. The ability to transform data from one schema to another is critical for the success of any ESB.

Service Aggregation

The service bus can act as a façade and make a series of web service calls appear as a single service. Service aggregation follows this pattern, making multiple web service calls on behalf of the proxy service and returning a single result. Service orchestration is similar to service aggregation, but includes some conditional logic that defines which of the lower-level web services are called, and the order in which they’re invoked.

Load Balancing

Due to their position in any architecture, ESBs are well suited to perform load balancing of service requests across multiple service endpoints. When you register a business web service with AquaLogic Service Bus (ALSB), you can specify the list service endpoints where that business service is running. You can change this list, adding or removing service endpoints without having to restart the ALSB server.

Enforcing Security

You should enforce security in a centralized manner whenever possible. This allows for a greater level of standardization and control of security issues. Furthermore, security is best enforced through a policy-driven framework. Using security policies means that the creation and application of security standards happens outside the creation of the individual web services.

Monitoring

An ESB plays a vital role in an SOA. As such, you must have a robust way to monitor the status of your ESB, in both proactive and reactive manners. The ability to proactively view the performance of the service bus allows you to help performance-tune the service bus for beter performance. Tracking the performance over time can help you plan for increasing the capacity of your ESB.

Reactive monitoring allows you to define alerts for specific conditions. For example, if a specific service doesn’t complete within a given timeframe, the ESB should be able to send an alert so that a technician can investigate the problem.

Configuration vs. Coding

A modern service bus should be configuration based, not code based. For many engineers the importance of that statement isn’t immediately obvious. It took us some time before we appreciated the configuration-oriented capability of ALSB. Most software systems in use today are code based. J2EE applications are a great example of this. In a J2EE application you write source code, compile it into an EAR or WAR file, copy that EAR or WAR file onto one or more J2EE application servers, then deploy those applications. Sometimes it’s necessary to restart the J2EE server, depending on the nature of your deployment.

Configuration-based systems work differently. There’s nothing to compile or deploy. You simply change the configuration and activate those changes.We would argue that your telephone is configuration based; you configure the telephone number you want to call, and your call is placed. There’s no need to restart your phone. Similarly, network routers and switches are configuration based. As you make changes to their configuration, those changes take effect. There’s no need for a longer software development life cycle to take place.

Configuration and coding are two different strategies. Neither is superior to the other in all situations. There are times when the J2EE approach is the right approach, and times when the configuration-based approach is best.