Web services are "in production." While much of the trade press insists on covering web services as a future technology, it is solving problems for organizations today. This case study profiles how one successful public deployment looks to the programmers who coded it.

Are web serivces projects manageable? This is a crucial uncertainty that plagues many deployment plans. Readers of the developerWorks web services zone already recognize that web services is a proven technology that will be of enormous importance in the near future. What are the consequences, though, for project planning and fulfillment? How does web services work differ from earlier generations of client-server or host-based programming? Lucin's public Short Message Service (SMS) sheds light on these questions.

Categories of services use

First, consider the industrial context for web services. Most such projects today fall into one of four categories:

1. Content management, collaboration, and syndication. Public leaders in this have been Dave Winer's Userland, O'Reilly and Associates' Meerkat facilities, and Jon Udell's development and articles for Linux Magazine and Byte.com.
2. Internal service consolidation. Not unlike the explosion of "intranets" in 1995 and 1996, quite a bit of web services development is hidden from public view behind firewalls. Organizations strategically dependent on a variety of technologies are consolidating their internal interfaces as services.
3. CORBA and DCOM substitution. Projects might be feasible with CORBA (IIOP, more properly) or DCOM, and would have been executed that way last year. This year, though, decision-makers have begun to choose web services as a technical substitute for these competing distributed-computing protocols.
4. "Programmer-centered" projects that exploit web services' public nature and interoperability in a way CORBA and DCOM don't effectively rival.

This case study falls in the last of these categories: Web services brings crucial benefits for this application that CORBA and DCOM can't match. DCOM essentially limits clients to those running on Windows desktops. On the other hand, CORBA is "heavier" than needed for the simple processing the gateway requires. Moreover, real-world CORBA projects have the reputation of stumbling over firewall and interoperability problems that web services handles gracefully.

Back to top

Development team: vital statistics

Lucin PLC is a small software consultancy headquarterd in Newport, Wales, in the United Kingdom. Mike Clark is its founder and managing director. It has specialized in transaction-oriented client-server applications for over a decade. In February 2001, three engineers began work on a small demonstration of a web services-to-SMS gateway. A few weeks later, in March, it opened the service to the public.

"Short Messaging Service" or "Short Message Sending" is widely supported in wireless telephones in most European and Asia-Pacific countries, although rarely in the USA. Wildly popular in Japan and elsewhere, SMS allows telephone users to compose short textual messages using the telephone handset, and transmit them asynchronously. Think of it as instant messaging for cellphones.

It's natural to bind together the pertinent telephony and computing protocols so that computers can originate and perhaps receive such messages. That's Lucin's achievement in its web services-to-SMS gateway; it is the first of several such for-fee gateways it plans for the months ahead:

• Web service to pager
• Web service to fax
• Web service to speech
• Web Service to TAPI (telephony application programming interface)

In Lucin's plan, it'll be only a short time, probably the final quarter of 2001, before it has the capability to dial a conventional telephone, and read out an arbitrary message in a synthesized voice.

The starting point, though, is the integration of web services and SMS. Let's look at that first step in more detail.

Back to top

Construction of a web service

The SMS gateway is a small software project. Much of the media publicity around web services envisions integrating enterprise applications on large supply chain projects. Clark insists that this misses the point of the "instant gratification services" already moving into production for modest, well-specified projects. He deliberately chose SMS as a model. As Clark indicates, "[SMS] fits this [model] perfectly as a web service that's great to use," but can afford occasional outages or downtime.

Current infrastructure enforces this kind of tolerance. Networks simply are not 100% reliable or ubiquitous yet.

Some web services vendors are hawking "revolution" with the intelligence in their web services tools. However well this software works in the laboratory, it appears few organizations have enough well-connected customers to layer so much weight over existing networks. It doesn't matter how clever the error-correction and transactional algorithms one programs: until basic network connectivity gains an order of magnitude in price and reliability, there's little point to building elaborate web services. Clark summarizes, "Don't expect your users to be happy with response times. It's currently out of our hands; maybe in two years time it will change."

The inadequacy of the current networking infrastructure impels Clark to manage Lucin conservatively: "We've deliberately budgeted for a three year cycle, meaning we can pretty much last three years with no significant customer base. This is because my belief is that it's going to be a long trek before web services are thought as reliable and trustworthy enough for businesses to use in the long term."

In the meantime, the kinds of service that do satisfy users might be even simpler than you expect. Web services developers think of the typical high-level design as one that pulls in data or objects across the network, performs calculations on them, then uses web services protocols to deliver results back across the network. Lucin sells a number of web services products that fit this model and has several internal tools to support such development.

For the SMS gateway, though, Lucin eventually settled on an even more primitive approach. Clark explains that ". . . if you know the interface then you simply need to construct a simple string variable and substitute the values that change at the time you send the data to the remote web service. This saves time and the overhead of having to reference [a SOAP toolkit or module]."

Lucin does this simple string substitution, and the other light-duty calculations involved in the production version of the SMS gateway, with Visual Basic, hosted on an NT Server 4.0. This supplies more than enough performance for the several hundred messages transacted each day (most often between 300 and 800).

The gateway's simplicity extends to its authentication: a user-password combination sent in plain text by way of HyperText Transport Protocol (HTTP). Clark contends, "You would not expect to use HTTPS [secure HTTP] for signing onto a web site, so why use HTTPS to get users to pass down username and passwords so that you can validate them for using your web service." Pressed about the frequency of HTTPS use, Clark criticized its run-time performance, and concluded, "we may be using HTTPS ability at some stage, but it will almost certainly be by customer request."

"One of the beauties of web service development," according to Clark, "is the flexibility that comes from use of simple, robust parts." The gateway connects on the back end to a metered SMS interface provided by a telecommunications vendor. Twice already, Lucin has switched providers for this back end, but without any interruption in service to its customers. Users of the gateway just receive acknowledgment of receipt of their requests; they don't have to know or care about the back end.

Authentication, along with interfaces to validate telephonic country code and local number, make the Web Services Description Language (WSDL) instance for the gateway one of the most widely-used publicly-visible services (see Resources). it defines four operations: SendTextMessage, SendMessage, ValidPhoneNumber, and GetCountryCodes. Part of the definition for the second of these, for example, is shown in Listing 1.

       <message name="SendMessageRequest">
         <part name="PhoneNumber" type="xsd:string"/>
         <part name="Message" type="xsd:string"/>
         <part name="SenderName" type="xsd:string"/>
         <part name="SenderPassKey" type="xsd:string"/>
       </message>
  

Lucin largely recycled its expertise in Visual Basic and allied technologies for this project. Clark tells, "the web service is simply a layer to DCOM components."

The next changes for the gateway, according to Clark, are "to push it as a pay to use service," at 4.5 British pennies per call, and to contract with telecomm provisioners for development of the pager, FAX, and other gateways mentioned above.

Back to top

Manageability conclusions

As a software project, the SMS gateway is small: under a dozen engineer-weeks went into its design, implementation, and deployment. Clark is reluctant to offer specifics about the coding, for competitive reasons. Part of the argument that he does advance publicly, though, is that web services provides the advantages of component-based software development. Requirement sets apt for web services often decompose naturally into simple designs to which even junior coders can contribute.

Other public web services also appear to be small in engineering scope. XMethods.net has a gateway to PacBell SMS (in the western United States). It has an even simpler public interface (see Resources), transacting only a single WSDL operation: sendMessage. The most elaborate public service interface is Lucin's demonstration of a mailing list manager. While this defines twenty six distinct operations, all the data transacted are of simple types such as string.

So, what's special about web services development? We are all really not sure yet. None of the companies doing large-scale web services-based development are disclosing much about their experiences. At small scales, the technology "feels" like other light-duty networking development. It is a definite advantage that humans can read XML, and that so many tools are available for its management.

Clark's view is that "The problem in developing web services is not the development cycle, but trying to create a web service that people will pay for." With the web itself now starting its second decade, the basic technologies are quite well understood, but there's still plenty of dissatisfaction and experiment in getting the right "business model" for human-readable web sites. That looks to be the biggest challenge for external web services -- the fourth category named in the introduction -- as well.

The big change in web services development is likely to come when its "component market" has matured in the fashion of the OCX or VBX practices. The technology already emphasizes work with building blocks, and that's likely to intensify as more and more services come online. One difference, perhaps, will be the influence of open source. While OCX and VBX had proprietary definitions and components licensed for fee have always dominated that field, web services are based entirely on public standards, and many of the toolkits for this technology are open-sourced.

Resources

• Userland home page: Dave Winer's Userland is a reliable location for enthusiasm about and experimentation on web services content syndication and related matters.
  
  
• "Meerkat, an Open Wire Service," O'Reilly's demonstration news web services.
  
  
• Check out Linux Magazine.
  
  
• Visit Byte.com.
  
  
• GSM - SMS Overview: a technical overview of SMS.
  
  
• Take the developerWorks tutorial on "Short Message Sending for Wireless."
  
  
• Read the Microsoft white paper, "IP Telephony with TAPI 3.0."
  
  
• Bowstreet's ambitious vision for tightly integrated, ubiquitous web services can be seen this whitepaper: "Bowstreet - Beyond B2B."
  
  
• WSDL instance for XMethods.net PacBell SMS.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Categories of services use
• Development team: vital statistics
• Construction of a web service
• Manageability conclusions
• Resources
• About the author
• Comments