Skip to main content

How to invoke Client Callback Handler from EJB3 Session Bean

34 replies [Last post]
Anonymous

Hi,

During some business logic in EJB3 session bean I need to ask the client
(Swing GUI Client using JNLP) for some additional information using
custom Swing Dialog Form. My questions are:
1. How can I invoke my own Callback Handler from EJB3 session bean? The
callback handler is specified in "application-client.xml" as follow:

com.cosmos.acacia.callback.AcaciaCallbackHandler
2. Are there another ways to do the above? My question is related with
the requirement of common using of Security Login Dialog and Custom
Dialog and some potential conflict(s).

Regards,
Miro.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
whartung
Offline
Joined: 2003-06-13

> The samples in the JMS Tutorial
> only will work with MDBs since they take the queue
> instance out the JMSReplyTo header field -- but that
> approach is not possible here, since we do not have
> an MDB reacting to a queue, but a SB reacting to a
> remote method call.
>
> So how shall that work?

Simple, don't use a Session Bean call. The MDB, for this case, replaces the Session Bean as the client interface. The MDB can act as a proxy for the SB if you like, or you can simple refactor the code out of the SB in to code that is called by both the SB and the MDB (assuming you still need the SB interface).

Once the MDB has the message, it can pass the message in to SB calls, and they can directly interact with the temporary queues if they like.

If you have several different methods for your SB, you can simply make it a parameter of the message, and then dispatch on that parameter within the MDB to make the proper call (or you can create a queue for each individual method you'd like to call).

You can also use a common queue for all of the various methods, but have different MDBs using filters to get the specific messages that they're interested in. All sorts of different mechanisms and paradigms that could be parleyed here.

But you need to embrace the idiom of the JMS queue and the MDBs, then rethink your problem in those terms. This isn't a "band aid", rather it's a bit of rearchitecting for your application.

Markus KARG

glassfish@javadesktop.org schrieb:
>> The samples in the JMS Tutorial
>> only will work with MDBs since they take the queue
>> instance out the JMSReplyTo header field -- but that
>> approach is not possible here, since we do not have
>> an MDB reacting to a queue, but a SB reacting to a
>> remote method call.
>>
>> So how shall that work?
>>
> Simple, don't use a Session Bean call. The MDB, for this case, replaces the Session Bean as the client interface. The MDB can act as a proxy for the SB if you like, or you can simple refactor the code out of the SB in to code that is called by both the SB and the MDB (assuming you still need the SB interface).
>
That is not possible since (a) it is a stateful SB that has to store
information on the current session (b) 99% of the SB calls need to
return results *synchronously*, while a replacement by MDB will not be
able to store are per-session information or return information
*synchronously*. So this is not a valid solution but imposes more
problems than it solves.
> Once the MDB has the message, it can pass the message in to SB calls, and they can directly interact with the temporary queues if they like.
>
> If you have several different methods for your SB, you can simply make it a parameter of the message, and then dispatch on that parameter within the MDB to make the proper call (or you can create a queue for each individual method you'd like to call).
>
> You can also use a common queue for all of the various methods, but have different MDBs using filters to get the specific messages that they're interested in. All sorts of different mechanisms and paradigms that could be parleyed here.
>
> But you need to embrace the idiom of the JMS queue and the MDBs, then rethink your problem in those terms. This isn't a "band aid", rather it's a bit of rearchitecting for your application.
>
Exactly. It will be a complete redesign of the application. The much
simpler approach is *not* using temporary queues, but just use a static
JMS topic and filter for self-defined session IDs: In ejbCreate, pass a
GUID that identifies the client, and use that GUID as a JMS header.
Apply a selection criteria in the JMS filter and you're done.

Sad but true, it seems as if temporary queues do not work as soon as
*synchronous* replies are needed or people just do not want to build big
stuff ontop of their current app.

Would be great if future JMS specs would address this issue by defining
a way of passing temporary queues to SBs directly, without the need of
MDBs. :-)

Regards
Markus
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=276349
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Miroslav Nachev

[att1.html]

Miroslav Nachev

[att1.html]

Miroslav Nachev

[att1.html]

Miroslav Nachev

[att1.html]

Miroslav Nachev

Hi,

But this mechanism is already implemented in GlassFish for LoginModule
on server side and GUI LoginDialog for client side. Unfortunately it is
very complex and that's why I need of help. I need just to know which
method of which class for server side produce the call and which method
received that call from client side. Just that. The rest is simple.

Miro.

glassfish@javadesktop.org wrote:
> Actually, we should stop speaking about client and server in this case. The client is by definition the caller and the server the callee. What you want is server-server communication. This is possible with RMI: the "client" can export a "notification" object when it starts. The "client" can then call the "server" and pass a remote reference of the "notification" object. The "server" can then broadcast event to all registered clients (It's maybe not exactly like this, but we do have such a solution for a RMI client-server application that need to be sometimes notified by the server side). But I fear that it's not possible with IIOP.
> [Message sent by forum member 'ewernli' (ewernli)]
>
> http://forums.java.net/jive/thread.jspa?messageID=275025
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

tjquinn
Offline
Joined: 2005-03-30

Miro,

Everyone who has replied to you is trying to help, although you seem to be frustrated with what we are saying. Let me try to explain once again.

As several of us have written, the Java EE programming model does not support what you want to do using a simple method invocation model.

You have mentioned the client authentication callback several times, repeatedly asking for what classes and methods in that implementation you can use to do what you want. You have assumed that the ORB server calls back to the ORB client. It does not.

In fact the naming and ORB implementation internally follows exactly the approach ljnelson and I have suggested that you use in your application. The fact that authentication is required is returned to the ORB client as part of a remote method [i]return value[/i]. The ORB on the client side uses that return value to prompt the user for additional information using the authentication callback. (Note that this method callback occurs locally, from one object on the client to another. It does NOT occur from the server to the client.) Then the ORB sends another remote method call to the server with the new information collected from the user. Always the ORB client makes the method call and responds to the return value.

ljnelson and I have suggested one way you can solve your problem using a similar approach. Markus suggested another. I understand that neither of these approaches is what you were thinking about initially, and neither is as simple as the remote method callback you first talked about. But your approach is not supported. No one will be able to tell you what class and method in the ORB implementation you can use to do this because no such method exists that will do what you want the way you want to do it. Plus it would not be supported and I would think you want to avoid an unsupported solution.

I believe that the technique ljnelson and I have suggested would be only slightly more complicated then your original idea in which the server calls back to the client. In your approach the server might be able to invoke one of several different client-side methods, depending on what additional information might be needed. In ljnelson's and my approach, the server needs to return that information as part of a return value object from the EJB method so the client can figure out what information to request of the user.

I understand you are frustrated that you cannot solve the problem in the way you first thought would work. People have tried to be helpful, suggesting several different ways you can implement your application that will meet the business need using what Java EE offers. I hope you will be able to choose one of those that meets the business need - even if it is not the technical approach you first had in mind - and be successful with your application.

- Tim

Miroslav Nachev

[att1.html]

whartung
Offline
Joined: 2003-06-13

Miroslav,

Read this carefully.

Callbacks are a dead end. IT CAN NOT BE DONE. There are several reasons that make it utterly impractical.

The most "straightforward" solution is simply JMS.

One of the features of JMS is a "private queue". Essentially, an attribute of the message being sent is a queue that the reciever can use to send back a result to the caller. This technique is a way to make what is nominally an asynchronous call, effectively a synchronous one.

When your client makes the initial request, it can set up a private response queue that it can listen to. The server (a Message Driven Bean) will listen to the "main queue", process what it wants to, and each time it may need to "call back", it can set up its own private queue, send a message to the client using the private queue the client originally sent, then listen for a response on its own private queue. The client gathers its information, and replies on the servers private queue. It can do that as often as it likes.

When it's all done, the private queues are destroyed and processing moves on.

It's a little cumbersome, but it works, and its portable, and should suit your need quite well.

The interchange all happens in the JMS server, the server never talks directly to the client.

Also, you'll need to ensure that you have enough instances of your Message Bean, since it sounds like it can block while waiting for the users (which means you'll need enough MDBs to service however many simultaneous blocked users you may have).

Miroslav Nachev

OK. I was thinking about that but it was difficult to find some way to
create "private queue". Are there any examples?

Miro.

On Fri, May 23, 2008 at 12:57 AM, wrote:

> Miroslav,
>
> Read this carefully.
>
> Callbacks are a dead end. IT CAN NOT BE DONE. There are several reasons
> that make it utterly impractical.
>
> The most "straightforward" solution is simply JMS.
>
> One of the features of JMS is a "private queue". Essentially, an attribute
> of the message being sent is a queue that the reciever can use to send back
> a result to the caller. This technique is a way to make what is nominally an
> asynchronous call, effectively a synchronous one.
>
> When your client makes the initial request, it can set up a private
> response queue that it can listen to. The server (a Message Driven Bean)
> will listen to the "main queue", process what it wants to, and each time it
> may need to "call back", it can set up its own private queue, send a message
> to the client using the private queue the client originally sent, then
> listen for a response on its own private queue. The client gathers its
> information, and replies on the servers private queue. It can do that as
> often as it likes.
>
> When it's all done, the private queues are destroyed and processing moves
> on.
>
> It's a little cumbersome, but it works, and its portable, and should suit
> your need quite well.
>
> The interchange all happens in the JMS server, the server never talks
> directly to the client.
>
> Also, you'll need to ensure that you have enough instances of your Message
> Bean, since it sounds like it can block while waiting for the users (which
> means you'll need enough MDBs to service however many simultaneous blocked
> users you may have).
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=276149
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
[att1.html]

whartung
Offline
Joined: 2003-06-13

The formal term is "temporary destination".

This is a link within the JEE 5 Tutorial briefly discussing them. Crawl around from there to get the details.

http://java.sun.com/javaee/5/docs/tutorial/doc/bncfu.html#bncgb

Markus Karg

I did not follow the thread completely, but AFAIK the original problem was that a session bean wants to asynchronously notify clients. "JMS Temporary Queue" seems to be a great idea, indeed, but how shall the session bean get that queue instance? Since the temporary queue gets created by the client, and since nobody guarantees that the vendor's implementation of the TemporaryQueue interface implements also the Serializable interface, one cannot pass that instance to the session bean. The samples in the JMS Tutorial only will work with MDBs since they take the queue instance out the JMSReplyTo header field -- but that approach is not possible here, since we do not have an MDB reacting to a queue, but a SB reacting to a remote method call.

So how shall that work?

Thanks
Markus

-----Original Message-----
From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
Sent: Freitag, 23. Mai 2008 00:50
To: users@glassfish.dev.java.net
Subject: Re: How to invoke Client Callback Handler from EJB3 Session Bean

The formal term is "temporary destination".

This is a link within the JEE 5 Tutorial briefly discussing them. Crawl around from there to get the details.

http://java.sun.com/javaee/5/docs/tutorial/doc/bncfu.html#bncgb
[Message sent by forum member 'whartung' (whartung)]

http://forums.java.net/jive/thread.jspa?messageID=276183

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Miroslav Nachev

Hi,

Thanks that somebody support me because the guys from Sun attack me so
embittered. I am fully agree with you and that was the reason to ask the
community how to get the session key (session id) with which to create a map
between the session and client. Do you know how to get the session key when
I am in some Stateful or Stateless bean?

Regards,
Miro.

On Fri, May 23, 2008 at 11:10 AM, Markus Karg wrote:

> I did not follow the thread completely, but AFAIK the original problem was
> that a session bean wants to asynchronously notify clients. "JMS Temporary
> Queue" seems to be a great idea, indeed, but how shall the session bean get
> that queue instance? Since the temporary queue gets created by the client,
> and since nobody guarantees that the vendor's implementation of the
> TemporaryQueue interface implements also the Serializable interface, one
> cannot pass that instance to the session bean. The samples in the JMS
> Tutorial only will work with MDBs since they take the queue instance out the
> JMSReplyTo header field -- but that approach is not possible here, since we
> do not have an MDB reacting to a queue, but a SB reacting to a remote method
> call.
>
> So how shall that work?
>
> Thanks
> Markus
>
> -----Original Message-----
> From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
> Sent: Freitag, 23. Mai 2008 00:50
> To: users@glassfish.dev.java.net
> Subject: Re: How to invoke Client Callback Handler from EJB3 Session Bean
>
> The formal term is "temporary destination".
>
> This is a link within the JEE 5 Tutorial briefly discussing them. Crawl
> around from there to get the details.
>
> http://java.sun.com/javaee/5/docs/tutorial/doc/bncfu.html#bncgb
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=276183
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
[att1.html]

Markus Karg

First of all, I do net see that anybody attacked you. They just tried to
convince you that using JMS is the right approach, whereas callbacks
just will not work.

No, I do not know how the session ID can be obtain and just wait what
the Sun guys will answer on my question how to obtain the temporary
queue in the session bean. For an MDB, it is not a problem, but for SBs
it seems to be pretty hard to do. Current in my app I just am using a
global, persistent topic and do "broadcasts" from a session into the
topic using my own header field with a client ID. The client ID is
generated by random from the client and forwarded to the SB in the
constructor of the SFSB.

Regards

Markus

From: Miroslav Nachev [mailto:miro@space-comm.com]
Sent: Freitag, 23. Mai 2008 11:30
To: users@glassfish.dev.java.net
Subject: Re: Re: How to invoke Client Callback Handler from EJB3 Session
Bean

Hi,

Thanks that somebody support me because the guys from Sun attack me so
embittered. I am fully agree with you and that was the reason to ask the
community how to get the session key (session id) with which to create a
map between the session and client. Do you know how to get the session
key when I am in some Stateful or Stateless bean?

Regards,

Miro.

On Fri, May 23, 2008 at 11:10 AM, Markus Karg wrote:

I did not follow the thread completely, but AFAIK the original problem
was that a session bean wants to asynchronously notify clients. "JMS
Temporary Queue" seems to be a great idea, indeed, but how shall the
session bean get that queue instance? Since the temporary queue gets
created by the client, and since nobody guarantees that the vendor's
implementation of the TemporaryQueue interface implements also the
Serializable interface, one cannot pass that instance to the session
bean. The samples in the JMS Tutorial only will work with MDBs since
they take the queue instance out the JMSReplyTo header field -- but that
approach is not possible here, since we do not have an MDB reacting to a
queue, but a SB reacting to a remote method call.

So how shall that work?

Thanks
Markus

-----Original Message-----
From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
Sent: Freitag, 23. Mai 2008 00:50
To: users@glassfish.dev.java.net
Subject: Re: How to invoke Client Callback Handler from EJB3 Session
Bean

The formal term is "temporary destination".

This is a link within the JEE 5 Tutorial briefly discussing them. Crawl
around from there to get the details.

http://java.sun.com/javaee/5/docs/tutorial/doc/bncfu.html#bncgb
[Message sent by forum member 'whartung' (whartung)]

http://forums.java.net/jive/thread.jspa?messageID=276183

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

[att1.html]

Miroslav Nachev

Hi,

In my opinion their position is so hardly because they are familiar with the
problem and because they don't want to solve it for some reason.

Regarding your current solution I was thinking in that way also, but I
decline it because of the big network traffic which will be produced to all
clients in the world (in my case in Bulgaria, because the clients will be in
the whole country).

Miro.
On Fri, May 23, 2008 at 12:36 PM, Markus Karg wrote:

> First of all, I do net see that anybody attacked you. They just tried to
> convince you that using JMS is the right approach, whereas callbacks just
> will not work.
>
>
>
> No, I do not know how the session ID can be obtain and just wait what the
> Sun guys will answer on my question how to obtain the temporary queue in the
> session bean. For an MDB, it is not a problem, but for SBs it seems to be
> pretty hard to do. Current in my app I just am using a global, persistent
> topic and do "broadcasts" from a session into the topic using my own header
> field with a client ID. The client ID is generated by random from the client
> and forwarded to the SB in the constructor of the SFSB.
>
>
>
> Regards
>
> Markus
>
>
>
> *From:* Miroslav Nachev [mailto:miro@space-comm.com]
> *Sent:* Freitag, 23. Mai 2008 11:30
> *To:* users@glassfish.dev.java.net
> *Subject:* Re: Re: How to invoke Client Callback Handler from EJB3 Session
> Bean
>
>
>
> Hi,
>
>
>
> Thanks that somebody support me because the guys from Sun attack me so
> embittered. I am fully agree with you and that was the reason to ask the
> community how to get the session key (session id) with which to create a map
> between the session and client. Do you know how to get the session key when
> I am in some Stateful or Stateless bean?
>
>
>
>
> Regards,
>
> Miro.
>
>
>
>
>
>
> On Fri, May 23, 2008 at 11:10 AM, Markus Karg wrote:
>
> I did not follow the thread completely, but AFAIK the original problem was
> that a session bean wants to asynchronously notify clients. "JMS Temporary
> Queue" seems to be a great idea, indeed, but how shall the session bean get
> that queue instance? Since the temporary queue gets created by the client,
> and since nobody guarantees that the vendor's implementation of the
> TemporaryQueue interface implements also the Serializable interface, one
> cannot pass that instance to the session bean. The samples in the JMS
> Tutorial only will work with MDBs since they take the queue instance out the
> JMSReplyTo header field -- but that approach is not possible here, since we
> do not have an MDB reacting to a queue, but a SB reacting to a remote method
> call.
>
> So how shall that work?
>
> Thanks
> Markus
>
>
> -----Original Message-----
> From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
> Sent: Freitag, 23. Mai 2008 00:50
> To: users@glassfish.dev.java.net
> Subject: Re: How to invoke Client Callback Handler from EJB3 Session Bean
>
> The formal term is "temporary destination".
>
> This is a link within the JEE 5 Tutorial briefly discussing them. Crawl
> around from there to get the details.
>
> http://java.sun.com/javaee/5/docs/tutorial/doc/bncfu.html#bncgb
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=276183
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>
[att1.html]

Markus Karg

The network traffic actually is not high: The message is put on the
topic with the client ID in the header. Each client has set the JMS
selector to this client ID. That means, *the server side* is filtering
*before* sending to the client. As a result, only that client that is
addressed will receive the message, all others, even listening on the
same topic, will not get bothered. So you can safely do that.

Regards

Markus

From: Miroslav Nachev [mailto:miro@space-comm.com]
Sent: Freitag, 23. Mai 2008 12:56
To: users@glassfish.dev.java.net
Subject: Re: Re: Re: How to invoke Client Callback Handler from EJB3
Session Bean

Hi,

In my opinion their position is so hardly because they are familiar with
the problem and because they don't want to solve it for some reason.

Regarding your current solution I was thinking in that way also, but I
decline it because of the big network traffic which will be produced to
all clients in the world (in my case in Bulgaria, because the clients
will be in the whole country).

Miro.

On Fri, May 23, 2008 at 12:36 PM, Markus Karg wrote:

First of all, I do net see that anybody attacked you. They just tried to
convince you that using JMS is the right approach, whereas callbacks
just will not work.

No, I do not know how the session ID can be obtain and just wait what
the Sun guys will answer on my question how to obtain the temporary
queue in the session bean. For an MDB, it is not a problem, but for SBs
it seems to be pretty hard to do. Current in my app I just am using a
global, persistent topic and do "broadcasts" from a session into the
topic using my own header field with a client ID. The client ID is
generated by random from the client and forwarded to the SB in the
constructor of the SFSB.

Regards

Markus

From: Miroslav Nachev [mailto:miro@space-comm.com]
Sent: Freitag, 23. Mai 2008 11:30

To: users@glassfish.dev.java.net

Subject: Re: Re: How to invoke Client Callback Handler from EJB3 Session
Bean

Hi,

Thanks that somebody support me because the guys from Sun attack me so
embittered. I am fully agree with you and that was the reason to ask the
community how to get the session key (session id) with which to create a
map between the session and client. Do you know how to get the session
key when I am in some Stateful or Stateless bean?

Regards,

Miro.

On Fri, May 23, 2008 at 11:10 AM, Markus Karg wrote:

I did not follow the thread completely, but AFAIK the original problem
was that a session bean wants to asynchronously notify clients. "JMS
Temporary Queue" seems to be a great idea, indeed, but how shall the
session bean get that queue instance? Since the temporary queue gets
created by the client, and since nobody guarantees that the vendor's
implementation of the TemporaryQueue interface implements also the
Serializable interface, one cannot pass that instance to the session
bean. The samples in the JMS Tutorial only will work with MDBs since
they take the queue instance out the JMSReplyTo header field -- but that
approach is not possible here, since we do not have an MDB reacting to a
queue, but a SB reacting to a remote method call.

So how shall that work?

Thanks
Markus

-----Original Message-----
From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
Sent: Freitag, 23. Mai 2008 00:50
To: users@glassfish.dev.java.net
Subject: Re: How to invoke Client Callback Handler from EJB3 Session
Bean

The formal term is "temporary destination".

This is a link within the JEE 5 Tutorial briefly discussing them. Crawl
around from there to get the details.

http://java.sun.com/javaee/5/docs/tutorial/doc/bncfu.html#bncgb
[Message sent by forum member 'whartung' (whartung)]

http://forums.java.net/jive/thread.jspa?messageID=276183

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

[att1.html]

ljnelson
Offline
Joined: 2003-08-04

> [att1.html]

Well, OK, I tried to help you out with an answer to your business problem, not your technical problem--that is, if the problem really is that a user doesn't supply enough information for a product selection and needs to be prompted for more information (color, size, etc.), then you absolutely want to do it as a result [i]of[/i] a method invocation (i.e. a return value). Really.

But since you seem to be more interested now in just the pure technology for technology's sake, yes, Markus is correct: JMS is the way that events are pushed around JEE, regardless of their direction (client to server or server to client).

Mind you, I stand by my assertion that that is the wrong solution for your business problem. It is however the way that servers notify clients--unbidden, usually for purely information purposes (a la UDP)--in the JEE world.

Here is the section in the JEE tutorial on JMS: http://java.sun.com/javaee/5/docs/tutorial/doc/bncdq.html

I hope this helps you out. I still think it's the wrong approach but you should be the one to evaluate that, of course.

Best,
Laird

Miroslav Nachev

[att1.html]

ewernli
Offline
Joined: 2007-10-21

Actually, we should stop speaking about client and server in this case. The client is by definition the caller and the server the callee. What you want is server-server communication. This is possible with RMI: the "client" can export a "notification" object when it starts. The "client" can then call the "server" and pass a remote reference of the "notification" object. The "server" can then broadcast event to all registered clients (It's maybe not exactly like this, but we do have such a solution for a RMI client-server application that need to be sometimes notified by the server side). But I fear that it's not possible with IIOP.

Miroslav Nachev

This sounds interesting but if this is not applicable for Java Web Start
where RMI-IIOP is used then what to do?

I think that the JMS solution is not suitable because:
1. The messages sent by server to each client MUST be unique. There is
no case where the server to send one message to many clients.
2. When the client session is destroyed all pending messages must be
destroyed also and no future messages to be applied. Is that a case for
synchronous messages?

Miro.

glassfish@javadesktop.org wrote:
> Actually, we should stop speaking about client and server in this case. The client is by definition the caller and the server the callee. What you want is server-server communication. This is possible with RMI: the "client" can export a "notification" object when it starts. The "client" can then call the "server" and pass a remote reference of the "notification" object. The "server" can then broadcast event to all registered clients (It's maybe not exactly like this, but we do have such a solution for a RMI client-server application that need to be sometimes notified by the server side). But I fear that it's not possible with IIOP.
> [Message sent by forum member 'ewernli' (ewernli)]
>
> http://forums.java.net/jive/thread.jspa?messageID=275025
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

ljnelson
Offline
Joined: 2003-08-04

> Everything is clear except how the Server side (EJB)
> will pass the
> parameters to the Client side.

Well, you surely wouldn't want the server randomly calling the client and popping up dialogs whenever it felt like it in this scenario. Bear in mind I know exactly what you're trying to do, and Tim is pointing you in the right direction.

You still want to do this as a return value from the server; trust me.

Think of it this way. You want extra information [i]as a reaction to[/i] the user entering too [i]little[/i] information. So the user supplies an ID, but didn't supply, say, color. Because of that you want the server to [i]return[/i] your client enough information so that it can ask your user for more. You don't want the server to push a dialog in the user's face--that kind of interaction should always be up to the client.

So here's your client pseudocode:
[code]
Result result = server.addProduct(incompleteInformation);
if (result != null) {
RequiredInformation infoUserNeedsToSupply = result.getRequiredInformation();
if (infoUserNeedsToSupply != null) {
// TODO: build JDialog; get information out of infoUserNeedsToSupply; show dialog
// TODO: when user closes dialog get user info
// TODO: re-call server method with new information
}
}
[/code]

Best,
Laird

Miroslav Nachev

[att1.html]

Markus KARG

I have not beeing following the thread right from the start, so sorry if
my answer is pointing in the wrong direction. But it reads as if you
just want to get notified of a server sided event. So why not just using
JMS?

Regards
Markus

Miroslav Nachev schrieb:
> Hi,
>
> I know what exactly you offer me but I don't want to do that because
> of many reason. Finally why to go round instead to solve the problems?
> Now I will try to see how this is solved in SailFin
> project because there they have
> similar problem I hope. It is when some body want to dial somebody and
> the server must notify the client for that. In this case the server
> must initiate the connection with the client and then the client to
> return the answer. This is by SIP protocol if you are familiar.
>
> Please tell me, why you do not want this to be realized? What is the
> reason? You offer somewhere as commercial future or what ?
>
> Will you give me some help how to connect to the client using ORB
> following GlassFish manner or not? If not, I will stop disturb you
> anymore. You try to do everything except to give me some directions
> how to solve the problem.
>
>
> Regards,
> Miro.
>
>
> glassfish@javadesktop.org wrote:
>>> Everything is clear except how the Server side (EJB)
>>> will pass the
>>> parameters to the Client side.
>>>
>>
>> Well, you surely wouldn't want the server randomly calling the client and popping up dialogs whenever it felt like it in this scenario. Bear in mind I know exactly what you're trying to do, and Tim is pointing you in the right direction.
>>
>> You still want to do this as a return value from the server; trust me.
>>
>> Think of it this way. You want extra information [i]as a reaction to[/i] the user entering too [i]little[/i] information. So the user supplies an ID, but didn't supply, say, color. Because of that you want the server to [i]return[/i] your client enough information so that it can ask your user for more. You don't want the server to push a dialog in the user's face--that kind of interaction should always be up to the client.
>>
>> So here's your client pseudocode:
>> [code]
>> Result result = server.addProduct(incompleteInformation);
>> if (result != null) {
>> RequiredInformation infoUserNeedsToSupply = result.getRequiredInformation();
>> if (infoUserNeedsToSupply != null) {
>> // TODO: build JDialog; get information out of infoUserNeedsToSupply; show dialog
>> // TODO: when user closes dialog get user info
>> // TODO: re-call server method with new information
>> }
>> }
>> [/code]
>>
>> Best,
>> Laird
>> [Message sent by forum member 'ljnelson' (ljnelson)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=274996
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net For
> additional commands, e-mail: users-help@glassfish.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Miroslav Nachev

[att1.html]

roisinflannery
Offline
Joined: 2007-05-08

Hi Miroslav,

Have you ever considered looking into getting a support contract with Sun? This would mean that you would have personalised help and advice on how to get the best out of your deployment. You would also have access to fully supported and tested sustaining patches containing fixes for recent bugs.

If you are interested, please go to the following link for more details:
http://www.sun.com/service/applicationserversubscriptions/index.jsp

or else, please feel free to reply to this thread and I will supply more information.

Kind regards,
Roisin
Sustaining Engineer, GlassFish

tjquinn
Offline
Joined: 2005-03-30

Hello, Miro.

The callback handler is invoked automatically by the app client container (on the client side) when authentication is needed to first access a guarded resource on the back-end (such as an EJB).

Once the EJB is running its business logic on behalf of the client, that authentication has already completed and there is no mechanism for the EJB itself to reactivate the callback handler to prompt for additional information.

I don't think I clearly understand what you are trying to accomplish. Is the EJB in question one that does not require authentication, and then as it runs does it discover the need to do some additional processing that does require authentication?

- Tim

Miroslav Nachev

Hi,

My target is not to do additional authentication. My target is to create
custom Callback Handle mechanism with which to retrieve additional
information related with some business process. For example if one session
bean calculate the needed products in one offer and there are some options
for color which is not specified preliminary. In that case the EJB3 session
bean need to ask the user with custom Swing Dialog form which color to use.

Regards,
Miro.

On Thu, May 8, 2008 at 2:33 AM, wrote:

> Hello, Miro.
>
> The callback handler is invoked automatically by the app client container
> (on the client side) when authentication is needed to first access a guarded
> resource on the back-end (such as an EJB).
>
> Once the EJB is running its business logic on behalf of the client, that
> authentication has already completed and there is no mechanism for the EJB
> itself to reactivate the callback handler to prompt for additional
> information.
>
> I don't think I clearly understand what you are trying to accomplish. Is
> the EJB in question one that does not require authentication, and then as it
> runs does it discover the need to do some additional processing that does
> require authentication?
>
> - Tim
> [Message sent by forum member 'tjquinn' (tjquinn)]
>
> http://forums.java.net/jive/thread.jspa?messageID=273230
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
[att1.html]

tjquinn
Offline
Joined: 2005-03-30

OK, thanks for clearing that up.

The callback handler is not the right approach for what you need to do. It's usefulness is limited to the authentication step before an access-controlled EJB is accessed in the first place.

You may need to rearchitect this part of your app. Here is one possible way, not necessarily the best but it would work.

Instead of thinking of having the EJB method call back to the client, think of the EJB doing two separate pieces of work: the part before when it would do the callback and the part it does after collecting the additional information. Then separate the EJB method into two different methods.

The first method invocation would accomplish the first part of the EJB logic and would return a value that tells your app client code whether it needs to collect more information from the user (and perhaps what information to collect). Then your app client logic would examine that return value to tell what to do. If more info is needed from the user, your app would display an additional window or a dialog to collect that information. Once the user enters that info your client could invoke a different EJB method that represents the second part of the work, the work you planned to happen after the callback returned in your original design.

Does that make sense?

- Tim

Miroslav Nachev

Hi,

Thank you very much. The problem is that the application don't know
preliminary from what information will need. That's why it is not
possible preliminary to ask the user for all possible questions.
I have another idea. During the application initialization to pass as
parameter the ApplicationCallbackHandler to the server and that value to
be stored in the session.

Regards,
Miro.

glassfish@javadesktop.org wrote:
> OK, thanks for clearing that up.
>
> The callback handler is not the right approach for what you need to do. It's usefulness is limited to the authentication step before an access-controlled EJB is accessed in the first place.
>
> You may need to rearchitect this part of your app. Here is one possible way, not necessarily the best but it would work.
>
> Instead of thinking of having the EJB method call back to the client, think of the EJB doing two separate pieces of work: the part before when it would do the callback and the part it does after collecting the additional information. Then separate the EJB method into two different methods.
>
> The first method invocation would accomplish the first part of the EJB logic and would return a value that tells your app client code whether it needs to collect more information from the user (and perhaps what information to collect). Then your app client logic would examine that return value to tell what to do. If more info is needed from the user, your app would display an additional window or a dialog to collect that information. Once the user enters that info your client could invoke a different EJB method that represents the second part of the work, the work you planned to happen after the callback returned in your original design.
>
> Does that make sense?
>
> - Tim
> [Message sent by forum member 'tjquinn' (tjquinn)]
>
> http://forums.java.net/jive/thread.jspa?messageID=273237
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

tjquinn
Offline
Joined: 2005-03-30

Hello, again, Miro.

I do not think the approach you suggested will work as you want. Although conceptually your idea is fine, in practice there will be problems. A reference to a normal Java object, which the callback handler implementation object is, cannot be passed to another JVM on another system, which the server is, and then be called back quite so simply, for a number of reasons. The most important one is that there would need to be logic in the client that would be able to receive incoming remote method invocations from the server. This is more complicated than the EJB on the server just invoking a method on an object passed from the client.

Such things are certainly possible but not automatic.

Also, I may not have been clear in my earlier comments. I was not suggesting that the client would ask the user all possible questions before invoking the first EJB method. Instead, the return value from the first method would somehow indicate what further information the client must collect from the user and then pass back to the server.

Or, perhaps the client does not know in advance what the possible set of questions might be In that case, you might want to consider this: If the client will not know in advance what questions to ask the user, perhaps you can define your own callback request objects and interfaces for the types of questions the server will want the client to ask the user. These would be conceptually similar to the security callback requests you are familiar with from the app client security callback model, but you would create the specific callback request types that the EJB and the app client would both use.

Returning to my earlier suggestion of splitting the original EJB method into two different ones, the first method could return an array (or List or some other type of collection) of your callback request types, depending on the specific pieces of information the EJB decided it needed from the user. The client could determine from the types of the callback requests returned by the EJB what questions - if any - to ask the user (perhaps the text for each question would be part of the callback request). Once the app client gathered the user's responses to those questions it would pas them back to the second method on the EJB.

Again, this might not be ideal but it may work for you.

- Tim

Message was edited by: tjquinn

Miroslav Nachev

Hi,

Everything is clear except how the Server side (EJB) will pass the
parameters to the Client side. Calling some Server method(s) from Client
side is easy. But how to initiate the opposite action? Are there any
examples how to initiate method call (or to pass some parameters) from
Server side to Client side. Are there any standard ways for that?

Regards,
Miro.

glassfish@javadesktop.org wrote:
> Hello, again, Miro.
>
> I do not think the approach you suggested will work as you want. Although conceptually your idea is fine, in practice there will be problems. A reference to a normal Java object, which the callback handler implementation object is, cannot be passed to another JVM on another system, which the server is, and then be called back quite so simply, for a number of reasons. The most important one is that there would need to be logic in the client that would be able to receive incoming remote method invocations from the server. This is more complicated than the EJB on the server just invoking a method on an object passed from the client.
>
> Such things are certainly possible but not automatic.
>
> Instead, you might want to consider this: If the client will not know in advance what questions to ask the user, perhaps you can define your own callback request objects and interfaces for the types of questions the server will want the client to ask the user. These would be conceptually similar to the security callback requests you are familiar with from the app client security callback model, but you would create the specific callback request types that the EJB and the app client would both use.
>
> Returning to my earlier suggestion of splitting the original EJB method into two different ones, the first method could return an array (or List, for example) of your callback request types. The client could determine from the types of the callback requests returned by the EJB what questions - if any - to ask the user (perhaps the text for each question would be part of the callback request). Once the app client gathered the user's responses to those questions it would pas them back to the second method on the EJB.
>
> Again, this might not be ideal but it may work for you.
>
> - Tim
> [Message sent by forum member 'tjquinn' (tjquinn)]
>
> http://forums.java.net/jive/thread.jspa?messageID=273277
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

tjquinn
Offline
Joined: 2005-03-30

In traditional Java EE applications the client side initiates the actions and passes arguments to the server. What comes back is a return value as with any normal Java method invocation. Servers do not call clients.

Because the server side does not call the client side but merely returns to it, there is (again, in the traditional model) no idea of "passing arguments" from the server to the client.

I'll try to "draw" the difference between your original idea and my suggestion. I'm sure the spacing will look bad but I think you will get the idea

Your idea:

Client.........................EJB
--- call methodM ------- >

<---- nested callback ------

[app client displays a dialog to get the additional info from the user]

--- return from nested callback -->

<--- return from first call --

In your idea, the "nested callback" would pass arguments that tell what added info to get from the user and the "return from nested callback" would return a single object as its return value that contains the added information the user supplied.

As I mentioned earlier the "nested callback" and "return from nested callback" are basically not a supported model in Java EE; servers cannot call clients.

Even in the approach you described, there are two parts to the EJB method: the part that runs before the (unsupported) nested call back to the client, and the part that runs after.

My suggestion is to do divide the EJB methodM into two separate methods, methodA and methodB.

Client ..................................... EJB
--- call methodA ----------------------->

<--- return

[ client displays a dialog to collect the new required information from the user ]

---- call methodB ----------------------->

<--- return ----------------------------------

In this approach the EJB's methodA returns a value is an object that indicates what further information is needed from the user. The app client uses that to display a dialog, collecting the required information. Then the app client invokes methodB on the EJB, passing the new information it just collected from the user.

I know this is not the approach you first had in mind, but I think it will meet your needs while also fitting the Java EE model in which the client calls the server and not the other way around.

Miroslav Nachev

Hi,

I don't know who is decided to restrict Java EE technology to have only
one direction connection (from Client to the Server like old Web/HTML)
but this is extremely stupidity. Before AJAX this was one big benefit
comparing with HTML technology and that benefit is removed by specification.

Can somebody help me how can design and develop custom client-side
callback mechanism for JNLP/Swing Clients? It is good to have similar
mechanism for Web AJAX/HTML Clients also.
At the moment in GlassFish there is login client-side callback mechanism
but I can not understand how works. I know that the used technology for
that is RMI-IIOP but I can not find in the source files for Server and
Client side where are the starting points which I can use as examples.
My need is just how from the server side to invoke client method. What
to do on the server side and how to listen on the client side for such
event.
Can you provide me any help?

When I am ready I would like to commit the code in GlassFish community
to be usable for all and to exists into the next GF releases. This will
be a big benefit comparing with the other Application Servers.

Regards,
Miro.

glassfish@javadesktop.org wrote:
> In traditional Java EE applications the client side initiates the actions and passes arguments to the server. What comes back is a return value as with any normal Java method invocation. Servers do not call clients.
>
> Because the server side does not call the client side but merely returns to it, there is (again, in the traditional model) no idea of "passing arguments" from the server to the client.
>
> I'll try to "draw" the difference between your original idea and my suggestion. I'm sure the spacing will look bad but I think you will get the idea
>
> Your idea:
>
> Client EJB
> --- call methodM ------- >
>
> <---- nested callback ------
>
> [app client displays a dialog to get the additional info from the user]
>
> --- return from nested callback -->
>
> <--- return from first call --
>
>
> In your idea, the "nested callback" would pass arguments that tell what added info to get from the user and the "return from nested callback" would return a single object as its return value that contains the added information the user supplied.
>
> As I mentioned earlier the "nested callback" and "return from nested callback" are basically not a supported model in Java EE; servers cannot call clients.
>
> Even in the approach you described, there are two parts to the EJB method: the part that runs before the (unsupported) nested call back to the client, and the part that runs after.
>
> My suggestion is to do divide the EJB methodM into two separate methods, methodA and methodB.
>
> Client EJB
> --- call methodA ----------------------->
>
> <--- return
>
> [ client displays a dialog to collect the new required information from the user ]
>
> ---- call methodB ----------------------->
>
> <--- return ----------------------------------
>
> In this approach the EJB's methodA returns a value is an object that indicates what further information is needed from the user. The app client uses that to display a dialog, collecting the required information. Then the app client invokes methodB on the EJB, passing the new information it just collected from the user.
>
> I know this is not the approach you first had in mind, but I think it will meet your needs while also fitting the Java EE model in which the client calls the server and not the other way around.
> [Message sent by forum member 'tjquinn' (tjquinn)]
>
> http://forums.java.net/jive/thread.jspa?messageID=273419
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net