Stan,
Thank you very much for your comments. Your comments revalidate some of my thoughts.
Currently we have only browser based clients for our site (Org1). The webapp does remember the input entered by the user for the session duration. Depending on the data, the system determines eligibility of the person for various assistance programs.
Kind of page-flow we have could be like this:
a user enters enters age on the first form.
If the age is not old enough then no need to ask further question
like if the person is receiving medicare or not, which will affect old-age assistance determination. And so forth.
Now if were to provide webservice to the non-browser client then that client needs pass xml request and get back the result, per the xml schema we will create. The other orgs will use our schema
to send the xml request would have to provide this information like person is receiving medicare or not unnecessarily, for persons which could not possibly have received medicare becuase they are not age-qualified.
So set of input data elements needed to determine
the eligibilities can vary depending ob values of other data.
So our implementation choices could be:
1) Require that org2 (and org3,org4... in not so distant future) send the xml request to supply superset of data some of which will not be used in eligibility determination.
2) Require minimal data first and if the system determines that some additional info could possibly lead the applicant to become eligible to some programs then in the reponse instead of sending eligibility determination we send message to supply more data and send request again.
3) The other agencies' worker enters data in his GUI and then clicks on a button/link which will open a new browser window for our application session where the user entered data is already pre-populated in our session and then the user continues interacting with our application as usual.
I'm not quite sure which one is better. None of these look perfect.
With choice 1, though on some level looks cleaner, we have redundancy.
Also, we may need to provide customized schema for org2 (and org3..in future).
With choice 2, on average, there will more than one invocation per one logical request. Doesn't look good.
Choice 3 does not look that attractive either. It merely is then existing application plus some data pre-populated. Also, with choice 3, the results are only displayed in the browser nothing gets sent back as would be possible with other choices. With the choice 1 or 2, the sent back results via webservice could potentially be used for further processing in those organizations.
I'm not sure whether I conveyed the problem clearly.
But if it did make some sense, which one looks better to you?
Regards
Roshan