An article on object serialization in .NET.

An Introduction to SOAP.

Simple Object Access Protocol is one of the neatest XML based technologies to be introduced as of late, yet many people are still trying to get a handle on all of the new terms and acronyms that SOAP has uncovered. This article is written to help you dig through the SOAP soup we have in front of us and create a foundation for truly understanding what SOAP is all about. This article is not meant to provide in-depth detail about SOAP, but is written as a preparation for future articles where we will get into the guts of SOAP.

SOAP - Simple Object Access Protocol - is the hottest thing in XML development right now. It has a major role to play in Microsoft's next generation of Visual Studio, and it is the basis of their ".NET" strategy. If you're looking to write a bullet-proof SOAP service now, in VB6, then look no further than Microsoft's SOAP toolkit for VB; but if you really want to understand what SOAP is all about, then you need to get under the hood, and start building your own objects around the SOAP standard. This article aims to get you started.

This is a beginner level article giving basic introduction to SOAP. The purpose of this article is to introduce the SOAP concept. This article does not address 'How to Build a SOAP Server/Client'. I plan to publish a separate article on how to build a SOAP Server/Client soon.

SOAP Interoperability - a recent very hot topic on various SOAP mailing/discussion lists, is really an interesting area to focus on. My previous article was a brief introduction to write Web services with SOAP, and we wrote a simple Hello SOAP Web service. There are atleast forty toolkits available today for writing SOAP Web services and clients including those from Microsoft, Apache, SOAP::Lite, IdooXoap, DevelopMentor, etc. So do they keep the promise of SOAP and permit write server using one while client using other toolkit? Let's take a look. This article series will focus on such interoperability issues, and with simple illustrations.

Creating a SOAP client using C++ instead of VB.

This July, W3C simultaneously published Working Drafts for SOAP (Version 1.2) and the XML Protocol Abstract Model. According to the W3C, "By formally publishing these working drafts at an early stage of the design work, W3C is ensuring that the public can follow the development of SOAP Version 1.2 and the XML Protocol Abstract Model, and contribute to a final result that is widely accepted and adopted."

Choosing Between SOAP and Application-Specific XML for Your Web Services

SOAP Version 1.2 is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. SOAP Version 1.2 Part 2: Adjuncts defines a set of adjuncts that may be used with SOAP Version 1.2 Part 1: Messaging Framework. This specification depends on SOAP Version 1.2 Part 1: Messaging Framework [SOAP Part 1].

More and more projects are using XML schemas to define the structure of their data. As your repository of schemas grows, you need tools to manipulate and manage your schemas. The Eclipse XSD Schema Infoset Model has powerful querying and editing capabilities. In this article, Shane Curcuru will show how you can update a schema for use with SOAP by automatically converting attribute uses into element declarations.

This is an excerpt from a mail conversation with someone who was a bit surprised to learn that I really don't like XML-based RPC protocols. Slightly edited for readability, and to protect the innocent.

Open source developer web site Advogato has been discussing SOAP, in response to Bruce Schneier's concerns about its security.

The SOAP with Attachments API for Java (SAAJ) provides a standard way to send XML documents over the Internet from the Java platform.

Today Dave Sifry of the excellent Technorati announced an API for the world. The API, as announced, is about as purely Webby a thing as you can imagine. Dave Winer pushed back, suggesting a more SOAP/XML-RPC kind of approach. This is maybe the single central issue in architecting Web apps right at the moment, so I think it's OK to take a few more whacks at the supine equine.

SOAP is the Simple Object Access Protocol. If you haven't heard of it by now, you've probably been living under a rock somewhere. It's become the newest craze in web programming, and is integral to the web services fanaticism that has taken hold of the latest generation of web development. If you've heard of .NET from Microsoft or the peer-to-peer "revolution," then you've heard about technologies that rely on SOAP (even if you don't know it). There's not one but two SOAP implementations going on over at Apache, and Microsoft has hundreds of pages on their MSDN website devoted to it (http://msdn.microsoft.com/).

I just spent all day working with SOAP and encryption and xmldocuments. Don Box just wrote a post that addresses a misconception that I had when working on my solution today. “What caught my attention was the implication that there are somehow two classes of XML - documents and something else.” Because I was dealing with SOAP I thought I had to send a “real” xmldocument, not whatever xml is created magically when you send a dataset from a webservice. So I converted my dataset to an xmldocument object, sent that back to my client then took the resulting xmlNode, converted back to an xmldoc and then back to a dataset.

The W3C has released Working Drafts of SOAP 1.2 and the XML Protocol Abstract Model.

A year ago, I wrote about the potential for XML to revolutionize mobile application development. One of the reasons is because mobile applications present the ultimate distributed computing environment: the clients run a multitude of operating systems and can be located just about anywhere. Despite these restrictions, they all need to interact with servers to obtain or update data. For the majority of applications, it is my opinion that technologies such as CORBA, DCOM, and Java RMI are now poor choices for basic remote procedure calls and data interchange. Why build a server application and worry about operating systems, proprietary calling methods, and ORBs when open, XML-based technologies such as XML-RPC and SOAP exist? XML levels the playing field and is serving to usher in a new generation of programmable Web services.

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.