From: simon.2.thompson@bt.com
Date: 05/03/02
I wonder how people on this list feel about the REST vs RPC debate? I have
read some articles on the web, but they seem to be polemics, and
interesting, but not what I want to base a software development policy on!
REST systems seem to be based on the idea that data should be made available
as a URI, and clients should manipulate that as they need to.
RPC seems to take a functional approach - SOAP or XML-RPC is used to call a
method to effect some data transforms and obtain a result.
I have two questions:
What applications require the RPC approach? Perhaps systems that need an
event model?
How does one handle side effects in RPC models - how can we describe
them in a service description?
Cheers,
Si.
-----Original Message-----
From: John Flynn [mailto:jflynn@bbn.com]
Sent: 02 May 2002 18:37
To: daml-services
Subject: When Web Services Don't Make Sense
When Web Services Don't Make Sense
Don't assume Web services will solve every problem you'll ever face.
by Yasser Shohoud
Posted April 29, 2002
According to IDC, the hype and noise surrounding Web services will reach
deafening levels in 2002. Although IDC sees Web services as valuable
technology for application integration and B2B ecommerce, it forecasts the
hype <http://www.computerworld.com/storyba/0,4125,NAV47_STO67084,00.html>
to increase exponentially in 2002.
To counteract some of this hype, I'll point out two specific scenarios where
Web services do not make sense. Unfortunately, I already see many developers
implementing Web services in these scenarios, indicating that the hype got
to them. It is clear that Web services offer the most benefit in cases where
you want interoperability and/or remoting over the public Internet. That
said, note these scenarios where you don't benefit from using Web services.
Single-Machine Applications
There are still many desktop applications for business and personal use.
Some of those applications might need to communicate with others running on
the same machine. In this case, it is almost always better to use a native
API rather than a Web service. COM is effective in this scenario because it
is fast and requires relatively little overhead. The same applies to server
applications running on the same server: Use COM or some other native API to
invoke one application from the other. While it's possible to use a Web
service in this scenario, it is considered suboptimal and does not buy you
anything.
Homogenous Applications on a LAN
In many cases, you'll have applications developed using Visual Basic and/or
Visual C++ and COM and running on Windows platforms on the same Local Area
Network (LAN). For example, you might have two server applications wanting
to communicate with each other or, more commonly, a Win32 or Windows Forms
client that wants to communicate with its server counterpart on the same
LAN. It's much more efficient for two such applications to communicate using
DCOM rather than SOAP/HTTP.
Similarly, if you have .NET applications that need to communicate with one
another over a LAN, you can use .NET remoting. Interestingly, .NET remoting
offers the option of using SOAP over HTTP, essentially acting as a Web
service. But .NET remoting can also run directly over TCP and can utilize a
binary format for the RPC calls which is supposedly more efficient than
using SOAP. Overall, .NET remoting focuses on faithfully reproducing the
remote object's interface whereas Web service focus on faithfully generating
the agreed-upon SOAP messages. Again, you would not use Web services in a
scenario where you had other viable options that are more efficient or make
more sense from an application architecture viewpoint.
About the Author
Yasser Shohoud is creator of LearnXmlWS.COM, a site dedicated to Web
Services resources. Yasser specializes in developing and delivering XML Web
Services training to professional developers. A Web Services expert, Yasser
speaks at several industry conferences and is writing a book titled
<http://www.learnxmlws.com/book/default.aspx> Building XML Web Services
(Addison-Wesley). Reach Yasser at www.LearnXmlws.com
<http://www.LearnXmlws.com> .
John Flynn
(703) 284-4612
DAML Integration and Transition PM
BBN Technologies
This archive was generated by hypermail 2.1.4 : 05/03/02 EDT