Kevin Werbach on Web Services in Release 1.0:
Web services are software objects that can be assembled over the
Internet using standard protocols to perform functions or execute
business processes. They fill in the white space between applications,
systems and companies with simple messaging, description,
discovery and management protocols and other mechanisms.
Web services seek to realize a widely shared vision for the future of
software: distributed, componentized, standardized, open, scalable,
and Internet-centric.In one way or another, [various] companies hope
to do for applications what the Web did for publishing: reduce costs,
catalyze innovation and dramatically lower the bar for anyone to
create new offerings Instead of mostly static links between data or
content, Web services promise active links (transactions) between
functions.
Beyond the near-term integration benefits, promoters of Web services
envision a world where every company connects to every other, and
systems are assembled and optimized on the fly to meet dynamic
business requirements. Web services are a specific set of technologies
and standards to implement this vision, roughly corresponding to the
“application syndication” category in our earlier framework.
Adam Bosworth of Crossgain (acquired recently by BEA) in an interview to XML Magazine:
What we’re really talking about is the next generation of n-tier
architecture, and it turns out that the next generation of n-tier
architecture needs to be one that can be distributed such that the
Internet is the computer, not just the network. The idea behind any
n-tier architecture is that a program can call another program, or an
application can call another application-in short, that there are
various pieces that work together, but they’re built by different
groups.
For Web services to really go to the next step, it’s going to be very
important that people not repeat the mistake that was made with
objects and reusability, where they didn’t write down this
stuff. Instead, people write down very clearly what the contract is
with the service-where the contract isn’t just, here’s the message you
can send me, here are the messages I can send you back, and here’s the
amount of time that you should respond to me within, and so on. It
should also include, look, here’s the sequence of things that has to
occur-that you’re supposed to do them in-and, by definition, anything
that wasn’t spelled out can be done in any order-and that’s also
missing today.We’ve still got a long ways to go before we have what a
Web services architecture needs for truly having the same kind of
interoperability that you get today between, say, a browser and Web
sites-where any app can go up to any other app and reuse it as a
service, and it’s easy and it’s reliable and when they change
implementation, they don’t break you.
