Thread: [Asterisk-java-devel] Asterisk-JAVA JEE JCA
Brought to you by:
srt
Menu
▾
▴
asterisk-java-devel
|
From: Conrad W. <ast...@co...> - 2009-05-06 20:52:03
|
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 |
|
From: Richard H. <ri...@ha...> - 2009-05-06 20:54:41
|
From what I read it seems that the answer is listed in the FAQ http://asterisk-java.org/development/faq.html It is a common question which occurs frequently on this list Regards Richard 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 > |
|
From: Conrad W. <ast...@co...> - 2009-05-06 20:59:43
|
I have read this, of course, and as far as I understood this is about AGI - and thus has nothing to do with my Question. Or am I missing something? On Wed, 2009-05-06 at 21:54 +0100, Richard Hamnett wrote: > From what I read it seems that the answer is listed in the FAQ > > http://asterisk-java.org/development/faq.html > > It is a common question which occurs frequently on this list > > Regards > > Richard > > 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 > |
|
From: Richard H. <ri...@ha...> - 2009-05-07 00:33:07
|
Sorry, I was skimming and I was certain I saw AGI and JBOSS and jumped to conclusions :P Conrad Wood wrote: > I have read this, of course, and as far as I understood this is about > AGI - and thus has nothing to do with my Question. > Or am I missing something? > > On Wed, 2009-05-06 at 21:54 +0100, Richard Hamnett wrote: > >> From what I read it seems that the answer is listed in the FAQ >> >> http://asterisk-java.org/development/faq.html >> >> It is a common question which occurs frequently on this list >> >> Regards >> >> Richard >> >> 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 > |
|
From: Martin B. S. <ma...@mb...> - 2009-05-07 01:17:30
|
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 |
|
From: Conrad W. <ast...@co...> - 2009-05-07 22:16:30
|
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 > |
|
From: Stefan R. <ste...@re...> - 2009-05-07 22:53:44
Attachments:
signature.asc
|
Conrad, Sounds interesting. My experience with JCA (and CCI which you won't probably use) is also a bit dated, so it may be that JCA in our days is indeed a good fit. Your information regarding inbound and outbound channels sounds promising. If you are going to take the route for the session bean based interface it would be great if you could leverage our live API which already defines abstractions for basic Asterisk concepts like channels, queues and the like. This will hopefully save you some work compared to the plain Manager API approach. Best regards and keep us informed, Stefan -- reuter network consulting Neusser Str. 110 50670 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: ste...@re... Jabber: ste...@re... WWW: http://www.reucon.com Steuernummern 215/5140/1791 USt-IdNr. DE220701760 |
|
From: Martin B. S. <ma...@mb...> - 2009-05-08 02:21:11
|
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 |
|
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 > |
|
From: Martin B. S. <ma...@mb...> - 2009-05-09 19:14:22
|
Hi Conrad, Stephan did a ton of work on the Live API that should thread safe, specifically the AsteriskServer and ChannelManager implementations. We'd welcome bug reports if you find things that aren't. Martin Conrad Wood wrote: > 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 >> > > > > ------------------------------------------------------------------------------ > 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X