Adding my thoughts..

As Mark mentioned there is no direct support for "out-in" message
exchange pattern directly just using Axis2/C.

But AFAIK you can use Savan/C[1] (eventing module for axis2) to do
that. There what you will do is subscribe set of clients with a
server, and then server can notify clients when required.

But in your case that is not required, because it will be a big
overhead if you setup savan just for the user confirmation. It is
supposed to used for some more complicated eventing.

>From Mark's thoughts I prefer the 3rd one. That is to use async
request with some big value in timeout..

There,

Client request asynchronously ----------> Server start do work
             |                                               |
             |                                               |
             |                                               |
                             <--------------    sends the confirmation.
   The callback pop up                (the response)
    the  message box                   (i.e. that operation ends)
            |
     The callback send a
      'in only' message to -------------> Server receive
        the server                       (in a new service operation)



Hope this will format ok in your mail client


[1] http://ws.apache.org/savan/c/


Thanks
Dimuthu



On Jan 30, 2008 12:34 AM, Ben Wyckoff <[EMAIL PROTECTED]> wrote:
> Hi,
>     I'm far from a windows (or web services) expert, so I can only offer
> some comments about the paradigm in general. I read this and thought of the
> http basic authentication paradigm: the client makes a request to the
> server, the server responds with a 401 Unauthorized response, which causes
> the browser to automatically pop up a dialog box asking for credentials.
> When they are supplied, the browser resubmits the request with the proper
> credentials, and the server processes it.
>
> I don't know what your client application is or at what point the web
> service needs to get feedback, but the challenge/response paradigm might
> work for you. You would have to return something to the client (e.g.,
> javascript, an active-x reference) that triggers the MsgBox. The point is
> that the requests are not nested in the authorization example, whereas the
> situation you described does have the server->client request nested.
>
> Lots of web sites use confirmation pages before completing some significant
> transaction.
>
> -Ben
>
>
> > From: Mark Nüßler <[EMAIL PROTECTED]>
> > Reply-To: Apache AXIS C User List <axis-c-user@ws.apache.org>
> > Date: Tue, 29 Jan 2008 19:31:49 +0100
> > To: Apache AXIS C User List <axis-c-user@ws.apache.org>
> > Subject: Re: AW: AW: [Axis2C] how to return a MsgBox
>
> >
> > Hello Josef,
> >
> > i've read your first post, opened a reply - starting to
> > write my thoughts down - deleted it, cause im not an expert ;-)
> >
> > first, i think you have to write your server side callback method
> > outside the service, cause the service is only active when triggerd.
> > you can use axis2 api to create payload - clear.
> >
> > second, if i am right, not alle mep's from wsdl are supported.
> > i think you want to have "Solicit-response"/"out-in".
> >
> > i do not know corba very well, but i think your former corba server
> > could send the message to the client, cause the client is registerd
> > and will be found over orb/naming service !? the client seems to be
> > permanetly connected / has a listening port !?
> >
> >
> > possible solutions i can imagine for axis2 :
> >
> > 1. the client has to ask from time to time if something has happend
> > on serverside. if nothing has happend on serverside, server didn't
> > send back anythink or just a message like "no thanks, ask again".
> > otherwise the server replys with your yes/no question, client has to answer.
> > but i think this is not what you want, if you talk about a
> > server side callback.
> >
> > 2. when starting your client, you call a "registerWithServer" method,
> > to let the server know the clients endpoint, using the servers context,
> > maybe at application level ?
> > write a service (not an axis service) that has a callback. when your
> > conditions are met, query the context and send the question.
> > now you have the problem, that the client is not listening - you have
> > to run a axis service on clientside :-(
> >
> > 3. client sends an async message to you server, server saves all
> > informations in context to answer and quits without reply.
> > i do no know what will happen ;-) maybe you have to increase client-side
> > timeout ?
> > write non axis service and your callback, when conditions are met, query
> > the context and create payload, then answer the initial async question.
> >
> >
> > cause i do not know if it is important to answer the question yes/no
> > immediately, when conditions are met - maybee this is also possible :
> >
> > 4. write a non axis service, when condition is met, write a flag to the
> > context. when client tries to communicate (you know the user is active),
> > query the context for the flag, send an special-fault as
> > answer. axis-client has to interpret this fault as yes/no question,
> > send the answer and service can do its work, reseting the flag in
> > context. after this, the user as to resend the initial message again.
> >
> >
> > mh, i don't really have an answer for you, just some thoughts and to let
> > you know that you are not alone with webservice paradigm and its
> > problems ;-)
> >
> > mfg derMark
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Stadelmann Josef schrieb:
> >> Hi Dinesh
> >>
> >> What relates to Axis2C and what not, how can a novice like I
> >> know that in FULL. i.e. possible Callbacks to caling clients
> >> without posting the service thread, but making it wait for the
> >> answer to occure. i.e. Agent paradigm.
> >>
> >> I am just seeking for an elegant method to invoke from within
> >> an Axis2/C server/service something like a callback to the client
> >> which askes Windows for a Windows MSGBOX with YES NO Buttons and
> >> a msg and a title.
> >>
> >> When the user then clicks a button, the answer is transfered
> >> to the waiting server/service and the service will evaluate
> >> the asnwer and can then continue.
> >>
> >>
> >> I am seeking an elegant way, one of you migth know, such as how
> >> to call back or agree on a clall back routin in the originating
> >> Axis2/C client
> >>
> >> If nobody knows that at your side of the pond, well, then I have
> >> to do it the hard way by miyelf.
> >>
> >> I generate a client side stub which is invoked by a server/service
> >> which sends to any server/service a message
> >> a title, a cpation, and some buttons or at least ID's to it.
> >>
> >> The receiving service, in this case on a windows system, will then
> >> invoke a Windows Operating System call and ask for a MsgBox.
> >>
> >> Once the button is clicked the resulting button value
> >> is then returedn as an integer to the client, which is in this
> >> case the invoked web service.
> >>
> >> I did so in the past using a corba server on a windows system
> >>
> >> Now all what changes is CORBA to WebServices
> >>
> >> And the paradigm is CLIENT -> AGENT -> question to MSG-BOX-SERVER
> >> and back.
> >>
> >> where Client is a web service client on a PC
> >>
> >> the Agent is the axis2/c webservice server which needs to ask back
> >>
> >> the Server is service hosted on the same PC as the Client resides.
> >>
> >> The bas thing is that I need on each PC a web service/server for that,
> >>
> >> Josef,
> >>
> >>
> >>
> >>
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Dinesh Premalal [mailto:[EMAIL PROTECTED] Auftrag von Dinesh
> >> Premalal
> >> Gesendet: Dienstag, 29. Januar 2008 10:00
> >> An: axis-c-user@ws.apache.org
> >> Betreff: Re: AW: [Axis2C] how to return a MsgBox
> >>
> >>
> >> Hi Josef,
> >>
> >>    I'm not sure how this question relates to Axis2/C? or I didn't
> >>    understand it well. If you could be more specific on your question
> >>    I guess you could get some more thoughts.
> >>
> >> thanks,
> >> Dinesh
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to