[
Lists Home |
Date Index |
Thread Index
]
If the SOAP message is just data packed up
to send to an interface that submits the
request to a facade over a business logic
layer to get data, pack up a report and
send it back, there is no difference.
I don't think web services get troublesome
because of the interface styles. That is
a matter of practice. I think they get
hard precisely because it is difficult to
orchestrate non-trivial business processes
without human intervention.
How many of you in this thread actually
do contract work, and by that, I mean
specifically, RFP analysis? I've seen
the discussion on the REST list for what
some would consider a "complex business
process", and they don't touch the really
complex processes that occur on the desk
and account for hierarchical management.
If one reads the papers on orchestration,
one notes that they cover concepts of
routing, but specifically and explicitly
avoid hierarchical decision processes.
len
-----Original Message-----
From: Mike Champion [mailto:mc@xegesis.org]
I keep coming back to the same basic opinion: SOAP-RPC and the
tools that support it are great for building distributed applications
within an enterprise, behind a firewall, where people basically trust
each other (and violations can be traced and punished), and where
reliability and latency are either not a problem (or can be handled
in a straightforward manner, such as with the extra step in VS.NET
that Francis Norton mentioned). In these situations, you can indeed
"hide the network behind the tools." But when you can't hide the
network because of lack of bandwidth, latency, trust, reliable
connectivity and so on, or you don't want to hide the network for
some other reason, REST looks like an awfully good design pattern.
|
