Hi,

I’m new to webMethods but worked a lot with WS* technologies.

I wrote a small Java Service in the Developer. This Java Service has an input called a and an output called b.

The Service just takes the input a and concatenates it with another variable and outputs it, quite simple

Then I generated a WSDL file based on that Java Service. Quite nice because it has little overhead, not like other WSDL Generation tools. I have a operation called Test and this operation has an input TestInput and an output TestOutput. Im using SOAP RPC.

TestInput is described as a message with a single part called a and respectively TestOutput encapsulates the b part.

I think that seems to be correct as webMethods made the biggest part for me. Now the strange behavior:

When I test the service inside the Developer, it pops up the window for input parameters: nice I can type my parameter a and the port and it responds with b (concatenated with a). So the Java Service is being called and the Web Service Connector works, passing variables.

Then I wrote a Java Client to send a SOAP message to this service. It responds to my request, but the variable that should be concatenated is lost somewhere or not bound to the service. With other words, the SOAP body in the request is lost. The Web Service Connector was generated automatically, what do I need to change so the request can be read correctly?

It also works when invoking via Browser as GET:
http://localhost:xxxx/invoke/test.testPortType/Test?a=blabla

It concatenates the blabla value of the variable a to the output.

The problem is when I pass the SOAP Request via the Java Client. Do I need to parse the variables using another step when calling it by a SOAP RPC passed via an external application?

Thanks and Bye,
Thomas

Can you post (as attachments) your WSDL and the soap request that your are sending.

Also, be sure to read all of the posts here on why using soap-rpc is not recomended when interoperabilty is a goal.

Mark

Thanks for the answer and I will post the WSDL as soon as I can. I just have a problem right now to get the files. Im on another computer.

But I can make another question: Doesnt webMethods support SOAP RPC literal? This recommendation eliminates many drawbacks from the SOAP RPC encoded and still has the quality of making the rpc call.

I read a lot of material about that and it sounds for me a good way to go and interoperability is possible by extracting the rpc call if needed and enriching the WSDL if somebody goes for that. One paper about this:

Best Practices in Web Service Style, Data Binding and Validation for use in Data-Centric Scientific Applications
[URL=“http://epubs.cclrc.ac.uk/bitstream/1133/621.pdf”]http://epubs.cclrc.ac.uk/bitstream/1133/621.pdf[/URL]

Apropos, BPM Engines normally support that, like the open source ActiveBPEL and so turning to be WS-I compliant and keeping WSDL world simple.

I will publish the WSDL and SOAP request later on. Thanks

Thomas,

The article you linked is very useful. I have attached it to this post for others to reference.

I don’t believe IS supports rpc/literal “out of the box” although I’m sure you could create a custom soap-rpc soap processor to do so. However, I find the limitations on message validation to be a major obstacle and would not personally use rpc-literal even if it were supported by IS in some future version.

Mark
Best Practices - Web Services Style.pdf (123 KB)

Correct me if Im wrong, but in an architectural approach it would be pretty clean to build a validation layer before presenting it as SOAP RPC literal. So the validation would be a matter of having a nice architecture to implement it before sending and after receiving. Something like a real network layer application/presentation layer.

I know it is more a matter of ideology then quality, but I worked a lot with RPC literal during my thesis, so I like it

Thanks for the help. Nice forum and I will get my source file up in the forum tomorrow.

Bye

Hi,

here are the sample files.

I tested using a Flow Service. Again build the Flow Service with input and output: request and response as strings.

In the flow I only concatenate the request with a Hello and send it as “Hello x”, where x defines the content of the request.

Then I generated the WSDL (TestFlow.wsdl) and created a Web Service Connector based on it. Turned all permissions to anonymous so every application can talk to the service without problems.

The output returns a SOAP response using the output template and setting the soapResponseData to the only output. So no other data makes any trouble.

I tested the Web Service with the Developer (clicking on Play). Typed something in the request and Voila: the output is “Hello aa” as in the response.xml attached.

The same thing occurs successfully if I type this on my browser:

http://localhost:yyyy/invoke/test/test.testPortType/TestFlow?request=aa

The soap response is the same as in response.xml. This is a nice for fast debugging.

Now my problem is: I wrote two java clients, one using axis2 and one using a HTTP connection to pass the request.xml. Because I first thought it could be axis.

Fact is, it returns the soap response but any content of the request parameter isnt used in the service. It gets lost.

I used the pub.flow:tracePipeline to test my WS and when I use the Developer or the Browser to call the service it returns the request with correct data types. But when I call it using the java client it returns following:
0 node {com.wm.lang.xml.Document} = ‘DOCUMENT System ID: null Public ID: null’

Any hint?

Thanks
request.xml (568 Bytes)
response.xml (596 Bytes)
TestFlow.wsdl (2.22 KB)

Thomas,

It looks like the request.xml you attached is invalid due to missing a /request tag. I’m sure that’s just a typo.

Also, to what URL are you posting your request? You should be using something like http://hostname:port/soap/rpc.

Your post discusses use of a web services connector. An IS WSC is only used to allow IS consume a web service and not used in any way to provide one. The fact that the WSC returns a soap response is not relevant with regard to providing a service.

IS exposes all Flow and java service as soap-rpc (encoded) web services automatically, you don’t need to do anything else except stay away from arrays and custom objects in your service’s inputs and outputs. (Some arrays may work, but are best avoided for any hope of interop).

HTH,

Mark

Thanks a lot. I didnt get that point, but now its clear and my RPC call is working.

For simple services this rpc encoded handler is quite good, but for interoperability with WS-I compliance I will have to write my own rpc or a document literal processor.

Nice discussion forum. Learning a lot about webMethods.