Hi all

I have a few functions (web services) in webMethods that have the same document type as input and output.

My problem is that when I generate the wsdl files, the input and output gets a unique namespace which ends with the function name.

This makes it impossible to write reusable code. i.e. to have only 1 declaration of the input and the output classes.

Example:

I have 2 services: ServiceA and ServiceB
Both services takes a docType as input and output:
docTypeIn & docTypeOut

When I look in the generated wsdl-files the namespaces looks like the following:

Namespace for FunctionA:
docTypeIn: [SIZE=2][COLOR=#800000][URL=“http://localhost/micke/dev/test/FunctionA”]http://localhost/micke/dev/test/FunctionA[/URL][/color][/size]
[COLOR=#800000] docTypeOut: [SIZE=2][COLOR=#800000][URL=“http://localhost/micke/dev/test/FunctionA”]http://localhost/micke/dev/test/FunctionA[/URL][/color][/size][/COLOR]

[COLOR=#800000][SIZE=2]Namespace for FunctionB:
docTypeIn: [SIZE=2][COLOR=#800000][URL=“http://localhost/micke/dev/test/FunctionB”]http://localhost/micke/dev/test/FunctionB[/URL][/color][/size]
[COLOR=#800000] docTypeOut: [SIZE=2][COLOR=#800000][URL=“http://localhost/micke/dev/test/FunctionB”]http://localhost/micke/dev/test/FunctionB[/URL][/color][/size][/COLOR]

When it comes to the input parameter, it´s possible to use any of the namespaces (manually editing the wsdl) regardless of which function is called, but this can´t be done with the output parameter.

If I try to use the same namespace (for output) for both functions, I get a SOAP exception.

Does anyone know how to solve this issue?

Any help is appreciated, I´ve been stuck on this for a while now.

Regards
Mikael
[/SIZE][/COLOR]

Don’t use SOAP-RPC.
Don’t use the WSDL generator.
Manually create a WSDL for a Service (capital ‘S’) to describe a group of related operations.
Assign a namespace to each Service.

Thanks for your reply, not the info i wanted though

I have seen multiple posts where one is advice not to use SOAP-RPC, but why?

Also (from the 1st post): Is it possible to supply a namespace for an input or output that points to the actual space where the (in this case) document type is saved. e.g. folder1.subfolder.docs?

As it is now, the namespace for the input/output points to the actual function that is invoked, which seems a bit odd.
e.g. If 10 services uses the same docType as an input parameter, one would need 10 class deklarations in .Net with different namespaces
There must be a way being able to have 1 single class declaration describing the input and use that for the 10 services… or?

As u can see, I´m no expert when it comes to wsdl and namespaces, but I´´m learning

Regards
Mikael

There are plenty of examples on this forum how to do Web Services. Mark C. has a very good example on how to construct the doc/literal web service. If you look at that example you will see how the documents are constructed along with their associated document wrappers for the doc/literal web service. The documents can be reused if you follow the example.

Doc/literal is the standard for Web Services. RPC is not supported for Basic Profile compliance which is fast becoming the industry wide standard. Beyond the standards support, it just plain ugly and difficult to work with once you get beyond a few parameters. Can you imagine trying to submit a 40 parameter PO via an RPC call when you only needed 5 of the 40 parameters? :eek: With doc/literal most tools will generate the associated beans for the messages so you are then using getter/setter methods on the beans instead of one method with 50 parameters of which 45 are null. Much easier to work with and to handle change/variation on the messages.

Off the topic…

I agree, SOAP-RPC == not much inter-op.

Mark, what do you reckon are the benefits of combining multiple operations in one end point against multiple end points for operations?
I have noticed both kinds of services, but have always wondered what the differences/trade offs may be.

Please advice.

Cheers
G

The one-WSDL-per-operation approach is usually followed when a development tool is used to expose a method or function as a web service. While this may allow that functionality to be invoked from beyond the applications original bounds, it often results in very fine-grained “services” which are more focused on the technology than the business.

If you think of the core “business services” that your organization provides, decompose those in to logical groups and then identify service candidates from those groups, you can create WSDL’s which describe more course-grained business services.

Those course-grained business services will look much less like a technology-driven API and more like something that the business can relate to (important when funding time rolls around) and that can be re-arranged or recombined in new ways.

Performance-wise there’s probably not much difference in the two approaches, except that fine-grained services could be “chatty” and may increase the overhead involved with WS-security on more, but smaller requests.

Mark