When Web Services Don't Make Sense

From: John Flynn (jflynn@bbn.com)
Date: 05/02/02

  • Next message: simon.2.thompson@bt.com: "RE: 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 Building
    XML Web Services <http://www.learnxmlws.com/book/default.aspx>
    (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/02/02 EDT