"SOAP is a protocol specification for invoking methods on servers, services, components and objects. SOAP codifies the existing practice of using XML and HTTP as a method invocation mechanism. The SOAP specification mandates a small number of HTTP headers that facilitate firewall/proxy filtering. The SOAP specification also mandates an XML vocabulary that is used for representing method parameters, return values, and exceptions." [DevelopMentor]
"SOAP is the Simple Object Access Protocol, a way to create widely distributed, complex computing environments that run over the Internet using existing Internet infrastructure. SOAP is about applications communicating directly with each other over the Internet in a very rich way." [MS]
[In the context of the Microsoft Windows DNA 2000 solution]: "The key enabler for Microsoft's vision of integrated, programmable Web services is XML. Through the exchange of XML messages, services can easily describe their capabilities and allow any other service, application or device on the Internet to easily invoke those capabilities. To help realize that vision, Microsoft today is submitting to the Internet Engineering Task Force (IETF) an Internet draft specification for the Simple Object Access Protocol (SOAP), an XML-based mechanism that bridges different object models over the Internet and provides an open mechanism for Web services to communicate with one another." [1999-09-13]
"To help developers build Web services and link heterogeneous components over the Internet, Microsoft worked with industry experts to create the Simple Object Access Protocol. SOAP provides an open, extensible way for applications to communicate using XML-based messages over the Web, regardless of what operating system, object model or language particular applications may use. SOAP facilitates universal communication by defining a simple, extensible message format in standard XML and thereby providing a way to send that XML message over HTTP. Microsoft is soliciting industry feedback on version 0.9 of the SOAP specification. . ." [MS announcement 1999-09-13]"
[May 08, 2000] The W3C has acknowledged receipt of a submission request including the Simple Object Access Protocol (SOAP) 1.1. The submission includes the text of the SOAP 1.1 specification along with a SOAP Envelope schema and a SOAP Encoding schema. Reference: W3C Note 08-May-2000. By: Don Box (DevelopMentor), David Ehnebuske (IBM), Gopal Kakivaya (Microsoft), Andrew Layman (Microsoft), Noah Mendelsohn (Lotus Development Corp.), Henrik Frystyk Nielsen (Microsoft), Satish Thatte (Microsoft), and Dave Winer (UserLand Software, Inc.). The submission is from Ariba, Inc., Commerce One, Inc., Compaq Computer Corporation, DevelopMentor, Inc., Hewlett Packard Company, International Business Machines Corporation, IONA Technologies, Lotus Development Corporation, Microsoft Corporation, SAP AG, and UserLand Software Inc. The co-submitters of the specification assert that they "believe strongly in the need for standardized protocols to support interoperable interactions with remote Web-based services. Although there are a number of similar efforts underway, [they] feel the W3C is well suited to co-ordinate work in this area, and propose the formation of a new working group within the existing XML Activity group to continue the evolution of this proposal." Document abstract: "SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework." The W3C staff comment on the NOTE presents the W3C's provisional disposition. It says, in part: "SOAP is one of the existing protocols in the domain of XML based protocols. However its object serialization scheme needs to be more explicit, as in the architectural model of HTTP-NG, where inheritance or method description issues were addressed. Also we think that security considerations should have a central place in such a design, as it is always more difficult, if not impossible, to add security afterwards. W3C is currently hosting a mailing list to discuss XML protocol requirements and compare several current protocols... it encourages participants to contribute requirements and use cases that will help scope XML protocol discussions. W3C solicits input regarding what its role should be in the development of this area of work."
References:
Simple Object Access Protocol (SOAP) 1.1. W3C Note 08-May-2000. [cache]
SOAP Version 1.2. See the announcement.
Apache SOAP - "Apache SOAP ("Simple Object Access Protocol") is an implementation of the SOAP submission to W3C. It is based on, and supersedes, the IBM SOAP4J implementation.
[April 26, 2000] SOAP v1.1 [from IBM's Web site]
SOAP References and Resources - From DevelopMentor
SOAP Workshop. "A VBXML.COM forum for articles, code samples, and utilities relating to SOAP, the Simple Object Access Protocol, and Web Services in general."
SoapRPC.com - SOAP Resource Center. "SoapRPC.com is a resource site for the Simple Object Access Protocol (SOAP) and related protocols. We have listings of technical articles, protocol specification, software, tutorials, sample code and a lot more."
[July 22, 2003] "SOAP Message Transmission Optimization Mechanism." Edited by Noah Mendelsohn (IBM), Mark Nottingham (BEA), and Hervi Ruellan (Canon). W3C Working Draft 21-July-2003. Latest version URL: http://www.w3.org/TR/soap12-mtom. ['The W3C XML Protocol Working Group has released the first public Working Draft of the SOAP Message Transmission Optimization Mechanism. Inspired by PASWA and enhancing the SOAP HTTP Binding, this technical report presents a mechanism for improving SOAP performance in the abstract and in a concrete implementation.'] "The first part of this document ('Abstract Transmission Optimization Feature') describes an abstract feature for optimizing the transmission and/or wire format of a SOAP message by selectively re-encoding portions of the message, while still presenting an XML Infoset to the SOAP application. This Abstract Transmission Optimization Feature is intended to be implemented by SOAP bindings, however nothing precludes implementation as a SOAP module. The usage of the Abstract Transmission Optimization Feature is a hop-by-hop contract between a SOAP node and the next SOAP node in the SOAP message path, providing no normative convention for optimization of SOAP transmission through intermediaries. Additional specifications could in principle be written to provide for optimized multi-hop facilities provided herein, or in other ways that build on this specification (e.g., by providing for transparent passthrough of optimized messages). The second part ('Inclusion Mechanism') describes an Inclusion Mechanism implementing part of the Abstract Transmission Optimization Feature in a binding-independant way. The third part ('HTTP Transmission Optimization Feature') uses this Inclusion Mechanism for implementing the Abstract Transmission Optimization Feature for an HTTP binding. This document represents a transmission optimization mechanism which was inspired by a similar mechanism in the PASWA document ('Proposed Infoset Addendum to SOAP Messages with Attachments'). The WG plans to work later on the other parts of that document (assigning media types to binary data in XML infosets and including representations of Web resources in SOAP messages) and to publish other drafts which will include such mechanisms... This specification has currently no well-defined relation with the 'SOAP 1.2 Attachment Feature' specification. However, it may be expected that this specification will supersede the SOAP-AF specification once this specification has reached a stable state..." See also "SOAP 1.2 Attachment Feature, W3C Working Draft 24-September-2002.
[June 10, 2003] "SOAP 1.2." By Rich Salz. From O'Reilly WebServices.xml.com (June 10, 2003). ['SOAP is a technology that has had much attention and been through numerous revisions. Now that SOAP 1.2 has reached "Proposed Recommendation" status at the W3C, it's all almost over. Rich Salz guides us through SOAP 1.2, highlighting the major changes and improvements from SOAP 1.1.'] "SOAP 1.2 has reached Proposed Recommendation (PR) status, which means that the W3C XML Protocol Working Group believes that it's done. A few PR issues have been raised. It can be fun to look at the list, as the issues range from 'I found a typo' to 'this isn't full XML, send it back to the committee'. If you're pedantically inclined -- and everyone in the computer field must have at least some inclination in that direction -- now is the time to break out the coffee and the reading glasses in order to find issues of your own. Within the next week or two, we should know if Tim Berners-Lee approves the PR, making it a formal W3C Recommendation (i.e., a standard in everything but name); or, if he identifies issues that need to be resolved, requiring another round of work. The results could be interesting: there are, as usual, a number of political issues involved... The biggest difference between SOAP 1.1 and SOAP 1.2 is that the 1.2 specification is built around the Infoset... The descriptions SOAP message processing are no longer based on syntax but on the information that the message carries. An implementor can determine what information items are important and must be preserved. It's now feasible to understand how to 'tunnel' a SOAP message safely over any appropriate transport. Following the logic, you can know see that SOAP is now much more transport-neutral. With any luck we'll see a wide variety of environments supporting SOAP messages in a very powerful way; as much as possible, they will look like native messages within the environment, but they'll be able to cross that environment and be safely converted to 'classic HTTP/SOAP' without any information loss. In other words, I can have HTTP-based servers at each end of a processing pipeline, but have MQ, SMTP, CORBA/IIOP, or other intermediaries doing parts of the processing along the way. If the middleware vendors follow through on that promise, we really will have a universal distributed messaging infrastructure. I'm actually fairly optimistic about this, since it seems the only way that proprietary middleware stands a chance of not being wiped out completely by HTTP plumbing and WS-xxx headers commoditizing their value-add for items like reliable transport. The relationship between SOAP, MIME, and HTTP has been cleaned up. Most SOAP developers will probably never notice this, but it's a good thing Hopefully SOAP vendors will make it easy to generate and parse these new formats: having multilingual server error messages can be a big win, although knowing what language to output might require close integration with the transport layer. From the developer's perspective, however, at least initially the major difference between SOAP 1.1 and SOAP 1.2 faults is that SOAP 1.2 does not use HTTP status code 500 (server error) to indicate a fault. As far as HTTP is concerned, a fault is a normal HTTP response message and is an accommodation to the principles of REST. It will have interesting implications for programmers who write their own SOAP stacks..." See details in "W3C Publishes SOAP Version 1.2 as a Proposed Recommendation."
[March 25, 2003] "Squeezing SOAP. GZIP Enabling Apache Axis." By Brian D. Goodman (IT Architect, IBM Intranet Technology, IBM). From IBM developerWorks, Web services. ['GZIP encoding over HTTP is pretty much old school. "Been there, done that" is the attitude of most. However, if you have been working with a few of the current SOAP implementations, you'll find that they don't take advantage of it. While knowing they will eventually come around, if you are building real world Web service solutions and want a performance boost, GZIP is for you.'] "GZIP encoding over an HTTP transport is a well known technique for improving the performance of Web applications. High traffic Web sites use GZIP to make their user's experience faster, and compression is widely used to make files smaller for download and exchange. In fact, as far as XML goes, GZIP is not even the latest, cool thing to be doing. New technology, like AT&T's XMill, claims twice the compression of GZIP in roughly the same amount of time. GZIP, however, is a core component of the Java platform and many Web servers have the ability to compress content independent of the files or applications it serves up. For that reason, this article will look at what it takes to use GZIP in conjunction with the Axis SOAP implementation. This has proven useful for projects and solutions that need the extra performance now and for which you are willing to sacrifice time spent integrating with follow on releases of SOAP implementations later. Furthermore, this article looks at encoding at the servlet level, which will enable you to implement a different content encoding scheme... GZIP encoding over HTTP is part of Web technologies as we know it. Using it in the existing Web service framework is a logical next step. However, solutions are being designed, built, and deployed every day on these SOAP implementations. In many instances, being able to GZIP encode the SOAP envelope results in faster transaction times with a relatively low overhead. This performance upgrade can be realized today with some simple code modifications. Enabling GZIP encoding in your SOAP environment lets you take advantage of compression today, while patiently waiting for the integration into our favorite implementations..."
[March 03, 2003] "XML, SOAP and Binary Data." By Adam Bosworth (BEA Systems), Don Box (Microsoft), Martin Gudgin (Microsoft), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), and Jeffrey Schlimmer (Microsoft). From XML.com (February 26, 2003). White paper Version 1.0, February 24, 2003. ['A white paper which discusses the architectural issues encountered when using opaque non-XML data in XML applications, including (but not limited to) Web services and SOAP. This white paper from Don Box and his colleagues addresses a long term issue in XML, namely the coordinated transport of opaque binary data in conjunction with an XML document.'] "The desire to integrate XML with pre-existing data formats has been a long-standing and persistent issue for the XML community. Users often want to leverage the structured, extensible markup conventions of XML without abandoning existing data formats that do not readily adhere to XML 1.0 syntax. Often, users want to leave their existing non-XML formats as is, to be treated as opaque sequences of octets by XML tools and infrastructure. Such an approach allows widely used formats such as JPEG and WAV to peacefully coexist with XML. As XML is increasingly used as a message format (e.g., SOAP), the interest in integrating opaque data with XML has increased to the point where there are at least two competing proposals for doing so (SOAP With Attachments [SwA] and WS-Attachments). Because SwA was the first widely-publicized mechanism for dealing with binary data, it has had a large influence on how the community views the issues surrounding this topic. Unfortunately, SwA (as well as WS-Attachments) conflates several orthogonal issues. Specifically, both SwA and WS-Attachments assume that a URI-based referencing mechanism by itself is sufficient for supporting opaque binary values in messages. Moreover, at least one of the proposals (SwA) attempts to solve problems that are in no way limited to SOAP, that is, how URI that appear as XML element or attributes content are to be resolved in the presence of multipart MIME. As field experience with both SwA and WS-Attachments has shown, the lack of an XML-focused approach to opaque data has lead to solutions that are unnecessarily complex for developers and software components. This white paper attempts to present the various issues raised by dealing with opaque data in XML, without nominating a particular solution... Retaining SOAP's tradition of purely Infoset-based messages has various advantages: (1) SOAP extensions only have to be defined in terms of one data model and one processing model, both of which are already defined in SOAP/1.2. (2) Applications can directly take advantage of the rich set of technologies available for XML processing. (3) Interface description can provide a single, simple, and consistent model to the developers and tools. (4) Programmatic interfaces can expose a single programming model to the developer. (5) A single security model can be applied to the Infoset, encompassing all message content in a uniform manner. (6) Infoset mappings can be defined for multiple serialization formats, effectively unifying multiple messaging technologies. (7) Finally (and perhaps most importantly), ALL SOAP messages can be represented in pure text. Even in the face of exotic in-memory or on-disk data structures for representing XML, one can always produce a purely text-based form of the message. The utility of the installed base of text processing tools should not be overlooked. Text is our heritage and abandoning it loses a key feature of the web service architecture. The authors of this paper believe strongly that that data and processing model for SOAP has always been and should remain purely XML-based. Literally thousands of man-years have been directed at defining and refining an architecture based on these assumptions. Moreover, the data and processing model for SOAP should deviate as little as possible from the current SOAP/1.2 Candidate Recommendation. The authors also believe that the XMLP WG charter allows sufficient freedom in associating opaque data with SOAP Messages to define a SOAP specific processing model, including the XInclude approach, as well as participating in or leading other approaches..."
[December 26, 2002] "From XML-RPC to SOAP: A Migration Guide." By Rich Salz. From XML.com. December 18, 2002. ['This month's installment from Rich Salz, our resident Web Services commentator, tells users of XML-RPC it's about time they started using SOAP, and provides a migration path to move between the two Web services protocols. As usual, Rich provides plenty of code and examples.'] "As you might expect from the name, XML-RPC is a way of using XML to send classic Remote Procedure Calls (RPC) over the net. XML-RPC's use of XML is very simple. It doesn't use namespaces. It doesn't even use attributes. Poking at the reasons behind technology standards can lead to interesting results. The really good ones, like the first ANSI C specification, include a detailed rationale for key decisions. Most internet standards don't spend the effort but prefer, instead, to allow an archived mailing list to act as a primary source. And, even then, it can be fun to play standards archaeologist. The primary motivator behind XML-RPC is Dave Winer, owner of a small ISV company, and one of the first webloggers. Winer was part of the initial, self-selected group that created SOAP. According to Don Box's Brief History of SOAP, Winer grew impatient with corporate delays. In July, 1998, Winer posted the specification for XML-RPC. At that point, the Namespaces in XML group had published two drafts; final recommendation publication wouldn't happen until January, 1999. Given the state of flux, and all the churn caused by following XML Schema drafts which Don describes in his article, it isn't surprising that XML-RPC avoids namespaces altogether. It is surprising, however, that XML-RPC doesn't use XML attributes. One might surmise that doing without attributes makes parsing much simpler. XML-RPC is well-suited to simple lexical handling: divide the input stream into 'tags', which are simple words surrounded by angle brackets, and values. In hindsight, however, it makes for strange XML... With a few simple changes, XML-RPC applications should be able to send and receive SOAP messages to and from well-behaved SOAP applications. Perhaps surprisingly, most of the work is in constraining the SOAP applications to be well-behaved. In the standards world, when a specification has many options and possibilities, and you define yourself to a conformant subset, that's called a profile. So what we've started work on is a SOAP profile, defined in WSDL, that should make it easy for 'legacy' XML-RPC applications to interoperate..."
[December 09, 2002] [W3C TAG] Draft of Position on SOAP's use of XML Internal Subset." By Noah Mendelsohn (IBM). Posting 2002-12-06 to W3C 'xml-dist-app' list, "a forum for discussion of XML in distributed applications, network protocols, and messaging systems," used by the W3C XML Protocol Working Group for its technical discussions. "A few days ago I was asked to draft a note that would explain to the TAG [Technical Architecture Group] and other concerned members of the W3C community some of the reasons behind SOAP's restrictions on the use of XML... The XML Protocols Workgroup appreciates this opportunity to clarify our design decisions regarding use of XML features such as the Internal Subset (for those not familiar with the term, 'Internal Subset' is the official term for a DTD that appears within an XML document..."
[November 19, 2002] "Mindreef Announces Availability of SOAPscope Personal 1.0 at SD East. Industry's First Web Services Diagnostics System Helps Solve Common Web Services Problems." - "Mindreef, LLC announced today at SD East the availability of Mindreef SOAPscope Personal 1.0, the first offering in the company's flagship product family and the industry's first Web Services Diagnostics System. This emerging category of products addresses the challenges of isolating and solving problems of applications built with Web Services. SOAPscope Personal 1.0 is an easy-to-use, platform-independent diagnostics aid for developers, testers and application support technicians. It provides a scalable logger and intelligent viewer for SOAP-based Web services, enabling users to quickly track and troubleshoot problems such as errant data, performance issues and interoperability issues... Debugging XML Web services is different than debugging other types of applications, even classic distributed systems. When components are running on disparate systems spread across departmental or corporate boundaries, even simple problems can be very difficult to isolate. Web services are driving the need for deeper, more specialized tools that focus on the connections between loosely coupled components rather than the code in the components... SOAPscope Personal stores the log in an embedded relational database. This gives users greater flexibility when slicing, dicing and filtering to quickly locate the target messages. By embedding the database Mindreef has made installation and administration simple... SOAPscope Personal offers two ways to hook into the SOAP stream for logging. Sniffer mode allows for quick and easy start-up without any code modification. For finer grained data collecting or for situations where users don't have access to a sniffable network entry point, SOAPscope Personal also supports proxy mode... A Pseudocode View simplifies the interpretation of XML in a SOAP packet or a WSDL file. It can reduce pages of tedious, complex XML to a few lines of pseudocode. Most of the time, viewing raw XML gets in the way. At other times, users need to see the raw XML to find a subtle problem. SOAPscope Personal provides both views... With Modify/Resend users can quickly try new values and re-send the SOAP packet to the service without leaving SOAPscope. Modify/Resend also allows for ad hoc testing of boundary and error conditions. And since the endpoint can be modified, it can be used to quickly test a service that has just been updated... SOAPscope's Debugging Annotations feature puts debug output statements in the log, providing message context and eliminating the need to identify what client or thread was active when the debug statement was output..."
[November 19, 2002] "Scoping Out Web Services Problems." By Darryl K. Taft. In eWEEK (November 19, 2002). "Mindreef LLC on Tuesday announced at the Software Development East 2002 show, in Boston, the availability of Mindreef SOAPscope Personal 1.0, a new Web services diagnostics system for developers. SOAPscope Personal 1.0 features a logger and viewer for finding and troubleshooting problems in such areas as performance and interoperability, said Jim Moskun, a co-founder of Mindreef, based in Hollis, N.H. Moskun said the Mindreef product collects information about Simple Object Access Protocol (SOAP) transactions and uses it to shed light on Web services communications. And while most logging tools store data in a flat file, SOAPscope Personal stores it in a relational database for easier use, he said. SOAPscope will run in sniffer mode on a network or as a proxy, the company said. It also supports psuedocode, has Modify/Resend capability for trying new values and re-sending SOAP packets when errors occur and features debugging annotations for putting debug output in the log, Moskun said. "There's a lot of activity in Web services management, but we felt there weren't any tools targeted at problems people have today," Moskun said. "A lot of companies are ahead of the curve, building large infrastructures to handle Web services management, but people are still in the early adopter phase. Things like interoperability between toolkits is a problem, and getting from point A to point B. If a message doesn't get through, you need to find out what went wrong." Moskun said Mindreef joined SOAPbuilders, an informal group of grassroots Web services implementers -- including Sun Microsystems Inc., IBM Corp., IONA Technologies Inc, BEA Systems Inc. and others -- who gather quarterly to test the interoperability of their Web services platforms. He said the group used SOAPscope as one of the tools in the tests..." See the SOAPbuilders discussion list and description [from Sun Microsystems].
[November 02, 2002] "W3C Close to Ratifying SOAP 1.2." By Paul Krill. In InfoWorld (November 01, 2002). "SOAP 1.2, the proposed revision of the Simple Object Access Protocol Web services specification, may be finalized by the World Wide Web Consortium (W3C) within two to three months, a W3C representative said on Friday. But intellectual property rights could hinder the process. The 393 issues raised by industry participants around the development of SOAP 1.2 since June 2001 have been narrowed down to just 11, said W3C representative Janet Daly. The W3C XML Protocol Working Group met in Bedford, Mass., October 29-31 to deliberate on SOAP 1.2. Among the remaining issues to be resolved is intellectual property, with the group believing 'there may be significant intellectual property issues with the SOAP specification,' according to the working group's statement. 'Multiple companies have said they believe they may have relevant patents. Further investigation is required here before the specification should proceed to PR [proposed recommendation] phase,' W3C said in noting the outstanding issues. Proposed recommendation is the ratification stage. Two vendors, webMethods and Epicentric, which has just been acquired by Vignette, have stated they may have possible patents pertaining to SOAP 1.2, with webMethods stating as of September 11 [2002] it is not willing to waive its patent rights and Epicentric saying it has not been given permission to make a public statement, as of the same date. There have been no changes in those statements as of Friday but that may happen next week, Daly said... Some other vendors participating in the working group, including IBM and Tibco, report in the W3C statement that they have not identified any intellectual property rights related to the SOAP 1.2 effort and thus have not declared any. Tibco, for one, said in its statement it has not identified any intellectual property rights in the current XML Protocols activity, but that it may own patents or have other intellectual property rights in this activity or may identify subsequent contributions to the W3C as containing intellectual property rights. Microsoft, which also has not declared any patents pertaining to SOAP 1.2, is granting royalty-free use of its copyrights for use the specification. Other outstanding issues in SOAP 1.2 include the scope of the specification itself, lack of both a dedicated conformance section in the specification, and a conformance clause and de-referencing of URIs (universal resource identifiers) inside SOAP. Additional issues include implementation technicalities and issues with specific technical terms and characterization of white space..." See SOAP Version 1.2 Part 1: Messaging Framework [W3C Working Draft 26-June-2002] and SOAP Version 1.2 Part 2: Adjuncts [W3C Working Draft 26-June-2002]; also from 2002-09-24 Last Call Working Draft for SOAP 1.2 Attachment Feature."
[October 09, 2002] "Finding Your Way Through Web Service Standards: Will My Web Service Work With Your Client? Understanding the Intricacies of SOAP." By Jordi Albornoz (Software Engineer, Advanced Internet Technology, IBM). From IBM developerWorks, Web services. October 2002. ['Web services are defined by a myriad of standards. Each standard is general enough to be independent from the other standards but specific enough to only address a small piece of the Web services puzzle. The interaction between SOAP, WSDL, XML Schema, HTTP, etc. can become very complicated... This series will guide you through the prevailing Web services standards describing their specific use and explaining what it really means to support each one, how they interact, and most importantly, where compatibility problems are likely to occur. The articles will also discuss the relevant changes to come as many of these standards are being revised. In this first article in the series, Jordi Albornoz will introduce the issue of complex interaction of standards and describe some of the issues around SOAP.'] "... communicating with a Web service does not simply involve understanding WSDL, SOAP, and XML Schema. That is not enough information. Instead it involves, among other things, understanding particular extensions to WSDL, the specific transports over which to send SOAP envelopes, and the data encoding expected by the service. Just as XML is often joked about as being a standard whose sole purpose is to create more standards. The family of Web services standards seems to share that property. No doubt we will soon see higher level specifications making use of WSDL and SOAP in some specific manner. In Web services terminology, these higher level specifications would often be referred to as bindings. Moreover, each of the main specifications contains ambiguities that can stifle interoperability, thus requiring understanding of the specific interpretations of the specs. Each standard has extensibility points, optional sections, and ambiguities which contribute to divergence in functionality of implementations.... The generality of SOAP means that not all systems that make use of SOAP can communicate easily. Since SOAP is transport independent and does not enforce a data encoding format, one must be aware of more about a service than simply that it supports SOAP. The most important thing to understand is that SOAP is simply a message format. In the next article in this series, I will explain another commonly misunderstood aspect of SOAP which is responsible for many interoperability issues, namely, data encoding... one must be aware of the data encoding to properly communicate with a Web service. But that is not enough in many cases. I will attempt to clarify the purpose of different data encodings and dig deeper into the specific issues surrounding the particularly confusing SOAP Section 5 Encoding. I will also begin to discuss WSDL and its relation to SOAP and other Web services standards..."
[October 02, 2002] "Developing Web Services, Part 3: SOAP Interoperability." By Bilal Siddiqui (CEO, WAP Monster). From IBM developerWorks, Web services. September 2002. ['In this article, Bilal will start with a discussion of the evolution of SOAP, present a list of major SOAP interoperability issues and their details, and create a guideline to develop better interoperable Web services. Bilal will also cover the details of using datatypes in SOAP.'] "This article is the third in a series of four articles aimed at introducing the process of creating, describing and publishing Web services. In the first part, I explained how to describe a Web service with the help of WSDL authoring examples. In the second part, I discussed the architecture of SOAP and its semantics. In this installment, I'll take a look at the interoperability issues related to SOAP. The Web services model divides the entire B2B spectrum into three steps or domains: describe a service, bind it with a concrete implementation, and publish it over a registry. These three steps are independent of one another and give rise to separate interoperability issues. WSDL (Web Services Description Language) constitutes the description domain, SOAP covers the binding domain, and Universal Description, Discovery and Integration (UDDI) registries cover the publishing domain. My discussion in this part will be limited to the interoperability issues related to the binding domain. I will start by describing the evolution of SOAP, which will follow the actual SOAP interoperability issues... Interoperability problems can surface due to an engine's inability to process the mustUnderstand SOAP headers. SOAP functionality can be extended through custom headers. This extensibility also opens the route for proprietary and non-standard solutions which may ultimately create interoperability issues. SOAP allows the use of multiple return parameters which are not supported by some implementations (for example, Apache SOAP 2.2). Encoding schema describes the rules that are followed to serialize and de-serialize data to and from XML. Unfortunately SOAP 1.1 does not specify a default encoding for SOAP messages although it does propose one. SOAP implementers are not bound by the specification to implement the specification-defined encoding in order to conform. The lack of a default encoding schema can lead to interoperability problems... I can offer a little advice for developers who are planning to build Web services on present SOAP implementations or who are on their way writing their own SOAP servers and clients. (1) If you are planning to work with SOAP 1.1 implementations, keep the SOAPAction header quoted in your requests and be sure it conforms to the service's WSDL file. (2) Adopt the 2001 namespace URI for XML Schema as it is the de facto standard now. (3) Comply with the encoding defined by SOAP 1.1 and ensure that data that you send and receive is really what it should be. (4) Your method element names should conform to the WSDL description. Provide datatype information on the wire in SOAP messages. See also part 1 "Introduction to Web services" and part 2 "Simple Object Access Protocol (SOAP)." Also in PDF format.
[August 30, 2002] "Transporting Binary Data in SOAP." By Rich Salz. From XML.com. (August 28, 2002). ['In his monthly Web services column, XML Endpoints, Rich Salz tackles the problem of sending binary data using SOAP. There are several solutions to this problem, and this month Rich looks at "SOAP Messages with Attachments".'] "... it's not good to try to embed arbitrary binary or XML content into another XML document. This is particularly bad news for SOAP and web services, since SOAP messages are XML documents with a thin layer -- a SOAP bubble, perhaps? -- around them. The right approach is to pull the embedded content out of the XML container, and replace it with a link. Fortunately, SOAP defines the href attribute that makes such linking fairly easy... Usually it's necessary to bundle the data with the message. When this is done, we typically call the SOAP message the payload and the data that used to be embedded as attachments. There are three common formats for doing this. In no particular order, they are (1) SOAP Messages with Attachments (SwA), which uses multi-part MIME; (2) DIME, a binary packaging format created by Microsoft; (3) BEEP, a very powerful facility by protocol expert Marshall Rose. We'll look at each of these in turn, starting with SwA for the rest of this column, and DIME and BEEP in subsequent months. While "direct handling of binary data" was explicitly declared to be out of scope for the W3C SOAP working group, this should change once SOAP 1.2 enters the standardization track. Using one of the existing mechanisms seems the most reasonable way to move forward... SOAP Messages with Attachments is a W3C Note, just like SOAP 1.1. It was published in December of 2000, seven months after the SOAP Note. The name turns out to have been unfortunate, having usurped the obvious generic term. SwA is very simple: the first part of the multipart MIME message is the XML SOAP document; the subsequent parts contain the attached data. The bulk of the document addresses URI resolution, particularly relative URIs. If we ignore them and always use absolute URIs (the current recommendation), the specification becomes even simpler. In the example below, we'll use email-like Message-IDs as our identifiers, as they have the convenient properties of being globally unique and absolute. We'll just attach a prefix to a single Message-ID to distinguish the parts..." See also (1) "Direct Internet Message Encapsulation (DIME)"; (2) "Blocks eXtensible eXchange Protocol Framework (BEEP)."
[July 19, 2002] "Processing SOAP Headers." By Rich Salz. From XML.com. July 17, 2002. ['Rich Salz examines the how and why of SOAP header processing. Rich takes last month's Google Web service example further and introduces an intermediary into the SOAP message chain.'] "Last month we built a simple client for the Google API. In this month's column we'll look at how SOAP headers can be used to talk to an intermediate server that adds value to the basic search service. The value-add is actually pretty silly: we'll send the query, pick one of the results at random to return, and send it back as an HTML page in Pig Latin. Our goal, however, is to understand how to process SOAP headers, and why you'd want to do so. But first I want to thank Google for providing a wonderful Web API, which it is, module the concerns I addressed in my first column. SOAP structures a message into two main parts: the headers and the body. I'll go out on a limb and say that almost all SOAP messages so far use the body. Very few put anything in the SOAP headers. I think the recent flurry of activity in SOAP security standards means that this will soon change, however, so it's worth understanding when and how to use SOAP header elements. SOAP is more than just a sender-receiver protocol, although that, too, is certainly the dominant use today. SOAP supports the concept of a message passing from a recipient, possibly through one or more intermediaries, and ending up at its destination, more precisely known as the ultimate receiver... Along the way, the intermediaries may perform processing on the message or its side-effects. For example, a message may pass through a transaction service, providing a client with guaranteed invocation in the presence of network failures; a security service may sit at an enterprise portal, providing authentication information; and so on. An important aspect of these examples is that the basic operation is unchanged. While this isn't made explicit in the SOAP specifications, it's commonly accepted that intermediaries are intended to work primarily on the metadata of the SOAP message. SOAP headers are the ideal place for such data. SOAP headers are also a good place to put optional information, and a good means to supporting evolving interfaces..."
[June 28, 2002] "SOAP Version 1.2 Email Binding." By Highland Mary Mountain (Intel), Jacek Kopecky (Systinet), Stuart Williams (HP), Glen Daniels )Macromedia), and Noah Mendelsohn (IBM). W3C Note 26-June-2002. Version URL: http://www.w3.org/TR/2002/NOTE-soap12-email-20020626. Latest version URL: http://www.w3.org/TR/soap12-email. The document has been published as a "result of the Transport Binding Task Force (TBTF), which is part of the XML Protocol WG. The document is meant to be an illustration of the SOAP 1.2 Protocol Binding Framework applied to a well known Internet transport mechanism, Email, specifically RFC2822... The motivation for this document is to illustrate the SOAP 1.2 Protocol Binding Framework and the creation of an alternative protocol binding specification to the Default HTTP binding. This second binding is meant to validate the Protocol Binding Framework for completeness and usability; note that this document is a non-normative description of an Email Binding. It is not the responsibility of this SOAP binding to mandate a specific email infrastructure, therefore specific email infrastructure protocol commands (such as SMTP, POP3, etc) are not covered in this binding document. The underlying email infrastructure and the associated commands of specific email clients and servers along the message path are outside the scope of this email binding... This SOAP binding specification adheres to the SOAP Protocol Binding Framework, and as such uses abstract properties as a descriptive tool for defining the functionality of certain features. Properties are named with XML qualified names (QNames). Property values are determined by the Schema type of the property, as defined in the specification which introduces the property..." Note in this connection that the W3C XML Protocol Working Group has released four SOAP Version 1.2 Last Call Working Drafts: the Primer, Messaging Framework, Adjuncts, and Assertions and Test Collection.
[April 09, 2002] "Apache SOAP Type Mapping, Part 2: A Serialization Cookbook. Follow these steps to write your own custom serializers and deserializers." By Gavin Bong (Software Engineer, eUtama Sdn. Bhd.). From IBM developerWorks, Web Services. April 2002. See previously: "Apache SOAP Type Mapping, Part 1: Exploring Apache's Serialization APIs. Learn how to translate the data types in your apps into XML." ['SOAP specifies an encoding to represent common types found in databases, programming languages (for example, Java programming language), and data repositories. Apache SOAP's toolkit supports encoding by supplying a base set of (de)serializers; classes that do the grunt work of mapping Java types to serialized XML representations. Part 1 of this two-part series explored the use of these (de)serializers. Here in Part 2, Gavin Bong shows you how to write your own (de)serializers when none from the toolkit suit your needs. He also provides an example application that demonstrates many of the concepts explored in this series.'] "In the first article in this series, you saw how SOAP maps data types to XML, and learned how to use the serializers and deserializers (hereafter referred to collectively as (de)serializers) included in the Apache SOAP toolkit. In this installment, I'll walk you through a cookbook that will show you how to write your own (de)serializers. I would advise you to have the sources of some of the base (de)serializers available for reference. You may also want to reread the 'Type Mapping Pattern' section in Part 1 to refresh your memory on how type mappings are resolved internally. Once I've finished with the cookbook, I will present a simple application that implements schema-constrained SOAP. The application will describe an interaction in which a purchase order document that's purposely noncompliant with Section 4 encoding is sent using SOAP. [...] I hope that the examples in this article have made clear the theoretical concepts outlined in the first article in this series. If Web services operating across many machines on the network are to become a widespread reality, developers must understand how programmatic objects are transmitted from one machine to another. A better understanding of SOAP's type mapping abilities should help you build better distributed applications and services."
[April 03, 2002] "Apache SOAP Type Mapping, Part 1: Exploring Apache's Serialization APIs. Learn how to translate the data types in your apps into XML." By Gavin Bong (Software Engineer, eUtama Sdn. Bhd.). From IBM developerWorks, Web Services. April 2002. ['SOAP defines a simple wire protocol for transferring application-level data. This protocol can easily carry arbitrary Java types as serialized XML, thanks to its rich and extensible type system. In this article, the first of a two-part series on the type system support found in the Apache SOAP toolkit, Gavin Bong will introduce you to the theoretical underpinnings of SOAP's type system. You'll also learn more about SOAP's programmatic support for serialization and deserialization and conclude with an exploration into the toolkit's internals. A better understanding of how these processes work will help you build your own distributed systems.'] "When data is exchanged electronically, the endpoints of the exchange need to agree in advance on two things: an interaction pattern and a type system. The former is concerned with the architecture of the communication channel (for example, point-to-point versus many-to-one, or blocking versus asynchronous). The latter, on the other hand, is an agreed data format for use in encoding and decoding messages. In this article, I will describe the type system in SOAP, as applicable to the Apache SOAP toolkit. Although the current incarnation of the SOAP toolkit supports both messaging and RPC interaction patterns, this article will concentrate on the latter. Unless otherwise stated, the features discussed in this article apply to Version 2.2 of Apache SOAP, released in May 2001. Where appropriate, I will highlight bug fixes or interface changes that have occurred since that release. [...] In this article, I've explored most of Apache SOAP's out-of-the-box API support for (de)serializing Java types. I've also covered some of the idiosyncracies that may inhibit interoperability with other Java- or non-Java-based SOAP toolkits. In the next installment, I will introduce a cookbook that will guide you in writing your own (de)serializers. You'll also see how you can work with SOAP's non-Section 5 encodings by utilizing a schema language." Article also available in PDF format.
[February 21, 2002] "SOAP Encodings, WSDL, and XML Schema Types." By Martin Gudgin and Timothy Ewald. From XML.com. February 20, 2002. ['This month's installment of XML Endpoints, our web services column, focuses on the relationship between WSDL, SOAP encoding and W3C XML Schema types. In particular, it looks at how the encoding of a SOAP message is generated when a WSDL decription and corresponding schema are not the starting point for using the web service.'] "Using a web service involves a sender and a receiver exchanging at least one XML message. The format of that message must be defined so that the sender can construct it and the receiver can process it. The format of a message includes the overall structure of the tree, the local name and namespace name of the elements and attributes used in the tree, and the types of those elements and attributes. The name and types of the element and attributes contained in the message can be defined in a schema. The Web Services Description Language (WSDL) can use a schema in this way. And if a WSDL description of the web service is the start point, then the message format is known before a line of code is written. However, in many cases, the code that is to be exposed as a web service already exists. In other cases, developers are reluctant to start with WSDL, preferring to start with some programmatic data structure. Even in these cases, some description of the web service is needed in order for clients to correctly construct request messages and destructure responses. Ideally that description would still be WSDL, otherwise clients will have to learn to read and understand multiple description languages. So in cases where a schema and associated WSDL are not the starting point, how is the WSDL to be generated and what format do the XML messages have? Many of the SOAP implementations that exist today will happily take a programmatic data type, typically a class definition of some sort, and serialize that type into XML. But in the absence of a schema, how do these implementations decide whether to use elements or attributes? How do they decide what names to give to those constructs and what the overall structure of the tree should be? The answer can be found in the SOAP Encoding section of Part 2 of the SOAP 1.2 specification..."
[February 13, 2002] "RealNames Announces Keyword Registration Web Service. New SOAP-Based Keywords Registration Service Built in Less Than Two Weeks with Microsoft Visual Studio .NET." - "RealNames Corporation, the extended naming services company, today announced the availability of its Keywords Registration Service as a XML Web service. It was developed using Microsoft Visual Studio .NET. RealNames' Registration Service application programming interface, or approximately 35 interface calls, will be available as a XML Web service to the more than 50 RealNames registries and registrars, who can deploy it to sell and manage Keywords on their Web sites. Keywords are modern Web addresses that complement the Domain Name System (DNS), making Internet naming and navigation easier with simple names and brands that work in all languages and character sets..."
[January 22, 2002] "SOAP Messages with Attachments." By Ian Moraes. In XML-Journal Volume 3, Issue 01 (January 2002). "Organizations are being challenged to partner with other organizations in order to respond more rapidly to new business opportunities, increase the efficiency of business processes, and reduce the time to market for their products. To address these issues, they're typically required to develop interoperability between disparate, legacy applications to support collaborative business processes. This is accomplished by coordinating the exchange of business documents between applications in a predefined manner. For example, two insurance companies with different systems may need to exchange auto insurance claim data, such as a TIFF file for claims processing. Enterprise applications that support these types of requirements are known as business services. Supporting business services through Web applications, commonly known as Web services , requires a careful evaluation of available technologies. An important underlying technology of Web services is Simple Object Access Protocol. SOAP enables applications to communicate with each other in a platform, language, and operating system-independent manner. For those who need to use a Web service to perform a functionality such as sending a document in the form of attachments (e.g., a TIFF file) from one application to another using SOAP, a pertinent specification is the SOAP Messages with Attachments note. This article discusses this emerging W3C note and illustrates how it can be used with the Apache SOAP implementation..." See SOAP Messages with Attachments, W3C Note 11-December-2000; it "defines a binding for a SOAP 1.1 message to be carried within a MIME multipart/related message in such a way that the processing rules for the SOAP 1.1 message are preserved. The MIME multipart mechanism for encapsulation of compound documents can be used to bundle entities related to the SOAP 1.1 message such as attachments. Rules for the usage of URI references to refer to entities bundled within the MIME package are specified."
[January 11, 2002] "Web Services Acronyms, Demystified." By Pavel Kulchenko. From XML.com. January 09, 2002. '[The coauthor of Programming Web Services with SOAP presents a quick guide to the protocols and the specifications behind more than 20 acronyms related to Web services, from SOAP to XLANG, including a description of how they relate to each other and where each sits on the Web services landscape.'] "More than twenty acronyms related to Web services came to light during this year, and in this article I present a quick guide to the protocols and the specifications behind them, including a description of how they relate to each other and where each sits on the Web services landscape. Some of those acronyms are scrutinized in O'Reilly's recently published Programming Web Services with SOAP, which is a complete guide to using SOAP and other leading Web services standards, including WSDL and UDDI... The Web services architecture is implemented through the layering of several types of technologies. These technologies can be organized into the following four layers that build upon one another: [Discovery, Description, Packaging/Extensions, Transport]... Each layer of the Web services stack addresses a separate business problem, such as security, reliable messaging, transactions, routing, workflow and so on. Addressing the need for standardization in this field, several players have come up with a set of specifications that serve as the foundation for their own versions of a comprehensive Web services architecture... Let's wade through a bit of the acronym soup first to get a sense of the breadth and scope of the proposals floating around right now, and then we'll map those protocols to the architecture stacks being pushed by some of the companies... As you can see, the picture is quite complex. To make things even more confusing, some of these specifications define extensions for SOAP messages (WS-Routing, WS-Security, WS-License and SOAP-DSIG), some define packaging format (SWA, DIME), some define SOAP-based protocol (UDDI and WS-Referral) or XML-based protocol (USML), and others define an XML format for service description or orchestration (WSDL, WSEL, WSFL, WSUI and the rest)..." Principal resources for the article: [1] OASIS, IBM: Web Services Component Model (WSCM); [2] Sun: Open Net Environment (SUN ONE); [3] HP: Services Framework Specification; [4] Microsoft: Global XML Web Services Architecture; [5] UN/CEFACT, OASIS: ebXML.
[November 30, 2001] "Microsoft Tosses a DIME for Web Services." By Cathleen Moore. In InfoWorld (November 27, 2001). Working to hammer out the technical details of Web service interactions, Microsoft this month quietly submitted to the IETF (Internet Engineering Task Force) a message format protocol designed to simplify the transmission of video, graphics, and sound files in Web services. Building on the success of the MIME (Multipurpose Internet Mail Extensions) specification, which allows graphics, audio, and video files to be sent and received in e-mail, DIME (Direct Internet Message Encapsulation) sets out to streamline the MIME standard for use in Web services. DIME addresses the difficulties involved in embedding binary data, such as video, graphics, and sound, into XML documents and in putting an XML document in another XML document, according to Philip DesAutels, product manager for XML Web services at Microsoft. The Redmond, Wash.-based company submitted DIME as an IETF Internet Draft on November 14, 2001. Hewlett-Packard and Microsoft earlier this year submitted for standards consideration development work that described how to use MIME and SOAP (Simple Object Access Protocol) to combine binary data and multiple messages together. From this development work in using SOAP with attachments, Microsoft saw a need for a simpler format for combining multiple chunks of information into one message, DesAutels said... The end goal of DIME, DesAutels said, is to untangle complex Web service interactions, which could involve passing images and video feeds as part of a service." See the news item of June 06, 2001: "Microsoft Publishes XML Web Services Specifications."
[October 16, 2001] "SOAP Version 1.2 Test Collection." From the W3C XML Protocol Working Group. Edited by Hugo Haas (W3C) and Oisin Hurley (IONA Technologies). ['Demonstrating interoperability, the tests are intended to show that SOAP 1.2 meets its goal for conformance requirements, and that implementations exist for each of its features. Instructions are linked from the call for contributions.'] Abstract: "This document draws a list of testable assertions found in the SOAP Version 1.2 specification, and provides a set of tests in order to show whether the assertion is implemented in a SOAP processor. The goal of this document is to get a list of features whose implementation can be tested in order to satisfy the entrance criteria of the Proposed Recommendation stage. It is incorrect to claim to be compliant with the SOAP Version 1.2 specification by passing successfully all the tests provided in this test suite. An implementation which would pass all the tests below may claim to be compliant with the test suite dated 2001/10/12 21:14:17..."
[October 11, 2001] "Transport Message Exchange Pattern: Single-Request-Response." From the W3C XML Protocol WG. October 11, 2001. "This is an attempt of a write-up of a request-response message exchange pattern description based on discussions within the XML Protocol WG TBTF. The document has no status whatsoever nor does it necessarily represent consensus within the TBTF or within the XML Protocol WG as a whole... The use of single here is to capture the notion that this there is to be no implied timing relationship between contemporaneous exchanges conforming to this transport exchange pattern, i.e., nothing can be said about the relative temporal ordering of the transmission and reception of messages arising from distinct exchanges. Might rename Independent-Request-Response. Single could be misinterpreted as just 1 response or a unicast pattern (both of which happen to be the case but are not the motivation for the prefix)." Informal description: "The single-request-response transport message exchange pattern defines a pattern for the exchange of two messages between two adjacent SOAP nodes along a SOAP Message Path. One message is exchanged in each direction between a Requesting SOAP Node and a Responding SOAP Node. The normal operation of a message exchange conforming to the single-request-response exchange pattern is such that a Request Message is first transferred from Requesting SOAP Node to Responding SOAP Node. Following the successful processing of the Request Message by the Responding SOAP Node, a Response Message is then transferred from Responding SOAP Node to Requesting SOAP Node. Abnormal operation of a message exchange conforming to the single-request-response exchange pattern may arise due to a failure to transfer the Request Message, a failure at the Responding SOAP Node to process the Request Message, or a failure to transfer the Response Message. Such failures MAY be silent at requesting, responding or both SOAP Node involved in the exchange. Also, under abnormal operation each SOAP Node involved in the message exchange MAY differ in their determination of the successful completion of the message exchange..."
[November 05, 2001] "Professional XML Web Services.. Overview of the book by Patrick Cauldwell, Rajesh Chawla, Vivek Chopra, Gary Damschen, Chris Dix, Tony Hong, Francis Norton, Uche Ogbuji, Glenn Olander, Mark A Richman, Kristy Saunders, and Zoran Zaev. Published by Wrox Press, September 2001. ISBN: 1861005091. 1000 pages. "Web Services are self-describing, modular applications. The Web Services architecture can be thought of as a wrapper for the application code. This wrapper provides standardized means of: describing the Web Service and what it does; publishing it to a registry, so that it can easily be located; and exposing an interface, so that the service can be invoked -- all in a machine-readable format. What is particularly compelling about Web Services is that any client that understands XML, regardless of platform, language and object model, can access them. This book provides a snapshot of the current state of these rapidly evolving technologies, beginning by detailing the main protocols that underpin the Web Services model (SOAP, WSDL, and UDDI), and then putting this theory to practical use in a wide array of popular toolkits, platforms, and development environments. The technologies presented in this book provide the foundations of Web Services computing, which is set to revolutionize Distributed Computing, as we know it. The book covers: (1) The architecture of Web Services -- past, present, and future; (2) Detailed explanation of SOAP 1.1; (3) An overview of SOAP 1.2 and XML Protocol; (4) IBM's Web Services Toolkit and Microsoft's SOAP toolkit 2.0; (5) Other SOAP implementations in Perl, C++, and PHP; (6) Java Web Services with Apache SOAP; (7) WSDL 1.1, UDDI 1.0, and 2.0; (8) Creating and deploying Web Services using .Net; (9) Building Web Services using Python; (10) Applying security at both transport and application levels." See the online Table of Contents and the sample chapter on "SOAP Basics." [cache]
[October 23, 2001] "Sun Extends SOAP Support Across Sun ONE Integrated Product Portfolio. Sun Software Incorporates Web Services and XML Standards." - "Sun Microsystems, Inc. today announced that the Sun ONE integrated product portfolio continues to support emerging web services and XML standards, including SOAP. As a result, Sun ONE customers can develop web services with XML support that is interoperable with other standards-based services, regardless of their underlying platform. The Java technology will provide Sun ONE with open, cross-platform support for SOAP and other key web services standards. SOAP is the simple object access protocol, an industry standard now being defined by the World Wide Web Consortium (W3C). It defines how applications communicate with one another on the network, a fundamental feature for networked services on demand. Sun ONE includes the vision, architecture, platform and expertise for developing and deploying services on demand today - from the Solaris Operating Environment and Forte tools to Java, as the applications and services development platform, to the entire stack of iPlanet products...Web services standards, such as SOAP, are still being defined, but developers can use a variety of interim implementations available from several sources, such as the Apache Project, Cape Clear or tools vendors. Vendors can also write native support into their products. The Sun ONE products and the Java platform currently utilize this model. Ultimately, the individual products that make up the Sun ONE family will utilize common implementations of XML and other web services standards as they are created by the Java Community Process (JCP), including support for SOAP and XML processing. The JCP program has completed and released the JAXP API specification to support XML processing and parsing. The Java API for XML Messaging (JAXM), which is nearing completion by the JCP, will provide SOAP support to the iPlanet Message Queue product, which in turn provides SOAP support to iPlanet Application and Integration Servers and other Sun ONE products that are implementations of Java technology. The iPlanet Integration Server today includes a native implementation of SOAP. iPlanet Message Queue is a high performance 100% Java Message Service (JMS) implementation message oriented middleware product..."
[November 20, 2001] "Using SOAP to Clean up Configuration Management." By Paul O'Connell and Rachel McCrindle. Paper presented at COMPSAC 2001 (25th Annual International Computer Software and Applications Conference), 8 -12 October 2001, Chicago, Illinois, USA. Paper Session 11B "Extensible Markup Language (XML)," chaired by Thomas Weigert (Motorola Global Software Group, USA ) and T.Y. Lin (San Jose State University, USA). Published in the Conference Proceedings Volume [IEEE: 0730-3157/02]. "Software products have become increasingly complicated over the past decade. For example, software is no longer restricted to a single binary file constructed from a small number of source files residing at a single location. Products today are frequently split across client and server architectures with further complications arising through the need for the client and the server to be built and run on different platforms, developed and deployed in multiple physical locations and by workers spanning several different time zones. These factors contribute to making modern software configuration management (CM) a vital but extremely complex process. In this paper we describe a new method for managing the configuration management of evolving modern day distributed systems based on the use of emerging web technologies, specifically XML (Extensible Markup Language) XML-RPC (XML-Remote Procedure Call) and SOAP (Simple Object Access Protocol). We have currently designed and implemented a proof of concept prototype that enables the files that make up the configuration of a product to be distributed across a network of disparate machines and operating systems, yet appear to a user to be locally stored on a single client machine. We are now in the process of improving and extending this system. Currently the Repository module is brought into existence when it is needed. It would improve performance and make the system more scalable if the server created a thread pool. Each thread would contain an instance of the Repository module. This would extend to all other modules and the administrator could specify the size of the thread pool for each module. Simple load balancing could also be added. In this instance, if a client logs into a server that thinks it is too busy then the server could reply with the name of a different server to log into. The client software would then try the log on again to the new machine without the user knowing that a switch is necessary. Compression could be added on the server end. This would reduce the amount of disk space required to store a CI. This can be done already on a server running on Windows NT, because any directory can be compressed by the operating system itself if the administrator of the operating system requests this. Linux does not have a compressed file system yet. The compression would save a considerable amount of space because the data is stored in text file, which will compress well."
[September 21, 2001] "Talk SOAP. Building Devices that Communicate." By Amit Asaravala. In WebTechniques Volume 6, Issue 10 (October 2001), pages 35-37. "SOAP, an industry-backed device communications protocol, may make the "semantic Web" a closer reality than you thought possible... Like most protocols, SOAP isn't a tangible product, but rather a set of rules that anyone can implement in a software client or server. In essence, SOAP lets your applications invoke methods on servers, services, components, and objects that lie at remote locations on the Internet. While other protocols like DCOM and IIOP/CORBA let you do similar things, they're limited in that they weren't designed specifically for the Internet and for communication between diverse companies and devices. Using DCOM to communicate between applications in two separate companies is a difficult task that first requires agreeing on ports, transfer protocols, and so on. SOAP, on the other hand, sits on top of existing HTTP connections. As most companies have Web servers configured for HTTP connections on standard port 80, most of the initial coordination is complete. Of course, companies will still need to share APIs for available objects and methods; but SOAP lets people focus on these APIs and the data that needs to be transferred, rather than on the trouble of getting two disparate systems to communicate. All you need is a SOAP-compliant client application on the one side and a SOAP-compliant server on the other. The server could be as simple as a Web server that checks the headers of incoming HTTP requests. If it finds a POST statement with a text/xml-SOAP content-type or SOAPAction header, it sends the statement to a SOAP engine that parses the command found within. There are numerous SOAP implementations available, including SOAP::Lite for Perl... Because it's infrastructure agnostic, SOAP is positioned to become the de facto standard in communications. With its reliance on common protocols and languages such as HTTP and XML, SOAP promises to reduce the amount of coordination and development traditionally necessary to facilitate communication between two or more devices. In addition to its uses for network appliances, SOAP is being touted as the enabling component for Web services. This is one of the major reasons behind Microsoft's involvement with the SOAP specification. The company's .Net frameworks will use SOAP messages to send information between companies that have agreed to share data. eBay has already agreed to use the .Net framework to open up its auction databases. When the technology is in place, developers from other sites will be able to write auction applications that rely on live data from eBay's central database. In essence, SOAP is enabling the Web that we don't see. It's the technology that will help us realize a semantic, invisible Web that runs in the background, doing our bidding without our constant attention. So long, Web browsers."
[August 06, 2001] "SOAP: Simplifying Distributed Development." By Neil Gunton. In Dr Dobb's Journal [DDJ] (September 2001), pages 89-95. "The Simple Object Access Protocol (SOAP) was developed as an open RPC protocol using XML, targeting much the same problem set as CORBA, DCOM, and Java RMI. Neil uses it to add new facilities to his web site. Additional resources include soap.txt (listings)."
[August 08, 2001] "Silverstream Software Introduces jBroker Web 1.0. Free Web Services Engine Provides Unmatched Performance for Java-based Web Services." - "SilverStream Software, Inc. today announced the availability of jBroker Web 1.0, a high-performance, portable Web Services engine and tools designed to build, run and invoke Web Services using Java. jBroker Web provides unmatched performance and deploys to standard J2EE application servers. jBroker Web provides a standards-compliant, Web Services runtime with a small footprint and flexible architecture. It is a complete XML Remote Procedure Call (RPC) environment for building, running and invoking Web Services using Java. Based on the Java Remote Method Invocation (RMI) programming model, jBroker Web invokes Web Services like any other remote object to speed and simplify the development of Web Services. Some of the key features of jBroker Web 1.0 include: (1) The ability to generate a Web Service from any Java class including EJBs; (2) The ability to generate a Java client to access a Web Service from a WSDL file; (3) A high performance, scalable SOAP 1.1 runtime with 4-6 times the performance of Apache SOAP; (4) Interoperability with several SOAP implementations including Apache and Microsoft; (5) The ability to leverage J2EE security features for authentication and access control; (6) Deployment into standard J2EE application servers including SilverStream, IBM's WebSphere, BEA's WebLogic, Oracle 9iAS, Apache Tomcat and others. jBroker Web is also fully integrated with the SilverStream Application Server and provides the Web Services engine for the SilverStream eXtend product line, including the SilverStream eXtend Workbench. SilverStream eXtend is the first complete and integrated services environment that enables organizations to exploit the value of existing systems and deliver business applications to any user on any device or platform..." See also (1) the previous announcement, and (2) "SilverStream Software Ships the SilverStream Application Server with Full Web Services Capabilities. Provides a High-performance Web Services Engine and Tools to Simplify J2EE and Web Services-based Application Development."
[July 21, 2001] "SOAP InterOpera." By Steve Gillmor. In XML Magazine June/July 2001. "SOAP forms the core layer of Web services, and there is an active effort under way by leading developers to keep SOAP simple as a foundation for Web services that provide universal interoperability among implementations. In a roundtable discussion hosted by Editor in Chief Steve Gillmor and Editorial Director Sean Gallagher, principal developers -- SOAP coauthors Dave Winer and Noah Mendelsohn, Microsoft XML Chief Andrew Layman, and other luminaries -- discussed recent accomplishments and current challenges for interop and the standardization of Web services."
[July 13, 2001] "Building Secure Web Services with Microsoft SOAP Toolkit 2.0." By Kirill Gavrylyuk (Test Lead, Web Data SOAP Team, Microsoft Corporation). MSDN. July 2001. ['Microsoft SOAP Toolkit 2.0 provides a flexible framework to build scalable Web services for various intranet and Internet solutions. Security is an important aspect of building reliable services in both scenarios. SOAP Toolkit 2.0 provides support for Internet security based on the IIS security infrastructure. This article describes how to build secure solutions with the Microsoft SOAP Toolkit 2.0.'] "As with any distributed protocol, a critical part of any successful SOAP application is getting the security right. The SOAP standard doesn't specify any security mechanisms but delegates security handling to the transport layer. In the case of the SOAP Toolkit 2.0, that transport layer is HTTP. SOAP running on HTTP is basically just a Web application like any other ASP or ISAPI application you have running on IIS. Authentication, authorization, and encryption for SOAP use the same mechanisms as your favorite Web applications do. If you're familiar with Web security, you already know SOAP security. If you haven't worked much with Web applications, this paper will give you enough background to get started. Each topic is covered at a fairly high level... Based on the ideas laid out in Designing Secure Web-Based Applications for Microsoft Windows 2000, we will start by outlining the golden rules in building secure Web services. The following seven categories stand behind a secure Web service: Authentication, Authorization, Auditing, Privacy, Integrity, Availability, Nonrepudation. Authentication is a process by which an entity, also called a principal, verifies that another entity is indeed who or what it claims to be. Yhe SOAP Toolkit 2.0 provides support for the following Authentication methods: Basic, Digest, Kerberos, Windows NTLM, SSL Client certificates, SOAP headers based Authentication, Proxy Authentication. In this document we will cover how to configure both the server- and client-sides to use these methods..."
[July 12, 2001] "SOAP Specification for Web Services Progresses." By Tom Sullivan. In InfoWorld July 09, 2001. "The W3C (World Wide Web Consortium), in Cambridge, Mass., on Monday published a working draft for the SOAP (Simple Object Access Protocol) 1.2 standard. SOAP, a key standard embraced by vendors pushing Web services, is a data transfer protocol for sending and receiving XML information. The new working draft of SOAP 1.2 operates under a refined processing model, and major enhancements include compliance with the W3C Schema Recommendation and the use of XML Namespaces. Furthermore, the draft includes recommendations for error messages for mandatory extensions. The W3C said the recommendations provide developers with more pertinent information to help them build more interoperable and extensible applications... [MS] Desautels said that SOAP 1.2 will not break SOAP 1.1, and upgrading will be a nominal rewrite that only affects a small part of the system. So companies that already have a SOAP 1.1 implementation will not need to rewrite the back-end logic or the actual Web service. SOAP works in conjunction with the XML, WSDL (Web Services Description Language), and UDDI (Universal Description, Discovery, and Integration) standards to form the core de facto Web services protocols that enable the describing, registering, locating, and consumption of Web services." See the announcement.
June 21, 2001] "SOAP Cleans Up E-Traders' Web of Confusion." By Nick Langley. In Computer Weekly June 21, 2001. "Soap provides a mechanism for integrating services over diverse Web infrastructures. For example, developers using Visual Studio 6.0 tools in conjunction with the toolkit have a means to describe Web services as well as the transport mechanism for delivering services to devices that support Soap and XML Programmers can add this functionality to existing Com components...Microsoft describes Soap (Simple Object Access Protocol) as 'an open, standards-based interoperability protocol that uses XML (Extensible Markup Language) to provide a common messaging format to link applications and services anywhere on the Internet'. It is a 'wire protocol' similar to IIOP for Corba or ORPC for DCom. Soap has also been described as an RPC (Remote Procedure Call) toolkit that uses XML to overcome RPC's limitations. Soap was originally a Microsoft initiative, but IBM and Orb specialist Iona have also contributed a great deal. Both IBM and Microsoft are using Soap in their Web services strategies. Soap builds on universally accepted standards such as XML and HTTP. The Soap standard is now in the hands of the World-Wide Web Consortium. Applications and services that support Soap should be able to communicate freely with one another. Essentially, Soap is simple: it opens an HTTP connection, sends the appropriate XML to invoke a remote method, and reads the XML response returned by the server. Soap provides a common mechanism for integrating services over existing Web infrastructures, regardless of operating system, object model or programming language... Soap has been almost universally adopted by suppliers, standards bodies and end-users. Apache -- the open source Web server organisation -- has taken over IBM's Soap for Java toolkit. IBM's Websphere supports it. It is supported by Windows XP and VB6. Delphi 6.0 will feature compiler-level support for Soap. UDDI is Soap-based, and EBXML has pledged to support it. Online auction site eBay has signed up with Microsoft to develop Soap-based services..."
[April 27, 2001] "Soapbox: Magic bullet or dud? A closer look at SOAP." By Brett McLaughlin (Enhydra strategist, Lutris Technologies). From IBM developerWorks. April 2001. ['Brett McLaughlin casts a critical eye on the Simple Object Access Protocol, assessing the value this much-discussed new technology can provide developers and demonstrating its foundation in a mixture of the old RPC (remote procedure calls) technology and in XML. Brett examines RPC, XML-RPC, RMI, and SOAP in detail, comparing and contrasting the use of each, and discusses whether SOAP makes sense. This article also includes sample code for a SOAP envelope.'] "Like almost anything that is related to XML, the Simple Object Access Protocol (SOAP) has received plenty of press lately. It may come as a surprise to you that while SOAP's window dressing is new, what's present under the hood dates back years, even decades. In this article, I cut through the hype surrounding SOAP and look at what it's supposed to be, what it actually is, and how it stacks up to similar technologies. As always with my articles, the bottom line is to determine whether this technology works for you, and here I'll try to get beyond the buzzword-mania SOAP comes with and identify the value it can bring to your applications. I'll start with a quick look at the acronym soup that makes up SOAP, including its less-than-auspicious origins in RPC (remote procedure calls), and its use of XML to solve some of RPC's early problems. Next I'll address the features SOAP brings to the table that normal XML-RPC toolkits do not deliver, and why these additions are, or aren't, important. From there, I'll go on to compare SOAP, and RPC in general, with one of its biggest competitors, remote method invocation (RMI). I'll discuss the RPC model, the RMI information-flow model, and advantages of using XML in this context. I'll also take a look at how to make SOAP work for you. Finally, I'll cover the actual practicalities versus future promises of SOAP, and whether the underlying XML is the complete answer for your communication needs, or just part of a larger equation... I hope I've demonstrated that SOAP is not the magic bullet that some people believe it to be. Even more importantly, I hope you can see that many of SOAP's 'features,' rather than being unique to SOAP, actually are parts of RPC and XML-RPC. I did identify some specific features of SOAP, such as the SOAP envelope. Is it possible to make any conclusions at this point about the value and feasibility of using SOAP in your own work? Absolutely! First, and this is nothing new, you should always keep your eye firmly on business needs, not technology needs. While SOAP is lots of fun to play with and very chic among all your geek friends, the fact is, if it doesn't offer you a way to solve your problems, it's probably going to waste a lot of time. Also, and this is an important point, it's very possible that the task for which you've chosen to use SOAP could be accomplished more easily using XML-RPC. So don't be fooled by the hype. SOAP has arrived, but it's not a stranger in a strange land. Instead, SOAP is just the big, sometimes bloated, brother of technologies that have been around for quite a while and often are easier to use. I'll see you next time, when I'll carve even deeper into SOAP and talk more about what it can do for you." Article also available in PDF format.
[May 16, 2001] "A simple SOAP client. A general-purpose Java SOAP client." By Bob DuCharme (VP of Corporate Documentation, UDICo). From IBM developerWorks. May 2001. ['Bob DuCharme introduces a simple, general purpose SOAP client (in Java) that uses no specialized SOAP libraries.'] "This article describes a simple, general purpose SOAP client in Java that uses no specialized SOAP libraries. Instead of creating the SOAP request XML document for you under the hood, this client lets you create your own request with any XML editor (or text editor). Instead of merely giving you the remote method's return values, the client shows you the actual SOAP response XML document. The short Java program shows exactly what SOAP is all about: opening up an HTTP connection, sending the appropriate XML to invoke a remote method, and then reading the XML response returned by the server. SOAP, the Simple Object Access Protocol, is an evolving W3C standard developed by representatives of IBM, Microsoft, DevelopMentor, and UserLand Software for the exchange of information over a network. As more SOAP servers become publicly available on the Web, SOAP is doing for programs written in nearly any language -- even short little programs written in popular, simple languages like Visual Basic, JavaScript, and perl -- what HTML does for Web browsers: It gives them a simple way to take advantage of an increasing number of information sources becoming available over the Web. Like HTML, SOAP provides a set of tags to indicate the roles of different pieces of information being sent over the Web using the HTTP transport protocol (and since SOAP 1.1, SMTP as well). SOAP, however, gives you much more power than HTML. With SOAP, your program sends a 'SOAP request' (a short XML document that describes a method to invoke on a remote machine and any parameters to pass to it) to a SOAP server. The SOAP server will try to execute that method with those parameters and send a SOAP response back to your program. The response is either the result of the execution or the appropriate error message. Public SOAP servers are available to provide stock prices, the latest currency conversion rates, FedEx package tracking information, solutions to algebraic expressions, and all kinds of information to any SOAP client that asks. Before SOAP existed, programs trying to use this kind of information had to pull down Web pages and 'scrape' the HTML to look for the appropriate text. A visual redesign of those Web pages (for example, putting the current stock price in a table's third column instead of its second column) was all it took to render these programs useless. The SOAP spec, along with its brief accompanying schemas for SOAP requests and responses, provides the framework for a contract between clients and servers that creates a foundation for much more robust information-gathering tools. There are plenty of SOAP clients available for most popular programming languages..." Article also available in PDF format.
[April 05, 2001] "Clean up Your Wire Protocol with SOAP, Part 1. An Introduction to The Basics of SOAP. [Wire Protocol.]" By Tarak Modi. In JavaWorld (March 2001). ['SOAP is not just another buzzword. It is a powerful new application of vendor-agnostic technologies, such as XML, that can help take the world of distributed programming to new heights. This article, the first in a series of four articles, introduces you to the basics of SOAP.'] "SOAP stands for Simple Object Access Protocol. In a nutshell, SOAP is a wire protocol similar to the IIOP for CORBA, ORPC for DCOM, or Java Remote Method Protocol (JRMP) for Java Remote Method Invocation (RMI). At this point you may be wondering, with so many wire protocols in existence, why do we need another one. In fact, isn't that what caused the problem discussed in the opening paragraph in the first place? Those are valid questions, however SOAP is somewhat different from the other wire protocols. Let's examine how: While IIOP, ORPC, and JRMP are binary protocols, SOAP is a text-based protocol that uses XML. Using XML for data encoding gives SOAP some unique capabilities. For example, it is much easier to debug applications based on SOAP because it is much easier to read XML than a binary stream. And since all the information in SOAP is in text form, SOAP is much more firewall-friendly than IIOP, ORPC, or JRMP. Because it is based on a vendor-agnostic technology, namely XML, HTTP, and Simple Mail Transfer Protocol (SMTP), SOAP appeals to all vendors. For example, Microsoft is committed to SOAP, as are a variety of CORBA ORB vendors such as Iona. IBM, which played a major role in the specification of SOAP, has also created an excellent SOAP toolkit for Java programmers. The company has donated that toolkit to Apache Software Foundation's XML Project, which has created the Apache-SOAP implementation based on the toolkit. The implementation is freely available under the Apache license. Returning to the problem stated in the opening paragraph, if DCOM uses SOAP and the ORB vendor uses SOAP, then the problem of COM/CORBA interoperability becomes significantly smaller. SOAP is not just another buzzword; it's a technology that will be deeply embedded in the future of distributed computing. Coupled with other technologies such as Universal Discovery, Description, and Integration (UDDI) and Web Services Description Language (WSDL), SOAP is set to transform the way business applications communicate over the Web with the notion of Web services. I can't emphasize enough the importance of having the knowledge of SOAP in your developer's toolkit. In Part 1 of this four-part series on SOAP, I will cover the basics, starting with how the idea of SOAP was conceived. . ." Note also on the early history of SOAP, the article of Don Box, "A Brief History of SOAP."
[May 09, 2001] "Borland Enters Web Services Fray." By Tom Sullivan. In Infoworld (May 07, 2001). "When Borland announces the latest incarnation of its Delphi RAD (rapid application development) environment this week, the company will focus on the toolkit's tighter integration with its Kylix Linux tools and on the product's cross-platform interoperability. But Delphi's more important enhancements clearly are its support for Web services standards. Delphi 6.0 will feature compiler-level support for SOAP (Simple Object Access Protocol) and WSDL (Web Services Description Language). That means programmers will be able to Web-enable their applications without writing extra code, according to Michael Swindell, director of product management at Borland, in Scotts Valley, California. 'Delphi programmers don't have to do anything differently; they just select to expose the code from a menu,' Swindell said. The software itself adds the SOAP and WSDL functionality. Also new to Delphi 6.0 are BizSnap, a Web-services platform for building and integrating components; WebSnap, a Web application design tool; and DataSnap, a tool for creating Web-enabled database middleware. Borland is not the only tools vendor looking to help developers build Web services. WebGain, in Santa Clara, Calif., is also equipping its toolbox for Web services, and is componentizing the development process in preparation for Web services, according to CTO Ted Farrell. Analysts expect other tools vendors, such as Merant and Rational, to release products designed to help developers build Web services. All the major Web services vendors, including Microsoft, IBM, Sun Microsystems, and Oracle, have tools in various stages of development as well. 'We're at the point right now where people are starting to build Web services,' said Rikki Kirzner, an analyst at Framingham, Mass.-based IDC. 'They're not really building mission-critical apps, but they are making things such as e-business applications that use the same functions over and over.' One such customer, Hewitt Associates, a Lincolnshire, Ill.-based management consulting firm specializing in human resource solutions, is using IBM's WebSphere application server and the WebSphere suite of tools to move toward Web services..." See also the Borland announcement.
[May 09, 2001] "Borland Aims to Make Web Services a 'Snap'." By Peter Coffee. In eWEEK (April 26, 2001). "Within the next few weeks, Borland hopes to dilute the dominance of Microsoft's mind share in setting the course for Web services. While Microsoft's .Net development tools slog through a surprisingly volatile beta program, Borland will unveil in May a services-oriented tool kit that could unleash a surge of standards-based Web application deployment. I found the foundation-level DataSnap framework a logical next step along the XML-based data-handling path blazed by Borland's Linux-hosted Kylix tool set, launched earlier this year. Developers using DataSnap APIs will be able to publish any broadly supported SQL relational database via XML syntax, manipulated by SOAP (Simple Object Access Protocol) messages. Developers will be able to offer database access to a wide range of clients, including thin client browsers and 'headless' Web services, without costly development and maintenance of parallel code bases. Most strategic for Borland is the top-level BizSnap framework that fully integrates Web services into an object-oriented development environment. Anticipating the rapid adoption of XML by many enterprise developers, outpacing the emergence of standard XML schema, BizSnap tools streamline the definition of modular XML transforms that let a single application interact with XML data streams of similar content but differing structure. I found the transform creation tools intuitive and powerful. Meanwhile, SOAP bindings to Borland's integrated development environment will help developers follow the learning curve by automating syntax checking and offering intelligent auto-completion of XML-manipulating expressions, just as for conventional application code..." [Website description: "Delphi 6 radically simplifies building next-generation eBusiness applications on the Internet with complete SOAP based Web Services and XML data exchange support. The seamless integration of XML and Web Services technologies with Delphi 6 delivers the only Rapid Application Development for industry standard Web Services and B2B, B2C, and P2P integration over the Internet... DataSnap delivers high-performance, Web Service-enabled database middleware that enables any client application or service to easily connect with any major database over the Internet DataSnap supports all major database servers such as Oracle, MS-SQL Server, Informix, IBM DB2, Sybase and InterBase. Client applications connect to high-performance DataSnap servers through industry standard SOAP/XML HTTP connections over the Internet without bulky database client drivers and complex configuration requirements. DCOM, CORBA, and TCP/IP connections are also supported... Connect any Delphi 6 application or Web Service with Borland AppServer/EJBs using new SIDL (Simple IDL). Easily build ultra high-performance rich GUI Windows clients for EJB based AppServer applications. Publish AppServer EJB functionality to the world over Internet as industry standard SOAP/XML Web Services."] See also the Borland announcement.
[April 06, 2001] "ebXML Ropes in SOAP." By Alan Kotok. From XML.com. April 04, 2001. ['Our report on the latest happenings in ebXML covers their adoption of SOAP, and takes stock as ebXML nears the end of its project.'] "The Electronic Business XML (ebXML) project released three more technical specifications for review on 28-March-2001, including a new draft document on messaging services. This part of ebXML -- formerly known as transport, routing, and packaging -- had made more early progress than the other technical features, but it also came under more pressure to include the work of other initiatives, specifically the Simple Object Access Protocol (SOAP). Enhancements to the original SOAP specification made it easier for ebXML to join forces. But it also marked something of a change in operation for ebXML, now more willing to make accommodations with other related initiatives in order achieve its goal of a single worldwide e-business standard... SOAP's importance extends beyond its definition of an XML-based message protocol. Several other e-business specifications based on XML -- most notably BizTalk and Universal Description, Discovery and Integration (UDDI) -- use SOAP for its messaging functions. ... The technical architecture specifications approved by the ebXML plenary at its mid-February meeting in Vancouver, Canada, provide a technical map for the other ebXML project teams in developing the details of the technology. The document also provides a look ahead into the end game for the initiative. Part of that strategy includes the critical ebXML registry specifications. Companies will have most of their early encounters with ebXML through the registries, as companies download business processes, list their capabilities to conduct e-business, and search for potential trading partners. At the same time as the release of the messaging specifications, ebXML also released for review two draft specifications for registries: one for the registry services and the other for the registry information model. The registry services document spells out the functions and operations of ebXML registries, while the information model details how registries organize and index the data they represent. Also on 28 March ebXML released for review the draft trading partner profile and agreement specifications. The ebXML specifications carve out specific technically-oriented functions for trading partner information stored in registries (profiles) and the rules of the road for conducting e-business (agreements). As a result, ebXML uses the terms collaboration-protocol profiles and collaboration-protocol agreements to distinguish them from the more comprehensive trading partner profiles and agreements that contain much more than technical details. EbXML expects to finish its technical specifications in May 2000 at its last meeting in Vienna, Austria. At that time, the participants plan to take up the business process and core components specifications, the last two pieces of the technology still in development." For bibliographic details and other description, see (1) "ebXML Specifications Completed and Submitted for Quality Review Process", (2) "ebXML Integrates SOAP Into Messaging Services Specification."
[March 07, 2001] From Dave Winer: 37 SOAP 1.1 implementations. Last week we started a directory for SOAP 1.1 developers. One of the goals was to get a good list of all the implementations. This sub-directory is maintained by Paul Kulchenko, the developer of SOAP::Lite for Perl. [As of 2001-03-06] There are 37 implementations, we just learned of a new one today, from Mozilla: http://www.mozilla.org/xmlextras/.
[April 03, 2001] "Fun with SOAP Extensions." By Keith Ballinger and Rob Howard. From MSDN Online. March 27, 2001. ['As promised, in this month's column we're going to look at one of the more advanced, but cooler features of ASP.NET Web Services -- SOAP Extensions. For this month's column Keith Ballinger, a Program Manager for .NET Web Services, has offered to share some of his knowledge of this subject.'] " One of the more interesting things you can do with the .NET Frameworks Web Services technology is create SOAP Extensions. These extensions allow you to gain access to the actual network stream before it is deserialized into objects within the framework, and vice versa. SOAP Extensions allow developers to create very interesting applications on top of the core SOAP architecture found within .NET. For instance, you can implement an encryption algorithm on top of the Web Service call. Alternatively, you could implement a compression routine, or even create a SOAP Extension that will accept SOAP Attachments. How does this work? It's easy. First, I'd recommend that you review Rob Howard's earlier article 'Web Services with ASP.NET,' and then come back. You may also want to read 'SOAP in the Microsoft .NET Framework and Visual Studio.NET.' Basically, you need to do two things: (1) Create a class that derives from System.Web.Services.Protocols.SoapExtension (2) Create a class that derives from System.Web.Services.Protocols.SoapExtensionAttribute And you are almost done! Now, all that you have to do is create something interesting from you derived classes. OK, so maybe that isn't as easy as I make it sound. . . For this column, we will create an extension that records incoming and outgoing SOAP messages to our Web Service. This trace extension is useful for debugging when you really care about getting the SOAP message to look exactly the way you want it to look... SOAP Extensions are a very useful feature, and I hope to see a lot imaginative uses for them over the next few years."
[April 13, 2001] "Microsoft Updates SOAP toolkit, Further Supports Web Services Standards." By Tom Sullivan. In InfoWorld (April 11, 2001). "Microsoft on Wednesday announced a new version of its SOAP (Simple Object Access Protocol) toolkit and said that the forthcoming version of Windows will natively support SOAP. Version 2.0 of the toolkit supports the latest iteration of SOAP, Version 1.1, and, perhaps more important, the emerging standard for describing Web services, WSDL (Web Services Description Language). Microsoft unveiled the toolkit at the Web Services World show here. Developers using Visual Studio 6.0 tools in conjunction with the toolkit have a means to describe Web services as well as the transport mechanism for delivering services to devices that support SOAP and XML. Programmers also can add such functionality to existing COM (Component Object Model) applications or components, according to Redmond, Wash.-based Microsoft. In a surprise to no one because Microsoft is one of the key players driving the SOAP standard, Microsoft also stated that the next-generation Windows operating system, Windows XP, will natively support SOAP, thereby making it easier for developers to build Web services and for users to access them. Microsoft is not the only one backing SOAP. Earlier this week, SilverStream Software and Cape Clear both announced that their J2EE (Java 2 Enterprise Edition) application servers now support the protocol..." See discussion and references.
[March 30, 2001] "A Brief History of SOAP." By Don Box (DevelopMentor Inc.). March 30, 2001. "... For the most part, people have stopped arguing about SOAP. SOAP is what most people would consider a moderate success. The ideas of SOAP have been embraced by pretty much everyone at this point. The vendors are starting to support SOAP to one degree or another. There are even (unconfirmed) reports of interoperable implementations, but frankly, without interoperable metadata, I am not convinced wire-level interop is all that important. It looks like almost everyone will support WSDL until the W3C comes down with something better, so perhaps by the end of 3Q2001 we'll start to see really meaningful interop. SOAP's original intent was fairly modest: to codify how to send transient XML documents to invoke/trigger operations/responses on remote hosts. Because of our timing, we were forced to tackle issues that the schemas WG has since solved, which caused the S in SOAP to be somewhat lost. At this point in time, I firmly believe that only two things are needed for mid-term/long-term convergence: (1) The XML Schemas WG should address the issue of typed references and arrays. Adding support for these two 'synthetic' types would obviate the need for SOAP section 5. These constructs are broadly useful outside the scope of messaging/rpc applications, so it makes sense (to me at least) that the Schemas WG should address this. (2) Define the handful of additional constructs needed to tie the representational types from XML Schemas into operations and SUDS-style interfaces/WSDL-style portTypes. WSDL comes close enough to providing the necessary behavioral constructs to XML Schemas, and I am cautiously optimistic that something close to WSDL could subsume SOAP entirely. I strongly encourage you to study the WSDL spec and submit comments/improvements/errata so we can get convergence and interop in our lifetime..." Note 2001-04-05: Article reprinted on XML.com, April 4, 2001 as "an insider's view of the last three years of SOAP's development, its relationship with W3C XML Schema, and an assessment of where XML protocols should go next."
[March 30, 2001] "A Busy Developer's Guide to SOAP 1.1." By Dave Winer and Jake Savin (UserLand Software). March 28, 2001. "This specification documents a subset of SOAP 1.1 that forms a basis for interoperation between different environments much as the XML-RPC spec does. When we refer to 'SOAP' in this document we're referring to this subset of SOAP, not the full SOAP 1.1 specification. What is SOAP? For the purposes of this document, SOAP is a Remote Procedure Calling protocol that works over the Internet. A SOAP message is an HTTP-POST request. The body of the request is in XML. A procedure executes on the server and the value it returns is also formatted in XML. Procedure parameters and returned values can be scalars, numbers, strings, dates, etc.; and can also be complex record and list structures..." See also the political background [Dave's SOAP Journal, part 2] and the compatible validator running on SoapWare.Org.
[March 19, 2001] "Untangling the Web. SOAP Uses XML as a Simple And Elegant Solution that Automates B2B Transactions." By Greg Barish. In Intelligent Enterprise Volume 4, Number 5 (March 27, 2001), pages 38-43. "What B2B really needs is an easy way to integrate the back-end systems of participating organizations. And we're not just talking about a solution that involves each business maintaining multiple interfaces to that data. That's the way things work today and, to a large extent, visual interfaces have often proved to be unwieldy solutions. IT managers want a way to consolidate their data and functionality in one system that can be accessed over the Web by real people or automatically by software agents. The Simple Object Access Protocol, better known as SOAP, is aimed squarely at this data consolidation problem. Recently approved by the World Wide Web Consortium (W3C), SOAP uses XML and HTTP to define a component interoperability standard on the Web. SOAP enables Web applications to communicate with each other in a flexible, descriptive manner while enjoying the built-in network optimization and security of an HTTP-based messaging protocol. SOAP's foundations come from attempts to establish an XML-based form of RPC as well as Microsoft's own efforts to push its DCOM technology beyond Windows. SOAP increases the utility of Web applications by defining a standard for how information should be requested by remote components and how it should be described upon delivery. The key to achieving both of these goals is the use of XML to provide names to not only the functions and parameters being requested, but to the data being returned... SOAP simply and elegantly solves the major problems with both the HTML-based and DCOM/CORBA approaches by using XML over existing HTTP technology. Use of XML yields three important benefits: (1) XML makes the data self-describing and easy to parse. (2) Because XML and XSL separate data from presentation, useful data is distinguished from the rendering metadata. Thus, pages used as data sources for software agents can be reused for human consumption, eliminating the need for redundant data views. (3) XML enables complicated data structures (such as lists or lists of lists) to be easily encoded using flexible serialization rules. Using XML for encoding data also represents an alternative to ANSI-based Electronic Data Interchange (EDI). While EDI has been successfully used for years, it does have its problems. For example, it is cryptic and difficult to debug. Also, it is more expensive and requires the server and client to have special software installed to handle the format. What's more, EDI over HTTP is problematic: It doesn't completely support important HTTP encryption and authentication standards, and thus secure transactions are limited or simply not possible. In contrast, SOAP keeps things simple. It's extensible, the data is self-describing, simple to debug, and it can enjoy the benefits of HTTP-based security methods. While a SOAP message requires more bandwidth than an EDI message, bandwidth has become less of a concern as the Internet itself becomes faster - particularly between businesses that can afford high-speed network access. Finally, you can deploy SOAP over a number of protocols, including HTTP. This capability is important because it allows the firewall issues to be avoided and retains the optimizations that have been built into HTTP... While SOAP messages consist of XML- compliant encoding, they can be also be communicated via alternative transport mechanisms, such as RPC. Communication via RPC points back to the history of SOAP in its XML-RPC form. XML- based RPC cuts to the chase: It says, "Let's forget all this stuff about Web servers and Web clients, we just want distributed objects to be interoperable between disparate systems." SOAP over HTTP, in contrast, is a more general form of object-to-object (or agent-to-agent) communication over the Internet. It assumes what is minimally necessary: that objects are accessible via HTTP and that the data they return is self-describing."
[February 22, 2001] ebXML Integrates SOAP Into Messaging Services Specification. An announcement from UN/CEFACT and OASIS describes efforts now underway to "integrate the SOAP 1.1 and SOAP with Attachments specifications into the ebXML Messaging Specification. SOAP (Simple Object Access Protocol) is designed to provide the underpinnings for messaging requirements. This development by ebXML will result in an open, widely adopted global standard for reliably transporting electronic business messages over the Internet. The ebXML Messaging Specification encompasses a set of services and protocols that allow an electronic business client to request services from electronic business servers over any application-level transport protocol, including SMTP, HTTP and others. ebXML defines a general-purpose message, with a header that supports multiple payloads, while allowing digital signatures within and among related messages. Although the header is XML, the body of the message may be XML, MIME or virtually anything digital." [details]
[February 09, 2001] Apache XML Project Releases Apache SOAP Version 2.1. A communiqué from James Snell announces the release of Apache SOAP Version 2.1. Apache SOAP ("Simple Object Access Protocol") is an implementation of the SOAP submission to W3C. It is based on, and supersedes, the IBM SOAP4J implementation. Apache SOAP v2.1 has been released and is available for download in a Zipfile. New features in version 2.1 include: (1) Added message handling support; (2) Added configurable error handling mechanism; (3) Added pluggable provider support; (4) Added client-side HTTPS support; (5) Added HTTP proxy support; (6) Added HTTP basic authentication support; (7) Added support for SOAP Messages with Attachments; (8) Introduced SOAPContext; (9) Added support for transport hooks; (10) Added SSL support; (11) Reduced dependency on xsi:type for deserialization; (12) Added soap configuration file; (13) Added pluggable configuration manager; (14) Added support for international character sets; (15) Added support for default serialization/deserialization of: Hashtable (as xmlsoap:Map), Date (as xsd:timeInstant) GregorianCalendar (as xsd:date).
[February 14, 2001] "Soapbox: Why I'm using SOAP. One developer tells why he's feeling sold on SOAP." By Benoît Marchal (Software Engineer, Pineapplesoft). IBM DeveloperWorks XML Library. February 2001. ['In the XML zone's new opinion department, Benont Marchal steps up on the soapbox to tell why SOAP is winning him over. SOAP's selling point is its simplicity, Marchal says. Because the new protocol builds on familiar technologies, in particular the Web server and XML, it's relatively easy for developers to design and deploy SOAP servers. Learn when its best to consider and use SOAP.] "SOAP, the Simple Object Access Protocol, is a new protocol engineered by IBM, Microsoft, Userland, and DevelopMentor to support remote procedure calls (and other sophisticated requests) over HTTP. SOAP draws from two distinct environments. Built on HTTP and XML, SOAP aims to be as simple as the Web. Yet it targets object-oriented remote procedure calls borrowed from CORBA and DCOM. I think that the major benefit of adopting SOAP is that it builds on a Web server. Therefore, to understand SOAP, one needs to start with Web servers. Modern Web servers -- and in particular application servers like WebSphere, WebLogic, or ColdFusion -- are powerful development platforms. They are optimized to process requests efficiently. SOAP is an attempt to turn these Web servers into object servers. By object servers I mean the middle-tier servers in a three-tier architecture. SOAP supports object servers this way by adding a thin XML layer over HTTP... I started using SOAP and I realized that its major benefit is that it builds on the Web. Granted, SOAP is more limited than CORBA and DCOM. For example, it offers limited support for object-oriented concepts like inheritance, and it lacks transaction management (as offered by MTS with DCOM or OTS with CORBA). However, what it lacks in power, SOAP more than compensates for in its simplicity. For example, since SOAP uses HTTP, SOAP servers are Web servers. Most businesses have significant experience in deploying Web servers or developing Web applications. With SOAP, they can leverage that experience for object servers. I can think of only two drawbacks to SOAP but, depending on the project, they can be significant. First, SOAP is not an official standard yet. The W3C has launched its own Protocol Activity, and there is no guarantee that the result will be compatible with SOAP. Second, SOAP is new, and it lacks some of the tools common for CORBA or DCOM. In particular, there is no transaction management with SOAP. This is not an inherent limitation of SOAP; I'm sure transaction managers will eventually appear on the market, but they are not available yet."
[February 09, 2001] IBM and Microsoft Submit Specification for SOAP Security Extensions. The W3C acknowledged submission of a note by International Business Machines Corporation and Microsoft Corporation for SOAP Security Extensions: Digital Signature. Reference: W3C NOTE 06-February-2001, by Allen Brown (Microsoft), Barbara Fox (Microsoft), Satoshi Hada (IBM), Brian LaMacchia (Microsoft), Hiroshi Maruyama (IBM). Submitted by David Fallside (IBM) and David Turner (Microsoft Corporation). Document abstract: "This document specifies the syntax and processing rules of a SOAP header entry to carry digital signature information within a SOAP 1.1 Envelope." Rationale: "The motivation for this Note is to propose a standard way to use the XML Digital Signature syntax to sign SOAP 1.1 messages. We define a SOAP header entry <SOAP-SEC:Signature> for this purpose. We also propose the definition of an extensible namespace for adding security features to the SOAP header. By extensible we mean that new elements can be added to the schema overtime but elements in the schema will not change. It is our intention that other security features, such as confidentiality of SOAP 1.1 messages, will be added within this namespace as appropriate standards, such as forthcoming XML Encryption, become available. What we specifically defer to another Note or working group is the definition of an authentication protocol for SOAP. By 'protocol', we mean any expectation of processing by the recipient of a signed/encrypted message." According to the text of the submission, "The co-submitters of this specification believe strongly in the need for standardized protocols to support interoperable interactions with remote Web-based services. Although there are a number of similar efforts underway, we feel the W3C is well suited to co-ordinate work in this area. We propose the formation of a new working group within the existing XML Protocol Activity or the inclusion of this activity in the XML Protocol Working Group to continue the evolution of this proposal. It is essential that security be part of the interoperability goals within XML messaging." Joseph Reagle (W3C Team Contact for the XML Signature Working Group) supplied this explanation and disposition in the W3C Staff comment: "The SOAP-SEC submission specifies how to use XML Signature with SOAP via envelop headers. First, it imports two optional envelop headers for use in SOAP-SEC: 'actor' can be used to indicate the recipient of a header element; 'mustUnderstand' indicates whether an application must attempt validation of the enclosed Signature. While the example provided is of a detached signature, (<Signature> is a sibling of the element signed), enveloping and enveloped signatures are permitted, where <Signature> is an ancestor or descendant respectively. XML Signature can work with arbitrary content, but its use with these SOAP headers might be of interest to the XML Protocol Working Group as a usage scenario for mandatory/optional signature validation over messages. Second, the submission defines a global attribute 'ID' in the SOAP-SEC namespace that is defined to always be of type ID. This can be used by applications as a referent of a Signature to unambiguously identify and reference elements. W3C Working Groups, especially XML Signature, might consider generalizing and standardizing this approach for use by all XML applications. This submission will be referred to the attention of the XML Protocol Working Group and the XML Signature Working Group email lists for the reasons stated above."
[February 02, 2001] SOAP 1.1 Validator Web Application. Dave Winer (UserLand Software Inc.) announced the availability of an online SOAP 1.1 Validator Web Application. "This server is running Frontier 6.2, with our SOAP 1.1 support. We used the validator approach with much success in shaking out incompatibilities in XML-RPC implementations. Now that SOAP is starting to be widely deployed it'll be interesting to know if we're all talking the same language, or how far apart we are... The application calls a suite of scripts running on your server, and tells you whether your server is working in accordance with the SOAP 1.1 specification. It's patterned after a similar validator we did for XML-RPC."
[February 05, 2001] "SOAP/XML Must Mature Quickly." By Jim Fawcette. In XML Magazine Volume 2, Number 1 (February/March 2001). ['Corporate interest in XML and SOAP has never been higher, but the danger of fragmentation has never been greater. What needs to happen before the enterprise accepts the new technologies? And to ensure interoperability? Find out what the co-founder and Chairman of Iona Technologies thinks.'] "chairman of Iona Technologies, Dr. Christopher J. Horn runs a company whose existence depends on helping corporations tie together many technologies, from legacy systems to the bleeding edge of object-oriented programming. This makes Horn well qualified to put the emerging landscape in perspective -- from XML and SOAP, to Java 2 Enterprise Edition, from wireless to peer-to-peer networking. FTP, Inc. President James Fawcette traveled to Iona's Dublin, Ireland, headquarters to interview Horn about these technologies and their importance in the corporate middleware market. Listen to Part I and Part II of the full audio stream of this interview... It is in the early days; nevertheless, we see widespread corporate interest in employing SOAP for Internet and extranet use rather than for intranets -- more for applications that are outward looking from the corporation. XML and SOAP are more verbose than binary technologies such as CORBA or Enterprise Java Beans (EJB), where one gets a stronger, better-performance coupling... The basic technology is being extended to handle issues such as transactions and security. Until enterprise capability has been demonstrated in SOAP, there will be resistance to widespread use. It is coming, though. This is much like 1993 when CORBA was an emerging technology. A few pioneers were willing to adopt it, and that opened the floodgates in 1995, '96, and '97. We can expect widespread adoption of XML and SOAP in 12-18 months... In the CORBA specification, security levels vary from straightforward SSL to full-scale authentication, including the ability to handle repudiation of access rights. Similarly, there are sophisticated transaction models around full two-phase commit. For SOAP, in most applications, a simpler, lighter-weight, high-performance model will suffice. But some less widely used applications require more. Quality of service requirements also have different levels, from low-band sync and rollover to synchronous and asynchronous messaging, publish-and-subscribe, and notification. These are just different communications paradigms underlying presentation syntax of something like SOAP. You could say that this doesn't really matter in an XML-based system like SOAP, but in practice, we feel that there are things you can do to make capabilities such as publish-and-subscribe easier to use for the developer..."
[February 08, 2001] SoapRMI from 'Extreme! Computing'. From the IU Extreme! Computing Group: "SOAP RMI is our implementation of RMI [Remote Method Invocation] based on nanoSOAP; it's our implementation of a simple SOAPv1.0 serialization and deserialization mechanism. SOAP RMI uses an XML-Schema specification of the server interface to generate the associated stubs and skeletons. A remote object reference is an HTTP URL along with information that uniquely identifies the instance. The stubs and skeletons do not directly interact with the SOAP implementation, but instead use a communication object which is an abstraction that helps hide the underlying implementation of SOAP. This design is useful as it allows run-time insertion of different SOAP implementations. We have created a mailing list soaprmi@extreme.indiana.edu for the purpose of bug reporting and discussion about our SoapRMI. You can subscribe to it using Mailman interface or just browse list archives... SoapRMI-Events sketches how events can work with SoapRMI 1.1. A project research paper addresses the relevant questions; "Requirements for and Evaluation of RMI Protocols for Scientific Computing," by Madhusudhan Govindaraju, Aleksander Slominski, Venkatesh Choppella, Randall Bramley, and Dennis Gannon (Department of Computer Science,Indiana University, Bloomington, IN). This paper, accepted for SuperComputing 2000, asks: (1) What is the raw performance of SOAP when used as a foundation for a RMI system? (2) How does SOAP performance compare with that of Java RMI and Nexus? (3) Where are the bottlenecks in SOAP performance? Which are removable through better implementations, and which are inherent in the protocol itself? (4) Can a dynamic multi-protocol system be designed that achieves the benefits of several runtime systems? The paper addresses these questions and shows that SOAP can be used to build a reliable, multi-protocol RMI system that can access desktop component technology like Microsoft COM and other non-Java software components. However, when additional performance is needed a multi-protocol approach allows a faster, more specialized protocol to be dynamically inserted to move data. Several efforts have been started to extend SOAP to have security and higher performance. You may download beta version of XML Pull Parser. Pull Parser 1.1 was designed for and it should be optimal for applications that require very small size XML parser - the jar file with compiled classes is around 20KB. Its pull parsing model is especially well suited for unmarshalling complex data structures from XML. Before using pleease read API documentation and browse through source code. Full source code both for Java and C++ versions is available under open source license... Our first implementation of SOAPRMI is now available. It uses SOAP 1.0 serialization but is not fully SOAP 1.0 complaint. We are now finishing next verion of SOAPRMI that will be interoperable with Apache SOAP and is implemented both for Java and C++. It is available as ZIP or JAR file. SoapOpera: We are currently working on RMI based on SoapC++ that will interoperate with the RMI based on SoapJava. We will update this page as soon as we are done with our implementation..."
[February 09, 2001] "Requirements for and Evaluation of RMI Protocols for Scientific Computing." By Madhusudhan Govindaraju, Aleksander Slominski, Venkatesh Choppella, Randall Bramley, and Dennis Gannon (Department of Computer Science, Indiana University, Bloomington, IN). From the SoapTeam: Extreme Computing Lab. 2000-08-17. "Distributed software component architectures provide a promising approach to the problem of building large scale, scientific Grid applications. Communication in these component architectures is based on Remote Method Invocation (RMI) protocols that allow one software component to invoke the functionality of another. Examples include Java remote method invocation (Java RMI) and the new Simple Object Access Protocol (SOAP). SOAP has the advantage that many programming languages and component frameworks can support it. This paper describes experiments showing that SOAP by itself is not efficient enough for large scale scientific applications. However, when it is embedded in a multi-protocol RMI framework, SOAP can be effectively used as a universal control protocol, that can be swapped out by faster, more special purpose protocols when large data transfer speeds are needed." See the group's SoapRMI: "SOAP RMI is our implementation of RMI based on nanoSOAP, our implementation of a simple SOAPv1.0 serialization and deserialization mechanism. SOAP RMI uses an XML-Schema specification of the server interface to generate the associated stubs and skeletons. A remote object reference is an HTTP URL along with information that uniquely identifies the instance. The stubs and skeletons do not directly interact with the SOAP implementation, but instead use a communication object which is an abstraction that helps hide the underlying implementation of SOAP. This design is useful as it allows run-time insertion of different SOAP implementations."
[January 16, 2001] "W3C Acknowledges SOAP Extension Co-Submitted by WebMethods, Microsoft and HP. Extension of the SOAP 1.1 Specification Adds Functionality Needed for More Efficient B2B Transactions." - "webMethods, Inc., a leading provider of business-to-business integration (B2Bi) solutions, today announced that the World Wide Web Consortium (W3C) has acknowledged the co-submission of an extension to the Simple Object Access Protocol 1.1 (SOAP 1.1) specification. The specification extension, SOAP Messages with Attachments, adds to the capabilities of SOAP 1.1 to allow non-textual data such as catalog images, handwritten signatures, blueprints and circuit diagrams, to be effectively included in and transferred with XML documents. 'We are pleased to be invited by Microsoft to participate in this submission as it reinforces our leadership position in the development and support of open standards and protocols that allow companies to overcome traditional integration challenges,' said Stewart Allen, vice president of Architecture and Technology for webMethods, Inc. 'SOAP 1.1 and this extension provide a sufficiently light-weight protocol that small and mid-sized companies can use to enable B2B operations. We will continue to track this standard in our product line as we believe it will play a significant role in accelerating the widespread adoption of B2B.' The SOAP 1.1 specification created by Microsoft, IBM, Lotus Development Corp., DevelopMentor, UserLand Software and other W3C members uses XML and HTTP to provide a common messaging protocol to link applications and services anywhere on the Internet. SOAP 1.1 facilitates the transfer of information by defining a framework for describing what is in a message and how to process it. webMethods joined other W3C members Microsoft, IBM, Commerce One, Hewlett-Packard, and IONA Technologies in submitting the SOAP 1.1 extension. As a result of the specification extension, companies can use SOAP 1.1 to transfer more types of data from one application to another, eliminating steps and streamlining processes. The submitted extension does not require any changes to the SOAP 1.1 specification already acknowledged by the W3C. The acknowledgment of the extension from the W3C does not imply endorsement by the W3C... webMethods, Inc. is a leading provider of software solutions for business-to-business integration (B2Bi). As the only company providing seamless B2Bi across the Internet and throughout the extended enterprise, webMethods provides Global 2000 companies and B2B marketplaces with a complete, end-to-end solution for integrating customers, suppliers and partners into real-time B2B trading networks, while also increasing internal operational efficiencies. The webMethods product family allows companies to create new revenue opportunities, strengthen relationships with customers, substantially reduce supply chain inefficiencies, and streamline internal business processes."
[January 16, 2001] "Microsoft SOAP Toolkit: Version 2.0 and Version 1.0." From Microsoft. January 02, 2001. ['Microsoft SOAP Toolkit Update. Now available are new versions of the SOAP Toolkit for developing Web Services with today's tools.'] "The Microsoft SOAP Toolkit version 1.0 is an unsupported MSDN sample. While some of you have already used the MSDN code to solve real problems you face today, most of you approached the MSDN sample in the way it was intended -- to experiment with Web Services. Over the past few months of successful experimentation with Web Services, you have provided us with feedback that you're ready to move forward from the experimentation phase to begin developing and deploying enterprise-scale applications that implement and consume Web Services. Therefore, starting with the SOAP Toolkit version 2.0, Microsoft will deliver the SOAP infrastructure you need to build production Web Services. The Microsoft SOAP Toolkit version 2.0 is developed and supported by the same team that delivers the Microsoft XML Parser (MSXML), and represents core Web Services technology that will be used across a number of Microsoft's own software products. Thus, having fulfilled its primary purpose, the December release of SOAP Toolkit version 1.0 is the final update of the MSDN sample. The Microsoft SOAP Toolkit version 2.0 adds complete support for the Web Services Description Language (WSDL) 1.0 Specification, Universal Description, Discovery and Integration (UDDI), and the SOAP Specification version 1.1. While the Beta 1 release doesn't include full support of these specifications, subsequent beta releases will fill out the missing functionality with a feature-complete version delivered by the end of the first quarter of 2001. Microsoft is also announcing that the final release of SOAP Toolkit version 2.0 will be fully supported by Microsoft product support. With the SOAP Toolkit version 2.0, Microsoft has responded to customer requests to make some critical architectural changes, primarily to support the latest level of standards specifications and to implement a programming model designed for rapid developer productivity. These changes might require that you modify some of the existing application code that you've written using the SOAP Toolkit version 1.0 sample code."
[January 03, 2001] Microsoft Releases Updated SOAP Toolkit and Web Services Behavior Application. From a recent company announcement: "Microsoft Corporation today unveiled two SOAP-related technologies to help developers build and use Web Services -- applications made available over the Web via Internet-standard XML, SOAP and UDDI. The first tool is the beta release of the Microsoft SOAP Toolkit Version 2.0, which provides developers using Microsoft Visual Studio 6.0 with rapid Web Services development capabilities for production-ready applications. The second is Web Services Behavior for the Microsoft Internet Explorer browser software, enabling Web developers to aggregate Web Services from multiple Web pages. Both are key technologies for facilitating the creation and integration of Web Services, the programmable building blocks that form the next-generation applications of the Internet. To make it easy for developers to build and use Web Services without having to learn the intricacies of SOAP or XML, Microsoft last summer announced Version 1.0 of the SOAP Toolkit for Visual Studio 6.0. With Version 2.0, Microsoft is making significant usability and architectural enhancements to track to the latest Web Services standards including full support for the Web Services Description Language (WSDL), Universal Description, Discovery and Integration (UDDI) and SOAP 1.1. By delivering greater development productivity and by supporting the latest versions of these standards, Microsoft is continuing its leadership in delivering development and runtime support for Web Services. The final release of Version 2.0 will provide developers with the tools and technologies that will enable them to deploy enterprise-scale applications with forward compatibility with the Microsoft .NET platform. The toolkit will work with additional operating systems, including Windows 2000, Windows NT 4.0, Windows 98 and Windows Me, and will be fully supported by Microsoft Product Support Services... Web Services support for Internet Explorer provides a transparent mechanism for developers to easily use Web Services from scripts in a Web page to improve many aspects of traditional database-drive Web page design. This support, compatible with all major SOAP implementations available today, enables developers to easily build unique applications from multiple Web Services that offer more personalized, more targeted user experiences such as improving the end-user browsing experience by minimizing time-consuming full page refreshes. By releasing this behavior, Microsoft is the first company to deliver Web Services capabilities directly to a Web browser, bringing the power of aggregating applications across the Internet to all users and developers. Both the beta release of the Microsoft SOAP Toolkit Version 2.0 and the Web Services Behavior for Internet Explorer 5.0 are available for free download." See the announcement for other particulars: "Microsoft Updates Tools for Building Web Services With Visual Studio and Internet Explorer. Updated SOAP Toolkit and Web Services Plug-In for Internet Explorer Offer More Ways to Build and Use Web Services."
[January 25, 2001] "IT and the NOW Economy. XML technologies can provide more options and flexibility in enterprise messaging." By Michael Hudson and Craig Miller (Blueprint Technologies). In Intelligent Enterprise Volume 4, Number 2 (January 30, 2001), pages 24-29. "...No single standard for exchanging data exists, and most of the solutions you've considered purchasing are really batch-oriented systems that lack the direct interactivity you require. One system may directly invoke the functionality of an application on another in what is known as a remote procedure call (RPC), or two systems may collaborate by exchanging data through brokering mechanisms that are often referred to as message-oriented middleware (MOM). Traditionally, however, solutions in this market have usually been much more at home in homogenous, closed LAN-based environments. Solutions have often been expensive, mainframe-oriented, or bound to a specific platform or programming language. RPC mechanisms illustrate the point vividly. Traditional RPC mechanisms included large-scale solutions such as the Distributed Computing Environment (DCE), and later, object-oriented RPC architectures such as Microsoft's Distributed Component Object Model (DCOM), the Common Object Request Broker Architecture (CORBA), or the Remote Method Invocation (RMI) APIs supported by Java. All of these technologies have great merit and have served as the basis of many enterprise success stories. However, there are significant obstacles to their widespread adoption in open environments. Each component architecture is commonly tied to either a platform (DCOM), a programming language (RMI), or a small number of solution vendors. Reliable deployment of these technologies often requires installation of large, complex client-side libraries in the case of DCOM and CORBA. The greatest challenge for many of these technologies, however, are firewalls and proxy servers. Many firewall solutions employ a combination of packet filtering and network address translation to provide security. For instance, your company may block all traffic except that on the default HTTP port 80; moreover, many firewalls inspect the packets themselves to determine whether they constitute valid HTTP traffic. Finally, the actual target of an RPC call may have no publicly routable IP address; instead, packets destined for it are translated by a proxy mechanism to a private network address behind the firewall. These security mechanisms often foil RPC mechanisms, which often rely on other ports (typically, port 135 and a range of higher-numbered ports) and direct linkage to a known routable IP address. On the other hand, extensible markup language (XML) is extremely well-suited for expressing complex data types, such as arrays, master-detail relationships, records, and the like. Like HTTP, it is an open and platform-independent standard that has rapidly achieved widespread adoption. Perhaps it is not surprising that efforts are underway to link the two standards. The best known initiative to date is the Simple Object Access Protocol (SOAP). The SOAP protocol is the brainchild of many organizations, notably Microsoft, IBM, and others. Like XML, which is in part a greatly simplified descendant of the older SGML language, SOAP embodies a 'less is more' viewpoint. One of its architects, Don Box, describes it as a 'no new technology' approach. SOAP is merely a specification -- to be precise, an XML implementation language with a specific schema. It packages the information contained within a remote procedure call and provides standards for error handling. The SOAP content specifies the resource on the server responsible for performing the invoked functionality, known as an endpoint. But how it is carried out is entirely at the server's discretion. As with all XML content, the schema defining the structure of the specific RPC call between client and server is referenced as an XML namespace. The content of the call (to get the last trading price of a stock with the symbol DIS) is contained within the SOAP 'body', which is in turn contained within a SOAP 'envelope' that provides the XML schema reference for the SOAP standard itself... Microsoft has made SOAP a critical technology for its .Net initiative; SOAP is the underlying RPC protocol that links events on HTML forms to specific triggers on Microsoft servers. Java and Apache tools for SOAP now exist as well. Whether SOAP will ultimately prevail as the dominant RPC mechanism in the Internet era remains to be seen..."
[December 01, 2000] "SOAP Toolkit for Visual Studio 6.0 November Release." By [Staff]. From MSDN (November 21, 2000). The November 2000 release of the SOAP Toolkit for Microsoft Visual Studio 6.0 is a available for download; see the documentation. "The November 2000 release of the SOAP Toolkit for Microsoft Visual Studio 6.0 offers improved security features through the use of the SSL protocol for message transmission over the Internet. This update includes added support for several authentication mechansims. The much-anticipated November 2000 release of the SOAP Toolkit for Visual Studio 6.0 has improved security features by making use of the commonly used protocol SSL (Secure Socket Layer) for message transmission over the Internet. This latest release of the SOAP Toolkit has added support for several authentication mechanisms, including: (1) Sending and receiving messages over SSL (2) Basic authentication (3) Basic over SSL (4) Integrated Windows authentication (5) Client and Server certificates (6) Authenticating a client to an HTTP proxy This is an exciting addition to the SOAP Toolkit because, in addition to authentication, the SSL protocol adds data integrity and data privacy to HTTP as well as brokering access to only those authorized to use internal business logic and data stores used to implement a Web Service. Sending SOAP messages with the SSL security features implemented assures that the messages cannot be read or modified while in transit. If you are using a protocol such as HTTP, the client credentials will be passed as plain text. By utilizing the new SSL features instead of HTTP, you can be sure that client credentials will be securely encrypted. Developers of Web Services can utilize the robust new security features of the SOAP Toolkit to balance their security and performance needs. SSL produces significantly slower performance than using a protocol such as HTTP, but it is possible to selectively use SSL for only those operations of a Web Service that have heavy security needs, thus minimizing performance overhead while maximizing Web Service integrity. Additional information is available in the release notes included in the download. Please note that the SOAP Toolkit requires Microsoft Windows 2000 or Windows NT 4.0 SP6, as well as Visual Studio 6.0 SP4 to be fully functional."
[November 25, 2000] "SOAP in the Microsoft .NET Framework and Visual Studio.NET." By Keith Ballinger, Jonathan Hawkins, and Pranish Kumar. From MSDN Online Library. November 2000. ['The article discusses the SOAP offerings in .NET Remoting, ASP.NET Web Services, and ATL Web Services. The primary goal of this article is to provide a broad perspective of the SOAP offerings in the .NET Frameworks and Visual Studio.NET. The secondary goal is to provide a roadmap for customers about which path to use when starting to build an application that uses SOAP.'] "The Microsoft .NET Framework and Microsoft Visual Studio.NET take advantage of XML and SOAP technologies to allow developers to create solutions with reach. SOAP is a simple and lightweight protocol with wide industry support. It is useful and usable for a wide variety of applications. SOAP and the .NET Frameworks are an easy and natural fit. SOAP was designed from the ground up to be an extremely simple protocol that can be implemented in a variety of ways for a variety of different needs. Many other companies have produced implementations, including IBM, Develop Mentor, and Userland, as well as Microsoft. There are several key technologies in the framework that use SOAP. Each of these features solves common problems that developers encounter when creating SOAP-based solutions. These areas are .NET Remoting, ASP.NET Web Services, and ATL Web Services. These features share a number of common technologies and characteristics: (1) XML for message generation and consumption. (2) SOAP 1.1 compliance, including Section 5 SOAP encoding. This enables strong SOAP interoperability with other SOAP implementations. (3) XML-fidelity (non-section 5 SOAP encoding) for a very disconnected model. (4) WSDL (a form of XML Schema) for Description. (5) Scaling out using a stateless programming model. (6) An excellent development environment with Visual Studio.NET..."
[September 20, 2000] An announcement from the Object Management Group summarizes a recent OMG Technical Meeting in which the Platform Technology Committee (PTC) "initiated work on a standard that will integrate the new protocol SOAP with OMG's CORBA architecture. "SOAP (Simple Object Access Protocol) transmits business data expressed in the Extensible Markup Language (XML) over the widely-used web protocol HTTP. In order to take full advantage of this new protocol, enterprises need to integrate it with their existing computing infrastructure. When complete less than a year from now, the new standard will enable this integration by allowing SOAP clients to invoke CORBA servers, and CORBA clients and servers to interoperate using SOAP. Also in the infrastructure arena, the PTC initiated efforts to standardize methods to transmit CORBA network packets through firewalls, and to adapt Real-Time Object Request Brokers to emit alternative protocols needed for, e.g., telecommunications or other Real-Time applications. The PTC also initiated efforts to standardize a mapping from OMG IDL (Interface Definition Language) to WMLscript, a scripting language based on the Wireless Markup Language, and to standardize an activation framework for persistent CORBA servers." The new RFP is published as CORBA/SOAP Interworking Request For Proposal. Reference: OMG Document 'orbos/00-09-07'; submissions due February 5, 2001. "The RFP solicits proposals for (1) support of CORBA semantics over SOAP (2) enabling native SOAP clients to access CORBA services. Description and scope: "CORBA is a widely deployed distributed systems infrastructure that is currently used as an enabling technology for web integration (intranet, internet, and extranet). SOAP (Simple Object Access Protocol) is an evolving specification being developed under the auspices of the W3C. It is anticipated that SOAP will be widely deployed in the future for use in B2B interactions. It is important that there be a seamless integration between the CORBA and SOAP infrastructures which would enable CORBA invocations to be carried using SOAP. The scope of proposals shall be limited to defining a protocol (marshaling format and message exchange state machine) and the limited object model mappings implicit in the mandatory requirements. Mappings between object models, the definition of a 'service description language', and mappings between SOAP infrastructure services and CORBA services, such as Naming, are out of scope of this RFP. Proposals are expected to track and take into account ongoing work within the W3C, e.g., the proposed XML-PC Working Group. [Specifically:] proposals shall: (a) support the full set of IDL types defined in CORBA 2.4; (b) support the semantics of CORBA invocations, including service contexts; (c) use the SOAP extensibility framework (without changing the SOAP protocol) and track ongoing W3C work; (d) define an IOR profile for SOAP; (e) provide an interoperability solution that permits native SOAP clients to make invocations that are processed by CORBA servers; that is, present a SOAP view, (as defined in CORBA 2.4 section 17.2.3) of a CORBA service to a CORBA unaware SOAP client..." See also in connection with this new RFP: (1) the paper Proposed CORBA SOAP RFP, by Jeff Mischkinsky (Persistence Software), and (2) A Discussion Paper: Simple CORBA Object Access Protocol (SCOAP) (with slides). By BEA Systems, Inc., Financial Toolsmiths AB, Hewlett Packard Company, International Business Machines Corporation, Iona Technologies, Inc., Object Oriented Concepts, Inc., Persistence Software, Inc., Rogue Wave Software, Inc., and Sun Microsystems, Inc. Reference: OMG TC Document 'orbos/00-09-03'. 78 pages. Chapter 3, 'IDL-to-XMLSchema Mapping' describes the XML Schema that is used to describe IDL types; Chapter 8, 'Mapping XML Schema Types to IDL' describes how to.map certain XML Schema datatypes to IDL. "This work was undertaken as a 'proof of concept' (to ourselves and others) that there exists at least one reasonable and viable way to integrate CORBA and SOAP. In addition, its purpose is to spark discussions and debate about this and other approaches to the problem space..." See "XML and CORBA."
[September 07, 2000] XMethods SOAP Registry. "By listing publicly accessible SOAP services, we hope this site will help to catalyze the creation, deployment, and use of more services. Our intention is to be as implementation-agnostic as possible, although much of our current content focuses on Apache SOAP. While we do enable pointers to SDL, SCL, or NASSL files, we have made the general description section freeform so a service owner can describe a service in whatever way is most appropriate. If you know of a service that should be listed, please add it to the list. We are willing to host services on our servers for free if you do not have your own hosting capability. Please contact us for more information. This site is maintained by Tony Hong, James Hong, and Mahipal Kante. . . Standards like XML and SOAP make it easier for systems to make remote procedure calls across the Internet. For example, corporate systems will allow customers to make calls that check real-time inventory levels. Your car's navigation system will check local traffic reports when planning the quickest route. These are all 'services'. This site helps you find services that are publicly accessible. You can invoke services from within your own application using the information provided in each listing. If available, you can download sample code demonstrating how to invoke a service. We have a primer on writing a client application."
[December 06, 2000] Microsoft Releases XML for Analysis Specification. Microsoft recently announced an 'XML for Analysis Specification' as a protocol for extending business intelligence to Web Services. This specification is now available for download from the Universal Data Access Web Site. It is open for public feedback from 10/30/00 to 1/15/01; an updated specification will be posted approximately 1/30/01. From the text of the press release: "Microsoft Corporation today announced the release of the beta specification for XML for Analysis -- a new protocol that extends the Microsoft business intelligence strategy to the Microsoft .NET vision of Web services, allowing application developers to provide analytic capabilities to any client on any device or platform using any programming language. Built on HTTP, XML and SOAP and with more than 50 industry players having been instrumental in its development, XML for Analysis is being hailed by developers of analytical tools as the first cross-platform solution designed to address the unique challenges of analytical data access and manipulation. As an extension to OLE DB for OLAP and OLE DB for Data Mining, XML for Analysis uses the Internet as the platform for building analytical applications from diverse sources of data, thus enabling developers to provide better Web services for analytic data. Corporations can now allow trading partners, customers and suppliers to access data easily and securely over the Web without worrying about client operating system, application language or middleware compatibility issues. XML for Analysis expands access to business intelligence by increasing the flexibility for developers to incorporate analytical data within applications that reside remotely on the Internet, or even those that are hosted by another company. Users can achieve a new level of pervasive data analysis because they have access to data from any client ranging from a PDA to an Internet-enabled phone, interactive TV device, laptop computer or PC. XML for Analysis is a fully compatible advancement to the OLE DB for OLAP and OLE DB for Data Mining protocols. Thousands of applications developers, representing hundreds of third-party products currently using the existing OLE DB for OLAP and OLE DB for Data Mining standards, can quickly and easily upgrade to XML for Analysis. Over 100 developers and architects from more than 50 companies were involved in the review process of the XML for Analysis specification. These include Adaytum Inc., AlphaBlox Corp., Andersen Consulting, ANGOSS, Brio Technology Inc., Broadbase Software, Business Objects, Cognos Corp., Knosys Inc., Maximal Software Inc., PricewaterhouseCoopers, SAP Americas Inc., SAS Institute Inc., Seagate Software, SPSS Inc., Symmetry and Walker Interactive Systems Inc. Developer feedback was captured during a preview event held at the Microsoft campus in late October and via a newsgroup facility... 'Web-based services for e-business are definitely on the rise, and -- in terms of business intelligence -- this means accessing analytic databases hosted over the Internet,' said Philip Russom, research director of business intelligence at Hurwitz Group. 'Microsoft's XML for Analysis addresses this need with a protocol that's based on Internet standards and optimized for interaction with Web services. Unlike newer attempts at a standard protocol, XML for Analysis is based on OLE DB for OLAP, which has seen almost three years of industry review, IT implementation and support by third-party analytic software. And it's not just for OLAP; XML for Analysis also supports Web-based data mining'." For other details, see the full text of the announcement: "Microsoft Offers XML-Based Protocol for Extending Business Intelligence to Web Services. Industry Rallies Around Platform-Independent XML for Analysis Specification."
[July 11, 2000] "Microsoft Publishes Key Specifications for Web Services. Adds to SOAP Technologies With SOAP Contract Language and Discovery Specifications." - "Today at the Professional Developers Conference (PDC) 2000, Microsoft Corp. published preliminary versions of two core specifications for creating and using Web services, adding to the SOAP group of Extensible Markup Language (XML) interoperability technologies. The two specifications, published on the MSDN developer program Web site, are the SOAP Contract Language (SCL), which describes the capabilities of Web services, and SOAP Discovery, which provides rules for locating Web services. Together, these additions strengthen the interoperability capabilities defined in the SOAP specification and provide the standards-based foundation underlying the entire Microsoft .NET Platform. 'These two additions to the SOAP technologies enhance developers' ability to build a Web services infrastructure,' said Andrew Layman, Web services architect at Microsoft. 'By publishing these specifications openly, Microsoft is demonstrating a continuing commitment to working with the development community to make Web services ubiquitous.' SOAP is an open standards-based interoperability protocol that uses XML to provide a common messaging format to link together applications and services anywhere on the Internet. Microsoft and industry partners submitted SOAP to the World Wide Web Consortium (W3C) standards body earlier this year. The new SCL specification builds on SOAP to provide a mechanism to help developers describe the features of a Web service using XML. Developers will be able to use SCL to provide other developers and development tools with a description of the messages a Web service is expecting to send and receive. For example, they will be able to describe, in a standard way, that a stock quote Web service understands how to process messages that contain stock ticker symbols and return messages that contain the current stock price. The SOAP Discovery specification provides a set of rules for locating the SCL description of a Web service automatically; in other words, it enables the SCL description to be automatically discovered. For example, if a developer wanted to build the stock quote Web service into his application, a tool such as Visual Studio..NET would follow the rules defined in the SOAP Discovery specification to do so automatically. The SOAP specifications provide a common mechanism for integrating services on the Internet or intranet regardless of operating system, object model or programming language. Because they support Internet-standard XML and HTTP, the SOAP technologies enable new or existing applications to communicate with one another. By supporting the SOAP technologies, Web sites can become programmatically accessible Web services that don't require human initiation or intermediation. Because the SOAP technologies share an integration fabric that enables direct interaction between software connected to the Internet, new opportunities abound in aggregation, federation and integration of services and devices located anywhere on the Internet."
[September 22, 2000] "W3C Is Moving Aggressively On SOAP." By Antone Gonsalves. In TechWeb News (September 21, 2000). "The World Wide Web Consortium, which recently formed a working group for standardizing SOAP, is expected to finish within a year its first specification for it, an official close to the group said Thursday. The W3C announced last week it has formed an XML protocol activity working group that would be chaired by David Fallside, who works for IBM's standards division. '[The working group] has a very aggressive schedule,' said Robert Sutor, Fallside's boss and program director of IBM e-Business Standards Strategy. 'If you look at the charter, they believe they can get this done pretty much within a year, which is extremely fast by W3C standards.' 'I don't see any major roadblocks,' Sutor said. 'It's just a question of these companies who have said they would work on it to get their technical resources out there in doing so.' Because SOAP is XML-based, the technology is easier to use than programming-based cross-platform solutions. However, it is best suited for lightweight applications and exchanging information in an environment like the Web. It is not optimized for industrial-strength applications requiring tightly coupled, synchronous, ultra-secure processing among applications, observers said." See the earlier announcement for the W3C working group and related XML Protocol Activity.
[August 29, 2000] "ObjectSpace to Adopt SOAP Specification for B2B Interoperability. Leading B2B Provider to Incorporate Latest XML Communications Protocol Into Its OpenBusiness Software Solutions." - "ObjectSpace, a leading provider of web service-enabled business-to-business infrastructure software products and services, announced today its support of the Simple Object Access Protocol (SOAP) by incorporating it into their OpenBusiness product line of B2B software solutions. SOAP is a communications protocol that uses Extensible Markup Language (XML) to link applications and services over the Internet and allows business software programs to communicate regardless of the programming model on which they are based. OpenBusiness is a comprehensive set of integrated products and professional services to help companies realize business-to-business integration. OpenBusiness provides an easy-to-configure platform that enables B2B partners to build integration solutions rapidly without the need for alterations to existing software applications and enables the use of different business applications across all operating systems. ObjectSpace will integrate SOAP in the release of OpenBusiness 2.0 this year. SOAP was created in late 1999, by developers DevelopMentor, Inc., Microsoft and UserLand Software as a standard to bridge both XML and HTTP technologies to facilitate interoperability. Most recently, those companies, along with IBM and Lotus, developed SOAP version 1.1 and submitted that specification to the World Wide Web Consortium (W3C) for standardization."
[August 06, 2000] "Standards critical for .Net success." By Roberta Holland. In eWEEK (July 24, 2000). page 22. "Standards organizations will play an important role for two of the key technologies involved in Microsoft Corp.'s .Net software as a service vision. But whether the company follows through on the standards processes, and whether that makes a difference for developers, remains to be seen. When the Redmond, Wash., company introduced its new C# programming language last month, it submitted the software to the ECMA, a European standards body. Microsoft officials also said they will continue to push for the standardization of SOAP (Simple Object Access Protocol) by the World Wide Web Consortium. Microsoft, with co-authors including IBM and UserLand Software Inc., submitted SOAP 1.1 to the W3C in May. The W3C has not yet decided whether to create a working group focused on XML (Extensible Markup Language) protocols, which would include SOAP. Microsoft this month announced two extensions to SOAP intended to bolster Microsoft .Net. The first, SCL (SOAP Contract Language), describes the features of a Web service and what messages it is expecting to send and receive. The second, the SOAP Discovery specification, is a set of rules for automatically locating the SCL description of a Web service. . . "The SOAP stuff based on XML and [the standards effort around it] probably has a lot of traction to it," Bickel said. 'There are two platforms, Micro soft and Java, and SOAP goes across both.' In touting its commitment to standards, Microsoft has not shied away from pointing out that Sun Microsystems Inc.'s Java is not an official standard. It was the ECMA's process from which Sun withdrew last year, citing possible fragmentation or a slowdown of innovation. Instead, Sun has used its own Java Community Process to oversee the language, leaving ultimate control under the Palo Alto, Calif., company's purview."
[August 22, 2000] "Platform-Neutral Interoperability with SOAP. Big player support gives momentum to a new Internet protocol for distributed programming." By Kent Brown. In XML Magazine (Fall 2000). ['Kent Brown shows how SOAP, a new Internet protocol, will bring about a new age of interoperability by strengthening interaction among distributed computing systems.'] "The goal of SOAP is to eliminate (or at least penetrate) the walls separating distributed computing platforms. SOAP attempts to do this by following the same model attributes as the other successful Web protocols: simplicity, flexibility, platform neutrality, and text-based. In fact, when you get down to it, SOAP is less a new technology than a codification of the usage of existing Internet technologies to standardize distributed computing communications over the Web. SOAP started out as XML-RPC, a very simple protocol designed by Dave Winer of UserLand for doing RPC over HTTP using XML. SOAP 1.0 was a refinement of the original XML-RPC specification and was released in September 1999. Don Box of DevelopMentor, and several engineers from Microsoft, helped with the 1.0 specification. Initially IBM and Sun, who were getting involved in a similar but more ambitious effort called ebXML, dismissed SOAP as unimportant. This would have been a shame because an interoperability protocol is useless if the big players choose not to interop. Fortunately for SOAP and the entire distributed computing industry, IBM changed its mind and now not only supports SOAP but helps to drive it. David Ehnebuske of IBM and Noah Mendelsohn of the IBM subsidiary Lotus Development Corporation are co-authors of the SOAP 1.1 specification. Proving that its support of SOAP is strong, IBM was quick to supply a reference implementation of SOAP for Java. In fact, IBM beat Microsoft to the punch by several weeks, delivering SOAP4J a few days after SOAP 1.1 was announced. By contrast, the long-awaited Web Services Toolkit (renamed the SOAP Toolkit) was not released until more than a month later. Open source fans will be happy to hear that IBM has donated its SOAP4J reference implementation to Apache. . . Although synchronous RPC was the original intent of SOAP, the latest specification adds flexibility that allows SOAP messages to be used for asynchronous and one-way message passing schemes as well. In this type of usage, the format of the SOAP Body does not follow the SOAP encoding rules defined in Section 5 of the SOAP 1.1 specification, and the data doesn't necessarily map to the parameters of a specific RPC. The recipient of the XML document needs to know how to interpret it, which will usually be accomplished by referencing an XML schema that defines the structure of the document. There are some restrictions on the types of XML documents that can be included in SOAP messages. SOAP prohibits DTDs and Processing Instructions and therefore you can't necessarily pass an existing XML document (say a RosettaNet message) in a SOAP call if the XML document wasn't designed to be SOAP friendly. Perhaps the best example of the application of SOAP to messaging scenarios is the draft of the BizTalk Framework version 2.0 released on June 27, 2000. This newest version of the BizTalk Framework has been redefined to be SOAP 1.1 compliant, allowing BizTalk Framework XML documents to be transmitted in the form of SOAP messages. In addition, BizTalk Framework version 2.0 has been extended to provide Multi-Part MIME (Multipurpose Internet Mail Extensions) encoding guidelines to support the inclusion of one or more non-XML attachments within a BizTalk message. This will also allow non-SOAP-friendly XML documents to be passed in SOAP messages. All in all, the latest developments add up to good news for SOAP and the future of cross-platform interoperability. With luck, you'll soon find yourself reaping the benefits of using SOAP to provide or consume Web services."
[April 27, 2000] "SOAP: Simple Object Access Protocol." Version 1.1. 18-April-2000. "SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework." ['IBM and Lotus joined in co-authorship of SOAP, and the 1.1 spec is out.' - Dave Winer. [cache]
[June 20, 2000] Dave Winer (Userland) recently announced that "we have SOAP 1.1 running in Frontier, alongside XML-RPC..." The article "Introducing SOAP for Frontier" by André Radke on Soap.Weblogs.Com provides an overview: "On June 20th, 2000, UserLand released the first version of SOAP support for Frontier. This release implements a client and a server for performing remote procedure calls (section 7 of the SOAP 1.1. spec) over HTTP (section 6) using the SOAP encoding for parameters and return values (section 5). This version has not yet been tested for interoperability with other implementations, so all we can claim right now is interoperability with our own implementation. However, we expect to demonstrate interoperability with the IBM-SOAP implementation in the near future. We plan to set up a public test server later today. Our implementation currently has the following known limitations: (1) All parameters and return values must contain an appropriate xsi:type attribute indicating the type of the value. (2) Only a single return value is supported. Additional return values (out parameters) are currently ignored. (3) Arrays (5.4.2) are limited to one dimension only. Partially Transmitted Arrays (5.4.2.1) and Sparse Arrays (5.4.2.2) are supported. (4) Generic compound types are not supported, if they contain several accessors with the same name. (5) Only the following simple types can be successfully decoded: string, base64, boolean, float, decimal, double, unsignedByte, byte, unsignedShort, short, int, integer, nonPositiveInteger, negativeInteger, long, nonNegativeInteger, unsignedLong, unsignedInt, positiveInteger, timeInstant. (6) Only the following simple types will be encoded: string, base64, boolean, byte, double, int, short, timeInstant. (7) There is currently no API for processing SOAP headers. However, if your client sends SOAP headers with the SOAP-ENV:mustUnderstand attribute set to "1", the server will generate the appropriate SOAP fault. (8) On the server, we support the HTTP protocol binding with or without using the HTTP Extension Framework. The client does not support using the HTTP Extension Framework."
[June 27, 2000] "Microsoft Unveils BizTalk Framework 2.0. New Version Adopts SOAP 1.1 Specification, Supports Non-XML Attachments and Reliable Messaging." - "Furthering its commitment to the Extensible Markup Language (XML) and open industry standards, Microsoft Corp. today released a draft of the Microsoft BizTalk Framework version 2.0. This newest version of the BizTalk Framework has been redefined to be SOAP 1.1 (Simple Object Access Protocol) compliant, thereby allowing BizTalk Framework XML documents to travel over a network in the form of SOAP messages. In addition, version 2.0 has been extended to include specifications for reliable server-to-server messaging, guaranteeing exactly-once delivery of business documents over the Internet. Multi-Part MIME (Multipurpose Internet Mail Extensions) encoding guidelines also have been added to the framework to support the inclusion of one or more non-XML attachments within a BizTalk message. Microsoft BizTalk Server 2000 will support BizTalk Framework 2.0 as the protocol for reliable interoperability over the Internet. 'BizTalk Framework 2.0 enhances one of the industry's most popular frameworks for XML-based integration over the Internet,' said Chris Atkinson, vice president of the Windows DNA and Web Services Group at Microsoft. 'Among the enhancements is support for SOAP, an emerging standard for integrating applications and services over the Internet.' The BizTalk Framework takes advantage of standard Internet technologies such as XML and MIME to provide the specifications for XML-based integration within and between organizations. The support for the SOAP 1.1 specification, which was recently submitted to and acknowledged by the World Wide Web Consortium (W3C), will allow developers to create applications and services that can be more easily integrated, independent of operating system, programming model or programming language. . ."
[June 28, 2000] "Clean Interactions. SOAP simplifies Web application development." By Timothy Dyck. In eWEEK (June 26, 2000). "Businesses wanting to integrate purchasing systems, share business data or participate in the fluid business alliances that global e-business favors will find the recently updated SOAP a key technological enabler. The Simple Object Access Protocol is an XML (Extensible Markup Language)-based RPC (remote procedure call) standard originally developed by Microsoft Corp., Develop Mentor Inc. and UserLand Software Inc. (later joined by IBM and Lotus Development Corp.) that can greatly simplify cross-language and cross-business development. Key changes in SOAP 1.1 are a switch from Microsoft's older XML-Data to XML Schema and the addition of transport protocol independence. SOAP 1.0 required HTTP; SOAP 1.1 is transport-agnostic -- e-mail or message queuing links can be used if desired to move SOAP messages around. . . 'Making it independent was one of the main things we worked on with Microsoft in SOAP 1.1,' said Bob Sutor, program director for XML technologies at IBM. Like all prestandard efforts, SOAP is, for now, a slippery target. Even so, we believe SOAP 1.1 can deliver value now in specific situations."
[June 28, 2000] "XORBA Lathers Up SOAP." By Timothy Dyck. In eWEEK (June 26, 2000). ['Version 1.1 of Rogue Wave Software's XORBA provides a quick way to connect Web applications to CORBA servers, finds eWEEK Labs.'] "Version 1.1 of Rogue Wave Software Inc.'s XML-CORBA Link (known as XORBA) significantly simplifies the job of connecting Common Object Request Broker Architecture components to other types of program objects, such as those written using Microsoft Corp.'s Component Object Model framework or as straight Java classes. However, eWeek Labs' tests showed that, as with most programming object frameworks, IT staffs will have their hands full trying to connect CORBA with competing frameworks. As one of the very earliest products implementing Simple Object Access Protocol, or SOAP 1.0, XORBA also gives organizations a way to learn about and start implementing this important new remote procedure call technology. . ."
[May 26, 2000] Sanjiva Weerawarana posted an announcement for the release of IBM-SOAP Version 1.2. IBM-SOAP is "a Java reference implementation of the SOAP v1.1 specification. The implementation is released under the IBM Public License with full source. It implements most of the SOAP specification as well as a few extras. Specifically, it supports two encodings for data types: the SOAP encoding as defined by the SOAP specification and XMI encoding. Also, in addition to the HTTP transport defined by the SOAP specification, it supports SMTP as well using two alphaBeans from IBM alphaWorks (SMTP and POP3). IBM-SOAP's server-side support includes a generic SOAP router that can be used to SOAP-enable any Java class. An administration tool is also included to deploy new services to the router via the Web... The new version of IBM-SOAP adds support for services implemented in scripting languages, a new service manager client and support for 1-dimensional arrays. Details: "IBM-SOAP v1.2 is now available for download at the IBM alphaWorks Web site. New features include: (1) support for serialializing/de-serializing of 1-dimensional arrays using SOAP encoding style. (2) services can now be authored in scripting languages (all languages supported by BSF [ http://www.alphaWorks.ibm.com/tech/bsf] that support BSF's call operation). JavaScript (Rhino) is best supported at this time. (3) added a service manager client: can now deploy/undeploy/list/query services using a command line utility and the deployment descriptor XML file (4) added support for a literal XML encoding style. A serializer/deserializer is pre-registered for RPC parameters which supports sending and receiving parameters of type org.w3c.dom.Element without having to write any code at all. The addressbook example illustrates how this encoding style can be used to send/receive arbitrary XML."
[June 28, 2000] "Hanson Brothers Interoperability Sample." MSDN Technical article. (June 20, 2000). This sample demonstrates the SOAP Toolkit for Visual Studio 6.0 and how it can be used to interact with a Web Service. It displays interaction between two Web Services: one that resides on a Windows 2000 server and a second that resides on a Sun Solaris server.'] "Hanson Brothers is an online retailer who recently expanded their product offerings through the acquisition of a sporting goods company. They wanted to integrate their e-commerce site with an operational system from the recently acquired sporting goods company. The sporting goods company's inventory management system runs on a Sun Solaris server. The company's product and inventory information is maintained in an Oracle database and the data is accessed through Common Object Request Broker Architecture (CORBA) components. Hanson Brothers' e-commerce and order management systems are based on the Windows DNA application architecture and run on Microsoft. Windows 2000. servers. Rather than rewrite the sporting goods inventory management system, the Hanson Brothers IT department decided to integrate the systems using the Simple Object Access Protocol (SOAP) Toolkit for Visual Studio 6. In addition to reusing existing systems, Hanson Brothers wanted to provide systems to support its business partners. Hanson Brothers created an additional Web Service to allow partners to browse their catalog and add orders. In writing the HBInterop sample, our first goal was to provide a demonstration of how COM+ and components could be integrated using SOAP. Next, we wanted to demonstrate how SOAP could be used to integrate components on distinct platforms such as Windows 2000 and UNIX. Finally, we thought this sample provided a great opportunity to demonstrate the use of the SOAP Toolkit for Visual Studio 6.0 and how it simplifies the process of calling and implementing a Web Service. To meet these goals we: (1) Used the SOAP Toolkit for Visual Studio 6.0 to verify and manage inventory that is maintained in an Oracle database on the Solaris server. (2) Created a component that uses the SOAP Toolkit for Visual Studio 6.0 to make calls to CORBA components on a Solaris server. (3) Provided a Web Service so remote business partners can reuse our COM+ component to browse the catalog or place orders. The resulting sample demonstrates not only the reuse of COM+ components by remote users, but how COM+ and CORBA components residing on distinct platforms can be integrated using SOAP. . ."
[May 10, 2000] "Microsoft Submits SOAP Specification to W3C. First Step Taken Toward Standardizing Key Specification for Integration of Web Services." - "Microsoft Corp. today announced that the World Wide Web Consortium (W3C) has acknowledged its submission of the latest version of the Simple Object Access Protocol (SOAP) specification. Microsoft was joined by Ariba Inc., Commerce One Inc., Compaq Computer Corp., DevelopMentor Inc., Hewlett-Packard Co., IBM Corp., IONA Technologies PLC, Lotus Development Corp., SAP AG and Userland Software Inc. in submitting the specification and proposing the formation of a working group in the area of Extensible Markup Language (XML)-based protocols. SOAP is an open standards-based interoperability protocol that uses the W3C's XML to provide a common messaging format to link together any applications and services anywhere on the Internet..."
[April 30, 2000] "SOAP Specification Version 1.1 Now Available." By Don Box, DevelopMentor; David Ehnebuske, IBM (et al). From MSDN (April 2000). Version 1.1, '18 Apr 2000'. ['DevelopMentor, IBM, Lotus, Microsoft, and UserLand Software have finished work on the Simple Object Access Protocol (SOAP) specification version 1.1, adding a place for supporting protocols other than HTTP, complex message patterns, and generally cleaning up language that makes the spec easier to read and implement.'] Abstract: "SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework."
[May 01, 2000] Sanjiva Weerawarana recently posted an announcement for the release of a reference implementation of SOAP version 1.1, with full source under IPL. This reference implementation follows just a few days after the release of the version 1.1 specification for SOAP. The tool is being beveloped by Matthew J. Duftler, Sanjiva Weerawarana, and Paco Curbera (IBM TJ Watson Research Center, Hawthorne, NY), and is available from the IBM alphaWorks Web site. "We just sent our implementation of SOAP v1.1 to IBM alphaWorks. It is a mostly complete implementation architected to support: (1) doing messaging with SOAP, (2) doing RPC with SOAP, (3) multiple transport protocols, and (4) multiple encoding styles. . . We support two encodings for data types: the SOAP encoding as defined by the SOAP specification and XMI encoding Also, in addition to the HTTP transport defined by the SOAP specification, we support SMTP as well using two alphaBeans from IBM alphaWorks (SMTP and POP3). IBM-SOAP's server-side support includes a generic SOAP router that can be used to SOAP-enable any Java class. An administration tool is also included to deploy new services to the router via the Web. ['We have an IDL for SOAP in progress and expect to release that early next week. We plan to generate the IDL from the deployment descriptor which we already have (in XML). On the client-side, we provide an API which can be used to do RPC over any of the supported transports using any of the supported encodings. The RPC over SMTP impl is about 90% done; the code to pick up the returned result via POP3 is not integrated fully yet (it's in another class). The server side for SMTP posted requests is implemented as a POP3->HTTP->SMTP bridge. Once we have the IDL is done, we plan to generate client-side stubs as well.'] The software is released under the IBM Public License with full source; we envision making this a true open-source project in the future..."
[May 02, 2000] XIDL: An Interface Definition Language for SOAP-RPC. Francisco Curbera (Component Systems Group, IBM T. J. Watson Research Center) has posted an announcement for the draft release of an XIDL specification - a proposed IDL language for SOAP (Simple Object Access Protocol). He writes: "Interface definition languages for SOAP seem to be getting more and more attention. We, at the group that developed IBM's Reference Implementation, have been working on this problem too. Since proposals are already being made, we figure out it was time to contribute our work to the discussion. Hence, we have just posted a proposed IDL language for SOAP. It is included in the download page of SOAP for Java (IBM's Reference Implementation for SOAP v1.1), at the Alphaworks site, as an independent download. Visit the Web site for IBM's SOAP 1.1 implementation and fetch the SOAP interface definition language proposal: XIDL, an Interface Definition Language for SOAP-RPC. This document provides "a short description of XIDL, an XML-based interface definition language designed with two basic goals in mind: extreme simplicity and type system independence. XIDL uses very few different elements and will be able to work with any existing type definition languages because it assumes that all types are defined externally. Moreover, XIDL can be be directly mapped into a subset of the OMG's IDL. The purpose of all these features is, of course, to foster faster adoption and and easier integration into existing code bases. The document includes a schema, a simple example, and a short description of the language... XIDL is a very small language: it includes just seven different elements and three attributes..."
[April 29, 2000] Soap.Weblogs.Com - Dave Winer (CEO, Userland) announced: "I started a new weblog for SOAP at soap.weblogs.com. SOAP is an XML-over-HTTP protocol -- an open protocol for distributed computing based on the standards of the Internet. SOAP version 1.1 was released publicly on 4/26/00. UserLand is proud to have participated along with Microsoft, DevelopMentor, IBM and Lotus, in the design of this simple protocol, that we believe will revolutionize the development of applications for the Internet. When there are news stories related to SOAP we will point to them here in the weblog]. And let this be a web-based focal point for developers who are using SOAP to build client, workstation and server applications that build on SOAP. Membership is open. There's a discussion group and email bulletins and lots of other community-organizing tools. UserLand also actively supports development in, and deployment of XML-RPC, an elegant protocol that is widely supported and deployed. UserLand played an active role in the development of both SOAP and XML-RPC."
"Web Services and the Simple Object Access Protocol." By Pete Loshin.
"SOAP: The Simple Object Access Protocol." By Aaron Skonnard. "Remote objects can give a program almost unlimited power over the Internet, but most firewalls block non-HTTP requests. SOAP, an XML-based protocol, gets around this limitation to provide intraprocess communication across machines."
Simple Object Access Protocol (SOAP) - Objects Talking with XML
[April 28, 2000] "Revised Simple Object Access Protocol (SOAP) specification (v1.1). An open letter from the IBM and Lotus co-authors of the revised SOAP specification." By Noah Mendelsohn (Lotus Distinguished Engineer) and Dave Ehnebuske (IBM Senior Technical Staff Member). April 26, 2000. ['IBM and Lotus are co-authors of the revised specification, posted by several parties to public Web sites including IBM developerWorks.'] "April 26, 2000: Today, several parties, including IBM and Lotus, have posted a revised Simple Object Access Protocol (SOAP) specification (v1.1) to public Web sites, including [to IBM developerWorks. IBM and Lotus are now co-authors of the specification. Furthermore, IBM has been developing a Java implementation of SOAP, and we expect to post an early version to IBM's alphaWorks later this week. We thought the developerWorks community would like to know why we are joining in the SOAP effort, and why we are now co-authors of the specification. What is SOAP? The SOAP specification defines a simple, Internet-friendly way of using XML to send messages and to access services. SOAP is important to e-business because it provides a flexible, natural way of building applications whose pieces are distributed across networks. With XML and SOAP, each business can choose its own internal implementation technology, such as Enterprise JavaBeansTM, Microsoft Component Object Model (COM), or traditional languages such as COBOL. Yet any business can access a service, such as a parts catalog, or send a purchase order to or from any other business. When you implement these services, SOAP makes it easy to bind to the programming language or object system of your choice. SOAP's built-in support for Remote Procedure Calls (RPC) also makes it easy to invoke methods on remote objects, using XML and HTTP, so you can use SOAP to create distributed systems within your own organization too. SOAP is simple. The specification is short and easy to understand. Best of all, it takes only a few lines of JavaTM or JavaScript code to build real SOAP messages that do useful work. Just take a look at the specification if you want to get started. What is new in SOAP v1.1, and why did we become co-authors? The first versions of SOAP were developed by a team from DevelopMentor, Microsoft, and Userland, and were made available to the public last year. That early work generated tremendous excitement. At the same time, we at IBM and Lotus, along with others in the SOAP community, believed that the initial specification could be improved. Working together, we created the v1.1 specification that was posted today. What's new in 1.1? Better layering and better synergy with other Internet standards. In addition to HTTP, SOAP services and RPCs can now be accessed through your choice of message transports. For example, bindings could be defined to the IBM MQSeries or to electronic mail messages (SMTP). SOAP data representations and structures have been aligned with the proposed W3C XML Schema language, and it is now possible to apply those encodings in a much broader range of message patterns (such as streaming, one-way, multicast, and more). In short, SOAP has been made much more flexible and powerful, without sacrificing the simplicity that made the first versions so exciting. How will SOAP evolve? In addition to being immediately useful, SOAP provides a very simple but solid foundation for defining the standards that will support universal connectivity across businesses and organizations. For e-business to succeed, everyone must be able to talk to everyone else. Working with our partners, we are offering SOAP as a common, compatible starting point for building that infrastructure. And SOAP is just a starting point. For example, SOAP v1.1 does not provide security, message routing, or multicast capabilities that will be needed for robust e-business communication, but it does provide ways that such services can be layered on top of the base definition. Even without such features, SOAP is already proving successful as the basis for many useful applications. By agreeing with others in the industry to evolve from a common starting point, we set off together to build increasingly robust standards that are truly open and truly interoperable. IBM and Lotus are pleased to have co-authored this version of SOAP. We will continue to participate as the specification evolves, and we expect to use SOAP where appropriate to solve our customer's problems..."
[April 28, 2000] "SOAP Update Spurs Integration of Web Services. Industry Participation Grows With Version 1.1." - "Microsoft Corporation today announced the availability of the latest version of the Simple Object Access Protocol (SOAP) specification on the MSDN developer program Web site. SOAP is an open standards-based interoperability protocol that uses the Extensible Markup Language (XML) to provide a common messaging format to link together any applications and services anywhere on the Internet. This new version extends SOAP's asynchronous messaging capabilities and enables support for the Internet protocols SMTP, FTP and TCP/IP in addition to existing support for HTTP. These new capabilities further bolster SOAP's ability to integrate heterogeneous applications within the enterprise or diverse trading partners across the Internet. The specification was initially developed last fall by DevelopMentor Inc., Microsoft and UserLand Software Inc.; IBM Corp. and Lotus Development Corp. join as authors with version 1.1. The SOAP specification provides a common mechanism for integrating services on the Internet and/or intranet regardless of operating system, object model or programming language. Through its reliance on Internet-standard XML and HTTP, SOAP enables any new or existing applications to communicate with one another. By supporting SOAP, Web sites can become Web services that are accessible programmatically without requiring human initiation or intermediation. With a common integration fabric for direct interaction between software connected to the Internet, new opportunities abound in aggregation, federation and integration of services and devices located anywhere on the Internet."
[April 27, 2000] "IBM Switches Support to Microsoft-Backed Web Standard." By Wylie Wong. In CNet News.com (April 27, 2000). "After criticizing a Web technology created by rival Microsoft, IBM has changed its mind and is working with the software giant on a potential Internet standard that allows businesses to link Web-based software. The communications technology, Simple Object Access Protocol (SOAP), allows businesses to link their computing systems over the Net. It is based on a Web standard for exchanging data called XML (Extensible Markup Language). When the software giant unveiled the technology in October, IBM executives said SOAP too closely favored Microsoft technologies over industry standards. They said the effort to create SOAP should have originated from a standards organization, not from Microsoft. Sun Microsystems was even more dismissive, calling the technology pure hype with no value. But IBM has had a change of heart. Microsoft yesterday released an updated version of SOAP that included the work of IBM and its subsidiary Lotus Development. IBM and Microsoft executives said they expect to release tools soon that will allow developers to test SOAP in their own software. The main reason for IBM's support is the need for the software industry to find a way for businesses to link their different computing systems, said Bob Sutor, IBM's program director for XML technology... About 20 companies have voiced support for SOAP, including Iona Technologies, Compaq Computer, Intel, Ariba and Commerce One. Both IBM and Microsoft executives believe the W3C and the Internet Engineering Task Force will have roles in making SOAP a standard protocol. Sutor said some important changes in the latest version of SOAP include the ability to not only exchange data over the Internet but through other technology, such as messaging software."
[April 18, 2000] SOAP reference page, from James Snell. "I set up a really down and dirty website for logging SOAP related news, articles and resources on the web. Anybody can post new news, links to articles, links to resources on the site -- just gotta register first. Once you've registered you can delete items you've added, etc..."
[April 18, 2000] "SOAP, BizTalk, and Super Scalability. Microsoft's leading man on XML talks about the company's "embrace and extend" strategy -- and speculates on Sun's reaction." [John Montgomery] Interview by Sean Gallagher and Steve Gillmor. From DevX.com (April 17, 2000). "Microsoft's strategy to 'embrace and extend' XML, the Extensible Markup Language, includes two key technologies: SOAP, a protocol proposal for simple object access; and BizTalk, the company's schema standard for XML-based e- commerce and enterprise application integration. Lately, it seems the functions of SOAP and BizTalk are moving closer together. XML Magazine editorial director Sean Gallagher and editor Steve Gillmor spoke with John Montgomery, product manager for Web services in Microsoft's developer division, about the convergence... [Montgomery:] 'We see XML as being kind of the next level of technology that's going to come along and provide a universal description format for data on the Web, and what this is going to enable, from our perspective, is Web programmability. Once data is in a common format, it makes it that much easier for you to link together disparate things -- services in the sense of a telephone service or a cable-TV service -- using a minimal amount of consultant resources, a minimal amount of architect time. Basically, turning browsing the Web into programming the Web in a very simple way'."
[November 30, 1999] "Microsoft Proposes Net software Specification." By Mike Ricciuti. In CNET News.com (November 30, 1999). "Microsoft today will submit a draft of a proposed Internet communications specification to a key standards body. The Redmond, Wash.-based software giant will publish and submit version 1.0 of the Simple Object Access Protocol (SOAP) specification to the Internet Engineering Task Force (IETF) as an Internet draft. SOAP, based on the increasingly popular Web standard for data exchange called the Extensible Markup Language (XML), will let business software programs communicate over the Internet, regardless of the programming model on which they are based. Microsoft is attempting to gain an advantage over competitors, including Sun Microsystems, IBM and others, by establishing SOAP as an Internet standard and incorporating it into its server-based software. In many ways, SOAP, and Microsoft's plans to establish it as a standard, represent a reversal of Microsoft's past attempts to steer the software development business. The company many times has been accused of attempting to control the market with Windows, a de facto proprietary standard. With SOAP, Microsoft is proposing an open standard that would nullify a competitor's proprietary advantage. SOAP, which doesn't require any Microsoft software, is a network protocol that lets software objects developed using different languages communicate with each other. Microsoft sees it as effectively leveling the playing field between Windows and development strategies based on Java. Instead of being forced to choose one model, companies will be free to select whichever is best suited to solving the problem at hand, Microsoft reasons..."
[February 10, 2000] "Inside SOAP." By Don Box. From XML.com. (February 04, 2000). ['A technical introduction to SOAP, an XML-over-HTTP remote procedure protocol. SOAP was recently submitted to the IETF as an Internet Draft. Taking advantage of the pervasiveness of XML and HTTP, SOAP is a protocol for remote procedure calls over the web. Don Box, one of SOAP's creators, presents a technical introduction in his article.'] "The Simple Object Access Protocol (SOAP) is a minimal set of conventions for invoking code using XML and HTTP. DevelopMentor, Microsoft, and UserLand Software submitted SOAP to the IETF as an Internet Draft in December 1999. Since then, numerous application server/ORB vendors have announced support for the protocol as an Internet-friendly alternative to Microsoft's DCOM, Sun's RMI, and OMG's CORBA/IIOP (see the SOAP FAQ for a list of supporting vendors and products). SOAP utilizes the existing HTTP-centric fabric of the Internet to carry method requests that are encoded as XML both for ease of parsing as well as platform/language agnosticism. SOAP walks a very precarious tightrope, balancing the needs of developers using sophisticated type-centric technologies like Java and CORBA against the desires of the casual Perl or Tcl programmer writing CGI scripts. This tightrope is similar to the one walked by the W3C Schemas Working Group, who have had to design a metadata format that satisfies the needs of object and database technologies, while at the same time addressing the problem of describing document markup. While SOAP does not mandate the use of XML Schemas, it was certainly designed with them in mind. XML Schemas offer an excellent way to describe SOAP types and endpoints, as their type model matches that of SOAP very closely."
[January 28, 2000] "Microsoft Continues to Drive Home Standards." By Brian Ploskina. In ent - The Independent Newspaper for Windows NT Enterprise Computing [Online] Volume 5, Number 1 (January 12, 2000), pages 14, 20. "Two Microsoft Corp.-driven Internet standards accomplished some important steps at the end of 1999. The BizTalk Framework Document Specification 1.0 was approved by the BizTalk Steering Committee and is now available at the BizTalk.org Web site. The Simple Object Access Protocol (SOAP) 1.0 was submitted to the Internet Engineering Task Force (IETF, www.ietf.org) for review. With SOAP, the IETF is considering the specification as a common framework for integrating services on the Internet. Microsoft hopes that with SOAP Web sites will become Web services that work like sophisticated applications -- accessible via a program or through a browser -- allowing new levels of Web service aggregation. . . there needs to be a standard way for services to talk to each other. SOAP enables this communication at the lowest level. It takes HTTP as a starting point and places XML inside it. XML is tuned for application-to-application communication and acts as the barter between services..."
SOAP as an IETF Internet Draft. SOAP: Simple Object Access Protocol. HTTP Working Group. Informational draft, draft-box-http-soap-00.txt, September 1999. Abstract: "SOAP defines an RPC mechanism using XML for client-server interaction across a network by using the following mechanisms: (1) HTTP as the base transport; (2) XML documents for encoding of invocation requests and responses. SOAP is both low-entry and high-function, capable of use for simple stateless remote procedure calls as well as rich object systems. SOAP works with today's deployed World Wide Web and provides extensibility mechanisms for future enhancements. For example, SOAP supports submitting invocations using both M-POST and POST." [local archive copy]
About the Simple Object Access Protocol (SOAP) By David Chappell. September 10, 1999. "Summary: The Simple Object Access Protocol (SOAP) is a way to use the existing Internet infrastructure to enable applications to communicate directly with each other without being unintentionally blocked by firewalls. . . [Conclusion:] There is no shortage of distributed object protocols in the world. Yet none of them can be used unchanged with the infrastructure in place on today's Internet. By providing a simple, flexible mechanism to send requests and responses, one that rides on the ubitquitous HTTP, SOAP allows invoking remote methods without changing what's currently in place. Given the importance of accessing applications across the Internet, this is no small thing. And because it's not tied to any single object model, this new technology can potentially be used in many different scenarios. For all of these reasons, SOAP is a useful addition to today's protocol portfolio." [local archive copy]
SOAP Specification, version 0.9, from Microsoft Web site; local archive copy
Comments to MS at: soapwish@microsoft.com
SOAP References from 'www.xmlrpc.com' [UserLand Software, Inc.]
"An end to the Uber-Operating System." An article from DaveNet that provides context = comments from Dave Winer. September 12, 1999. "Along with Microsoft and Developmentor, we [DavNet] released a specification called the Simple Object Access Protocol, or SOAP. It's available on www.xmlrpc.com. The URL follows later in this piece. SOAP, as its name implies, is an object access protocol. It is more complex than the XML-RPC specification, which is deployed on a wide variety of operating systems and scripting languages. The purpose of both specs is to enable scripted web applications to cross operating system boundaries. I am an author of both specs, along with Don Box of Developmentor and a small group of Microsoft architects and engineers, including Gopal Kakivaya, Andrew Layman, Satish Thatte, and for the earlier spec, Bob Atkinson and Mohsen Al-Ghosein. SOAP is a milestone in a process that started for me in the mid-80s on MS-DOS, and continued into the 90s with interapplication scripting on the Macintosh, and onto the Internet with the release of the XML-RPC specification in April 1998. SOAP is a milestone for Microsoft because it is the opening of DCOM, the protocol for connecting applications over Windows networks."
[October 16, 1999] "SOAP Could Slip Up Microsoft Rivals." By Wylie Wong. In CNET News.com (October 15, 1999). "Microsoft has developed a new technology for exchanging information over the Web that could give the software giant an advantage over Sun Microsystems, IBM, and other competitors if adopted by a standards body. The new technology, called the Simple Object Access Protocol (SOAP), based on the increasingly popular Web standard for data exchange called the Extensible Markup Language (XML), will let business software programs communicate over the Internet, regardless of the programming model on which they're based. SOAP would replace Microsoft's current proprietary protocol called DCOM for communication over the Internet. Because SOAP is based on XML, it's compatible with all programming models and allows businesses to easily exchange data with each other over the Internet, said analyst Mike Gilpin, of Giga Information Group. Microsoft plans to submit the new protocol to an international standards body for approval soon. Like many software firms, Microsoft is supporting XML in its entire product line, and the company says it has no plans to hijack the Web standard..."
