[Wsf-general] Messaging project concept

[Paul Fremantle]

Our current Sandesha implementation doesn't support this kind of 
solution - yet.

Firstly, we don't have a separate process that can be run simply to 
deliver and manage the messaging interaction. So - for example - you run 
wsclient to deliver a message. Suppose the endpoint isn't up. wsclient 
doesn't run as a daemon. And if wsclient kept running, I don't think you 
could start a new wsclient and expect everything to run sweetly.

However, I think if you had a local engine running as an intermediary, 
the wsclient could deliver to that - get the acks, and then the engine 
could keep running to deliver the messages.

Secondly, I don't think we've really thought about the long-running case 
properly with Sandesha. For example, we don't have a mode where we will 
back off to a once a day attempt if the server is down for more than 12 
hours. Similarly we don't have any console or way of seeing what the 
status of messages is. We don't have a simple logger that only logs the 
delivery status of each message.

Basically, our messaging agent is designed to be run as a handler inside 
a SOAP engine and not as a standalone messaging engine. However, that 
isn't to say that we can't morph it to be that. I actually think there 
is a lot of mileage in the multi-process design that James has proposed. 
I think however, that we could still implement the multi-process design 
while re-using much of the web services code we already have.

However, I think that the concept - of selling a lightweight, Unix 
friendly, messaging engine has a lot of potential. In fact, it could fit 
the Presto case much better than what we are selling today.

Paul

Sanjiva Weerawarana wrote:
> Hi James,
> 
> First of all sorry for the delay in replying. I read the doc when u 
> first sent it but didn't get a chance to think thru it and reply.
> 
> Very interesting. I agree with most of it, but not the proposed 
> implementation plan .. as u probably expected :).
> 
> First of all, this would be a straightforward set of python scripts that 
> uses wsclient underneath. Obviously that won't support adding transports 
> with python etc. but it'll solve business problem: provide a tool to 
> move data from one machine to another. The intermediary would be a 
> straightforward configuration of the ESB. Are you actually suggesting 
> that we re-write SOAP/WS-Sec*/RM etc. all in Python?? I must be 
> mis-reading it.
> 
> It seems to me its key to figure out who the audience is. If its for 
> "users" to move files around, then we shouldn't expose things like 
> transport selection, endpoint selection etc. to them (as much as 
> possible). This feels like a solution that we'd be doing over our stuff 
> (like the identity solution): WSO2 Secure Messaging Solution. (BTW this, 
> I believe, is what we're doing with Zend in France.)
> 
> If the target is for developers to use to exchange data between machines 
> reliably then the UI would be different but not by much. Again I still 
> see it as a simple python script that uses wsclient underneath. Server 
> side would another python script that uses wsf/c with a thttpd type 
> embedded transport.
> 
> I won't answer the questions yet because it depends a lot on the 
> positioning.
> 
> Sanjiva.
> 
> James Clark wrote:
>> I've written up the concept for a new project/product focusing on
>> messaging functionality:
>>
>>  http://www.wso2.org/wiki/display/wsf/Telegon+Project
>>
>> This is based on some discussions Paul and I had in London.
>>
>> Comments are, as always, welcome.
>>
>> James
>>
>>
>>
>>
>> _______________________________________________
>> Wsf-general mailing list
>> Wsf-general at wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/wsf-general
>>
> 

-- 
Paul Fremantle
VP/Technology and Partnerships, WSO2
OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul at wso2.com
(646) 290 8050

"Oxygenating the Web Service Platform", www.wso2.com