Any encoding style can be used with SOAP 1.1, but the SOAP 1.1 Note offers a “standard” encoding style, called SOAP Encoding, which is what most SOAP tool kits support. SOAP Encoding generally is used with the RPC messaging style, in which case it's called RPC/Encoded messaging. RPC/Encoded messaging is not supported by the WS-I Basic Profile 1.0 (BP), because it is a major source of interoperability problems. Instead, the BP supports the RPC/Literal and Document/Literal messaging modes. It's likely that you will encounter legacy Web service endpoints that use RPC/Encoded messaging mode. In such cases, this appendix will serve as a useful reference for you.
RPC/Encoded messaging defines rules for serializing programming-language structures into XML. In other words, it explains how SOAP toolkits should map arguments in a programming language into a SOAP message. SOAP is language-neutral. RPC/Encoded messaging was designed to be flexible enough to accommodate most modern programming languages by defining types that are portable, so that data can be exchanged between different platforms. For example, SOAP Encoding makes it possible for you to invoke a Web service implemented in Java from an application written in Perl, by defining rules that allow data to be mapped from Perl to XML and from XML to Java.
This appendix describes the structure of SOAP messages based on RPC/Encoded messaging, the messaging mode that many stub-based SOAP toolkits still support. Understanding the mechanics of RPC/Encoded messaging is not critical to using stub-based toolkits, because most toolkits hide the details of encoding behind the stub; but in general, it's best to have an idea of how RPC/Encoded messaging works if you need to interoperate with Web services based on it. This appendix ends with a discussion of the differences between RPC/Encoded messaging and XML schema, and why they differ.
Before we can create a SOAP message using RPC messaging style, we have to know what encoding style is being used. The encoding style of a SOAP message is indicated using the soap:encodingStyle attribute, which is part of the SOAP namespace. It can be any value, as long as the sender and receiver both understand it. When standard SOAP Encoding is used (as is often the case with RPC-style messaging), the attribute value will be "http://schemas.xmlsoap.org/soap/encoding/", as in Listing D-1.
Example D-1. An RPC/Encoded SOAP Request Message
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookPrice"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" >
<Body>
<mh:getBookPrice>
<isbn xsi:type="string">0321146182</isbn>
</mh:getBookPrice>
</Body>
</soap:Envelope>
This attribute can be declared anywhere, but it's commonly declared in the Envelope or an immediate child of the Body element. This appendix does both.
RPC-style messaging, regardless of the encoding style, requires that the Body of the SOAP message have only one immediate child element. That child element identifies the Web service operation that is being invoked, and is called the operation struct. For example, the SOAP message for the getBookQuote operation might look like Listing D-2.
Example D-2. An RPC/Encoded Operation Struct
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookPrice" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <Body> <mh:getBookPrice> <isbn xsi:type="string">0321146182</isbn> </mh:getBookPrice> </Body> </soap:Envelope>
Identifying the operation immediately under the Body element makes it pretty easy for the Web service to map the SOAP message to the correct Web service component when it receives a message. The child element is called the operation struct because, like a struct in C or C++, it defines a set of named arguments, which are represented as elements. Each element in the operation struct maps to a parameter of the Web service operation (method call).
Obviously, procedure and method calls will often have multiple parameters that can be represented in RPC/Encoded messaging using multiple elements in the operation struct. Each element in an operation struct is called an accessor. For example, the Web service might support a slightly more complex operation called the getBulkBookPrice, which has two arguments: the ISBN number of the book and a quantity that allows the caller to query for bulk discounts on a particular book (see Listing D-3).
Example D-3. RPC/Encoded Messaging with a Complex Type Accessor
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookPrice"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<Body>
<mh:getBookPrice>
<isbn xsi:type="string">0321146182</isbn>
<quantity xsi:type="int">100</quantity>
</mh:getBulkBookPrice>
</Body>
</soap:Envelope>
Technically, the names of the accessors in an operation struct of a SOAP message can be anything. In the preceding example, the accessor names could match the argument names in a remote interface, but such matching isn't required by the specification. The SOAP specification (specifically, Section 5) doesn't dictate the mapping between SOAP program arguments and accessors—that's up to the SOAP toolkit. JAX-RPC (Java API for XML-based RPC) happens to specify a one-to-one mapping between the method argument names and the accessor names of the operation struct, but this is only a convention of JAX-RPC (and some other toolkits) and is not a standard. Some SOAP toolkits use arbitrary names. For example, the GLUE SOAP toolkit uses array-like position names (arg0, arg1, … argN) for accessors, as in Listing D-4.
Example D-4. RPC/Encoded Messaging with Arbitrary Accessor Names
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookPrice" >
<Body>
<mh:getBookPrice
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<arg0 xsi:type="string">0321146182</arg0>
<arg1 xsi:type="int">100</arg1>
</mh:getBulkBookPrice>
</Body>
</soap:Envelope>
Notice that the elements reflect the arguments' types, but not their names, which are determined by the conventions of the SOAP toolkit used. You might think that this would cause interoperability problems: If JAX-RPC uses the struct style and GLUE uses the array style (arg0, arg1, … argN), how can a GLUE client talk to a JAX-RPC Web service, or vice versa? The answer is WSDL (Web Services Description Language).
SOAP messages are usually constructed according to a WSDL document. The WSDL document describes the operations supported by a Web service, including the operation parameter names. Stub-based SOAP toolkits generate client stubs that exchange SOAP messages according to the WSDL document and not their own conventions. If a GLUE SOAP client, for example, wants to talk to a JAX-RPC-based Web service, it uses JAX-RPC-style operation structs as described by that Web service's WSDL document.
In the examples used throughout this book, the operation element, the immediate child element of the Body element, is namespace-qualified. This qualification is actually not required. You don't need to namespace-qualify the operation element and its subelements, but doing so allows you to distinguish elements of the operation structure from standard SOAP elements.
RPC/Encoded uses the XML schema simple types in the definitions of structures and arrays. You might have noticed that each of the arguments in the BulkBookQuote SOAP method explicitly declares its type using XML schema simple types, as shown in bold in Listing D-5.
Example D-5. RPC/Encoded XSI Type Declarations
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookPrice" > <Body> <mh:getBookPrice soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <isbn xsi:type="string">0321146182</isbn> <quantity xsi:type="int">100</quantity> </mh:getBulkBookPrice> </Body> </soap:Envelope>
The use of XML Schema-Instance simple types allows simple values to be portable, validated, and matched with corresponding types of the Web service component or object. XML schema simple types were adopted by RPC/Encoded messaging because that part of the XML schema specification was stable at the time SOAP 1.1 was completed. As you'll see in the next section, complex types in SOAP do not conform with complex types in XML schema.
SOAP Encoding also defines a set of global elements that correspond to XML simple types. For example, string, int, double, dateTime, and other elements defined in the namespace of SOAP Encoding are based on the XML simple types. These simple type elements can be used in RPC/Encoded messages as shown later, in Sections D.5: Array Types and D6: References.
RPC/Encoded allows you to use complex types as parameters and describes how complex types should be mapped to elements in the SOAP Body. For example, the BookQuote Web service might include an operation called getBulkBookPrice WithShipping(), which gives the bulk price but also adds in the shipping costs for a specified address. The method signature in Java would look as in Listing D-6.
Example D-6. A Java Interface Definition for the BookQuote Web Service
public interface BookQuote extends javax.rmi.Remote { public float getBookPrice(String isbn) throws RemoteException, InvalidIsbnException; public float getBulkBookPrice(String isbn, int quantity) throws RemoteException, InvalidIsbnException; public float getBulkBookPriceWithShipping(String isbn, int quantity, Address addr) throws RemoteException, InvalidIsbnException; }
The Address type is a Java serializable class, which is defined as follows.
public class Address implements java.io.Serializable {
public String name;
public String street;
public String city;
public String state;
public String zip;
// accessors and constructor follow
}
When the getBulkBookPriceWithShipping() method is invoked, all the arguments, including the Address object, are encoded into the SOAP Body, as in Listing D-7.
Example D-7. RPC/Encoded Messaging with Multiple Parameters
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookPrice">
<Body>
<mh:getBookPrice
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<isbn xsi:type="string">0321146182</isbn>
<quantity xsi:type="int">100</quantity>
<addr>
<name xsi:type="string">Amazon.com</name>
<street xsi:type="string">1516 2nd Ave</street>
<city xsi:type="string">Seattle</city>
<state xsi:type="string">WA</state>
<zip xsi:type="string">90952</name>
</addr>
</mh:getBulkBookPrice>
</Body>
</soap:Envelope>
Notice that each field in the Address class has a corresponding accessor in the addr element. The addr element is named after the method argument, whereas each of its accessors are named and typed according to the fields of the Address class. This matching is not required by the specification but is a convention supported by JAX-RPC.
Although simple-type arguments in RPC/Encoded messaging are based on the XML Schema-Instance simple types, complex types like addr are not typed—a departure from most object-oriented languages, which define named types for both simple and complex data. In RPC/Encoded messaging, complex data structures do not have explicit, named types. This weak type system is one the drawbacks of RPC/ Encoded messaging. The fact that a complex data object does not have an explicit type definition makes validating its structure difficult, and eliminates the possibility of complex-type inheritance. These limitations are one of the reasons that developers prefer RPC/Literal and Document/Literal to the RPC/Encoded mode.
In addition to complex types, RPC/Encoded messaging defines the Array type. The Array type provides a standard representation for arrays—a feature not offered by XML schema. The standardized representation of arrays in XML is one of the reasons some developers favor RPC/Encoded messaging.
The BookQuote Web service might define a method that provides the prices for several books at once, instead of a single book, as in Listing D-8—eliminating the need for multiple invocations when prices for more than one book are needed.
Example D-8. A Java Interface Definition for the BookQuote Web Service
public interface BookQuote extends javax.rmi.Remote { public float getBookPrice(String isbn) throws RemoteException, InvalidIsbnException; public float getBulkBookPrice(String isbn, int quantity) throws RemoteException, InvalidIsbnException; public float getBulkBookPriceWithShipping(String isbn, int quantity, Address addr) throws RemoteException, InvalidIsbnException; public [] float getBookPrice(String [] isbns) throws RemoteException, InvalidIsbnException; }
A SOAP message request for the getBookPrice() method might look like Listing D-9.
Example D-9. RPC/Encoded Messaging Using the Array Type Attribute
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi='http://www.w3.org/2001/XMLSchema-Instance' xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookPrice" > <Body> <mh:getBookPrice soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <isbns xsi:type="enc:Array" enc:arrayType="xsd:string[4]"> <isbn xsi:type="xsd:string">0596002262</isbn> <isbn xsi:type="xsd:string">0596000685</isbn> <isbn xsi:type="xsd:string">1558604154</isbn> <isbn xsi:type="xsd:string">0132017997</isbn> </isbns> </mh:getBulkBookPrice> </Body> </soap:Envelope>
This is only one of several possible representations of the same array using SOAP. RPC/Encoded messaging defines an Array element, as well as elements corresponding to many of the simple types defined by XML schema. For example, RPC/Encoded messaging defines int and string elements. Listing D-10 shows the same SOAP message, but this time it uses the RPC/Encoded Array and simple type elements.
Example D-10. RPC/Encoded Messaging Using the Array Type Attribute
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookPrice" > <Body> <mh:getBookPrice soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <enc:Array enc:arrayType="xsd:string[4]"> <enc:string>0596002262</enc:string> <enc:string>0596000685</enc:string> <enc:string>1558604154</enc:string> <enc:string>0132017997</enc:string> </enc:Array> </mh:getBulkBookPrice> </Body> </soap:Envelope>
You refer to an element of an array by its position or index rather than to a named field, as you do in the case of structs or objects. As a result, the names of the accessors for elements of an Array type are not important. Different SOAP toolkits use different accessor names, but when reading an Array value these are ignored anyway; only the ordinal positions of the elements are important.
The elements of a SOAP Array are polymorphic, which means they can contain any subtype of the array-element type. For example, an Array of integers can contain elements of type integer but may also contain elements of types long, int, short, and byte, because these other types are derived from integer in XML schema (see Listing D-11).
Example D-11. RPC/Encoded Messaging Using a Polymorphic Array
<SomeArray xsi:type="enc:Array" enc:arrayType="xsd:integer[4]"> <number>0596002262</number> <number xsi:type='int' >0596000685</number> <number xsi:type='short'>31930</number> <number xsi:type='byte'>132</number> </SomeArray>
The Java programming language does not support polymorphism in its primitive array types, so this type of array would probably be mapped to an array type like Object[] or some java.util.Collection type, and the elements would be of wrapper types (Integer, Short, and Byte) instead of their primitive counterparts (int, short, and byte).
Arrays can also contain complex types and other arrays. Accessors that contain complex types or other arrays can be represented in line, as in Listing D-12, or using references, as discussed in the next section. The array in the following example is of type ur-type, which is the base type of all the other XML schema types. The ur-type is analogous to the Object type in Java.
Example D-12. RPC/Encoded Messaging Using an Array of Complex Types and Other Arrays
<SomeArray xsi:type="enc:Array" enc:arrayType="xsi:ur-type"> <item xsi:type='string'>0596002262</item> <item xsi:type='mh:USAddress' > <address> <name>Amazon.com</name> <street>1516 2nd Ave</street> <city>Seattle</city> <state>WA</state> <zip>90952</zip> </address> </item> <item xsi:type='enc:Array'> <enc:Array enc:arrayType='int' enc:arraySize='3'> <number>541</number> <number>3833452</number> </number>20382</number> <enc:Array> </item> </SomeArray>
When arrays are elements of some other array, as in the preceding example, the result is not the same as a multi-dimensional array. The distinction is the same as in the Java programming language. In Java, an array of type Object may contain other arrays as elements. For example, the following code creates an Object array that contains two other arrays.
// create an array of arrays
int [] intArray = {22, 33, 44};
double [] doubleArray = {22.22, 33.33, 44.44};
Object [] objectArray = new Object[2];
ObjectArray[0] = intArray;
ObjectArray[1] = doubleArray;
This type of array is very different from a multi-dimensional array, which is a matrix of ordinal values. For example, the following code creates a multi-dimensional array that contains both Integer and Double values.
// create a multi-dimensional array
Object [][] objectArray = new Object[2,3];
objectArray[0,0] = new Integer(22);
objectArray[0,1] = new Integer(33);
objectArray[0,2] = new Integer(44);
objectArray[1,0] = new Double(22.22)
objectArray[1,1] = new Double(33.33);
objectArray[1,2] = new Double(44.44);
RPC/Encoded messaging mode makes the same distinction between arrays that contain other arrays and multi-dimensional arrays. When a multi-dimensional array is serialized into a SOAP message using RPC/Encoded messaging, the contents of the array are listed in order, incrementing the index of the lowest dimension first. For example, the multi-dimensional Java array in the previous snippet might be represented using RPC/Encoded messaging as in Listing D-13.
Example D-13. An RPC/Encoded Multi-dimensional Array
<enc:Array enc:arrayType='xsi:ur-type' enc:arraySize='2,3'>
<item xsi:type="string">22</item>
<item xsi:type="string">33</item>
<item xsi:type="string">44</item>
<item xsi:type="string">22.22</item>
<item xsi:type="string">33.33</item>
<item xsi:type="string">44.44</item>
</enc:Array>
The array size is indicated using a size qualifier following the type identification in the value of the arrayType attribute. This qualifier indicates the size of each dimension of the array. If the array has only one dimension, a single integer value is used, as in Listing D-14.
Example D-14. A One-Dimensional Array
<isbns xsi:type="enc:Array" enc:arrayType="xsd:string[4]">
<isbn xsi:type="xsd:string">0596002262</isbn>
<isbn xsi:type="xsd:string">0596000685</isbn>
<isbn xsi:type="xsd:string">1558604154</isbn>
<isbn xsi:type="xsd:string">0132017997</isbn>
</isbns>
If the array has multiple dimensions, the size of each dimension is listed from the highest (leftmost) dimension to the lowest (rightmost) dimension, separated by commas, as in the following snippet.
<enc:Array enc:arrayType='xsi:ur-type' enc:arraySize='2,3'>
<item xsi:type="string">22</item>
<item xsi:type="string">33</item>
<item xsi:type="string">44</item>
<item xsi:type="string">22.22</item>
<item xsi:type="string">33.33</item>
<item xsi:type="string">44.44</item>
</enc:Array>
There are other ways in which arrays are manifested, including partially transmitted arrays, sparse arrays, and arrays of bytes. These are somewhat esoteric and are covered only in brief in this section.
Partially transmitted arrays allow very large arrays to be transmitted in multiple SOAP messages. For example, one SOAP message can contain the first part of a large array, while the next SOAP message contains the second part of the array. This feature is rarely used.
Sparse arrays allow arrays with lots of empty elements to be compressed, so that only the positions that contain values are transmitted. The relative index of each position is indicated so the sparse array can be reconstructed.
The byte array uses Base64 encoding to transmit binary data as ASCII text. It's not an array in the same sense as the SOAP Encoding Array type. It is just a data type of base64 whose value is a character-encoded binary stream. For example, the following shows a byte array for an image.
<image xsi:type="enc:base64"> aG93IG5vDyBicm73biBjb3cNCg== </image>
Base64 encoding is covered in detail in Appendix C.
One of the principal advantages of RPC/Encoded messaging over RPC/Literal and Document/Literal messaging is the capability to use references. An object graph will sometimes have multiple references to the same instance of an object. As an example, we can imagine an object graph of book authors, as illustrated in Figure D-1.
Figure D-1 illustrates graphically the relationship between instances of three Book objects and two Author objects. In this case, all three Book instances refer to a single author, Richard Monson-Haefel. As a result, the three Book instances share a reference to the same Author instance. You can represent this multiplicity in RPC/Encoded messaging using the href and id attributes, as in Listing D-15.
Example D-15. RPC/Encoded Messaging References
<books enc:arrayType="addBook:ArrayOfBooks[3]">
<book>
<title>J2EE Web Services</title>
<authors enc:arrayType="addBook:ArrayOfAuthors[1]">
<author href="#author_1" xsi:type="addBook:Author" />
</authors>
</book>
<book>
<title>Enterprise JavaBeans, 4th Edition</title>
<authors enc:arrayType="addBook:ArrayOfAuthors[1]">
<author href="#author_1" xsi:type="addBook:Author" />
</authors>
</book>
<book>
<title>Java Message Service</title>
<authors enc:arrayType="addBook:ArrayOfAuthors[2]">
<author href="#author_1" xsi:type="addBook:Author" />
<author xsi:type="addBook:Author" >
<fname>David</fname>
<mi>A</mi>
<lname>Chappell</lname>
</author>
</authors>
</book>
</books>
<author id="#author_1" xsi:type="addBook:Author">
<fname>Richard</fname>
<mi>W</mi>
<lname>Monson-Haefel</lname>
</author>
The three books all share a reference to a single author element. When an element is not shared, it must be embedded. For example, in this example, the third book element contains a single reference to an element representing David A. Chappell, which is embedded and not referred to. An object graph may use local or remote references, depending on the value of the href attribute.[1]
If you have worked with HTML, the href attribute may look familiar. The value of the href attribute in RPC/Encoded messaging, like the href in HTML, can be an absolute, relative, or fragment address. In practice, the value of the href attribute is normally a fragment, which is a reference to an element in the same document.
You may run across the use of a full URL, one that points to an element of an XML document located at some remote Internet address, but don't hold your breath. This is rarely, if ever, done. The following is an example of a remote reference.
<mh:book>
<title>J2EE Web Services</title>
<author href='http://wwww.Monson-Haefel.com/jwsbook/authors.xml#author_1' />
<mh:book>
A local reference points to a shared element that is listed within the same SOAP message. The href value is usually prefixed with a pound sign (#), followed by an identifier. The identifier corresponds to the value of an id element. The value of an element id attribute must be unique; two elements cannot have the same id attribute value.
In addition to referring to complex types, the href attribute may refer to simple types that are reused in an object graph. Normally, this technique is applied only to string types. For example, Listing D-16 shows two different authors sharing the same first and last names, but having different middle initials.
Example D-16. Referring to Simple Types
<book>
<title>Java Message Service</title>
<authors enc:arrayType="addBook:ArrayOfAuthors[2]">
<author href="#author_1" xsi:type="addBook:Author" />
<author xsi:type="addBook:Author" >
<fname href="string_1" />
<mi>A</mi>
<lname href="string_2" />
</author>
</authors>
</book>
<book>
<title>Understanding .NET</title>
<authors enc:arraySize="2" enc:itemType="addBook:ArrayOfAuthors">
<author href="#author_2" xsi:type="addBook:Author" />
</authors>
</book>
...
<author id="#author_2" xsi:type="addBook:Author">
<fname href="string_1" />
<mi>F</mi>
<lname href="string_2" />
</author>
<soap-encoding:string id="string_1">David</soap:encoding>
<soap-encoding:string id="string_2">Chappell</soap:encoding>
Whether encoded messages benefit from shared references to elements of simple types depends on how often a simple value is reused or how many characters are used for a simple type value. In many cases, it's probably more efficient simply to repeat the value rather than refer to it, but the better strategy to use depends on the SOAP toolkit.
It's important to understand that the first SOAP specification (SOAP 1.1) was completed before XML schema became a final recommendation. In fact, at the time that SOAP 1.1 was submitted as a Note to the W3C, XML schema was still in development. At that time, XML schema defined only simple types and not complex types. As a result, SOAP Encoding tends to overlap with the XML schema specification when it comes to defining complex types. This overlap creates a lot of confusion. If XML schema had been completed before SOAP 1.1, the SOAP Encoding might have been better aligned with the final XML schema recommendation.
Because SOAP 1.1 was in use for a while before XML schema, a lot of toolkits still support the SOAP RPC/Encoded mode of messaging. The general trend today, however, is to move away from RPC/Encoded messaging and toward the RPC/Literal and Document/Literal modes, because XML schema is perceived as offering a stronger type system and better interoperability.
Although Web service pundits tend to dismiss SOAP Encoding, the fact is that there are aspects of SOAP Encoding that are necessary in RPC programming and not available in XML schema. Specifically, SOAP Encoding supports object graphs with shared references, whereas XML schema doesn't support shared references. In addition, SOAP Encoding provides a common definition of an array, which is pervasive in programming languages but is not explicitly supported by XML schema. Still, RPC/Encoded messaging is not supported by the WS-I Basic Profile 1.0, so you should avoid SOAP Encoding if you can.
[1] In addition to the book Java Message Service (O'Reilly, 2000), David A. Chappell is also the co-author of the books Java Web Services (O'Reilly, 2002) and Professional ebXML Foundations (Wrox, 2001).