Hi Bernd
Hmmm.... also with plain WS-Addressing the URI would be the same, right?
I meant that if contexts are used then a client would access AccountService
only through a single uri like http://host/accounts
ever, passing account ids in the request headers, as opposed to
http://host/accounts/1, http://host/accounts/2, etc
I've just realized that it (using http://host/accounts) perhaps not that great
at all, given that individual accounts will lose the
linkability property...so I probably don't like it that much now :-).
If the client will get the same URI after the server restart then the idea of a
single Account WebService endpoint, with a stem
context matching, thus handling URIs like account/1, account/2, etc, seems quite attractive :-). IMHO the URI should stay the same
after the restart.
Maybe I don't get WS-Context correctly, I'll have to do some reading :)
This is one of the links :
http://www.w3.org/2007/01/wos-papers/redhat
Maybe you are going already one step further and you want to have some sort of
cluster of servers with shared application state? Then WS-Context seems to make
a lot of sense.
I personally like WS-Context and perhaps it's where it can be used sucessfully too. My understanding is that it's targeted as the
base buidling block at handling distributed activities where the same activity spans multiple services, etc. So perhaps it can excel
at working with the shared application state too... This makes me wonder whether it's actually best suitable for modelling
application level activities like accessing an individal account by submitting a non URL context (account id) in a header or not as
individual accounts don't get their unique URLs. Possible answer is that it depends upon requirements, etc...
Cheers, Sergey
P.S. Sorry for reordering fragments from your email in my reply :-)
----- Original Message -----
From: "Bernd Schuller" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, March 23, 2007 1:31 PM
Subject: Re: Support for stateful services in CXF
Hi Sergey,
Sergey Beryozkin wrote:
Hi Bernd
[....]
I just feel that with WS-Context (or with approach advocated by that spec) you
can preserve the familiar factory-instance
relationship, both at the server and the client
sides, but the advantages you'd get is :
* server resource consumption is obviously under more control - just one
Account instance, seems pretty important when the large
number of accounts are there...
Agreed. However you don't have to keep things in memory, the instance could be
created (e.g. retrieved from a database) just for the duration of the request.
* client-side : what happens when the individual account/server goes down and
get restarted from the client perspective holding
to a
reference with uri to the individual account ? If after the restart the
individual account gets mapped to the same uri then it's
fine
Right, you have to guarantee that individual instances don't change their
"identity"
when restarting. You can achieve this by having a persistence layer.
Maybe you are going already one step further and you want to have some sort of
cluster of servers with shared application state? Then WS-Context seems to make
a lot of sense.
Perhaps, if we look at this slightly differently, using WS-Context would
formalize this one possible approach. But from the
application perspective, noone prevents people from creating one BankService,
one AccountService with a stem match (as Gary
pointed
out), have BankService returning multiple EPRs/or just plain URLs all leading
to the same Account instance...
Where I see the advantage of using the context (passing it through the header)
is that from the client perspective the Account
URI is always the same, and this may pay benefits when restarting, possibly
simplify the persistence issues on both sides, etc
Hmmm.... also with plain WS-Addressing the URI would be the same, right?
Maybe I don't get WS-Context correctly, I'll have to do some reading :)
Best regards,
Bernd.
thanks for your reply. The way you describe it, WS-Context goes into a similar
direction.
IMO it does not matter much if you have a single instance or many instances of
a stateful service,
it's just a matter of taste and modelling preference.
Sergey Beryozkin wrote:
What would be your opinion about investing the dev effort into WS-Context ?
Prehaps the high-level purpose of that spec is not
to
deal with bank-account scenarious but the idea would be the same in that the
account id will be an application-level *context*,
passed as a header, for example.
The advantage is that there will be one Account instance ever which will deal
with individial accounts by picking up the
application context from the header (account id).
>>>
Bernd Schuller wrote:
I was wondering about whether you think it is a good idea to add support for
stateful services to CXF.
[...]
--
Dr. Bernd Schuller
Central Institute for Applied Mathematics
Forschungszentrum Juelich GmbH
mail [EMAIL PROTECTED]
phone +49 2461 61 8736
fax +49 2461 61 6656
blog http://www.jroller.com/page/gridhaus
