We've all heard the stories about the myriad benefits of Web services, how they make it easier to build reusable services, do business with partners and customers and more. But what's it like building Web services in the real world -- specifically inside a world-spanning enterprise? How is it really used, and does the reality match up against the hype?
To answer that question, I'll take a look at TradeAbility, a major Web services development project at UPS. In this first column, I'll look at the business problem UPS was looking to solve, and why UPS chose to solve it using Web services. In my next column, I'll look at the details of the deployment itself.
The problems with global trade
UPS is the world's largest package delivery company, managing the flow of goods, funds and information in more than 200 countries and territories worldwide. It started as a messenger company in the U.S., and today is a global, $30 billion company. UPS has handled international trade for many decades, but in recent years, it has seen a shift in the kind of companies that engage in global commerce -- and this shift has been problematic for some customers.
In the past, only large, well-established companies tended to be involved in worldwide trade, and they often specialized in it. So typically, a large exporter in one country would ship goods to large importer in another country. Both firms usually have sizable staffs experienced with the numerous regulations, tariffs and forms required for international trade.
But as with many other things, the Internet changed all that. Because anyone can easily sell or buy goods in the global marketplace, virtually anyone can be an importer or an exporter. For example, if you buy goods on eBay from someone in Japan, you are the official importer of record for the transaction and a variety of regulations apply to you. It's not only individuals who can do worldwide business now, of course, but also small and medium-sized businesses as well.
This has proved to be problematic for many businesses that don't understand the regulations and rules that govern international trade, notes Gary Huff, marketing director, new product development for UPS.
"[These customers] want to make deals with international vendors and suppliers, but they're not used to doing that, and don't have the established business processes that more established importers and exporters have," he said.
Moving toward implementation
So UPS set out to solve the problem. Instead of examining any kind of technology, UPS developed a set of business requirements, including one that UPS had to be able to directly integrate into a customer's own internal processes and be available straight from the Web. Many groups, not just a single one, helped determine these processes, including employees from marketing, development , product development and others. The requirements were prioritized, and based on that, actual functional requirements were decided upon.
The cycle of doing this took several months. According to Geoff Calmers, UPS application project manager, "Making sure that we were serving the business needs and that we had a product that was going to be easy for our customers to use was the hardest part of the process. As in any implementation of this scale, we were working against a background of a changing marketplace … We solved the problem by making sure that our customers were heavily involved in the project all the way through."
Only when the functional requirements were decided upon did the group start to examine technology in a serious way. The group had to choose from either XML tools or Web services to build TradeAbility.
Calmers was convinced that a Web service was the better solution, and he suggested to UPS that Web services should be used. There were two primary reasons, he said:
- Web services are standardized, so they can be widely used, while XML offers too many options and choices, which means it could more problematic for a wide range of customers to easily use.
- Since Web services have more tools that can be used for development, Web services offer a richer infrastructure than XML. That means it would be easier and less expensive for UPS customers to implement.
Calmers noted that building it as a Web service also allowed UPS to leverage TradeAbility so the company could use it internally as well.
Huff added that doing it as a Web service meant that the solution would be easier to integrate into UPS customers' existing processes -- for example, they would then be able to integrate UPS online tracking into their own systems. Key to everything, he added, was easy integration.
Because of all these reasons, the decision to make it a Web service was a relatively easy one. But making a decision to build it as a Web service is one thing, and actually implementing it is another.
In my next column I look at how the project was implemented, and the ultimate results for UPS and its customers. I'll look at the planning process, roadblocks UPS developers came across and recommendations for others involved in Web services development.
Continues in Part Two
About the Author
Preston Gralla is an expert on Web services and is the author of more than 20 books, including How the Internet Works. He can be reached at preston@gralla.com.
