WebMethods SOAP Developer's Guide - Software AG Documentation

(1)

Developer

Version 7.1

SOAP Developer’s Guide

Title Page

(2)

Cerebra, Glue, Infravio X‐Broker, Infravio X‐Registry, Infravio, My webMethods Server, My webMethods, webMethods Access, webMethods Administrator, webMethods Broker, webMethods Central Configuration, webMethods Dashboard, webMethods Designer, webMethods Developer, webMethods Fabric, webMethods Glue, webMethods Infrastructure Data Collector, webMethods Infravio X‐Broker, webMethods Infravio X‐Registry, webMethods Installer, webMethods Integration Server, webMethods logo, webMethods Mainframe, webMethods Manager, webMethods Modeler, webMethods Monitor, webMethods Optimize for Infrastructure, webMethods Optimize for Process, webMethods Optimize, webMethods Portal, webMethods Process Engine, webMethods Servicenet, webMethods Task Engine, webMethods Trading Networks, webMethods Workflow, and webMethods are either registered trademarks or trademarks of webMethods, Inc. Acrobat, Acrobat, and Reader are registered trademarks of Adobe Systems Incorporated. Amdocs and ClarifyCRM are registered trademarks of Amdocs. Ariba is a registered trademark of Ariba, Inc. BEA, BEA WebLogic Server, Jolt, and Tuxedo are registered trademarks, and BEA WebLogic Platform is a trademark of BEA Systems, Inc. Action Request System, BMC Software, PATROL, and Remedy are registered trademarks of BMC Software, Inc. BroadVision is a registered trademark of BroadVision, Inc. Chem eStandards and CIDX are trademarks of CIDX, The Chemical Industry Data Exchange. SiteMinder and Unicenter are registered trademarks of CA, Inc. PopChart is a registered trademark of CORDA Technologies, Inc. Kenan and Arbor are registered trademarks of Alcatel‐Lucent. Data Connection and SNAP‐IX are registered trademarks of Data Connection Corporation. D&B and D‐U‐N‐S are registered trademarks of Dun & Bradstreet Corporation. Eclipse is a trademark of Eclipse Foundation, Inc. Entrust is a registered trademark of Entrust, Inc. papiNet is a registered trademark of the European Union and the United States. Financial Information eXchange, F.I.X, and F.I.X Protocol are trademarks of FIX Protocol Ltd. UCCnet and eBusinessReady are registered trademarks, and 1SYNC and Transora are trademarks of GS1 US. Hewlett‐Packard, HP, HP‐UX, OpenView, PA‐ RISC, and SNAplus2 are trademarks of Hewlett‐Packard Company. i2 is a registered trademark of i2 Technologies, Inc. AIX, AS/400, CICS, ClearCase, DB2, Domino, IBM, Informix, Infoprint, Lotus, Lotus Notes, MQSeries, OS/390, OS/400, RACF, RS/6000, SQL/400, S/390, System/390, VTAM, and WebSphere, and z/OS are registered trademarks; and Communications System for Windows NT, DB2 Universal Database, IMS, MVS, and SQL/DS are trademarks of IBM Corporation. InnoDB is a trademark of Innobase Oy. Itanium is a registered trademark of Intel Corporation. Linux is a registered trademark of Linus Torvalds. W3C is a registered trademark, and X Window System is a trademark of the Massachusetts Institute of Technology. MetaSolv is a registered trademark of Metasolv Software, Inc. ActiveX, Microsoft, Outlook, Visual Basic, Visual SourceSafe, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation. Six Sigma is a registered trademark of Motorola, Inc. Firefox and Mozilla are registered trademarks of the Mozilla Foundation. MySQL is a registered trademark of MySQL AB. nCipher is a trademark of nCipher Corporation Ltd. Eclipse is a trademark of Eclipse Foundation, Inc. Entrust is a registered trademark of Entrust, Inc. papiNet is a registered trademark of the European Union and the United States. Financial Information eXchange, F.I.X, and F.I.X Protocol are trademarks of FIX Protocol Ltd. UCCnet and eBusinessReady are registered trademarks, and 1SYNC and Transora are trademarks of GS1 US. Hewlett‐Packard, HP, HP‐UX, OpenView, PA‐RISC, and SNAplus2 are trademarks of Hewlett‐Packard Company. i2 is a registered trademark of i2 Technologies, Inc. AIX, AS/400, CICS, ClearCase, DB2, Domino, IBM, Informix, Infoprint, Lotus, Lotus Notes, MQSeries, OS/390, OS/400, RACF, RS/6000, SQL/400, S/390, System/390, VTAM, and WebSphere, and z/OS are registered trademarks; and Communications System for Windows NT, DB2 Universal Database, IMS, MVS, and SQL/DS are trademarks of IBM Corporation. InnoDB is a trademark of Innobase Oy. Itanium is a registered trademark of Intel Corporation. Teradata is a registered trademark of NCR Corporation. Netscape is a registered trademark of Netscape Communications Corporation. ServletExec is a registered trademark, and New Atlanta is a trademark of New Atlanta Communications, LLC. SUSE is a registered trademark of Novell, Inc. Appia is a registered trademark and Javelin Technologies is a trademark of NYFIX, Inc. CORBA is a registered trademark of Object Management Group, Inc. JD Edwards, OneWorld, Oracle, PeopleSoft, Siebel, and Vantive are registered trademarks; and Infranet, PeopleSoft Pure Internet Architecture, Portal, and WorldSoftware are trademarks of Oracle Corporation. Perforce is a trademark of Perforce Software. JBoss and Red Hat are registered trademarks of Red Hat, Inc. PIP and RosettaNet are trademarks of RosettaNet, a non‐profit organization. SAP and R/3 are registered trademarks of SAP AG. PVCS is a registered trademark of Serena Software, Inc. SWIFT and SWIFTNet are registered trademarks of Society for Worldwide Interbank Financial Telecommunication SCRL. SPARC and SPARCStation are registered trademarks of SPARC International, Inc. BAAN and SSA are registered trademarks; and SSA Global is a trademark of SSA Global Technologies, Inc. EJB, Enterprise JavaBeans, Java, JavaServer, JDBC, JSP, J2EE, Solaris, Sun, and Sun Microsystems are registered trademarks; and Java Naming and Directory Interface, JavaServer Pages, SOAP with Attachments API for Java, and SunSoft are trademarks of Sun Microsystems, Inc. Sybase is a registered trademark of Sybase, Inc. VERITAS is a registered trademark, and VERITAS Cluster Server is a trademark of Symantec Corporation. UNIX is a registered trademark of The Open Group. Unicode is a trademark of Unicode, Inc. VeriSign is a registered trademark of Verisign, Inc. Software AG and all Software AG product names are either trademarks or registered trademarks of Software AG. Copyright & Docu‐ ment ID

(3)

Contents

About This Guide

Welcome to the SOAP Developer’s Guide. This guide describes how to use the webMethods Integration Server to exchange SOAP messages over the Internet. It is for solution developers who need to understand: How to receive and process SOAP messages and SOAP remote procedure calls with the webMethods Integration Server. How to submit SOAP messages and SOAP remote procedure calls to other servers.

Document Conventions

Additional Information

The webMethods Advantage Web site at http://advantage.webmethods.com provides you with important sources of information about webMethods products:

Troubleshooting Information. The webMethods Knowledge Base provides troubleshooting information for many webMethods products. Convention Description Bold Identifies elements on a screen. Italic Identifies variable information that you must supply or change based on your specific situation or environment. Identifies terms the first time they are defined in text. Also identifies service input and output variables.

Narrow font Identifies storage locations for services on the webMethods Integration Server using the convention folder.subfolder:service. Typewriter font Identifies characters and values that you must type exactly or messages that the system displays on the console. UPPERCASE Identifies keyboard keys. Keys that you must press simultaneously are joined with the “+” symbol. \ Directory paths use the “\” directory delimiter unless the subject is UNIX‐specific. [ ] Optional keywords or values are enclosed in [ ]. Do not type the [ ] symbols in your own code.

(8)

About This Guide

Documentation Feedback. To provide feedback on webMethods documentation, go to

the Documentation Feedback Form on the webMethods Bookshelf.

Additional Documentation. Starting with 7.0, you have the option of downloading the

documentation during product installation to a single directory called

“_documentation,” located by default under the webMethods installation directory. In addition, you can find documentation for all webMethods products on the

(9)

Chapter 1. Overview of SOAP

What is SOAP? . . . 10 What Does a SOAP Message Look Like? . . . 10

(10)

1. Overview of SOAP

What is SOAP?

The Simple Object Access Protocol (SOAP) is a standard, lightweight protocol for

exchanging messages across the Internet. It uses XML to define a basic message packet that can be used to convey an arbitrary XML document or a remote procedure call (RPC).

What Does a SOAP Message Look Like?

A SOAP message uses XML to form a simple message packet. The packet consists of an envelope that encloses two elements: an optional header and a mandatory body.

A simple SOAP message packet

SOAP Header (optional) SOAP Envelope SOAP Body <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <JournalEntry xmlns="http://www.gsx.com/gl/"> <entry> <Id>2398</Id> <amt>237.50</amt> <acct>Cash</acct> </entry> </JournalEntry> </SOAP-ENV:Body> <SOAP-ENV:Header> <MSG:priority xmlns:MSG="http://www.gsx.com/gl/">9</MSG:priority> </SOAP-ENV:Header> </SOAP-ENV:Envelope> Note: Although not shown in the example above, SOAP 1.1 also allows additional, implementation‐specific elements to follow the body of a SOAP message. In this book, such elements are referred to as trailers. For more information about trailers, see “Trailers” on page 18. Trailers are not supported with SOAP 1.2.

(11)

The Envelope

The envelope is the top‐level element in a SOAP message. It is the “container” that holds the entire message. The envelope must be the first (that is, the outermost) element in a SOAP message. It has the name Envelope. The envelope may contain a header element. When a SOAP message contains a header, the header element must be the first child within the envelope. For additional information about the header element, see “The Header” on page 12. The envelope must contain a body element. The body carries the content of the message. For more information about the body element see “The Body” on page 15. The envelope must be associated with a SOAP namespace. The SOAP namespace serves as the qualifier for the message’s SOAP‐related elements and attributes. It also specifies the XML schema to which the message conforms. For additional information about the SOAP namespace, see “The SOAP Namespace Declaration” below.

The envelope may include other implementation‐specific namespace declarations. The envelope may contain the encodingStyle attribute, which specifies the way in which the elements within the envelope are serialized and deserialized. The envelope may contain additional implementation‐specific attributes, but if it does, these attributes must be namespace qualified. The envelope may contain additional implementation‐specific children besides the header and body elements; however, if it does, the additional elements must be namespace qualified and must follow the body element.

The SOAP Namespace Declaration

The primary purpose of the SOAP namespace is to distinguish SOAP‐related elements and attributes from the application‐specific elements and attributes conveyed in the message. The SOAP namespace also serves another purpose; it specifies the schema to which the SOAP message conforms.

A SOAP 1.1 message uses the namespace http://schemas.xmlsoap.org/soap/envelope/ to qualify the elements and attributes that make up the SOAP message packet. A SOAP 1.2 message uses the namespace http://www.w3.org/2003/05/soap-envelope/. A SOAP message must declare this namespace in the SOAP envelope. By convention, the prefix SOAP-ENV (for SOAP 1.1) and env (for SOAP 1.2) is given to the SOAP namespace; however, a message may use any prefix to represent the SOAP namespace.

(12)

1. Overview of SOAP Messages that conform to the Simple Object Access Protocol (SOAP) 1.1 ‐ W3C Note 08 May 2000 use the namespace http://schemas.xmlsoap.org/soap/envelope/ and those that conform to the SOAP 1.2 W3C Recommendation 27 April 2007 specification use the namespace http://www.w3.org/2003/05/soap-envelope/. Messages whose envelopes declare a different namespace, or no namespace, are considered invalid and are rejected by Integration Server.

The Header

A SOAP message can include an optional header component to store additional information. The header element provides a place where a sender can pass auxiliary, implementation‐specific information such as authorization codes, routing information, version numbers, or message IDs. For example, if your solution routes invoices through one or more approval steps before passing it to an accounts‐payable processor, the header could hold the document’s routing information. When a header is included in a SOAP message, it must appear as the first child element within the envelope and must have the name Header. A header may contain one or more child elements. Each child is referred to as a header entry. All header entries must be namespace qualified.

...and is used to qualify the elements and attributes that make up the SOAP packet. The SOAP namespace is declared in the envelope element... <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> . . . </SOAP-ENV:Header> <SOAP-ENV:Body> . . . </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Note: Unless otherwise noted, when the namespace prefix SOAP-ENV appears in this book, it represents the namespace http://schemas.xmlsoap.org/soap/envelope/.

(13)

The following example shows a SOAP envelope containing a single header entry called

<MSG:priority>. Note that the entry is namespace qualified, which is a requirement of all

header entries in a SOAP message.

Soap 1.1 message with single header entry

Soap 1.2 message with single header entry

Important! The inclusion of a header component and the information it stores are implementation‐specific. The SOAP specification does not define any standard header entries. It simply provides the header as a container that implementers can use as needed. The parties exchanging SOAP messages are responsible for defining header entries for processing them. <SOAP-ENV:Header> <MSG:priority xmlns:MSG="http://www.gsx.com/">9</MSG:priority> </SOAP-ENV:Header>

This message has a header... ...containing one entry

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> . . . </SOAP-ENV:Body> </SOAP-ENV:Envelope> <MSG:priority xmlns:MSG="http://www.gsx.com/">9</MSG:priority> <SOAP-ENV:Header xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" > xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding"> > </SOAP-ENV:Header> <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" > xmlns:xml="http://www.w3.org/XML/1998/namespace" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Body> . . . </SOAP-ENV:Body> </SOAP-ENV:Envelope> <MSG:priority xmlns:MSG="http://www.gsx.com/">9</MSG:priority>

(14)

SOAP 1.1 Header Attributes

The SOAP 1.1 specification defines the following optional attributes for a header entry. These attributes allow an entry to specify its intended recipient and to indicate whether the recipient is required to process the entry.

The following example shows a SOAP 1.1 header entry that uses both the actor and mustUnderstand attributes.

Message that uses the “actor” and “mustUnderstand” attributes

For more information about using the actor and mustUnderstand attributes, see the Simple Object Access Protocol (SOAP) 1.1 ‐ W3C Note 08 May 2000 at

http://www.w3.org/TR/SOAP/#_Toc478383498.

SOAP 1.2 Header Attributes

The SOAP 1.2 specification defines the optional attributes for a header entry. Attribute Description actor Identifies the intended recipient of the header entry. This attribute allows a sender to direct a header entry to a specific process. mustUnderstand Indicates whether processing of the header entry is mandatory. Recipients that do not recognize an entry whose mustUnderstand attribute is set to 1 must reject the message and return a fault to the client. <MSG:nextDest xmlns=MSG:"http://www.gsx.com/" SOAP-ENV:actor="http://www.gsx.com/msgRouter" SOAP-ENV:mustUnderstand="1"> rubicon:5555 </MSG:nextDest> . . . <SOAP-ENV:Header> </SOAP-ENV:Header> . . . SOAP-ENV:actor="http://www.gsx.com/msgRouter" SOAP-ENV:mustUnderstand="1"

(15)

The following example shows a SOAP 1.2 header entry that uses both the role and mustUnderstand attributes.

Message that uses the “role” and “mustUnderstand” attributes

For more information about using the role and mustUnderstand attributes, see the SOAP 1.2 W3C Recommendation 27 April 2007 at http://www.w3.org/TR/2003/REC‐soap12‐part1.

The Body

When a SOAP message conveys an arbitrary XML document (sometimes referred to as application data or the business payload), the document is carried in the body of the message. When SOAP is used as an RPC protocol, the body specifies the method name that the client is calling and carries the method’s input values. A SOAP message must contain a body element. This element must be named Body. If a SOAP message contains a header, the Body element must appear immediately after the header. Otherwise, the body must be the first element in the SOAP envelope. Each immediate child of the Body element is referred to as a body entry. Attribute Description encodingStyle Identifies the usage of encoding rules to serialize parts of a SOAP message. role Identifies the SOAP node to which a particular SOAP header entry is targeted. mustUnderstand Identifies whether processing of the header entry is mandatory. Recipients that do not recognize an entry whose mustUnderstand attribute is set to 1 must reject the message and return a fault to the client. relay Identifies whether a header entry targeted at a SOAP receiver must be relayed, if it is not processed. <<MSG:nextDest> xmlns:hb1="http://example.org/hb1" SOAP-ENV:actor="http://www.gsx.com/msgRouter" SOAP-ENV:mustUnderstand="1"> </MSG:nextDest> This header entry...

...uses both the role and mustUnderstand attributes . . . <SOAP-ENV:Header> </SOAP-ENV:Header> . . SOAP-ENV:role="http://example.org/Qos" SOAP-ENV:mustUnderstand="1"> rubicon:5555

(16)

A body containing one entry

A body containing two body entries . . . <SOAP-ENV:Body> <GL:JournalEntry xmlns:GL="http://www.gsx.com/gl/"> <transaction> <entry> <Id>2398</Id> <amt>237.50</amt> <acct>Cash</acct> </entry> <entry> <Id>2398</Id> <amt>-237.50</amt> <acct>AR</acct> </entry> </transaction> </GL:JournalEntry> </SOAP-ENV:Body> . . . . . . <SOAP-ENV:Body> <RQ:addr xmlns:RQ="http://www.gsx.com/rfq/"> <street1>1501 Bridger Hwy<street1> <street2></street2> <city>Laurel</city> <state>MN</state> </RQ:addr> <RQ:customer xmlns:RQ="http://www.gsx.com/rfq/"> <acctNo>AGT-432398</acctNo>

<name>GSX Sporting Goods</name> <phone>218-376-2500</phone> </RQ:customer> </SOAP-ENV:Body> . . . Note: Although a SOAP message must contain a body, the body does not have to contain data. A message that has an empty Body element is a valid SOAP message.

(17)

SOAP Fault Elements

The SOAP specification defines one body element, whose name is Fault. A recipient must return the Fault element if it cannot process a SOAP message successfully. SOAP 1.2 faults are structured differently than SOAP 1.1. The SOAP 1.1 fault element contains the following child elements: The SOAP 1.2 fault element contains the following child elements: Element Value <faultcode> _{A qualified name indicating the type of error that occurred. The} SOAP specification defines several standard error codes (for example, SOAP-ENV:Server, SOAP-ENV:Client). See

http://www.w3.org/TR/2000/NOTE‐SOAP‐20000508/ for details. <faultstring> _{A string describing the fault that occurred.} <faultactor> _{Optional. A URI indicating which process or application produced} the fault. <detail> _{Optional. An element containing implementation‐specific details} about the error. This element must be present if the error occurs while processing the body of the message. For a description of the detail element returned by Integration Server, see Appendix A, “SOAP Faults Returned by the Integration Server”. Element Value Code _{An element containing the child value <env:Value> with value of} Version Mismatch, mustUnderstand, dataEncodingUnknown, Sender, Receiver, and the optional sub elements <env:Subcode> and <env:Value>. Reason _{An element intended to provide a human readable explanation of} the fault. The value is in the form of a string. Node _{Optional. A URI for the SOAP node that generated the fault.} Role _{Optional. The role played by the node that generated the fault.} Detail _{Optional. An element containing implementation‐specific details} about the error. This element must be present if the error occurs while processing the body of the message. For a description of the detail element returned by the webMethods Integration Server, see Appendix A, “SOAP Faults Returned by the Integration Server”. Note: Faults must be namespace‐qualified with the namespace http://www.w3.org/2003/05/soap‐envelope.

(18)

The following shows an example of the SOAP 1.1 fault that the Integration Server returns when a sender submits a message to a non‐existent SOAP processor.

A SOAP message returning a fault

When you write clients that submit SOAP messages to the Integration Server, your client code should test for the presence of a fault code and process the response appropriately. For information about when and how the Integration Server returns a SOAP fault, see Appendix A, “SOAP Faults Returned by the Integration Server”.

Trailers

The SOAP 1.1 specification permits additional implementation‐specific elements (elements besides a header and a body) to reside in a SOAP envelope. The Integration Server refers to these elements as trailers. If a SOAP envelope carries trailers, they must appear after the body and they must be namespace qualified. <SOAP-ENV:Fault> <faultcode> SOAP-ENV:Server </faultcode> <faultstring>

[ISS.0088.9123] Requested SOAP processor mySoapProc is not registered on this server </faultstring> <faultactor> http://localhost:5555/soap/mySoapProc </faultactor> </SOAP-ENV:Fault> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> A fault is returned in the

body of a message

Important! SOAP 1.2 does not support trailers. If you are designing a new solution,

Software AG recommends against the use of trailers. However, if you exchange SOAP messages with older systems that use trailers, Integration Server provides services that allow them to work.

(19)

A SOAP 1.1 message containing two trailers

Trailers allow you to transmit information in a SOAP message without placing it in the body or the header of the message. Although used infrequently, they are permitted by the SOAP 1.1 specification and they provide a mechanism that you can use to deliver information to a pre‐processor, a message handler or some other intermediate process without trespassing on the message’s header or body. <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header xmlns:MSG="http://www.gsx.com/"> <MSG:priority>9</MSG:priority> </SOAP-ENV:Header> <SOAP-ENV:Body> <GL:JournalEntry xmlns:GL="http://www.gsg.com/gl/"> <transaction> <entry> <amt>237.50</amt> <acct>Cash</acct> </entry> </transaction> </GL:JournalEntry> </SOAP-ENV:Body> </SOAP-ENV:Envelope> trailer <AUDIT:TransInfo xmlns:AUDIT="http://www.etrans.com/monitor/> <server>14.226.151.96</server> <port>5540</port> <time>2001-06-13 16:00:00 5</time> <node>http://www.gsx.com/clearInv</node> </AUDIT:TransInfo> <AUDIT:TransInfo xmlns:AUDIT="http://www.etrans.com/monitor> <server>20.117.70.33</server> <port>8081</port> <time>2001-06-13 16:00:04 5</time> <node>http://www.gsx.com/updateCustAcct</node> </AUDIT:TransInfo> trailer trailer

(20)

(21)

Chapter 2. SOAP Support on the webMethods Integration

Server

Overview . . . 22

Receiving SOAP Messages with the Integration Server . . . 22

Sending SOAP Messages with the Integration Server . . . 25

(22)

2. SOAP Support on the webMethods Integration Server

Overview

Support for SOAP is delivered by a SOAP message handler and a set of built‐in services. These facilities allow you to: Receive and process SOAP messages via HTTP or HTTPS. Submit SOAP messages to other servers via HTTP or HTTPS. Compose and decompose SOAP messages using a set of built‐in services. Use RPC‐Encoded, RPC‐Literal or Document‐Literal messaging for SOAP 1.1 requests and Document‐Literal messaging for SOAP 1.2 requests. Make Integration Server services available to clients via RPC‐Encoded or Document‐ Literal bindings. For more information about bindings, see the Web Services Developerʹs Guide.

SOAP Versions Supported by webMethods Integration Server

The webMethods Integration Server supports SOAP 1.1 as described in Simple Object Access Protocol (SOAP) 1.1 ‐ W3C Note 08 May 2000 at http://www.w3.org/TR/SOAP/ and SOAP 1.2 as described in SOAP 1.2 W3C Recommendation 27 April 2007 at

http://www.w3c.org/TR/soap12‐part1/.

Receiving SOAP Messages with the Integration Server

The following diagram illustrates the process by which Integration Server receives and processes SOAP messages.

(23)

Processing and receiving a SOAP request

An HTTP client submits a SOAP message by posting it to the URL for a SOAP processor on the Integration Server. A SOAP processor is a special service that operates on SOAP messages. The URL for a SOAP processor has the following format: http://hostName:portNum/soap/[processDirective] HTTP Client HTTP Listener-Dispatcher 2 1 3

webMethods Integration Server SOAP Message Handler

SOAP Default Processor Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e 4 HTTP Client HTTP Listener-Dispatcher 2 1 3

webMethods Integration Server SOAP Message Handler

SOAP Default Processor Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e Ser v ic e 4

Stage 1 The HTTP Client Posts a SOAP Document to the Integration Server

Where... Is... hostName The numeric IP address or name of the webMethods Integration Server. portNum The number of a port on which hostName accepts HTTP or HTTPS requests. processDirective The process directive associated with the requested SOAP processor. The process directive is a unique name that you assign to a SOAP processor when you register it on the Integration Server. If processDirective is omitted or set to “default,” the message is passed to the default SOAP processor. The Web Services processor is the default processor; provided with webMethods Integration Server.

(24)

When the Integration Server receives a message for a SOAP processor, it passes the message to the SOAP message handler, which does the following:

Verifies that the requested SOAP processor is registered on the server. If the SOAP processor does not exist or is not available, the message handler returns a SOAP fault containing the ISS.0088.9123 or ISS.0088.9111 error. (For a description of these error messages, see Appendix A, “SOAP Faults Returned by the Integration Server”.) Verifies that the message declares the appropriate SOAP namespace. If the message does not declare a namespace or declares a namespace other than http://schemas.xmlsoap.org/soap/envelope/ (SOAP 1.1) or http://www.w3.org/2003/05/soap-envelope/ (SOAP 1.2), the message handler returns a SOAP fault containing the ISS.0088.9128 error. Validates the structure of the message against the SOAP schema (if the SOAP processor requests message validation). If the message violates the SOAP schema, the message handler returns a SOAP fault containing the ISS.0088.91125 error.

During the validation step, the message handler validates the structure of the SOAP envelope only. For example, it ensures that the message has at least one body element and only one header element. After the message handler establishes that the SOAP processor is available and has received a valid SOAP message, the message handler does the following: Transforms the message into a soapRequestData object. This object contains the entire SOAP envelope in addition to other operational values that the Integration Server uses to manage the message internally. Creates an empty soapResponseData object. This object is used to compose the message to be returned to the client. Invokes the requested SOAP processor and passes the soapRequestData and soapResponseData objects to it.

Stage 2 The SOAP Message Handler Invokes the Appropriate SOAP Processor

Important! Validating the application data that is carried inside the SOAP envelope is the

(25)

2. SOAP Support on the webMethods Integration Server The selected SOAP processor handles the message in soapRequestData (usually by calling other services on the webMethods Integration Server) and composes a response message in soapResponseData. When the SOAP processor ends or exits, the message handler generates an HTTP response from the message contained in soapResponseData and returns it to the client.

Sending SOAP Messages with the Integration Server

Besides receiving and processing SOAP messages, the Integration Server can send SOAP messages to remote servers via HTTP.

To send a SOAP message, execute pub.client:soapHTTP with the following input parameters:

Stage 3 The SOAP Processor Performs Work and Generates a Response

Note: For Integration Server 7.1, the RPC processor and the use of custom SOAP

processors is deprecated. Processors built with prior versions of Integration Server are still supported.

Stage 4 The Message Handler Returns the Response to the Client

Note: If the SOAP processor or one of the services it calls throws an exception, the message

handler automatically returns a SOAP fault to the client.

Input Parameter Description

soapRequestData The soapRequestData object containing the message that you want to send. You construct and populate this object using the server’s message composition services (for example, createSoapData, addHeaderEntry, addBodyEntry). address The URL where the SOAP message is to be sent. Example: http://servername:5555/soap/rpc auth Optional. The user name and password that the Integration Server must supply when it connects to the target server.

(26)

2. SOAP Support on the webMethods Integration Server validateSOAP Optional. Indicates whether the response message will be validated against the SOAP schema. Set to ... To ... true _{Validate the response message and throw an exception} if the response does not conform to the SOAP schema. false _{Bypass the validation process (default).} SOAPAction Optional. Value to which you want to set the SOAPAction HTTP header. Note: The SOAPAction header was required by the initial SOAP specification but has since been deprecated. The Integration Server does not use the SOAPAction header and accepts SOAP messages that omit it. If you are designing a completely new solution, we recommend that you avoid using the SOAPAction header. However, if you exchange SOAP messages with systems that require a SOAPAction header, this parameter allows you to set it. contentType Optional. Specifies the value of Content‐Type in the HTTP header. loadAs Optional. Specifies the format of the soapResponseData. Default is stream for an HTTP service and byteArrayStream for an HTTPS service.

Set to... To...

stream Return the response body as a java.io.InputStream object. Use this setting to invoke an HTTP Web service. bytes Return the response body as a byte array. Use this setting if the message body will be used as input to a service that operates on entire HTML or XML documents. byteArray Stream Read the response stream fully and convert to a java.io.ByteArrayStream object. This setting prevents data loss or a truncated SOAP response if the connection closes prematurely. Use this setting to invoke an HTTPS Web service. timeout Optional. Time (in milliseconds) to wait for a response from the remote server before timing out and terminating the request. The default value is to wait forever.

(27)

2. SOAP Support on the webMethods Integration Server This service returns a soapResponseData object that contains the response document returned by the target server. You use the server’s data‐retrieval services (for example, getHeaderEntries, getBody) to retrieve information from the message. For more information about sending SOAP messages from the Integration Server, see “Composing and Sending SOAP Messages” on page 51.

Sending SOAP RPC Messages with the Integration Server

The Integration Server supports SOAP RPC, which allows you to make remote procedure calls to other servers with SOAP.

To submit a remote procedure call, you execute pub.client:soapRPC with the following basic set of parameters:

Note: SOAP RPC is supported only by SOAP 1.1.

Input Parameter Description

address A string specifying the HTTP address of the server on which the remote procedure resides. (If you are submitting the request to a webMethods Integration Server, remember to direct it to the RPC processor as shown in the following example.) Example: http://servername:5555/soap/rpc reqParms A document (an IData object) whose elements represent the input parameters that are to be passed to the remote procedure. For example, if you were to pass three string parameters, acct, amt, and org, containing the values, Cash, 150.00 and Sales,

reqParms would contain the following: Key Value acct Cash amt 150.00 org Sales At run time, the values in reqParms are XML‐encoded by the message coder. For a description of this process, see “Encoding the Input Parameters for the Remote Procedure Call” on page 74.

(28)

2. SOAP Support on the webMethods Integration Server method A document (an IData object) specifying the QName of the requested procedure, where: Key Description namespaceName A string specifying the namespace portion of the procedure’s QName. localName A string specifying the local portion of the procedure’s QName. auth A document (an IData object) specifying the user name and password that are to be submitted to the server specified in address, where: Key Description type A string specifying the type of authentication that the server uses. Set type to basic. user A string specifying the user name that is to be presented to the server. pass A string specifying the password for the user name specified in user. targetInputSignature Optional. A string specifying the fully qualified name of the document type that is to be used to validate and encode the contents of reqParms. For a description of how the message coder uses targetInputSignature, see “Encoding the Input Parameters for the Remote Procedure Call” on page 74. targetOutputSignature Optional. A string specifying the fully qualified name of the document type that is to be used to validate and decode the output value returned by the remote procedure. For a description of how the message coder uses targetInputSignature, see “Decoding the Output Parameters from a Remote Procedure Call” on page 76.

(29)

SOAPAction Optional. A string specifying the value to which you want the

SOAPAction HTTP header set.

Note: The SOAPAction header was required by the initial SOAP specification, but has since been deprecated. The Integration Server does not use the SOAPAction header and accepts SOAP messages that omit it. If you are designing a completely new solution, we recommend that you avoid using the SOAPAction header. However, if you exchange SOAP messages with systems that require a SOAPAction header, this parameter allows you to set it. contentType Optional. A string that specifies the value of Content‐Type in the HTTP header.

Set to... To...

text/xml; charset=”utf-8” Default. Specify the content type as XML and the character encoding of the text as UTF‐8. text/xml _{Specify the content type as XML. Since the} charset parameter is not specified, the character encoding of the text defaults to US‐ASCII. encoding Optional. Specifies the encoding method. Default value is UTF‐8. loadAs Optional. Specifies the format of the soapResponseData. Default value is stream for an HTTP service and byteArrayStream for an HTTPS service.

Set to... To...

stream Return the response body as a java.io.InputStream object. Use this option to invoke an HTTP Web service. byteArrayStream Read the response stream fully and convert to a java.io.ByteArrayStream object. This setting prevents data loss or a truncated SOAP response if the connection closes prematurely. Use this setting to invoke an HTTPS Web service.

(30)

2. SOAP Support on the webMethods Integration Server This service returns a document (an IData object) called respParms, which contains the results from the remote procedure. For information about submitting SOAP remote procedure calls from the Integration Server, see “Using the SOAP RPC Client” on page 65. timeout Optional. Time (in milliseconds) to wait for a response from the remote server before timing out and terminating the request. The default value is to wait forever.

(31)

Chapter 3. Building Solutions with SOAP

Building Solutions that Receive SOAP Messages . . . 32 Building Solutions that Send SOAP Messages . . . 37

(32)

3. Building Solutions with SOAP

Building Solutions that Receive SOAP Messages

If you are building a solution that receives and processes SOAP messages, you will need to do the following: Understand the structure of the SOAP message that clients will submit to your Integration Server. Define the work that you want the Integration Server to perform when it receives the SOAP message. Determine whether the SOAP processor provided by the Integration Server will satisfy the needs of your solution or whether you will need to build and register a “custom” SOAP processor.

What is a SOAP Processor?

A SOAP processor is a service that acts upon SOAP messages that the Integration Server receives. When the SOAP message handler receives a SOAP message, it invokes the SOAP processor based on the process directive specified in the URL requested by the client. The process directive is the last segment of the URL for the SOAP message handler on a webMethods Integration Server. For example, if a client submits a SOAP request to the following URL, the SOAP message handler would invoke the SOAP processor registered as “genLedger.”

The process directive determines the SOAP processor to which the message is passed

http://rubicon:5555/soap/genLedger

Note: The SOAP processors that were provided with previous versions of Integration

Server are deprecated, but are still supported. Custom SOAP processors created for previous versions of Integration Server are also deprecated.

(33)

SOAP Processors Provided by the Integration Server

The Integration Server is installed with the following SOAP processors:

Universal Names

A universal name is a unique public identifier that external protocols use to reference a service on a webMethods Integration Server. A QName is a qualified name, made up of a namespace URI, a local part, and a prefix. The SOAP processor routes messages to services based on a qualified name (QName). If the SOAP message includes an HTTP header, the QName is derived from the SOAPAction (SOAP 1.1) or ActionHTTP (SOAP 1.2) field of the header. If the SOAP message does not include an HTTP header, the QName is derived from the first element in the SOAP body. The structure of a universal name is the same as the structure of a QName in an XML namespace and consists of two parts: a namespace name and a local name.

The namespace name is a qualifier that distinguishes a webMethods Integration Server

service from other resources on the Internet. For example, there might be many resources with the name AcctInfo. A namespace name distinguishes one AcctInfo resource from another by specifying the name of the collection to which it belongs (similar to the way in which a state or province name serves to distinguish cities with the same name—for example, Springfield, Illinois, versus Springfield, Ontario). Like namespaces in XML, the namespace portion of a universal name is expressed as a URI. This serves to assure uniqueness, because URIs are based on globally unique domain names.

SOAP Processor Description

default This is a basic processor that invokes a service based on the QName. This processor passes the entire envelope to the services that it invokes. The Web Services processor is the default processor provided with Integration Server 7.1. For information about the default processor, see “Using the Default SOAP Processor” on page 39. RPC This processor processes SOAP remote procedure calls (messages that conform to the remote procedure call (RPC) section of the SOAP specification).

For information about the RPC processor, see Appendix D, “Using the SOAP RPC Processor”.

Note: The SOAP RPC Processor is deprecated for Integration Server

7.1. It is supported only for Web service connectors created in earlier versions of Integration Server.

(34)

3. Building Solutions with SOAP The namespace portion of the universal name can consist of any combination of characters that form a valid absolute URI (relative URIs are not supported). For example, the following are all valid namespace names: http://www.gsx.com http://www.gsx.com/gl/journals http://www.ugmed.ch/résumè For a complete description of what makes up a valid URI, see RFC 3986 Uniform Resource Identifiers (URI): Generic Syntax at http://www.ietf.org/rfc/rfc3986.txt.

The local name uniquely identifies a service within a particular namespace. Many

webMethods users use a serviceʹs unqualified name as its local name. Under this scheme, a service named gl.journals:closeGL would have a local name of closeGL. Local names follow the same construction rules as NCNames in XML. Basically, a local name can be composed of any combination of letters, digits, or the period (.), dash (‐), and underscore (_) characters. Additionally, it must begin with a letter or an underscore character (the _ character). The following are examples of valid local names: addCustOrder authorize-Level1 générent For specific rules relating to NCNames, see the “NCName” definition in the

Namespaces in XML specification at

http://www.w3.org/TR/1999/REC‐xml‐ names‐19990114.

Implicit and Explicit Universal Names

Every service that exists on a webMethods Integration Server has an explicit or an implicit universal name.

An explicit universal name is a universal name that you specifically assign to a service

with Developer. When you assign an explicit universal name, you must specify both

Note: The server normalizes Universal Names according to Unicode Normalization Form

C, as recommended by the Character Model, SOAP, and XML standards. This ensures that names containing non‐ASCII characters (particularly those with accented or combining characters) are represented in a standard way.

For information about normalization, see http://www.unicode.org/reports/tr15/ (Unicode Standard Annex #15) and http://www.w3.org/TR/charmod/ (Character Model for the World Wide Web).

(35)

Specifying explicit universal names in Developer

An implicit universal name is automatically derived from the name of the service itself.

The implicit name acts as the universal name when a service does not have an explicit universal name. The server derives an implicit name as follows:

The namespace name is the literal string http://localhost/ followed by the fully qualified name of the folder in which the service resides on the Integration Server. The local name is the unqualified name of the service. The following table shows the implicit names for a variety of service names: You assign an explicit universal name on the Properties panel in Developer

The service’s implicit universal name is... Fully qualified service name Namespace name Local name

gl.journals:jrnlEntry http://localhost/gl.journals jrnlEntry gl.journals.query:viewJournals http://localhost/gl.journals.query viewJournals orders:postPO http://localhost/orders postPO

Important! To ensure interoperability with other vendor’s implementations of SOAP, we recommend that you always assign explicit universal names to those services that you want to make available to SOAP clients. Note: Earlier versions of the webMethods SOAP implementation did not include the http://localhost/ prefix as part of an implicit name. However, the server is backward compatible. It will resolve QNames that clients submit in either the old form (without the http prefix) or the new form (with the http prefix). Note: It is possible for an implicit name to match the explicit name of another service. When this condition exists, the explicit name takes precedence. That is, when a universal name is requested, the Integration Server searches its registry of explicit names first. If it does not find the requested name there, it looks for a matching implicit name.

(36)

1 Start Developer and connect to the server on which the service resides.

2 From the Navigation panel, open the service whose universal name you want to assign, edit, or view.

3 If you want to assign or edit the service’s universal name, specify the following in the

Universal name category of the service’s Properties panel:

4 On the File menu, click Save to save the new settings.

1 Start Developer and connect to the server on which the service resides.

2 From the Navigation Panel, open the service whose universal name you want to

To assign, edit, or view an explicit universal name

In this field... Specify...

Namespace name The URI that will qualify the local name of this service. The name can be composed of any sequence of characters except leading and trailing white‐space characters

Local name A name that uniquely identifies the service within the collection encompassed by Namespace name. The name can be composed of any combination of letters, digits, or the period (.), dash (‐), and underscore (_) characters. Additionally, it must begin with a letter or the underscore character. Note: Many webMethods users use the unqualified portion of the service name as the local name. Important! When you assign an explicit universal name to a service, you must enter values

in both the Namespace name and Local name fields. If you specify one field but not the other, you will receive an error message when you attempt to save the service. You will not be permitted to save the service until you specify both parts of the universal name. Note: If you move a service, or a folder containing a service, Developer retains the service’s explicit universal name. If you copy a service or a folder containing a service, Developer does not retain the service’s explicit universal name. You must restore the universal name for the copied service by editing the service’s properties.

(37)

3 In the Universal name category of the service’s Properties panel, remove the current settings from the Namespace name and Local name fields.

4 On the File menu, click Save to save the new settings.

The Universal Name Registry

The webMethods Integration Server maintains a registry, called the Universal Name Registry, which maps explicit universal names to the services that they represent. The registry is generated each time the Integration Server is started and is maintained in memory while the server is running. When you use the Developer to assign, modify, or delete a service’s universal name, you update the Universal Name Registry. To view the contents of the registry, you can execute the service pub.universalName:list in Developer and view the contents of the names variable on the Results panel. (This service resides in the WmPublic package.)

Services You Use to Interact with the Registry

The following services can be used to display the Universal Name Registry or locate the name of a service associated with an explicit universal name. For more information about these services, see the webMethods Integration Server Built‐In Services Reference.

Building Solutions that Send SOAP Messages

To build a solution that sends a SOAP message to a SOAP‐compliant server, you need to do the following: Define the structure of the SOAP message that you want to send. Determine where the SOAP message will be submitted for processing (get the URL of the server that will process the message). Understand the structure of the SOAP message that the server will return in response to the SOAP message that you send. Build a service that composes the SOAP message, submits it via HTTP to the appropriate server, and processes the response. Service Description pub.universalName:list Returns a document list containing the entries in the current registry. Each document in the list represents an entry in the registry and contains a service’s fully qualified webMethods name and both parts of its explicit universal name. pub.universalName:find Returns the fully qualified service name for a specified explicit universal name.

(38)

3. Building Solutions with SOAP For information about building services that compose and send SOAP messages, see “Composing and Sending SOAP Messages” on page 51. For information about building a services that submit SOAP RPC messages to remote servers, see “Using the SOAP RPC Client” on page 65. Note: SOAP RPC messages are only supported by SOAP 1.1.

(39)

Chapter 4. Using the Default SOAP Processor

Accessing the Default Processor . . . 40 Behavior of the Default SOAP Processor . . . 40 Building Target Services for the Default Processor . . . 42

(40)

4. Using the Default SOAP Processor

Accessing the Default Processor

The Integration Server provides a default SOAP processor registered under the name Web Services processor. The SOAP message handler invokes this SOAP processor when the process directive is omitted or when the specified process directive is undefined in Integration Server.

The following examples illustrate the two types of URLs that invoke the default processor:

Behavior of the Default SOAP Processor

The default SOAP processor acts as a dispatcher that delegates messages to other services on the Integration Server. It does this by invoking the service whose universal name matches the qualified name (QName) of the message body’s first element or of the action field in the message header. This service is referred to as the target service.

How the Processor Selects the Target Service

The default SOAP processor selects a target service by matching the fully expanded QName to a universal name (implicit or explicit) of a service on the webMethods Integration Server. For example, if the default processor were to receive a SOAP message with the body shown below, it would invoke the service whose universal name is made up of the namespace name http://www/exprint.com/GL/ and the local name JournalEntry.

You can specify the “ws” process directive...

http://rubicon:5555/soap/ws/example:calculator

—OR—

http://rubicon:5555/soap/

...or omit the process directive . . . <SOAP-ENV:Body> <GL:JournalEntry xmlns:GL="http://www.exprint.com/GL/"> <Id>2398</Id> <date>03/15/2000</date> <amt>237.50</amt> <acct>Cash</acct> </GL:JournalEntry> </SOAP-ENV:Body> . .

(41)

4. Using the Default SOAP Processor If the default processor received a message with the body shown below, it would invoke the service whose implicit universal name is made up of the namespace name GL.journals.queries and the local name viewJournal. (Recall that an implicit name is derived by combining a service’s fully qualified service name with the prefix string http://localhost/.)

What if the Requested Service Does Not Exist?

If the default processor cannot locate the service whose universal name matches the QName of the body’s first element or of the action field in the message header, it returns a SOAP fault to the client with the following error: [ISS.0088.9122] Service

namespaceName:localName does not exist. See Appendix A, “SOAP Faults Returned

by the Integration Server” for information about this error.

Processor Inputs and Outputs

When the default SOAP processor calls a target service, it passes two input parameters to the service: soapRequestData, an object containing the entire SOAP message soapResponseData, an object containing an empty SOAP message. When the target service exits, the default SOAP processor returns soapResponseData to the SOAP message handler. The message handler extracts the SOAP message from soapResponseData and returns the message to the client. . . . <SOAP-ENV:Body> <GL:viewJournal xmlns:GL="http://localhost/GL.journals.queries"> <acct>Cash</acct> <fromDate>01/01/2000</fromDate> <toDate>03/31/2000</toDate> </GL:viewJournal> </SOAP-ENV:Body> . . . Note: The Integration Server expects the QName in the incoming SOAP message to be normalized according to Unicode Normalization Form C. Normalization assures that names containing non‐ASCII characters (particularly those with accented or combining characters) are represented in a standard way. If the client has not normalized the QName, the Integration Server might not be able to properly match it with a universal name in its registry.

WebMethods SOAP Developer's Guide - Software AG Documentation

Developer

Version 7.1

SOAP Developer’s Guide

Contents

About This Guide. . .

7

Chapter 1. Overview of SOAP . . .

9

Chapter 2. SOAP Support on the webMethods Integration Server . . . 21

Chapter 3. Building Solutions with SOAP . . . 31

Chapter 4. Using the Default SOAP Processor . . . 39

Chapter 5. Composing and Sending SOAP Messages . . . 51

Chapter 6. Using the SOAP RPC Client . . . 65

Appendix A. SOAP Faults Returned by the Integration Server . . . 79

Appendix B. Encoding/Decoding Data-Type Mapping . . . 103

Appendix C. SOAP-Related Server Parameters . . . 113

Appendix D. Using the SOAP RPC Processor . . . 117

Appendix E. Creating Custom SOAP Processors . . . 135

About This Guide

Document Conventions

Additional Information

Chapter 1. Overview of SOAP

What is SOAP?

What Does a SOAP Message Look Like?

The Envelope

The SOAP Namespace Declaration

The Header

SOAP 1.1 Header Attributes

SOAP 1.2 Header Attributes

The Body

SOAP Fault Elements

Trailers

Chapter 2. SOAP Support on the webMethods Integration

Server

Overview

SOAP Versions Supported by webMethods Integration Server

Receiving SOAP Messages with the Integration Server

Sending SOAP Messages with the Integration Server

Sending SOAP RPC Messages with the Integration Server

Chapter 3. Building Solutions with SOAP

Building Solutions that Receive SOAP Messages

What is a SOAP Processor?

SOAP Processors Provided by the Integration Server

Universal Names

Namespaces in XML specification at

Implicit and Explicit Universal Names

The Universal Name Registry

Services You Use to Interact with the Registry

Building Solutions that Send SOAP Messages

Chapter 4. Using the Default SOAP Processor

Accessing the Default Processor

Behavior of the Default SOAP Processor

How the Processor Selects the Target Service

What if the Requested Service Does Not Exist?

Processor Inputs and Outputs