Thank you all, and I will comment ++> below
-----Ursprüngliche Nachricht-----
Von: Dimuthu Gamage [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 30. Januar 2008 03:49
An: Apache AXIS C User List
Betreff: Re: AW: AW: [Axis2C] how to return a MsgBox
Adding my thoughts..
As Mark mentioned there is no direct support for "out-in" message
exchange pattern directly just using Axis2/C.
++> that is what I would like to see.
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.
++> SAVAN/C good to know for other things. But PC clients demanding
to send just YES or NO to a requesting server (call it an agent, as
it can not finish its method until he got the users response. YES/NO.
So I agree, SAVAN/C is a bit of overhead.
>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
++> This has formatted nicely, and it is what we do! However the
client request is only synchronous. The reason is that we have
a synchronous working server. Matters of facts, which we have to
respect. So we have a clear client server synchronous
request/response paradigm.
And that is why we need today a detached CORBA-YES-NO-Server-Process
running on the clients PC
If somebody out-there needs to know YES/NO from a user, it can send
a request to this PC's-CORBA-YES-NO-Server. A msgbox will then pop
up and the user can press the button.
As we have a CORBA-Server fo each PC-Client, we pass the IOR (Ref)
of the PC's CORBA-YES-NO-Server to the CORBA-Server on the OpenVMS
Host. And then any Method in the OpenVMS CORBA Server can ask back.
So right now it looks as we need to run a Axis2/C or Axis2/J Server
on the PC, with the ability to pop up a MsgBox satisfying the incoming
request for YES/NO with either a YES or a NO.
I thougth there would be some kind of a call-back-feature in Axis2/C
for that.
++> more below
[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.
>
++> correct
> Lots of web sites use confirmation pages before completing some significant
> transaction.
++> I have no clue how confirmation pages work. Is this something a web-server
can pop-up on the client's PC? It migth what I am looking for. Just a kind which
does not enforce me to have a web service server running on each PC Client just
as an AXIS2/C-YES-NO-Server tomorrow, today an CORBA-YES-NO-Server.
>
> -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 ;-)
++> I agree the design and code of such a YES-NO-Server is not so easy.
> >
> > 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.
++> I was more thinking about an agreed up-on callback method running
on the PC client, beeing invoked when the service has to ask back for
a confirmation.
> >
> > second, if i am right, not alle mep's from wsdl are supported.
> > i think you want to have "Solicit-response"/"out-in".
++> I am far not there today to model this in WSDL, but when it comes
to the simple paradigm, that my Service has to answer YES or NO as a
result of a request, then I will certainly use WSDL and then use its
stub by the service demanding YES or NO from the user.
> >
> > 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 !?
> >
++> exactly what we do. However for security reason and simplicity we
do not register the PC' clients CORBA-YES-NO-Server, because only the
directly enaged CORBA-Server on the OpenVMS Host needs to know about
how and where to ask questions. For that we exchange the IOR's between
the two. If we need more then 1 CORBA-YES-NO-Server we just launch a
second one on the PC. Each CORBA-Server running for a given PC Clinet
has it's own CORBA-YES-NO-Server on that PC. A strict 1 : 1 relation.
And when the CORBA-Server on the HOST terminates, it sends the stop
mesage to its CORBA-YES-NO-Server to allow this one to stop and run-down
it's process.
> >
> > 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.
++> It is not what we want. We have a strict synchronously working client /
server a synchronous request / response paradigm.
> >
> > 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 :-(
> >
++> Interesting: what is registerWithServer suposed to do? Does it exist in
Axis2/C?
++> why not an axis2/c service which has a call-back-request-routine
(calling back to PC client)
++> correct the client has sent a request, a message to the axis2/service
and hence is waiting for it's response in a synchronous request/response
paradigm. But if the client would be a non-blocking-client, which has by
default a response-callback-routine, why can I not register a second or
a third call-back-routine and have the server use one of it to ask back
a question to the client. That would be very elegant.
> > 3. client sends an async message to you server, server saves all
> > informations in context to answer and quits without reply.
++> No no no, when I invoke a service I waht the fastest possible service
and a hopefully ASAP answer.
> > i do no know what will happen ;-) maybe you have to increase client-side
> > timeout ?
++> How long a non-blocking client has to wait depends on the service he
has invoked, performance figures, system load etc. Therefore we have a call-
back routine which gets control back when the server replies.
Where which paradigm comes into action synchronous blocking or
asynchronous non-blocking depends on architecture and MEP and
vice versa.
++> so have a YES-NO-Callback routine of a non-blocking client called by
the service, that could work very well and would not demand an extra
axis2/c-YES-NO-SErver on each PC.
> > write non axis service and your callback, when conditions are met, query
> > the context and create payload, then answer the initial async question.
> >
++> what do you mean with a "non axis service"? I guess I miss something.
> >
> > 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 :
> >
++> yes an immediate response is almost what a user does working with a system
unless a telephone rings and interrups him from working. In which case the
YES/NO MsgBox is on the screen and when the User reqturns, he reads the
question and answers with YES or NO, and this goes then to the waiting
Service on the Host (sorry OpenVMS :-)
> > 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.
> >
++> Here I can not follow you. Again. why a non axis service? And how do I
write to a context. Is the context a new message send to a service? I think
we do not understand us, because "what is now server and what is now client".
A fault is normaly sent to the requesting client. Lets say to our PC client
waiting for something to be completed. Now, if the server replys with a special
fault, the client expects this as the posting of his request. Ofcourse no
problem that the client can interogate the special fault and then send a YES
or a NO. But how do I get to the exact same context at the server. How does
the server know, that this incomming YES/NO is the reply of the client to
the special fault triggerd back to client in a previous step? I think this
does not work well.
> >
> > 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 ;-)
++> Thank you anyway, you gave me some hints, one I closer watch will be that
of having maybe if Axis2/C or Axis2/J allows a client with severla registered
call-back-routines and a way to make a service aware which call-back to use
for a simple YES-NO-Answer.
All thousand thanks
Josef.Stadelmann@
axa-winterthur.ch
> >
> > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
