> If Fowler's first rule of distributed computing is "don't
> distribute", then the corollary to that is to make your remote calls
> as coarse as possible.
That may be an unfortunate consequence of the languages and tools we
use. An alternative supported by languages like Erlang is "distribute
everything", then the corollary to that is to make your message sends
as fine-grained as possible.
> In most cases, if you don't know if the service you want is local or
> remote (at least from an invocation point of view), you're likely to
> make the wrong design decisions. You may choose to deploy a set of
> services so that the actual communication is via in-memory messaging
> for efficiency/scalability considerations, but that should not be
> part of the decisions you make when you design the code that invokes
> it.
In Erlang nearly everything is an asynchronous message send. Spawning
processes in the same address space looks the same as spawning
processes remotely. Neither local nor remote processes share memory,
even when in the same address space. Then locating certain processes
close to each other, even in the same address space becomes an
important decision.
The more remote processes collaborate over more coarse messages, but
this is not necessary, and a key feature is that the programming model
is uniform for all message sends. When we program distributed systems
in Java or Ruby we have to make unnecessary disinctions about these
things. We can minimize the impact, but the degenerate form of that is
a reliance on code generators that consume WSDLs, etc.
Quoting someone out of context: "How quaint!" Erlang represents to me
a true service-oriented approach. These others a mere pretenders, with
a few reasonable approximations.
-Patrick
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
