Re: [Asterisk-java-devel] Asterisk-JAVA JEE JCA
Brought to you by:
srt
Menu
▾
▴
Re: [Asterisk-java-devel] Asterisk-JAVA JEE JCA
|
From: Conrad W. <ast...@co...> - 2009-05-08 20:12:44
|
Hi there, Well using the Live-API is what I was thinking... How about the thread-safety of "AsteriskServer" ? May I use the methods on a single instance from different threads simultaenously? Conrad On Thu, 2009-05-07 at 21:53 -0400, Martin B. Smith wrote: > Hi Conrad, > > > Do you think I am missing something there? > > Well, you're going to be in a world of hurt trying to write the > component that will do this kind of job, but I'd love to see it on top > of the Live API. > > I'd love to hear about or to see the results! > > Martin > > > > Conrad Wood wrote: > > 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 > >> > > > > > > ------------------------------------------------------------------------------ > > 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 > |
