At its core, a good SOA should have a good messaging infrastructure, and JMS is a fairly good example. But it obviously will not be the only implementation supported. Other capabilities that an ESB provides include:
? Process orchestration, typically via WS-BPEL.
? Protocol translation.
? Adapters.
? Change management (hot deployment, versioning, lifecycle management).
? Quality of service (transactions, failover).
? Qualify of protection (message encryption, security).
? Management.
Access control lists (ACLs) are important and complimentary to security protocols, such as WS-Security/WS-Trust, and often overlooked by existing implementations. We'll want to investigate how JBossESB will support ACLs are part of the security capabilities.
Many of these capabilities can be obtained by plugging in other services or layering existing functionality on the ESB. We should see the ESB as the fabric for building, deploying and managing event-driven SOA applications and systems. As mentioned earlier, there are many different ways in which these capabilities can be realised and JBossESB does not mandate one implementation over another. Therefore, all capabilities will be accessed as services which will give plug-and-play configurability and extensibility options.
This overall approach will allow for better "best-of-breed" solutions, where vendors and users can swap out components from the core ESB and swap in replacements that maybe offer better performance or reliability for specific use cases (for example), but at a higher price.
