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

[Sanjaya Karunasena]

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.

Thanks
Sanjaya
-- 
Senior Software Architect
WSO2 Inc. www.wso2.com
"Oxygenating the Web Service Platform."
==================================================
“Opportunity is missed by most people because it is dressed in overalls and 
looks like work.”
- Thomas Edison