July 17, 2000
|
|
Solution Series:
SOAP Lets Web Apps Talk Across Firewalls
By Stuart J. Johnston
eb app developers may add one more acronym to their Internet lexicon: Soap. The Simple Object Access Protocol is a toolkit that can invoke interprocess communication such as remote procedure calls through an Internet firewall. RPCs let one program ask another to execute a task over the Internet, an intranet or an extranet. And unlike so-called synchronous protocols such as Corba and Microsoft's COM and DCOM, Soap is loosely coupled so it can communicate with any application.But Soap is best for lightweight applications and exchanging information in a decentralized, distributed environment, according to the World Wide Web Consortium (W3C). It's not optimized for industrial-strength applications that require tightly coupled, synchronous, ultra-secure processing among apps. Based on the Extensible Markup Language, Soap consists of three parts: an envelope that defines a framework for describing what's in a message and how to process it, encoding rules for expressing application-defined data types, and a convention for representing RPCs and responses.
For the first time, a developer can write a program on one platform that can call a remote program running on a different platform behind an Internet firewall, ask it to do something, and return the results to the initiating program. The two platforms don't have to be the same as long as the program at the other end of the wire has a Soap "listener" written in any language. From a programmer's point of view, it will be simpler to integrate applications running on different operating systems over the Internet. "When you start talking about software as a service on the Web, it's no longer homogenous" on both ends of a communication, says John Montgomery, a group product manager in Microsoft's developer division. "Software as a service means you start dealing with a really heterogeneous environment--with Unix and Windows systems--and integrating them together to build higher-level applications," he says.

Soap was proposed last September by Microsoft, UserLand Software, and DevelopMentor, but has garnered support from Ariba, Commerce One, Compaq, Hewlett-Packard, IBM, Iona Technologies, Lotus Development, and SAP. While Soap plays a large role in Microsoft.Net, a follow-on specification this spring was endorsed and modified by IBM. Now called Soap 1.1, it also has won support from Sun Microsystems.
In May, IBM contributed its Soap Toolkit to the Apache Software Foundation, which oversees the Apache open-source Web server. Microsoft made a Soap implementation available for its Visual Studio 6.0 development suite last month and says support will be built into Visual Studio 7, due out in beta this fall.
Soap 1.1 was submitted to the W3C, but the committee hasn't yet decided whether to make it a standard--though its creators are confident it will become one.
Soap will let companies quickly build distributed Web apps using services--or other programs--running on diverse Web sites. At the recent Microsoft.Net announcement officials showed a patient giving a doctor in a city he was visiting access to his medical records via a Web application and charging it to his health-care provider. Soap-driven transactions such as this one let Web apps in different cities interact on an ad hoc basis. Developers didn't have to design code specifically to let those systems interact. Instead, Soap let the user's health-care provider's system communicate securely with the applications.
Although Soap will be fine for so-called lightweight programmatic interactions such as a quick look up of health-care information, for industrial-strength app--such as securities transactions--developers will continue to use homogenous protocols such as Corba, COM, DCOM, or a more industrial-strength protocol under design, called ebXML.
Moreover, since Soap uses the same entry point into corporate firewalls as HTTP--called port 80--its messages pass easily through firewalls, yet security concerns remain. "Soap will be popular," says Anne Thomas Manes, director of business strategy, software products, and platforms at Sun. But it leaves open a huge security hole, she says. By using the same port as HTTP, most firewalls don't block it and a malicious employee could easily cause sabotage. Manes says Soap could be vulnerable to virus attacks similar to Melissa or ILOVEYOU that used Visual Basic for Applications to penetrate users' systems.
Other analysts are less worried and say security-savvy developers will implement Secure Sockets Layer or even Kerberos-based security in any distributed application to block that kind of malicious attack.
The specification may need some cleaning up, but there's a good chance users will have Soap in their application future.
Return to main story, "XML Drives Development."
Return to the Solution Series homepage
Back to This Week's Issue
Send Us Your Feedback
Top of the Page
UC Berkeley seeking Helpdesk Team Lead in Berkeley, CA
Hebrew SeniorLife seeking Telecommunication Analyst in Boston, MA
Novant Health seeking Chief Technology Officer in Charlotte, NC
ISES, Inc. seeking SAS Oracle Clinical Developer in Clinton, NJ
Lowe's seeking Network Engineer II in Mooresville, NC
For more great jobs, career-related news, features and services, please visit our Career Center.