Opinion: Service-oriented computing is an attitude, not just an architecture.Were past the stage of ITs evolution where people come to a
computer in the manner that they pick up a power tool, having a
specific task in mind and probably some training in how to do it. The
fastest-growing model of computing today, with no end to the trend in
sight, is one of systems that seek to recognize a situation or an
opportunity to be of service—whether were talking about a
process-to-human or a process-to-process relationship.
When this service-based model meets the real-world environment,
system builders will find that their task is much more complicated than
it seems when theyre crafting a scripted technology demonstration.
A vivid example of the challenge is in voice-synthesis
notifications for active environments—for example, those that try to assist the
driver of a car. This merely begins with the challenge of meeting
rising expectations for a natural-sounding voice that correctly
pronounces same-spelled words: for example, "close" ("you are close to
an object behind you") and "close" ("please close the trunk lid before
driving"). Navigation systems must also deal with database entries that
were meant to be read by a person, not spoken by a machine: A
now-ancient Digital Equipment Corp. demo showed an algorithm correctly
inferring from context to pronounce the text string "St. James St." as
"Saint James Street."
Problems like the ones that Ive just described can be solved by
experts in speech synthesis who dont know anything about the task
environment of driving. Other domains also pose distinctive technical
challenges that may seem to represent the crucial problems to be solved—but it may turn out that those milestones, once reached, arent
enough to yield a useful result.
Additional perspective is needed to prioritize tasks: in the automotive case, for example, so that warnings about what might be a child playing behind a car thats in reverse are issued more immediately and with greater urgency than warnings of traffic
problems or routine service reminders.
Allocation of processor cycles, sensor network bandwidth and "air
time" on the driver cockpit audio channel all depend on task knowledge
and the provision of scalable infrastructure to provide any needed "mother ship"
support.
Developers crafting service-oriented architectures for enterprise IT
operations should also have this kind of perspective. They need to
maintain a big picture of the resources that theyre allocating
themselves and also the resources that theyre consuming. They need to
consider the manner in which services should best be prioritized by
urgency, and enabled to communicate with each other and with the user
based on task-related models of what will happen if a request is not fulfilled or a piece of
information is not delivered.
Its one thing to build a system thats impressive when its working
as planned. Its quite another to build one thats not ridiculous, or
worse, when its best-case assumptions arent valid.
Tell me what youd call good service at
peter_coffee@ziffdavis.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
Application Development 
