Re: Re: Exposing XForm as a web service

> Hi Erik,
>
> as described in the orbeon tutorial,the way to implement a web  
> service is to
> create an xpl file which handles the request and returns a  
> response.This is
> possible with processors provided by orbeon package.What I'd like to  
> do is to
> extend a little bit the idea of just handling the request and  
> sending a
> response without user interaction.I'm wondering if it is possible to  
> implement
> as a part of my web service, a user interaction on some step of  
> processing the
> response.
> For example a SOAP message with some data is sent to my web  
> service,and that
> data should be verified by an operator before sending the response
> back.Received data may be  represented in a XForm with a submit  
> button.The
> operator checks data and submit it - submitting data send the  
> resposne back to
> the client of my web service.That's it.
>
> Is the idea clearer now ?
>
> Please ask if something is still not clear.Thanks for your help !
>
> Regards,
> Boris

> Boris,
>
> Yes, this is clearer. You could do the following:
>
> * Have the web service set a "flag" along with data received into
> storage, like a local database.
>
> * Block the web service until further notice, e.g. by polling in the
> database or other synchronization mechanism.
>
> * Communicate to a connected user that the flag has been set. This
> could be done through polling, i.e. the user's web browser must
> periodically check whether the flag has been set or not.
>
> * Once the user detects that the flag is set, take some action, such
> as displaying the data sent though the web service.
>
> * Once the user takes some action, such as approving the data or
> filling-out more data, store the result into storage.
>
> * Unblock the web service call.
>
> * The web service returns with the information from the user.
>
> This makes the assumption that until the user is connected to a page
> that has the polling functionality above, the web service will just
> wait. I am not sure I can see how this could work differently.
>
> This clearly requires quite a bit of implementation work. It is not
> built-in functionality.
>
> Another approach could consist in having the web service just putting
> the information to check in a queue. The operator's UI periodically
> updates with the latest information in the queue. Once a piece of
> information is approved, the application calls another web service
> which continues the processing. This would avoid the issue of blocking
> the initial web service, and that is one synchronization problem to
> solve.
>
> Does this help?
>
> -Erik
>
> On Feb 24, 2008, at 7:50 AM, Boris Dushanov wrote:
>
>> Hi Erik,
>>
>> as described in the orbeon tutorial,the way to implement a web
>> service is to
>> create an xpl file which handles the request and returns a
>> response.This is
>> possible with processors provided by orbeon package.What I'd like to
>> do is to
>> extend a little bit the idea of just handling the request and sending a
>> response without user interaction.I'm wondering if it is possible to
>> implement
>> as a part of my web service, a user interaction on some step of
>> processing the
>> response.
>> For example a SOAP message with some data is sent to my web
>> service,and that
>> data should be verified by an operator before sending the response
>> back.Received data may be  represented in a XForm with a submit
>> button.The
>> operator checks data and submit it - submitting data send the
>> resposne back to
>> the client of my web service.That's it.
>>
>> Is the idea clearer now ?
>>
>> Please ask if something is still not clear.Thanks for your help !
>>
>> Regards,
>> Boris
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>

> Hi Erik,
>
> yes,both ideas are clear.What if the so called operator who checks  
> data
> and submit it could not reply instantly but a week later for  
> example.It
> is not possible to keep many clients' connections for such a long  
> period
> of time.The perfect scenario for me would be :
>    - process the request
>    - store data in a database for example
>    - generate an unique URL for that specific request
>    - send a mail to the operator who has to handle that request with
> the URL generated in the previous step
>    - the operator uses that URL which points to a xform and submit  
> data
> In this case the connection is not kept.Is there a mechanism in the
> orbeon which could handle such cases and reply to the client of the  
> web
> service not in the context of the initial request
> connection?Xml-serializer processor seems to be too simple for  
> handling
> such scenarios.
>
> Regards,
> Boris
>
>
> Erik Bruchez wrote:
>> Boris,
>>
>> Yes, this is clearer. You could do the following:
>>
>> * Have the web service set a "flag" along with data received into
>> storage, like a local database.
>>
>> * Block the web service until further notice, e.g. by polling in the
>> database or other synchronization mechanism.
>>
>> * Communicate to a connected user that the flag has been set. This
>> could be done through polling, i.e. the user's web browser must
>> periodically check whether the flag has been set or not.
>>
>> * Once the user detects that the flag is set, take some action, such
>> as displaying the data sent though the web service.
>>
>> * Once the user takes some action, such as approving the data or
>> filling-out more data, store the result into storage.
>>
>> * Unblock the web service call.
>>
>> * The web service returns with the information from the user.
>>
>> This makes the assumption that until the user is connected to a page
>> that has the polling functionality above, the web service will just
>> wait. I am not sure I can see how this could work differently.
>>
>> This clearly requires quite a bit of implementation work. It is not
>> built-in functionality.
>>
>> Another approach could consist in having the web service just putting
>> the information to check in a queue. The operator's UI periodically
>> updates with the latest information in the queue. Once a piece of
>> information is approved, the application calls another web service
>> which continues the processing. This would avoid the issue of  
>> blocking
>> the initial web service, and that is one synchronization problem to
>> solve.
>>
>> Does this help?
>>
>> -Erik
>>
>> On Feb 24, 2008, at 7:50 AM, Boris Dushanov wrote:
>>
>>> Hi Erik,
>>>
>>> as described in the orbeon tutorial,the way to implement a web
>>> service is to
>>> create an xpl file which handles the request and returns a
>>> response.This is
>>> possible with processors provided by orbeon package.What I'd like to
>>> do is to
>>> extend a little bit the idea of just handling the request and  
>>> sending a
>>> response without user interaction.I'm wondering if it is possible to
>>> implement
>>> as a part of my web service, a user interaction on some step of
>>> processing the
>>> response.
>>> For example a SOAP message with some data is sent to my web
>>> service,and that
>>> data should be verified by an operator before sending the response
>>> back.Received data may be  represented in a XForm with a submit
>>> button.The
>>> operator checks data and submit it - submitting data send the
>>> resposne back to
>>> the client of my web service.That's it.
>>>
>>> Is the idea clearer now ?
>>>
>>> Please ask if something is still not clear.Thanks for your help !
>>>
>>> Regards,
>>> Boris
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws