[
Lists Home |
Date Index |
Thread Index
]
Do you really think the average office worker knows what the
<!DOCTYPE at the top of an HTML file is for? I don't. OTOH,
they don't code them. They make others do it for them.
1. The average office worker still hides behind FrontPage and it's ilk.
Having spent a lot of time a week ago rebuilding several FP enabled
pages and closing security holes (ODBC strings in .htms?????), I can
say it wasn't too hard to do it right the first time, but these folks
were career-oriented, got what they wanted, moved on to bigger and
better, and left a mess behind. One reason I dig into these issues
is a real-world awareness that the mess lands on my desk.
2. It is interesting to take a look at the MS pages on web services
with their animation of how Visual Studio, VBA etc., will support
discovery and integration. It glosses over the right to use these
services, how to pay for them, the contract bits, but it looks about
like what a VBA programmer is used to. Let's be honest: it isn't
just programmers (the pure, the mighty, the powerful, the knowledgeable)
vs everyone else (the slothful, the ignorant, the spoiled, the needy). Most
web programming above the level of core technology is object scripting
and that includes HTML (particularly HTML). The model the MS pages
show is the model many scripters know.
I have to think that is a key reason: ease of integration into VBA and
the toolkits that support it and languages like it (Javascript).
Point: it would be nice to get this right. Legacy builds fast and
there are dimensions of that that extend into the organization, the
habits of the humans, and the performance of both. I don't like
to clean up the messes of the politically correct or the wild-eyed
individuals. (somewhere between objectivism and vedantic beliefs,
there must be a middle ground better than "do the right things for
the right reasons", but I'm danged if I know what that is).
Scalability worries me. Treating a WAN like a LAN worries me. Getting
the scripters to not code too close the process of an individual
desktop worries me. On the other hand, reliance on a global namespace
has its perils too. The issue today is edge system integration; not
understanding the philosophy of URI. That is corrupt on the face of
it; it conveniently "webs" but the namespace as URI is corrosive.
The Web Way doesn't worry me. The Web doesn't exist. Parts and
assemblies exist. After that, what works had better work for
long enough to get ROI. My intuition is that that is what the
WSIO is about: code on the loading docks.
len
From: Mike Champion [mailto:mc@xegesis.org]
2/18/2002 10:03:40 AM, "Bullard, Claude L (Len)" <clbullar@ingr.com> wrote:
>So Why Traditional RPC? Why Web Services per UDDI/WSDL/SOAP?
I didn't think there was much dispute -- this is the programming way,
the CORBA and DCOM way, to access remote applications. It works
well on LANs, so there's a solid base of experience to draw on that
you can hide the network behind an RPC. It makes a lot of intuitive
sense -- SOAP-RPC as a neutral wire format, WSDL as a neutral IDL,
UDDI as a directory service. It has a plausible business model:
vendors compete on ease of use and quality of implementation rather
than on basic protocols.
I can agree with the REST people that it's not "the Web way",
that it forces a reinvention of things that the Web already
supplies, and that it may not scale to the web as it really exists...
but I understand why the Web Services people chose the "programming
way" and treat the Web as simply a giant LAN. We shall see if
it works out that way.
I'll predict that both win: Traditional RPC really is the easiest
way for programmers, and will work well enough behind firewalls
and between established partners and in arenas where user simplicity
matters more than system reliability (e.g., for Userland's typical
customer, AFAIK). But now matter how fast the Internet that we know
today improves latency, reliability, security, etc., it will
be extended geographically and to smaller
and more mobile devices,continually opening more niches where the REST
paradigm shines.
The only "REST rules, RPC drools" scenario I can imagine, i.e. that
would make the WS tool vendors' inital focus on RPC ill-considered,
is if the non-programmers somehow grok REST big time
and find it an easy migration path from what they do now to
the Wonderful World of Web Services. It's more likely than
assuming they will learn to think like a programmer, no?
Will non-programmers build and use web services? Maybe not,
but who would have thought 10 years ago that the average student,
office worker, etc. would have a basic knowledge of a markup
langugage (HTML) today?
|
