[
Lists Home |
Date Index |
Thread Index
]
I just sat down with a guy who said that and
he told me he meant that exchanges based on
standard vocabularies is "tight coupling".
Now it makes better sense: terminology
confusion. Nevermind.
So let's rolllllllll back.
We don't need to debate if a message is a document
or doc vs data-centric. We may want to inquire
into the costs of how the size of the message/doc
affects the cost of negotiation and maintaining
fidelity. We may want to inquire into the
performance efficiencies of lots of small
messages vs larger ones and the time between
transactions. We know (as you point out)
that tight interfaces are a pain to manage.
Yet on the private IP networks, two way stateful
systems are a reality and there are protocols
designed to let one operate in stateful or
stateless mode (e.g., voice apps).
Anyone who thinks we can magically hook up the
world's businesses and skip the step of
creating the vocabularies missed Markup 101.
On the other hand, I'm still not sure the
interface model changes that requirement.
I can see it working either way. But that is a
business app. It is intelligence, not
command and control in real time. For desktop
level C2, one really might want RPC and a
more tightly coupled system.
What do you think?
The aliens are busy fighting one another and
can't stop to bother with us or
are out there making love and wondering why
we haven't joined them. Either way, it's
their party so far.
len
-----Original Message-----
From: Mike Champion [mailto:mc@xegesis.org]
2/26/2002 3:01:31 PM, "Bullard, Claude L (Len)" <clbullar@ingr.com> wrote:
> I've got serious guys here who say tightly coupled
> web services are the way to go.
I'd be awfully curious to know the reasoning behind that.
I thought that "tight coupling" was a famous design
anti-pattern, more or less antithetical to "modularity."
Web services would seem to be that LAST place one
would want to use tight coupling .
I can understand why people *want* to extend conventional
programming paradigms to the internet. It's not
obvious how far that will take us ... certainly to the
LAN, probably to the intranet ... but Don Box's article
makes it clear that even SOAP-RPC's most fervent advocates
acknowledge that it hits the wall when we try to take
that to the Web. "Fix HTTP to be RPC-friendly" is
a perfectly logical response (although "fix the messaging
model to be HTTP-friendly" seems a bit more practical to
me). But I can't understand why someone would think that
"tightly coupled web services are the way to go" UNTIL
the standard internet hardware and software infrastructure
make this feasible.
|
