Saturday, May 17, 2008

Your reference is not my reference

This week we had a discussion at work. It was about reference IDs. When a system calls the webservice on another system, sometimes you need to specify a reference ID. One such case is with asynchronous webservices. The system does the call, but does not get an immediate answer (other than: "Yeah, we're working on it"). And at some point in the future the system gets a call from the webservice (a callback) to return the result of the webservice. One way (and in my opinion the easiest way) to deal with this is to have the system send a reference ID with the original request and have the webservice put the reference in the asynchronous result. This way the system can correlate the result with the request and process it.

But as we found out today, that's thinking in "functions". Meaning that calling a webservice function and getting it's results is an operation that's completely separate of anything else. Any other thing can occur between calling and receiving a result and after you get the results, if there is a process, that ends that part of the result. But for some calls we need to think in "processes".

Our system is like a webservice bridge. We expose a generic interface to commercial systems and we consume very specific interfaces from technical back-end systems. So when a commercial system sends us a request, we map it into a specific request to a back-end system. This way the commercial system doesn't need to know all the gritty details of the technical system. Also all of our calls are atomic....except for two. Normally the commercial system deals with the process and it has never had any effect on our system. Until we needed to support a certain function that did. Now in my opinion the biggest problem was caused by a faulty design of the technical back-end, but it did expose a pit-trap we could fall in ourselves now that we are designing a new interface for the commercial systems. Sometimes you not only need to know what request was responsible for the incoming result, but also which commercial process it's part of. This is required if you need to perform certain steps in order and the technical back-end system also needs to follow-up on an earlier request with a follow-up request.

So we had a discussion about this. Do we take the reference form the commercial system and pass it on to the technical system. Out-sourcing the generation of references as it were? I was opposed, because I think a reference should only have meaning to the system that generated it. If we use the reference from the commercial system, we give it a meaning it shouldn't have. Also, if some time in the future we add more commercial systems there is a chance (and knowing Murphy it will happen) that more then one commercial system will come up with the same reference and then we have a problem.

My take on the whole situation is that we apparently need both a "function-reference" and a "process-reference". We generate our own function reference and use the process reference of the system that guards the process. This could be our system, in which case we generate the process reference, or it could be a commercial system, in which case we just take the reference and pass it on.

No comments: