Hi Paul,
Please see my comments below.
Thanks,
Jaliya
----- Original Message ----- From: "Paul Fremantle" <[EMAIL PROTECTED]>
To: "Jaliya Ekanayake" <[EMAIL PROTECTED]>
Sent: Monday, June 16, 2008 11:40 AM
Subject: Re: Policy or other extensions to indicate persistent messaging
Jaliya
My idea is that the persistence is a feature that the admin can turn on
or
off per service.
So I agree that it is a good feature to turn it on and off per
service, and that we support today. So for this model, what I am
proposing adding is the ability for the server to advertize that it
supports that.
If it is to be per sequence, I think it will over
complicate the handshakes.
It will *complicate* the handshakes :) I agree. I think to say it
over-complicates the handshake is a subjective idea.
I agree.
Also, Sandesha should not impose restrictions to the clients based on
their
persistence settings.
I don't agree. WSRM imposes plenty of restrictions on the client and
server. It is perfectly possible for a server to refuse to communicate
with a client that does not support RM. With WSRM 1.1 It is possible
for clients to demand that the server creates an association between
the sequence and a security session.
If the server supports persistence but the client doesn't, then there
is no overall guarantee of reliability. So I believe that it ought to
be *possible* for a server to send CreateSequenceRefused if it
*requires* persistence and the client cannot provide it. Of course
that should be configured by the server. Similarly the client should
be able to demand (like a mustUnderstand) that the server provides a
persistent capability.
Why do I want this? Almost every customer I talk to says that WSRM
without persistence is basically pointless.
I totally agree with this. Without persistance, I can almost trust TCP
for
the reliability. (not for the multi-transport multi-hop cases)
So we need persistance for *real* use cases.
The blogging from people
who believe that WSRM should not support persistence has - in my view
- been very harmful to the adoption of the spec. Now the normal
argument is that "you can support persistence if you need it". But
frankly, that is a weak argument, because in a real distributed SOA
you cannot (at the moment) know if there is persistence involved,
except maybe by phoning up the sysadmin at the other end. So if you
require proper persistent reliability then you need a way of agreeing
between both parties that it exists. Now WSRM has the perfect model
for this negotiation - the CreateSequence/CSResponse. This ability to
negotiate details is perfect for this, and I don't see any problem
extending it to support this.
I agree that the Client should be able to request persistence from a
Service, but I still don' t understand why we need the server to reject a
client if it does not support persistence.
Here is a scenario.
Say we have two companies A and B that perform some communications over
snail mail.
All the mails received by the company B first go through its mail
processing
system (MPS) which keeps information on all the mails received, and also
keeps a copy of them.
All the mails sent by the company B also go through the same MPS.
Company A is not that sophisticated in its operations. They don't simply
have a system as above.
Now consider the communications that could happen.
1. A sends a mail to B
If this reach B, things are fine.
If this does not reach B then it is a problem of A. A should keep a copy
so
that it can send it again.
2. B sends a mail to A as a response to A's request
If this reach A and processed by A things are fine
If this reach A but not processed by A, then B can send it again. (up to
some number of times)
If this does not reach A, B can still send it again.
3. B needs to send a mail to A requesting something. (Now A is the
service
provider)
In this case B can request that A provides the necessary reliability to
its
requests.
If A does not support it, B should not proceed.
Therefore, IMO the client does not need to have a real persistence to use
a
service offered with persisted reliability, but it can request this
feature
from the service.
Let me know your thoughts. probably I have missed some use case.
Thanks,
Jaliya
Say, the server supports persistance. In that case, any request sent by
the
client is guranteed to be served.
Paul
, but we can advertise that we have persistence for this
service.
Thanks,
Jaliya
----- Original Message ----- From: "Paul Fremantle" <[EMAIL PROTECTED]>
To: "Danushka Menikkumbura" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Monday, June 16, 2008 8:12 AM
Subject: Re: Policy or other extensions to indicate persistent
messaging
Danushka
I'm not clear I understand your point.
Firstly, I was just using AMQP as an example - I didn't mean that we
wanted to be exactly the same as AMQP or do anything with AMQP.
So firstly, in general, I don't believe that Sandesha2 can modify the
persistence on a sequence by sequence basis - either it is on for a
service or off. However, logically the sequence *is* the level at
which persistence can be defined. So these are the options I see:
* The server has persistence set permanently on for a service. It does
not demand persistence from the client. It publishes a policy saying
persistence is optional for the client. It accepts any sequence
creation, and persistently stores messages. If the client "asks for
persistence" during the create sequence, then it says "yes I'm
persistent in reply" (by some yet to be determined mechanisms). This
is how we operate today, except with the addition of the policy and
the optional information passing during create sequence.
* The server has persistence set permanently on for a service. It
demands persistence from the client. Therefore it publishes a policy
saying that client's must be persistent. During the CreateSequence
exchange, it can refuse any client that doesn't agree (by some
yet-to-be-defined mechanism) to be persistent. This would be a new
capability.
* The server has some clever ability to turn persistence on or off
per-sequence based on the create sequence. In this model, the server
picks up the preference from the client. So the same service might
have some persistent and some non-persistent sequences. Maybe this is
overkill and beyond the basic requirements. I'm not clear. However,
this seems to be a model that other systems allow. Of course, a server
could respond that it doesn't support this capability.
Ideally, all of this would be designed to allow backwards
compatibility. So even in the cases where the server refuses a
sequence because it requires persistence and the client doesn't
support this extension, the failure is explained in the error and the
administrator can see why.
Paul
On Mon, Jun 16, 2008 at 12:20 PM, Danushka Menikkumbura
<[EMAIL PROTECTED]> wrote:
1) A policy element to indicate whether this endpoint supports
and/or
requires persistence
(b) Even if we go for transport level persistence, the endpoint
does
not
have a say in it, because in AMQP we can have either queue level
persistence
(i.e. transport receiver level abstraction) or message level
persistence
(i.e. message sender level abstraction).
Hi Paul,
But still this is not doable with AMQP.
Danushka
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
