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

[Martin B. S. <ma...@mb...>]

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