Fast Web Services

By Paul Sandoz, Santiago Pericas-Geertsen, Kohuske Kawaguchi, Marc Hadley, and Eduardo Pelegri-Llopart, August 2003  

Fast Web Services is an initiative at Sun Microsystems aimed at the identification of performance problems in existing implementations of Web Services standards. Our group has explored several solutions to these problems. This article focuses on a particular solution that delivers maximum performance gains. Fast Web Services explores the use of more efficient binary encodings as an alternative to textual XML representations. In this article, we:

  • Identify the performance of existing technologies
  • Introduce the main goals of Fast Web Services, both from a standards and an implementation perspective.
  • Highlight some of the use cases for Fast Web Services
  • Discuss standards and associated technologies needed for Fast Web Services
  • Present an example in which XML and the proposed binary encoding are compared
  • Describe the Java prototype that has been used to obtain some compelling performance results

The following sections use the terms Fast Web Services and Fast interchangeably.

The Performance Problem

XML-based messaging is at the heart of the current Web Services technology. XML's self-describing nature has significant advantages, but they come at the price of bandwidth and performance.

XML-based messages are larger and require more processing than existing protocols such as RMI, RMI/IIOP or CORBA/IIOP: data is represented inefficiently, and binding requires more computation. For example, an RMI service can perform an order of magnitude faster than an equivalent Web Service. Use of HTTP as the transport for Web Services messages is not a significant factor when compared to the binding of XML to programmatic objects.

Increased bandwidth usage affects both wired and wireless networks. Often the latter, e.g. mobile telephone networks, have bandwidth restrictions allotted for communication by a network device. In addition, larger messages increase the possibility of retransmission since the smaller the message, the less likely it will be corrupted when in the air.

Increased processing requirements affects network devices communicating using both types of networks (wired and wireless). A server may not be able to handle the throughput the 'network' demands of it. Mobile phone battery life may be reduced as a device uses more memory, performs more processing and spends more time transmitting information. As the scale of Web Services usage increases, these problems are likely to be exacerbated.

Fast Web Services attempts to solve these problems by defining binary-based messages that consume less bandwidth and are faster and require less memory to be processed. The price for this is loss of self-description.

Fast Web Services is not an attempt to replace XML-based messaging. It is designed to be an alternative that can be used when performance is an issue.


The main goal of Fast Web Services is

To enable fast and efficient end-to-end, interoperable, Web Services for a whole spectrum of devices, from mobile phones to large back end servers

For the Java community this goal translates as:

To enable fast and efficient end-to-end, interoperable, Web Services for J2ME, J2SE and J2EE platforms

A sub-set of the main goals is to:

  • Minimize the impact on the developer
  • Interoperate with existing peers
  • Become a multi-platform standard

Fast has to work well with existing Web Services standards and APIs so that there is minimal impact on the developers. A developer should not have to maintain two code bases with different APIs for the same Web Service, nor should (s)he have to define two different Web Service contracts for any particular service. Ideally, a developer should be able, at the flick of a switch, to specify: "I want my service to go Faster when talking to Fast-enabled peers."

Fast must define the interoperability between Fast peers. In addition, it must define the interoperability with existing Web Services that do not support Fast. The approach is to: "Use Fast when available, and use XML otherwise."

Fast is not a Java-only technology: it is designed to be platform-independent, just like existing Web Services. This expands the interoperability to non-Java platforms, such as C#, C and C++ or scripting languages such as Perl and Python. Standards are crucial: Fast will not be deployed and implemented by vendors unless it has good standards traction backed by parties influential in the Web Services space.

Use Cases

In this Section we highlight some of the use cases for Fast. The first three represent general cases, and the last two represent more specific domains which involve end-to-end computing between mobile devices and large servers.

Within the Enterprise

Web Services within the enterprise, such as for use in Enterprise Application Integration, is where Web Services currently has predominance. This can be attributed to four factors:

  1. Ease of managing deployment
  2. Use of stable Web Service specifications only
  3. Single security domain
  4. Same vendor for client and service

Time and Resource-Sensitive Systems

The case of mobile telephone networks has already been mentioned. Resource constraints of mobile devices, such as memory and bandwidth, dictate what may be possible on the device. As these devices become more powerful and battery technology allows for longer life, these constraints may not be so restrictive. However, there is a constant effort to network-enable smaller and smaller devices, and it is likely that similar constraints will apply to future devices as apply to the devices we see today.

High-transaction throughput systems are sensitive to both bandwidth and processing time. It is likely that Web Services, using XML-based messaging, will not function in this domain. Even though Moore's law postulates that machines are getting faster (as a consequence of exponential rate of transistor density), the rate of this increase is significantly slower than that of network bandwidth. More and faster machines will be employed to meet demands for throughput. Although this case is compelling, the ability to do more with less, possibly with systems that have already been deployed, is a significant advantage.

Satellite communications may combine the two previous examples with the addition of real-time constraints. The tools and technologies of XML-based messaging were recently evaluated for a large European satellite constellation project. The technical support team ruled out XML messaging and its tools because these were not suitable for efficient transfer of data in real time. Instead they chose to concentrate on tools and technologies that underlie Fast Web Services.

The three examples above suggest that if Web Services can support the requirements of these domains, then they may be adopted in new and perhaps unexpected application domains.

High-Performance Computing (HPC)

The scientific grid project is an area of high-performance computing that is adopting Web Services tools and technologies. XML-based messages in these cases can be large and do not represent the data in the most efficient form (such as, real numbers are represented as strings). The HPC community recognizes that this issue has yet to be encountered but anticipates it will be [ 1].

Fast can offer a solution to this emerging area and its market, without impacting the main goals of grid computing.


Auto-ID [ 2] is an initiative to standardize the processing and management of Radio Frequency ID and RF-ID systems. RF-ID tags, which have the size of a small coin, can be attached to every product on supermarket shelves such that when an item is taken off the shelf, the store can order more. Just as barcodes improved the efficiency of inventory management in the 1980s, RF-ID systems will make further improvements in this decade, as items are individually identified and it is not necessary to remove items from their packaging to identify them.

An Auto-ID architecture, such as Sun Microsystem's [ 3], can be based, in part, on Web Services. RF-ID readers will read IDs and and send Web Service messages to servers. The readers may be small wireless devices, so there is potential for multiple devices to send messages to a server at the same time. The scale of Auto-ID systems and the throughput they require will be vast.

Fast can ensure that small devices may efficiently participate as Web Service clients, that bandwidth usage from many clients sending messages is reduced, and that servers may be able to process messages efficiently.

Open Mobile Alliance (OMA): Mobile Web Services and Value-Add Services

The OMA [ 4] is defining how non-intermediated Web Services [ 5] can be used for mobile services. Currently, this effort defines the use of value-add services using a Web service framework, such as impromptu teleconferencing and context-sensitive apps like "find-a-friend". In the future, the OMA could define how mobile clients may directly connect to value-add services and achieve end-to-end communication.

The scale of mobile user numbers and growth in this area means that there will be significant demands on servers to provide unprecedented levels of throughput. Fast could play a small but critical part, and may help to achieve this in conjunction with hardware based throughput computing plans.

Standards and Technology

This Section outlines new specifications that underlie Fast Web Services and describes the relationship of these new specifications with existing ones.

Fast has a goal to minimize the impact to existing specifications and thus minimize the effect on Web Services developers and tools vendors. Fast is targeted at developers of Web Service stacks rather than the end users of those stacks who outnumber stack developers by a large factor.

With this goal in mind it is of paramount importance that WSDL [ 6], the basic contract between a client and service, is not changed in any radical fashion.

Figure 1 illustrates how this can be accomplished. It is possible to change the underlying Web Services framework (consisting of a protocol, data binding and transport layer) without affecting the application. Note that WSDL defines a contract to all three layers depicted. To ensure no radical changes, existing WSDL concepts such as the SOAP binding and W3C XML Schema [ 7], are maintained. This ensures that the existing syntax can be interpreted differently but consistently (see below for more details).

Figure 1. Application hidden from lower level details

Fast is built on a foundation of well-proven network standards and technologies that ensure that no changes are required to WSDL, however this lack of change may not be considered appropriate as explained in Section 3.2.

Abstract Syntax Notation One (ASN.1)

ASN.1 [ 8] is a well-established set of standards that have been in development for nearly 20 years. These standards are defined by the International Telecoms Union Telecommunication Standardization sector (ITU-T) [ 9], of which Sun Microsystems is a member, and they are jointly defined with ISO. All ASN.1 standards defined in the ITU-T/ISO can be licensed on a royalty-free basis.

ASN.1 may seem obscure to Web Services specialists, but it is used extensively in the telecommunications industry. For example, ASN.1 is used in mobile phone networks to help transfer control between network cells [ 10]. It also plays a critical role in the "central nervous system" of telephone networks when routing data is modified.

ASN.1 is a formal language for abstractly describing messages to be exchanged between distributed computer systems. ASN.1 schemas are used to define messages that may be encoded in many different textual or binary forms. Tools can be used to compile the schema into programmatic types such that the encoding/decoding process is automated. This concept is similar to that of compiling W3C XML Schema to programmatic types that may encode and decode to XML.

Recently two initiatives have been underway in Study Group 17 (SG-17) [ 11], the main group chartered to progress ASN.1 until the end of 2004:

  1. To enable ASN.1 schema to be used as an XML Schema, just like W3C XML Schema and Relax-NG. This is referred to as X.693 [ 13].
  2. To map W3C XML Schema (XSD) to ASN.1 schema such that ASN.1 tools can be used to encode W3C XML Schema defined data in more efficient binary forms. This is referred to as X.694 [ 14].

This work is defined under Question 12 (Q12/17) [ 12].

Fast and ASN.1

X.694, a specification that defines a mapping from XSD to ASN.1, is an important building block for Fast because XSD is used in WSDL to define the structure of messages. Consequently, the XML schema referenced in a WSDL document can be considered an abstract schema, with an equivalent ASN.1 description, whose instances can be encoded using XML or an ASN.1 encoding. In the latter case it is possible to use an efficient binary encoding such as Packed Encoding Rules (PER), also known as X.691 [ 15]. Figure 2 depicts this process.

Figure 2. XSD as an abstract schema and the Fast schema encoding

ASN.1 schema and PER encoded messages are used in the latest generation of air-ground and ground-ground protocols employed by the Federal Aviation Administration and International Civil Aviation Organization.

PER has two interesting properties:

  1. It defines the most compact ASN.1 encoding
  2. It is the fastest to encode and decode

PER is ideal for the requirements of Fast, namely a compact and efficient-to-process wire format that has already been deployed in wireless networks. Values for types such as integer, boolean and real are encoded in a compact binary form that is efficient to process.

X.694 and PER (X.691) provide Fast with an ideal combination to achieve the goals stated in Section 1.2, and this is what we refer to as the Fast Schema Encoding. It is important to stress that Fast does not define any new specific binary encoding of XSD. There is no need to invent a new technology. Instead, the existing ASN.1 standards can be applied and if necessary evolved to meet future requirements.

New Standards Work

Sun Microsystems, in conjunction with OSS Nokalva (a leading ASN.1 tools vendor) has initiated a new work item at the joint ITU-T/ISO body, provisionally entitled "ASN.1 Support for SOAP, Web Services and the XML Information Set" and referred to as X.695. This aims to define a number of proposed specifications to ensure that X.694 and X.691 (or other alternative ASN.1 encoding rules) can be used in Web service environments.

X.695 consists of the following sub-specifications:

  • ASN.1 Schema for SOAP
  • ASN.1 Schema for the XML information set
  • Fast annotations for WSDL

The ASN.1 schema for SOAP is based on the W3C SOAP 1.2 specification [ 16] and ensures that the SOAP semantics and processing model are preserved. This enables WSDL-defined content to be efficiently encapsulated in a SOAP-based envelope using the same encoding technology. No changes to the SOAP binding syntax are required. Appendix B presents a draft of the ASN.1 schema for SOAP that has been discussed in ITU-T meetings.

The ASN.1 Schema for the XML information set provides the capability to encode XML content that is not described by a schema. It defines an alternative to XML 1.0 serialization and, like the ASN.1 Schema for SOAP, ensures the application of a consistent encoding technology.

Fast annotations for WSDL allow services to explicitly state that a binding can support the Fast encoding (in addition to XML). Although Fast does not require any modification to WSDL, specifically to the SOAP binding, it may be appropriate to formalize the contract to state clearly that the binding supports Fast in addition to XML.

Impact Due to Loss of Self-description

Fast is designed to have minimal impact on the developer and to ensure compatibility with the SOAP standard. Standard WSDL tools, SOAP header processing and SOAP intermediaries are preserved. However, since Fast loses the self-descriptive nature of XML (the example in Section 4 explains this in more detail), existing standards and tools that rely on this mechanism will be impacted.

Security based on OASIS Web Services Security (SOAP Message Security) [ 17] is one such area that is impacted. In contrast to SOAP Message Security, where XPath expressions can be used to identify document components to be signed/encrypted, Fast can only sign/encrypt SOAP envelope components such as the body, the headers and the fault details. The implications of using XPath expressions has its own performance issues for the processing of SOAP messages (a DOM tree may have to be created) and it may be advantageous to identify a minimal subset of the Web Services security standard regardless of its applicability to Fast.

Fast and XML Encoding Example

An example of a WSDL contract is presented in Appendix A. This WSDL contract defines a single operation bound to the SOAP protocol using document literal encoding. The XML schema that abstractly defines the SOAP body of the operation (the input or output in this case) is as follows:

<xsd:complexType name="ComplexTypeSimple">


    <xsd:element name="varBoolean" type="xsd:boolean"/>

    <xsd:element name="varInt" type="xsd:integer"/>

    <xsd:element name="varString" type="xsd:string"/>



<xsd:element name="paramRefComplexTypeSimple"


The paramRefComplexTypeSimple element defines the SOAP body contents for both the input and the output of the operation. Using X.694, this can be mapped to an equivalent ASN.1 type:

ComplexTypeSimple ::= SEQUENCE {

  varBoolean BOOLEAN,

  varInt INTEGER,

  varString UTF8String


ParamRefComplexTypeSimple ::= ComplexTypeSimple

The following is an instance of a SOAP request (or response) encoded in XML 1.0:












An equivalent instance of the SOAP request (or response) as an ASN.1 value type using the Fast encoding looks like this:

soapBodyContent ParamRefComplexTypeSimple ::=  

  varBoolean TRUE,

  varInt 100,

  varString "string"

soapEnvelope ::= SoapEnvelope ::= {

  body-or-fault {

    body {


        id {

          qName {

            uri "",

            localName "paramRefComplexTypeSimple"



        content soapBodyContent





The qualified name

is used to identify the soapBodyContent value.

When encoded using the aligned variant of PER, the soapEnvelope value is as follows:

00000000 |

CHOICE of body-or-fault

00000001 |

length of SEQUENCE of body

00000002 |

CHOICE of id

1xxxxxxx |

bit-map for qName

00011111 |

length of the uri component

01101000 |


01110100 |




00011001 |

length of the localName component

01110000 |


01100001 |




1xxxxxxx |

TRUE of the varBoolean value

00000001 |

length of the varInt component

01100100 |

100 of the varInt value

00000110 |

length of the varString component

01110011 |


01110100 |


Only information that needs to be sent is actually encoded; the element names are not encoded. Note how values of type integer or boolean are encoded using an efficient binary form. Fast encodes the ASN.1 SOAP envelope in 72 bytes. The XML SOAP envelope is encoded in 272 bytes (without line feeds and white spaces).

It is worth pointing out that the XML envelope and the Fast envelope will require different MIME types such that clients and services can process the different encodings. Although not specifically mentioned, this is an important part of the standardization process highlighted below.

Fast and the Java Prototype

A Java prototype for end-to-end Fast Web Services has been implemented (taking advantage of the technologies in the Java Web Services Developer Pack 1.2 [ 18]) in order to test the ideas and to obtain the performance results which are presented below. The prototype has been implemented for:

  • JAX-RPC 1.1, JSR-101 [ 19], using JAXB, JSR-31 [ 20], for method parameters. JAXB has been modified for the marshaling and unmarshaling of XML or Fast schema encoded data (PER). JAX-RPC has been modified to use JAXB to compile XSD to Java classes that are used for remote method parameters.
  • J2ME Web Services, JSR-172 [ 21]. This has been implemented into the current reference implementation in a modular fashion.

Figure 3 presents the ideal goal of how Fast can be supported in a stack. A client and a service use WSDL-generated code, for example, stubs and ties, that is independent of the chosen runtime, XML or Fast.  Additionally, a client or a service may dynamically switch between XML or Fast, thus a service may serve XML and Fast clients concurrently.

Figure 3. XML and Fast stacks

At the time this article was written, the prototype supports document literal and RPC literal style and uses. Header support has yet to be implemented.

Prototype Performance Results

Loopback latency results for the prototype have been obtained for a basic Web service sending and receiving a data structure whose instances could easily be varied in size. Performance was compared with equivalent data structures for RMI, RMI/IIOP, JAX-RPC SOAP encoded and JAX-RPC XML literal. All Web service tests were performed using the Java Web Services Developer Pack 1.0, which uses Apache Tomcat as the servlet engine. RMI and RMI/IIOP results were performed using the standard implementations in the Java Runtime Environment 1.4.0 (it is recognized that the RMI/IIOP implementation is not as efficient as those provided by some application servers).

The XML schema representation was defined as follows:

<xsd:schema targetNamespace=""


  <xsd:complexType name="dataStoreType">


      <xsd:element name="data" type="xsd1:dataType"

        minOccurs="1" maxOccurs="unbounded"/>




  <xsd:complexType name="dataType">


      <xsd:element name="stringT" type="xsd:string"/>

      <xsd:element name="integerT" type="xsd:integer"/>

      <xsd:element name="booleanT" type="xsd:boolean"/>




Thus the xsd1:dataStoreType will contain one or more of xsd1:dataType, which in turn contains an xsd:string, xsd:integer and an xsd:boolean. The values used for one instance of xsd1:dataType, as represented in XML 1.0 are these:

<dataStore xmlns="">


    <stringT>this is a string</stringT>





Table 1 presents the loopback latency results for xsd1:dataStoreType with 20 elements.

Table 1. Loopback latency results

The first graph presents the actual latency time in milliseconds for the data store structure. In addition "void" tests for XML literal and Fast are presented. The void tests will be used later to estimate a breakdown of where time is spent in the Fast and XML stack. The second graph presents the percentage when compared to RMI; a value greater than 100% is slower than RMI.

The measurements show that Fast performs at 165% of RMI, is faster than RMI/IIOP and is approximately 4 times faster than XML literal. The difference between the Fast and XML void test is less marked because there is no SOAP body content and, consequently, no data binding.

Table 2 presents an estimated breakdown in layers for the Fast and XML literal loopback latency times.

Table 2. Loopback latency results

The three layers are defined as follows:

  1. Transport: the time to transmit the message using the HTTP protocol and dispatch to the deployed servlet in Tomcat.
  2. Protocol: the time to process the SOAP envelope according to the SOAP protocol.
  3. Application: the time to process the SOAP body content.

The transport and protocol layer together are estimated to be the equivalent of the void time, and the transport time is estimated from measuring HTTP POST tests for similar content sizes. Since the size of the encoded SOAP envelope for the test is small, it is assumed to be negligible on the protocol layer and to have a small effect on the transport layer because the Fast SOAP envelope is smaller than the XML SOAP envelope.

The breakdown shows that (1) the Fast transport is similar to XML literal, (2) the Fast protocol is approximately twice as fast, and (3) the application layer is approximately ten times as fast. This correlates well with previous performance evaluations of JAX-RPC where it was found that most of the time is spent going from XML to Java and vice-versa.

It follows from the data that Fast now spends the majority of time in the transport and protocol layer. This implies that improving the performance of these two layers will improve both Fast and XML but will additionally increase the speed-up factor between the two. The latter can be confirmed by keeping the transport and protocol layers fixed and increasing the size of data that needs to be processed by the application layer.

Table 3 presents a number of latency tests increasing the number of data elements in array. As the number of elements increases, the processing in the application layer gets larger when compared to the transport and protocol layers. As the data gets larger, the speed-up factor will tend towards that of just the application layers, as shown in Table 2. Thus when there are 500 elements, Fast performance is nearly 10 times that of XML literal. In other words, Fast will perform better as the size of the content increases.

Table 3. Size of data and increase in speed up factor

The size of the Fast-encoded SOAP envelope is approximately a fifth of the XML-encoded SOAP envelope. For 500 data elements, Fast is 11544 bytes, and XML is 51406 bytes.


This article has discussed the performance costs of traditional encodings of Web Services. The article then provides a fairly broad description of one of the techniques that we have explored for addressing this problem: the concept of Fast Web Services. Fast web services is designed to maximize the performance of Web Services in a number of domains, while minimizing developer impact and ensuring interoperability. The performance gains from Fast WS are very substantial although its applicability is not universal; there are some issues due to its loss of self-description that are not present when using XML encoding.

Performance results obtained from the Java prototype provide compelling evidence that it is possible for a Web Service implementation to perform at speeds close to that of binary equivalents such as RMI and RMI/IIOP. If performance is an issue then Fast may be the answer, and a number of use cases in which Fast can be used were presented.

Sun Microsystems is participating in the ITU-T SG-17 to ensure that Fast Web Services is standardized. The majority of the standardization process is complete (or close to be completed) given that X.694 and the ASN.1 encoding rules represent a significant proportion of work. X.695 represents the finishing touches that are needed for a well proven technology such as ASN.1 to be applied to Web Services.


  1. Kenneth Chiu, Madhusudhan Govindaraju, Randall Bramley. Investigating the Limits of SOAP Performance for Scientific Computing. 11th IEEE International Symposium on High Performance Distributed Computing HPDC-11 2002, p. 256. IEEE Computing Society, July 2002.

  2. Auto-ID and RFID

  3. Sun's Auto-ID architecture

  4. Open Mobile Alliance (OMA)

  5. OMA Mobile Web Services

  6. Web Services Description Language (WSDL)

  7. W3C XML Schema (XSD)

  8. Abstract Syntax Notation One (ASN.1)

  9. International Telecoms Union Telecommunication Standardization sector (ITU-T)

  10. ASN.1 overview and uses

  11. ITU-T Study Group 17 (SG-17)

  12. ITU-T SG-17 Question 12 (Q12/17)

  13. X.693: XML value notation for ASN.1 types

  14. X.694: Mapping from XML Schemas to ASN.1 modules

  15. ASN.1 Packed Encoding Rules: ITU-T Rec. X.691 (2002) | ISO/IEC 8825-2:2002

  16. SOAP SOAP Version 1.2 Part 1: Messaging Framework

  17. OASIS Web Services Security TC

  18. Java Web Services Developer Pack

  19. JAX-RPC, JSR-101

  20. JAXB, JSR-31

  21. J2ME Web Services, JSR-172


Paul Sandoz
Paul is a Staff Engineer at Sun Microsystems.
Santiago Pericas-Geertsen
Santiago is a Staff Engineer at Sun Microsystems.
Kohuske Kawaguchi
Kohsuke is a Member of Technical Staff at Sun Microsystems.
Marc Hadley
Marc is a Senior Staff Engineer at Sun Microsystems.
Eduardo Pelegri-Llopart
Eduardo is a Distinguished Engineer at Sun Microsystems.

Appendix A. WSDL Example

<?xml version="1.0" encoding="UTF-8"?>

<definitions name="SimpleDocLitService"








    <schema targetNamespace=""




      <xsd:complexType name="ComplexTypeSimple">


            <xsd:elementname="varBoolean" type="xsd:boolean"/>

            <xsd:element name="varInt" type="xsd:integer"/>

            <xsd:element name="varString" type="xsd:string"/>



      <xsd:element name="paramRefComplexTypeSimple"





  <message name="messageParamRefComplexTypeSimple">

    <part element="xsd1:paramRefComplexTypeSimple"




  <portType name="SimpleDocLitPortType">

    <operation name="echoParamRefComplexTypeSimple">

      <input message="tns:messageParamRefComplexTypeSimple"


      <output message="tns:messageParamRefComplexTypeSimple"





  <binding name="SimpleDocLitPortBinding"


    <soap:binding style="document"


    <operation name="echoParamRefComplexTypeSimple">


      <input name="messageParamRefComplexTypeSimpleRequest">

        <soap:body namespace=""



      <output name="messageParamRefComplexTypeSimpleResponse">

        <soap:body namespace=""






  <service name="SimpleDocLitService">

    <port binding="tns:SimpleDocLitPortBinding"








Appendix B. ASN.1 Schema for SOAP






  AnyURI, Int, Language, QName







SoapEnvelope ::= SEQUENCE {

  header SoapHeader OPTIONAL,

/* The provision for an optional SoapHeaders which can be an empty

   SEQUENCE OF, is deliberate and matches the semantics in

   W3C SOAP 1.2,



  body-or-fault CHOICE {

    body SoapBody,

    fault SoapFault




SoapHeader ::= SEQUENCE OF SoapHeaderBlock


SoapHeaderBlock ::= SEQUENCE {





  /* Version 1 systems shall behave as follows:

- if the node does not process the header block,

  then version 2 material should be relayed.

- if the node processes the header block, then the

  version 2 material should be ignored and not

  relayed if processing calls for reinsertion of the

  header block.



  content OpenContent



SoapBody ::= SEQUENCE OF OpenContent


SoapFault ::= SEQUENCE {

  faultCode SoapFaultCode,

  reasons SEQUENCE SIZE(1..MAX) OF SoapFaultReason,




  /* Version 1 systems shall ignore version 2 material. */


  detail OpenContent OPTIONAL



SoapFaultCode ::= SEQUENCE {

  code SoapFaultCodeValue,

  subCodes SEQUENCE OF XSD.QName



SoapFaultCodeValue ::= ENUMERATED {








SoapFaultReason ::= SEQUENCE {

  lang XSD.Language,

  text UTF8String



OpenContent ::= SEQUENCE {


  id Identifier,

  content OPEN.&Type



Identifier ::= CHOICE {


  qName XSD.QName



/* The value to be used for the Identifier (and the type of the

content) will be published in the WSDL specification of a given web

service, or in a SOAP module.

If a header is include in the formal WSDL contract then it is possible

to use an OID for identification purposes, otherwise use of QName is

recommended.  In the case of the body, the OID could always be







Have a question about programming? Use Java Online Support.

IMPORTANT: Please read our Licensing policy: