4/27/2002 10:28:36 AM, Bill de hÓra <> wrote:
>
>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 you?re 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 think that's a very good point. Good abstractions are *hard*
to get right, partly because there's a tension between the needs of the
user ("make it easy for me to do with familiar tools"), the
architect ("make it reliable, scalable, evolveable, ..."), the
vendor ("sell it profitably and leverage the sale for repeat
business"), etc. As much as I appreciate having grungy details
I don't care about encapsulated away, I just don't think it's clear
yet what is a powerful abstraction, and what is an implementation
detail. I hope that there are enough people out there who can
"have at the XML/Infoset directly" to stave off standardization on
abstract APIs until we understand what details need to be exposed
to whom, and which abstractions work best for which needs.
