Re: AW: Inbound / Outbound communication in JCA 1.5

On Wednesday, January 22, 2003, at 03:13 PM, Gyhra, Norman wrote:

> David,
>
> We have obviously misunderstood each other.
> I am aware that you need some form of multi-threading
> for a listener waiting for incoming calls.
> And yes, the Work Management Contract provides
> a handy mechanism to deal with multi-threading.
>
> However, my initial question had a different aim.
> See my reply to Jim.
>
> The problem that I see is that I don't know if
> an incoming call is synchronous or asynchronous

How can you not know this?  These have really different meanings, in  
particular in regards to transactions.  I would expect that by examing  
an EIS's documentation it would be quite clear what semantics are  
intended, so you could use the appropriate interfaces in the adapter.

> and the Message Inflow Contract seems to be clearly
> aimed at asynchronous messaging.

Agreed, it's principal feature over direct use of the work contracts is  
delivery of an asynchronous message inside a "delivery transaction".   
As such it is totally inappropriate for synchronous or "method call"  
semantics.  The work interfaces are useful for message delivery, but  
the transaction import and work interfaces are essential for  
synchronous/method call semantics.
>
> As a result, in case of a synchronous call
> the EIS is blocked because I have decided not to send
> a reply to the message for whatever reason.

Again, I don't see how you can get into the position of not knowing and  
having a choice about whether to return from a method call.

david

>
> Regards,
> Norman
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: David Jencks [mailto:[email protected]]
> Gesendet am: Mittwoch, 22. Januar 2003 21:01
> An: [email protected]
> Betreff: Re: AW: Inbound / Outbound communication in JCA 1.5
>
> On Wednesday, January 22, 2003, at 02:47 PM, Gyhra, Norman wrote:
>
>> Hi David!
>>
>>>> * Synchronous inbound:
>>>>   How can my J2EE application be synchronously called
>>>>   by an EIS through the Connector Architecture?
>>>
>>> Work interface/contracts. [...]
>>
>> As far as I have understood the purpose of the
>> Work Management Contract, it emulates multi-threading
>> for the resource adapter, which cannot spawn threads
>> by itself. The specification does not mention anything
>> about communication with the EIS.
>
> True enough, but I sure don't know how to write something that listens
> for e.g. socket messages and interprets them as ejb method invocations
> them without having at least one thread for the listener and a thread
> pool or factory for the execution threads, should you want concurrent
> execution of requests.  If your EIS already knows how to look up the
> desired ejb in jndi and use the remote and home interfaces, obviously
> you don't need an adapter for it to call ejbs.   Otherwise I think
> there are obvious advantages to running whatever does the translation
> from EIS-speak to ejb invocation in the app server jvm.  In this case
> the Work/WorkManager interfaces seem like the only spec-compatible
> choice to me.
>
> For a rather primitive and unfinished example of this (not in an
> adapter per se) look at the JBoss TrunkInvoker in cvs head (JBoss 4).
>
> david jencks
>>
>> It says on page 125:
>> "Goals:
>> * Provide a flexible work execution model to handle the
>>   thread needs of a resource adapter.
>> * Provide a mechanism for an application server to pool
>>   and reuse threads, and to exercise more control over thread
>>   behavior in a managed environment."
>>
>>
>> Regards,
>> Norman
>>
>> ====================================================================== 
>> =
>> ====
>> To unsubscribe, send email to [email protected] and include in the
>> body
>> of the message "signoff CONNECTOR-INTEREST".  For general help, send
>> email to
>> [email protected] and include in the body of the message "help".
>>
>
> ======================================================================= 
> ====
> To unsubscribe, send email to [email protected] and include in the  
> body
> of the message "signoff CONNECTOR-INTEREST".  For general help, send  
> email to
> [email protected] and include in the body of the message "help".
>
> ======================================================================= 
> ====
> To unsubscribe, send email to [email protected] and include in the  
> body
> of the message "signoff CONNECTOR-INTEREST".  For general help, send  
> email to
> [email protected] and include in the body of the message "help".
>

==========================================================================To unsubscribe, send email to [email protected] and include in the body
of the message "signoff CONNECTOR-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".