Menu
Menu
Portal and web services: Web services pioneers report minimal pain

Portal and web services: Web services pioneers report minimal pain

The good news, according to one provider and other network executives who have launched Web services projects, is that Web services doesn't come with a steep learning curve or crushing price tag

National Student Clearinghouse has built a Web service that streamlines and automates one of its key business processes. And the good news, according to NSC and other network executives who have launched Web services projects, is that Web services doesn't come with a steep learning curve or crushing price tag.

"One of our biggest learning experiences was that we tried to overunderstand Web services. In other words, we were expecting to learn some new crazy technology," says Doug Falk, CIO for the NSC in Herndon, Va., which provides university and college degree and enrollment verification services.

"When you get right down to it, it is nothing more than another application. Sure, you have a Web services standard that provides message transport and XML, which defines the data format. But other than that, it's just a normal computer application," he says.

Falk, however, cautions that the technology is in an initial adoption phase that consists primarily of data and application integration within a corporation. The next two steps - supporting transactions and automating business processes that flow among companies - will take additional standards and more time and money to become reality.

Today's typical investments in Web services projects involve thousands of dollars and a handful of developers, but that eventually will morph into tens of millions of dollars and dedicated IT manpower, experts say.

"Companies are not changing a whole lot of the systems that they already have. They are developing new ways to get at things," says Johna Till Johnson, president and chief research officer at Nemertes Research and a Network World columnist. But the game changes when companies bite hook, line and sinker. "When you put all your applications into a Web services model and include hardware changes, building redundancy, support and documentation, the average cost of a Web services rollout is about (US)$10 million," she says.

But today, companies are content to spend much less money and effort on Web services because they already are reaping tangible benefits.

At NSC, an investment of $50,000 and a handful of developers working for six months produced two Web services. One streamlines requests for degree and enrollment verifications from employers, insurers, lenders and those who needed information on current or former students. A second automates NSC's retrieval of that information from nearly 7,000 universities, colleges and professional schools.

Under the old system, NSC, which executes nearly 100 million transactions per year, required its customers to fill out forms on an NSC Web site, which meant customers had to rekey data already in their systems.

Through a Java-based Web service, customers now can send data directly to NSC just by retrofitting their client software to support Web services standards. The client puts the data in an XML document that is sent via HTTP in an "envelope" based on the Simple Object Access Protocol (SOAP) to the NSC Web service. The client locates the service using a Web Services Description Language (WSDL) file, a pointer to an Internet address that amounts to a traditional URL. The envelope is opened, and the message is read by a Java application, which formulates a query to an Informix database running on IBM's AIX. The Java application receives the response, translates it back into XML and sends it to the requester via the same route.

NSC also uses Apache Web servers and the Apache Access SOAP engine to facilitate the transaction, and software from Flamenco Networks to authenticate and secure the communication. NSC does not use the Universal Description, Discovery and Integration (UDDI) protocol, a sort of Yellow Pages of available Web services, because it knows who its clients are.

"What we're talking about is a faster system that requires less human intervention, has fewer errors and is lower in cost," says Mark Jones, vice president of business development and marketing for NSC. "We figure for each client that adopts the Web service, we will see a 33 percent increase in volume. So that translates into $25,000 to $50,000 a month fairly quickly."

So far, NSC has about 30 customers willing to update their own internal applications and many others exploring the possibility. But interest by member schools has not been as hot. Most continue to provide updates via FTP.

But with the ball rolling, NSC sees other benefits, including potential changes to its business model. "We have the potential to partner with someone like a PeopleSoft and build access to our Web service directly into their software and have them act as a distribution channel. That has the potential to greatly expand the number of people that have access to our service," Jones says. "We are certainly looking at how this reshapes our future."

Tracking elk in Colorado

Others are eyeing the future with Web services. The Colorado Department of Agriculture (CDA) in Denver is a year into a Web services project and is angling to become an information hub and a model for sharing data.

The government agency uses its Captive Elk Facility Web service to track 160 domestic elk herds in the state. The herds are suffering from Chronic Wasting Disease, typified by chronic weight loss leading to death.

Under a government mandate to collect and disseminate information about the disease, CDA needed to centralize data collected by three of its divisions - Brand Inspection, which inventories herds; Colorado State University Laboratories, which tests elk samples; and Animal Industry, which examines test results and recommends action.

To pull it all together, CDA spent 10 weeks and $100,000 to build its Web service, which is based on Microsoft's .Net. The Web service provides access to a database where the divisions input their data and run reports.

"Previously, the brand division would collect hard copy data on the herds and put it into their proprietary database, then everything was shared via fax," says John Piscano, CTO at CDA.

The Web service uses SOAP and WSDL and includes hooks for UDDI, although that technology is not used currently. It has a Web portal front end that each division uses to access the database through a browser. The front end uses SOAP messages to trigger Web services that make XML-based procedure calls, such as "input data" or "run reports," into a Microsoft SQL database.

Piscano says CDA could have built the application in one of four ways, including as a client/server application. But Web services was the only method that worked over the 64K frame relay pipe that connects the brand division, which handles 80 percent of the data, to the main CDA office.

Moreover, Web services mean CDA easily can integrate its data with other applications, particularly those that the Department of Wildlife runs, which tracks wild elk herds. Piscano also plans to use the Web services model this summer to integrate data on West Nile Virus from a handful of government agencies.

"Government agencies have all this iron sitting around and apps that are 15 years old," Piscano says. "And since the days of decent IT budgets are long past, let's keep this stuff up for a few more years, throw on a little different way we are going to access it, (such as) XML, and keep running. What people need to figure out is that they should consider Web services their gateway."

Tracking the elusive 401(k)

Hewitt Associates has figured that out. The Lincolnshire, Ill., company has nearly 250 large companies contracted to its outsourcing service for employee benefits administration, such as enrollment and maintenance of 401(k) or health plans.

Previously, Hewitt used a Web interface and screen scraping so users could cull data from its mainframe system. Now about a dozen Web services, which took six to eight months to build, offer a programmatic way to access that data. "XML documents give us a more direct connection and a more flexible robust connection into that data," says Tim Hilgenberg, chief technology strategist for Hewitt. "Instead of delivering HTML over the wire, we are now delivering XML over the wire. That's the difference between talking to a Web page vs. a Web service."

Web services and XML, he says, make it easier for companies to integrate benefits data into their portals and for third parties to combine the data with value-added services, such as 401(k) investment advice. Hewitt also used Web services to build applications that it offers to its clients, such as aggregating an employee's benefits information.

Customers access Hewitt's Web service from their company portal applications, which locate Hewitt's Web services using a WSDL file and then send XML-based requests wrapped in a SOAP envelope over HTTP to an IBM WebSphere Application Server.

On the server, a Java servlet unwraps the envelope and initiates a CICS transaction to access a mainframe application. The mainframe returns XML-based data to WebSphere where it is wrapped in SOAP and sent back to the portal. The company does not use UDDI.

Hilgenberg says the keys to Hewitt's success with Web services are that the company already had a robust Web infrastructure on which it could piggyback, and that its applications were service oriented.

"To succeed with Web services your application has to be built around a set of high-level business service, such as 'get this data,'" Hilgenberg says. "It can't be built around some lower-level screens that say 'update table X' or 'get field Y.'"

Hilgenberg says the next level is guaranteed transactions and business process automation.

"Today, most of the stuff we are doing is SOAP over HTTP, and that is not necessarily reliable delivery," he says. "Today, we only do updates if there is a user on the other end of the wire. But when you start to talk about how can I get other systems to talk to our benefits administration system, a system-to-system connection, you need guaranteed delivery of those transactions."

Tracking the mobile cell phone user

Despite those limitations, T-Mobile, headquartered in Bonn, Germany, bet on Web services two years ago as the foundation for delivery of data to mobile workers and consumers. The company has middleware built on 50 to 60 Web services that integrate T-Mobile services such as identity, personalization and billing, with mobile content delivery services for consumers, which 250 partners provide. Also, the company has spent $30 million to develop its Service Integration Platform, a middleware that uses Web services to hook mobile workers into their corporate applications.

On the consumer side, Web services help T-Mobile integrate with content providers to give users features such as single sign-on and itemized billing. For example, a content provider incorporates T-Mobile's identity and billing Web services into its Web applications using a SOAP interface. When a T-Mobile user accesses a content provider application through their phone, the application makes a SOAP call to T-Mobile to access identity information on the user. The application uses that information to provide personalized services and also to link into the billing Web service. Web services also are used to integrate the platforms that T-Mobile divisions in different countries use, so, T-Mobile can offer single billing, currency conversion and taxation Web services.

"There is obviously a support drag on our organization to keep content providers integrated and tested," says Mike Glendinning, a consultant at T-Mobile. "The fact that Web services are simple and technically neutral means we actually have a fighting chance of supporting those guys." He says content providers need only modify their applications with WSDL and SOAP, which is a couple of lines of code that T-Mobile generates using tools from Systinet.

On the corporate side, T-Mobile used .Net to create its Service Integration Platform middleware, which takes in XML data from a corporate customer's application and transcodes it for delivery to a mobile worker's device or laptop over any channel, including wireless and fixed lines. The service is available in Germany with plans for worldwide rollout over the next few years.

"We really don't care if the systems are Microsoft, Unix or mainframes on the corporate side, as long as the output is in XML and is using SOAP and our extensions for mobility," says Hossein Mooin, chief architect and director of technology for T-Mobile international data services. He says Web services gives corporations the flexibility to change their back-end systems and front-end clients independent of one another.

"This was not possible before," Mooin says. He says T-Mobile only needed to modify its network architecture to provide access points for users because T-Mobile re-uses the routing and monitoring of its Web infrastructure.

"Web services do offer you one thing that we had great difficulty with in the past with things such as (Common Object Request Broker Architecture) or Object Request Brokers, and that is having this notion of components that serve each other as opposed to monolithic architectures," Mooin says.

He says the benefit of Web services clearly is simplification: "Sometimes you go in and you recall how long it took you to do things in the old days. You say, 'Wow.'" --

Network World (US)

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.
Show Comments

Market Place