web services dev guide

Web Services Developer’s Guide

VERSION 6.5, SERVICE PACK 1

webMethods, Inc.South Tower3877 Fairfax Ridge RoadFairfax, VA 22030USA703.460.2500http://www.webmethods.com

webMethods Access, webMethods Administrator, webMethods Broker, webMethods Dashboard, webMethods Developer, webMethods Fabric, webMethods Glue, webMethods Installer, webMethods Integration Server, webMethods Mainframe, webMethods Manager, webMethods Modeler, webMethods Monitor, webMethods Optimize, webMethods Portal, webMethods Servicenet, webMethods Trading Networks, and webMethods Workflow are trademarks of webMethods, Inc. webMethods and the webMethods logo are registered trademarks of webMethods, Inc.

Acrobat and Adobe are registered trademarks, and Reader is a trademark of Adobe Systems Incorporated. Amdocs is a registered trademark, and ClarifyCRM is a trademark 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. ChemeStandards and CIDX are trademarks of Chemical Industry Data Exchange. Unicenter is a registered trademark of Computer Associates International, Inc. PopChart is a registered trademark of CORDA Technologies, Inc. Kenan and Arbor are registered trademarks of CSG Systems, Inc. Data Connection and SNAP-IX are registered trademarks of Data Connection Corporation. DataDirect, DataDirect Connect, and SequeLink are registered trademarks of DataDirect Technologies. D&B and D-U-N-S are registered trademarks of Dun & Bradstreet Corporation. 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, DB2, Domino, IBM, Informix, Infoprint, Lotus, Lotus Notes, MQSeries, OS/390, OS/400, RACF, RS/6000, SQL/400, S/390, System/390, VTAM, z/OS, and WebSphere 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. JBoss is a registered trademark, and JBoss Group is a trademark of Jboss, Inc. 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, Windows, and Windows NT are registered trademarks; and Windows Server is a trademark of Microsoft Corporation. Six Sigma is a registered trademark of Motorola, Inc. Firefox is a registered trademark, and Mozilla is a trademark of the Mozilla Foundation. MySQL is a registered trademark of MySQL AB. nCipher is a trademark of nCipher Corporation Ltd. Teradata is a registered trademark of NCR International, Inc. Netscape is a registered trademark of Netscape Communications Corporation. SUSE is a registered trademark of Novell, Inc. ServletExec is a registered trademark, and New Atlanta is a trademark of New Atlanta Communications, LLC. CORBA is a registered trademark of Object Management Group, Inc. JD Edwards, OneWorld, Oracle, PeopleSoft, Siebel, and Vantive are registered trademarks, and PeopleSoft Pure Internet Architecture and WorldSoftware are trademarks of Oracle Corporation. Infranet and Portal are trademarks of Portal Software, Inc. Red Hat is a registered trademark 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. SWIFT and SWIFTNet are registered trademarks of Society for Worldwide Interbank Financial Telecommunication SCRL. SPARC and SPARCStation are registered trademarks of SPARC International, Inc. SSA is a registered trademark, and Baan and SSA Global are trademarks 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, SOAP with Attachments API for Java, JavaServer Pages, 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.

All other marks are the property of their respective owners.

Copyright © 2006 by webMethods, Inc. All rights reserved, including the right of reproduction in whole or in part in any form.

Document ID: DEV-WS-DG-65SP1-20060210

Contents

Contents

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7What Is a Web Service? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Using webMethods Software to Invoke Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Using webMethods Software to Create Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Using webMethods Software to Manage Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9What Is a WSDL Document? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Information Required to Generate a WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

About Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11XML Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Integration Server Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Specifying Universal Names for Integration Server Services . . . . . . . . . . . . . . . . . . . 12Associating Integration Server Fields with XML Namespaces . . . . . . . . . . . . . . . . . . 12

Chapter 2. Creating and Running a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . 15Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Creating a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Supporting Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Example Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Testing a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapter 3. Generating a WSDL Document that Uses the SOAP RPC Protocol . . . . . . . . 21Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Service Requirements when Using the Default SOAP RPC Processor . . . . . . . . . . . . . . . . . . . . . . . 22Input and Output Signature Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Generating the WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Chapter 4. Generating a WSDL Document that Uses the SOAP Message Protocol . . . . 31Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Service Requirements when Using the Default SOAP Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Service Requirements When Registering into Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Input and Output Signature Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Generating the WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Web Services Developer’s Guide Version 6.5 Service Pack 1 3

C o n t e n t s

Chapter 5. Generating a WSDL Document that Uses the HTTP POST or GET Protocol . . 43Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Service Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Input and Output Signature Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Text/XML Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45URL Encoded Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Generating the WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Chapter 6. Using Servicenet to Register and Bind to Web Services . . . . . . . . . . . . . . . . . 57Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58What Is webMethods Servicenet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Connecting to Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Refreshing and Disconnecting a Servicenet Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Viewing Servicenet in the Developer Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Servicenet Tab Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Servicenet Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Web Service Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Registering a Service in Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Updating a Service that is Registered in Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Removing a Service from Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Browsing for Web Services in Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Applying a Filter to Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Clearing an Applied Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Binding to a Web Service in Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Appendix A. WSDL Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Basic Elements in WSDL Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

The Address Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79WSDL Namespace Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Sample WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Appendix B. Web Service-Related Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Message Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Web Service-Related Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Messages Received when Generating a WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Messages Received when Creating a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . 89

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4 Web Services Developer’s Guide Version 6.5 Service Pack 1

About This Guide

About This Guide

This guide is for users who want to create Web services and incorporate Web services into the solutions they develop. This guide explains how to generate WSDL documents for webMethods Web services and use webMethods software to call Web services located on remote servers.

Document Convent ions

Addit ional Informat ionThe webMethods Advantage Web site at http://advantage.webmethods.com provides you with important sources of information about webMethods components:

Troubleshooting Information. webMethods provides troubleshooting information for many webMethods components in the webMethods Knowledge Base.

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

Additional Documentation. All webMethods documentation is available on the webMethods Bookshelf.

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.


http://advantage.webmethods.com

http://advantage.webmethods.com/troubleshooting

http://advantage.webmethods.com/docfeedback

http://advantage.webmethods.com/Bookshelf

http://advantage.webmethods.com/Bookshelf

A b o u t T h i s G u i d e


C H A P T E R 1
Concepts
What Is a Web Service? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Using webMethods Software to Invoke Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Using webMethods Software to Create Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Using webMethods Software to Manage Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

What Is a WSDL Document? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Information Required to Generate a WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10


C H A P T E R 1 C o n c e p t s

What Is a Web Service?Web services are building blocks for creating open, distributed systems. A Web service is a collection of functions that are packaged as a single unit and published to a network for use by other software programs. For example, you could create a Web service that checks a customer’s credit or tracks delivery of a package. If you want to provide higher-level functionality, such as a complete order management system, you could create a Web service that contains other Web services that each perform an order management function.

Using webMethods Software to Invoke Web ServicesYou can use webMethods Integration Server and webMethods Developer to invoke Web services located on remote servers. To do so, you generate a Web service connector from the WSDL document for the remote Web service, then run the connector. A Web service connector is a flow service that has an input and output signature that corresponds to the input and output messages from the WSDL document from which it was created.

Using webMethods Software to Create Web ServicesYou can use Integration Server and Developer to turn any service in any Integration Server package into a Web service. Integration Server provides an environment for executing services efficiently and securely. It receives and decodes requests from clients, calls the requested services, and encodes and returns the output to the clients. Integration Server also provides an extensive library of built-in services. Developer is the integrated development environment (IDE) that you use to create services on Integration Server.

Integration Server’s service-oriented architecture makes it ideal for use in integration scenarios because it separates implementation from presentation. When a client application wants to invoke a Web service, the client need know only the service’s name, inputs, and outputs. The client does not need to know how the service is implemented (for example, in Java or C) or what kind of back-end system it accesses.

Similarly, the Web service implementation (that is, the back-end business logic) does not need to know what kind of client invoked it. A client can use HTTP/HTTPS, FTP, or SMTP to invoke the same service. You do not need to have multiple versions of the same service because the webMethods content handler layer takes care of all marshalling and unmarshalling between the protocol layer and the implementation layer.


Using webMethods Software to Manage Web Services

Integration Server’s service-oriented architecture

With webMethods software, you can create Web services using programming languages such as Java, C/C++, or COM. You can also create Web services from existing back-end systems, without producing custom code or reconfiguring the back-end systems, using webMethods adapters.

Using webMethods Software to Manage Web ServicesYou can use webMethods Developer and webMethods Servicenet together to incorporate Web services development into your integration solution. Servicenet deploys and implements dynamic, coordinated networks of managed services. In addition, Servicenet offers distributed security. For more information about Servicenet, see “What Is webMethods Servicenet?” on page 58.

What Is a WSDL Document? A Web Services Description Language (WSDL) document is an XML document that describes Web services that are accessible over a network. The WSDL document for a Web service contains all the information a Web service consumer needs to send data to the Web service, invoke the Web service, and receive data from the Web service.

A Web service provider can:

Create the WSDL document and supporting files for a service.

Upload the WSDL document and files to a publicly accessible server.

Use a Web services registry to publish a URL that identifies the location of the WSDL document.

FTP SMTPHTTP/S

XML SOAP RPC SOAP MSG EDI

webMethods invoke handler

transports

content handlers

example service types Flow Java COM C/C++

Note: A Web service provider can also distribute a WSDL document and supporting files to Web service consumers directly.



Web service consumers can:

Browse the registry and locate the service.

Use the URL to download the WSDL document.

The WSDL document for a Web service describes the following:

Logic the Web service performs.

Location of the Web service.

Method to use to access the Web service, including the protocol that the Web service consumer must use to invoke the Web service and receive a response.

Input parameters that the Web service consumer must supply to the Web service and the output parameters that the Web service returns.

Informat ion Required to Generate a WSDL DocumentWhen you generate a WSDL document for a Web service, you provide the following information:

Information Description

Web service location Production Integration Server on which the Web service will reside.

Protocol Protocol that Web service consumers must use to communicate with the Web service. You can specify the SOAP RPC, SOAP message (document), HTTP POST, or HTTP GET protocol.

Transport Request transport mechanism that Web service consumers must use to invoke the Web service. You can specify HTTP or HTTPS, depending on the port you are using.

Service signature Input parameters the Web service requires and output parameters the Web service produces.

The service for which you generate a WSDL document, and the input and output parameters that compose the service’s signature, must meet certain requirements. These requirements differ depending on the protocol you select for Web service consumers to communicate with the Web service. For more information about these requirements, see the individual chapters that describe how to generate WSDL documents for each type of protocol.

Target namespace Namespace to which elements, attributes, and type definitions in the generated WSDL document will belong.


Information Required to Generate a WSDL Document

The subsystem of Integration Server that generates WSDL documents is called the WSDL generator. The WSDL generator creates a WSDL document using the information you provide along with information from the service.

About Namespaces Namespaces are collections of names (for example, the names of XML Schema elements, Integration Server document types, or Integration Server services). A namespace name is associated with each collection to provide context for the named entities within the collection. This helps prevent conflicts when the scope of a named entity extends beyond its current context.

The following sections describe XML namespaces and namespace use within the Integration Server.

XML NamespacesBy the World Wide Web Consortium (http://www.w3.org) definition, an XML namespace is a collection of names identified by a URI reference. XML namespaces help avoid naming conflicts by differentiating between element types or attributes with the same name in an XML document. As long as these like-named element types or attributes reside in different namespaces, they are considered different entities.

You can define a prefix to represent an XML namespace URI. Prefixes provide a way to shorten the reference to the XML namespace URI. In the following XML Schema example, the prefix address represents the XML namespace URI http://www.example.com:

xmlns:address="http://www.example.com"

You can use this prefix elsewhere in the XML document, in conjunction with an element's local name attribute, to represent the full URI with which the prefix is associated. For example:

<address:street>123 Main Street</address:street>

The name of an element type or attribute is referred to as its local name. When an element type or attribute is associated with a namespace, its name (whether prefaced by a prefix or not) is also known as an XML namespace qualified name (QName).

Integration Server Namespaces All webMethods entities that you save on an Integration Server, including services and document types, have a unique name. This unique name has two parts: the name of the entity (its local name) and the folder path in which it resides (its Integration Server namespace name). For example, a service called myService that resides in the folder structure topFolder\childFolder is represented in the Integration Server as topFolder.childFolder:myService, where topFolder.childFolder is the service's folder name and myService is the service's element name. An Integration Server namespace (folder path) cannot contain two different components with the same local name.


http://www.w3.org


Specifying Universal Names for Integration Server Services

When an Integration Server service is used as a SOAP Web service, the Integration Server identifies the service using a unique public identifier called a universal name. Similar in structure to a QName in an XML namespace, a universal name consists of a namespace name and a local name. These names are determined as follows:

The namespace name is specified as a URI and can consist of any combination of characters that form a valid absolute URI (for example, http://www.gsx.com/gl/journals).

The local name follows the same construction rules as NCNames in XML Schema (that is, it must conform to the naming conventions specified in http://www.w3.org/TR/REC-xml-names/#NT-NCName).

For more information about what makes up a valid URI and how to construct local names, see the SOAP Developer’s Guide.

Universal names can be explicit or implicit.

An explicit universal name is a universal name that you specifically assign to a service by completing the Namespace name and Local name fields in the service's Properties panel in Developer.

For more information about specifying an explicit universal name, see the webMethods Developer User’s Guide.

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.

Associating Integration Server Fields with XML Namespaces

Although it is not always necessary to do so, you can associate the name of an Integration Server field (such as an IS document variable) with an XML namespace. When you do so, the local name is the name of the field and the XML namespace name is the URI that identifies the namespace. You can also include a prefix as part of the name.

Note: The universal name should conform to the XML QName naming conventions specified in http://www.w3.org/TR/REC-xml-names/#NT-QName.

Note: The WSDL generator defines prefixes in WSDL documents to represent specific namespaces that identify a binding’s protocol. For more information about these prefixes and their associated namespaces, see Appendix A, “WSDL Documents”.


http://www.w3.org/TR/REC-xml-names/#NT-QName


http://www.w3.org/TR/REC-xml-names/#NT-NCName



Information Required to Generate a WSDL Document

In Developer, you assign XML namespaces and prefixes to Integration Server fields as follows:

To assign an XML namespace to an Integration Server field, complete the XML Namespace property in the General category of the field’s Properties panel.

To assign a prefix to an Integration Server field, precede the field name with the prefix followed by a colon (for example, prefix:variableName).

Note: In most cases, if you use a prefix you must also supply an XML namespace. For more information, see the chapters in this guide for generating WSDL documents for each type of protocol.


C H A P T E R 2
Creat ing and Running a Web Service Connector
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Creating a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Testing a Web Service Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20


C H A P T E R 2 C r e a t i n g a n d R u n n i n g a W e b S e r v i c e C o n n e c t o r

OverviewTo invoke Web services located on remote servers, you generate a Web service connector from the WSDL document for the remote Web service, then run the connector. A Web service connector is a flow service that has an input and output signature that corresponds to the input and output messages from the WSDL document from which it was created.

Creat ing a Web Service ConnectorBecause a Web service connector is a flow service, you lock, test, debug, and call the connector using same procedures you would use to lock, test, debug, and call a flow service.

1 Click on the main toolbar. Developer opens the New wizard.

2 Click Web Service Connector, then click Next. The wizard displays the New Web Service Connector panel.

3 Identify the folder in which you want to store the connector by clicking the folder in the Folder box, then click Next.

Note: To create a Web service connector, you need to specify a WSDL document that resides either on the Internet or on your local file system. If you do not have a WSDL document and you would like to use Developer to create one, see the chapters in this guide for generating WSDL documents that use the SOAP RPC, SOAP Message, HTTP POST, or HTTP GET protocols.

Note: Web service connectors cannot be created using WSDL documents generated for XSLT services.

To create a Web service connector

Tip! To automatically generate a Web service connector from an existing service registered in Servicenet, simply drag the Web service from the Servicenet tab to the folder in which you want to store the connector. For more information, see Chapter 6, “Using Servicenet to Register and Bind to Web Services”.

Note: You must have Write access to the folder in which you want to store the Web service connector.


Creating a Web Service Connector

4 Under Select a source, do one of the following:

Select Servicenet Web Service to generate a Web service connector from an existing service registered in Servicenet. The Servicenet Web Service radio button is enabled only if there is a Servicenet session open in Developer. For information about this option, see “Binding to a Web Service in Servicenet” on page 75.

OR

Select WSDL file to generate a Web service connector from a WSDL document. Click Next. The wizard displays the New Web Service Connector from WSDL dialog box.

5 If you selected Servicenet Web Service in the Choose a .wsd or .wsdl file box, select the appropriate Web service.

6 If you selected WSDL file in the Choose a .wsd or .wsdl file box, do one of the following:

If you want to create a Web service connector from a WSDL document that resides on the Internet, enter the URL for the document. The URL must begin with http:// or https://.

If you want to create a Web service connector from a WSDL document that resides on your local file system, click to navigate to and select the document.

7 Click Finish. Developer validates the WSDL document you selected, creates the connector and supporting Integration Server elements, and saves the connector and the elements to the folder you specified. For information about the IS elements that Developer generates, see “Supporting Elements” on page 18.

Note: If the Web site on which the document resides is password protected, you must download the WSDL document to your local file system, then create the Web service connector.

Note: If Developer cannot create or cannot completely generate a Web service connector from the WSDL document because the WSDL document is invalid or is missing WSDL elements, Developer displays error messages or warning messages. For more information about errors that can occur when generating connectors, see Appendix B, “Web Service-Related Errors and Warnings”.



Support ing ElementsWhen Developer creates a Web service connector from a WSDL document, it also creates supporting IS elements. Each of the IS elements that Developer creates corresponds to an element in the WSDL document.

The following table identifies the IS elements that Developer might create when it generates a Web service connector.

Example Web Service ConnectorThe following Web service connector was generated from a WSDL document that describes a Web service that authorizes a credit card. The WSDL document specified:

An input message named AuthorizeCreditCardInput that specified the inputs Name, CreditCardType, CreditCardNumber, and ExpirationDate.

An output message named AuthorizeCreditCardOutput that specified the output isAuthorized.

A <binding> element that specified SOAP RPC as the protocol.

This IS element... Corresponds to this WSDL element...

Folder Each unique <portType> element in the WSDL document. The subfolder name corresponds to the portType name.

Web service connector

Each unique <operation> element in a <portType> element. The Web service connector name corresponds to the operation name.

docType folder All of the IS document types generated from the messages in the WSDL document.

IS document type Each <message> element in the WSDL document. The IS document type name corresponds to the message name.

When creating the IS document type for the input message, Developer inserts the _port and auth variables into the IS document type. The Web service connector uses the _port variable as the switch value in the BRANCH on '/_port' step to determine which network address and binding to use to invoke the Web service. Integration Server uses the auth variable to authenticate the username and password the Web service connector is using to call the Web service.

IS schema Each target namespace to which the element declarations, attribute declarations, and type definitions that define the message parts (input and output signature) belong.


Creating a Web Service Connector

A <service> element that contained one <port> named AuthorizeCreditCardPortType.

A single <operation> element named AuthorizeCreditCard.

On the Input/Output tab for the Web service connector, note that the Web service connector uses references to the input and output IS document types to define the service signature.

Input/Output tab for a Web service connector

Developer inserts flow steps into the Web service connector by following an internal template for inserting input data into the service request, sending the request, processing the response, and adding service output values to the pipeline. The template that Developer follows depends on the protocol specified in the WSDL document. The following illustration shows the Web service connector generated for the Web service that performs credit card authorization.

The IS document typegenerated from the

output message is usedto declare the output

signature.

The IS document typegenerated from the

input message is usedto declare the input

signature.

Developer creates theseelements from theWSDL document.



Web service connector for credit card authorization Web service

Test ing a Web Service ConnectorYou can test a Web service in Developer using the Run command on the Test menu. When you execute a service with the Run command, Developer invokes the service and receives its results. The service executes once, from beginning to end (or until an error condition forces it to stop) on the server on which you have an open session.

Before Developer invokes the Web service, it prompts you for input values. You can type the input values into the dialog box provided by Developer or load the values from a file that was saved during an earlier test. Results from the service are returned to Developer and displayed on the Results panel.

For more information about testing flow services, see the webMethods Developer User’s Guide.

1 Open the Web service connector you want to run.

2 Click . Developer displays the Input for ‘connector’ dialog box. The dialog box shows the inputs required by the remote Web service.

3 Provide the input values, then click OK. Developer runs the connector, which calls the remote Web service, and displays the results on the Results panel.

This BRANCH stepcontains a child step for

each named port.

This BRANCH stepcontains a child step for

each named binding.

This SEQUENCEcorresponds to a binding

for the SOAP RPCprotocol.

Note: The $default port corresponds to the first named <port> element in the WSDL document.

To test a Web service connector


C H A P T E R 3
Generat ing a WSDL Document that Uses the SOAP RPC Protocol
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Service Requirements when Using the Default SOAP RPC Processor . . . . . . . . . . . . . . . . 22

Input and Output Signature Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Generating the WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


C H A P T E R 3 G e n e r a t i n g a W S D L D o c u m e n t t h a t U s e s t h e S O A P R P C P r o t o c o l

OverviewWhen you specify SOAP RPC as the protocol for Web service consumers to use to communicate with a Web service, the RPC processor will receive SOAP messages that call the service. You can select either the default RPC processor or a registered, custom-built SOAP RPC processor (for example, an access-controlled RPC processor). The processor you select will receive requests for the Web service.

The Web service for which you are generating the WSDL document will be a target service of the selected processor. Consequently, the service needs to conform to the target service requirements for the specified processor.

If you select a custom SOAP RPC processor, make sure the service for which you are generating the WSDL document conforms to the target service requirements for the custom processor. The following section explains the service requirements if you want to use the default SOAP RPC processor to receive and send SOAP messages for the service. For information about creating custom SOAP RPC processors, see the SOAP Developer’s Guide.

Service Requirements when Using the Default SOAP RPC Processor

When you use the default SOAP RPC processor to process remote procedure calls, the target service for which you are generating the WSDL document must meet this requirement:

If you specify a universal name for the service, you must include both a namespace name and a local name. The namespace name must consist of a valid URI. The local name must conform to the naming conventions specified in http://www.w3.org/TR/REC-xml-names/#NT-NCName. The universal name should conform to the XML QName naming conventions specified in http://www.w3.org/TR/REC-xml-names/#NT-QName.

In addition to this requirement, webMethods recommends the following:

Check the target service’s Execute ACL permission to ensure that consumers of the service can invoke it.

The RPC WSDL generator represents all document variables as closed complex types in the WSDL (that is, all child variables are declared). To ensure interoperability with other Web service vendors, avoid producing pipeline variables that you do not declare in the output signature.

Note: You assign a universal name to a service in Developer by completing the Namespace name and Local name fields on the service's Properties panel.








Input and Output Signature Requirements

Input and Output Signature RequirementsWhen you specify SOAP RPC as the protocol for accessing a Web service, the WSDL generator creates the input and output messages for the WSDL document from the signature specified on the Input/Output tab of the service.

If you want to use the default SOAP RPC processor to process remote procedure calls, the service’s input and output signature must meet the requirements listed in the table below. The other chapters that describe how to generate WSDL documents also contain this table so you can easily compare requirements across protocols.

Service signature requirements for the SOAP RPC protocol

Case Applies? Notes

Field types at the top level

Top-level strings are allowed. Yes

Top-level objects and documents are allowed. Yes

Top-level string, object, and document lists are allowed.

Yes

Top-level string tables are allowed. Yes

Field types below the top level

Strings, objects, and documents are allowed. Yes

String, object, and document lists are allowed. Yes

String tables are allowed. Yes

Field names

Field names can contain a prefix without an associated XML namespace.

Yes

Field names can be associated with an XML namespace without a prefix.

Yes

Field names must conform to QName lexical rules (that is, the prefix and local name must conform to NCName rules specified in http://www.w3.org/TR/REC-xml-names/#NT-NCName).

No If the names do not conform, the RPC WSDL generator encodes the names according to the rules specified in http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html#namemap.

String field names can begin with the character @ or be named *body.

Yes The WSDL generator encodes the names according to the rules specified in http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html#namemap.




http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html#namemap





Fields of type other than scalar string can have names that begin with the character @ or be named *body.


Duplicate field names

Fields at the same level (that is, beneath the same parent field in the input or output of the same signature) can have the same name and

Same type and properties. Yes

Different type and properties. Yes However, the WSDL generator uses only one field’s type and properties for all fields with that name at that level. Because the method used to select the field is not defined, webMethods recommends avoiding this case.

More than one field named *body can occur at the same level.


However, the WSDL generator uses only one field’s type and properties for all fields with that name at that level. Because the method used to select the field is not defined, webMethods recommends avoiding this case.

Duplicate field names that begin with the character @ can repeat at the same level.


However, the WSDL generator uses only one field’s type and properties for all fields with that name at that level. Because the method used to select the field is not defined, webMethods recommends avoiding this case.

Fields at different levels can have the same name and

Different or no XML namespace values, even though they may have different type and properties.

Yes

Case Applies? Notes









Duplicate XML namespace values and the same type and properties.

Yes

Duplicate XML namespace values and different type and properties.

Yes

Field properties

Document or Document list type fields can be open (that is, in the Constraints category of the Properties panel, the Allow unspecified fields property is set to True).

Yes However, the Integration Server displays a warning and marks the documents as “closed.”

Top-level fields must be associated with an XML namespace.

No The Integration Server ignores the XML namespace value if present.

Fields beneath the top level must be associated with an XML namespace.

No The Integration Server ignores the XML namespace value if present.

Recursive documents are allowed. Yes The Integration Server will generate the WDSL document but cannot create a Web service connector from the WSDL document.

Field type constraints

Object constraints are allowed. Yes However, the WSDL generator does not represent them in the WSDL document.

Strings constrained by older schema types (types defined before the W3C XML 2001 Schema recommendations) are allowed.

Yes However, the WSDL generator maps them into 2001 XML Schema types.

Case Applies? Notes

Note: By default, a field must exist at run time, can contain a null value, and (for document type fields), cannot contain unspecified fields. If you change a field's default properties, the WSDL generator reflects those changes in the schema section of the WSDL document. However, the message element of a WSDL document cannot define these properties. Therefore, when you use the WSDL document to generate a Web service connector, the Integration Server uses the default properties for all top-level fields.



Generat ing the WSDL DocumentTo create a WSDL document that specifies the SOAP RPC protocol, you do the following:

Stage Description

1 Identify the service for which you want to generate a WSDL document.

2 Specify the protocol and transport mechanism for Web service consumers to use to communicate with the Web service.

3 Specify the target namespace for the WSDL document.

4 Generate the WSDL document.

Note: Before you generate a WSDL for an adapter service, verify that the service will only return values that match its output signature to the pipeline. Otherwise, you must do one of the following:

Wrap the adapter service in a flow service. Add or drop variables to match the output signature. Then, generate the WSDL from the flow service.

Change the properties of any variable that does not match the output signature to make it optional, where applicable. To make a variable optional, set the Required property in the Constraints category of the Properties panel to False.


Generating the WSDL Document

1 In the Navigation panel, select the service for which you want to generate a WSDL document.

2 On the Tools menu, click Generate WSDL. Developer opens the Generate WSDL dialog box.

Generate WSDL dialog box

3 In the Host box, type the numeric IP address or domain name of the host machine on which the Web service will reside at production time.

By default, the Host box identifies the Integration Server on which the Web service currently resides; that is, the Integration Server to which you are currently connected.

You do not need to specify http:// or https:// as part of the host name; the WSDL generator automatically adds http:// or https:// (based on the transport mechanism you specify in the Via Transport box) to the host name when it compiles the network address for the Web service.

4 In the Port box, type the number of the port you want to use to accept requests for the Web service from Web service consumers.

By default, the Port box identifies the port you used to connect to the current Integration Server. If you want to use a different port, type the number of that port in the Port box.

The port you identify must be able to accept either HTTP requests or HTTPS requests. If you do not require that requests from Web service consumers be sent securely, specify a port that accepts HTTP requests. If you want requests from Web service consumers to be sent securely, specify a port that accepts HTTPS requests.

Stage 1 To identify the Web service



1 Under Protocol, click SOAP-RPC.

2 Under Via Transport, click the request transport mechanism that is accepted by the port you specified in the Port box. If the port accepts HTTP requests, click HTTP. If the port accepts HTTPS requests, click HTTPS.

3 From the Directive list, select the directive of the SOAP processor to which you want requests for this service directed. If you want requests for this service routed to the Integration Server’s default SOAP RPC processor, click rpc. If you want to use a custom RPC processor that is registered on your Integration Server, select its directive.

For information about creating and registering your own SOAP RPC processor, see the SOAP Developer’s Guide.

1 In the Target Namespace box, specify the target namespace for the WSDL document.

By default, the Target Namespace box displays http://host/ as the target namespace, where host is the name of the server you are currently logged on to. If you want to specify a different namespace, type the URI for that namespace in the box.

2 Click OK. Developer displays a dialog box that prompts you for a location and name for the generated WSDL document.

1 Under Save in, select the directory in which you want to save the generated WSDL document.

2 In the File name field, specify a name for the WSDL document. By default, Developer assigns the document the name serviceName.wsdl.

Stage 2 To specify the protocol

Note: The Directive list displays all registered SOAP processors on the Integration Server to which you are currently connected. If you plan to move the service to a production Integration Server, make sure the directive you select corresponds to a SOAP processor that is registered on the production server as well.

Important! If you specify anything other than the default SOAP RPC processor, be certain that the directive belongs to a SOAP RPC processor. Otherwise, requests for this service will not be processed correctly.

Stage 3 To specify the target namespace for the WSDL document

Stage 4 To generate the WSDL document



3 Click Save. The WSDL generator generates the WSDL document. Developer then displays a message that lists the WSDL document file and the directory in which it stored the file.

4 Click OK.

Note: If an error occurs during WSDL generation, Developer displays a message describing the error.


C H A P T E R 4
Generat ing a WSDL Document that Uses the SOAP Message Protocol
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Service Requirements when Using the Default SOAP Processor . . . . . . . . . . . . . . . . . . . . . 32


Service Requirements When Registering into Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . 33



C H A P T E R 4 G e n e r a t i n g a W S D L D o c u m e n t t h a t U s e s t h e S O A P M e s s a g e P r o t o c o l

OverviewWhen you specify SOAP messaging as the protocol for Web service consumers to use to communicate with a Web service, you can select the SOAP processor you want to use to handle messages sent by the Web service consumers. You can select either the default SOAP processor or a registered, custom-built SOAP processor (for example, an access-controlled processor). The processor you select will receive, process, and send SOAP messages that call the service.

The Web service for which you are generating the WSDL document will be a target service of the selected processor. Consequently, the service needs to conform to the target service requirements for the specified processor.

If you select a custom SOAP processor, make sure the service for which you are generating the WSDL document conforms to the target service requirements for the custom processor. The following section explains the service requirements if you want to use the default SOAP processor to receive and send SOAP messages for the service. For information about creating custom SOAP processors, see the SOAP Developer’s Guide.

Service Requirements when Using the Default SOAP ProcessorIf you want to use the default SOAP processor to handle the SOAP message request and response for the service, the target service for which you are generating the WSDL document must meet these requirements:

The service input signature must contain a soapRequestData object and a soapResponseData object, and its output signature must contain a soapResponseData object. You can use pub.soap.utils:requestResponseSpec to specify the inputs and outputs for the service.

The service should use the SOAP data-retrieval services, such as pub.soap.utils:getBody, pub.soap.utils:getHeader, pub.soap.utils:getBodyEntries, and pub.soap.utils:getHeaderEntries to extract elements from SOAP message objects. These services return the requested element as an XML node (or an array of XML nodes). To extract data from the returned node, you query it using the pub.xml:queryXMLNode service or convert it to a document using the pub.xml:xmlNodeToDocument service. For more information about these services, see the webMethods Integration Server Built-In Services Reference.

To ensure interoperability with other Web service vendors, you must provide a universal name for the target service. The universal name must include both a namespace name, which must consist of a valid URI, and a local name, which must conform to the naming conventions specified in http://www.w3.org/TR/REC-xml-names/#NT-NCName. The universal name should conform to the XML QName naming conventions specified in http://www.w3.org/TR/REC-xml-names/#NT-QName.







Service Requirements when Using the Default SOAP Processor

In addition to these requirements, you should also check the target service’s Execute ACL permission to ensure that consumers of the service can invoke it.

For more information about creating a target service for the default SOAP processor, see the SOAP Developer’s Guide.

Service Requirements When Registering into Servicenet

Servicenet only accepts services that use the “wrapped” Document Literal binding style. In other words, the service input signature or output signature must consist of a single top-level element. If you attempt to register a service using the SOAP Message protocol and the input or output signature consists of multiple top-level fields, Developer will display an error message.

The following input and output signatures will be accepted by Servicenet. Each signature is composed of a single, top-level field (Order and OrderRecord) containing the variables.

Top-level elements in input and output signatures

Note: You assign a universal name to a service in Developer by completing the Namespace name and Local name fields on the service's Properties panel.

Tip! If you use Servicenet to manage your Web services, you can simply drag a service from the Navigation panel to the Servicenet tab to automatically generate the WSDL. For more information, see Chapter 6, “Using Servicenet to Register and Bind to Web Services”.



The following input and output signatures have the same fields, but all the fields are top-level elements. These signatures will result in an error message from Servicenet.

Multiple elements in input and output signatures

Input and Output Signature RequirementsWhen you specify SOAP messaging as the protocol for accessing a Web service, you specify an IS document type or XML Schema component to represent the input and output signature of the service. The signature describes the XML documents that the service requires as input and produces as output.

The WSDL generator does not create the input and output messages for the WSDL document from the signature specified on the Input/Output tab of the service. This is because target services for the default processor and custom SOAP processors must have a soapRequestData object and a soapResponseData as input and produce a soapResponseData object as output. While this signature requirement is necessary for the processor, it does not provide meaningful signature information for WSDL documents generated for the services used with these processors. In an XML Schema definition, a soapRequestData object and a soapResponseData object would be represented as elements of type anytype. To produce a meaningful, descriptive signature for the WSDL document, you can select an IS document type or an XML schema element declaration to represent the service input and output signature.

When you specify the default SOAP processor for handling the SOAP message requests and responses for a service, the IS document type or XML Schema component that you select for the input and output signatures must follow some naming and property requirements.

For input signatures, the requirements are a result of the default SOAP processor’s routing behavior. The default processor routes messages to services by matching the fully expanded QName of the message body’s first element to the universal name of the target service. If the QName of the message body’s first part does not resolve to the universal name of the service, the Integration Server returns an error message stating that the service cannot be found.



If you specify the default SOAP processor for handling the SOAP message requests and responses for the service, the IS document type or XML Schema element declaration that describes the input and output signature must meet the following requirement:

The top-level fields of an IS document type or XML Schema component must be associated with an XML namespace and include an XML namespace prefix. In Developer, this means that the XML Namespace property must be set for each top-level field and the field name must contain a prefix in the format prefix:localName.

For example, suppose that the explicit universal name of the service gl.journals:journalEntry has a namespace name of http://www.exprint.com/GL/ and a local name of JournalEntry. The first top-level field of the IS document type that describes the input signature must be named prefix:JournalEntry, where prefix represents the XML namespace URI. Additionally, the value of the XML Namespace property for the JournalEntry field must be http://www.exprint.com/GL/.

If a top-level field of the service’s input or output signature is of type String, the field must be namespace qualified and the field name must contain a prefix in the format prefix:localName. If the field’s Content type property in the Constraints category of the Properties panel is not set (that is, does not contain a valid URI), the WSDL generator sets the field to type xsd:String.

In addition, the input signature must also meet the following requirements:

The IS document type or XML Schema component used for an input signature must contain at least one field.

The first top-level field’s XML Namespace property in Developer must match the Namespace name value of the service’s explicit universal name and its local name must match the Local name value of the service’s explicit universal name.

Note: You can generate a WSDL document using an IS document type or XML Schema component whose top-level fields are not namespace qualified by setting the server configuration parameters watt.server.wsdl.enforceSOAPMsgPartNS and watt.server.SOAP.enforceMsgPartNS to False. For more information about these parameters, see the webMethods Integration Server Administrator’s Guide.

However, for interoperability with other SOAP implementations, we recommend that you run your server with these parameters enabled (the default setting) and that you use IS document types or XML Schema components with top-level fields that are namespace qualified.

Note: The WSDL generator treats variables with the same QName as identical variables even if the variables are declared as different types.



The following table lists additional requirements for developing the service’s input and output signature and how they apply to the SOAP MSG protocol. The other chapters that describe how to generate WSDL documents also contain this table so you can easily compare requirements across protocols.

Service signature requirements for the SOAP MSG protocol

Important! To ensure interoperability with other Web service vendors, the Namespace name value of the service’s explicit universal name must be a valid URI.

Case Applies? Notes



Top-level objects and documents are allowed. Yes For Servicenet, multiple top-level objects are not supported.


No Including a string, object, or document list at the top level will not result in a WSDL generation error. However, top-level lists cannot be represented in a WSDL document.

Top-level string tables are allowed. No




String tables are allowed. No

Field names


No


Yes Omitting the prefix will not result in a WSDL generation error. However, the target SOAP message service may have runtime mapping errors when handling namespace qualified messages.


Yes






Yes Naming a top-level field *body, or beginning the name of a top-level field with the character @, will not result in a WSDL generation error. However, because mixed content models or attributes cannot be represented in a WSDL document’s message element, these fields will not appear in a client generated from this WSDL document.


No






No


No



Yes


Yes


Yes However, the WSDL generator uses only one field’s type and properties for all fields with that name at that level. Because the method used to select the field is not defined, webMethods recommends avoiding this case.

Case Applies? Notes



Generat ing the WSDL DocumentTo create a WSDL document that specifies the SOAP messaging protocol, do the following:

Field properties


Yes


Yes


No






Case Applies? Notes


Stage Description



3 Specify the input signature for the Web service.



1 Open the service for which you want to generate a WSDL document.



4 Describe the output format of the Web service.

5 Specify the target namespace for the generated WSDL document.


Stage Description











By default, the Port box identifies the port you used to open the current Integration Server. If you want to use a different port, type the number of that port in the Port box. The port you identify must be able to accept either HTTP requests or HTTPS requests. If you do not require that requests from Web service consumers be sent securely, specify a port that accepts HTTP requests. If you want requests from Web service consumers to be sent securely, specify a port that accepts HTTPS requests.

1 Under Protocol, click SOAP-MSG. Developer enables the Directive, Input, and Output boxes.


3 From the Directive list, select the process directive for the SOAP processor you want to use to receive, process, and send SOAP messages that invoke the target service. If you want to use the default processor, click default.


Important! To ensure interoperability with other Web service providers, the Namespace name value of the service’s explicit universal name must be a valid URI. Use the Properties panel in Developer to assign a universal name to a service.

Note: The Directive list displays all registered SOAP processors on the Integration Server to which you are currently connected. If you plan to move the service to a production Integration Server, make sure the directive you select corresponds to a SOAP processor that is registered on the production server as well.



You can describe the input signature for the WSDL document using an IS document type or using an element declaration from an XML Schema. Use one of the following procedures to define the input message for the Web service.

1 Next to the Input box on the Generate WSDL dialog box, click . Developer opens the Select Input/Output Constraint dialog box.

Select Input/Output Constraint dialog box

2 Under Choose Constraint Type, click Document Type.

3 Identify the IS document type you want to use to describe the input signature. You can either type the fully qualified name of the IS document type in the Name box or click the IS document type in the Folder box.

4 Click OK. Developer closes the dialog box and displays the fully qualified name of the IS document type in the Input box on the Generate WSDL dialog box.

1 Next to the Input field, click . Developer opens the Select Input/Output Constraint dialog box.

2 Under Choose Constraint Type, click Schema Component.

Stage 3 To describe the input signature for the Web service

To describe the input signature using an IS document type

To describe the input signature using an XML Schema



3 In the text field, after http://, type the Web location and name of the XML Schema that contains the element declaration you want to use to describe the input signature.

4 Click Load. Developer groups the element declarations in the XML Schema under the ELEMENTS heading. Expand the heading to view the global element declarations in the XML Schema.

5 Select the global element declaration that you want to use to represent the input signature.

6 Click OK. Developer closes the dialog box and displays the name of the selected element declaration in the Input box on the Generate WSDL dialog box.

You can describe the output signature for the WSDL document using an IS document type or using an element declaration from an XML Schema. See “To describe the input signature for the Web service” on page 41 for instructions.

1 In the Target Namespace box, specify the target namespace for the WSDL document. By default, the Target Namespace box displays http://host/ as the target namespace, where host is the name of the server you are currently logged on to. If you want to specify a different namespace, type the URI for that namespace in the box.





4 Click OK.

Important! The XML Schema you identify must be located on the Web and must be accessible to consumers of the WSDL.

Stage 4 To describe the output signature for the Web service





C H A P T E R 5
Generat ing a WSDL Document that Uses the HTTP POST or GET Protocol
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Service Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44




C H A P T E R 5 G e n e r a t i n g a W S D L D o c u m e n t t h a t U s e s t h e H T T P P O S T o r G E T P r o t o c o l

OverviewWhen you specify HTTP POST as the protocol for Web service consumers to use to communicate with a Web service, you can specify text/XML or URL encoded as the input format for the service. When you select HTTP GET as the protocol, Developer automatically sets the input format to URL encoded.

When you specify HTTP POST or HTTP GET as the protocol for the WSDL document, keep the following points in mind:

When you select URL encoded as the input format, the WSDL generator uses the input parameters declared on the Input/Output tab of the service to create the input message for the WSDL document. However, for the URL encoded input format, the input signature can only contain String variables. The input signature should not contain document, document list, Object, Object list, String list, or String table variables because these variables cannot be represented in name=value pairs in the HTTP request.

When you select text/XML as the input format, you can select an IS document type or XML Schema component (element declaration) to describe the incoming XML document.

For the HTTP protocols, Developer selects text/XML as the output format. You must select an IS document type or XML Schema component (element declaration) to represent the outbound XML document.

For more information about describing the service input and output for the HTTP protocols, see “Input and Output Signature Requirements” on page 45.

Service RequirementsWhen you specify HTTP POST or HTTP GET as the protocol for a WSDL document, the target service for which you are generating the WSDL document must meet these requirements:

The service must return an XML document to Web service consumers. When generating a WSDL document, the WSDL generator assumes that all services invoked via an HTTP request will return an XML document (text/xml content). To return an XML document, a service can do one of the following:

Call the pub.flow:setResponse service. This service takes any string and returns it as the body of an HTTP response. For more information about the pub.flow:setResponse service, see the webMethods Integration Server Built-In Services Reference.

Create and assign an XML output template to the service. You can use an XML output template to extract values from the pipeline and insert those values as element content in an XML tag. For more information about output templates, see Dynamic Server Pages and Output Templates Developer’s Guide.



If you select HTTP POST as the protocol and text/XML as the input format, the service input signature must include an object type named node. When webMethods Integration Server receives an HTTP POST request where the Content-Type header is text/XML, the server automatically parses the body of the request (the XML document) and passes it as an XML node to the service specified in the request’s URL. To extract data from the returned node, you query it using the pub.xml:queryXMLNode service or convert it to a document using the pub.xml:xmlNodeToDocument service.

Because an XML node object does not provide meaningful signature information for the WSDL document, you can select an IS document type or XML Schema component to describe the input signature. The IS document type or XML Schema component you select describes the XML document the service expects as input. See “Input and Output Signature Requirements” for more information about specifying IS document types and XML Schema components.

In addition to these requirements, you should also check the target service’s Execute ACL permission to ensure that consumers of the service can invoke it.

Input and Output Signature Requirements When you specify HTTP POST or GET as the protocol for accessing a Web service, you can specify an IS document type or an XML Schema element declaration to represent the input and output signature of the service. The signature describes the XML documents the service requires as input and produces as output.

Text/XML RequirementsThe following table lists the requirements for developing the service’s input and output signature when text/XML is selected as the input or output format. The other chapters that describe how to generate WSDL documents also contain this table so you can easily compare requirements across protocols.

Important! You must use the pub.flow:setResponse service or an XML output template to return an XML document, or Integration Server will return an HTML document to the HTTP request.

Note: An XML node is an element-based representation of an XML document. The node expresses a document in a tree-like structure that allows the data within it to be addressed and linked into services.



Service signature requirements when text/XML is specified as the input or output format

Case Applies? Notes



Top-level objects and documents are allowed. Yes


No Including a string, object, or document list at the top level will not result in a WSDL generation error. However, top-level lists cannot be represented in a WSDL document.





String tables are allowed. No

Field names


No


No


Yes


Yes Naming a top-level field *body, or beginning the name of a top-level field with the character @, will not result in a WSDL generation error. However, because mixed content models or attributes cannot be represented in a WSDL document’s message element, these fields will not appear in a client generated from this WSDL document.


No










No


No



Yes


Yes


Yes However, the WSDL generator uses only one field’s type and properties for all fields with that name at that level. Because the method used to select the field is not defined, webMethods recommends avoiding this case.

Field properties


Yes


No


No

Case Applies? Notes



URL Encoded RequirementsThe following table lists the requirements for developing the service’s signature when URL encoded is selected as the input format. The other chapters that describe how to generate WSDL documents also contain this table so you can easily compare requirements across protocols.

Service signature requirements when URL encoded is specified as the input format






Case Applies? Notes


In addition, The WSDL generator treats variables with the same QName as identical variables even if the variables are declared as different types.

Case Applies? Notes



Top-level objects and documents are allowed. No


No





Strings, objects, and documents are allowed. n/a The URL encoded input format does not support documents.

String, object, and document lists are allowed. n/a The URL encoded input format does not support documents.

String tables are allowed. n/a The URL encoded input format does not support documents.

Field names


No


No


Yes


No


n/a The URL encoded input format supports only scalar string fields.






No Fields cannot contain asterisks (*) anywhere in the field name.


No Fields cannot contain the character @ anywhere in the field name.


Case Applies? Notes






n/a The URL encoded input format does not support XML namespaces.





Field properties


n/a The URL encoded input format does not support Document or Document list type fields.


No The URL encoded input format does not support XML namespaces. Therefore, fields must not be associated with an XML namespace.


n/a The URL encoded input format does not support documents.

Recursive documents are allowed. n/a The URL encoded input format does not support documents.





Case Applies? Notes


In addition, The WSDL generator treats variables with the same QName as identical variables even if the variables are declared as different types.



Generat ing the WSDL DocumentTo create a WSDL document that specifies the HTTP POST or HTTP GET protocol, you do the following:

1 In the Navigation panel, select the service for which you want to generate a WSDL document.


Stage Description



3 Specify the input format of the Web service.

4 Describe the output format of the Web service.

5 Specify the target namespace for the generated WSDL document.













By default, the Port box identifies the port you used to open the current Integration Server. If you want to use a different port, type the number of that port in the Port box. The port you identify must be able to accept either HTTP requests or HTTPS requests. If you do not require that requests from Web service consumers be sent securely, specify a port that accepts HTTP requests. If you want requests from Web service consumers to be sent securely, specify a port that accepts HTTPS requests.



1 Under Protocol, click HTTP-POST or HTTP-GET. Developer changes the boxes on the dialog box. The following figure shows an example of the dialog box when you click HTTP-POST; when you click HTTP-GET, the dialog box is similar, except that the Input format and Input boxes are disabled.

Generate WSDL dialog box with HTTP-POST selected


3 The Integration Server’s default directive for invoking services via an HTTP request is invoke. If you need to specify another directive for Web service consumers to use to invoke the service, type the directive in the Directive box.

4 By default, the Path box provides the path to the Web service as it currently exists in the Navigation panel. If the Web service will reside in a different folder at production time, type the path to that folder in the Path box. Use the format folder.subfolder.subfolder/service.

5 If you selected HTTP-GET as the protocol for Web service consumers to use to communicate with the Web service, skip to “To describe the output signature for the Web service” on page 56. If you selected HTTP-POST, continue with “To specify the input format of the Web service (HTTP-POST protocol only)” on page 54.




If you selected HTTP-POST as the protocol for Web service consumers to use to communicate with the Web service, you must specify the input format in which the Web service requires input. You can specify the input format in one of the following ways:

1 In the Input format list on the Generate WSDL dialog box, click text/xml.

2 Next to the Input box, click . Developer opens the Select Input/Output Constraint dialog box.

Stage 3 To specify the input format of the Web service (HTTP-POST protocol only)

If the Web service expects input in the form of... Take this action...

Name=value pairs in the POST that invokes the Web service

Click URL encoded in the Input format list, then skip to “To describe the output signature for the Web service” on page 56. The WSDL generator uses the input signature on the Input/Output tab of the Web service to create the input message for the WSDL document.

An XML document, and you want to describe the input signature for the WSDL document using an IS document type

Go to “To describe the input signature using an IS document type” on page 54.

An XML document, and you want to describe the input signature for the WSDL document using an element declaration from an XML Schema

Go to “To describe the input signature using an XML Schema” on page 55.





3 Under Choose Constraint Type, click Document Type.

4 Identify the IS document type you want to use to describe the input format. You can either type the fully qualified name of the IS document type in the Name box or click the IS document type in the Folder box.

5 Click OK. Developer closes the dialog box and displays the fully qualified name of the IS document type in the Input box on the Generate WSDL dialog box.

1 In the Input format list, click text/xml.


3 Under Choose Constraint Type, click Schema Component.


5 Click Load. Expand the ELEMENTS headings to view the global element declarations in the XML Schema.



Note: If an XML Schema definition does not contain an element declaration, Developer does not display the ELMENTS heading.




7 Click OK. Developer closes the dialog box and displays the name of the selected element in the Input box on the Generate WSDL dialog box.

Describe the XML document the Web service produces as output. Complete the Output format box using the instructions in “To specify the input format of the Web service (HTTP-POST protocol only)” on page 54.

1 In the Target Namespace box, specify the target namespace for the WSDL document.






4 Click OK.

Stage 4 To describe the output signature for the Web service





C H A P T E R 6
Using Servicenet to Register and Bind to Web Services
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

What Is webMethods Servicenet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Connecting to Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Refreshing and Disconnecting a Servicenet Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Viewing Servicenet in the Developer Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Registering a Service in Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Updating a Service that is Registered in Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Removing a Service from Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Browsing for Web Services in Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Binding to a Web Service in Servicenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75


C H A P T E R 6 U s i n g S e r v i c e n e t t o R e g i s t e r a n d B i n d t o W e b S e r v i c e s

Introduct ionThis chapter provides information about using webMethods Developer with webMethods Servicenet to register, bind to, and browse for Web services.

What Is webMethods Servicenet?webMethods Servicenet is a comprehensive Web-services framework that delivers shared infrastructure for SOA-based applications (Services Oriented Architecture). It provides features that enable you to manage, monitor, and secure the systems that you build with Web services.

Servicenet runs in the space between your Web service providers and your Web service consumers. It provides:

A UDDI-based registry for cataloging and discovering the Web services in your organization, including services that run on Integration Server.

Instrumentation that monitors the operation of your Web services.

Automatic failover and load-balancing of Web services.

Automatic routing of messages based on message content.

Service Level Agreements (SLAs) that stipulate the qualities-of-service to be enforced between individual services and their consumers.

WS-Security infrastructure with support for LDAP, Security Assertion Markup Language (SAML), message encryption, and x.509-based digital signatures.

When working with Servicenet from Developer you can:

Discover the Web services registered in Servicenet. Developer displays a list of the Web services that are registered in Servicenet. By default, Developer displays all registered services, but you can use a filter to limit the number of services shown.

Register services in Servicenet. You can make a service that resides on Integration Server (such as a flow service, Java service, C/C++ service, or adapter service) available as a Web service by registering it in Servicenet.

Bind to a Web service in Servicenet. You can incorporate a Web service into your integration solution by binding to the Web service. When you bind to a service, Developer generates a Web service connector.


Requirements

RequirementsTo use Developer to register, bind to, and browse Web services in Servicenet, you must have the following:

webMethods Developer 6.5, Service Pack 1

webMethods Servicenet Release 6.5.0.5

Connect ing to Servicenet To use Developer to view, register, or bind to a Web service in Servicenet, you must first connect to Servicenet (specifically, to the Servicenet registry).

1 Start Developer.

2 Open a Servicenet session by selecting Session Open Servicenet.

Open Servicenet Dialog Box

Note: Developer 6.5 without Service Pack 1 is only compatible with webMethods Fabric Release 1.0.2.

Note: You can connect to only one Servicenet registry at a time, which means you can only open one Servicenet session at a time from Developer. If you open a new Servicenet session while already connected to a Servicenet registry, Developer automatically closes the existing session before opening a new one.

To connect to Servicenet



3 In the Connect Using list, select one of the following:

4 Enter the Servicenet registry location in the Subnet locator port or WAN locator URL field.

5 Click OK. The Servicenet tab lists all of the Web services in the Servicenet registry to which you are connected.

Refreshing and Disconnect ing a Servicenet SessionThe Servicenet tab is not dynamically updated when other users add or delete Web services from Servicenet or when Developer loses its connection to Servicenet. Use the following procedure to refresh the display and to explicitly disconnect from Servicenet.

Select Session Refresh Servicenet or click on the Servicenet tab.

Select Session Close Servicenet or click on the Servicenet tab.

Select... To...

Subnet locator port Connect to the Servicenet registry via the subnet port configured for the registry. The subnet locator broadcasts a User Datagram Protocol (UDP) ping out to the subnet to locate the Servicenet registry using the port you enter in this field. Developer then binds to the registry using that port. Use this method to connect to a Servicenet running on your Intranet.

Important! The subnet locator only works if the Servicenet registry and Developer are hosted on machines that reside on the same subnet. If you cannot connect to the Servicenet registry using a subnet locator, the hosts for these components could be on different subnets. In this case, you must use a WAN locator URL to connect to Servicenet.

WAN locator URL Connect to the URL of a Servicenet registry running in your wide area network (WAN).

Note: You cannot specify an HTTP proxy when connecting to Servicenet.

Important! If you want to reduce the number of services displayed in the Servicenet tab, try defining a filter. See “Applying a Filter to Servicenet” on page 72 for instructions.

To refresh the Servicenet session

To disconnect from Servicenet


Viewing Servicenet in the Developer Window

Viewing Servicenet in the Developer WindowWithin the Developer window, the Servicenet tab displays the Web services registered in the Servicenet registry to which you are connected. The Servicenet tab is located below the Navigation panel.

Within the Servicenet tab, Web services are sorted in alphabetical order. Simply select a Web service to view more information about the service.

Working with Servicenet in Developer

Servicenet tab

Note: When you select a Web service in the Servicenet tab, the Properties panel displays the properties of the Web service you selected, but the editor (the middle area of the Developer window between the Navigation and the Properties panels) does not change. It still displays details for the service selected in the Navigation panel. This is because Web service details and logic for a Servicenet service cannot be modified using Developer.



Servicenet Tab IconsThe Servicenet tab contains icons to represent Servicenet and the Web services that are registered within Servicenet. The following table identifies these icons.

For more information about concrete and virtual Web services, see the webMethods Servicenet User’s Guide.

Servicenet ToolbarThe following buttons on the Servicenet tab are shortcuts to frequently-used commands.

This icon... Represents...

Servicenet. All Web services registered in the Servicenet registry appear below the Servicenet name. As part of the Servicenet name, Developer displays the subnet port or WAN locator URL of the Servicenet registry to which you are connected.

A concrete Web service. A concrete service is a service that uses specific XML- based protocols and interface descriptions to communicate. It represents an endpoint that hosts an actual service. From the Servicenet panel in Developer, you can create a Web service connector from a selected Web service or delete a concrete Web service.

A virtual Web service. A virtual service is an HTTP (or HTTPS) endpoint that accepts SOAP messages and routes them to actual service endpoints. An intermediary agent enforces security and collects performance data for the services managed by the virtual service. From the Servicenet panel in Developer, you can create a Web service connector from a selected virtual service. You cannot create or delete a virtual Web service using Developer; you must do this from the Servicenet console.

Use this button... To...

Connect to a Servicenet session while working in Developer. Equivalent to Session > Open Servicenet.

Disconnect from a Servicenet session while working in Developer. Equivalent to Session > Close Servicenet.

Refresh the display of Web services. Equivalent to Session > Refresh Servicenet.


Viewing Servicenet in the Developer Window

Web Service Propert iesWhen you select a Web service in the Servicenet tab, Developer displays a set of properties in the Properties panel.

General properties contain basic information about the Web service, such as name, description, and location.

Servicenet internal properties contain system information used by Servicenet to perform failover, load balancing, and monitoring.

In Developer, Web service properties are display-only. However, you can modify some properties, such as name and description, using the Servicenet console. The following table describes the Web service properties:

Create an expression that filters the contents of the Servicenet tab based on the value of a Web service property. Equivalent to Session > Set Servicenet Filter.

Remove the filter from the contents of the Servicenet tab and display all the registered Web services. Equivalent to Session > Clear Servicenet Filter.

Property Description

name Specifies the name of the Web service.

description Describes the Web service.

WSDL A URL that specifies the location of the WSDL (Web Service Description Language) document that describes the Web service.

endpoint A URL that specifies the network address of the Web service.

since Specifies the date and time the metadata of the Web service was last updated in Servicenet.

serviceKey Specifies the universally unique identifier for the UDDI (Universal Description, Discovery, and Integration) businessService entry that corresponds to this Web service in a UDDI registry.

custom Specifies the custom metadata for this Web service. Custom metadata is user-defined metadata that does not fit into any of the standard metadata categories for the Web service. Custom metadata can be added when the Web service is published to Servicenet. Custom metadata is displayed in the key=value format.

Use this button... To...



online Specifies whether the Web service is currently available. Servicenet considers the Web service to be available if Servicenet has successfully contacted the service recently. True indicates that the Web service is currently available. False indicates that the Web service is offline.

interfaceSignature Specifies a string generated by Servicenet to represent the types defined in the Web service.

messageSignature Specifies a string generated by Servicenet to represent the input and output parameters of the Web service. Web services with identical messageSignatures can receive the same messages.

version Displays the version number of the Web service, if one was assigned by the user.

registryPath Displays the relative path on which the service is available.

parentContainerWsdlUrl

Displays the URL of the WSDL for the Web service's container manager (that is, its agent). If the field is blank, then the container that hosts the service does not have an agent.

managed Indicates whether Servicenet manages the Web service. If the field is True, the Web service is managed by Servicenet, that is, performance data can be gathered on it and it can be secured with WS-Security. If the field is blank, the Web service is unmanaged, that is, it is listed in the Servicenet registry but cannot be monitored or secured.

Property Description


Registering a Service in Servicenet

Registering a Service in ServicenetFor a service (flow, Java, C/C++, adapter) to be available as a Web service through Servicenet, you must register it in Servicenet (that is, add it to the Servicenet registry).

When you use Developer to register a service in Servicenet, the Integration Server creates a WSDL file. The WSDL describes the information a Web service consumer needs to send data to, invoke, and receive data from a Web service. This information includes the operations the service performs, location of the service, the protocol required to invoke the service, and required input and output parameters.

Keep the following points in mind when you register a service in Servicenet using Developer:

Only services that use the SOAP RPC or SOAP Message protocol can be registered in Servicenet. Services that use the HTTP POST and GET protocol cannot be registered in Servicenet. Refer to the SOAP Developer’s Guide for more information.

If you register a service that uses the SOAP Message protocol, the input signature for that service must consist of a single, top-level field and the output signature must also consist of only a single, top-level field. This is because Servicenet expects such services to exchange messages using the “wrapped” Document Literal binding style. If you attempt to register a service using the SOAP Message protocol and its input or output signatures consists of multiple top-level fields, you will receive an error message. The error message appears in the Developer console. That is, it only appears when you run Developer from the command line.

Any service containing a variable with one of the following String content types is not supported by Servicenet:

anySimpleType

ENTITIES, IDREFS, NMTOKENS

gDay, gMonthDay, gMonth, gYear, gYearMonth

time

NOTATION

When registering an adapter service in Servicenet, if the service returns values in the pipeline that do not match the output signature, you must do one of the following:

Wrap the service in a flow to add or drop variables to match the output signature.

Change those variable properties to optional fields (where applicable).

Note: After an IS service has been registered in Servicenet, the registered Web service must be deleted from the Servicenet registry before it can be replaced with an updated version of the IS service. For more information, see “Updating a Service that is Registered in Servicenet” on page 71.



To register a service in Servicenet, do the following:

1 From the Servicenet tab, open a session on the Servicenet in which you want to register a service.

2 In the Navigation panel, select the service you want to register in Servicenet.

Stage Description

1 Identify the service you want to register as a Web service in Servicenet.

2 Specify the protocol and transport mechanism for the Web service consumers to use to communicate with the Web service.

3 Specify the input signature for the Web service. (SOAP Message protocol only) The input signature for the service must consist of only a single top-level field.

4 Specify the output signature for the Web service. (SOAP Message protocol only) The output signature for the service must consist of only a single top-level field.

5 Specify the target namespace.

Tip! If you specified the actual DNS name or IP address of the Integration Server when you logged on to Developer, you can register a service simply by dragging it directly from the Navigation panel to the Servicenet tab. The service will be registered in Servicenet with the following characteristics:

SOAP-RPC as the protocol with the RPC directive.

http://host:port as the default target namespace for the WSDL.

However, if you used localhost as the address of the Integration Server when you logged on to Developer, the Integration Server will build the wrong URL when the service is registered. In that case, you must follow the full procedure to register a service.

Stage 1 To select a service to register in Servicenet



3 On the Tools menu, click Register in Servicenet. Developer opens the Register IS service ‘servicename’ in Servicenet dialog box.

Register IS service ‘servicename’ in Servicenet dialog box

4 In the Host field, select the host machine on which the Web service will reside at production time. By default, this field specifies the machine on which the current Integration Server resides.

5 In the Port field, select the number of the port you want to use to accept requests to invoke the service from Web service consumers. By default, this field specifies the port you used to connect to the current Integration Server.

1 Under Protocol, click SOAP-RPC or SOAP-MSG.

The Transport field is pre-selected for you, based on the port that was selected above. It specifies the transport mechanism, either HTTP or HTTPS, to be used with this port.

2 Select a directive:

For SOAP-RPC. From the Directive list, select the directive of the SOAP processor to which you want requests for this service directed. If you want requests for this service

Important! If this field contains localhost, change the value to the actual name or IP address of the machine on which the service resides (that is, the name of the machine on which the Integration Server to which Developer is connected resides). Otherwise, when a client on a different machine tries to invoke the service, the client will look on its own machine for the service. To prevent this problem, always log on to Developer using the actual DNS name or IP address of the Integration Server.




routed to the Integration Server’s default SOAP RPC processor, select rpc. If you want to use a custom RPC processor that is registered on your Integration Server, select its directive.

For SOAP-MSG. From the Directive list, select the directive for the SOAP processor that you want to use to receive, process, and send SOAP messages that invoke the target service. If you want to use the default processor, select default.

You can describe the input signature for the Web service using an IS document type or using an element declaration from an XML Schema.

1 Next to the Input field on the Register IS service dialog box, click . Developer opens the Select Input/Output Constraint dialog box.


2 Under Choose Constraint Type, select Document Type.

Note: The Directive list displays all registered SOAP processors on the Integration Server to which you are currently connected. If you plan to move the service to a production Integration Server, make sure the directive you select corresponds to a SOAP processor that is registered on the production server as well. For information about creating and registering your own SOAP processor, see the SOAP Developer’s Guide.

Stage 3 To describe the input signature for the Web service (SOAP Message protocol only)




3 Identify the IS document type you want to use to describe the input signature. You can either type the fully qualified name of the IS document type in the Name field or click the IS document type in the Folder box.

4 Click OK. Developer closes the dialog box and displays the fully qualified name of the IS document type in the Input field on the Register IS service dialog box.


2 Under Choose Constraint Type, select Schema Component.


4 Click Load. Developer groups the element declarations in the XML Schema under the ELEMENTS heading. Expand the heading to view the global element declarations in the XML Schema.


6 Click OK. Developer closes the dialog box and displays the name of the selected element declaration in the Input box on the Register IS service dialog box.

You can describe the output signature for the Web service using an IS document type or using an element declaration from an XML Schema. See “To describe the input signature for the Web service (SOAP Message protocol only)” above for instructions.

Note: The signature must consist of a single top-level field. Servicenet expects Web services using the SOAP Message protocol to use the “wrapped” Document Literal binding style. For an example, see “Service Requirements When Registering into Servicenet” on page 33.



Stage 4 To specify the output signature (SOAP Message protocol only)



1 In the Target Namespace box, specify the target namespace for the Web service.


2 Click OK. Developer registers the service in Servicenet.

Stage 5 To specify the target namespace

Important! If this field contains localhost, change the value to the actual name or IP address of the machine on which the service resides (that is, the name of the machine on which the Integration Server to which Developer is connected resides). Otherwise, when a client on a different machine tries to invoke the service, the client will look on its own machine for the service. To prevent this problem, always log on to Developer using the actual DNS name or IP address of the Integration Server.

Note: If Developer cannot display the service you just registered in the Servicenet tab because of the filter setting, it will display a message stating so. To see the service in the list, clear the filter by selecting Session Clear Servicenet Filter or by clicking on the Servicenet tab.


Updating a Service that is Registered in Servicenet

Updat ing a Service that is Registered in ServicenetAfter you have registered an IS service in Servicenet, if you make certain changes to the IS service in Developer (such as moving or renaming the service, or modifying the input or output signature), you must follow the process below to re-register the IS service in Servicenet. Otherwise, Servicenet will register an entirely new Web service with new message and interface signatures instead of updating the original Web service in the Servicenet registry.

1 From Developer, select the IS service and make changes as necessary.

2 Select the Servicenet tab and open a session on the Servicenet in which the service is registered.

3 In the Servicenet tab, select the Web service you want to update, right click, and select Delete.

4 After the Web service is deleted from the Servicenet registry, register the updated version of the IS service, as shown in “Registering a Service in Servicenet” on page 65.

If there is a virtual service routing to this Web service, then see the Managing Services chapter in the webMethods Servicenet User’s Guide for information on reloading the WSDL cache for an intermediary.

To update a service registered on Servicenet

Important! If you drag and drop an updated IS service into the Servicenet tab without first deleting the original version from the Servicenet tab, two identical icons with different properties will be displayed for the same service in the Servicenet tab. Delete both icons and re-register the updated version of the IS service.



Removing a Service from ServicenetUse the following procedure to remove a service from Servicenet. When you remove a service from Servicenet, the service still exists on the Integration Server, but it is no longer registered in Servicenet.

1 Click on the Servicenet tab to open a session. Specify the Servicenet from which you want to remove a service.

2 In the Servicenet tab, select the service you want to remove, right click, and select Remove from Servicenet.

Browsing for Web Services in ServicenetAfter you establish a session on Servicenet, you can browse for Web services that you would like to incorporate into your integration solution. You can discover Web services by simply scrolling through the Servicenet tab. To assist in the discovery process, you can reduce the number of displayed Web services by filtering the contents of the Servicenet tab. You can filter by:

Creating an expression that filters the Servicenet based on the value of a specified Web service property.

Showing or hiding offline services.

By default, the Servicenet tab displays all services registered in the Servicenet, including offline services.

Applying a Fi lter to Servicenet The following procedure explains how to create and apply a filter to the contents of the Servicenet tab.

To remove a Web service from Servicenet

Note: You cannot delete a virtual Web service; Remove from Servicenet will be disabled.

Important! If you are unable to connect to Servicenet using a subnet locator, your Servicenet and Developer components could be on different subnets. Subnet locators can only connect components within the same subnet of your network. In this case, you must use a WAN locator URL to connect to Servicenet, rather than a Subnet locator port.


Browsing for Web Services in Servicenet

1 Select Set Servicenet Filter from the Session menu, or click on the Servicenet tab.

2 In the Filter Servicenet dialog box, if you want to create an expression that filters the contents of the Servicenet tab based on the value of a Web service property, do the following:

a Select the Filter on Properties check box.

b In the Property list, select the Web service property that you want to use in the filter.

If you want Developer to examine all the Web service properties for the specified text, select any.

If you want to use a custom metadata property with the filter, type the name of the metadata tag in the Property list.

c In the Operator list, select one of the following:

d In the Search text field, type the text that you want to use as filter criteria. Developer compares the value of the selected property with the search text you specify.

3 If you want the Servicenet tab to hide Web services that are offline, clear the Show offline services check box. Offline services are Web services that did not respond the last time Servicenet attempted to contact them.

4 Click Apply to apply the filter.

To filter the contents of the Servicenet tab

Note: Filtering on the since property is not recommended, since the timestamp is displayed in a format based on your Developer locale. You can only filter with the since property after you convert the timestamp to the number of milliseconds since the epoch.

Select... To...

contains Locate Web services where the value of the specified property contains the search text.

equals Locate Web services where the value of the specified property matches the search text exactly.

starts with Locate Web services where the value of the specified property begins with the search text.

ends with Locate Web services where the value of the specified property ends with the search text.



If you click Apply, the Filter Servicenet dialog box remains open. Click OK if you want to apply the filter and close the Filter Servicenet dialog box.

Notes:

Developer continues to apply the specified filter until you explicitly clear the filter. Developer saves the filter across Developer and Servicenet sessions.

When the button on the Servicenet tab is active, it indicates that Developer is using a filter to limit the displayed Web services.

If you register a service that does not meet the criteria specified in the currently applied filter, Developer does not display the newly registered Web service in the Servicenet tab.

Developer applies each filter that you create to the entire contents of Servicenet. For example, if you apply two filters in succession, Developer clears the first filter before applying the second filter. Developer does not apply the second filter to the results of the first filter.

Clearing an Applied Fi l ter Developer continues to use a filter to limit the contents of the Servicenet tab until you explicitly remove the filter. The following procedure explains how to remove a filter.

Select Clear Servicenet Filter from the Session menu, or click on the Servicenet tab, if it is enabled.

Developer removes the filter and displays all the registered Web services in the Servicenet.

To clear a filter


Binding to a Web Service in Servicenet

Binding to a Web Service in Servicenet When you locate a Web service that you want to use in your integration solution, you can use Developer to bind to that service. Binding involves using the information contained in the Web service’s WSDL document to build the logic that constructs and sends a message to the Web service.

When you use Developer to bind to a Web service, Developer generates a Web service connector. A Web service connector is a flow service that is generated using the information in the WSDL document associated with the selected Web service.

The Web service connector:

Uses an input and output signature that corresponds to the input and output messages defined in the WSDL document.

Contains flow steps that create and send a message to the Web service using the transport, protocol, and location information specified in the Web service’s WSDL document.

Contains flow steps that extract data from the output message returned by the service.

When you use Developer to bind to a Web service, the reporting and security functions for that service are already determined by the type of the service (unmanaged, managed, or virtual). You must use Servicenet to manage concrete services or create virtual services.

An unmanaged concrete service has not been put under management through Servicenet and does not have an intermediary. It cannot be secured or reported on. The client (Developer) binds directly to the endpoint of the Web service. When the Web service connector executes, the request to invoke the Web service goes directly to the Web service and is not routed through Servicenet.

A managed concrete service is hosted on a server that includes a Servicenet plug-in and it has been put under management through Servicenet. It uses Servicenet as an intermediary to monitor XML traffic and gather performance data, and it can be secured with WS-Security. Although using Servicenet as an intermediary provides the benefits of monitoring, it can introduce network latency and affect performance.

A service routed through a virtual service can be hosted on any server, with or without a Servicenet plug-in agent. The virtual service runs on an intermediary and acts as a proxy for a service that runs on another server. At run time, consumers submit their requests to the URL for the virtual service, which routes the requests to the endpoints of the affected Web services. A virtual service provides fail over and load balancing, as well as the same security and reporting functions of a managed concrete service.

To provide fail over and load balancing for a Web service with Servicenet, use Developer to bind to the virtual Web service that wraps it, if one exists. If those functions are not needed, then bind directly to the service itself. For more information about virtual services and monitoring in Servicenet, see the webMethods Servicenet User’s Guide.



1 On the File menu, click New.

2 In the New dialog box, select Web Service Connector. Click Next.

3 In the New Web Service Connector dialog box, select the folder in which you want to save the Web service connector and its supporting files. Click Next.

4 Under Select a source, select Servicenet Web Service. Click Next.

5 Under Select a Servicenet Web Service, select the Web service that you want to bind to.

6 Click Finish. Developer locates the WSDL for the Web service, generates the Web service connector and its supporting Integration Server elements (folders, document types, and schemas), and saves the connector and elements to the folder you specified. For more information about the elements that Developer creates, see “Supporting Elements” on page 18.

To bind to a Web service in Servicenet

Note: You cannot bind to an offline service; the online property for the Web service must be true in order to create a Web service connector. If the Web service you select is not online, Developer will not allow you to bind to it; drag-and-drop operations will not be completed and the Create Web service connector option will be disabled.

Note: If Developer cannot create or cannot completely generate a Web service connector from the WSDL document because the WSDL document is invalid or is missing WSDL elements, Developer displays error messages or warning messages. For more information about errors that can occur when generating connectors, see “Web Service-Related Errors and Warnings” on page 83.

Tip! There are three ways to create a Web service connector in Developer from a Web service in Servicenet:

On the File menu, click New, and follow all the steps described in the procedure above.

Select the Web service in the Servicenet tab that you want to bind to, right-click it and select Create Web service connector. Since you have already selected the Web service, you only have to select your source folder to create the connector.

Simply drag the Web service that you want to bind to from the Servicenet tab to the location in the Navigation panel where you want to save the Web service connector.


A P P E N D I X A
WSDL Documents
Basic Elements in WSDL Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

WSDL Namespace Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Sample WSDL Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81


A P P E N D I X A W S D L D o c u m e n t s

Basic Elements in WSDL DocumentsThe following table describes the basic elements in a WSDL document.

Element Description

<definitions> Contains the elements that describe a Web service.

<types> Contains the type definitions that describe the data that is received and sent by the Web service. The <types> element can reference entire XML Schemas and can contain simple type definitions, complex type definitions, and element declarations. The type definitions and element declarations help define the input and output parameters for the Web service. WSDL uses XML Schema as its native type system.

<message> Specifies the data that is received and sent by the Web service. A <message> element describes a set of input parameters or a set of output parameters. Each <message> element can contain one or more <part> elements. A <part> element associates a piece of data with a name and a type definition or element declaration. The type definition or element declaration referenced by the <part> element can be defined, declared, or referenced in the <types> element.

<operation> Specifies the messages that are received and sent by the Web service. Within the <operation> element, the <input> element identifies the message whose parts specify the input parameters to the Web service while the <output> element identifies the message whose parts specify the output parameters of the Web service. Essentially, the operation specifies the signature for the Web service. An <operation> element is declared within a <portType> element.

<portType> Defines a named set of operations. The <portType> element associates a port type name with a set of operations. A <portType> element can contain multiple operations.

<binding> Specifies the protocol and message format to use to access the operations in a port type. Each <binding> element can specify only one protocol for a port type; however, a WSDL document can define more than one binding for a single port type. A WSDL document should include one <binding> element for each protocol that it supports.


WSDL Namespace Declaration

The Address ElementThe <address> element in the <port> element specifies the location of a Web service. More specifically, the <address> element carries a location attribute that specifies the network address for a service. The WSDL generator creates a value for this attribute using the protocol, transport, host, port, and directive information that you provide when you generate the WSDL document.

For WSDL documents that specify SOAP-RPC or SOAP-MSG as the protocol, the location attribute in the <address> element has this format:

transport://host:port/soap/directive

For WSDL documents that specify HTTP-POST or HTTP-GET as the protocol, the location attribute in the <address> element is used with the location attribute in the <operation> element to specify the URL used to call the service. For WSDL documents that specify HTTP-POST and HTTP-GET as the protocol, the location attribute in the <address> element has this format, where directive is almost always invoke:

transport://host:port/directive

The location attribute in the <operation> element specifies the fully qualified path name of the service on the webMethods Integration Server and has this format:

folder.subfolder/service

WSDL Namespace Declarat ionWSDL documents use the namespace http://schemas.xmlsoap.org/wsdl/ to qualify the elements and attributes used to create the framework of WSDL documents. By convention, the WSDL namespace is given the prefix wsdl. The primary purpose of the WSDL namespace is to distinguish WSDL-related elements and attributes from elements and attributes defined in other namespaces.

The following namespace prefixes are commonly found in a WSDL document and are inserted in WSDL documents generated by the WSDL generator. The WSDL generator is the subsystem of Integration Server that generates the WSDL document for a service.

<port> Associates a binding with a network address. Together, the binding and network address specify how to invoke a Web service. Each port can specify only one network address for a binding; however, multiple ports can be defined for a single Web service. Port elements are defined within the <service> element.

<service> Groups ports that can be used to call Web services. A <service> element can contain many ports.

Element Description



Prefix Namespace URI Description

mime http://schemas.xmlsoap.org/wsdl/mime/ Namespace defined by the WSDL specification for associating a binding with the MIME protocol.

wsdl http://schemas.xmlsoap.org/wsdl/ WSDL namespace for the WSDL framework.

webM http://www.webMethods.com/noNamespace

Deprecated. This prefix is no longer used.

soap http://schemas.xmlsoap.org/wsdl/soap/ Namespace defined by the WSDL specification for associating a binding with the SOAP protocol.

http http://schemas.xmlsoap.org/wsdl/http/ Namespace defined by the WSDL specification for associating a binding with the HTTP GET and HTTP POST protocols.

xsd http://www.w3.org/2001/XMLSchema W3C XML 2001 Schema.

tns The target namespace for the WSDL document

The namespace to which elements in the WSDL document belong. This includes elements such as <types>, <portType>, <operation>, <message>, and <binding>. Elements and type definitions defined within the <schema> tag (contained in the <types> element) belong to a different target namespace.

Note: In an XML schema definition, the target namespace defines the namespace to which the element declarations, attribute declarations, and type definitions belong.


Sample WSDL Document

Sample WSDL Document The following figure shows a sample WSDL document.

<wsdl:types><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"targetNamespace="http://localhost/AuthenticateUser/AuthenticateUser"xmlns:tns="http://localhost/AuthenticateUser/AuthenticateUser">

<xsd:complexType name="__AuthenticateUserInput"><xsd:sequence>

<xsd:element name="userName" nillable="true" type="xsd:string"/><xsd:element name="password" nillable="true" type="xsd:string"/>

</xsd:sequence></xsd:complexType>

<xsd:complexType name="__AuthenticateUserOutput"><xsd:sequence>

<xsd:element name="isValid" nillable="true" type="xsd:boolean"/></xsd:sequence>

</xsd:complexType>

</xsd:schema></wsdl:types>

<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions name="AuthenticateUser"

targetNamespace="http://www.example.com/"xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"xmlns:tns="http://www.example.com"xmlns:xsd="http://www.w3.org/2001/XMLSchema"

The definitions elementis the root element ofthe WSDL document.

The WSDL documentuses these Namespace

prefixes.

A types elementencloses the data types

associated with the partsin a message.

<wsdl:message name="AuthenticateUserInput"><wsdl:part name="userName" type="xsd:string"/><wsdl:part name="password" type="xsd:string"/>

</wsdl:message>

<wsdl:message name="AuthenticateUserOutput"><wsdl:part name="isValid" type="xsd:boolean"/>

</wsdl:message>

The message specifiesthe name and type of

data exchanged by theWeb service.



<wsdl:service name="AuthenticateUserService"><wsdl:port name="AuthenticateUserPort0" binding="tns:AuthenticateUserBinding"><soap:address location="http://localhost:5555/soap/rpc"/>

</wsdl:port></wsdl:service>

</wsdl:definitions>

<wsdl:binding name="AuthenticateUserBinding" type="tns:AuthenticateUserPortType">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/><wsdl:operation name="AuthenticateUser"><soap:operation soapAction="" /><wsdl:input> <soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://www.example.com" use="encoded"/>

</wsdl:input><wsdl:output>

<soap:bodyencodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="http://www.example.com" use="encoded"/></wsdl:output>

</wsdl:operation></wsdl:binding>

A binding describes thedata format and

protocol for a port type.

A service is a collectionof ports.

A port associates abinding with a network

address.

<wsdl:portType name="AuthenticateUserPortType"><wsdl:operation name="AuthenticateUser"><wsdl:input message="tns:AuthenticateUserInput"/><wsdl:outputmessage="tns:AuthenticateUserOutput"/>

</wsdl:operation></wsdl:portType>

Each operationidentifies the data

(messages) sent andreceived by the Web

service.

A portType groups theoperations performed by

the Web service.


A P P E N D I X B
Web Service-Related Errors and Warnings
Message Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Web Service-Related Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85


A p p e n d i x B W e b S e r v i c e - R e l a t e d E r r o r s a n d W a r n i n g s

Message DisplayWhen you generate a WSDL document or create a Web service connector from a WSDL document, Developer displays a message that indicates whether the process completed successfully.

If the process completed successfully but warnings occurred, Developer displays a message to that effect. If the process did not complete successfully, Developer displays a message that says errors occurred.

When you click Details on the message dialog box, Developer provides information similar to the information in the message dialog box shown below.

Name and location of WSDL document in which the error or warning occurred.

Location of the erroror warning in the

WSDL document.

Message code.

WSDL elementsthat caused the

error or warning.

Note: When generating a Web service connector, Developer might generate some of the flow steps in the Web service connector or some of the supporting IS elements (IS document types, folders, or IS schemas) before it encounters errors or warnings. The generated elements appear in the Navigation panel.



Web Service-Related Errors and WarningsFollowing are the error messages and warning messages that can occur when webMethods Developer generates a WSDL document or creates a Web service connector using a WSDL document.

Messages Received when Generating a WSDL Document

[ISC.0077.9014] Document to XSD error: Field fieldName cannot be represented in XML Schema. The field name does not conform to the XML NCName definition.

Cause: The Developer determined that the IS document type you are using to generate a WSDL document contains field names that do not conform to the XML NCName definition.

Response: To resolve this error, rename the fields to conform to the Qname lexical rules specified in http://www.w3.org/TR/REC-xml-names/#NT-QName and the XML namespace and local naming conventions specified in http://www.w3.org/TR/REC-xml-names/#NT-NCName.

[ISC.0082.9106] Complex type <typeName> is recursive. webMethods Integration Server does not support creating a document type from an XSD with a recursive complex type.

Cause: The XML Schema contains a recursive complex type definition. The Integration Server does not support generating a document type from an IS schema containing a recursive complex type. This error only occurs when you generate an IS document type from an XML Schema.

Response: Do not try to generate a document type from a schema containing a recursive complex type.

[ISS.0092.9032] Error: Input signature cannot be used to generate WSDL using URL Encoded format. Field {0} cannot be represented in XML Schema. The field name does not conform to the XML NCName definition.

Cause: A top-level IS document type field or XML Schema element in the input signature used to generate a WSDL document is named *body or contains the characters *, @, or :. These characters represent XML Schema components (mixed content, attributes, and XML namespace prefixes) that are not applicable to URL encoded parameters.

When URL encoded is specified as the input format for the HTTP POST or HTTP GET protocols, field names used in the input signature must conform to the QName lexical rules specified in http://www.w3.org/TR/REC-xml-names/#NT-QName and the XML namespace and local naming conventions specified rules specified in http://www.w3.org/TR/REC-xml-names/#NT-NCName.

















[ISS.0092.9033] Error: Input signature cannot be used to generate WSDL using URL Encoded format. Fields cannot have XML Namespace values.

Cause: The input signature used to generate a WSDL document contains fields that are associated with an XML namespace. Fields must not be associated with an XML namespace when you select either of the following:

HTTP GET as the protocol

HTTP POST as the protocol and URL encoded as the input format

[ISS.0092.9039] Error: URL encoding does not support input variables other than strings and string lists.

Cause: The input parameters declared on the Input/Output tab contain a variable that is not a String or a String list. When URL encoded is specified as the input format for the HTTP POST or HTTP GET protocols, Integration Server uses the input parameters declared on the Input/Output tab of the service to construct the input message for the WSDL document. For the URL encoded input format, the input signature can contain only String and String list variables. The input signature should not contain document, document list, Objects, Object lists, or String table variables because these variables cannot be represented in name=value pairs in the HTTP request.

[ISS.0092.9042] Error: text/xml does not support string tables.

Cause: When you generate a WSDL document and specify HTTP POST or HTTP GET as the protocol, you can select an IS document type to describe the format of the XML document expected by or produced by the service. The IS document type cannot contain a String table variable because multi-dimensional arrays cannot be represented in an XML Schema. (Developer generates an XML Schema to define types for variables in the IS document type.)

Response: To resolve this error, remove the String table variable from the IS document type, or select a different IS document type.

[ISC.0124.9001] Document to XSD warning: For interoperability reasons, the <any> type is not used in SOAP RPC WSDL. Document {0} will be defined as closed in the XSD.

Cause: The IS document type you are using to generate a WSDL document contains variables of type Document or Document list. These variables are open (that is, their Allow unspecified fields property is set to True).

Response: To resolve this warning, set the Allow unspecified fields property in the Constraints category of the Properties panel to False. Then, regenerate the WSDL document.



[ISC.0124.9002] Document to XSD error: Document {0} cannot be represented in XML Schema. This document contains a *body field constrained by a simple type and fields that would be represented as elements in the XSD. XSD could describe this document if the simple type constraint was removed or the non-attribute fields were deleted.

Cause: The IS document type you are using to generate a WSDL document contains a field named *body that is constrained by a simple type. The IS document type also contains fields that are mapped as elements (not attributes) in the XSD. This combination cannot be mapped in an XSD.

In a mixed content environment, the Integration Server can only map complex type definitions of simple content (that is, an IS document type containing attributes and a *body variable with or without a simple type constraint) or complex type definitions of complex content (that is, an IS document type containing attributes and/or elements and a *body variable that is not constrained).

Response: To resolve this error, do one of the following:

Remove the non-attribute fields.

Remove the *body variable’s simple type constraint. First, click the browse button next to the Content type property on the variable’s Properties panel. Then, select No Constraints Specified from the Content Type list on the resulting Properties dialog box.

[ISC.0124.9003] Document to XSD error: Referenced document type {0} does not exist.

Cause: The IS document type you are using to generate a WSDL document contains a reference to a nonexistent document type.

Response: To resolve this error, restore the nonexistent document type or remove the reference to it.

[ISC.0124.9004] Document to XSD error: Field {0} is a String table. String tables cannot be represented in XML Schema.

Cause: The IS document type you are using to generate a WSDL document contains String table fields. XML Schema does not support multi-dimensional arrays.

Response: To resolve this error, remove the String table field from the IS document type or select a different IS document type.

[ISC.0124.9005] Document to XSD error: Field {0} cannot be represented in XML Schema. The field name contains a prefix but an XML Namespace property is not assigned to the field.

Cause: The IS document type you are using to generate a WSDL document contains a top-level field whose name includes a prefix (that is, the name is in the format prefix:localName). However, this field is not associated with an XML namespace.




Associate the field with an XML namespace. First, select the variable in Developer. Then, type the namespace for the variable in the XML Namespace property in the General category of the variable’s Properties panel.

Remove the prefix.

[ISC.0124.9006] Document to XSD error: Field {0} cannot be represented in XML Schema. The field name does not conform to the XML NCName definition.

Cause: The IS document type you are using to generate a WSDL document contains field names that do not conform to the XML NCName definition.

Response: To resolve this error, rename the fields to conform to the QName lexical rules specified in http://www.w3.org/TR/REC-xml-names/#NT-QName and the XML namespace and local naming conventions specified in http://www.w3.org/TR/REC-xml-names/#NT-NCName.

[ISC.0124.9007] Document to XSD error: Document {0} cannot be represented in XML Schema. The document contains multiple *body fields.

Cause: The IS document type or XML Schema element declaration you are using to generate a WSDL document contains more than one field named *body at the same level.

Response: To resolve this error, remove or rename the duplicate *body fields.

[ISC.0124.9008] Document to XSD error: Document {0} cannot be represented in XML Schema. The document contains multiple attributes of the same name at the same level.

Cause: The IS document type or XML Schema element declaration you are using to generate a WSDL document contains attributes at the same level with the same name.

Response: To resolve this error, remove or rename the duplicate attributes.

[ISC.0124.9009] Document to XSD error: Field {0} cannot be represented in XML Schema. Attributes cannot have dimension greater than 0.

Cause: The IS document type or XML Schema element declaration you are using to generate a WSDL document contains array or table type attributes. XML Schema does not support multi-dimensional attributes.

Response: To resolve this error, remove the attribute from the IS document type or redefine its type to String.

Important! Some protocols require the use of a prefix. Before removing the prefix, check the service signature’s input and output requirements as documented for each protocol in this guide.











[ISC.0124.9011] Document to XSD error: Simple type {0} does not exist.

Cause: The IS document type you are using to generate a WSDL document contains a reference to a nonexistent simple type that has been applied to a variable as a content type constraint.


Restore the nonexistent simple type by generating a schema on the server that defines the missing type. To do so, you can either create a schema from an XSD or enable or import a package that contains a schema with the missing type.

Remove the reference to the missing type. First, click the browse button next to the Content type property on the variable’s Properties panel. Then, select No Constraints Specified from the Content Type list on the resulting Properties dialog box.

Messages Received when Creating a Web Service Connector

[ISS.0092.9001] Server Error: {0}

Cause: A server error occurred while Developer was generating the Web service connector.

Response: Click Details on the message dialog box to view the errors.

[ISS.0092.9002] Warning: Document does not contain service element, no ports were generated for any Web Service Connector.

Cause: The WSDL document does not contain a <service> element, and therefore does not contain any <port> elements. (A <service> element is a collection of <port> elements.)

Developer generates the Web service connector, but the Web service connector will not specify any flow MAP steps for setting the port information. In the Web service connector, the BRANCH on '/_port' step contains a child port MAP step for each unique <port> associated with the <operation>. The BRANCH on '/_port' step will not contain child port MAP steps. The Web service connector cannot execute successfully without port information because the port information specifies the network address for invoking the Web Service.

[ISS.0092.9003] Error: SOAP binding does not contain extended element http://schemas.xmlsoap.org/wsdl/soap/binding, binding was not created.

Cause: The <binding> element is missing the <soap:binding> element. If the WSDL document specifies SOAP as a protocol, the <binding> element must contain <soap:binding> as the first child element.

Developer generates the Web service connector, but the Web service connector does not contain a SEQUENCE step that corresponds to this binding. (In the Web service connector,



the BRANCH on '/binding' step contains a child SEQUENCE step for each unique <binding> associated with an <operation>.)

[ISS.0092.9004] Error: SOAP binding does not contain transport value, binding was not created.

Cause: In the WSDL document, the <soap:binding> element contains a transport attribute but no value is specified for it. The transport value indicates which transport of SOAP the binding uses. It is required for a SOAP binding and its value must be http://schemas.xmlsoap.org/soap/http.

Developer generates the Web service connector, but the Web service connector does not contain a SEQUENCE step that corresponds to this binding. In the Web service connector, the BRANCH on '/binding' step contains a child SEQUENCE step for each unique <binding> associated with an <operation>.

[ISS.0092.9005] Error: SOAP binding has an unsupported transport value, binding was not created.

Cause: In the WSDL document, the transport attribute in the <soap:binding> element specifies an unsupported SOAP transport. Developer can generate a binding for a SOAP binding only if the transport value is http://schemas.xmlsoap.org/soap/http.

webMethods Developer generates the Web service connector, but the Web service connector does not contain a SEQUENCE step that corresponds to this binding. In the Web service connector, the BRANCH on '/binding' step contains a child SEQUENCE step for each unique <binding> associated with an <operation>.

[ISS.0092.9006] Error: SOAP binding does not contain a transport attribute, binding was not created.

Cause: In the WSDL document, the <soap:binding> element does not contain a transport attribute. The transport value indicates which transport of SOAP the binding uses. It is required for a SOAP binding. The transport attribute value must be http://schemas.xmlsoap.org/soap/http.


[ISS.0092.9007] Error: SOAP binding has an unrecognized style value, binding was not created.

Cause: In the WSDL document, the <soap:binding> element specifies a value other than rpc or document for the style attribute.




[ISS.0092.9008] Error: HTTP binding does not contain extended element http://schemas.xmlsoap.org/wsdl/http/binding, binding was not created.

Cause: The <binding> element is missing the <http:binding> element. If the WSDL document specifies HTTP as a protocol, the <binding> element must contain <http:binding> as the first child element.


[ISS.0092.9009] Error: HTTP binding does not contain required verb attribute, binding was not created.

Cause: In the WSDL document, the <http:binding> element does not contain the verb attribute. The value of the verb attribute must be GET or POST.


[ISS.0092.9010] Error: HTTP binding has an unsupported verb attribute, binding was not created.

Cause: In the WSDL document, the <http:binding> element specifies a verb attribute value other than GET or POST.

Developer generates the Web service connector, but the Web service connector does not contain a SEQUENCE step that corresponds to this binding. (In the Web service connector, the BRANCH on '/binding' step contains a child SEQUENCE step for each unique <binding> associated with an <operation>.)

[ISS.0092.9011] Error: Mime binding style is unsupported, binding was not created.

Cause: The WSDL document specifies a MIME binding style for the entire <binding>. webMethods Developer only supports the MIME binding style to describe the inputs and outputs of an HTTP binding. webMethods Developer cannot generate a binding when the MIME binding style is specified outside of the HTTP binding context.

Developer generates the Web service connector, but the Web service connector does not contain a SEQUENCE step that corresponds to this binding. (In the Web service connector, the BRANCH on '/binding' step contains a child SEQUENCE step for each unique <binding> associated with an <operation>.)



[ISS.0092.9013] Warning: The operation's binding does not have any ports, no ports were generated for the Web Service Connector.

Cause: Developer cannot find a <port> element that corresponds to a particular <binding> element. A <port> element specifies a network address or endpoint for a binding.

Developer generates the Web service connector, but does not generate any MAP steps for setting the binding and address information. In a Web service connector, the BRANCH on '/_port' step contains a child portName MAP step for each <port> associated with the <operation>. When this warning occurs, the BRANCH on '/_port' step contains no child portName MAP steps.

[ISS.0092.9014] Warning: The operation does not have any valid ports, no ports were generated for the Web Service Connector.

Cause: The WSDL document does not contain any valid <port> elements for an <operation>. The WSDL document might not contain any <port> elements or a <port> element might reference a non-existent <binding> element. (A <binding> element associates a protocol with an <operation>.)

Developer generates the Web service connector, but does not generate any portName MAP steps for setting the binding and address information. In a Web service connector, the BRANCH on '/_port' step contains a child portName MAP step for each <port> associated with the <operation>. When this warning occurs, the BRANCH on '/_port' step contains no child portName MAP steps.

[ISS.0092.9015] Warning: Port does not have a valid binding type, port was not generated.

Cause: The WSDL document contains a <port> element that does not contain the binding attribute.

Developer generates the Web service connector, but does not generate a MAP step for this port. In a Web service connector, the BRANCH on '/_port' step contains a child portName MAP step for each <port> associated with the <operation>. The portName MAP step sets the binding and address information for a port.

[ISS.0092.9016] Warning: Port does not have a location value, port was not generated.

Cause: Within the <port> element, the <address> element does not specify a value for the location attribute. The location attribute specifies the network address or endpoint for the service.

Developer generates a Web service connector, but without the network address, webMethods Developer cannot generate a MAP step for this port. In a Web service connector, the BRANCH on '/_port' step contains a child portName MAP step for each <port> associated with the <operation>. The portName MAP step sets the binding and address information for a port.



[ISS.0092.9017] Warning: Port does not have required address element, port was not generated.

Cause: The selected WSDL document does not contain an <address> element within the specified <port> element. The <address> element carries an attribute that specifies the location or network address for of the Web service.

Developer generates a Web service connector, but does not generate a MAP step for this port. The portName MAP step sets the binding and address information for a port. Without the <address> element, Developer cannot set the address information and therefore cannot generate a MAP step.

[ISS.0092.9018] Warning: Port does not have required location attribute, port was not generated.

Cause: Within the <port> element, the <address> element does not carry the location attribute. The location attribute specifies the network address for the service.

Developer generates a Web service connector, but does not generate a MAP step for this port. The portName MAP step sets the binding and address information for a port. Without the location attribute, Developer cannot set the address information, and therefore cannot generate a MAP step.

[ISS.0092.9019] Warning: Port does not have a location value, port was not generated.

Cause: Within the <port> element, the <address> element does not specify a value for the location attribute. The location attribute specifies the network address or endpoint for the service.

Developer generates a Web service connector, but without the network address, Developer cannot generate a MAP step for this port. The portName MAP step set the binding and address information for a port. In a Web service connector, the BRANCH on '/_port' step contains a child portName MAP step for each <port> associated with the <operation>.

[ISS.0092.9020] Error: Operation is not referenced by any binding, Web Service Connector was not created.

Cause: The WSDL document does not specify a <binding> element for the <operation>. Each <operation> within a <portType> element needs to correspond to an <operation> element within a <binding> element. Without a binding, the WSDL document does not provide any information about how to invoke the Web service.

Developer does not generate a Web service connector for the <operation>.

[ISS.0092.9021] Error: Input and Output messages missing, invalid operation, Web Service Connector was not created.

Cause: In the WSDL document, the <operation> element within a <portType> element does not declare an input message or an output message. For Developer to generate a Web



service connector for the <operation>, the <operation> element must contain at least one <input> element and at least one <output> element.

Developer does not generate a Web service connector for the <operation>.

[ISS.0092.9022] Error: Input message missing, Notification operations not supported. Web Service Connector was not created.

Cause: In the WSDL document, the <operation> element does not declare an input message, but it does declare an output message. In other words, the <operation> element does not contain a child <input> element, but does contain a child <output> element. This structure corresponds to the grammar for a notification operation. Developer does not generate Web service connectors for notification operations.

[ISS.0092.9023] Error: Output message precedes Input message, Solicit Response operations not supported. Web Service Connector was not created.

Cause: In the WSDL document, the <operation> element declares an <output> element (output message) before the <input> element (input message). This describes a solicit-response operation. Developer does not generate Web service connectors for solicit-response operations.

[ISS.0092.9024] Error: HTTP binding has mime multipart Input. Multipart Input is not supported. Binding was not generated.

Cause: The <binding> element specifies a multi-part MIME binding for the operation. webMethods Developer does not support this type of binding.

Developer generates the Web service connector, but the Web service connector does not contain a SEQUENCE step that corresponds to this binding. In the Web service connector, the BRANCH on '/binding' step contains a child SEQUENCE step for each unique binding associated with an operation.

[ISS.0092.9025] Error: HTTP Binding input is of type http:urlReplacement. http:urlReplacement is not supported. Binding was not generated.

Cause: The <binding> element specifies <http:urlReplacement> as the binding for the operation input. Developer does not support this type of binding for the input message.

Developer generates the Web service connector, but the Web service connector does not contain a SEQUENCE step that corresponds to this binding. In the Web service connector, the BRANCH on '/binding' step contains a child SEQUENCE step for each unique binding associated with an operation.

[ISS.0092.9026] Error: HTTP Binding input is of an unknown type. Binding was not generated.

Cause: The input binding specifies an unknown binding type. When the protocol is HTTP POST, the <mime:content> element for the input binding must specify text/xml,



text/plain, or application/x-www-form-urlencoded for the type attribute. (The <mime:mimeXml> element is also valid for the input binding.) When the protocol is HTTP GET, the input binding must contain the child element <http:urlEncoded>.

Developer generates the Web service connector, but the Web service connector does not contain a SEQUENCE step that corresponds to this binding. (In the Web service connector, the BRANCH on '/binding' step contains a child SEQUENCE step for each unique binding associated with an operation.)

[ISS.0092.9027] Error: HTTP Binding output mime parts are missing. Binding was not generated completely.

Cause: The <binding> element specifies MIME binding for the output message, but the output binding does not specify a message part for the <mime:content> element or the output binding is missing <mime:part> elements.

Developer generates the Web service connector and generates a SEQUENCE step that corresponds to this binding. (In the Web service connector, the BRANCH on '/binding' step contains a child SEQUENCE step for each unique binding associated with an operation.) However, Developer does not generate a complete binding because the output binding in the WSDL document does not provide the part name information that Developer needs to link the service results to variables in the pipeline. Specifically, the Web service connector does not contain the BRANCH on '/numParts' step for this binding.

[ISS.0092.9028] Error: HTTP Binding output mime part is missing its type. Binding was not generated completely.

Cause: The <binding> element specifies MIME binding for the output message, but the <mime:content> element for the output binding does not specify a value for the type attribute. The type attribute specifies the MIME type.

Developer generates the Web service connector and generates a SEQUENCE step that corresponds to this binding. (In the Web service connector, the BRANCH on '/binding' step contains a child SEQUENCE step for each unique binding associated with an operation.) However, Developer does not generate a complete binding because the output binding in the WSDL document does not provide the part name information that Developer needs to link the service results to variables in the pipeline. Specifically, in the Web service connector, the BRANCH on '/loopCount' step does not have a child SEQUENCE step for linking the output message part to the pipeline.

[ISS.0092.9029] Warning: Generated Document Type, {IS document type name}, already exists in namespace.

The IS document type that Developer generated for the input or output message already exists in the server namespace. Developer will not generate a duplicate IS document type.



[ISS.0092.9030] Error: Input does not have a valid message reference, Web Service Connector was not created.

Cause: Within the <operation> element, the message attribute for the <input> element does not reference a <message> element within the WSDL. Developer cannot find the message specified by the message attribute, or the message attribute does not have a value. Developer does not generate a Web service connector for the <operation>.

[ISS.0092.9031] Error: Output does not have a valid message reference, Web Service Connector was not created.

Cause: Within the <operation> element, the message attribute for the <output> element does not reference a <message> element within the WSDL. Developer cannot find the message specified by the message attribute or the message attribute does not have a value. Developer does not generate a Web service connector for the <operation>.

[ISS.0092.9032] Error: Invalid schema definition for Input signature. Web Service Connector was not created.

Cause: The XML Schema definition that contains element declarations or type definitions for the <part> elements in the input message is invalid. Alternatively, the XML Schema definition does not contain the element declarations or type definitions referenced by the <part> elements. Developer does not generate a Web service connector for the <operation>.

[ISS.0092.9033] Error: Invalid schema definition for Output signature. Web Service Connector was not created.

Cause: The XML Schema definition that contains element declarations or type definitions for the <part> elements in the output message is invalid. Alternatively, the XML Schema definition does not contain the element declarations or type definitions referenced by the <part> elements. Developer does not generate a Web service connector for the <operation>.

Note: The message attribute value must be a QName.

Note: The message attribute value must be a QName.

Note: This error message is usually accompanied by specific IS schema generation errors. For more information about errors that occur when generating an IS schema from an XML Schema, see the webMethods Developer User’s Guide.



[ISS.0092.9034] Warning: Found port with an invalid binding reference, the port was not generated.

Cause: In the WSDL document, a <port> element contains a binding attribute that references a <binding> that does not exist within the WSDL document. Developer cannot find the <binding> element specified by the binding attribute.

Developer generates the Web service connector, but does not generate a MAP step for this port. The portName MAP steps set the binding and address information for a port. In a Web service connector, the BRANCH on '/_port' step contains a child portName MAP step for each <port> associated with the <operation>.

[ISS.0092.9035] Warning: Found service with no ports.

Cause: In the WSDL document, a <service> element contains no <port> elements. Developer generates a Web service connector, but if the WSDL document does not contain any <service> elements that provide port and address information for an operation, the Web service connector will be incomplete.

[ISS.0092.9036] Error: Could not process document. Found binding with an invalid PortType reference, no Web Service Connectors were created.

Cause: In a <binding> element, the type attribute specifies a <portType> that does not exist in the WSDL document. Developer does not generate a Web service connector.

[ISS.0092.9037] Error: HTTP Binding input type could not be found. Binding was not generated.

Cause: Developer cannot determine the input MIME type for the HTTP binding.


Note: This error message is usually accompanied by specific IS schema generation errors. For more information about errors that occur when generating an IS schema from an XML Schema, see the webMethods Developer User’s Guide.

Note: The binding attribute value must be a QName.

Note: The type attribute value must be a QName.



[ISS.0092.9038] Error: Unknown binding style was found, binding was not created.

Cause: The <binding> element specifies a protocol other than SOAP, HTTP, or MIME.


[ISS.0092.9040] Error: PortType name is zero length, Web Service Connector was not created.

Cause: In the WSDL document, the <portType> element carries the name attribute, but the name attribute does not have a value. Developer does not generate a Web service connector.

[ISS.0092.9041] Error: Operation name is zero length, Web Service Connector was not created.

Cause: In the WSDL document, the <operation> element carries the name attribute, but the name attribute does not have a value. Developer does not generate a Web service connector.

[ISS.0092.9043] Error: Schema Error: error text

Cause: The XML Schema definition that defines the types and elements for the input and/or output message parts is invalid. The schema errors are listed. For information about errors that occur when Integration Server processes an XML Schema definition, see the webMethods Developer User’s Guide.

[ISS.0092.9102] fileName: Not a valid web service description document.

Cause: The file you selected to generate the Web service connector is not a .wsdl or .wsd file. You can only generate Web service connectors from files with a .wsdl or .wsd file name extension.

[ITD.0012.0011] Web Service Connector created successfully but with warnings.

Cause: Developer generated the Web service connector successfully; however, warnings occurred.

Response: Click Details on the message dialog box to view the warnings.

[ITD.0012.0012] Error occurred while creating Web Service Connector.

Cause: Developer did not generate a Web service connector. Click Details on the message dialog box to view the errors.


Index

Index

Bbinding element, in WSDL document 78binding to a Web service 75

Cconcrete services 62, 75connecting to Servicenet 59conventions used in this document 5creating

Web service connectors 16, 75WSDL documents

describing service signature 34HTTP GET protocol 44HTTP POST protocol 44process overview 10SOAP Message protocol 32SOAP RPC protocol 22using Servicenet 65

Ddefault SOAP processor, using as directive for WSDL document

22, 32definitions element, in WSDL document 78docType folder, for Web service connector 18documentation

additional 5conventions used 5feedback 5

Eelements, in a WSDL document 78errors

Web service connector generation 89WSDL document generation 85

Ffiltering

removing filters from Servicenet 74Web services in Servicenet 72

GGenerate WSDL command 22generating WSDL documents

describing service signature 34HTTP GET protocol 44HTTP POST protocol 44process overview 10SOAP Message protocol 32SOAP RPC protocol 22

HHTTP GET protocol

input and output signature requirements 45service requirements for generating WSDL documents 44specifying for WSDL documents 44text/xml restrictions 45URL encoded restrictions 44, 48

HTTP POST protocolinput and output signature requirements 45service requirements for generating WSDL documents 44specifying for WSDL documents 44text/xml restrictions 45URL encoded restrictions 44, 48

Iicons, representing Web services 62input signature

describing (SOAP only) 68describing for WSDL documents 23, 34, 45describing with IS document type 68describing with XML schema 69HTTP GET requirements 45HTTP POST requirements 45SOAP Message requirements 34SOAP RPC requirements 23

IS document type, describing input signature 68


I n d e x

Llocal name, definition of 12

Mmanaged services 75message element, in WSDL document 78messages related to Web services 84

Nnamespace

definition of 12explicit name 12implicit name 12in WSDL documents 79universal name 12

Oopening a Servicenet session 59operation element, in WSDL document 78optional variables for validation 26, 39, 51output signature

describing (SOAP only) 69describing for WSDL documents 23, 34, 45HTTP GET requirements 45HTTP POST requirements 45SOAP Message requirements 34SOAP RPC requirements 23

Ppart element, in WSDL document 78port element, in WSDL document 79portType element, in WSDL document 78prefix 11program code conventions in this document 5

Rregistering a Web service in Servicenet 65

making changes to a registered Web service 71removing a Web service from Servicenet 72

Sservice element, in WSDL document 79Servicenet

binding to a service 75clearing a filter 74closing a session 60connecting to 59creating a filter 72creating a WSDL document 65definition of 58disconnecting from 60displaying Web services 61filtering 72finding Web services in 72generating a Web service connector 75hiding services 72opening a session 59refreshing 60registering a Web service 65removing a service 72requirements 59specifying a protocol for Web service 67toolbar 62updating a service 71viewing in Developer 61Web service icons 62Web service properties 63

Servicenet tabicons 62shortcuts 62

servicesgenerating WSDL documents for 10HTTP GET requirements 44HTTP POST requirements 44signature requirements 10SOAP Message requirements 32SOAP RPC requirements 22

shortcuts on the Servicenet tab 62SOA (Services Oriented Architecture)

managing Web services in 58


Index

SOAP Message protocoldescribing input signature 68describing output signature 69input and output signature requirements 34service requirements for default processor 32specifying for WSDL documents 32specifying for WSDL documents, using Servicenet 67

SOAP RPC protocolinput and output signature requirements 23service requirements for default processor 22specifying for WSDL documents 22specifying for WSDL documents, using Servicenet 67

Ttarget namespace, specifying for a Web service in Servicenet 70text/xml restrictions, for WSDL documents 45troubleshooting information 5types element, in WSDL document 78typographical conventions in this document 5

Uuniversal name 12URL encoded restrictions, for WSDL documents 44, 48

Vvariables, optional existence for validation 26, 39, 51viewing

Servicenet in Developer 61Web service properties 63

virtual services 62managing Web services through 75

Wwarnings

Web service connector generation 89WSDL document generation 85

Web service connectorcreating 16, 75definition of 8example 18generation errors and warnings 84supporting elements 18

Web servicesand WSDL documents 9changing after they are registered 71creating a connector 75definition of 8describing input signature

SOAP only 68using IS document type 68using XML schema 69

description 9displaying in Servicenet tab 61filtering in Servicenet 72finding in Servicenet 72hiding in Servicenet 72icons 62managing in a network 58managing through a virtual service 75messages related to 84registering in Servicenet 65removing from Servicenet 72removing Servicenet filter 74reporting and security functions 75SOA (Services Oriented Architecture) 58specifying communications protocol with Servicenet 67specifying output signature, SOAP only 69specifying target namespace in Servicenet 70types 75

concrete services 62, 75managed services 75virtual services 62, 75

using an intermediary to monitor 75using Servicenet to monitor 75viewing properties in Servicenet 63

Web Services Description Language. See WSDLwebMethods Fabric. See ServicenetWSDL documents 34

creating using Servicenet 65definition of 9elements 78example of 81generating

describing signature with SOAP MSG protocol 34HTTP GET protocol 44


I n d e x

HTTP POST protocol 44process overview 10service requirements 44SOAP Message protocol 32SOAP RPC protocol 22Web service connectors from 16

generation errors and warnings 84input signature

HTTP GET requirements 45HTTP POST requirements 45identically named variables 35, 48, 50SOAP Message requirements 34SOAP RPC requirements 23specifying 34

namespaces 79output signature

HTTP GET requirements 45HTTP POST requirements 45identically named variables 35, 48, 50SOAP Message requirements 34SOAP RPC requirements 23specifying 34

using to create Web service connectors 16, 29, 42using with default SOAP processor 32Web services 9

WSDL generator, definition of 10

XXML namespace

definition of 11prefix 11

XML schema, using to describe input signature 69
