[wsf-c-dev] Re: [] XMPP server side transport

[Damitha Kumarage]

Sanjaya Karunasena wrote:

>On Thursday 05 April 2007 16:37, Damitha Kumarage wrote:
>  
>
>>>What if think about this like this. A transport is an abstract entity
>>>which is been used by the server and the client both to send messages to
>>>each other.
>>>
>>>With that, HTTPTranport is a Transport, TCPTransport is a Transport,
>>>XMPPTransport is a Transport.
>>>
>>>So now the problem is pushed down to a level where we only need to worry
>>>about delivering a message from A to B. HTTP can do that, TCP can do
>>>that, XMPP can do that too.
>>>
>>>When I want to chat with some one I have mention the jabber ID of that
>>>individual so that jabber can find the end point to deliver the message,
>>>like in HTTP we have to tell an URL or in TCP IP:PORT.
>>>
>>>So then the question is how much do we have of such a XMPP transport at
>>>this point?
>>>
>>>Does this make sense with the current Axis-C design?
>>>      
>>>
>>What Ishan has implemented is a xmpp client transport which enable us to
>>expose a axis2 serivce
>>as following
>>
>>    chat_client ---------------------->jabber
>>server------------------------->axis2_service
>>                      <---------------------
>><-----------------------
>>In testing scenario we type a soap message in the chat window which is
>>wrppaed in the xmpp message body and sent to the jabber server.
>>axis2_service will receive this(as a chat client) and
>>using xmpp client transport(implemented using iksemel as parser) extract
>>the soap message and pass to the axis2c engine. Then the response from
>>the service is again wrapped inside the xmpp message and sent back to
>>the chat client.
>>AFAIK this is what ishan has implemented as xmpp client transport. I
>>think to enabling the required scenario what we need to do is
>>axis2c_client ---------------------->jabber
>>server------------------------->axis2_service
>>                     <---------------------
>><-----------------------
>>
>>I think this involve relatively easy work since ishan has implemented
>>and tested the first scenario.
>>
>>So we can get rid of implementing a xmpp server transport which will be
>>a tedios task.
>>
>>Damitha
>>
>>
>>_______________________________________________
>>Wsf-c-dev mailing list
>>Wsf-c-dev at wso2.org
>>http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
>>    
>>
>
>So I believe this means we can refactor what ishan has implemented in to an 
>API which enables both client side and server side XMPP communication. The 
>important point here is as far as the jabber server is concerns both the 
>webservice client and the service are clients.
>
>Meaning this approach would enable us to make use of publicly available jabber 
>servers to do the message transmission for us with what ever the QoS provided 
>by jabber.
>
>Also the existing call back mechanism available in the jabber API 
>("OnMessage") can be utilized to seamlessly implement the event notification 
>endpoint in eventing.
>  
>
Actually onMessage and onPresensce are implemented at the xmpp transport
level. Savan handlers invoked after the control pass to the axis2c 
engine should
do the job.

Damitha