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
