|Enterprise Integration Patterns|
|HOME PATTERNS RAMBLINGS ARTICLES TALKS DOWNLOAD BOOKS CONTACT|
Patterns and Best Practices for Enterprise Integration
Today's applications rarely live in isolation. Users expect instant access to all functions, which may be provided by disparate applications and services, inside or outside the enterprise. Integrating applications and services remains more difficult than it should be, though: developers have to deal with asynchrony, partial failures, and incompatible data models. The lack of a common vocabulary and body of knowledge for asynchronous messaging architectures made it difficult to avoid common pitfalls.
That's why Bobby Woolf and I documented a pattern language consisting of 65 integration patterns to establish a technology-independent vocabulary and a visual notation to design and document integration solutions. Each pattern not only presents a proven solution to a recurring problem, but also documents common "gotchas" and design considerations.
The patterns are brought to life with examples implemented in messaging technologies, such as JMS, SOAP, MSMQ, .NET, and other EAI Tools. The solutions are relevant for a wide range of integration tools and platforms, such as IBM WebSphere MQ, TIBCO, Vitria, WebMethods (Software AG), or Microsoft BizTalk, messaging systems, such as JMS, WCF, Rabbit MQ, or MSMQ, ESB's such as Apache Camel, Mule, WSO2, Oracle Service Bus, Open ESB, SonicMQ, Fiorano or Fuse ServiceMix.
Buy the book Enterprise Integration Patterns or read a sample chapter first. Find the most recent content in my blog or articles. Please contact me if you have feedback or would like me to speak at your company or event. The book received numerous accolades, e.g. from Forrester Research:
"The core language of EAI, defined by Gregor Hohpe and Bobby Woolf, is also the core language of defining ESB flows and orchestrations, as seen in the ESB's developer tooling."
New Book: The Software Architect Elevator
As the digital economy changes the rules of the game for enterprises, the role of software and IT architects is also transforming. Rather than focus on technical decisions alone, architects and senior technologists need to combine organizational and technical knowledge to effect change in their company’s structure and processes. To accomplish that, they need to connect the IT engine room to the penthouse, where the business strategy is defined.
This books equips architects and IT leaders with the technical, communication, and organizational skill to successfully effect lasting change. Available now on Amazon.
Work-in-progress: Conversation Patterns
Asynchronous messaging is the foundation for most integration solution because its architectural style acknowledges the challenges of distributed communication, such as latency or partial failure. However, many interactions between systems extend beyond sending a single, stateless message: a request may expect a response; a handshake or authentication are needed first; a reservation is confirmed or expires. Such conversations, stateful exchanges between participants, present new design challenges and patterns. I therefore started documenting Conversation Patterns, which are the starting point for Enterprise Integration Patterns 2.
What Makes Integration Difficult?
Architecting integration solutions is a complex task. There are many conflicting drivers and even more possible 'right' solutions. Whether the architecture was in fact a good choice usually is not known until many months or even years later, when inevitable changes and additions put the original architecture to test. Unfortunately, there is no "cookbook" for enterprise integration solutions. Most integration vendors provide methodologies and best practices, but these instructions tend to be very much geared towards the vendor-provided tool set and often lack treatment of the bigger picture, including underlying guidelines, principles and best practices.
Asynchronous Messaging Architectures
Asynchronous messaging architectures have proven to be the best strategy for enterprise integration because they allow for a loosely coupled solution that overcomes the limitations of remote communication, such as latency and unreliability. That's why most EAI suites and ESB's are based on asynchronous messaging. Unfortunately, asynchronous messaging is not without pitfalls. Many of the assumptions that hold true when developing single, synchronous applications are no longer valid. Vendor-independent design guidance helps developers avoid these pitfalls so they can build robust integration architectures based on asynchronous messaging.
How can Patterns Help?
Patterns are a proven way to capture experts' knowledge where no simple “one size fits all” answers exist, for example in application architecture, object-oriented design, or message-oriented integration . Each pattern tackles a specific problem by discussing design considerations and presenting an elegant solution that balances often conflicting forces. The solution is not the first approach that comes to mind, but one that has evolved through actual use over time, capturing the experience that senior developers and architects have gained by repeatedly building solutions and learning from their mistakes.
What am I Reading Right Now?
|© 2020 • All rights reserved.|