01 June 2003

Overcoming hurdles

By Alan MacLamroc

Web services prove nimble, but will they catch on?

In the competitive manufacturing environment these days, cost containment is critical to survival. Now, there is a new option with flexibility and speed: Web services, which offer users' companies the potential to grow rapidly without incurring hefty costs.

By using this technology, manufacturers can leverage partners' assets via network-based collaboration across the supply and demand chains. Through loosely coupled business networks, manufacturers can automate daily business interactions and streamline business processes among partners and in buyer-supplier relationships.

The openness of Web services lends itself to the constantly changing environment that results from fluctuations in customer demands. Because Web services are not hardwired to connections, things can change, enabling manufacturers to remain nimble. This feature will allow them to react to dynamic business conditions and relationships, and not experience a break in interaction. Even diverse technology assets can communicate with one another. But what could possibly matter most to manufacturers is the fact they can implement Web services incrementally and can leverage existing Information Technology (IT) assets, making them more responsive and flexible.

Cost-conscience manufacturers need to make practical decisions that they are confident can positively impact their operations.

Rochester, N.Y.–based Microwave Data Systems (MDS), a wireless solution provider for the utility telecom, industrial networking, and online transaction processing industries, had a goal of streamlining its small package-shipping operation while improving overall customer service. In this case, MDS decided to use the universal shipping system (USS) in conjunction with the SyteLine enterprise resource planning solution from MAPICS, Inc. As a result MDS accomplished both objectives.

USS uses direct component object model plus (COM+) communication within its integration to SyteLine, but leverages Web services for communication with its support carriers. When order-entry personnel want to retrieve rate and delivery information from a carrier such as UPS or FedEx for a quotation, all they need to do is hit the request button from within the SyteLine order screen. USS then calls out to the carrier specified on the order via a Web service. Within seconds, the carrier's site responds with the requested information, and the order-entry personnel can continue with the quotation process, confident in the shipping information provided. After an order ships and the customer calls looking for the shipping status, the system again can call out to the carrier to retrieve this information based on the tracking number stored with the shipment.

"We no longer have to manually enter shipping charges on customer orders," said Dwayne Niewiemski, manufacturing program manager for MDS. "Our customers can know up front what the shipping charges are, and they also know what the additional charges are for expedited shipments. Our shipping department now works from one application to process shipping transactions with multiple shipping carriers. The shipping method is automatically filled in from the customer master defaults and can be easily overridden at order entry or shipping. This gives us full control of the shipping process, thus improving our internal operational efficiency while improving our customer service."

Web services are still a new innovation, and as such they require maturation of standards and support platforms. The first wave is behind us, the definition of standards to establish connections: extensible markup language (XML) schema, simple object access protocol (SOAP), web services description language (WSDL), and universal description, discovery, and integration (UDDI)—a standard for a Web services (WS) registry. The next area of concentration is security and reliability.

Security exists for network level, with hypertext transfer protocol with secure sockets layer (SSL) and encryption via SSL. The WS-Security specification addresses a more complete scope. A complete solution must address:

Authentication—identity of party accessing a service
Authorization—services a party is authorized to use
Auditing—record of access and use
Availability—denial of service attacks
Privacy—protection of the information on the network
n Integrity—data transmission completeness and accuracy, and
Nonrepudiation—ensuring a transaction becomes accepted.

An optimal model for Web services security is for it to be a network service (versus node-imbedded) for efficiency and scalability.

NEXT IN LINE

Now that the standards to establish connections are in place, the next area for standards to address is management of long-running transactions. Currently, there is no definition for two-phased commit style transactions for Web services. This will be perhaps the most challenging arena, ensuring reliability for a business transaction that spans multiple network nodes, system boundaries, and enterprises outside the firewall where the transaction started. Several standards are addressing this problem space, notably WS-Transaction, which provides mechanisms for defining the type of transaction and a way to coordinate the activities in that transaction, and WS-Coordination, which provides a framework for executing the WS-Transaction protocols. A complementary notion is business process flow definition. Business process execution language for Web services specifies and automates business process execution. IBM's Web services flow language and Microsoft's XLang form the basis for this specification.

Other issues that need further definition and infrastructure support are network management concerns such as service provisioning, service execution health monitoring, and quality of service issues.

Web services are software components that you can call up over a network, using two newly evolved standards, SOAP and WSDL. The former describes a way to send a message with an XML payload to invoke a service; the latter is a way for a service to describe what it offers and establish how it should come into play. SOAP is typically bound to the hypertext transfer protocol, which allows it to pass through firewalls, but SOAP can also work with more robust network protocols.

These underlying developments have enabled a new way of thinking about building software: service oriented architecture (SOA). John Zachman, a strategic planner at IBM whose work laid the foundation for modern system development methodologies, said manufacturing was the best analog for systems development. He said that with the right architecture, manufacturers would be able to build business functionality in an assemble-to-order fashion. He was right, and that vision is now within reach. SOA allows components to assemble as services to solve business problems. They provide an interface to these services that greatly simplifies their use, and the loosely coupled nature of the interface allows the underlying logic or organization to change without breaking the interaction.

Web services put a business face on application components. Interfacing to these components occurs at a higher level than previous distributed computing standards, such as common object request broker architecture, which proscribed interface definition language (program-level) as the standard for application program interfaces.

Working at a higher level reduces the complexity, and therefore makes the architecture more robust and flexible. Also, applications can now come into play regardless of where they reside, so concerns about portability and compatibility recede. Execution is standards based and therefore independent of underlying technology. IBM Java 2 platform enterprise-edition services, written in Java, can utilize Microsoft .Net services, written in C# (C-sharp). Widespread use of Web services will come through standardization of access and transaction mechanisms.

THE NEXT STEP

Like any technology change, it will take a critical mass of software developers to adopt Web services before they become a truly essential part of the enterprise-systems landscape. And that will take time. Most application software developers have at least announced support for the new technology, and many have initiated development projects to incorporate some Web services functionality within existing product lines.

Still, don't expect to be able to fully enable your business for Web services in the next few weeks or months, even if your own applications are completely enabled. After all, it takes appropriate technologies on both sides of the business transaction.

We will soon encounter the "trough of disillusion" that all new technologies go through, where the expectations from the hype meet the letdown of the pace of implementation. This is because (1) the technology is not well understood by business people, and (2) while it is being incorporated into applications now under development, publicized success stories of real business benefits will have to wait until more Web services deploy and are in use.

To ensure your company fits into the Web services model, ask the vendors of all strategic software systems in your organization what their position is on Web services and how and when they will incorporate them in their applications. Also, understand the Web services plans and progress of any vendor on your short list for new or replacement applications under consideration. Thirdly, if you have internal software development and support resources, make sure they get the opportunity to learn about Web services and how they work. You might also want to gain some experience by adding Web services functions to existing applications for internal, interplant, or intersite use before asking trading partners to work with you on intercompany operations.

Web services will play a pivotal role in supply chain operations in the foreseeable future, bringing a whole new level of collaboration and coordinated responsiveness to those enterprises willing to make the investment.

Are Web services a reality? Yes, and as more people understand the benefits and the opportunities it can provide for global, seamless business processes, pervasive business interoperability will become a reality. IC

Behind the byline

Alan MacLamroc is chief technology officer of MAPICS, Inc., an enterprise resource planning, customer relationship management, and supply chain management provider. MacLamroc has nearly twenty years of enterprise software and services industry experience.

The road to Web services

There are three major technology advances that helped lead to today's era of Web services.

The first development was in network infrastructure. Internet protocol became the universal standard, allowing the creation of global networks that utilized a common network protocol. Unprecedented capital expenditure by telecomm providers creating a global grid of network access accompanied this standard. Coupled with advances in wireless technology, used in less-developed areas to hurdle the build-out issues they faced, there is now ubiquitous network capability worldwide, with massive amounts of data transport capacity in the industrialized world. Other network standards and advances, such as acceptance of simple network messaging protocol as "good enough," spurred the advancement of the Internet, which in turn led to the acceptance of a loosely coupled interface, specifically a browser, to access data and operations performed on that data.

The second advancement was the pervasive acceptance of object-oriented design, even down into operating system–level code—a move that revolutionized the programming world. This loosely coupled, message-oriented programming model allows the development of software as components or structures, which are completely analogous to the business operations they model and enable. Message architectures also greatly reduce the perceived complexity of systems by hiding the specifics of underlying processing, thus speeding development.

The third element necessary for the creation of a Web services–enabling common network data infrastructure was a universally accepted data standard. Over the past few years, XML has evolved into the common data format for the Internet. This is perhaps the most important development, as it removed the intractable problem of how business systems talk to each other, an issue that had thwarted more widespread utilization of distributed, network-based computing.

Now, with the foundation laid, the necessary components in place, and a common language to use, Web services are a reality.

— Alan MacLamroc

Coming Next

Ask The Experts

Read questions answered by our experts or join the email list.