axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chamil Thanthrimudalige <cha...@opensource.lk>
Subject Re: [Axis2] REQUEST_URI in mail transport
Date Thu, 17 Mar 2005 10:47:11 GMT
hi,

If more than one email address is used then how will the server side 
code [Listening Thread] operate?

In that case when the Listener starts up the email addresses and details 
[i.e. user names, passwords, server, etc.]  should have to be retrieved 
from the services [?!]. And then it has to pole multiple email 
addresses. I guess on the mailet scenario this will not be a problem, 
but if some one wants to use a generic mail server to setup a service 
then that will be a problem in my opinion [at least :) ].

Best Regards,
Chamil Thanthrimudalige.

Ajith Ranabahu wrote:

>Hi,
>Yes I agree that this is a broader issue than just the SOAPAction. The
>algorithm you suggest seems to be fair enough for service resolution.
>However I suppose we should look more into what others are doing
>(afterall its not only axis  that is there in the world :)) and decide
>the alternate branches of our service/operation resolution algorithm
>depending on that.
>
>
>On Thu, 17 Mar 2005 15:42:04 +0600, Srinath Perera <hemapani@gmail.com> wrote:
>  
>
>>Let me extend the Q bit .. as it is not only the SMTP that bring the Q
>>
>>At the web services we need to identify  two things
>>1) Service Name
>>2) Operation name
>>
>>to obtain the information we have the following
>>1) To address, (if the address not presents the request URI for HTTP
>>and the mail address for the SMTP case )
>>2) SOAP actions
>>3) if rpc-* or doc-literal-wrapped from the SOAP message
>>
>>we want to handle this for (at least) SMTP & HTTP
>>each of these can have a separator to have two information. I purpose
>>the following algorithm to
>>
>>1 try to get the service name from the To address.. that is basically
>>find string $A in the To address that Marches the patters
>>*/services/$A
>>2.1 if 1 is success,
>>       if (style == rpc || wrapped){
>>             find the operation from the Envelope
>>       }
>>       if(style == doc){
>>             pick the operation name from the SOAPAction
>>       }
>>2.2. if 1failed, try to pick up the service from the SOAP action. Then
>>the style must be rpc or doc literal wrapped as no way to find
>>operation
>>
>>Does the algorithm is fair enough?
>>
>>few issues are
>>1) do we need escape characters in the to addess or the SOAPAction to
>>let one entry have two information?
>>2) Are going to use the things like NSURI of the firat element to
>>locate service/operation
>>3) do we need configuration support to change the order of the things
>>taking the precedence.
>>
>>thoughts
>>Srinath
>>
>>On Thu, 17 Mar 2005 14:54:52 +0600, Chamil Thanthrimudalige
>><chamil@opensource.lk> wrote:
>>    
>>
>>>hi all,
>>>
>>>Well let me start by telling how I have setup the mail transport code
>>>for the time being. [Currently working on a maillet that can work with
>>>James.]
>>>
>>>There is a poling thread that listens to a specified mail address and
>>>when a mail comes to that address it will be fetched; broken down;  MC
>>>made and this MC will be used to call the engine.receive(MC) method.
>>>
>>>My problem is that since it is required to set a REQUEST_URI (which will
>>>be used to find out the service that should be called) before calling
>>>engine.receive(MC), what can I use to set this?
>>>
>>>Using the email address might cause a problem because then for different
>>>services the mail listener will have to listen to many email address.
>>>Before the current change I set the service using a value stored on the
>>>mail header.
>>>
>>>Best Regards,
>>>Chamil Thanthrimudalige.
>>>
>>>      
>>>
>
>
>  
>


Mime
View raw message