These may help ...
http://www.idealliance.org/proceedings/xml05/abstracts/paper54.HTML
http://wscc.info/p51561/files/57-hal.pdf
http://www.w3.org/2007/01/wos-papers/redhat
http://weblogs.java.net/blog/marklittle/archive/2005/05/
a_session_conte.html
http://www.orablogs.com/pavlik/archives/The-Session-Concept-in-Web-
Services.pdf
Mark.
On 23 Mar 2007, at 13:00, Sergey Beryozkin wrote:
Hi Bernd
it's just a matter of taste and modelling preference.
absolutely, I agree. I reckon if people preferring to work with WS-
RF can do it with CXF then it would be a good thing... it would
be great to have CXF be as large tent as possible for various
categories of developers. I like Don Box's saying that about Indigo
one day when saying that they got REST support wired in : no time
for religion.
thanks for your reply. The way you describe it, WS-Context goes
into a similar direction.
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...
* 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
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
Cheers, Sergey
Hi Sergey,
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.
Best regards,
Bernd.
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.
By "stateful" I mean you have multiple instances of a services
sitting behind a common
frontend. These instances are disambiguated by some unique ID.
Individual instances can be addressed
using WS-Addressing. The instances are kept alive between
service calls (either in memory or persisted to a database).
For example, you might have a "bank account service"
@Stateful @WebService
public class BankAccount{
@Unique
public String accountNumber;
private Balance balance;
@WebMethod
GetBalanceResponse public getBalance(GetBalanceRequest in){...}
}
There's a similar thing in Sun's JAX-WS RI, see
http://weblogs.java.net/blog/kohsuke/archive/2006/10/
stateful_web_se.html
which I think is fairly inflexible and can be greatly improved.
Support for this style of services would be useful for
implementing specs such as WS-RF on top of CXF.
I have implemented WS-RF on top of XFire, so I have some
experience with this stuff, and would
very much like to give this a try with 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
