The links that bind

Web services have a bright future in the trucking industry, as information can be exchanged among different systems – internally and among various supply chain partners – in real time. Despite these benefits, roadblocks remain, mostly related to customer preferences and ROI.

By today’s standards, the fax machine and telephone seem as ancient as smoke signals or drumbeats as business communications tools. But the Internet isn’t always a dramatic improvement. Logging on to websites or sending e-mails often is just a way to perform clunky, manual tasks faster.

The Internet truly can shine, however, as the backbone for Web services – a mechanism many businesses use to automate the exchange of data and transactions among information systems. Web services make it possible to easily abstract and access data from one system, and read and write data to another system.

Dispatchers at Caldwell Freight don’t visit websites to track trailers. Instead, the 180-truck carrier based in Lenoir, N.C., uses Web services to receive GPS and other trailer-tracking data in a readable format for its AS400-based dispatch program. So far, Caldwell Freight hasn’t seen the need to use Web services in other areas of its business, says Lisa Yow, director of information technology.

Similarly, Arcadia, Ind.-based Tradewinds uses Web services provided by several trailer-tracking vendors. Rather than visit separate websites to access location and other information on trailers, fleet managers rely on a tool developed by Ben Becker that integrates the information directly into Tradewinds’ information systems and custom reports.

“The ability to rely on this model is open to just about every application and scenario used in business today,” says Becker, chief information officer of the 150-truck carrier.

Becker believes that Web services have a bright future in trucking that will go beyond asset tracking. Information can be exchanged among different systems – internally and among various supply chain partners – in real time, and synchronized with important events surrounding the physical status of freight and assets, Becker says.

Despite the clear benefits of Web services as a platform for exchanging information electronically among business partners, adoption has been slow for various reasons. Nor is it at all certain that Web services will overtake electronic data interchange (EDI) as the new standard for exchanging information with customers.

Problems and promise
Many recent versions of the software carriers use to manage their businesses were developed using a Service-Oriented Architecture (SOA) model. SOA is a framework for software development that takes the functionality of a program and decomposes it into small, distinct units or services. The term “Web services” often refers to the registry of information services a business chooses to make available to others – its consumers – via a Web server and Internet connection.

A Web service uses a universal computer language, eXtensible Markup Language (XML), to describe and structure the data to be exchanged in a file. Programmers use the Simple Object Access Protocol (SOAP) to encode the XML file to make it “readable” by any operating system – Windows, MAC, AS400, etc. In other words, XML is used to tag data, and SOAP is used to transfer data.

When a Web service from one application is embedded into the computer code of another application, the latter is said to “consume” the Web service. In effect, one computer asks another a specific question and receives a succinct answer, says Marc Mitchell, transportation practice director for EIS, a transportation software developer and consultancy.

Today, Web services appear to suffer from reliability problems. Information systems managers must closely monitor the quality of Internet connections; a dropped connection with a vendor or other provider of Web services in midstream fouls up data exchanges.

“It is not a dedicated connection, so [Web services] need a lot more control,” says Tom Benusa, chief information officer for Transport America, a 1,300-truck carrier based in Eagan, Minn.

Furthermore, XML lacks definitive standards for describing data. Just as in English, XML code can have different meanings. A vehicle tracking system, for example, may use the XML tag ” 12:00 ” to define the value of 12:00, but what does “time” mean? Is it when the system recorded its GPS location? Or is 12:00 when the system transmitted its information over the airwaves? What time zone is it? In general, fleets that consume Web services must ensure that the data they consume matches their own definitions, Benusa says.

Benusa’s staff has tested pulling data from a mobile communications vendor via a Web service using XML. “It has actually been a painful process, with a lot to learn on both ends before getting it reliable and stable,” he says.

These frustrations aside, Web services do have promise. Because XML uses simple English to label the data in a file, it is easy to identify the various entities and attributes of the data in the documents to be exchanged, Becker says. And since an XML Web service is a structured document, it provides a mechanism to support more complex data types, such as one to many data relationships that are difficult to do with traditional “flat file” formats, he adds.

Web services could be a key component of a fleet’s technology strategy for automating business processes. Tradewinds automates its driver log auditing process by using Web services to merge logbook records from its log scanning system with fuel purchase data captured by fuel payment processing vendor Fleet-Tech Transportation Services (FTS).

“With Web services, we built an interface on our side that allows FTS to easily consume our data at will and merge the data into their system, which is published to us weekly,” Becker says.

Becker also is finalizing development of a mobile phone application that will let dispatchers manage drivers while they are on call but away from their desks. The smart phone application will consume Web services from multiple applications using a single user interface. When a dispatcher selects a driver, the application calls a Web service from Tradewinds’ enterprise software system, TMW Suite, bringing in the driver’s basic load status information. The application also consumes Web services from FTS to allow dispatchers to activate or deactivate a driver’s fuel card or generate an electronic express check.

Fleet managers will not notice that they are tapping data from multiple systems in real time, Becker says. “All of this will be powered by Web services to interface seamlessly to the backend systems through the Internet.”

Becker provides details of several other applications he has developed that use Web services
at, a blog he authors about his experiences and insights into technology and the trucking industry.

Commercial offerings
For a growing number of commercial software providers in the trucking industry, Web services is a way to unbundle the functionality of their products, and to offer customers anytime/anywhere access to the data and functions they choose to consume.

Suppose a fleet wants to build or buy a freight-rating application that would require standard mileages for every ZIP-to-ZIP combination. The fleet also may want to incorporate directions, toll costs and mapping into their product. The information for this application could be brought in, on demand, through Web services by embedding a code into the program – instead of installing a comprehensive mapping and mileage software package in the office.

Earlier this year, ALK Technologies launched PC Miler Web Services. The offering enables fleets and other customers to write custom interfaces to the PC Miler database engine to call up whatever information and functionality they want, on demand, says Craig Fiander, ALK’s senior director of marketing.

The full database and functionality of PC Miler is housed at an offsite provider, and customers choose which functions they wish to consume. Customers that use PC Miler Web Services pay for the features they choose, not for the number of transactions they generate. One customer may want only the core mileage functionality. Another may want mileage, mapping and reporting. Others may want the full functionality of PC Miler, including toll costs, maps and driving directions.

Some fleets may prefer to not write interfaces themselves. In many cases, PC Miler Web Services is a more appropriate platform for transportation software providers that want to include PC Miler functionality in the products they market directly to fleets, Fiander says.
“In general, it is a very attractive benefit for our partners,” he says. “They do not have to worry about an annual version update. It just works. It’s very attractive for vendors as much as it is for the end user.”

This year, TransCore launched a new freight matching Web service called Connexion.

Traditionally, brokers and carriers that use TransCore’s freight matching system -called 3sixty Freight Match – had to log in to a website to post loads and trucks, and to search for matches.

“With Web services, you don’t have to use our application anymore,” says Gordon Ferlitsch, TransCore’s vice president of technology. With Connexion, fleets and brokers can integrate freight matching directly into their own transportation software, making freight matching part of their workflow. TransCore customers can “utilize the data from freight matching in any way they can conceive of,” he says. “These are things that were never possible until XML Web services.”

Online Freight Services (OFS), a third-party logistics provider based in Mendota Heights, Minn., has integrated TransCore’s freight matching within its custom-built freight management system, Freight Track.

“We use their Connexion interface to pass data back and forth,” says Jeff Burns, OFS chief technology officer. “We are posting loads that way automatically. Our load posting is real time when we use their product.”

Anytime one of OFS’ 65 broker agents enters loads into the company’s Freight Track system, they can check a box in Freight Track to post their loads directly into the 3sixty Freight Match website. The load information is transferred immediately.

“From our standpoint, that is a competitive advantage,” Burns says. Before using Connexion, agents would spend about 10 to 15 minutes per load going to the website to post and remove loads. Connexion also provides truck-load matches in real time to Freight Track.

“We are trying to be leading-edge, and to gain efficiencies where we can to make it easier to move more freight,” Burns says. Building the interface for Connexion to work was easy, he says: TransCore provides its users with a software development kit that has code samples for integrating its load posting and load matching features.

Customer communications
Important considerations in freight transportation such as payment and liability mean that the quality of information about freight movements can be just as important to carriers as the freight itself. For years, truckload and less-than-truckload carriers have exchanged information with their customers via EDI and third-party value-added networks (VANs) to facilitate transactions between dissimilar systems. This model has proven to be costly, cumbersome and complex.

XML is simpler than EDI, since XML uses plain text to create “tags” that describe information fields such as name of consignee, delivery address, billing address, etc. XML supporters say XML is preferable because a company can map its data in XML-based definitions on a secure website. Its trading partners then can go to its website and pick and choose what data they want to exchange.

As a viable alternative to EDI, XML eventually will become the preferred mode of communications, says Dave Mook, chief technology and chief operating officer of TMW Systems, a provider of fleet enterprise resource planning (ERP) software.

Mook predicts that within the next five years, a majority of carriers will use Web services to exchange load tenders, shipment status and invoices with customers. Increasingly, shippers and third-party logistics providers will insist on Web services because they will prioritize data instantaneously rather than depend on carriers “pushing”
EDI data to them, Mook says.

XML has a long way to go, however. Today, TMW’s customers altogether exchange more than 1 billion characters a month with their customers through EDI, and roughly 20 to 30 million characters via XML Web services – about 2 to 3 percent of the volume of EDI. The supply chain currently relies heavily on EDI, and shippers, carriers and 3PLs may find they have more pressing concerns than transitioning to an entirely new communications backbone. (For more on the issue, see “EDI’s a hard habit to break,” page 58.)

Whether or not Web services ultimately replaces EDI, its advantages and momentum in many other areas are clear and hard to ignore.

EDI’s a habit hard to break
Some carriers say Web services not worth investment, effort

Even carriers that are using and experimenting with Web services based on the universal eXtensible Markup Language (XML) for operational needs aren’t necessarily convinced that they offer a viable alternative to electronic data interchange (EDI) for transactions with customers.

“We still do the vast majority of electronic communication with our customers via EDI,” says Transport America’s Tom Benusa. “With EDI being so prevalent here, over 50 percent of our orders come to us via a ‘204,’” – the shorthand name for an EDI load tender. “It is more efficient for us to continue that model than it is to move to XML.”

Transport America has moved most of its high-volume customers to direct connect via AS2 or FTP to avoid value-added network (VAN) charges. These methods are similar to XML-based Web services in that they allow carriers and shippers to exchange data directly, instead of through a VAN. But AS2 and FTP do not facilitate real-time queries from one machine to another. Going to XML Web services will facilitate real-time data exchange, but it also will have many of the same challenges as EDI, Benusa says.

“What one shipper considers to be the value of a field will differ from what another shipper considers that value to be,” Benusa says. Pulling data might be easier, but interpretation of that data will still be challenging when one shipper is using fields for different purposes than other shippers do, he adds. “In the end, it is still likely that there will be a customized XML format for a shipper, just as there is a customized EDI format when they deviate from the ‘standard.'”

Caldwell Freight’s Lisa Yow says she doesn’t see any compelling reason either to move to XML Web services from EDI or transactions through a website. Already, a majority of its customers login to its website to trace their shipments. For a carrier, having a shipper visit a website is automation, Yow says, as customers can trace shipments and request delivery documents online.

Going to XML Web services would take significant effort, Caldwell says. “Things already have been set up, and it is easy to make a change for someone else. XML would be like starting all over.”

This opinion is hardly universal, however. Con-way has a much different experience with XML. Most customers already are doing some form of XML Web services or EDI transactions with the San Mateo, Calif.-based company. While the number of XML transactions is smaller, it is growing at a faster rate than EDI, says Tom Nightingale, vice president of communications and chief marketing officer.

Many Con-way customers, for example, incorporate a Web service from the carrier to build customized rates into their own websites, Nightingale says. When an online shopper orders an item, the website calls up a Web service from Con-way’s server to get freight charges, based on the attributes of the shipment the shopper orders.

In addition to offering customers a full menu of Web services, Con-way is working to improve the customer self-service tools it offers through its website. In December, the company launched a new website ( that features a Quick Tools module. Customers now can select from 30 different tools on the website, store them on their home page in any sequence, and eliminate those they never use, Nightingale says.

Web services terms defined

Key components in the Web services framework – used to abstract the message content, transportation and implementation language, and standardize the exchange of data – include:

  • eXtensible Markup Language (XML), which describes what the data is. By comparison, HTML was designed to display data and focus on how the data looks. XML was created to store, structure and send information.
  • Simple Object Access Protocol (SOAP), an XML-based protocol for messaging and communication between applications. A protocol is a communication language for sending data between software applications on one or more computer systems. The basic communication language or protocol of the Internet is Transmission Control Protocol / Internet Protocol (TCP/IP). SOAP is built on top of TCP/IP.
  • Web Service Description Language (WSDL), an XML-based language used to describe Web services and how to locate them. It provides information on what the service is about, where it resides and how it can be invoked. A fuel card vendor, for example, may provide a WSDL to a fleet that wants to consume the Web services that the vendor offers.
  • Accredited Standards Committee X12 group (ASC X12) is an organization that brings together business and industry professionals in a cross-industry forum to develop and support electronic data exchange standards, including XML schemas for transportation. See more information.
  • .NET, Microsoft’s new Internet and Web strategy. It is a framework that delivers software as Web services.