Brewing a new kind of connection
Green Mountain Coffee Roasters joins ranks of companies saving money, improving business processes by working with Web services
By Tony Baer, senior contributing editor -- Manufacturing Business Technology, 1/1/2005 12:00:00 AM
The specialty blends from Green Mountain Coffee Roasters, Waterbury, Vt., are wildly popular in the cafés and restaurants where they are traditionally served. So popular, in fact, those who have savored the blends are clamoring to enjoy them at home.
This trend boosted Green Mountain's direct-to-consumer sales by 50 percent in just the past year. It also forced Green Mountain to reconstruct its Web site, which originally was built to accommodate B2B commerce.
Just in time for the 2004 holiday season, Green Mountain launched a new, more consumer-oriented Web site powered by Microsoft Commerce Server. And Russ Wright, Green Mountain's IT analyst, says the site was developed in much less time—and at a significantly lower cost—than would have been possible just a few years ago, thanks to the emergence of Web services.
A Web service is a small piece of a larger program—normally a piece of functionality or business logic—that has been wrapped in a layer of standards. That packaging enables the program component—or service—to communicate instantly with any other application component that is wrapped in the same set of standards. These components are called Web services because they typically are wrapped in the same standards used to package data that travels over the Internet.
As Green Mountain discovered, shrewd use of Web services can greatly simplify the process of linking disparate applications to support new business processes. To make its consumer-oriented Web site function properly, Green Mountain needed to link the order-taking components of the Commerce Server program with the order-processing pieces of its PeopleSoftERP package—a task that normally would require writing program interfaces.
"We didn't want to develop a bunch of application integration code, and we didn't want to reinvent any business logic," Wright says.
Ultimately, that wasn't necessary, because both Microsoft and PeopleSoft now build their applications to comply with Web services standards. That allowed Green Mountain's IT staff to simply expose the pieces of functionality within the two programs that needed to interact. Now, it's a snap for Green Mountain's customers to order coffee on the front-end, Microsoft-powered Web site and have the back-end PeopleSoft systems move those orders through the fulfillment process.
Easy upgrades
Many companies are finding that Web services are even more valuable as part of a service-oriented architecture, or SOA. An SOA is comprised of a series of application components that sit in a central repository from which they can be plucked and strung together almost at will to create new business processes.
The publish-and-subscribe mode is perhaps the most popular way of deploying Web services within an SOA. Under this approach, a company will create a directory listing all of the Web services it has created, along with instructions for how to communicate with those services. The directory can be published on an internal corporate network if the services are only to be used within a single enterprise, or it can be published on the Internet for use by outside trading partners.
Programmers in need of pieces of functionality to execute new business processes can search these directories for services that meet their needs and then subscribe to them. Once their subscription is approved, that service automatically responds each time it is needed to perform its role in a business process.
Leading ERP software supplier SAP, which has embedded Web services standards inside its NetWeaver integration platform, refers to linking services to create business processes as building "composite applications."
An example of how to build a composite application could involve matching the order lookup and order-processing components of the SAP suite with the piece of a freight carrier's system that calculates order delivery dates. Linking this functionality via Web services standards could result in an application that automatically gives users detailed information on the status of any pending order in a company's supply chain. And because the application was built with Web services, users could access it through a generic interface, such as a Web browser or even their own company's enterprise application. In most cases, the user wouldn't even have to know where the data originated; they would just know their question was answered.
More productive workers
It actually is becoming easier for companies to build these types of composite applications because both of the dominant platforms for developing business software—the Java and Microsoft .NET frameworks—require programmers to expose all functionality as individual program objects.
The Advanced Technologies and Venture business unit of Dow Corning, Midland, Mich., has been especially aggressive at creating composite applications. This unit, which supplies materials to electronics and semiconductor manufacturers, has developed nearly 20 composite applications that pull data from its plant-floor systems and make it available to users of the company's SAP ERP suite.
The pieces of functionality that generate the requested data have been packaged as Web services. They are published in a portal built by Lighthammer, which specializes in publishing plant-floor data for use by enterprise-level systems.
One of these applications consistently polls shop-floor machines for reports on their performance. When a report shows a machine is operating outside of certain parameters, the composite application automatically generates a maintenance work order.
Keith Carey, IT architect, says the use of Web services and composite applications has several advantages over traditional programming and system integration techniques. In addition to being easier and cheaper to build than traditional programming interfaces, Web services can be reused any number of times to create new applications.
"That gives us the ability to respond quickly to our customers' needs, which is a big issue for us," Carey says, pointing to a Web service that was built to convert data scanned from paper documents into XML format. Recently, that service was reused to automate purchase order processing from small customers that lacked EDI connections.
That application was developed in roughly one month—about 80-percent faster than normal, according to Carey. "This application leveled the playing field for our smaller customers," he says.
Proceed with caution
While Web services and SOAs are becoming the technology of choice for vendors exposing their applications (see sidebar, p. 42), the technology is still evolving. That means companies deploying the technology must take extra precautions, particularly when ensuring that all transactions a service should perform are completed, and protecting against unauthorized access to services.
Traditional, self-contained transaction systems always have safeguards to ensure that interrupted transactions don't corrupt the database. However, with Web services, the systems are loosely coupled. Consequently, there are no set guarantees, unless you specify that the systems exchange acknowledgement messages. Because the standards community is still debating several rival approaches for transaction reliability and validation, customers are, for now, left to their own devices.
"A key design issue was ensuring that actions would be completed between both systems," says Green Mountain's Wright.
Similarly, methods for tracking the identity and authorization of users or programs that request access to Web services remain a work-in-progress. For now, Dow Corning relies on a proprietary adapter from Lighthammer to SAP's access control system—an approach that works well inside company walls, but raises questions when extending access to customers outside the company that are not listed in the SAP user directory.
Furthermore, there are performance concerns because Web services transactions—which often include XML—typically require more messages, which result in a larger data packet than generated by conventional transaction systems. For now, these issues remain manageable.
"We did a count of the messages that normally travel across our network," says Wright. "We then spoke to PeopleSoft and our local service partner, and got a good sense that we wouldn't be banging into any ceilings."
Of course, if Green Mountain's new consumer Web site generates more traffic than expected, that might not be a bad problem to have.
Web services standards
| XML—eXtensible markup language | A language used to create documents or compose messages to be transmitted between applications. |
| SOAP—Simple Object Access Protocol | Tells anyone wishing to access a specific Web service how to format requests. |
| WSDL—Web Services Description Language | The language used to write a description of what an individual Web service does. |
| UDDI—Universal Description, Discovery, and Integration protocol | The format for creating entries for individual Web services in a Web services directory. Companies typically build their own internal Web services directories, but creating directory entries in UDDI format also allows them to list their Web services in a global Web services directory that is available on the Internet. |
| Source: Manufacturing Business Technology | |
