-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike,
> -----Original Message-----
> From: Mike Champion [mailto:]
>
> In OOP-ese, APIs present an abstraction of the underlying
> process or protocol, allowing the "bits on the wire" (or
> machine instructions, or whatever) to be encapsulated, thus
> the bits behind the abstraction can be modified, replaced,
> ported, etc. with minimal impact on the application. There
> are lots of C programs out there that are carefully written
> to standard APIs (or libraries that abstract away the
> differences among standards) that run on everything from
> handhelds to mainframes. That obviously wouldn't be possible
> if people wrote to the "bits on the wire". Also, it works if
> the "network/protocol isn't really there", and the API just
> keeps people in the state/transitions that actually work.
>
> Of course there's a dark side to this, ESPECIALLY when we're
> talking about XML, which was supposed to be simple and
> standardized enough to provide a consistent set of bits on
> the wire that could be
> programmed to on any platform: if you can't stand a little
> "pain" and write to the interoperable standards, you won't get
> the platform/vendor/language-neutrality "gain" that attracted
> you
> to XML and the Web in the first place.
>
> This is a common theme in the web services debate. Those who
> are building the higher layer APIs say that they are
> leveraging the power
> of HTTP, URIs, and XML and simply providing convenient
> abstractions that ordinary programmers can work with.
What I've seen of webservice APIs (particularly SOAP) is that
they're insufficiently abstract. Some of the JAX* stuff is like
that, neither here not there. If youre going to abstract this
stuff for developers benefit then you want to model services and
processes (maybe messaging in the SOAP context). Otherwise let's
have at the XML/Infoset directly. Plus it's not /that/ hard to
enable more views. In the XML case take an Infoset as your
model/event stream and generate increasingly abstract views on that
model/stream, the developer decides which level to plug into. Some
GUI frameworks do this by layering event semantics; SAX/DOM
completely enable it afaict.
I'm thinking of something like POSIX or even a VM for network
services, where the wire bindings are bit more scoped out than
today (it's interesting you mentioned C). In that sense, one
doesn't need SOAP or WSDL APIs, one needs x-platform services SPIs.
Interop's only so useful; if you can't swap out the platform,
you're owned. Servlets/JSP are a fine example; code ports easily.
> I think the lesson here is "build your own abstractions and
> APIs on top of the real, basic, interoperable standards."
> Don't wait for some industry
> consortium or inter-agency task force to build
> one-size-fits-all abstractions; that won't happen, or if it
> does the "standards" will be so vague and broad that they
> don't give real interop anyway. And be especially careful
> not to become dependent on the APIs and abstractions offered
> by those who may be offering convenience at the price of your
> soul.
On the other hand, if I turn on a dime to use open protocols in the
name of portability, interoperability and simplicity, and later on
allow vendors to tie me back in via arbitrary calls and opaque
tools, I and my architect/consultant/employer are frankly, suckers.
Bill de hÓra
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPMq1j+aWiFwg2CH4EQJMoACdH7A5pJptvs1vj2cdLzksiLryBukAoOA0
HJfKWdVT8NumSQYALpp+y6q1
=MxFL
-----END PGP SIGNATURE-----
