Level: Introductory Cameron Laird (Cameron@Lairds.com), Vice president, Phaseit, Inc.
01 Aug 2001 Web services are moving into production. This case study of a Short Message Service application examines issues specific to Web services development in telecommunications services. 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:
-
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.
-
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.
-
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.
-
"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.
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.
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.
Listing 1: process.xml
<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.
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
About the author  | | | Cameron is a full-time developer for independent consultancy Phaseit, Inc. He writes frequently on Web services and other technical subjects. He can be reached at Cameron@Lairds.com. |
Rate this page
| 
