Recently, the Web Services Interoperability Organization (WS-I) board approved the board approval drafts of the Basic Profile 1.1 (BP1.1), the Simple Soap Binding Profile 1.0 (SSBP1.0), and the Attachments Profile 1.0 (AP1.0) (see Resources). A board approval draft comprises work that the WS-I Working Group that produced the document has approved. The approved documents are now before the WS-I membership for review and (hopefully) approval later this month (August 2004). Once approved by the WS-I membership, the document becomes WS-I Final Material. Testing Tools and Sample Application implementations for these profiles will enter their own approval cycles in the near future.
Many Web services developers and IT architects might wonder why WS-I published three profiles instead of simply incorporating the new support for SOAP Messages with Attachments (see Resources) and the WSDL1.1 MIME Binding Extension into a single profile. Others might wonder just what has changed between these new profiles and the Basic Profile 1.0 that was published as WS-I Final Material in August of 2003. In this paper, I explain the Basic Profile Working Group's rationale for making these changes and highlight any substantive changes.
WS-I did not choose to produce multiple profiles arbitrarily. The initial intent was to add support for SOAP with Attachments to the Basic Profile 1.0 and to call the new profile Basic Profile 1.1. However, for a variety of reasons this approach proved to be infeasible.
The three new profiles address both the need to address the customer requirement to provide guidance on the interoperable use of attachments today and the need to accommodate future bindings for technologies such as the W3C XML Protocol WG's MTOM and XOP (which many believe to be a superior solution to SOAP Messages with Attachments and which at some point in the future might replace its use entirely -- see Resources for more on these technologies). Essentially, the Basic Profile was re-architected to enable the composition of profiles that supported multiple bindings such as SOAP over HTTP, SOAP Messages with Attachments over HTTP and eventually MTOM/XOP over HTTP. It is conceivable that there might be other bindings in the future. The binding-specific requirements have been separated into their own profiles, each with its own conformance claim, and the testing tools have been modified to enable composition of the Test Assertion Documents (TAD) such that conformance to a set of relevant profiles can be measured.
Basically, if your Web service is not using attachments, then you would use the TAD composition of BP1.1 plus SSBP1.0 to test conformance. If you are using attachments, then you would use the TAD composition of BP1.1 plus AP1.0.
So, while there are now three profiles that cover roughly the same scope as the Basic Profile 1.0 (BP1.0), from the developer's perspective there are really only two meaningful compositions: BP1.1 plus SSBP1.0 and BP1.1 plus AP1.0.
Note also that Web services that use an alternate binding for SOAP, such as SOAP over FTP, JMS, or MQ, can use the BP1.1 stand-alone to assess conformance, which was not possible with BP1.0 because of the requirement to use SOAP/HTTP binding.
Basically, aside from the addition of interoperability guidance for SOAP Messages with Attachments and the WSDL MIME Binding Extension, not much has changed (aside from the architecture of the profile document itself) since the BP1.0 was published as WS-I Final Material in August of 2003. The Basic Profile Working Group (BPWG) has been maintaining both editorial and some technical issues in an errata document (see Resources). Most of the errata comprise editorial clarifications so as to remove ambiguity of interpretation and make other editorial tweaks. As you would expect, the BPWG has incorporated all of the errata against BP1.0 into the new profiles.
Thus, a Web service (and its artifacts) that conforms to the new BP1.1 plus SSBP1.0 profiles is basically equivalent to a claim of conformance to BP1.0 plus its published errata. Conversely, if your Web service(s) were conformant to BP1.0, then it is most likely that it's also conformant to the composition of BP1.1 plus SSBP1.0. To be certain, you should test your Web service and its artifacts against the new release of the WS-I Testing Tools and corresponding BP1.1 and SSBP1.0 TAD(s) when they are released. However, it is more than likely that you will not need to make any changes to your Web service.
One of the most significant changes in support of the re-architecting of the Basic Profile is the bifurcation of the MESSAGE target into MESSAGE and ENVELOPE so that you can make a clearer distinction between the SOAP envelope and the HTTP message for purposes of testing conformance. However, this change doesn't really affect the actual conformance of a Web service or its artifacts because, other than changing the conformance target itself, the requirements remained the same. The following requirements were changed solely to replace the conformance target of MESSAGE with the new conformance target, ENVELOPE:
| R1031, R1005, R1006, R1008, R1009, R1011, R1013, R1014, R2211, R2301, R2725, R2729, | |
| R2735, R2738, R2739, R2753, R2752 |
Additionally, the following requirements were modified such that the term message was replaced with the term envelope to be consistent with the revised conformance targets that distinguish between the SOAP envelope and the HTTP message:
| R2751, R2748, R1025, R1027, R1028, R1029 |
Again, aside from making the distinction between message and envelope, these requirements are otherwise unchanged since BP1.0.
In the original Basic Profile 1.0, there were a number of places where there was inconsistent use of terminology. The new profiles provide a more consistent use of terms throughout so that there is less ambiguity or confusion.
The following requirements were changed to align on the use of the term 'fault' as opposed to either 'fault message' or 'SOAP fault', but again are otherwise unchanged since BP1.0:
| R1002, R1016, R1003, R1029, R1030, R1119, R1126 |
A number of requirements were removed for various reasons. I provide below the rationale for each of the requirements removed.
A number of requirements were removed because they are related to the conformance claim attachment mechanisms and therefore did not really constitute interoperability requirements. The requirement mechanism was used to specify how you could attach conformance claim mark-up to various artifacts to provide a concise description, but the BPWG decided that they added little value as requirements.
| R0002, R0003, R0004, R0005, R0006, R0007, R3004, R3005, R3020, R3021, R3030 |
The following requirement was removed because it was redundant with R2707:
R2728 A wsdl:binding in a DESCRIPTION that omits the use attribute on a contained soapbind:fault element MUST be interpreted as though use="literal" had been specified.
The following requirement was removed because the BPWG felt that this requirement generated unnecessary confusion. It was originally intended to clarify discussion regarding the use of port 80, but, in hindsight, decided that nothing needed to be said:
R1110 An INSTANCE MAY accept connections on TCP port 80 (HTTP).
The following requirements were consolidated into a new requirement (R2030):
R2020 The wsdl:documentation element MAY occur as a child of the wsdl:import element in a DESCRIPTION.
R2021 The wsdl:documentation element MAY occur as a child of the wsdl:part element in a DESCRIPTION.
R2024 The wsdl:documentation element MAY occur as a first child of the wsdl:definitions element in a DESCRIPTION.
R2030 In a DESCRIPTION the wsdl:documentation element MAY be present as the first child element of wsdl:import, wsdl:part and wsdl:definitions in addition to the elements cited in the WSDL1.1 specification.
The following requirements have been relocated to the Simple Soap Binding Profile 1.0 because they pertain specifically to the SOAP over HTTP binding:
| R4001, R1010, R1012, R1018, R2401 (note: the BPWG renumbered some of these). |
The Basic Profile 1.0, as with all profiles, is comprised of both normative content (requirements of the form Rnnnn) and non-normative content (rationale and explanatory prose, and examples). Some of the non-normative prose was of a nature that many in the BPWG felt should be characterized as requirements. Addressing this issue, the following were elevated from non-normative prose to normative requirements of the Basic Profile 1.1:
R2803 In a DESCRIPTION, the namespace attribute of the wsdl:import MUST NOT be a relative URI.
R2212 An ENVELOPE MUST contain exactly one part accessor element for each of the wsdl:part elements bound to the envelope's corresponding soapbind:body element.
R2213 In a doc-literal description where the value of the parts attribute of soapbind:body is an empty string, the corresponding ENVELOPE MUST have no element content in the soap:Body element.
R2214 In a rpc-literal description where the value of the parts attribute of soapbind:body is an empty string, the corresponding ENVELOPE MUST have no part accessor elements.
R9980 An ENVELOPE MUST conform to the structure specified in SOAP 1.1 Section 4, "SOAP Envelope" (subject to amendment by the Profile).
R2755 The part accessor elements in a MESSAGE described with an rpc-literal binding MUST have a local name of the same value as the name attribute of the corresponding wsdl:part element.
The following requirement was added to address an interoperability issue that was not addressed in BP1.0 -- namely the use of the xml: namespace prefix in WSDL descriptions. While an errata to the Namespaces in XML Recommendation had been published, and many parser implementations updated to handle documents with an explicit namespace declaration for the xml: prefix, there is much in the way of deployed parsers and processors that have not yet been patched to handle this situation. Hence, the BP1.1 recommends against the practice in cases where interoperability is a key requirement.
R1034 A DESCRIPTION SHOULD NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".
Additionally, the following new requirements, not previously present in BP1.0, were added to the SSBP1.0 with the intent that it could be concluded that only the SOAP binding could be used:
R9700 A MESSAGE MUST serialize the envelope as the exclusive payload of the HTTP entity-body.
R9701 A MESSAGE MUST serialize the envelope as XML 1.0.
R9702 A MESSAGE MUST have a "Content-Type" HTTP header field.
R9703 A MESSAGE's "Content-Type" HTTP header field MUST have a field-value whose media type is "text/xml".
R9802 A wsdl:binding element in a DESCRIPTION MUST only use the WSDL SOAP Binding as defined in WSDL 1.1 Section 3.
R9800 In a DESCRIPTION WSDL binding extension elements and attributes which cause messages on the wire to be non-conformant to the Profile MUST NOT be used.
R9801 In a DESCRIPTION the WSDL MIME and HTTP GET/POST and DIME binding extensions MUST NOT appear in the SOAP binding.
And lastly, this requirement was added to the SSBP1.0 to clarify that the character encoding specified in the MIME header always overrides whatever is specified in the instance document:
R1019 A RECEIVER MUST ignore the encoding pseudo-attribute of the envelope's XML declaration in a message.
And finally, a total of thirty six requirements were modified to provide improved clarity and to restate the requirement in more precise terms, eliminating the possibility of ambiguous interpretation. As you can see below, their essence really hasn't changed. I detail each of these changes below with the wording both before and after, followed by a brief explanation as to the motivation and nature of the change.
| Requirement | BP1.0 | BP1.1 |
| R0001 | An INSTANCE MUST be described by a WSDL 1.1 service description, by a UDDI binding template, or both. | Either an INSTANCE's WSDL 1.1 description, its UDDI binding template, or both MUST be available to an authorized consumer upon request. |
Some had complained that requirement R0001 was unclear as to what be described meant. Ultimately, the BPWG concluded that it meant that either the WSDL description or the UDDI template must be available to an authorized consumer. Hence, it would be possible that an instance were capable of generating these upon request by an authorized consumer, rather than requiring that the artifact actually exist.
| Requirement | BP1.0 | BP1.1 |
| R1000 | When a MESSAGE contains a soap:Fault element, that element MUST NOT have element children other than faultcode, faultstring, faultactor and detail. | When an ENVELOPE is a Fault, the soap:Fault element MUST NOT have element children other than faultcode, faultstring, faultactor and detail. |
| R1001 | When a MESSAGE contains a soap:Fault element its element children MUST be unqualified. | When a MESSAGE contains a soap:Fault element its element children MUST be unqualified. |
The changes to R1000 and R1001 entail the use of the ENVELOPE conformance target and the alignment of terminology around the use of the term Fault.
| Requirement | BP1.0 | BP1.1 |
| R1004 | When a MESSAGE contains a faultcode element the content of that element SHOULD be one of the fault codes defined in SOAP 1.1 or a namespace qualified fault code. | When an ENVELOPE contains a faultcode element, the content of that element SHOULD be either one of the fault codes defined in SOAP 1.1 (supplying additional information if necessary in the detail element), or a Qname whose namespace is controlled by the fault's specifying authority (in that order of preference). |
Requirement R1004 was changed a little more substantively than simply fixing the conformance target and aligning the terminology. There was some concern that the intent of the BPWG was not clearly expressed. In addition to the changes in the requirement text, there were also changes made to the rationale and explanatory text. Basically, the idea behind these changes was to make it abundantly clear that the preferred use of the faultcode element was to use one of the faultcodes specified in SOAP1.1. Use of a QName is better than the dot notation defined in SOAP1.1, but still presents some potential for interoperability problems dealing with interpretation of the meaning of the fault.
| Requirement | BP1.0 | BP1.1 |
| R1007 | A MESSAGE described in an rpc-literal binding MUST NOT contain soap:encodingStyle attribute on any elements are grandchildren of soap:Body. | An ENVELOPE described in an rpc-literal binding MUST NOT contain soap:encodingStyle attribute on any element that is a grandchild of soap:Body. |
Requirement R1007 was modified to accommodate the new ENVELOPE conformance target as well as to fix some grammatical errors.
| Requirement | BP1.0 | BP1.1 |
| R1113 | An INSTANCE SHOULD use a "400 Bad Request "HTTP status code, if the request message is a malformed HTTP request, or not well-formed XML. | An INSTANCE SHOULD use a "400 Bad Request" HTTP status code, if a HTTP request message is malformed. |
Requirement R1113 was changed to be consistent with the intent of HTTP 400 Bad Request semantics. Also, given that the BP1.1 is also a foundation for the Attachments Profile 1.0, it needed to be clear that any aspect of the message that was malformed should result in a 400 Bad Request HTTP Response.
| Requirement | BP1.0 | BP1.1 |
| R1107 | A RECEIVER MUST interpret SOAP messages containing only a soap:Fault element as a Fault. | A RECEIVER MUST interpret a SOAP message as a Fault when the soap:Body of the message has a single soap:Fault child. |
Requirement R1107 was changed to be more precise as to the definition of a SOAP Fault. Obviously, a message might contain headers (for instance) and still be considered a Fault. However, the language used was imprecise enough as to create some doubt.
| Requirement | BP1.0 | BP1.1 |
| R1114 | An INSTANCE SHOULD use a "405 Method not Allowed" HTTP status code if the request method was not "POST". | An INSTANCE SHOULD use a "405 Method not Allowed" HTTP status code if a HTTP request message's method is not "POST". |
Requirement R1114 was modified to make it clear that it only applied to the HTTP request message's method.
| Requirement | BP1.0 | BP1.1 |
| R1115 | An INSTANCE SHOULD use a "415 Unsupported Media Type" HTTP status code if the Content-Type HTTP request header did not have a value consistent with the value specified for the corresponding binding of the input message. | An INSTANCE SHOULD use a "415 Unsupported Media Type" HTTP status code if a HTTP request message's Content-Type header field-value is not permitted by its WSDL description. |
The language used for R1115 in BP1.0 was a little unclear. For instance, some inquired as to what value specified meant.
| Requirement | BP1.0 | BP1.1 |
| R1124 | An INSTANCE MUST use a 2xx HTTP status code for responses that indicate a successful outcome of a request. | An INSTANCE MUST use a 2xx HTTP status code on a response message that indicates the successful outcome of a HTTP request. |
Requirement R1124 was simply tweaked editorially to make it clear that it applied to an HTTP request.
| Requirement | BP1.0 | BP1.1 |
| R1130 | An INSTANCE MUST use HTTP status code "307 Temporary Redirect" when redirecting a request to a different endpoint. | An INSTANCE MUST use the "307 Temporary Redirect" HTTP status code when redirecting a request to a different endpoint. |
Requirement R1130 was merely tweaked editorially. It has the same meaning as it did in BP1.0.
| Requirement | BP1.0 | BP1.1 |
| R2004 | A DESCRIPTION MUST NOT use the XML Schema "import" statement to import a Schema from any document whose root element is not "schema" from the namespace "http://www.w3.org/2001/XMLSchema". | In a DESCRIPTION the schemaLocation attribute of an xsd:import element MUST NOT resolve to any document whose root element is not "schema" from the namespace "http://www.w3.org/2001/XMLSchema". |
Requirement R2004 was changed to be more precise in stating the constraint to satisfy the Testing Tools BPWG members who were unclear as to what it was that they should test.
| Requirement | BP1.0 | BP1.1 |
| R2008 | In a DESCRIPTION the value of the location attribute of a wsdl:import element SHOULD be treated as a hint. | A CONSUMER MAY, but need not, retrieve a WSDL description from the URI specified in the location attribute on a wsdl:import element. |
Requirement R2008 was modified to have a different conformance target since there is no way to measure conformance on the part of the DESCRIPTION since it takes no action.
| Requirement | BP1.0 | BP1.1 |
| R2027 | If during the processing of an element in the WSDL namespace in a description, a consumer encounters a WSDL extension element amongst its element children, that has a wsdl:required attribute with a boolean value of "true" that the consumer does not understand or cannot process, the CONSUMER MUST fail processing of that element in the WSDL namespace. | If during the processing of a description, a consumer encounters a WSDL extension element that has a wsdl:required attribute with a boolean value of "true" that the consumer does not understand or cannot process, the CONSUMER MUST fail processing. |
Requirement R2027 was shortened editorially to make it clearer.
| Requirement | BP1.0 | BP1.1 |
| R2101 | A DESCRIPTION MUST NOT use QName references to elements in namespaces that have been neither imported, nor defined in the referring WSDL document. | A DESCRIPTION MUST NOT use QName references to WSDL components in namespaces that have been neither imported, nor defined in the referring WSDL document. |
Requirement R2101 was modified to use the term WSDL component rather than element to make it more consistent with the WSDL specification.
| Requirement | BP1.0 | BP1.1 |
| R2110 | In a DESCRIPTION, array declarations MUST NOT extend or restrict the soapenc:Array type. | In a DESCRIPTION, declarations MUST NOT extend or restrict the soapenc:Array type. |
| R2111 | In a DESCRIPTION, array declarations MUST NOT use wsdl:arrayType attribute in the type declaration. | In a DESCRIPTION, declarations MUST NOT use wsdl:arrayType attribute in the type declaration. |
| R2112 | In a DESCRIPTION, array declaration wrapper elements SHOULD NOT be named using the convention ArrayOfXXX. | In a DESCRIPTION, elements SHOULD NOT be named using the convention ArrayOfXXX. |
| R2113 | A MESSAGE containing serialized arrays MUST NOT include the soapenc:arrayType attribute. | An ENVELOPE MUST NOT include the soapenc:arrayType attribute. |
Requirements R2110 through R2113 used the term serialized arrays and array. It was pointed out that there was no way in a literal schema definition to determine that something was a serialized array. Hence, these requirements were all restated simply to eliminate the use of those terms since they had no XML Schema correlary. Their meaning was not changed though, and the Testing Tools "do the right thing" in their current and future incarnations.
| Requirement | BP1.0 | BP1.1 |
| R2209 | A wsdl:binding in a DESCRIPTION SHOULD bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers to one of soapbind:body, soapbind:header, soapbind:fault or soapbind:headerfault. | A wsdl:binding in a DESCRIPTION SHOULD bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers with a binding extension element. |
Requirement R2209 was modified so as not to explicitly refer to the soapbind:body and similar elements because BP1.1 is intended also as a base for AP1.0 and possibly other binding profiles. Since it would be required to modify the BP profile each time a new binding were added, it was decided that these enumerated components should be simply re-characterized with a generic term. Again, the meaning was unchanged.
| Requirement | BP1.0 | BP1.1 |
| R2305 | A wsdl:portType in a DESCRIPTION MUST be constructed so that the parameterOrder attribute, if present, omits at most 1 wsdl:part from the output message. | A wsdl:operation element child of a wsdl:portType element in a DESCRIPTION MUST be constructed so that the parameterOrder attribute, if present, omits at most 1 wsdl:part from the output message. |
Requirement R2305 was modified to be more specific as to the location of the parameterOrder attribute because it only applies to the wsdl:operation children of a wsdl:portType.
| Requirement | BP1.0 | BP1.1 |
| R2705 | A wsdl:binding in a DESCRIPTION MUST use either be a rpc-literal binding or a document-literal binding. | A wsdl:binding in a DESCRIPTION MUST either be a rpc-literal binding or a document-literal binding. |
Clearly, this requirement had a typo left from an earlier incarnation of the requirement text.
| Requirement | BP1.0 | BP1.1 |
| R2710 | The operations in a wsdl:binding in a DESCRIPTION MUST result in wire signatures that are different from one another. | The operations in a wsdl:binding in a DESCRIPTION MUST result in operation signatures that are different from one another. |
This requirement used the term wire signatures which some people had complaints about. The term chosen to replace it is operation signature and this new term was formally defined in a new glossary section of the profile.
| Requirement | BP1.0 | BP1.1 |
| R2712 | A document-literal binding MUST be represented on the wire as a MESSAGE with a soap:Body whose child element is an instance of the global element declaration referenced by the corresponding wsdl:message part. | A document-literal binding MUST be serialized as an ENVELOPE with a soap:Body whose child element is an instance of the global element declaration referenced by the corresponding wsdl:message part. |
For the term wire signature to be consistent, the usage of the term wire was replaced with operation. Nothing else changed and the true intent of requirement R2712 remains unchanged as well.
| Requirement | BP1.0 | BP1.1 |
| R2720 | A wsdl:binding in a DESCRIPTION MUST use the attribute named part with a schema type of "NMTOKEN" on all contained soapbind:header and soapbind:headerfault elements. | A wsdl:binding in a DESCRIPTION MUST use the part attribute with a schema type of "NMTOKEN" on all contained soapbind:header and soapbind:headerfault elements. |
The requirement text for R2720 was changed simply to make it read more clearly.
| Requirement | BP1.0 | BP1.1 |
| R2724 | If an INSTANCE receives a message that is inconsistent with its WSDL description, it SHOULD generate a soap:Fault with a faultcode of "Client", unless a "MustUnderstand" or "VersionMismatch" fault is generated. | For one-way operations, an INSTANCE MUST NOT return a HTTP response that contains an envelope. Specifically, the HTTP response entity-body must be empty. |
Requirement R2724 from BP1.0 was actually consolidated into another and the requirement number was reused for a new requirement that made it clear that the HTTP response message for one-way operations must be empty.
| Requirement | BP1.0 | BP1.1 |
| R2737 | A MESSAGE described with an rpc-literal binding MUST namespace qualify the children of part accessor elements for the parameters and the return value with the targetNamespace in which their types are defined. | An ENVELOPE described with an rpc-literal binding MUST namespace qualify the descendents of part accessor elements for the parameters and the return value, as defined by the schema in which the part accessor types are defined. |
In addition to usage of the new ENVELOPE conformance target, requirement R2737 was also changed to make it unambiguous as to what their referenced; the accessor types.
| Requirement | BP1.0 | BP1.1 |
| R2742 | A MESSAGE MAY contain a fault detail entry in a SOAP fault that is not described by a wsdl:fault element in the corresponding WSDL description. | An ENVELOPE MAY contain fault with a detail element that is not described by a soapbind:fault element in the corresponding WSDL description. |
| R2743 | A MESSAGE MAY contain the details of a header processing related fault in a SOAP header block that is not described by a wsdl:headerfault element in the corresponding WSDL description. | An ENVELOPE MAY contain the details of a header processing related fault in a SOAP header block that is not described by a soapbind:headerfault element in the corresponding WSDL description. |
In BP1.0, requirements R2742 and R2743 incorrectly used the wsdl namespace prefix instead of the soapbind namespace prefix. Additionally, their conformance targets were changed to ENVELOPE.
| Requirement | BP1.0 | BP1.1 |
| R2749 | A wsdl:binding in a DESCRIPTION MUST NOT use the attribute named parts on contained soapbind:header and soapbind:headerfault elements. | A wsdl:binding in a DESCRIPTION MUST NOT use the parts attribute on contained soapbind:header and soapbind:headerfault elements. |
Requirement R2749 was changed editorially to be more easily parsed by the reader.
| Requirement | BP1.0 | BP1.1 |
| R2750 | A CONSUMER MUST ignore a SOAP response carried in a response from a one-way operation. | A CONSUMER MUST ignore an envelope carried in a HTTP response message in a one-way operation. |
And finally, requirement R2750 was modified to use the term envelope instead of SOAP response in order to be consistent with the usage of the new conformance target terminology.
Of course, in addition to all of the changes described in this article, the BPWG has made other editorial improvements to the non-normative rationale and explanatory prose and added a few more examples to reinforce the improvements made to the text of the requirements.
Overall, these three new profiles represent a significant improvement in quality, and hence enhance the potential for achieving interoperability between conformant Web services and their consumers.
- Find all three board approval drafts of the new profiles on the Web Services Interoperability Organization's Web site:
- Basic Profile 1.1 (BP1.1)
- Simple Soap Binding Profile 1.0 (SSBP1.0)
- Attachments Profile 1.0 (AP1.0)
- Find out more about SOAP Messages with Attachments (WS-I)
- Explore W3C XML Protocol WG's MTOM and XOP, examples of the technologies for which the three new profiles endeavor to accommodate future bindings.
- Learn more about the W3C XML Protocol Working Group.
- Read the Basic Profile Working Group's errata document, in which it maintains both some editorial and some technical issues.
- Access Web services knowledge, tools, and skills with Speed-start Web services, which offers the latest Java-based software development tools and middleware from IBM (trial editions), plus online tutorials and articles, and an online technical forum.
- Browse for books on these and other technical topics.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
Chris Ferris is a Senior Technical Staff Member in the IBM Emerging Technology group. He has been involved in the architecture, design, and engineering of distributed systems for most of his 25+ year career in IT and has been actively engaged in open standards development for XML and Web services since 1999. He currently chairs the WS-I Basic Profiles Working Group, is an elected member of the OASIS Technical Advisory Board, and is also a co-author and editor of the WS-ReliableMessaging specification.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
WebSphere Application Server can leverage its built in Web Services support to expose services to remote consumers in an industry-standard way.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and includes built in Web Services support.
- Article: Learn how to use of the JAX-WS programming model to create dispatch and dynamic proxy clients and how to create an asynchronous Web service client.
- Tutorial: This tutorial takes you through the steps to deploy Data Web Services to the WebSphere Application Server Community Edition.
- Demo: This demo shows how to extract and install the IBM Java Platform, Java EE 5 SDK with WebSphere Application Server.
- Buy: WebSphere Application Server - Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
