Hi,

Altough this is my first post, I had found wmusers to be pretty helpful on previous issues I have had. So thanks in advance.

Now, to my current problem:

I'm having a pretty common escenario where an external client sends a request to a  Web Service in IS (RPC style, altough I believe doc/lit it's better). Anyways, this request has to be completely synchronous, so the WS in IS does some processing and send back an answer (pretty normal until here). The prob is, I'm being asked to 'know', when sending back the response, if the requestor was online or not, so an automatic correcting action can be performed. 

I believe my only try is convincing the client this isn't natural and resembles client-server development instead of SOA (haven't been successful so far) or having the SOAP content handler rewritten to catch a 'hope-it's-thrown' exception when trying to send the response back to the requestor. I'm no expert on WS's so I'm not sure if this would actually work since I don't know if I'll be able to have access to that 'exception'. I'd appreciate any light shed on this matter.

On the other side, if the 'exception' approach is 'possible' (altough not plausible), I would still have to face with rewritting the SOAP content handler which I believe won't be a small task even knowing what it has to be implemented to successfully replace the wM's built-in content handler. 

If you happen to have any leads on this regard, would be highly appreciated.
I understand I would need to implement the getInputValues() and setOutputValues() methods from the ContentHandler interface but have no idea on what’s to be done there.

Again, I appreciate any ideas on how could this could be solved or reasons why it couldn't, even knowing how crazy this should sound.

Regards,
Brian Ponce

Hey Brian,
SOAP or Web Services is really not the issue here. The underlying transport protocol is HTTP. That’s what is handling the communication exchange. I’m not aware of any spec with HTTP that allows the system sending the response back to know whether the client got it or not. That’s kind of anti-http. :eek:

Within webMethods IS, the soap processor is handling the soap exchange but end the end http is actually handling the communication.

I think the only real way to do this, your requirement is sounding sorta kinda like a two phase commit situation, is to handle the ack on the client side. It short your client sends a request to IS server, the IS server processes the request, the client acks the response received back from the IS server.

my two cents on this.

I’m with Mark on this. Expecting the service provider to take action when the synchronous service consumer unexpectedly disappears is quite odd.

On a side note, strictly speaking this interaction is a form of client-server. The service client makes a request of the service server.

This scenario as described is pseudo-asynchronous. I would change things a bit to make it truly asynch. Have the client send the request and retrieve some type of request ID from the service provider.

The service provide could push results to the client if it is capable of receiving an incoming SOAP request message or the client could send a subsequent request to obtain the results of the initial request.

In that way you can handle long-running operations and have a reasonable opportunity to know that the client received the results. If the client can receive a SOAP request you would only assume that the results were received if it acknowledged receipt.

HTH,

Mark

Thanks Rob and both Mark G and Mark C, for your prompt response.

To complete my escenario, the web service client is being used inside an oracle store procedure, which starts a transaction and expects a response from the web service on IS to commit/rollback. This behavior isn’t to be changed at all (constraint because is one of the so called ‘soon-to-be-dead/replace’ piece of code), so it has to be completely synchronous while within the WS processing there is a call to a program on AS400 which could take some mins to end.

I agree this resembles client-server and that is protocol issue instead of SOAP/web services issue, but since I’m not sure what’s inside the SOAP message content handler I was hoping I could get some access to that layer somehow.

I also agree this is an odd scenario and I’m no certain the could even be solved at the http layer. Also as you mentioned, this seems more like getting it solved by a semi-asynchronous or asynchronous model, by having acknowledges sent back and forth between the requestor and provider systems.

Thanks again, and if there are any further suggestions or comments on this, they’ll be more than welcome.

Regards,
Brian Ponce

Hmm. I’m quite confused now. If a stored proc is calling a web service within a transaction context (odd in itself)–what is IS expected to do if it cannot send the response? What exactly does the “correcting action” consist of? Why doesn’t the stored proc deal with connection/communication errors?

Hi Rob, indeed is an odd escenario.

The requestor client as I said is called within a store procedure and expects a response from the WS in order to commit/rollback the transaction it started but is not a XA transaction, I understand there are just some inserts/updates which would be confirmed upon the response. What the IS has to do as a correcting action is on the AS400 side.

The reason of this ‘integration’ is to be able to sent info back and forth between this custom app residing in Oracle (the store procedure is part of this app) and AS400 (through some CLs), having wM IS in the middle as the ‘connector’ and exposing this ‘connection’ as a WS.

For one escenario, if the info sent to AS400 is processed correctly, the answer has to go back all the way to the Oracle App but, if the Oracle App (and particularly the original transaction from which the client was called) isn’t available (the response couldn’t be delivered for any reason) there has to be a ‘rollback’ operation on AS400.

So, we’re being asked to be aware if the requestor client is actually receiving the response otherwise, we should go to AS400 and ‘execute’ another CL which would performed the ‘rollback’.

I’m not claiming this is a best practice nor a clean solution but it’s been a hard time since the provider which is working on both Oracle app and AS400 end points doesn’t have, at the end, the appropriate skills (reason why we’re using RPC instead of doc/lit) and above that the client is convinced the synchronous means online and online means having both end points aware of each other. I think this may have changed in the past hours (I mean, the conception the client has on that) but it was the initial context and thus the main reason of my questions.

I hope I’ve clarified this a bit more and thanks for your time

Regards,
Brian

Brian,
Sounds like a compensating transaction pattern to me. This is similar to a two-phase commit where all parties need to be coordinated except you are not going to be able to do that in this case. Generally in this case you would use a compensating transaction to roll back the AS400 transaction if the Oracle SP times out waiting for a response from the IS server.

That’s really the only reason right? No response from the IS server because of a network failure, or crash. Any other error type will either be caught on the IS side or passed back to the SP within the SOAP reply.

If the Oracle SP times out waiting for the response then it catches that and issues a compensating transaction back to IS which handles the AS400.

It’s a more complicated pattern. I like Mark C’s idea of the async callback pattern better. It’s much more reliable.

The other option is to invoke the Oracle SP from webMethods IS and let it handle the transaction on both Oracle and the AS400. An RPC base web service been called from an Oracle SP is really not buying you a lot here.(I know that’s not your idea either)

That’s correct Mark G. It’s a compensating transaction pattern we’re trying to achieve and unfortunately we have to stick to a completely synchronous model so altough I too agree with Mark C. on the asynchronous callback pattern I couldn’t go over it. We even had to keep off having guaranteed delivery due to that constraint. The way that SP was constructed also restricted us to have it run in background, they practically have the user sticked to the screen waiting for the process to end, which could be quite short when sending individual records but definitely not when processing a bunch of them (pretty ugly and frustrating when knowing there are some much better ways to have it running). Again, it’s a piece of code they don’t want to have it changed ‘cause eventually it’ll be replaced as well as they dont’ want to bother having the actual operation changed now and when the new system comes about, so we’ll just have to stick to the possibilities as ackward as they may be. Lucky me

I don’t like either having a SP call the WS client but at the moment I don’t believe they’ll reconsider, while having wM handle the transaction from both end points by calling the SP (I would have like to be able to) might not be possible since they’ll be just switching to send the info to wM instead of another legacy code, and won’t agree to change the way their ‘app’ works (each post I write I come to find more oddities around the escenario)

I thank you for sharing your experience and dropping your comments on this. I just wanted to be sure I wasn’t missing something I could have done for having implemented the ‘I’m-aware-of-the-client’ thing from within wM, like an exception being thrown when sending back the response if there was a prob, on some layer I could access.

Regards,
Brian Ponce

Have you looked at using IS Event Handler?
I’ve not used it personally so I can’t vouch that it’ll handle your requirements but I’m sure you’ll be able to easily write a quick proof of concept.
Check the Developer User guide for how-to…

Phil,

I’ll check upon it altough we’re considering having some response acknowledges as suggested by Mark G. and Rob. Not fully asynchronous as MarK C. suggested due to our constraint but should’ve been the solution for this since inception. Still, we will be violating in some sort our constraint since it would be semi-asynchronous as Mark C. pointed.

Now, If you allow me, I will give this thread a turnaround… :rolleyes:

Keeping on the same context, right before ‘deciding’ to go with RPC/encoded we were doing doc/lit wrapped. Well, we’re still trying to get the provider to stick to doc/lit wrapped.

Since the Web Service will have a single input string as well as a single output string, having the wrapping element would appear not to be required (but for having the service name to call).

I know there are some other threads referring to doc/lit but haven’t found the following. If there happends to actually be a thread who could answer this and you could be so kind to point me to it, I’ll appreciate it.

Is it possible to have a plain doc/lit approach (without the ‘wrapping’ document) while still using wM’s default SOAP processor? I mean, if having the wrapping doc removed which I understand helps the SOAP processor to know which service on IS to invoke, would still be valid to have the name used for the wrapping document on the input string? I’ve tried a quick example and altough I was unsuccesful I might be missing something.

Would the wsc wizard produce a ‘client’ for the resulting WSDL or would we need to have it done by ourselves? The latter, knowing that wsc wizard isn’t the better approach for having this or other ‘clients’ done for reasons Mark C. has already enlisted on other threads.

Thanks again for sharing your thoughts.

Regards,
Brian

Brian,
Take a look at this thread on Doc/literal and Doc/literal wrapped. [URL=“wmusers.com”]wmusers.com

Be sure to read all of the messages because there are clarifications from further testing.

In a nutshell, webMethods IS supports Doc/Literal. Doc/Literal Wrapped requires the input message name and the operation name to be the same. webMethods IS default soap processor uses the name of the input message along with the namespace to find the service to invoke not the operation name.

Thanks again Mark, that’ll do it.

Regards,
Brian