Case Studies, B. Lheureux Research Note 3 January 2003 National Student Clearinghouse's Web Services Network NSC provides access to U.S.-based college and university student records via electronic data interchange and Web browsers. NSC now also supports Web services access, using a Web services network for security and reliability. Core Topic Application Integration and Middleware: Application Integration Key Issues How will electronic commerce and other interenterprise integration strategies differ from intraenterprise integration solutions? What strategies will address the unique challenges of integrating Web-based applications with enterprise systems? National Student Clearinghouse (NSC) is a nonprofit organization that was founded by the higher-education community in 1993 to streamline the student record verification process for many organizations, including colleges and universities, employers, lending institutions, insurance companies, and the U.S. government. NSC maintains a comprehensive electronic registry of more than 70 million student records, providing a secure point of contact for organizations and individuals requiring timely, accurate verification of student enrollment and degree data. NSC serves approximately 2,700 universities (representing 90 percent of the United States' college students) and conducts more than 100 million transactions per year. Problem: NSC's customers today access student records online using an Internet browser. Updates to NSC's database are via electronic data interchange (EDI) or FTP. Some of NSC's customers have begun automating their internal business processes that use student records (for example, to verify student records for employment or to qualify for special insurance rates) and thus have been requesting a more realtime, programmatic interface to NSC's database so their applications could dynamically access student records. Requests for student records, such as verification of current enrollment, are pretty simple (typically involving three incoming and 20 outgoing data elements) and are generally executed in a request/reply fashion, but nevertheless NSC considered its current browser interface to be too awkward (even via HTML scraping) for use in real-time applications. It also considered EDI and FTP too awkward to support real-time access to higher-education institutions' data, which is necessary when NSC receives a request for which it does not have current data on hand. It began to look for a different solution to link its student record providers and consumers. Gartner Entire contents 2003 Gartner, Inc. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.
Objective: NSC's approach in choosing an automated, programmatic interface was to seek a solution with a "light touch" that is, an interface that would be relatively easy to implement and support. In particular, NSC's requirements included: Internet-based communications Ease of provisioning Strong security Standards-based Scalability (for many users) Manageability (outsourced) Internet access was preferred, to leverage its ubiquity and to avoid the cost of private networks, such as dial-up and leased lines. Ease of provisioning was important because NSC was concerned about how to register and activate potentially thousands of users in particular, the educational institutions typically have a big IT backlog, and lead time to deployment of new projects is six months to a year, so integrating with NSC's network needed to be very simple. Strong security public-key infrastructure (PKI) was not strictly essential, but was chosen over weaker security user ID/password plus Secure Sockets Layer (SSL) in part to comply with the privacy requirements of the U.S. Family Educational Rights and Privacy Act (FERPA) as well as to meet long-term IT infrastructure requirements. To ensure that the interface would continue to be relevant in the future, NSC desired open, standards-based data and interfaces that is, it did not want to deploy proprietary data formats, communications protocols or application programming interfaces (APIs). Scalability was important to support potentially thousands of trading partners. Finally, because of its limited IT staff size, NSC sought to outsource the operation for its new automated programmatic interface. Approach: Key factors affecting NSC's decision to go with a Web services network (WSN) were its interest in Web services and its prior experience with EDI as well as with integration projects involving general-purpose integration suites, such as Mercator Software's suite. In part because its transaction set was small, NSC concluded that leading integration suite solutions would be too "heavyweight" for its integration requirements. NSC also eliminated EDI value-added networks (VANs), in part because they were considered too expensive and in part because of its perception that there was "no value" in passing its data through any VAN networks. It also ruled out RosettaNet after concluding that like EDI the overall specification was too complex. Although it plans to continue using established 3 January 2003 2
solutions (for example, EDI) for trading-partner connectivity, NSC was looking for a simple, low-cost, Internet-based solution that would support the near-real-time and component-based requirements of a service-oriented architecture in a business-tobusiness (B2B) scenario. Given the increasing popularity of Web services and the availability of Web-services-enabled application servers and development tools, NSC chose Web Services Description Language (WSDL) as the way to express its application interfaces for use by trading partners and Web services Simple Object Access Protocol (SOAP) as the underlying protocol to receive and deliver student records with its trading partners. Universal Description, Discovery and Integration (UDDI) is not used NSC did not see a need to register its services in a formal UDDI registry, because the WSDL information is already incorporated into the endpoint software. Because NSC needed to execute Web services between trading partners safely and reliably, which requires security and quality-of-service capabilities not available in the base Web services specifications, it required a WSN (see "Web Services Networks Secure a New Web Technology"). NSC chose to outsource its WSN refer to "New Functionality" in Figure 1 to Flamenco Networks. Education College and University Sites DB Logical Student Record Flow Today EDI, Flat Files Figure 1 NSC's WSN Clearinghouse Site Student Degree/ Enrollment DB Apache/Java Platform Today Browsers Commercial Insurance, Lenders, Employer, Government and Other Sites DB Student Enrollment Applications Web Services Web Services Web Services Various Applications New Functionality Web Services Network Flamenco Site Source: Gartner Research Access to NSC's Web-services-based student data is implemented using Flamenco's e-mail-based provisioning 3 January 2003 3
process, by means of which trading partners can download and install the Flamenco endpoint software (self-provisioning). WSNs often use some form of endpoint software to support their facilitation of Web services communications and management, including security, for safe, reliable execution of Web services between trading partners. Both instances of endpoint software are Web services proxies and communicate directly with each other in peer-to-peer fashion to exchange SOAP-based Web services between Web services consumer and requester applications. The endpoint software also acts as management agents and communicates with the Flamenco management site in a hub-and-spoke fashion for example, for performance monitoring and distribution of PKI-based certificates. To link to NSC's WSN, trading partners initially must develop their own Web services consumer applications to execute NSC's published Web services exposed via the Flamenco endpoint software. NSC will later offer its trading partners adapters so that their student record retrieval service can be directly integrated into selected operating environments for example, Java 2 Platform, Enterprise Edition (J2EE) and packaged applications (such as PeopleSoft). In the latter case, the trading partner will install both the Flamenco endpoint software and NSC's adapter whether any development work will be required will depend on whether the adapter simply exposes an API to an operating environment (for example,.net or J2EE) or whether it is designed as a "plug-in" for a specific packaged-application module. NSC's decision to use Flamenco was based on several key factors: It has limited staff, so outsourcing its WSN was preferable to managing it in-house using a WSN technology stack (such as those from Blue Titan Software or Westbridge Technology). One factor that led to the decision to use Flamenco, however, is that this vendor also offers a WSN technology stack that NSC has the option to license later if it chooses to insource its WSN. NSC's WSN will potentially involve hundreds or thousands of trading partners, so it was particularly concerned about scalability and considered Flamenco's facilitated peer-to-peer WSN to be particularly scalable (for example, vs. a hub-andspoke model). It also sees a peer-to-peer scenario as a way to avoid routing its traffic through a third-party hub. NSC also liked Flamenco's semiautomated provisioning capabilities, which allow WSN administrators to create trading-partner profiles and invite new trading partners via e- mail. These partners can respond and do their own 3 January 2003 4
provisioning for example, to register to the network and then download and install endpoint software to participate in the network. Security was a key factor, and Flamenco's Rivest-Shamir- Adelman (RSA)-based PKI solution was considered secure. In this project, Flamenco is also the certificate authority. NSC would have considered even just SSL to provide a secure "pipe" between trading partners' endpoint software, but it wanted a solution that would satisfy long-term security requirements. NSC did have some reservations about Flamenco's viability, given that the vendor is still quite small and its technology is not yet extensively field-proven. It considered Web services solutions from more-mainstream IT vendors, but, although these supported Web services, they did not currently include the generally available security and provisioning tools that are necessary to safely and reliably support B2B Web services interactions. Because Web services are standard and because the Flamenco endpoint proxy is not coded directly into trading-partner applications, NSC believes that, if necessary, it can later "swap in" another WSN technology or service provider. Although the lack of tight application binding simplifies this task, to swap in another WSN would still require effort for example, to distribute new versions of the WSN endpoint software and to convert users from one security system to another. Results: With regard to Web services integration: The NSC's WSN is currently deployed and available for trading partners to use. Initial prototypes have demonstrated that the concept works NSC successfully developed and deployed its Web services, which were then executed by simulated trading partners. NSC's conclusions were that "parsing XML is trivial" and that "schemas are easy to understand a simple transformation step." At least for NSC's targeted, well-defined transaction set and integration problem, Web services delivered via a WSN to quote the management at NSC "just work." With regard to Web services adoption: Before making its decision to implement Web services, NSC previewed its proposed solution with some of its trading partners. Most were surprised (and often unaware of the potential for Web services in this role), but, after hearing about the details of the implementation and provisioning process, all were satisfied that it could work and be safe. More recently, NSC polled 50 of its top (by revenue) trading partners, offering to provide Web services automated interfaces as an alternative to using browser-based access. Of these, 35 have expressed interest in more details, and several will begin testing soon. NSC hopes to have 25 trading partners using Web services by the end of 1Q03. 3 January 2003 5
Critical Success Factors/Lessons Learned: After explanation of the technology involved, including the WSN, trading partners are willing and some are eager to use Web services. Since rollouts are just beginning, we do not yet know what the adoption rates will be, but, to date, no trading partner has objected to using Web services. Although Web services overall are immature, use of a WSN has mitigated trading-partner concerns about security and quality of service. UDDI was not considered essential, particularly in this case, where the WSDL is provided as part of the provisioning process (with the endpoint software) and the number of methods defined in the transaction set is small (fewer than five). Initial testing has shown that Web services can safely be deployed in a B2B fashion using a WSN. The loosely coupled binding nature and standards-based interoperability of Web services are appealing to trading partners, because they minimize overall integration activities, although it is also understood that, if it were later necessary to swap out Web services or WSN vendors, this would still require some development effort. Acronym Key API B2B EDI FERPA J2EE NSC PKI RSA SOAP SSL UDDI VAN WSDL WSN Application programming interface Business-to-business Electronic data interchange U.S. Family Educational Rights and Privacy Act Java 2 Platform, Enterprise Edition National Student Clearinghouse Public-key infrastructure Rivest-Shamir-Adelman Simple Object Access Protocol Secure Sockets Layer Universal Description, Discovery and Integration Value-added network Web Services Description Language Web services network Except for some concern about vendor and product immaturity, there have been no trading-partner objections to using Web services or a WSN. No serious technical problems were exposed during testing. NSC believes that the peer-to-peer architecture of its WSN implementation will be capable of scaling to potentially hundreds or thousands of trading partners. Bottom Line: Breaking from the traditional use of electronic data interchange within the educational community, National Student Clearinghouse (NSC) has successfully begun executing Web services with its trading partners. Through the use of a Web services network (WSN), NSC has demonstrated that easy-todevelop, standards-based Web services can be safely and reliably deployed in business-to-business (B2B) scenarios. While understanding that related vendors and services are still relatively immature, enterprises should immediately begin to include WSNs as a viable emerging alternative to moretraditional forms of B2B application integration. 3 January 2003 6