[Wsf-general] Messaging project concept

[Paul Fremantle]

My responses inline

Sanjiva Weerawarana wrote:
> Paul Fremantle wrote:
>> Our current Sandesha implementation doesn't support this kind of 
>> solution - yet.
> 
> Have you made these suggestions on sandesha-dev? If not why not??

Because this hasn't been the target for Sandesha. I'm not saying that 
this approach shouldn't be a target for Sandesha. On the other hand you 
could see this as an extension that goes beyond the aims of Sandesha.

>> 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.
> 
> Of course not Paul. But that's a *trivial* thing to do if that's what we 
> want to do .. we can run Sandesha as an endpoint manager by having a 
> transport that drops messages to a queue (database, filesystem, 
> whatever) and have another process pick it up and delivers them reliably.

I never said it wasn't trivial.

> Why have we not done it? No one asked for it yet.

Er. Yes. That was the whole point of my note. I'm not clear why you are 
arguing with me.

>> 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.
> 
> Piece of cake.

+1. I agree with you we can do this simply and we should.

>> 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 
> 
> Come on; is that a serious problem for us to implement an exponential 
> backoff on the sending logic?? Its trivial.

We have exponential backoff. I think we need something a little more 
configurable to support real-life scenarios. Again I didn't say it 
wasn't trivial to implement.

> Just because we haven't done a specific thing is not a reason to dismiss 
> the whole thing. Let's not throw the baby out with the bathwater.

You are reading something into my note that I didn't write. I never 
suggested dismissing Sandesha or our code.

Where on earth did you get the idea that I'm suggesting throwing out 
*any code* at all. My note was simply highlighting areas we need to 
develop from our current codebase to meet the proposed use-case.

In common English usage if you write:

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

then the word "yet" that implies that it can be made to do that.

Similarly see this comment I made later in the note:

 >> However, that isn't to say that we can't morph it to be that.

>> 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.
> 
> Again, piece of cake. We have an API for checking status of Sandesha- 
> all we'd need is a command line tool to drive that API. What's hard 
> about it??

Again I didn't say it was hard, I merely said we hadn't done this so far.

>> 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.
> 
> +1. All it takes is a few custom transports to decouple the pieces into 
> multiple processes.
> 
>> However, I think that the concept - of selling a lightweight, Unix 
>> friendly, messaging engine has a lot of potential. 
> 
> +1.
> 
>  > In fact, it could fit
>> the Presto case much better than what we are selling today.
> 
> How does that reconcile with doing that work with our current partner? 

I think we should implement the first prototype of this in PHP thereby 
making it available with a web UI to them.

Paul

-- 
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