A service-oriented approach
Cooper Tire joins a growing list of manufacturers using Web services to create architectures that better support their business models
By Sidney Hill, Jr., executive editor -- Manufacturing Business Technology, 1/1/2004 12:00:00 AM
When Cooper Tire & Rubber Co., Findlay, Ohio, looked to speed up its manufacturing pro-cess, it quickly recognized that its method for keeping track of the molds from which its tires are built was a major bottleneck.
These molds—which are large, round pieces of cast metal—are shared by four manufacturing facilities, each with its own system for recording when it received a mold and when it passed one to a different location. Behind it all was a communication chain that required individual workers to place a phone call, or send a fax or e-mail message when they finished using a mold. More than once, this system caused molds to sit in storerooms for weeks at a time while production schedulers scrambled to find the materials needed to fill just-in-time (JIT) orders.
Finally, Cooper called Sagestone Consulting, Grand Rapids, Mich., for help. Roughly nine weeks later, Cooper had a single, corporatewide mold-tracking system that allows Cooper to easily satisfy its customers' demand for JIT delivery of tires.
Scott Quibill, a Sagestone architectural consultant, says this new system represents the first building block in what's called a service-oriented architecture that will make it easier for Cooper to institute new business processes for years to come. Quibill and other industry experts also contend this architecture could not have been built just a few years ago—before the advent of Web services.
A service-oriented architecture 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. "People have been talking about this for much of the past decade," says Eric Austvald, a research director with Boston-based AMR Research. "Now the concept of Web services—which offers a standard method of linking application components—finally makes it feasible."
Universal acceptance
There are two major reasons why Web services might indeed become the catalyst for widespread adoption of the service-oriented architecture. First, the Web services model calls for using a specific set of standards for building application components. Second, nearly every technology vendor—from major infrastructure players like IBM and Microsoft to competing application suppliers like Oracle and SAP—is embracing the same set of Web services standards. Only the Internet itself has garnered such widespread industry support.
"Web services actually evolved from the success of the Internet," says John Kiger, a director with BEA Systems, an enterprise application integration software supplier. "The use of http and HTML standards allowed Web browsers to talk to any application anywhere in the world without having to know anything about an application's language or data model. Soon, people realized what an incredible breakthrough it would be to find a data format like HTML and a protocol like http that would let any application talk to any other application—just like the Web browser can talk to any application."
Ultimately, the industry settled on something called Simple Object Access Protocol—or SOAP—to play the role of http in the Web services realm, while eXtensible markup language—better known as XML—is the standard Web services data format. The Web Services Description Language (WSDL) and the Universal Description, Discovery, and Integration (UDDI) protocol round out the core set of Web services standards. (See box, p. 46, for standards definitions.)
These standards give Web services inherent business value because they allow the services to be strung together fairly easily to create new business processes—even when those processes require exchanging data between disparate applications that were built on different technology platforms.
That was the case at Cooper Tire, which now stores all of its mold-related data in a single Oracle database housed at its corporate headquarters. In fact, Sagestone was called in after the Oracle database was installed because Cooper wanted its users to tap into the database through Microsoft Office, and Sagestone is a certified Microsoft consulting firm.
A services library
"We interviewed members of Cooper's project team, as well as people who would be using the system, to find out exactly what they wanted it to do," Quibill recalls. "That's how we determined that a service-oriented architecture would be appropriate. It also is how we determined exactly which services to build."
Cooper's Web services library contains application components that verify the part number of any mold a user wants to find, and pinpoint the location of a mold after its part number has been verified. The services reside on a server linked to a Microsoft Office application called InfoPath on the front end, and the Oracle database on the back end.
InfoPath is the user interface for the mold-tracking system. Users now enter all information about their use of a mold into standard InfoPath forms. They also use an InfoPath form to request information about molds. In both cases, one or more of the Web services communicates with the Oracle database, either updating it with new information input by the user or retrieving information from the database and returning it to the user through the InfoPath form.
Even before Sagestone finished building this initial library of Web services, Cooper had already launched a second project in which it planned to use these same services to feed data to enterprise portals built with Microsoft's SharePoint Portal Server.
"The bottom-line business value from Web services is in building a foundation of services that can be easily and effectively reused," Quibill contends. "They also allow for quick, cost-effective implementation of any new projects."
Austvald says any company with $1 billion in annual revenues is at least experimenting with Web services, but he believes it will be several years before Web services or the service-oriented architecture become standard for corporate IT infrastructure. "Most new technologies have about a 10-year adoption cycle," he says. "With Web services, we [are in] year three." Still, there is ample evidence that this technology has staying power.
True business value
"The maturity of the core set of Web services standards means that Web services now have more business value than technology value," says Michael Liebow, IBM's VP of Web services. "Visa International used a Web service to resolve billing disputes and pass information to member banks and merchants that produced savings of $200 million in the first three months."
Numbers like that prompted IBM to embed Web services capabilities into its WebSphere line of application development and integration products. That means any application built on the WebSphere platform can automatically be used as a Web service. WebSphere also allows for converting components of outside applications, including legacy systems, into Web services.
Microsoft calls its .NET framework a platform for building Web services, and companies like Epicor, an ERP software supplier that targets medium-size manufacturers, see that as an advantage. "Companies only want to adopt new systems and technology when it makes financial sense, and that is especially true in the midmarket," says John Hiraoka, an Epicor VP. "The ability to break our system down into small components, or Web services, means customers will be able to plug in new applications more efficiently, and at a lower overall cost."
Siebel Systems, the largest supplier of customer relationship management software, has used Web services standards to create interfaces to all of its applications, according to Bharath Kadba, general manager of the Universal Application Network, which is Siebel's integration platform. "You can look at our products as a collection of Web services," Kadba says. "That addresses issues that are associated with integrating our products with other applications."
Composite apps
Vendors like BEA Systems and SeeBeyond also are embracing Web services and the service-oriented architecture.
"Web services are at the core of the latest release of our software suite," says Alex Andrianopoulos, See-Beyond's VP of product management. "The focus of that release is extending EAI beyond its traditional role of simply connecting systems to making it a tool for any company to create composite applications."
Composite applications are bits of logic from multiple applications that are combined to create specific business processes. They can be built with traditional system integration tools, such as application adapters and message brokers, but Andrianopoulos says the easiest way to build them is through Web services.
SeeBeyond calls its product suite ICAN, which stands for Integrated Composite Application Network. The ICAN suite contains tools for connecting applications, transforming data, and building user interfaces, which are necessary for creating composite applications. But Andrianopoulos calls the business process manager, which goes by the name eInsight, the key piece of the suite because that is where composite applications become Web services.
"All of the business processes created in eInsight ICAN are based on the Web services paradigm," Andrianopoulos says. "This actually forces customers to build solutions on a service-oriented architecture. It also has made our internal development teams more efficient at generating new products."
The WebLogic platform from BEA Systems also contains the elements for building composite applications and binding them to a service-oriented architecture, but Kiger, the BEA director, says building that architecture will take time. "It wouldn't make sense to try to convert everything in an existing IT infrastructure to a service-oriented model," he says. "Our forward-thinking customers typically look to identify certain business functions or types of data that are used in multiple areas of the business and convert those to Web services."
Customer information is an example of the type of information that is ideal for converting into a Web service, Kiger says.
As companies start building service-oriented architectures, SeeBeyond's Andrianopoulos says they should also push technology suppliers to collaborate on additional Web services standards. "There should be standards that address things like system security, which is an issue that has kept some companies from adopting Web services," he says.
Web services standards
| XML—eXtensible markup language | A language used to create documents or compose messages to be transmitted between applications. |
| SOAP—Simple Object | Tells anyone wishing to access a specific Web Access Protocol service how to format his or her request(s). |
| WSDL—Web Services | The language used to write a description of what Description Language an individual Web service does. |
| UDDI—Universal Description, | The format for creating entries for individual Web Discovery, and Integration protocol 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: MSI | |
