A problem with a web service that hides the code that produces
results is debugging it remotely. One assumes one doesn't
have to debug it because one can validate the
results. But is that the case? Umm... co-occurrence
constraints, being sure that the returned set is
complete and not simply valid, come to mind. Factory
Acceptance Testing (FAT) and cutover are about proving the
system works as specified. Contracting is about making
sure the specified system is built according to the
requirements and that's it. The contest is when one
gets into the FAT, how to stay out of the fire. That is,
it can be very hard to prove a feature works everytime
and in every case. There are bugs that don't show up
unless you know what to look for, and sometimes these
are outed by serendipity: a feature is run that exposes
a bug that has nothing to do with the feature being
tested.
So planning ahead even in hairy detail is jut
very expensive and possibly, not exhaustive. Consider a
simple case of a recordset that populates a treeview
and fails to Treeset.Moveprevious at the beginning
of the leaf level (to pick up the first guy). So it
is a minor error. But without either visually inspecting
it, it isn't invalid. Just lost. Someone will find it but
how long that takes depends on what they are looking for.
Yes, that is what test datasets are for. Are you certain
the web service vendor did this? How long is the FAT and
what did you sign afterwards with respect to liquidated
damages? Still think this is frictionless or that
apps can depend on metadata to discover and automagically
hook up? Reliability is the number one problem.
One assumes that web services like any widely used app
benefits from having lots of users who out bugs. So
does REST, but the difference is, REST gets the whole
Web working on the problem and a web service only has
to scale to its customer base. Caveat emptor.
It may not be good to be the first penguin into the
water. Cu cu ca choo.
len
