EAI is still appropriate wherever it makes sense (but I would not take this approach any more). The architecture approach is ADAPTOR-->TRANSFORMATION--->BUSINESS PROCESS -->TRANSFORMATION--->ADAPTOR which leverages EAI tool like TIBCO, WebMethods, WLI, etc. Is this truly SOA? No! - it is basically a point-to-point implementation on a Hub. The developer of the process need worry about all the protocol translation, routing, etc. and this is generally tightly coupled with the business process.
ESB on the other hand decouples the protocol translation, message/event routing, limited message validation, etc. and is targetted for use by IT Operations. Developers need not worry about all these details, which makes it faster to roll out new services. However, to make this a vaiable approach within an enterprise, there
is definitely a greater emphasis on architcture.The ESB also enables servcie abstraction at various levels, thereby enabling multiple teams to develop a particular service. In addition, with it's integration with the Service Registration and Management Capability it definitely makes it easier for IT Operations to track and provide the SLA requested by the business. The above diagram illustrates (Source: Paul Patrick - Chief Architect for Services Infrastructure, BEA Systems) how the ESB enables creating a grid within the enterprise - allowing each business unit / organization to grow at their own pace.
