| Before going on to discuss the core components of an ESB, it is important to examine some new diagramming notations that are introduced in this chapter. This chapter describes in detail some key concepts of an ESB, and uses a set of glyphs to describe each one. (The Preface to the book goes into an explanation of the history of these glyphs and shows examples of all of them; Chapter 11 will show how these glyphs can be used together to form sketches for integration patterns.) Figure 6-5 depicts a generic ESB endpoint. Figure 6-5. Generic ESB endpoint 
Throughout this book, an endpoint will always be shown as residing inside a service container, the details of which will be explained later in this chapter. There are different types of endpoints in an ESB, each with its own style of representative icon. Figure 6-6 shows how a SOAP or web services endpoint is visualized. Chapter 2 showed one of these in the "Refactoring to an ESB" section. Figure 6-6. SOAP or web service endpoint 
In Figure 6-6, the ESB endpoint that is labeled "HTTP" is an endpoint that uses the HTTP protocol. The HTTP endpoint either exposes a web service interface or acts as a client of a web services interface. Figure 6-7 shows the icon for an ESB client API endpoint. The client interface exposes methods that an application or service would use to plug into the bus. For a Java client, the application interface would be JMS. For a C++ or C# client, the API would likely mimic the JMS API, but be implemented in either C++ or C#, respectively. For a custom ESB service, there can be a service API that exposes a DOM, SAX, or some other form of interface that treats a service invocation as an inbound SOAP message. Figure 6-7. ESB client API endpoint 
The dashed line between the ESB and the service container is a connection, usually a MOM connection. Note that the C++ client happens to be shown as slightly detached from the endpoint and the service container. This illustrates a separation between the physical implementation of the C++ client and the endpoint. For example, the ESB service container may be implemented in Java, and the C++ client may be hooked into the container using the Java Native Interface (JNI) or via a network layer. The client may also use the native on-the-wire protocol of the underlying MOM directly. In practice, there may not be a physical container at all. For direct client API connections or protocol connections, the container may be more of an abstract concept than a physical implementation. The container is conceptually part of the bus, and therefore the dotted connection line is a virtual connection in the abstract sense. It may map to an underlying MOM connection in the physical implementation. The endpoint definition and the invocation and management framework could be transparently built into the bus fabric instead of being represented by a physically separate Java, C++, or C# process. These implementation details would also depend on the ESB vendor. The point is that these are representative forms of showing a service container with an endpoint. You, as the integration architect, have the flexibility to choose the appropriate rendition that most closely matches your perspective. Figure 6-8 shows examples of the various connection types and protocols that an ESB should be able to support. They will be explained in more detail in the next section. Figure 6-8. ESB endpoints with various client types and protocols associated with them 
| 