As I speak both formally and informally to developers about Web services, the same questions always come up: Is anyone we know doing it? Don't we have to wait for .NET or the next version of J2EE? Is it secure enough to be trusted?

The best way to answer these questions is to look at leading-edge companies that have already successfully implemented Web services. Barry-Wehmiller is just such a company. Located in St. Louis, it is an e-commerce marketplace that brings together buyers and sellers, as well as seekers and suppliers of information, to provide value-added alternatives to the packaging industry. The company recently completed a Web services application based on current Microsoft technologies that provides insight into the questions.

Barry-Wehmiller Thinks Forward ...and Adopts Web Services
In Q1 of 2000, Barry-Wehmiller, like many forward-thinking organizations, began evaluating their strategic development and reviewing technologies that could provide a competitive edge. The company had successfully developed a marketplace that provided a meeting place for manufacturers, brokers, consultants, and material suppliers with a variety of end users, such as plant engineers, purchasing agents, and maintenance managers. Suppliers could post changes to their catalogs and receive orders in near real time - but with a catch. Proprietary systems and a significant trust relationship were required for the successful integration of the supply chain.

The technology solutions combined the use of asynchronous messaging through Microsoft Message Queue (MSMQ) with a VPN (see Figure 1). This solution, though effective, incurred significant maintenance costs, set up serious barriers to entry, and raised security concerns. Internal and acquired suppliers could be trusted as part of the VPN, but what of outside suppliers? Would the cost of implementing MSMQ and a VPN, in addition to the integration of data formats, raise the bar too high? Would suppliers running non-Microsoft platforms pass on the business opportunity, rather than be forced to maintain a Microsoft server (including maintaining MSMQ)?

Web services offered them a way to lower the barrier to participation in the supply chain while increasing the company's overall security - with the added benefit of eliminating the VPN, along with its associated cost and maintenance.

Clear Business Value Proposition
The business value proposition in this particular case is an instance of one of the overall key value propositions of Web services in general. Barry-Wehmiller wanted to develop a complex and secure technological bridge to an abstract class of business partners (in this case a supplier) through standards-based service mechanisms. Before Web services, the complexity of the technology interface would need to be evaluated with each new supplier and (unless there was a lucky alignment of the technology stars) the construction effort would be repeated. The elimination of this repetition of effort and the associated cost in time, effort, and expertise leads to new business opportunities in which relatively new business relationships may engage in complex transactions between disparate operating and security environments.

The Technology Picture
So, the business case was clear. But what about the choice of technology? In this case, Barry-Wehmiller chose to implement SOAP across https using the Web technologies already in place - i.e., Microsoft. Its current Web offerings were developed on top of Windows NT 4.0 and Internet Information Services (IIS) 4.0 using Active Server Pages (ASP), VBScript, and JavaScript. Microsoft SQL Server and MSMQ provided data services on the Web farm and asynchronous messaging. Business objects were developed with Visual Basic 6.0 and for the most part ran in the context of Microsoft Transaction Server (MTS).

Barry-Wehmiller had the choice of either being an early adopter of Microsoft .NET or working with an older version of IIS/ASP to implement XML-based RPC. Fortunately, Microsoft had already provided the MS SOAP Toolkit 2.0 and some key samples. Some quick proof-of-concept attempts showed that the available functionality was sufficient for its needs.

I should mention here how surprised I am that so many developers fail to realize that Web services are already available with the current toolsets in both the Microsoft and Java world. The conversations I have with them usually go something like this:

Me: "Hey, have you had a chance to mess around with Web services?"
Developer: "Well, no, I haven't installed .NET on my machine yet."

The Tools Are Already Here
For Microsoft developers, the SOAP Toolkit 2.0 (you know, the one that really works) has been out since early Q1 of 2000. Get it! Play with it! (Sorry about that, I know you know that: but would you please tell your friends? OK, I got that off my chest.)

I understand the disconnect: Microsoft touts .NET as the premier Web services platform and developers make the assumption that the current technologies are insufficient. Visual Studio.NET certainly increases development productivity by being intimately aware of SOAP and XML and providing some interesting and powerful language extensions through its attribute-based programming features, but the current toolset is sufficient and quite productive.

How productive? With two developers and one half-time project manager, Barry-Wehmiller completed the conversion to Web services in less than two months! Operations were up and running on budget and on time - a significant feat when you consider that the company was introducing a new programming paradigm to a mission-critical application.

Secrets of a Successful Transition
As a consultant who helps development teams transition to new technologies, I was interested in understanding how the Barry-Wehmiller team was able to make this successful transition. "Training was absolutely critical," Chris Brauch, manager of site development, told me. As I talked to the developers and support staff, I asked whether the transition to Web services was as difficult as the transition from client/server to Web development. The answer was a resounding "Yes!" They'd attended several seminars and read articles and books, but a formal class was what proved critical in enabling managers, developers, and support staff to come up to speed. Consultants were important as well: Barry-Wehmiller engaged G.A. Sullivan to provide critical insight and assistance with the SOAP implementation. The mentoring of a knowledgeable consultant in the context of this real-world project gave the company the ability to apply skills gained in the classroom to its problem-space.

Missing Jigsaw Pieces
The final technical solution is indicative of the present state of Web services. Though SOAP proved sufficient for the transmission protocol, work external to the Web services framework was required for two of the key elements of the solutions: encryption and guaranteed delivery (see Figure 2). The requirement for external components to handle encryption and guaranteed delivery detracted from the overall goal of loosely coupled services, and required that multiple implementations be constructed depending on the supplier operating environment. That was exactly what the company was trying to avoid!

Recent submissions to the W3C by IBM and Microsoft (www.w3.org/2001/03/WSWS-popa/paper51) highlight the still-missing pieces in the Web services jigsaw puzzle, such as standards for binary attachments (eliminating the performance cost of converting to and from a textual representation), message routing, transactions, digital signature support, guaranteed message exchange, and encryption. Barry-Wehmiller is looking at these developments to enhance its Web services offerings and further reduce the barrier to entry into its supply chain.

Despite these missing pieces, the investment made has produced the return expected. New suppliers are able to come on board with minimal investment. The VPN has been eliminated and suppliers don't have to participate in any trust-relationship with the corporate network. Performance has been increased by 150% over the MSMQ/VPN solution. Maintenance costs have been significantly reduced.

Further, with the expertise gained and a solid success under its belt, the development team at Barry-Wehmiller is poised to embrace new Web services technologies that will enhance and expand the service offerings and thereby maintain their leadership in the market.

Conclusions
So, back to those three questions I keep getting asked...

Is anyone we know doing it? Yes, and they've been successful with a surprisingly low investment. Their ROI has been solid and they're poised to capitalize further on their initial success.

Don't we have to wait for .NET or the next version of J2EE? Absolutely not. While these new tools provide some impressive support for SOAP and XML, toolkits are available as effective bolt-ons to current technology.

Is it secure enough to be trusted? Probably not by itself, not yet. So consider third-party tools or home-grown mechanisms in order to add features such as encryption, digital signature support, and guaranteed delivery - and watch the W3C for fast action on these critical missing puzzle pieces.

Author Bio
Eric Lynn, a software architect with 11 years of experience in both Microsoft and Java technologies, has authored several courses on Microsoft Distributed Technologies and has taught publicly as well as privately (for Fortune 500 companies, including Intel Corp). He's CEO of DeltaPoint Solutions, a company focused on helping development teams make a successful transition to new technologies, and is a frequent speaker on technology trends. elynn@deltapointsolutions.com