[Wsf-general] Messaging project concept

[Sanjiva Weerawarana]

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

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

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

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

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

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.

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

> 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? 
Let's take this to a non-public forum as we can't discuss customer stuff here.

Sanjiva.
-- 
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
email: sanjiva at wso2.com; cell: +94 77 787 6880; fax: +1 509 691 2000

"Oxygenating the Web Service Platform."