Basically, what I am trying to achive is exposing the C# webservices to external clients in as transparent manner as possible.
What I tried in webMethods developer was this:
Created a consumer webservice connector on the C# WSDL URL
Created a provider webservice connector using the WSDL URL from the connector created in step 1.
Step 2 seems to fail partly because it can’t register various universal names but the web service functions seem to be created as flows but they are all empty and do nothing.
Is there a better preferred way to expose webservices like this through webMethods?
Skip step 2 since webMethods IS is acting as the consumer of you .Net web service, you don’t need it. Invoke the connector the you created in Step 1 and you should be good to go.
Is the wM IS-hosted web service going to add some capability over what the original web service provides? If not, what is the benefit of exposing the same web service at another host? Does it matter that the implementation of the web service uses C#?
sorry didn’t read the top part correctly, you want your external clients to invoke basically a webMethods IS service acting as proxy to the real service in .Net, correct?
You are still going to have to write the proxy service, the way you are trying to generate the provider service is just going to give you a blank stub, you will have to add the call to the real service. So in Step two you create your proxy shell, you will need to invoke the connector you created in step 1.
Just as an aside, are you adding any additional functionality to the call within webMethods IS or is simply a pass through?
No, not really, the WM IS hosted webservice doesn’t add any logic at all. It only exposes it. The reason we want to do this is more of an architectural one. That is, the WM IS server is supposed to be on the DMZ network and provide all acceess into and out of the system we’re desigining.
So, the C# webservice layer is more of an internal system component behind firewalls etc etc…
It’s actually not a bad pattern, I was just curious. I use that pattern more often than not in fact. IS adds almost no overhead to the call and can provide another layer of abstraction which can provide additional benefits.
For your current situation you will just need to add the actual implementation on your stub provider service that you created from the WSDL.
Hi,
So is this a known problem in WM? That is, creating a provider on a consumer connector WSDL URL results in errors and the provider stubs being empty?
But there is a new angle to my problem as well!
The C# webservices are all session based. (using the EnableSession property)
When I do what you suggested, that is call the consumer stubs in the provider routines the session ID (from the HTTP cookie header?) is not passed on. That is, external client(which i wrote in c#) calls the WM provider service, which in turn calls the consumer stub. Session ID doesn’t go down to consumer stub and therefore not to the internal C# webservice.
Do you know what might cause this or if this is normal behavior?
Let me know if I am not explaining this problem in enough detail…
Not really an issue. A WSDL file is just an interface definition not an implementation. That’s up to you, just like the one you wrote in .Net. You have to write one in webMethods IS. It’s working like it is suppose to.
You are session issue is interesting, I’m not sure its going to automatically pass session information on since it’s really not the same session. You may to implement some a custom handler to extract that session id and pass it on to the downstream services. Haven’t tried that before myself, anyone else?
it’s auto generated for a provider if you selected an existing service to generate it from, which can’t be an existing consumer wsd. Is that what you are trying to do? You are not going to be able to webMethods IS auto generated a functioning provider service for you.
