| Figure 6-4 highlights some examples of client types and connection points, covering a broad range of options. The middleware at the core must be capable of supporting multiple connectivity choices. Providing a single JMS interface or a proprietary C-based interface is not enough. Diversity in connectivity is a core capability that is fundamental to making the ESB a realistic approach across a global enterprise. Some large organizations that are in the process of integrating their enterprise have more than 1,000 distinct application types, with more than 10,000 actual instances of applications behind those endpoints. (This is also one of the reasons you need an enterprise MOM at the core.) It is not reasonable to expect that all applications across the board resort to the same interface technology, whether it be web services-based, Java-based, or .NET-based, to participate in an integration environment. Figure 6-4. An ESB provides multiple client types, connection options, and protocols 
IT departments have too many other things to worry about to go back and significantly retool all their legacy apps. An application that needs to be integrated may be capable only of dumping and loading flat files and transmitting them over FTP. The application may have never been intended to interface with anything, and perhaps was written in C or COBOL. The application may have exposed a low-level, network socket-level interface as part of a one-of-a-kind point-to-point integration project, and can't otherwise be tampered with. Some of the applications that participate in the data exchange along the bus may reside at a business partner's site, and may therefore be able to interoperate with your applications only by using SOAP over HTTP. As we will see in Chapter 8, an ESB can even be used as an integration strategy to augment and replace EDI traffic. All of these situations are acceptable because the ESB provides connectivity options or "on-ramps" for each of these approaches. Because the ESB can support multiple ways of connecting into it, applications don't require any drastic changes to "get on the bus." The motto for ESB adoption is "If you can't bring the application to the bus, bring the bus to the application." This means that applications should be able to connect into the bus with as little modification as possible. It is the bus, not the applications, that provides the flexibility in connection technologies. To J2EE, or .NET To Be The scope of connectivity across an integration project is bigger than what can be solved with just Java technology or just .NET technology. I have yet to see an integration project in which the applications being integrated consisted of all Java or all .NET. You likely have some current projects underway that are using J2EE, and some that are using .NET. You may even work with organizations that consider themselves an "all-Microsoft shop" or an "all-Java shop," which means that they have chosen one platform for all new projects going forward. Now, you need to bring them into the fold of your existing applications and infrastructure, which is likely based on neither platform. The issue of J2EE versus .NET will not be going away anytime soon, but it will become much less of an issue when you're using an ESB to integrate. An ESB provides the common integration fabric that bridges the gap between these two technology platforms. If an application is written in Java, it can use JMS to connect into the ESB. If it's written using a J2EE EJB server, a MessageDrivenBean (MDB) interface may be used. The .NET interface shown in Figure 6-5 depicts a .NET application that connects into the bus using a native .NET client, which connects directly into the MOM using the MOM's internal connection protocol. However, the application could just as well have been implemented using SOAP over HTTP, or WS-ReliableMessaging. |
|
