对于EIP现在已经谈论的很少，但是在10年前还在EAI企业应用集成阶段的时候却谈论的相当多，可以将EIP模式基本将企业应用系统间围绕消息集成和传输和转换的场景全部将清楚了。
对于EIP大家可以先看下官方的一些介绍材料 http://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html ，引用官方的一个图参考如下：
一个围绕消息集成的企业应用集成场景基本在上面的图中描述的比较清楚的，简单说明如下
1)消息发送方和接收方：可以是异构的业务系统，但是都需要提供Endpoint实现集成。
2)消息本身：两个应用系统通过channel连接，实现了消息本身的发送和接收操作
3)消息Channel：即消息传输的通道，消息本身必须要通过channel来实现传输，从源到达目标。
4)消息路由：当有多个目标接收方的时候，如果根据消息的特征来确定究竟发送到哪个接收方?
5)消息转换：消息在传输过程中是否需要进行转换和数据映射，包括报文格式转换和内容转换映射。
6)Pipe and Filter：在执行复杂的消息流处理时，如何维护消息本身的独立性和灵活性。
一个完整的应用集成系统或消息中间件产品基本应该包括以上的所有组件内容。对于EIP本身，我们在企业应用集成过程中可以参考该模式进行实现，但是具体的实现层面的产品则可能有多种。有可能是复杂和完善的ESB服务总线，消息中间件平台，也可能是简单的消息系统。在这方面EIP并没有进行强制约束，对于官方给出的可以参考EIP模式实现的产品建议主要包括了如下：
EAI and SOA platforms , such as IBM WebSphere MQ, TIBCO, Vitria, Oracle Service Bus, WebMethods (now Software AG), Microsoft BizTalk, or Fiorano.
Open source ESB 's like Mule ESB, ServiceMix，JBoss Fuse, Open ESB, WSo2, Spring Integration, or Talend ESB
Message Brokers like ActiveMQ, Apache Kafka, or RabbitMQ
Web service- or REST-based integration , including Amazon Simple Queue Service (SQS) or Google Cloud Pub/Sub
JMS-based messaging systems
Microsoft technologies like MSMQ or Windows Communication Foundation (WCF)
可以看到以上多种产品都可以参考EIP模式来实现企业应用集成的各种场景。
结合ESB企业服务总线的设计和实现，可以来看下以上各个子系统或组件在构建的过程中可以参考EIP模式和消息集成的一些具体点。
首先围绕业务系统本身的接入和适配，即上面Endpoint部分的内容，在这里对于ESB服务总线而言更多的是通过适配器来进行了实现，而适配器本身基本就包括了各种常见的协议，消息和数据库，第三方面中间件的适配工作。通过适配后我们即可以从一个原有封闭的业务系统内部获取到我们需要的消息流。
消息的适配：当前实际包括了JMS和AMQP两种消息协议，适配这两种基本可以适配所有消息中间件。
数据库适配：对于数据库适配，更多的是对数据库连接的适配，即建立了JDBC连接池适配后本身就可以支持多数据库的接入能力，当然也可以针对特定数据库单独适配，如适配Oracle 存储过程等。
FTP和文件适配：通过适配后可以通过FTP文件传输协议实现文件的读写和传输工作。
HTTP协议适配：在ESB总线中逐渐大量应用，包括基于Http协议的SOAP消息也是Http协议适配的一种
TCP适配：TCP是在原有的分布式CS类应用中大量使用，实现高性能的消息传输
适配的目的不是简单的做代理或透传，因此通过适配后我们实际是拿到了完整的消息报文信息。这个消息报文本身需要通过Channel传输到业务系统接收方。
对于Channel而言，在EIP模式中也有详细的描述，而里面最常见的主要有点对点的传输，基于消息的发布订阅模式，还有就是消息总线模式，通过消息总线来实现对所有消息的集成和适配。
在消息体本身的描述中，EIP参考文档中将消息分为三个类型的消息，1. Command Message 2. Document Message 3. Event Message。这些消息基本在我们的服务集成中都会出现，特别是文档类消息体或事件类消息体，在EDA事件驱动架构中则会大量使用事件消息流。而对于第一种命令类消息，在CQQS模式的实现过程中可以看到会大量使用。对于1和3本身区别并不太大，而3更加强大了事件本身的1对多分发。