[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: RE: SOAP-RPC and REST and security

• To: 'Mike Champion' <mc@x...>, xml-dev@l..., Joshua Allen <joshuaa@m...>
• Subject: RE: RE: SOAP-RPC and REST and security
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Wed, 20 Feb 2002 08:41:49 -0600

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@x...]

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.

• Prev by Date: Re: Re: [namespaceDocument-8] 14 Theses
• Next by Date: RE: Re: [namespaceDocument-8] 14 Theses
• Previous by thread: RE: SOAP-RPC and REST and security
• Next by thread: RE: SOAP-RPC and REST and security
• Index(es):
  • Date
  • Thread