ESBs Update Pure Java-Driven IntegrationRead: JavaOne: Unlocking the ESB Secrets
Chappell says that the standards and technologies that will comprise an ESB have matured enough that its safe for Java devs to begin thinking about leaving 100% Java-driven integration behind.
Traditional Java messaging and middleware approaches, he says, focus on one point-to-one-point or one-to-many data transfers. These approaches do not easily upgrade to a services-oriented architecture many-to-many approach for sharing data, as well as higher-level application and business logic as services.
Chappell cites five (5) reasons why CIOs will consider using ESBs, and shift away from traditional integration approaches:
- Increased ability to integrate inter-departmentally, as well as with business partners using standard interfaces and standard protocols.
- Leverage existing IT staff as architects: The amount of information available on Java standards such as JAXP, JCA, and JMS, and XML-related standards such as SOAP, WSDL, XSLT, XPATH and XQuery is expanding at an ever-increasing rate. This means that the average IT professional can readily attain the expertise he or she needs to become the in-house integration architect.
- Reduced vendor lock-in by using a standards-based approach to integrating at the protocol, data and business intelligence layers. ESBs will reduce the appeal of proprietary middleware or integration stacks.
- Reduced need for wide appserver deployments: Because integration functionality and business process routing is inherent in the ESB fabric,, IT shops can avoid the need to purchase and install J2EE app servers at all target and source integration points throughout their organization, simply for the purpose of providing integration functionality.
- More predictable project milestones/deliverables: The ESB standards-based integration approach means that devs can reuse common design patterns and successful templates/models from project to project, without expensive consultants and vendor lock-in.