Re: [Highly OT] Webservices are NOT distributed objects

"Gerald Brose" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Right, there are always other ways to do things, and it can
> be done without XML. However, XML-based message formats are
> a "standard" solution with both tools and industry consortium
> specifications available. They are thus the first choice for
> most integration-related settings that need to achieve the
> technical goal while retaining some protection of investments.

Hmmm... Now, I seem to have heard these words once or twice
before. About DCE, about DCOM, about Java, about CORBA.
Personally, I think I'll sit back and wait a few years. After that,
I might just repost your quote about web services with a bit of
a smirk :-)

> For an in-house problem with lots of capable protocol designers
> available, you may come up with a technically superior solution.
> ;-)

Correct ;-)  And to use the solution, I need to know nothing about
protocols.

> > The problem with this idea of loose
> > coupling is that the sender no longer has any idea of how much of a
> > message the receiver will actually be able to process.
>
> In a truly loosely coupled setting, the sender should not care at all
> who the receiver is, what he does and how much he understands. Let's
> not think of RPCs but of messaging systems.

Hmmm... I think I have a problem with this. If the sender doesn't care
about who the receiver is, why is the sender bothering to talk? True, there
are cases where this is the case, such are radio, TV, ticker tape news, etc.
But these aren't very interesting to e-commerce (or other rich application
choreographies (thanks for the term Steve! ;-)  For those, the sender
does care very much whether the receiver has understood the message
and, quite often, does care whether the message was understood in toto.

>
> > It provides
> > complete type safety at the same time as full extensibility and versioning,
> > and it does it all without breaking compatibility with older-version
clients
> > and servers.
>
> But complete type safety is not always required or even desirable.
> To give an analogy, the whole point of having scripting languages,
> is that they are not statically type safe!

I'm a bit stumped by the comment -- I honestly don't know whether that
is the whole point of scripting languages. It seems to me though that there
are other points, such as no need to compile first, that scripts make it easy
to knock up something quickly, and that scripting languages tend to be
used for small software of limited complexity. (As a rule, people don't
write large and complex systems using Perl -- I suspect that the benefits
of static type safety are at least one reason for that.)

> > And, besides, XML is of no help if I need to make an
> > incompatible change to something: I can add stuff, but I can't change
> > stuff.
>
> You can always change the contents of an untype, any-style message
> element if all parties that need to process that element agree
> on that change.

Ah, yes. But that's not loosely coupled then anymore, is it? If all parties
have to agree anyway, I might as well enjoy the safety of static type
checking instead of learning about any problems at run time.

> And in many case that may be exactly what you want.
> A type-safe solution requires a considerable modelling effort
> beforehand, with wise designers making the right design choices
> and foreseeing all those modifications that will later be required.

Huh? So, without a type-safe solution (aka web services and XML), I don't
need to make a considerable modelling effort beforehand, and I don't
need a wise designer making the right design choices? If so, God help
us all in this future e-commerce world...

> Versioning will always require effort and discipline, with any
> technical tool.

Not all that much discipline and effort at all. With interface aggregation,
adding a new version to existing deployed distributed systems is trivial,
type safe, non-intrusive, and pretty much a no-brainer. The problem
in the past seems to have been that people just never designed the right
mechanism for versioning into middleware platforms, and suddenly the
problem became hard to solve, when it needn't be so.

Cheers,

Michi.

--
Michi Henning              Ph: +61 4 1118-2700
ZeroC, Inc.                http://www.zeroc.com