Page 237 - DCAP312_WEB_TECHNOLOGIES_II

Unit 11: Web Services in Visual Studio .NET

Notes
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 does not 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, “Do not
expect your users to be happy with response times. It is 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 have 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 is 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 Hyper Text 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 do not 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. 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.

Contd...

LOVELY PROFESSIONAL UNIVERSITY 231