Hosting WSDL in webMethods

, ,
1

Hi all,

Can I use WSDL file created in another application (It will make calls to some some jar files) and host it in webMethoids?? and call WSDL file using other SOAP Client??

Thanks
Kevin

2

Kevin,

I’m not sure I understand what you are trying to do. Do you want Integration Server to act as a soap client, consuming services described in this WSDL or do you want IS to simply act as a host to make the WSDL accessible to some other soap client? Either can be done, but I’m not sure why you’d want to do the latter.

Also, the WSDL file does not call anything. It is just an XML file that describes the inputs and outputs of the service and identifies the URL of the service provider (soap server).

Mark

3

Mark,

Thanks for your reply…I just want IS to simply act as a host to make the WSDL accessible to some other soap client. The reason behind this is I can write a java code and convert that to WSDL using Axis JAVA2WSDL tool and want webMethods to host this WSDL(The underlying technology to this WSDL is java). I can create a SOAP client (using Axis) to invoke this WSDL hosted on webMethods…I am just thinking of various possiblities…

Thanks
Kevin

4

Kevin,

Seems like a bit of overkill to simply use IS to host a WSDL file, but you can certainly do this by copying the WSDL into the \pub folder of an IS package that you create and setting permissions appropriately in the .access file. See the Administrator’s guide for instructions on how to work with .access files.

Mark

5

I have a v6.1 flow service that’s invoked as a web service. I need to add this web service to our corporate UDDI registry. Our corporate UDDI requires access to the WSDL via remote URL, not a local file. I see how to generate a WSDL file in a file system using webMethods Developer. However, what is the webMethods built-in/recommended method to host a WSDL file on the Integration Server and make it accessibly remotely via a URL (say HTTP)?

Jay

6

IS Feature Pack 1 or 2 added support for browsing Fabric (now ServiceNet) from Developer. As part of that change, a URL was exposed that dynamically generates a WSDL from a Flow service. I don’t have it handy just now, but I believe the dynamic WSDL URL does not require Fabric/ServiceNet to work, just the Feature Pack. Someone please check me on this.

If you want to generate the WSDL from developer and copy it to your package’s pub folder, you can use the same URL that works to expose a DSP page http://hostname:port/packagename/filename

Mark

7

The dynamic WSDL URL should look something like this:


[U][/u]http://[I]hostname[/i]:5555/invoke/wm.server.wsdl/getWSDL?svcName=folder.folder:service&targetNamespace=urn:somenamespace&type=soap-rpc&transport=http&hosts=http://localhost:5555/soap/rpc
[/quote]

Where:

  • svcName = fully qualified name of the service to be invoked
  • targetNamespace = target namespace of the service to be invoked (set on the Universal Names property)
  • type = Either soap-rpc or soap-msg
  • transport = Protocol to be used (http)
  • hosts = URL of the IS soap processor (http://host:port/soap/rpc or http://host:port/soap/default.

Mark

8

Hi Mark, from your very last post have found the dynamic WSDL call works for soap-rpc web services but when changing the url to soap-msg for doc lit etc have found the resultant wsdl does not contain the (xml) type info ? In the wsdl just see
…
<wsdl:types />
…

This should work for doc lit right ?

9

I improved the formatting that post.

Yes, this should work for doc-lit. However, your service would need to have one document type for input and one document type for output.

I haven’t tried this in IS 6.5.

Mark

10

Oh, i thought doc lit services as implemented in OOTB webMethods required the service interface to be SOAPRequest,SOAPResponse (IN), SOAPResponse (OUT) etc. (from your previous extensive email on the subject etc etc)?
Do i need to change the service interface to explicitly reference the interface documents ? then the doc lit service will not work in webMethods 6.5 ? lol now i am confused…

11

Gavin,

Exposing IS services using doc/lit does require processing the a message directly using the pub.soap.utils:* services. However, you can create a custom soap processor to do most or all of the heavy lifting so that your IS services are mostly unaware that they are being invoked as doc/lit web services.

I say mostly because those services do need to accept document type references as input and return a document type reference as output and the document types that are referenced should have their XML namespace property populated.

Mark

12

Yep, in fact we have a Custom Processor implementation that enables the use of Document Literal while still enabling “useful” service interfaces (showing document type) rather than the generic SOAPRequest/ResponseData interface in use with the webMethods OOTB Doc Lit Impl. See posts by Craig Harper on how to setup the Custom Processor (based on your good work Mark :}

13

Hello,
I created a WSDL for a flow service and its running on my side.
But when i gave it to the client and he is trying to run it. Its not running.
What wud be the possible reasons ?
Plz suggest me.
Thanks

14

Not enough information to answer your questions. The current incarnation of the WSDL Generator leaves much to be desired. If you don’t know what you are doing with WSDL (not many people do) its very easy to generate a non-useful WSDL.

Feel free to post it here as an attachment and I’ll take a quick look.

Also, be sure that you have read the posts here on web services best practices and evils of soap-rpc.

Mark

15

Stepheny,

I was caught most sometimes with the Access Denied exception. Do you want IS to authenticate the user. If not have you set the service execute ACL to Anonymous. If you want to set the IS to authenticate then you have to set the user credentials at the client side.

If all the above are addressed then the question would be what type of XML messaging are you using XML-RPC or SOAP-MSG.

Ram Challuri