Welcome!

SOA & WOA Authors: Jeremy Geelan, Aditya Banerjee, Chris Wiborg, Carmen Gonzalez, Udayan Banerjee

Related Topics: SOA & WOA

SOA & WOA: Article

Where HTTP Fails SOAP

Alternative choices for situations when HTTP does not scale sufficiently for enterprise Web service deployments
By Frank Lynch, Mark Fynes
Article Rating:
October 23, 2005 12:45 PM EDT
Reads:
 44,741

Conclusion
SOAP/HTTP has one major thing going for it: its ubiquity and widespread support. While HTTP does a great job at serving Web pages, it is not an enterprise-strength protocol, and does not scale well in the back office. Clearly an open, interoperable, standards-based, enterprise-strength protocol is needed here. The most widely deployed protocol that fulfills all of these criteria today is the OMG's IIOP.

One thing an ESB allows you to do that a Web services toolkit cannot is adopt an SOA using SOAP without sacrificing the qualities of service required in the back office. In other words, an ESB allows you to apply SOAP where it fits best without forcing you to also apply it to problems for which it's a poor solution. An ESB should allow the developer to preserve the loose coupling that SOAP affords us, while taking advantage of the qualities of service demanded in the back office that are available with IIOP.

References

Published October 23, 2005 – Reads 44,741
Copyright © 2005 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

More Stories By Frank Lynch

Frank Lynch is a principal services engineer with Iona Technologies. He holds B.Sc. in applied computing from Waterford Institute of Technology, Ireland. Frank has 10 years of experience in the software industry, primarily working with distributed systems technologies. He has worked in a wide range of roles including product development, professional services/consulting, sales, and support. He has advised some of the world's largest financial services and telecommunications firms, and spends considerable time with Global 2000 companies as a distributed systems technologist.

More Stories By Mark Fynes

Mark Fynes is a senior systems engineer at Iona Technologies. Previously he had been a freelance consultant, carrying out a number of roles including development training and implementation of Web-based staff-management systems. Mark secured his Bachelors degrees in both Arts and Engineering from Trinity College Dublin, Ireland with honors. He then joined the Computer Architecture Group at TCD and secured a research-based Masters in Science. During his time as a post-graduate researcher at TCD, he participated in an ESPRIT-funded project to provide video-on-demand with the hotel industry as an early adopter, focusing his work on remote systems management.

Comments (4) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
n d 08/21/06 05:22:31 PM EDT

Web services allow for the delivery of SOAP messages over any protocol. A common misconception is that all SOAP messages must be transmitted over HTTP. While that approach is useful in many cases, there are situations where it makes sense to use alternatives. This paper investigates situations where HTTP does not scale sufficiently for enterprise Web service deployments and looks at available alternatives.
Alysson Oliveira 11/11/05 09:22:55 PM EST

Hi,

I´d like to know how to do reference this article.
Volume: 5, Issue: 7 Page number:?????

Thanks

Alysson
A Non-Mouse 08/08/05 04:44:12 PM EDT

HTTP requests don't have to wait for an entire process to be completed before recieving a response. A "202 Accepted" and "Location" header can indicate to the client that the process is in a queue (or currently busy) and where the completed request will be found. Alternatively, a SMTP header could be borrowed (?) and a client could request with a "Reply-To" header for where the completed request should be sent (Reply-To being a URL endpoint, perhaps).

This isn't really something web browsers could leverage obviously but then back-end processing doesn't have to be in complete synchronization with what the user is seeing anyway.
Peter Saint-Andre 08/08/05 12:58:11 PM EDT

And let's not forget about the binding of SOAP to XMPP: http://www.jabber.org/jeps/jep-0072.html