A few times on this blog now we have kind of waltzed around these questions: When are Web services a good fit? Where not?

In a recent article, writer Colleen Frye asked just such questions of Forrester analyst John Rymer. Like others, he admits that,  where performance is a key issue, Web services may not be the best option.

For loosely coupled application or component integration, where the interactions can be accomplished through messages rather than direct API calls, Web services may fit the bill, Rymer said. However, for tightly coupled integration or in-process integration, Rymer suggests other options like bridging middleware such as integration servers or Enterprise System Buses [ESBs]; extended J2EE platforms that implement .NET features; and language integration technologies.

The verbosity or latency of Web services - call it what you will - was there at the outset. One is careful to place too much emphasis on that, since hardware historically has had a way of catching up. But you’d antcipate that Web services would be largely frozen out of intense applications such as electronic trading today. How far does that boundary extend?

In a Forrester report last year, Rymer wrote that Web services technologies will eventually become more broadly useful. Binary Web services formats continue to be discussed as an option for in-process integration, but one wonders if they are much further along this year than last. What do you think?

Web services no interop cure - TheServerSide.NET

This entry was posted on Friday, February 2nd, 2007 at 1:18 pm and is filed under Messaging, Interoperability, XML/Web services, Distributed objects. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.