How to invoke Net web service asynchronously

Kenny1 · February 25, 2005, 2:00pm

Hi,

I want to invoke .Net web service asynchronously using wM Developer 6.1.If you are experienced in how to invoke .Net web service asynchronously ,please leave your advice.

Thanks!

mwr0707 · February 25, 2005, 7:49pm

I don’t see how you can do this directly from the Integration Server. You could call a local .Net Web Service that acts as a proxy and calls the remote Web Service asynchronously for you.

Kenny1 · February 26, 2005, 11:26am

Hi,Mark
"You could call a local .Net Web Service that acts as a proxy and calls the remote Web Service asynchronously for you. "
Did you say it had been asynchronouse if I called the remote Web Service in webMethods platform?

I have read the documents about web service developing provided by webMethods.But it seems like these documents do not mention how to invoke a web service asynchronously or synchronously.

Thanks!

mwr0707 · February 27, 2005, 4:24am

As you said, it does not appear that webMethods supports asynchronous calls.

You could have webMethods call a web service on a local IIS synchronously. This web service would call the remote service asynchronously, and return immediately to webMethods, while waiting for a response from the remote IIS.

Kenny1 · February 28, 2005, 8:38am

Hi,Mark
If I call a web service remotely from webMethods IS,that web service is asynchronously called.Is it true?

Another question.Web services need web server,for example,IIS,to process the HTTP request or other request.Is there any other webMethods product can play a role like web server(IIS) and house web services?In other words,we can deploy web service using this product without a web server.

I know webMethods has Glue and Fabric,but I don’t know the detail of them.

Thanks!

mwr0707 · February 28, 2005, 8:54pm

If by “calling remotely” you mean calling from another .NET service NOT webMethods, then yes, if you configure the .NET proxy to do an Async call as described in the .NET docs.

I would look to Glue for easy (by comparison to J2EE) deployment of “Application Server” i.e., heavy-duty business logic type Web Services. This makes a lot of sense for shops standardized on Java. I think of Glue as bringing .NET-like simplicity of Web Service deployment to Java.

I would look to the Integration Server for B2B or Enterprise Application Integration Web Services because of the wealth of built-in functionality, the easy, powerful and reliable publish-and-subscribe facility (Broker), and developer productivity offered by Flow services.

Servicenet (formerly webMethods Fabric) provides the means to link Web Services in what is generally generically called an “Enterprise Service Bus”.

webMethods now seems to be using the term Fabric to refer to the entire product Suite.

Bottom line: If you are trying to decide whether to use Integration Server or Glue to host a Web Service:

If it’s an integration pattern, consider the Integration Server.
If it’s a business logic pattern that requires Java, consider Glue.

Kenny1 · March 1, 2005, 3:20pm

Hi,Mark
" Servicenet (formerly webMethods Fabric) provides the means to link Web Services in what is generally generically called an “Enterprise Service Bus”. "

Do Servicenet just “link” the web services?Do Servicenet have ability to house the web service if I want to deploy web services we just use Servicenet without setuping a web server like IIS?

Tanks!

mwr0707 · March 1, 2005, 5:17pm

I have not used it. But from the webMethods materials, it does not appear to house the actual Web Services, rather it acts as a “broker” for Web Services hosted elsewhere.

Using IIS as a Web Service container is very easy. Are you running into any problems with it?

Kenny1 · March 2, 2005, 8:24am

Hi,Mark
Thanks very much!I learned much from you!

wMusers.Com1 · March 2, 2005, 10:08am

See both parts of this article for info on what Fabric provides over UDDI registries as an “intelligent intermediary”.

Mark

mwr0707 · March 2, 2005, 2:28pm

Hi Mark,

Do you think Servicenet will be adding publish-and-subscribe (or Content-based Routing) capabilities out-of-the-box to compete with other ESB products like KnowNow, or SonicMQ?

In this kind of environment, how would you position publish-and-subscribe through the ESB versus publish-and-subscribe through the Integration Broker? The vendors seem to be tap-dancing around this question at this point.

Kenny1 · March 4, 2005, 11:35am

Hi,
I create a .Net web service,which have a object as input parameter.This object is a instance of a Purchase Order class.
webMethods can using the web service connector to create a soap cliet to invoke that .Net web service.Because the input parameter of the web service is a object,so the “service in” of the soap client is a “document” type.So I should do many mapping to this “document” type when invoking the web service.

There is a question,a member of my team asked why I do not use a “string” type as the input of the .Net web service,then the soap client just has a “string” service in.

In fact,I want to transport Purchase Order to the .Net web service.I do not know the best practice is make a object or a simple type as the interface(input parameters) of the web service.

Kenny1 · March 4, 2005, 3:05pm

Hi,

Another question,please.

Now the web service is RPC/Encoded,and have a object as input parameter.It works well.

But I failed to make the .Net web service return a object to webMethods.The exception message is “com.wm.app.Server.ServerException:
java.net.ConnectException:Connection Refused:connect”,occured at pub.client:soapRPC.

Thanks!

mwr0707 · March 4, 2005, 6:46pm

When you say object, I assume you mean the deserialized equivalent of:

Passing in a single string parameter means the .Net service must de-serialize the document contained in the string. Why do the extra work?

When the data is complex and/or there are a lot of fields ( like a PO ), I prefer SOAP-Message over SOAP-RPC. I do try to keep all of the fields as strings in order to avoid cross-system type equivalence issues.

Also, SOAP-RPC is a point-to-point protocol which I have a general bias against for delivery of business messages. This is a topic of debate however. I’ve used it for simple requests that are more technical in nature than business-related, i.e.: lookups, etc.

As you’ve probably noticed, .Net generates SOAP-Message WSDLs by default. You have to add an extra attribute to get SOAP-RPC.

So I’d do pretty much what you have except I’d use SOAP-Message instead of SOAP-RPC.

Regarding the connection refused:

Did you add the System.Web.Services.Protocols.SoapRpcService() attribute to your .Net web service class?
Did you create a webMethods web service connector, or are you calling pub.client:soapRPC yourself?
What is the declaration for your .Net function/method?

system · March 5, 2005, 6:58pm

I think Mark’s answer is right on. .Net does a lot of the work for you when it comes to doc/literal(I wish webMethods did). RPC is kind of the first generation webservices. Here is a pretty good article for further reading that kind of goes through rpc history and where doc/literal and even more generic doc/literal soap messages are going.

[url=“http://64.233.187.104/search?q=cache:onWN0ZsggesJ:www.webservices.org/index.php/ws/content/view/full/39565%2B"document%2Bliteral"%2Bstate%2Bcoupling&hl=en”]http://64.233.187.104/search?q=cache:onWN0ZsggesJ:www.webservices.org/index.php/ws/content/view/full/39565+“document+literal”+state+coupling&hl=en[/url]

As a side note to others…Has anyone work with webservices with IBM’s WSAD IDE and webMethods? I’m curious about other’s experience with WSAD.

markg
http://darth.homelinux.net