This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs for the special pre-order price, click here for more information. Aimed at everyone from enterprise developers to self-taught scripters, Real-World AJAX: Secrets of the Masters is the perfect book for anyone who wants to start developing AJAX applications.
Corporate Mashups: Composite Applications Simplified Through AJAX and SOA
In this chapter we'll look at rapidly implementing an AJAX Rich Internet Application that leverages various XML and SOAP Web Services while using the visual tools and application objects from TIBCO Software's AJAX toolkit: TIBCO General Interface. Download TIBCO General Interface at www.tibco.com/mk/gi.
What's Old Is New Again
Corporate mashups? The idea of putting information stored in various application systems on a single screen for the end user isn't new. When Yahoo! first popularized the Web portal, people suddenly had the experience of seeing information from different places on one screen and businesses quickly caught on to the portal concept.
Not surprisingly, providing composite views of data is often central to business operations. More than ever composite views of information are core to securities trading, shipping and logistics, telecommunications, customer service call centers, and other industries' primary operational activities. Of course providing this capability has been technically challenging to achieve atop previous generations of application architectures that were largely monolithic systems generally incompatible with one another. And so the integration software market came into being - an entire industry segment dedicated to getting the heterogeneous landscape of business information technology systems to work together.
Then as now the leading strategy for breaking down the barriers between systems has been "decoupling" - separating the production and consumption of information in systems intermediated by an independent information exchange protocol. This idea is perhaps the simplest definition of a service-oriented architecture (SOA). The key to the success of such systems is the extent to which producers and consumers can communicate using the independent information exchange protocol and be connected on a network.
Various technical approaches such as EDI, CORBA, real-time and queue-based messaging have been promoted over the years as popular ways of integrating systems. Interestingly it was in part a vision of composite views of stock exchange data that led to the creation of TIBCO Software's messaging technology in the 1980s as a way to get real-time information from disparate systems into composite view applications on securities traders' desktops.
While messaging remains at the core of enterprise integration implementations today, the global adoption of HTTP via the Web has led to XML and SOAP as prime standards for SOA implementations as well. Today XML, RSS, SOAP, and other forms of HTTP-based services, combined with the AJAX capabilities of the Web browser, provide a way to create a new generation of rich Internet applications that "mash up" information into a new lighter-weight and lower-cost class of composite applications.
Where Is This AJAX/SOA Approach Applicable? One of the things that AJAX affords is the ability, at least in part, to manage state on the client. This is advantageous since many Web services are implemented as stateless. The RSS feed you request doesn't remember what it gave you last time. An XML or SOAP service typically gets a request message and provides a response. Since these services aren't going to maintain state for you, you can now do it at the client. So implementing simple workflows at the client is feasible. Creating dashboards where portions of the screen update asynchronously is possible. Providing 360-degree views of customer information from multiple services becomes an easier task even so far as to merge data from one service with data from another service at the client.
Managing 100% of the end-user state on the client wouldn't be appropriate if you have long-running workflows, typical of Business Process Management systems, or sophisticated business logic that requires access to session and state. There's already plenty of infrastructure out there for that in Business Process Management (BPM) suites, rules engines, and Web application server products.
In cases where managing some state on the client makes sense, you can achieve remarkably highvalue solutions in just a little time mashing up Web services into AJAX rich Internet applications.
Let's take a look at how.
Anatomy of a Typical System
Figure 13.1 shows a typical implementation of a system with an AJAX application running in an HTML page served by a Web server asynchronously communicating back to that server when certain client-side events happen. The view in the browser is updated by JavaScript commands that manipulate DOM and CSS. JavaScript event bindings to DOM and CSS capture mouse and keyboard events invoking other JavaScript commands.
In the browser, the XMLHTTPRequest (XHR) object, which puts the "asynchronous" in the AJAX acronym, restricts communications to the sub-domain from which the HTML page it contains was served. Therefore, to the extent that various Web services reside in the same sub-domain as the Web server, no special server configuration is necessary.
When Web services reside in a remote domain or other sub-domain, those services must be proxied through the sub-domain from which the AJAX application was served. Since the Web server provides a gateway to services, it's also an opportune point at which to implement authentication and security policies.
Some AJAX implementations use iFrames or JavaScript Object Notation (JSON) to access information beyond the sub-domain directly from the browser. From a security point-of-view, such multisecurity domain access forces authentication policies to become distributed and so may represent more implementation challenges. Of course if you're not authenticating or securing services, then these methods may be easier. However, in business applications the security of information is more critical than in "mashup" solutions, like Google Maps and all the various overlays that combine public information. In business some information has to remain private, even compartmentalized to various groups of users. Accordingly, a central place for administering these policies becomes useful over time when creating corporate mashups. While a Web server can provide the basics, we've already seen multiple successful uses of AJAX and SOA where a more robust portal infrastructure provides the middle tier for application provisioning, personalization, and access control to both the AJAX applications and Web services. But that discussion would be grounds for a whole other chapter...so let's keep on moving towards our baseline implementation.
Use Case: 360-Degree Customer View
Figure 13.2 shows the application we'll build: a 360-degree view of a customer in a personal banking scenario. In this case a financial advisor needs rapid access to a broad range of current and historic customer information to provide service.
The primary use case consists of these basic steps:
- The user finds a customer through a modal dialog configured to talk to an HTTP GET-based service that returns customer information in a basic XML document.
- When a customer is selected, the customerID is broadcast to the GUI, data, and communication objects in the AJAX application.
- Objects subscribing to the customerSelected event subject receive the customerID triggering asynchronous calls to various services, some of them SOAP-based, others RSS and miscellaneous XML.
- As data from the services arrives, it is transformed into a Common Data Format (CDF is explained below) and put into the client-side data cache. Each time this happens a "success" event for that service call is broadcast.
- Objects subscribed to the success event for that call, handle it by repainting their onscreen view, using the new information in the data cache.
We'll implement this case using TIBCO General Interface (GI), which provides multiple features that help implement more robust AJAX/SOA applications faster. With TIBCO General Interface, speed to implementation is achieved by minimizing the amount of coding required. First is through an extensible set of out-of-the-box components that are ready to use so you don't have to create them from scratch in DHTML and JavaScrip; second is through visual tools that let you simply configure many aspects of your application, leaving only the client-side interaction logic of the task to writing code. We'll use the following visual utilities in TIBCO General Interface (GI) in our implementation:
- Visual WYSIWYG Layout Tools: With GI you don't create GUIs by coding DHTML tags. Instead you instance and configure JavaScript objects that know how to render the rich GUI controls for you. While you can instance these objects programmatically via the JavaScript APIs to GI's objects, TIBCO General Interface Builder provides a WYSIWYG drag-and-drop GUI construction capability. These components can be saved in XML files for later reuse in other projects and can include data, logic, and service bindings to make them "AJAX-lets" unto themselves.
- Client-Side Data Objects and Data Cache: GI features a data cache on the client. This inmemory cache runs in the context of the current HTML page. You can store one or more XML data objects in this cache and make that data available to other GUI components and application functions. GI GUI components all implement rendering routines that expect data in what GI calls the Common Data Format (CDF). CDF is simply an open schema for describing any data. Since many of GI's components implement interfaces to CDF, a single CDF document can drive multiple views of that data, streamlining client-side scripting and supporting mashup-type implementations. To get data in and out of the CDF format, you can use the programmatic APIs of GI's CDF class object or use the visual service binding tools.
- Visual Service Binding Tools: GI features drag-and-drop binding to XML- and SOAP-based services in its XML Mapper Utility. So if you're connecting to RSS, SOAP, or other XML services, you can eliminate significant coding here as well. The Mapper lets you transform client-side data in GUI components or data objects to and from the message formats required by the various services you're using. The XML Mapper Utility also enables single-click generation of pre-bound form elements from your XML message schemas. Once the bindings are defined in the visual tool, an execution script is generated for you to paste in your application logic, then modify to script the behaviors you want.
- Client-Side Publish and Subscribe: Besides bindings for GUI events such as drag-and-drop, mouse actions, and key presses, GI implements a client-side publish-and-subscribe notification system. Similar to server-based message buses, GI's "pub/sub" capability lets an object be published to all the other objects that subscribe to the subject property of the published object. By implementing this technique, a component can broadcast a "customerSelected" event subject, passing the customerID to one or more subscribing objects, each of which can implement their own handler for that event and its data.
To get started you'll need to have two things in place: a locally running copy of TIBCO General Interface and the starter code for this project.
TIBCO General Interface Professional Edition is free for development, testing, and public deployment and features a dual-licensing program for smaller private or enterprise-grade use. You can download it from http://developers.tibco.com
The starter code for this project can be downloaded at http://developer.tibco.com. Search for Real-World AJAX: Secrets of the Masters. The code and installation instructions are available. Once you've downloaded and installed TIBCO General Interface and the starter code, you should see the following:
The project is comprised of a series of files as shown in Figure 13.4
We've already built out the various GUI components and screen layouts for you. The GUI component file appCancas.xml provides the primary layout and references the other GUI component files, enabling you to create your applications in reusable modules. Modularizing applications results in faster loading and rendering times in the way that Microsoft Word loads some of its DLL functionality upfront, then more DLLs later when you need them. The GUI components in the c360 project were modeled by dragging-and-dropping items from the Component Library onto the canvas of a component file, arranging the components hierarchically, and configuring them using either drag-and-drop sizing or the Properties palette.
The JavaScript files consist of logic.js, which contains the client-side interaction logic for the project.
The Mapping Rules have two "mapping" files that define the bindings between the various components of the client application and the various services with which they communicate.
The XML documents in the Project Files contain dummy data for the portions of the project that are simply mocked up at this time.
This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs, click here to order.