Re: [Asterisk-java-devel] Asterisk-JAVA JEE JCA

[Conrad W. <ast...@co...>]

Hi Martin,

thanks for your reply - good stuff. I agree the threading issue is only
part of the problem, particularly because - as you know - jboss is
rather 'tolerant' on this issue.

I have thought about the various ways of communicating with the asterisk
manager api too and came to the same conclusion as you did (even though
I couldn't have said it as concise as you did!)


The two-communication is perfectly well suited for the JCA Architecture
as it defines inbound and outbound channels, so I expect little trouble
there.

I thought of taking the route of creating a session bean which is feed
information by the JCA.
Thus the session bean would 'know' the asterisk state at all times, e.g.
which queues and channels are active and who's registered etc.
Therefor one can query the session bean for this sort of information at
any given time. 
Secondly, I would like to trigger certain actions via a session bean
too. I reckon most of the actions are either "fine" to be done
asynchronously (still unsolved is how a 'delayed' error sent by asterisk
could be propagated to the EJB-Client) or have such a quick reply that
it could be done fake-synchronously (as in: the JCA waits for the reply
before returning to the caller)
Do you think I am missing something there?

At the end I would like to have a perfectly integrated easy-to-use
SessionBean interface to asterisk. I also intend to create an interface
(perhaps EntityBeans) to asterisk-realtime databases.

Admittedly I am not a very good graphical interface designer, but I if I
can create a good java-like JEE interface it'll be much, much simpler
and quicker to come up with some cool gui tools and reports for
asterisk.


Conrad




On Wed, 2009-05-06 at 21:17 -0400, Martin B. Smith wrote:
> Hi Conrad,
> 
> > I figured I could create a JCA which connects to asterisk
> > and forwards the events to a Bean.
> 
> Let me first say I have not used the Java Connector Architecture as it
> stands today. It rings a JDBC bell in my head, but it seems that the
> spec has dramatically broadened itself from what I remember JCA meaning
> in the past.
> 
> Secondly, I've combined JBoss with Asterisk, and I wrote the FAQ entry
> related to hosting AGI scripts in JBoss. I've also implemented many
> AMI-related solutions that end up tieing into JBoss.
> 
> > and forwards the events to a Bean.
> > However, when I login with a ManagerConnection it starts a new Thread.
> > On the JCA I got the worker-thread already so it mustn't start it's own.
> 
> Regardless of the threading issue, there's something much more basic
> about the Manager interface that (for me) ran afoul of tieing any beans
> to the Manager interface. The Manager interface is:
> 
>  (a) two way communication
>  (b) a source of events
>  (c) loosely session based (via lots of XxxCompleteEvent)
> 
> When I looked how this "should" integrate with JBoss, I considered:
> 
>  (1) JMS beans (both topic and queue)
>  (2) Session beans
>  (3) Data-oriented beans
> 
> In my opinion, (1) and (2) didn't work because of the loosely
> session-oriented communication in the AMI (things like the actions that
> cause a stream of data events followed by a complete event), and even if
> you could wrap some basic session around an event-sequence in order to
> figure out where it should go on the Java client side, sometimes you did
> want to do more than just respond to events -- you want to perform
> actions. Finally, (3) didn't make a lot of sense because it forces the
> data (2-way events and actions) to fit a model (call -> return value)
> that doesn't make sense, making it hard to write code for and support.
> 
> In the end, I chose to keep the Manager interface between individual
> clients and Asterisk, outside of the J2EE environment; in my case, this
> worked, simply because only a *very* small percentage (like 2 out of
> every 100) needed the Manager functionality.
> 
> In closing, I think you'll find it absolutely acceptable to keep the
> Asterisk-Java threading model. J2EE developers are cautioned about how
> they shouldn't think in a multithreaded way about Java Beans -- but
> you're not developing an app here, you're creating a new component in
> the JBoss 'microkernel,' so I think you should let A-J do its own
> threading. You may consider implementing a JMS endpoint that maps
> clients to Manager sessions, identifying which actions are and aren't
> related to a session, sharing some manager connections and
> single-purposing others.
> 
> Hope that helps with your question,
> 
> Martin Smith
> ma...@mb...
> 
> 
> Conrad Wood wrote:
> > Hi there,
> > 
> > I would like to use the asterisk manager interface from my JBOSS
> > application. I figured I could create a JCA which connects to asterisk
> > and forwards the events to a Bean.
> > However, when I login with a ManagerConnection it starts a new Thread.
> > On the JCA I got the worker-thread already so it mustn't start it's own.
> > I pondered over some solutions, including subclassing
> > ManagerConnectionImpl and overriding connect() - but that seems somewhat
> > dirty. 
> > Of course, the JCA shall be open to the public and perhaps part of the
> > asterisk-java distribution if so desired, so it should be somehow more
> > integrated.
> > Does anyone have any comments on how I should proceed here?
> > 
> > Conrad
> > 
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> > production scanning environment may not be a perfect world - but thanks to
> > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> > Series Scanner you'll get full speed at 300 dpi even with all image 
> > processing features enabled. http://p.sf.net/sfu/kodak-com
> > _______________________________________________
> > Asterisk-java-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel
> 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Asterisk-java-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-devel
>