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

[Samisa Abeysinghe]

Sanjaya Karunasena 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?
>  
>
In Axis2/C transport have two forms of operation - service and client. 
The current XMPP transport has focused on client side of operation - 
sending a request payload and receiving a response payload. In there, 
there is no dispatching involved - in other words no need to locate a 
service and operation - the client know them in advance. On server side, 
the picture differers a bit - we have to deal with the transport and 
pick up information that helps us to locate the service and operations. 
In addition, we are also operating inside some server (e.g. Apache2 
server), so we need to figure out how we deploy our services with that 
server.

The best examples with current Axis2/C implementation are the libcurl 
based client transport and Apache2 based server transport. Our current 
implementation of XMPP is analogous to libcurl based client transport. 
Now what I am trying to understand is that how to implement an XMPP 
server transport analogous to Apache2 server transport, that helps us to 
host services with an XMPP server.

To put the question in other words, do we want to host services with an 
XMPP server - do we want a mod_axis2 equivalent for an XMPP server?

Thanks,
Samisa...

>Sanjaya
>
>On Thursday 05 April 2007 10:14, Asankha C. Perera wrote:
>  
>
>>Samisa
>>
>>As far as I know Ishan had already thought through most of these issues
>>when he developed the XMPP transport support to Axis2-C that we already
>>have. Also the XMPP server to be used *will* be the one being developed
>>by Jabber for ML with kerberos support and we will have to stick to its
>>API's and these may have some variations from jabberd. I do not quite
>>understand the current discussion on the XMPP implementation.. and why
>>we are talking about things like dispatching at this point in time..  I
>>will talk with Sanjaya and you on this.
>>
>>asankha
>>
>>Samisa Abeysinghe wrote:
>>    
>>
>>>I was Googling a bit to understand and figure out how to support XMPP
>>>server side transport.
>>>Here are some thoughts.
>>>
>>>First, I was initially under the impression that with XMPP server side
>>>transport, a service would be a 'chat room'. However I have to change my
>>>mind, because in the context of Axis2 architecture, a service is an
>>>implementation of some processing with XML as input and XML as output in
>>>AXIOM format. Hence with an XMPP server, we have to have a mechanism to
>>>'dispatch' an incoming request to a service that implements the
>>>svc_skeleton API. Hence the key problem that we have to solve is:
>>>        How can we dispatch (that is identify the service and operation)
>>>an incoming request to our service? I hope we can use the same
>>>dispatching mechanisms that we have in the Axis2 engine; however we have
>>>to figure out how to interface that with the XMPP server API
>>>
>>>Jabber has a concept of "components". Some Jabber components can be
>>>found in [1] and [2]
>>>[3] defines protocol for external components. In my understanding, what
>>>we need is an internal component. [3] mentions internal components, but
>>>there does not seem to be a formal spec on that. Basically we have to
>>>use the internal API of the server we are going to use. I also found JCR
>>>[4]. " The Jabber Component Runtime *JCR* is the first attempt at making
>>>"C" language components built for the *jabberd 1.4* code base able to
>>>run as standalone processes". Standalone process sounds appealing as
>>>that would solve our dispatching problems - we could run simple axis
>>>server and interface it to XMPP server. We may have to do a POC and see
>>>if we can use JCR with Axis2/C.
>>>
>>>Obviously this area needs some research work - so we need someone to
>>>play around with these libs.
>>>
>>>Thanks,
>>>Samisa...
>>>
>>>[1] http://www.jabberstudio.org/project/?cat=6
>>>[2] http://www.jabber.org/software/components.shtml
>>>[3] http://www.xmpp.org/extensions/xep-0114.html
>>>[4] http://jabber.terrapin.com/JCR/
>>>
>>>
>>>_______________________________________________
>>> mailing list
>>>@lists.wso2.com
>>>https://www-lk.wso2.com/cgi-bin/mailman/listinfo/
>>>      
>>>
>>_______________________________________________
>>Wsf-c-dev mailing list
>>Wsf-c-dev at wso2.org
>>http://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev
>>    
>>
>
>
>
>  
>