| A portal application is normally used to pull data from multiple backend sources and represent it in a unified view via a web browser. The means for gathering the data from backend applications and databases into a portal environment is typically based on application servers and synchronous RPC-style communications. Like the ESB itself, this pattern arose out of necessity, based on the work of IT architects looking to solve problems they encountered with existing portal server infrastructures. Some organizations that started out using the typical portal server approach soon realized that it wouldn't scale to suit their long-term needs, and looked for an alternate architecture. They discovered that having an ESB as an integration strategy behind the portal server provides the ideal mediation between the portal server and the disparate backend data sources. This case study will explain the reasons why a default portal server architecture can break down or become unwieldy as the number of backend systems increases, and the span of time to fulfill the requests increases. The ESB can act as a reliable buffering mechanism between the portal application and the backend systems. Through asynchronous communication, reliable delivery, and correlation, an ESB can improve the overall success rate of inquiries, improve throughput and responsiveness, and reduce errors. In addition, an ESB can provide a much more flexible backend integration layer than what can be provided by the portal server alone. Backend applications can use a variety of connectivity choices to plug into the bus and immediately begin to participate in an event-driven SOA with other applications and shared integration services. The ESB architecture accommodates change. As new sources of information are brought into the realm of what the portal can access, an ESB allows these new sources to plug into the SOA and immediately start participating in the data sharing network simply by administratively configuring the new service to join into business processes. Standards such as the JSR-168 "Portlet" specification and the OASIS Web Services for Remote Portlets (WS-RP) specification can help provide an API and a model for portal developers to build portlets, which are components that populate and render portions of a web page in a portal. The portlet can plug into the ESB and have a single interface to the entire backend system. This allows the portlet to rely on the ESB to normalize the data from all backend sources and feed it into the portlet. As data sources change over time, the portlet code can remain the same. Because an ESB is very XML-aware, it can provide a much simpler interface from the perspective of the portal application. The ESB can perform much of the aggregation and semantic mediation instead of delegating it to the presentation layer or portal server. If the ESB is used to deliver all of the data to the portal server, the developer of the portlet consumer can simply focus on reformatting XML using XSL stylesheets rather than handling each data source as a unique format. This section will explore the general advantages of using an ESB in a portal server environment. Later, two specific design patterns will be explored:
- Forward Cache
-
The ability to move data from distributed systems close to the presentation tier for low-latency, read-only access to the data.
- Federated Query
-
The ability to efficiently query multiple systems and aggregate the responses asynchronously at the presentation tier.
These patterns are explained in the context of a portal server integration scenario. However, they are generic enough to be used in other scenarios as well. 11.3.1 The Portal Server Deployment Architecture Figure 11-9 shows a typical deployment model for a portal without an ESB. The portal provides a unified view of data that may originate from a variety of sources: for example, databases, applications, and other portals. These data sources can be deployed across multiple physically separate locations and can be based on a variety of platforms and technologies, including C, C++, J2EE, and .NET (or .NET predecessors). Figure 11-9. Portal infrastructure using a portal server that acts as an aggregation point for multiple data sources 
The portal server provides the presentation logic for the users of the portal who use web browsers to look up information. This type of environment is used within many forms of Customer Relationship Management (CRM), including helpdesk applications, call-center applications, and even customer-facing applications where customers interface directly with portal-based applications to perform self-service queries. The portal server in this example is based on a J2EE application server platform. One of the operations the portal server performs is accepting web requests from a web browser, and using web page generation technology to dynamically format an HTML page as a response back to the user. A J2EE application server is well suited for this type of request/response handling and HTML page generation. The portal server also acts as the interface to a variety of backend systems from which data is extracted to populate the page generation engine. The interface to the backend systems can be accomplished in a variety of ways: Using JCA-compliant adapters that are supplied with the application server Putting web service interfaces on the backend data sources and using SOAP-over-HTTP to make web service requests Using JMS to reliably and asynchronously integrate with the backend systems Using a reliable SOAP protocol to reliably and asynchronously integrate with the backend systems
Sounds great, right? But what's wrong with this picture? There are challenges associated with this architecture that motivated several IT departments to adopt an ESB: The back-office system may be incapable of sustaining the peak loads required to support the frontend presentation tier. There is a risk associated with exposing the back-office system directly to the presentation tier. Placing a web frontend on an existing application and allowing all customers to suddenly start using the application directly can result in an increased volume of data and unknown amounts of traffic. An application that was once built for a single user, or a given number of users sitting in front of a terminal at predictable times throughout the day, may not be capable of handling these larger volumes of throughput. The portal server approach by itself does nothing to alleviate that situation. The latency for request/response could exceed the tolerances of the presentation tier. Some of the queries being executed could take longer than a typical browser request/response time to complete. In a distributed, SOA-based environment, careful attention must be paid to how systems interoperate, and what would happen in the event of failures or downtime. In many situations, preexisting systems are not capable of resending messages as necessary and providing the "in-doubt resolution" required to compensate for these failures. An ESB can offload this complexity from those systems. The back-office system could be in a different geography than the portal server. If links go down between the two data centers, the data should still be available to end users. Likewise, if the backend data source should become temporarily unavailable, the query should still be able to complete.
The first step toward achieving a solution for these issues is to deploy an ESB in between the portal server and the backend systems, as illustrated in Figure 11-10. Figure 11-10. The ESB as the integration layer between the portal server and the backend systems 
The general advantage of deploying an ESB in this fashion is that it provides a more flexible, enterprise-grade backbone to reliably link applications and services together into a cohesive event-driven SOA, capable of servicing the full range of integration scenarios required by most portals. Before continuing on to explore more about the ESB, let's revisit the non-ESB portal solution and examine some of its characteristics. 11.3.2 Portal Server Challenges The typical portal server deployment architecture presents several challenges. 11.3.2.1 Synchronous sequential aggregation Figure 11-11 shows a browser request being sent to a portal server, which in turn initiates a series of synchronous requests to a number of backend systems using web services interfaces. Figure 11-11. A portal invoking synchronous web services requests sequentially 
Latency issues associated with this approach can make it an untenable experience for the end user of the portal. To illustrate this point, consider a request to the portal server that results in a query to four backend services. If each service takes 3 seconds to process, invoking these services sequentially would take a minimum of 12 seconds. Some queries that are executed using this model can take 20 minutes to several hours to complete. 11.3.2.2 Web services Another quality of the approach illustrated in Figure 11-11 is the expectation that web services interfaces will be used as a one-size-fits-all solution. An integration solution needs to be capable of accommodating the needs of the application without doing a synchronized retrofit onto every application across an organization. It is not reasonable to mandate that all applications will switch over to web services interfaces on a certain date; coordinating such an effort on a mass scale with limited resources is nearly impossible, especially when factored in with the everyday priorities of an IT organization. Instead, it's much more reasonable to have a plan to eventually achieve a common interface description using WSDL and web services, and it is much less of a barrier for embarking on a portal integration project. 11.3.2.3 Concurrency via multithreaded request To compensate for the latency issue, it is possible for a portal server to introduce concurrency by creating a separate thread for each request, and to have the thread block and wait on the synchronous call (Figure 11-12). Figure 11-12. Introducing concurrency by creating separate threads that block on synchronous invocations 
The multithreading allows multiple requests to be executed in parallel, thus reducing the overall latency to the longest individual query time rather than the sum of the query response times. However, this solution is not without its problems, and there are better ways to handle this situation using an ESB. There is still the possibility that a network link could go down, that one of the backend systems could be shut down due to failure or scheduled downtime, or that the portal server itself could go down (Figure 11-13). Figure 11-13. Network failure or system downtime can cause interruption in service and a frustrating user experience 
If a failure occurs, the portal server may not be built to automatically retry the request. This could be done by manually creating a thread and going into a retry loop, which can result in a buildup of unused threads under high-volume usage. Also, if a failure occurs and the query has already been running for 10 minutes, it can be extremely frustrating for the end user to have to start over again. 11.3.2.4 Long-duration conversation management The portal server may have implemented some form of stateful long-duration conversation management for web services interactions. However, this requires all backend systems to be enabled as web services, and to be enabled to support long-duration conversations. This still does not protect against failure modes, however. The portal server may manage persistent state for its side of the conversation, but that doesn't help with the conversational state of the remote service. 11.3.2.5 Asynchrony and reliability using JMS One approach to providing asynchrony and solving the reliability problem without explicitly using an ESB would be to use JMS between the portal server and the backend data sources. This is a step in the right direction. A portal server that is based on J2EE may also come with a JMS provider in the box. However, this approach also suffers from the one-size-fits-all problem. The JMS provider that comes with the application server may support only Java clients, and you can't reasonably expect every backend application and data source that the portal needs to integrate with to switch over to Java and JMS interfaces. 11.3.2.6 Connectivity using application adapters To allow more flexible options for backend applications or data sources to plug into the portal server, special adapters may be used. Many application servers offer integration capabilities by licensing third-party application adapters (the same adapters that can also be licensed by ESB providers) that are made for plugging into specific brands of applications, such as SAP or PeopleSoft. The downside of this approach is the requirement that the adapter be housed inside the application server container, leading to the "appservers everywhere" problem that was discussed in Chapter 6 (Figure 11-14). This is not always a terrible thing, if you really must have application servers installed at every location to host middle-tier business logic. However, if they need to be installed at every location across your organization simply to act as conduits to an enterprise application, an ESB can be a much more viable alternative. Figure 11-14. Appservers everywhere 
You could piece together an alternative approach that combines the use of JMS and adapters, as illustrated in Figure 11-15. Figure 11-15. JMS implementations that are supplied with application servers do not provide adequate routing across geographically dispersed deployments 
This approach is a step in the right direction in terms of providing asynchrony and reliability, but it still has the "appservers everywhere" problem. Another potential downside is that the JMS that comes in the box with the application server can typically provide asynchronous, guaranteed messaging capability only in a single network domain, and doesn't allow for a uniform and seamless namespace of destinations to scale across multiple departments or business units. Application server vendors have attempted to link multiple installations of their JMS messaging systems by providing a custom SOAP bridge to forward messages reliably between data centers, but this does not provide the end-to-end global accessibility that an ESB provides. Lastly, if the application servers being used in different departments are from different J2EE vendors, this presents the further challenge of getting them to work together using the JMS layer from one of the vendors. 11.3.3 Inserting an ESB as the Integration Backbone The solution to the problems outlined previously is to install an ESB as an intermediate infrastructure between the portal server and the backend applications and data sources, as illustrated in Figure 11-16. An ESB provides seamless end-to-end asynchronous and reliable communications across a distributed environment. It also provides additional connectivity options, such as web services and application adapters, allowing flexible deployment of the services anywhere on the ESB. Furthermore, an ESB provides the event-driven SOA to plug in the added integration services when and where you need them, facilitating the extraction, routing, and transformation of the data as it moves across the bus between the portal server and the backend applications. Figure 11-16. The ESB as the integration infrastructure between the portal server and the backend data sources 
With the ESB layered in the middle, all links between the portal server and the backend data sources can now be asynchronous and reliable, without the downsides stated earlier. Because of the flexibility of choices in connectivity, the backend data sources can use any combination of JMS, C++, web services, FTP, and HTTP to integrate into the ESB backbone. This not only saves time in the integration project, but also potentially results in higher performance and reliability for legacy connections. Remote ESB service containers can host application adapters without the need to install application servers at each remote location. In many cases, such as the SAP RFC adapter for the Availability To Promise application from Chapter 8, the remote ESB container can use a custom service to act as an application adapter, which makes the development and deployment of that integration point extremely lightweight and simple. This architecture can scale across geographically dispersed deployments, allowing all data sources plugged into the bus to be accessible from anything else that is plugged into the bus, regardless of its physical location. Lastly, inserting an ESB allows the use of the general-purpose integration patterns that will be explored in this chapter and in Chapter 12. | 