You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Bernd Schuller <b....@fz-juelich.de> on 2007/03/23 08:36:27 UTC
Support for stateful services in CXF
Hi all,
first, I'm new to CXF, so forgive my lack of detailed knowledge.
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.
What do you think?
Best regards,
Bernd.
--
Dr. Bernd Schuller
Central Institute for Applied Mathematics
Forschungszentrum Juelich GmbH
mail b.schuller@fz-juelich.de
phone +49 2461 61 8736
fax +49 2461 61 6656
blog http://www.jroller.com/page/gridhaus
Re: Support for stateful services in CXF
Posted by Sergey Beryozkin <se...@iona.com>.
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" <b....@fz-juelich.de>
To: <cx...@incubator.apache.org>
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 b.schuller@fz-juelich.de
> phone +49 2461 61 8736
> fax +49 2461 61 6656
> blog http://www.jroller.com/page/gridhaus
>
Re: Support for stateful services in CXF
Posted by Bernd Schuller <b....@fz-juelich.de>.
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 b.schuller@fz-juelich.de
phone +49 2461 61 8736
fax +49 2461 61 6656
blog http://www.jroller.com/page/gridhaus
Re: Support for stateful services in CXF
Posted by Mark Little <ma...@jboss.com>.
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 b.schuller@fz-juelich.de
>> phone +49 2461 61 8736
>> fax +49 2461 61 6656
>> blog http://www.jroller.com/page/gridhaus
>>
>
Re: Support for stateful services in CXF
Posted by Sergey Beryozkin <se...@iona.com>.
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 b.schuller@fz-juelich.de
> phone +49 2461 61 8736
> fax +49 2461 61 6656
> blog http://www.jroller.com/page/gridhaus
>
Re: Support for stateful services in CXF
Posted by Bernd Schuller <b....@fz-juelich.de>.
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 b.schuller@fz-juelich.de
phone +49 2461 61 8736
fax +49 2461 61 6656
blog http://www.jroller.com/page/gridhaus
Re: Support for stateful services in CXF
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
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).
Cheers, Sergey
> Hi all,
>
> first, I'm new to CXF, so forgive my lack of detailed knowledge.
>
> 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.
>
>
> What do you think?
>
>
> Best regards,
> Bernd.
>
> --
> Dr. Bernd Schuller
>
> Central Institute for Applied Mathematics
> Forschungszentrum Juelich GmbH
>
> mail b.schuller@fz-juelich.de
> phone +49 2461 61 8736
> fax +49 2461 61 6656
> blog http://www.jroller.com/page/gridhaus
>
Re: Support for stateful services in CXF
Posted by Bernd Schuller <b....@fz-juelich.de>.
Hi Gary,
Tully, Gary wrote:
>
> I have been toying around with my default servant test cases and
> implementing as I go. My test case determines if Numbers are even by
> accessing a particular Number instance from a NumberFactory (via create)
> and using the returned reference to invoke the isEven() operation.
> Trivial but illustrative I hope.
> To make the implementation work/scale on the Server, a single stateless
> servant represents all possible numbers and determines its current
> identity based on the details of its current/target Endpoint Reference.
[...]
>
> Bernd, does this nail your use case?
Yes, it does. Your implementation (MultiplexDestination) makes sense as well, especially
the freedom of using WS-A, HTTP URL parameters, or something else to
identify the target. I'm looking forward to seeing this in the CXF trunk!
Best regards,
Bernd.
>
> All, Does it make sense?
>
> Comments appreciated, I would like to further this into a proposal in
> the near future.
>
> Thanks,
> Gary.
>
>
>
>> -----Original Message-----
>> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
>> Sent: 23 March 2007 13:13
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: Support for stateful services in CXF
>>
>> Hi Gary,
>>
>> thanks a lot for your reply.
>>
>> Tully, Gary wrote:
>>> Only yesterday I started to investigate providing simple
>> support for a
>>> single instance service that can represent many WS-addressing
>>> identities.
>>>
>>> What I am after at the moment is a simpler version of what is
>>> supported by @Stateful in the JAX-WS RI. The only state is
>> a unique-id
>>> that is encapsulated in the WS-Address.
>> That looks like a starting point...
>>
>> [...]
>>
>>> At the moment I am capturing the FactoryPattern use-case as
>> a system
>>> test in order to provide a starting proof-point for an
>> implementation.
>>> The use of WS-Context (thanks Sergey) or HTTP session
>> information as a
>>> means of determining unique id would be neat but I think this is
>>> orthogonal.
>> agreed.
>>
>>> From a WS-RF point of view, what are the usage scenarios
>> that you will
>>> need? Do they lend them selves to capture as system tests?
>> The basic scenario is approximately
>> - allow for instance creation on a stateful service, for
>> example using a
>> Factory service
>> - deal with state, e.g. persist instances to some permanent storage
>> - manage instance lifecycle, manage their lifetime, destroy them
>> - allow clients to access instances by EPR / WS-Addressing
>> This can be captured by system tests, I guess.
>>
>>> Like you, I am learning as I go here, so any input is appreciated,
>>> especially your ideas on improving @Stateful and your experiences
>>> doing something similar with Xfire.
>> My main improvements on the JAX-WS RI @Stateful would be to
>> try and make the whole instance resolving process, instance
>> lifecycle management and EPR creation much more flexible, and
>> give more control to the application programmer.
>> Of course all this should fit in as nicely as possible in the
>> CXF environment, which I unfortunately don't know much about yet...
>>
>> In my XFire implementation, things were fairly easy, because
>> I could hook into the mechanism that XFire uses to get the
>> service object (the Invoker). Figure out the unique id from
>> the message context, re-create the requested service instance
>> from permanent storage, restore its state, and invoke the operation.
>>
>> Maybe something similar can be done in CXF.
>>
>>> As I am only starting on my quest for a design, you may as
>> well give
>>> it a try from your perspective. We can swap ideas or experiences to
>>> come up with a working solution. It need not be a race :-)
>> Perfect!
>>
>> Thanks, and best regards,
>> Bernd.
>>
>>
>>>> -----Original Message-----
>>>> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
>>>> Sent: 23 March 2007 07:36
>>>> To: CXF devel
>>>> Subject: Support for stateful services in CXF [...] 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 b.schuller@fz-juelich.de
>> phone +49 2461 61 8736
>> fax +49 2461 61 6656
>> blog http://www.jroller.com/page/gridhaus
>>
>>
>
>
--
Dr. Bernd Schuller
Central Institute for Applied Mathematics
Forschungszentrum Juelich GmbH
mail b.schuller@fz-juelich.de
phone +49 2461 61 8736
fax +49 2461 61 6656
blog http://www.jroller.com/page/gridhaus
Re: Support for stateful services in CXF
Posted by Sergey Beryozkin <se...@iona.com>.
I was rather hoping to initiate some discussion on how stateful web services can be done under the hood. CXF does it one way which is very good, this is similar how other providers do it too, and it works.
I'm really after trying to explore if there's anything that can be learnt or borrowed from the WS-Context spec and put into the practical surface, as far as bulding stateful services is concerned.
WS-Context is about supporting distributed activities (those spanning muliple services), so I'm wondering, can it all be applied to the issue of supporting the application-level stateful interactions or not...as the alternate strategy
Thanks, Sergey
----- Original Message -----
From: "Jeff Genender" <jg...@apache.org>
To: <cx...@incubator.apache.org>
Sent: Thursday, June 14, 2007 3:03 PM
Subject: Re: Support for stateful services in CXF
> If I think I understand what you are asking for, I believe I added
> support for stateful services by setting the
> "javax.xml.ws.session.maintain" in your request context to a Boolean.TRUE.
>
> You can enable stateful WS by setting:
>
> requestContext.put(BindingProvider.SESSION_MAINTAIN_PROPERTY, Boolean.TRUE);
>
> Thanks,
>
> Jeff
>
>
> Sergey Beryozkin wrote:
>> Hi Gary
>>
>> I'd like to revive this thread for a bit :-)
>> As you mentioned,
>>
>>> The 'value' of WS-Context IMHO is that the context is not tied
>>> to a particular EPR but can flow with a request to any EPR.
>>
>> Which is indeed quite a good thing. Do you reckon there's any space
>> for pushing the support for stateful services a bit further and providing an alternate
>> implementation built around WS-Context so that people can choose between the two ones ?
>>
>> I reckon both approaches have their value. It seems that "statefullness" is always associated with the use of WS-Addressing under the hood [1] in the WS-Services world. I think with WS-Context one might afford for a more loose interaction model between the client and the service endpoint...
>>
>> Cheers, Sergey
>>
>>
>> [1] http://weblogs.java.net/blog/kohsuke/archive/2007/06/stateful_web_se_1.html
>>
>>
>> ----- Original Message -----
>> From: "Tully, Gary" <Ga...@iona.com>
>> To: <cx...@incubator.apache.org>
>> Sent: Thursday, April 05, 2007 10:24 AM
>> Subject: RE: Support for stateful services in CXF
>>
>>
>> Hi Sergey,
>> I agree and as you spotted, AbstractHTTPDestination can ensure that HTTP
>> works with the address rather than with a WS-A reference parameter.
>> It would also be possible to use WS-Context as a strategy to transmit
>> the Id. The 'value' of WS-Context IMHO is that the context is not tied
>> to a particular EPR but can flow with a request to any EPR. This 'value'
>> is not apparent to my use case, hence the punt of WS-Context in to the
>> orthogonal sphere earlier.
>>
>>
>> The real motivator for WS-A is that it is transport neutral and as such
>> would work for any potential CXF transport that wants to support
>> multiplexing. This makes it an architecturally good choice for a default
>> propagation strategy.
>> In the realm of HTTP and yoko, the best return will come from the native
>> approach of embedding the id in the address as these addresses can still
>> be accessible to native consumers.
>>
>> Thanks for the input, academic? No :-)
>> Gary.
>>
>>> -----Original Message-----
>>> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
>>> Sent: 05 April 2007 09:53
>>> To: cxf-dev@incubator.apache.org
>>> Subject: Re: Support for stateful services in CXF
>>>
>>> Hi
>>>
>>> "is over kill for some transports. For example, for a
>>> transport like http or Yoko, it is possible to embed the
>>> unique Id into the endpoint address" ...
>>>
>>> IMHO this is what should happen for HTTP because this will
>>> make individul number services addressable...Using EPR
>>> parameters to convey the unique id looses the identity of the
>>> service endpoint.
>>> Sorry if my comments would seem a bit academic in the scope
>>> of your very interesting and more important, *practical*
>>> proposal. It's just that CXF shows the lead in letting people
>>> to build resful services, etc, so I feel that trying to
>>> pursue the general idea of bringing even purely SOAP-based
>>> services closer to the web, when possible, would be good. We
>>> can imagine then SOAP Number services being able to GET-reply
>>> with their state while still being able to process soap post
>>> increment/decrement requests, etc...This will increase the
>>> value of the Number service. Actually, have just seen your
>>> comment that AbstractHTTPDestination can be used for this,
>>> sounds great, perhaps this can be used to enhance the way
>>> things work with http in the future !
>>> If even for HTTP the WSA header will be sent to the service
>>> to indicate what instance the invocation should be made
>>> againt then it would be in general mean the explicit context
>>> is used, which is good, but I hope you can see now why I was
>>> referring to WS-Context earlier, one can imagine passing a
>>> WS_Context header to the Number service indicating an
>>> application level context, the number on which the service
>>> should perform the even check....so even though WS-Context is
>>> probably more natural for dealing with higher-level
>>> activities, it may work with the application-level ones too
>>>
>>> Overall it's a great start...
>>>
>>> Thanks, Sergey
>>>
>>> ----- Original Message -----
>>> From: "Tully, Gary" <Ga...@iona.com>
>>> To: <cx...@incubator.apache.org>
>>> Sent: Wednesday, April 04, 2007 5:40 PM
>>> Subject: RE: Support for stateful services in CXF
>>>
>>>
>>> Hi Bernd, all,
>>>
>>> I have been toying around with my default servant test cases and
>>> implementing as I go. My test case determines if Numbers are even by
>>> accessing a particular Number instance from a NumberFactory
>>> (via create)
>>> and using the returned reference to invoke the isEven() operation.
>>> Trivial but illustrative I hope.
>>> To make the implementation work/scale on the Server, a single
>>> stateless
>>> servant represents all possible numbers and determines its current
>>> identity based on the details of its current/target Endpoint
>>> Reference.
>>>
>>> My client code does the following:
>>>
>>> NumberFactoryService service = new NumberFactoryService();
>>> NumberFactory factory = service.getNumberFactoryPort();
>>>
>>>
>>> EndpointReferenceType numberTwoRef = factory.create("2");
>>>
>>> NumberService numService = new NumberService();
>>> A. ServiceImpl serviceImpl =
>>> ServiceDelegateAccessor.get(numService);
>>>
>>> B. Number num = (Number)serviceImpl.getPort(numberTwoRef,
>>> Number.class);
>>> assertTrue("2 is even", num.isEven().isEven());
>>>
>>> Of interest here is:
>>> A: JAX-WS is correctly particular about denying access to the
>>> underlying
>>> implementation and with 2.1, EndpointReferences are first
>>> class citizens
>>> so the need will no longer arise. Long term we probably need
>>> to start a
>>> jax-ws-2.1-frontend. Short term, implementing the functionality in the
>>> CXF implementation objects and providing this accessor is a fast win.
>>> B: the ServiceImpl.getPort(EndpointReferenceType epr,..)
>>> simply uses the
>>> address info of the epr to override the address of the EndpointInfo.
>>> There is an issue with duplication of information between EndpointInfo
>>> and EPRs in the Conduit that I will address in another post.
>>>
>>>
>>> The Server side is more interesting.
>>> NumberFactoryServiceImpl.create() needs to produce
>>> EndpointReferenceTypes (EPRs) for the NumberService that identity a
>>> particular number. First it inits and publishes a NumerServiceImpl
>>> servant. On the trunk this requires working with
>>> EndpointReferenceUtils
>>> to flesh out a valid EPR. My default implementation uses EPR
>>> referenceParameters to contain the unique Id and WS-A to propagate the
>>> target address. This has the advantage of being transport
>>> neutral but it
>>> is over kill for some transports. For example, for a
>>> transport like http
>>> or Yoko, it is possible to embed the unique Id into the endpoint
>>> address, append it to the context in http (context match based on
>>> startsWith) or for Yoko, burn it into a default servant
>>> object key. Then
>>> the need for WS-A disappears. This pushes the detail of EPR creation
>>> with a unique Id onto the transport/Destination.
>>>
>>> I am thinking along the lines of an extension to Destination that
>>> transports can optionally support.
>>>
>>> /**
>>> * A MultiplexDestination is a transport-level endpoint capable of
>>> receiving
>>> * unsolicited incoming messages from different peers for multiple
>>> targets
>>> * identified by a unique id.
>>> * The disambiguation of targets is handled by higher layers as the
>>> target
>>> * address is made available as a context property or as a WS-A-To
>>> header
>>> */
>>>
>>> public interface MultiplexDestination extends Destination {
>>>
>>> /**
>>> * @return the a reference containing the id that is
>>> * associated with this Destination
>>> */
>>> EndpointReferenceType getAddressWithId(String id);
>>>
>>> /**
>>> * @param contextMap for this invocation, for example from
>>> * JAX-WS WebServiceContext.getMessageContext(). The context will
>>> * either contain the WS-A To content and/or some property that
>>> * identifies the target address, eg MessageContext.PATH_INFO for
>>> * the current invocation
>>> * @return the id associated with the current invocation
>>> */
>>> String getId(Map contextMap);
>>> }
>>>
>>> The default implementation in AbstractMultiplexDestination can map the
>>> uniqueId to an EPR referenceParameter and propagate via WSA in a
>>> transport neutral way. AbstractHttpDestination can optionally override
>>> the default to make use of the address context for a more
>>> efficient and
>>> natural http implementation.
>>>
>>> From a users perspective, a unique server side epr would be
>>> resolved/created from a existing published service using
>>>
>>> EndpointRefernceType epr =
>>>
>>> EndpointReferenceUtils.getEndpointReferenceWithId(NUMBER_SERVI
>>> CE_QNAME,
>>> null, // portName
>>> uniqueId,
>>> BusFactory.getDefaultBus());
>>>
>>> Note: The portName should allow a particular port among many in a
>>> service, to be identified.
>>>
>>> Where EndpointReferenceUtils goes as follows:
>>>
>>> public static EndpointReferenceType getEndpointReferenceWithId(QName
>>> serviceQName, String portMame, String id, Bus bus) {
>>> EndpointReferenceType epr = null;
>>> ServerRegistry serverRegistry = (ServerRegistry)
>>> bus.getExtension(ServerRegistry.class);
>>> List<Server> servers = serverRegistry.getServers();
>>> for (Server s : servers) {
>>> QName targetServiceQName =
>>> s.getEndpoint().getEndpointInfo().getService().getName();
>>> if (serviceQName.equals(targetServiceQName)) {
>>> Destination dest = s.getDestination();
>>> if (dest instanceof MultiplexDestination) {
>>> epr =
>>> ((MultiplexDestination)dest).getEndpointReferenceWithId(id);
>>> break;
>>> }
>>> }
>>> return epr;
>>>
>>> Also
>>> public static String getCurrentEndpointReferenceId(Map context, Bus
>>> bus) {
>>> ...
>>> }
>>>
>>> During an invocation (server dispatch) accessing the current target
>>> EndpointReference needs a little work however. The JAX-WS
>>> MessageContext
>>> Map contains all the required information as properties. The
>>> MultiplexedDestination can use this information to locate and extract
>>> the uniqueId for this current request. The use of Map in the api keeps
>>> the EndpointReferenceUtils front-end neutral and the
>>> MultiplexedDestination transport neutral.
>>>
>>>
>>> Having to traverse the list of registered services in is a bit
>>> cumbersome, would it be possible to have services registered
>>> by Service
>>> QName? Or would that restrict us to single instance services. It could
>>> be map<QName, List<Service>>.
>>>
>>>
>>> Bernd, does this nail your use case?
>>>
>>> All, Does it make sense?
>>>
>>> Comments appreciated, I would like to further this into a proposal in
>>> the near future.
>>>
>>> Thanks,
>>> Gary.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
>>>> Sent: 23 March 2007 13:13
>>>> To: cxf-dev@incubator.apache.org
>>>> Subject: Re: Support for stateful services in CXF
>>>>
>>>> Hi Gary,
>>>>
>>>> thanks a lot for your reply.
>>>>
>>>> Tully, Gary wrote:
>>>>> Only yesterday I started to investigate providing simple
>>>> support for a
>>>>> single instance service that can represent many WS-addressing
>>>>> identities.
>>>>>
>>>>> What I am after at the moment is a simpler version of what is
>>>>> supported by @Stateful in the JAX-WS RI. The only state is
>>>> a unique-id
>>>>> that is encapsulated in the WS-Address.
>>>> That looks like a starting point...
>>>>
>>>> [...]
>>>>
>>>>> At the moment I am capturing the FactoryPattern use-case as
>>>> a system
>>>>> test in order to provide a starting proof-point for an
>>>> implementation.
>>>>> The use of WS-Context (thanks Sergey) or HTTP session
>>>> information as a
>>>>> means of determining unique id would be neat but I think this is
>>>>> orthogonal.
>>>> agreed.
>>>>
>>>>> From a WS-RF point of view, what are the usage scenarios
>>>> that you will
>>>>> need? Do they lend them selves to capture as system tests?
>>>> The basic scenario is approximately
>>>> - allow for instance creation on a stateful service, for
>>>> example using a
>>>> Factory service
>>>> - deal with state, e.g. persist instances to some
>>> permanent storage
>>>> - manage instance lifecycle, manage their lifetime, destroy them
>>>> - allow clients to access instances by EPR / WS-Addressing
>>>> This can be captured by system tests, I guess.
>>>>
>>>>> Like you, I am learning as I go here, so any input is appreciated,
>>>>> especially your ideas on improving @Stateful and your experiences
>>>>> doing something similar with Xfire.
>>>> My main improvements on the JAX-WS RI @Stateful would be to
>>>> try and make the whole instance resolving process, instance
>>>> lifecycle management and EPR creation much more flexible, and
>>>> give more control to the application programmer.
>>>> Of course all this should fit in as nicely as possible in the
>>>> CXF environment, which I unfortunately don't know much about yet...
>>>>
>>>> In my XFire implementation, things were fairly easy, because
>>>> I could hook into the mechanism that XFire uses to get the
>>>> service object (the Invoker). Figure out the unique id from
>>>> the message context, re-create the requested service instance
>>>> from permanent storage, restore its state, and invoke the operation.
>>>>
>>>> Maybe something similar can be done in CXF.
>>>>
>>>>> As I am only starting on my quest for a design, you may as
>>>> well give
>>>>> it a try from your perspective. We can swap ideas or
>>> experiences to
>>>>> come up with a working solution. It need not be a race :-)
>>>> Perfect!
>>>>
>>>> Thanks, and best regards,
>>>> Bernd.
>>>>
>>>>
>>>>>> -----Original Message-----
>>>>>> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
>>>>>> Sent: 23 March 2007 07:36
>>>>>> To: CXF devel
>>>>>> Subject: Support for stateful services in CXF [...] 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 b.schuller@fz-juelich.de
>>>> phone +49 2461 61 8736
>>>> fax +49 2461 61 6656
>>>> blog http://www.jroller.com/page/gridhaus
>>>>
>>>>
>>>
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Support for stateful services in CXF
Posted by Jeff Genender <jg...@apache.org>.
If I think I understand what you are asking for, I believe I added
support for stateful services by setting the
"javax.xml.ws.session.maintain" in your request context to a Boolean.TRUE.
You can enable stateful WS by setting:
requestContext.put(BindingProvider.SESSION_MAINTAIN_PROPERTY, Boolean.TRUE);
Thanks,
Jeff
Sergey Beryozkin wrote:
> Hi Gary
>
> I'd like to revive this thread for a bit :-)
> As you mentioned,
>
>> The 'value' of WS-Context IMHO is that the context is not tied
>> to a particular EPR but can flow with a request to any EPR.
>
> Which is indeed quite a good thing. Do you reckon there's any space
> for pushing the support for stateful services a bit further and providing an alternate
> implementation built around WS-Context so that people can choose between the two ones ?
>
> I reckon both approaches have their value. It seems that "statefullness" is always associated with the use of WS-Addressing under the hood [1] in the WS-Services world. I think with WS-Context one might afford for a more loose interaction model between the client and the service endpoint...
>
> Cheers, Sergey
>
>
> [1] http://weblogs.java.net/blog/kohsuke/archive/2007/06/stateful_web_se_1.html
>
>
> ----- Original Message -----
> From: "Tully, Gary" <Ga...@iona.com>
> To: <cx...@incubator.apache.org>
> Sent: Thursday, April 05, 2007 10:24 AM
> Subject: RE: Support for stateful services in CXF
>
>
> Hi Sergey,
> I agree and as you spotted, AbstractHTTPDestination can ensure that HTTP
> works with the address rather than with a WS-A reference parameter.
> It would also be possible to use WS-Context as a strategy to transmit
> the Id. The 'value' of WS-Context IMHO is that the context is not tied
> to a particular EPR but can flow with a request to any EPR. This 'value'
> is not apparent to my use case, hence the punt of WS-Context in to the
> orthogonal sphere earlier.
>
>
> The real motivator for WS-A is that it is transport neutral and as such
> would work for any potential CXF transport that wants to support
> multiplexing. This makes it an architecturally good choice for a default
> propagation strategy.
> In the realm of HTTP and yoko, the best return will come from the native
> approach of embedding the id in the address as these addresses can still
> be accessible to native consumers.
>
> Thanks for the input, academic? No :-)
> Gary.
>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
>> Sent: 05 April 2007 09:53
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: Support for stateful services in CXF
>>
>> Hi
>>
>> "is over kill for some transports. For example, for a
>> transport like http or Yoko, it is possible to embed the
>> unique Id into the endpoint address" ...
>>
>> IMHO this is what should happen for HTTP because this will
>> make individul number services addressable...Using EPR
>> parameters to convey the unique id looses the identity of the
>> service endpoint.
>> Sorry if my comments would seem a bit academic in the scope
>> of your very interesting and more important, *practical*
>> proposal. It's just that CXF shows the lead in letting people
>> to build resful services, etc, so I feel that trying to
>> pursue the general idea of bringing even purely SOAP-based
>> services closer to the web, when possible, would be good. We
>> can imagine then SOAP Number services being able to GET-reply
>> with their state while still being able to process soap post
>> increment/decrement requests, etc...This will increase the
>> value of the Number service. Actually, have just seen your
>> comment that AbstractHTTPDestination can be used for this,
>> sounds great, perhaps this can be used to enhance the way
>> things work with http in the future !
>> If even for HTTP the WSA header will be sent to the service
>> to indicate what instance the invocation should be made
>> againt then it would be in general mean the explicit context
>> is used, which is good, but I hope you can see now why I was
>> referring to WS-Context earlier, one can imagine passing a
>> WS_Context header to the Number service indicating an
>> application level context, the number on which the service
>> should perform the even check....so even though WS-Context is
>> probably more natural for dealing with higher-level
>> activities, it may work with the application-level ones too
>>
>> Overall it's a great start...
>>
>> Thanks, Sergey
>>
>> ----- Original Message -----
>> From: "Tully, Gary" <Ga...@iona.com>
>> To: <cx...@incubator.apache.org>
>> Sent: Wednesday, April 04, 2007 5:40 PM
>> Subject: RE: Support for stateful services in CXF
>>
>>
>> Hi Bernd, all,
>>
>> I have been toying around with my default servant test cases and
>> implementing as I go. My test case determines if Numbers are even by
>> accessing a particular Number instance from a NumberFactory
>> (via create)
>> and using the returned reference to invoke the isEven() operation.
>> Trivial but illustrative I hope.
>> To make the implementation work/scale on the Server, a single
>> stateless
>> servant represents all possible numbers and determines its current
>> identity based on the details of its current/target Endpoint
>> Reference.
>>
>> My client code does the following:
>>
>> NumberFactoryService service = new NumberFactoryService();
>> NumberFactory factory = service.getNumberFactoryPort();
>>
>>
>> EndpointReferenceType numberTwoRef = factory.create("2");
>>
>> NumberService numService = new NumberService();
>> A. ServiceImpl serviceImpl =
>> ServiceDelegateAccessor.get(numService);
>>
>> B. Number num = (Number)serviceImpl.getPort(numberTwoRef,
>> Number.class);
>> assertTrue("2 is even", num.isEven().isEven());
>>
>> Of interest here is:
>> A: JAX-WS is correctly particular about denying access to the
>> underlying
>> implementation and with 2.1, EndpointReferences are first
>> class citizens
>> so the need will no longer arise. Long term we probably need
>> to start a
>> jax-ws-2.1-frontend. Short term, implementing the functionality in the
>> CXF implementation objects and providing this accessor is a fast win.
>> B: the ServiceImpl.getPort(EndpointReferenceType epr,..)
>> simply uses the
>> address info of the epr to override the address of the EndpointInfo.
>> There is an issue with duplication of information between EndpointInfo
>> and EPRs in the Conduit that I will address in another post.
>>
>>
>> The Server side is more interesting.
>> NumberFactoryServiceImpl.create() needs to produce
>> EndpointReferenceTypes (EPRs) for the NumberService that identity a
>> particular number. First it inits and publishes a NumerServiceImpl
>> servant. On the trunk this requires working with
>> EndpointReferenceUtils
>> to flesh out a valid EPR. My default implementation uses EPR
>> referenceParameters to contain the unique Id and WS-A to propagate the
>> target address. This has the advantage of being transport
>> neutral but it
>> is over kill for some transports. For example, for a
>> transport like http
>> or Yoko, it is possible to embed the unique Id into the endpoint
>> address, append it to the context in http (context match based on
>> startsWith) or for Yoko, burn it into a default servant
>> object key. Then
>> the need for WS-A disappears. This pushes the detail of EPR creation
>> with a unique Id onto the transport/Destination.
>>
>> I am thinking along the lines of an extension to Destination that
>> transports can optionally support.
>>
>> /**
>> * A MultiplexDestination is a transport-level endpoint capable of
>> receiving
>> * unsolicited incoming messages from different peers for multiple
>> targets
>> * identified by a unique id.
>> * The disambiguation of targets is handled by higher layers as the
>> target
>> * address is made available as a context property or as a WS-A-To
>> header
>> */
>>
>> public interface MultiplexDestination extends Destination {
>>
>> /**
>> * @return the a reference containing the id that is
>> * associated with this Destination
>> */
>> EndpointReferenceType getAddressWithId(String id);
>>
>> /**
>> * @param contextMap for this invocation, for example from
>> * JAX-WS WebServiceContext.getMessageContext(). The context will
>> * either contain the WS-A To content and/or some property that
>> * identifies the target address, eg MessageContext.PATH_INFO for
>> * the current invocation
>> * @return the id associated with the current invocation
>> */
>> String getId(Map contextMap);
>> }
>>
>> The default implementation in AbstractMultiplexDestination can map the
>> uniqueId to an EPR referenceParameter and propagate via WSA in a
>> transport neutral way. AbstractHttpDestination can optionally override
>> the default to make use of the address context for a more
>> efficient and
>> natural http implementation.
>>
>> From a users perspective, a unique server side epr would be
>> resolved/created from a existing published service using
>>
>> EndpointRefernceType epr =
>>
>> EndpointReferenceUtils.getEndpointReferenceWithId(NUMBER_SERVI
>> CE_QNAME,
>> null, // portName
>> uniqueId,
>> BusFactory.getDefaultBus());
>>
>> Note: The portName should allow a particular port among many in a
>> service, to be identified.
>>
>> Where EndpointReferenceUtils goes as follows:
>>
>> public static EndpointReferenceType getEndpointReferenceWithId(QName
>> serviceQName, String portMame, String id, Bus bus) {
>> EndpointReferenceType epr = null;
>> ServerRegistry serverRegistry = (ServerRegistry)
>> bus.getExtension(ServerRegistry.class);
>> List<Server> servers = serverRegistry.getServers();
>> for (Server s : servers) {
>> QName targetServiceQName =
>> s.getEndpoint().getEndpointInfo().getService().getName();
>> if (serviceQName.equals(targetServiceQName)) {
>> Destination dest = s.getDestination();
>> if (dest instanceof MultiplexDestination) {
>> epr =
>> ((MultiplexDestination)dest).getEndpointReferenceWithId(id);
>> break;
>> }
>> }
>> return epr;
>>
>> Also
>> public static String getCurrentEndpointReferenceId(Map context, Bus
>> bus) {
>> ...
>> }
>>
>> During an invocation (server dispatch) accessing the current target
>> EndpointReference needs a little work however. The JAX-WS
>> MessageContext
>> Map contains all the required information as properties. The
>> MultiplexedDestination can use this information to locate and extract
>> the uniqueId for this current request. The use of Map in the api keeps
>> the EndpointReferenceUtils front-end neutral and the
>> MultiplexedDestination transport neutral.
>>
>>
>> Having to traverse the list of registered services in is a bit
>> cumbersome, would it be possible to have services registered
>> by Service
>> QName? Or would that restrict us to single instance services. It could
>> be map<QName, List<Service>>.
>>
>>
>> Bernd, does this nail your use case?
>>
>> All, Does it make sense?
>>
>> Comments appreciated, I would like to further this into a proposal in
>> the near future.
>>
>> Thanks,
>> Gary.
>>
>>
>>
>>> -----Original Message-----
>>> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
>>> Sent: 23 March 2007 13:13
>>> To: cxf-dev@incubator.apache.org
>>> Subject: Re: Support for stateful services in CXF
>>>
>>> Hi Gary,
>>>
>>> thanks a lot for your reply.
>>>
>>> Tully, Gary wrote:
>>>> Only yesterday I started to investigate providing simple
>>> support for a
>>>> single instance service that can represent many WS-addressing
>>>> identities.
>>>>
>>>> What I am after at the moment is a simpler version of what is
>>>> supported by @Stateful in the JAX-WS RI. The only state is
>>> a unique-id
>>>> that is encapsulated in the WS-Address.
>>> That looks like a starting point...
>>>
>>> [...]
>>>
>>>> At the moment I am capturing the FactoryPattern use-case as
>>> a system
>>>> test in order to provide a starting proof-point for an
>>> implementation.
>>>> The use of WS-Context (thanks Sergey) or HTTP session
>>> information as a
>>>> means of determining unique id would be neat but I think this is
>>>> orthogonal.
>>> agreed.
>>>
>>>> From a WS-RF point of view, what are the usage scenarios
>>> that you will
>>>> need? Do they lend them selves to capture as system tests?
>>> The basic scenario is approximately
>>> - allow for instance creation on a stateful service, for
>>> example using a
>>> Factory service
>>> - deal with state, e.g. persist instances to some
>> permanent storage
>>> - manage instance lifecycle, manage their lifetime, destroy them
>>> - allow clients to access instances by EPR / WS-Addressing
>>> This can be captured by system tests, I guess.
>>>
>>>> Like you, I am learning as I go here, so any input is appreciated,
>>>> especially your ideas on improving @Stateful and your experiences
>>>> doing something similar with Xfire.
>>> My main improvements on the JAX-WS RI @Stateful would be to
>>> try and make the whole instance resolving process, instance
>>> lifecycle management and EPR creation much more flexible, and
>>> give more control to the application programmer.
>>> Of course all this should fit in as nicely as possible in the
>>> CXF environment, which I unfortunately don't know much about yet...
>>>
>>> In my XFire implementation, things were fairly easy, because
>>> I could hook into the mechanism that XFire uses to get the
>>> service object (the Invoker). Figure out the unique id from
>>> the message context, re-create the requested service instance
>>> from permanent storage, restore its state, and invoke the operation.
>>>
>>> Maybe something similar can be done in CXF.
>>>
>>>> As I am only starting on my quest for a design, you may as
>>> well give
>>>> it a try from your perspective. We can swap ideas or
>> experiences to
>>>> come up with a working solution. It need not be a race :-)
>>> Perfect!
>>>
>>> Thanks, and best regards,
>>> Bernd.
>>>
>>>
>>>>> -----Original Message-----
>>>>> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
>>>>> Sent: 23 March 2007 07:36
>>>>> To: CXF devel
>>>>> Subject: Support for stateful services in CXF [...] 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 b.schuller@fz-juelich.de
>>> phone +49 2461 61 8736
>>> fax +49 2461 61 6656
>>> blog http://www.jroller.com/page/gridhaus
>>>
>>>
>>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
Re: Support for stateful services in CXF
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Gary
I'd like to revive this thread for a bit :-)
As you mentioned,
>The 'value' of WS-Context IMHO is that the context is not tied
>to a particular EPR but can flow with a request to any EPR.
Which is indeed quite a good thing. Do you reckon there's any space
for pushing the support for stateful services a bit further and providing an alternate
implementation built around WS-Context so that people can choose between the two ones ?
I reckon both approaches have their value. It seems that "statefullness" is always associated with the use of WS-Addressing under the hood [1] in the WS-Services world. I think with WS-Context one might afford for a more loose interaction model between the client and the service endpoint...
Cheers, Sergey
[1] http://weblogs.java.net/blog/kohsuke/archive/2007/06/stateful_web_se_1.html
----- Original Message -----
From: "Tully, Gary" <Ga...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Thursday, April 05, 2007 10:24 AM
Subject: RE: Support for stateful services in CXF
Hi Sergey,
I agree and as you spotted, AbstractHTTPDestination can ensure that HTTP
works with the address rather than with a WS-A reference parameter.
It would also be possible to use WS-Context as a strategy to transmit
the Id. The 'value' of WS-Context IMHO is that the context is not tied
to a particular EPR but can flow with a request to any EPR. This 'value'
is not apparent to my use case, hence the punt of WS-Context in to the
orthogonal sphere earlier.
The real motivator for WS-A is that it is transport neutral and as such
would work for any potential CXF transport that wants to support
multiplexing. This makes it an architecturally good choice for a default
propagation strategy.
In the realm of HTTP and yoko, the best return will come from the native
approach of embedding the id in the address as these addresses can still
be accessible to native consumers.
Thanks for the input, academic? No :-)
Gary.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 05 April 2007 09:53
> To: cxf-dev@incubator.apache.org
> Subject: Re: Support for stateful services in CXF
>
> Hi
>
> "is over kill for some transports. For example, for a
> transport like http or Yoko, it is possible to embed the
> unique Id into the endpoint address" ...
>
> IMHO this is what should happen for HTTP because this will
> make individul number services addressable...Using EPR
> parameters to convey the unique id looses the identity of the
> service endpoint.
> Sorry if my comments would seem a bit academic in the scope
> of your very interesting and more important, *practical*
> proposal. It's just that CXF shows the lead in letting people
> to build resful services, etc, so I feel that trying to
> pursue the general idea of bringing even purely SOAP-based
> services closer to the web, when possible, would be good. We
> can imagine then SOAP Number services being able to GET-reply
> with their state while still being able to process soap post
> increment/decrement requests, etc...This will increase the
> value of the Number service. Actually, have just seen your
> comment that AbstractHTTPDestination can be used for this,
> sounds great, perhaps this can be used to enhance the way
> things work with http in the future !
> If even for HTTP the WSA header will be sent to the service
> to indicate what instance the invocation should be made
> againt then it would be in general mean the explicit context
> is used, which is good, but I hope you can see now why I was
> referring to WS-Context earlier, one can imagine passing a
> WS_Context header to the Number service indicating an
> application level context, the number on which the service
> should perform the even check....so even though WS-Context is
> probably more natural for dealing with higher-level
> activities, it may work with the application-level ones too
>
> Overall it's a great start...
>
> Thanks, Sergey
>
> ----- Original Message -----
> From: "Tully, Gary" <Ga...@iona.com>
> To: <cx...@incubator.apache.org>
> Sent: Wednesday, April 04, 2007 5:40 PM
> Subject: RE: Support for stateful services in CXF
>
>
> Hi Bernd, all,
>
> I have been toying around with my default servant test cases and
> implementing as I go. My test case determines if Numbers are even by
> accessing a particular Number instance from a NumberFactory
> (via create)
> and using the returned reference to invoke the isEven() operation.
> Trivial but illustrative I hope.
> To make the implementation work/scale on the Server, a single
> stateless
> servant represents all possible numbers and determines its current
> identity based on the details of its current/target Endpoint
> Reference.
>
> My client code does the following:
>
> NumberFactoryService service = new NumberFactoryService();
> NumberFactory factory = service.getNumberFactoryPort();
>
>
> EndpointReferenceType numberTwoRef = factory.create("2");
>
> NumberService numService = new NumberService();
> A. ServiceImpl serviceImpl =
> ServiceDelegateAccessor.get(numService);
>
> B. Number num = (Number)serviceImpl.getPort(numberTwoRef,
> Number.class);
> assertTrue("2 is even", num.isEven().isEven());
>
> Of interest here is:
> A: JAX-WS is correctly particular about denying access to the
> underlying
> implementation and with 2.1, EndpointReferences are first
> class citizens
> so the need will no longer arise. Long term we probably need
> to start a
> jax-ws-2.1-frontend. Short term, implementing the functionality in the
> CXF implementation objects and providing this accessor is a fast win.
> B: the ServiceImpl.getPort(EndpointReferenceType epr,..)
> simply uses the
> address info of the epr to override the address of the EndpointInfo.
> There is an issue with duplication of information between EndpointInfo
> and EPRs in the Conduit that I will address in another post.
>
>
> The Server side is more interesting.
> NumberFactoryServiceImpl.create() needs to produce
> EndpointReferenceTypes (EPRs) for the NumberService that identity a
> particular number. First it inits and publishes a NumerServiceImpl
> servant. On the trunk this requires working with
> EndpointReferenceUtils
> to flesh out a valid EPR. My default implementation uses EPR
> referenceParameters to contain the unique Id and WS-A to propagate the
> target address. This has the advantage of being transport
> neutral but it
> is over kill for some transports. For example, for a
> transport like http
> or Yoko, it is possible to embed the unique Id into the endpoint
> address, append it to the context in http (context match based on
> startsWith) or for Yoko, burn it into a default servant
> object key. Then
> the need for WS-A disappears. This pushes the detail of EPR creation
> with a unique Id onto the transport/Destination.
>
> I am thinking along the lines of an extension to Destination that
> transports can optionally support.
>
> /**
> * A MultiplexDestination is a transport-level endpoint capable of
> receiving
> * unsolicited incoming messages from different peers for multiple
> targets
> * identified by a unique id.
> * The disambiguation of targets is handled by higher layers as the
> target
> * address is made available as a context property or as a WS-A-To
> header
> */
>
> public interface MultiplexDestination extends Destination {
>
> /**
> * @return the a reference containing the id that is
> * associated with this Destination
> */
> EndpointReferenceType getAddressWithId(String id);
>
> /**
> * @param contextMap for this invocation, for example from
> * JAX-WS WebServiceContext.getMessageContext(). The context will
> * either contain the WS-A To content and/or some property that
> * identifies the target address, eg MessageContext.PATH_INFO for
> * the current invocation
> * @return the id associated with the current invocation
> */
> String getId(Map contextMap);
> }
>
> The default implementation in AbstractMultiplexDestination can map the
> uniqueId to an EPR referenceParameter and propagate via WSA in a
> transport neutral way. AbstractHttpDestination can optionally override
> the default to make use of the address context for a more
> efficient and
> natural http implementation.
>
> From a users perspective, a unique server side epr would be
> resolved/created from a existing published service using
>
> EndpointRefernceType epr =
>
> EndpointReferenceUtils.getEndpointReferenceWithId(NUMBER_SERVI
> CE_QNAME,
> null, // portName
> uniqueId,
> BusFactory.getDefaultBus());
>
> Note: The portName should allow a particular port among many in a
> service, to be identified.
>
> Where EndpointReferenceUtils goes as follows:
>
> public static EndpointReferenceType getEndpointReferenceWithId(QName
> serviceQName, String portMame, String id, Bus bus) {
> EndpointReferenceType epr = null;
> ServerRegistry serverRegistry = (ServerRegistry)
> bus.getExtension(ServerRegistry.class);
> List<Server> servers = serverRegistry.getServers();
> for (Server s : servers) {
> QName targetServiceQName =
> s.getEndpoint().getEndpointInfo().getService().getName();
> if (serviceQName.equals(targetServiceQName)) {
> Destination dest = s.getDestination();
> if (dest instanceof MultiplexDestination) {
> epr =
> ((MultiplexDestination)dest).getEndpointReferenceWithId(id);
> break;
> }
> }
> return epr;
>
> Also
> public static String getCurrentEndpointReferenceId(Map context, Bus
> bus) {
> ...
> }
>
> During an invocation (server dispatch) accessing the current target
> EndpointReference needs a little work however. The JAX-WS
> MessageContext
> Map contains all the required information as properties. The
> MultiplexedDestination can use this information to locate and extract
> the uniqueId for this current request. The use of Map in the api keeps
> the EndpointReferenceUtils front-end neutral and the
> MultiplexedDestination transport neutral.
>
>
> Having to traverse the list of registered services in is a bit
> cumbersome, would it be possible to have services registered
> by Service
> QName? Or would that restrict us to single instance services. It could
> be map<QName, List<Service>>.
>
>
> Bernd, does this nail your use case?
>
> All, Does it make sense?
>
> Comments appreciated, I would like to further this into a proposal in
> the near future.
>
> Thanks,
> Gary.
>
>
>
> > -----Original Message-----
> > From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> > Sent: 23 March 2007 13:13
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Support for stateful services in CXF
> >
> > Hi Gary,
> >
> > thanks a lot for your reply.
> >
> > Tully, Gary wrote:
> > >
> > > Only yesterday I started to investigate providing simple
> > support for a
> > > single instance service that can represent many WS-addressing
> > > identities.
> > >
> > > What I am after at the moment is a simpler version of what is
> > > supported by @Stateful in the JAX-WS RI. The only state is
> > a unique-id
> > > that is encapsulated in the WS-Address.
> >
> > That looks like a starting point...
> >
> > [...]
> >
> > > At the moment I am capturing the FactoryPattern use-case as
> > a system
> > > test in order to provide a starting proof-point for an
> > implementation.
> > >
> > > The use of WS-Context (thanks Sergey) or HTTP session
> > information as a
> > > means of determining unique id would be neat but I think this is
> > > orthogonal.
> >
> > agreed.
> >
> > > From a WS-RF point of view, what are the usage scenarios
> > that you will
> > > need? Do they lend them selves to capture as system tests?
> >
> > The basic scenario is approximately
> > - allow for instance creation on a stateful service, for
> > example using a
> > Factory service
> > - deal with state, e.g. persist instances to some
> permanent storage
> > - manage instance lifecycle, manage their lifetime, destroy them
> > - allow clients to access instances by EPR / WS-Addressing
> > This can be captured by system tests, I guess.
> >
> > > Like you, I am learning as I go here, so any input is appreciated,
> > > especially your ideas on improving @Stateful and your experiences
> > > doing something similar with Xfire.
> >
> > My main improvements on the JAX-WS RI @Stateful would be to
> > try and make the whole instance resolving process, instance
> > lifecycle management and EPR creation much more flexible, and
> > give more control to the application programmer.
> > Of course all this should fit in as nicely as possible in the
> > CXF environment, which I unfortunately don't know much about yet...
> >
> > In my XFire implementation, things were fairly easy, because
> > I could hook into the mechanism that XFire uses to get the
> > service object (the Invoker). Figure out the unique id from
> > the message context, re-create the requested service instance
> > from permanent storage, restore its state, and invoke the operation.
> >
> > Maybe something similar can be done in CXF.
> >
> > > As I am only starting on my quest for a design, you may as
> > well give
> > > it a try from your perspective. We can swap ideas or
> experiences to
> > > come up with a working solution. It need not be a race :-)
> >
> > Perfect!
> >
> > Thanks, and best regards,
> > Bernd.
> >
> >
> > >> -----Original Message-----
> > >> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> > >> Sent: 23 March 2007 07:36
> > >> To: CXF devel
> > >> Subject: Support for stateful services in CXF [...] 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 b.schuller@fz-juelich.de
> > phone +49 2461 61 8736
> > fax +49 2461 61 6656
> > blog http://www.jroller.com/page/gridhaus
> >
> >
>
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Support for stateful services in CXF
Posted by "Tully, Gary" <Ga...@iona.com>.
Hi Sergey,
I agree and as you spotted, AbstractHTTPDestination can ensure that HTTP
works with the address rather than with a WS-A reference parameter.
It would also be possible to use WS-Context as a strategy to transmit
the Id. The 'value' of WS-Context IMHO is that the context is not tied
to a particular EPR but can flow with a request to any EPR. This 'value'
is not apparent to my use case, hence the punt of WS-Context in to the
orthogonal sphere earlier.
The real motivator for WS-A is that it is transport neutral and as such
would work for any potential CXF transport that wants to support
multiplexing. This makes it an architecturally good choice for a default
propagation strategy.
In the realm of HTTP and yoko, the best return will come from the native
approach of embedding the id in the address as these addresses can still
be accessible to native consumers.
Thanks for the input, academic? No :-)
Gary.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 05 April 2007 09:53
> To: cxf-dev@incubator.apache.org
> Subject: Re: Support for stateful services in CXF
>
> Hi
>
> "is over kill for some transports. For example, for a
> transport like http or Yoko, it is possible to embed the
> unique Id into the endpoint address" ...
>
> IMHO this is what should happen for HTTP because this will
> make individul number services addressable...Using EPR
> parameters to convey the unique id looses the identity of the
> service endpoint.
> Sorry if my comments would seem a bit academic in the scope
> of your very interesting and more important, *practical*
> proposal. It's just that CXF shows the lead in letting people
> to build resful services, etc, so I feel that trying to
> pursue the general idea of bringing even purely SOAP-based
> services closer to the web, when possible, would be good. We
> can imagine then SOAP Number services being able to GET-reply
> with their state while still being able to process soap post
> increment/decrement requests, etc...This will increase the
> value of the Number service. Actually, have just seen your
> comment that AbstractHTTPDestination can be used for this,
> sounds great, perhaps this can be used to enhance the way
> things work with http in the future !
> If even for HTTP the WSA header will be sent to the service
> to indicate what instance the invocation should be made
> againt then it would be in general mean the explicit context
> is used, which is good, but I hope you can see now why I was
> referring to WS-Context earlier, one can imagine passing a
> WS_Context header to the Number service indicating an
> application level context, the number on which the service
> should perform the even check....so even though WS-Context is
> probably more natural for dealing with higher-level
> activities, it may work with the application-level ones too
>
> Overall it's a great start...
>
> Thanks, Sergey
>
> ----- Original Message -----
> From: "Tully, Gary" <Ga...@iona.com>
> To: <cx...@incubator.apache.org>
> Sent: Wednesday, April 04, 2007 5:40 PM
> Subject: RE: Support for stateful services in CXF
>
>
> Hi Bernd, all,
>
> I have been toying around with my default servant test cases and
> implementing as I go. My test case determines if Numbers are even by
> accessing a particular Number instance from a NumberFactory
> (via create)
> and using the returned reference to invoke the isEven() operation.
> Trivial but illustrative I hope.
> To make the implementation work/scale on the Server, a single
> stateless
> servant represents all possible numbers and determines its current
> identity based on the details of its current/target Endpoint
> Reference.
>
> My client code does the following:
>
> NumberFactoryService service = new NumberFactoryService();
> NumberFactory factory = service.getNumberFactoryPort();
>
>
> EndpointReferenceType numberTwoRef = factory.create("2");
>
> NumberService numService = new NumberService();
> A. ServiceImpl serviceImpl =
> ServiceDelegateAccessor.get(numService);
>
> B. Number num = (Number)serviceImpl.getPort(numberTwoRef,
> Number.class);
> assertTrue("2 is even", num.isEven().isEven());
>
> Of interest here is:
> A: JAX-WS is correctly particular about denying access to the
> underlying
> implementation and with 2.1, EndpointReferences are first
> class citizens
> so the need will no longer arise. Long term we probably need
> to start a
> jax-ws-2.1-frontend. Short term, implementing the functionality in the
> CXF implementation objects and providing this accessor is a fast win.
> B: the ServiceImpl.getPort(EndpointReferenceType epr,..)
> simply uses the
> address info of the epr to override the address of the EndpointInfo.
> There is an issue with duplication of information between EndpointInfo
> and EPRs in the Conduit that I will address in another post.
>
>
> The Server side is more interesting.
> NumberFactoryServiceImpl.create() needs to produce
> EndpointReferenceTypes (EPRs) for the NumberService that identity a
> particular number. First it inits and publishes a NumerServiceImpl
> servant. On the trunk this requires working with
> EndpointReferenceUtils
> to flesh out a valid EPR. My default implementation uses EPR
> referenceParameters to contain the unique Id and WS-A to propagate the
> target address. This has the advantage of being transport
> neutral but it
> is over kill for some transports. For example, for a
> transport like http
> or Yoko, it is possible to embed the unique Id into the endpoint
> address, append it to the context in http (context match based on
> startsWith) or for Yoko, burn it into a default servant
> object key. Then
> the need for WS-A disappears. This pushes the detail of EPR creation
> with a unique Id onto the transport/Destination.
>
> I am thinking along the lines of an extension to Destination that
> transports can optionally support.
>
> /**
> * A MultiplexDestination is a transport-level endpoint capable of
> receiving
> * unsolicited incoming messages from different peers for multiple
> targets
> * identified by a unique id.
> * The disambiguation of targets is handled by higher layers as the
> target
> * address is made available as a context property or as a WS-A-To
> header
> */
>
> public interface MultiplexDestination extends Destination {
>
> /**
> * @return the a reference containing the id that is
> * associated with this Destination
> */
> EndpointReferenceType getAddressWithId(String id);
>
> /**
> * @param contextMap for this invocation, for example from
> * JAX-WS WebServiceContext.getMessageContext(). The context will
> * either contain the WS-A To content and/or some property that
> * identifies the target address, eg MessageContext.PATH_INFO for
> * the current invocation
> * @return the id associated with the current invocation
> */
> String getId(Map contextMap);
> }
>
> The default implementation in AbstractMultiplexDestination can map the
> uniqueId to an EPR referenceParameter and propagate via WSA in a
> transport neutral way. AbstractHttpDestination can optionally override
> the default to make use of the address context for a more
> efficient and
> natural http implementation.
>
> From a users perspective, a unique server side epr would be
> resolved/created from a existing published service using
>
> EndpointRefernceType epr =
>
> EndpointReferenceUtils.getEndpointReferenceWithId(NUMBER_SERVI
> CE_QNAME,
> null, // portName
> uniqueId,
> BusFactory.getDefaultBus());
>
> Note: The portName should allow a particular port among many in a
> service, to be identified.
>
> Where EndpointReferenceUtils goes as follows:
>
> public static EndpointReferenceType getEndpointReferenceWithId(QName
> serviceQName, String portMame, String id, Bus bus) {
> EndpointReferenceType epr = null;
> ServerRegistry serverRegistry = (ServerRegistry)
> bus.getExtension(ServerRegistry.class);
> List<Server> servers = serverRegistry.getServers();
> for (Server s : servers) {
> QName targetServiceQName =
> s.getEndpoint().getEndpointInfo().getService().getName();
> if (serviceQName.equals(targetServiceQName)) {
> Destination dest = s.getDestination();
> if (dest instanceof MultiplexDestination) {
> epr =
> ((MultiplexDestination)dest).getEndpointReferenceWithId(id);
> break;
> }
> }
> return epr;
>
> Also
> public static String getCurrentEndpointReferenceId(Map context, Bus
> bus) {
> ...
> }
>
> During an invocation (server dispatch) accessing the current target
> EndpointReference needs a little work however. The JAX-WS
> MessageContext
> Map contains all the required information as properties. The
> MultiplexedDestination can use this information to locate and extract
> the uniqueId for this current request. The use of Map in the api keeps
> the EndpointReferenceUtils front-end neutral and the
> MultiplexedDestination transport neutral.
>
>
> Having to traverse the list of registered services in is a bit
> cumbersome, would it be possible to have services registered
> by Service
> QName? Or would that restrict us to single instance services. It could
> be map<QName, List<Service>>.
>
>
> Bernd, does this nail your use case?
>
> All, Does it make sense?
>
> Comments appreciated, I would like to further this into a proposal in
> the near future.
>
> Thanks,
> Gary.
>
>
>
> > -----Original Message-----
> > From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> > Sent: 23 March 2007 13:13
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Support for stateful services in CXF
> >
> > Hi Gary,
> >
> > thanks a lot for your reply.
> >
> > Tully, Gary wrote:
> > >
> > > Only yesterday I started to investigate providing simple
> > support for a
> > > single instance service that can represent many WS-addressing
> > > identities.
> > >
> > > What I am after at the moment is a simpler version of what is
> > > supported by @Stateful in the JAX-WS RI. The only state is
> > a unique-id
> > > that is encapsulated in the WS-Address.
> >
> > That looks like a starting point...
> >
> > [...]
> >
> > > At the moment I am capturing the FactoryPattern use-case as
> > a system
> > > test in order to provide a starting proof-point for an
> > implementation.
> > >
> > > The use of WS-Context (thanks Sergey) or HTTP session
> > information as a
> > > means of determining unique id would be neat but I think this is
> > > orthogonal.
> >
> > agreed.
> >
> > > From a WS-RF point of view, what are the usage scenarios
> > that you will
> > > need? Do they lend them selves to capture as system tests?
> >
> > The basic scenario is approximately
> > - allow for instance creation on a stateful service, for
> > example using a
> > Factory service
> > - deal with state, e.g. persist instances to some
> permanent storage
> > - manage instance lifecycle, manage their lifetime, destroy them
> > - allow clients to access instances by EPR / WS-Addressing
> > This can be captured by system tests, I guess.
> >
> > > Like you, I am learning as I go here, so any input is appreciated,
> > > especially your ideas on improving @Stateful and your experiences
> > > doing something similar with Xfire.
> >
> > My main improvements on the JAX-WS RI @Stateful would be to
> > try and make the whole instance resolving process, instance
> > lifecycle management and EPR creation much more flexible, and
> > give more control to the application programmer.
> > Of course all this should fit in as nicely as possible in the
> > CXF environment, which I unfortunately don't know much about yet...
> >
> > In my XFire implementation, things were fairly easy, because
> > I could hook into the mechanism that XFire uses to get the
> > service object (the Invoker). Figure out the unique id from
> > the message context, re-create the requested service instance
> > from permanent storage, restore its state, and invoke the operation.
> >
> > Maybe something similar can be done in CXF.
> >
> > > As I am only starting on my quest for a design, you may as
> > well give
> > > it a try from your perspective. We can swap ideas or
> experiences to
> > > come up with a working solution. It need not be a race :-)
> >
> > Perfect!
> >
> > Thanks, and best regards,
> > Bernd.
> >
> >
> > >> -----Original Message-----
> > >> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> > >> Sent: 23 March 2007 07:36
> > >> To: CXF devel
> > >> Subject: Support for stateful services in CXF [...] 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 b.schuller@fz-juelich.de
> > phone +49 2461 61 8736
> > fax +49 2461 61 6656
> > blog http://www.jroller.com/page/gridhaus
> >
> >
>
>
Re: Support for stateful services in CXF
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
"is over kill for some transports. For example, for a transport like http
or Yoko, it is possible to embed the unique Id into the endpoint
address" ...
IMHO this is what should happen for HTTP because this will make individul number services addressable...Using EPR parameters to
convey the unique id looses the identity of the service endpoint.
Sorry if my comments would seem a bit academic in the scope of your very interesting and more important, *practical* proposal. It's
just that CXF shows the lead in letting people to build resful services, etc, so I feel that trying to pursue the general idea of
bringing even purely SOAP-based services closer to the web, when possible, would be good. We can imagine then SOAP Number services
being able to GET-reply with their state while still being able to process soap post increment/decrement requests, etc...This will
increase the value of the Number service. Actually, have just seen your comment that AbstractHTTPDestination can be used for this,
sounds great, perhaps this can be used to enhance the way things work with http in the future !
If even for HTTP the WSA header will be sent to the service to indicate what instance the invocation should be made againt then it
would be in general mean the explicit context is used, which is good, but I hope you can see now why I was referring to WS-Context
earlier, one can imagine passing a WS_Context header to the Number service indicating an application level context, the number on
which the service should perform the even check....so even though WS-Context is probably more natural for dealing with higher-level
activities, it may work with the application-level ones too
Overall it's a great start...
Thanks, Sergey
----- Original Message -----
From: "Tully, Gary" <Ga...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Wednesday, April 04, 2007 5:40 PM
Subject: RE: Support for stateful services in CXF
Hi Bernd, all,
I have been toying around with my default servant test cases and
implementing as I go. My test case determines if Numbers are even by
accessing a particular Number instance from a NumberFactory (via create)
and using the returned reference to invoke the isEven() operation.
Trivial but illustrative I hope.
To make the implementation work/scale on the Server, a single stateless
servant represents all possible numbers and determines its current
identity based on the details of its current/target Endpoint Reference.
My client code does the following:
NumberFactoryService service = new NumberFactoryService();
NumberFactory factory = service.getNumberFactoryPort();
EndpointReferenceType numberTwoRef = factory.create("2");
NumberService numService = new NumberService();
A. ServiceImpl serviceImpl =
ServiceDelegateAccessor.get(numService);
B. Number num = (Number)serviceImpl.getPort(numberTwoRef,
Number.class);
assertTrue("2 is even", num.isEven().isEven());
Of interest here is:
A: JAX-WS is correctly particular about denying access to the underlying
implementation and with 2.1, EndpointReferences are first class citizens
so the need will no longer arise. Long term we probably need to start a
jax-ws-2.1-frontend. Short term, implementing the functionality in the
CXF implementation objects and providing this accessor is a fast win.
B: the ServiceImpl.getPort(EndpointReferenceType epr,..) simply uses the
address info of the epr to override the address of the EndpointInfo.
There is an issue with duplication of information between EndpointInfo
and EPRs in the Conduit that I will address in another post.
The Server side is more interesting.
NumberFactoryServiceImpl.create() needs to produce
EndpointReferenceTypes (EPRs) for the NumberService that identity a
particular number. First it inits and publishes a NumerServiceImpl
servant. On the trunk this requires working with EndpointReferenceUtils
to flesh out a valid EPR. My default implementation uses EPR
referenceParameters to contain the unique Id and WS-A to propagate the
target address. This has the advantage of being transport neutral but it
is over kill for some transports. For example, for a transport like http
or Yoko, it is possible to embed the unique Id into the endpoint
address, append it to the context in http (context match based on
startsWith) or for Yoko, burn it into a default servant object key. Then
the need for WS-A disappears. This pushes the detail of EPR creation
with a unique Id onto the transport/Destination.
I am thinking along the lines of an extension to Destination that
transports can optionally support.
/**
* A MultiplexDestination is a transport-level endpoint capable of
receiving
* unsolicited incoming messages from different peers for multiple
targets
* identified by a unique id.
* The disambiguation of targets is handled by higher layers as the
target
* address is made available as a context property or as a WS-A-To
header
*/
public interface MultiplexDestination extends Destination {
/**
* @return the a reference containing the id that is
* associated with this Destination
*/
EndpointReferenceType getAddressWithId(String id);
/**
* @param contextMap for this invocation, for example from
* JAX-WS WebServiceContext.getMessageContext(). The context will
* either contain the WS-A To content and/or some property that
* identifies the target address, eg MessageContext.PATH_INFO for
* the current invocation
* @return the id associated with the current invocation
*/
String getId(Map contextMap);
}
The default implementation in AbstractMultiplexDestination can map the
uniqueId to an EPR referenceParameter and propagate via WSA in a
transport neutral way. AbstractHttpDestination can optionally override
the default to make use of the address context for a more efficient and
natural http implementation.
>From a users perspective, a unique server side epr would be
resolved/created from a existing published service using
EndpointRefernceType epr =
EndpointReferenceUtils.getEndpointReferenceWithId(NUMBER_SERVICE_QNAME,
null, // portName
uniqueId,
BusFactory.getDefaultBus());
Note: The portName should allow a particular port among many in a
service, to be identified.
Where EndpointReferenceUtils goes as follows:
public static EndpointReferenceType getEndpointReferenceWithId(QName
serviceQName, String portMame, String id, Bus bus) {
EndpointReferenceType epr = null;
ServerRegistry serverRegistry = (ServerRegistry)
bus.getExtension(ServerRegistry.class);
List<Server> servers = serverRegistry.getServers();
for (Server s : servers) {
QName targetServiceQName =
s.getEndpoint().getEndpointInfo().getService().getName();
if (serviceQName.equals(targetServiceQName)) {
Destination dest = s.getDestination();
if (dest instanceof MultiplexDestination) {
epr =
((MultiplexDestination)dest).getEndpointReferenceWithId(id);
break;
}
}
return epr;
Also
public static String getCurrentEndpointReferenceId(Map context, Bus
bus) {
...
}
During an invocation (server dispatch) accessing the current target
EndpointReference needs a little work however. The JAX-WS MessageContext
Map contains all the required information as properties. The
MultiplexedDestination can use this information to locate and extract
the uniqueId for this current request. The use of Map in the api keeps
the EndpointReferenceUtils front-end neutral and the
MultiplexedDestination transport neutral.
Having to traverse the list of registered services in is a bit
cumbersome, would it be possible to have services registered by Service
QName? Or would that restrict us to single instance services. It could
be map<QName, List<Service>>.
Bernd, does this nail your use case?
All, Does it make sense?
Comments appreciated, I would like to further this into a proposal in
the near future.
Thanks,
Gary.
> -----Original Message-----
> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> Sent: 23 March 2007 13:13
> To: cxf-dev@incubator.apache.org
> Subject: Re: Support for stateful services in CXF
>
> Hi Gary,
>
> thanks a lot for your reply.
>
> Tully, Gary wrote:
> >
> > Only yesterday I started to investigate providing simple
> support for a
> > single instance service that can represent many WS-addressing
> > identities.
> >
> > What I am after at the moment is a simpler version of what is
> > supported by @Stateful in the JAX-WS RI. The only state is
> a unique-id
> > that is encapsulated in the WS-Address.
>
> That looks like a starting point...
>
> [...]
>
> > At the moment I am capturing the FactoryPattern use-case as
> a system
> > test in order to provide a starting proof-point for an
> implementation.
> >
> > The use of WS-Context (thanks Sergey) or HTTP session
> information as a
> > means of determining unique id would be neat but I think this is
> > orthogonal.
>
> agreed.
>
> > From a WS-RF point of view, what are the usage scenarios
> that you will
> > need? Do they lend them selves to capture as system tests?
>
> The basic scenario is approximately
> - allow for instance creation on a stateful service, for
> example using a
> Factory service
> - deal with state, e.g. persist instances to some permanent storage
> - manage instance lifecycle, manage their lifetime, destroy them
> - allow clients to access instances by EPR / WS-Addressing
> This can be captured by system tests, I guess.
>
> > Like you, I am learning as I go here, so any input is appreciated,
> > especially your ideas on improving @Stateful and your experiences
> > doing something similar with Xfire.
>
> My main improvements on the JAX-WS RI @Stateful would be to
> try and make the whole instance resolving process, instance
> lifecycle management and EPR creation much more flexible, and
> give more control to the application programmer.
> Of course all this should fit in as nicely as possible in the
> CXF environment, which I unfortunately don't know much about yet...
>
> In my XFire implementation, things were fairly easy, because
> I could hook into the mechanism that XFire uses to get the
> service object (the Invoker). Figure out the unique id from
> the message context, re-create the requested service instance
> from permanent storage, restore its state, and invoke the operation.
>
> Maybe something similar can be done in CXF.
>
> > As I am only starting on my quest for a design, you may as
> well give
> > it a try from your perspective. We can swap ideas or experiences to
> > come up with a working solution. It need not be a race :-)
>
> Perfect!
>
> Thanks, and best regards,
> Bernd.
>
>
> >> -----Original Message-----
> >> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> >> Sent: 23 March 2007 07:36
> >> To: CXF devel
> >> Subject: Support for stateful services in CXF [...] 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 b.schuller@fz-juelich.de
> phone +49 2461 61 8736
> fax +49 2461 61 6656
> blog http://www.jroller.com/page/gridhaus
>
>
RE: Support for stateful services in CXF
Posted by "Tully, Gary" <Ga...@iona.com>.
I have added a description/explanation of the feature at
http://cwiki.apache.org/confluence/display/CXF20DOC/Multiplexed+Endpoint
References
Linked to from "Advanced Integration"
Gary.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 20 April 2007 20:19
> To: cxf-dev@incubator.apache.org
> Subject: Re: Support for stateful services in CXF
>
> Gary - any chance you could add a quick write up of how it
> works to the user's guide? Maybe a quick How-To?
>
> - Dan
>
> On 4/20/07, Bernd Schuller <b....@fz-juelich.de> wrote:
> >
> > Hi Gary and CXF crowd,
> >
> > thank you :)
> >
> > Glynn, Eoghan wrote:
> > > Thanks Gary, lovely green bar on Linux for the latest
> version of the
> > > patch, committing now ...
> > >
> > > -----Original Message-----
> > >> From: Tully, Gary [mailto:Gary.Tully@iona.com]
> > >> Sent: 19 April 2007 20:11
> > >> To: cxf-dev@incubator.apache.org
> > >> Subject: RE: Support for stateful services in CXF
> > >>
> > >> Hi,
> > >> I have submitted a patch[1] via
> > >> https://issues.apache.org/jira/browse/CXF-542 that provides
> > >>support for stateful services.
> > >>[...]
> >
> > --
> > Dr. Bernd Schuller
> >
> > Central Institute for Applied Mathematics Forschungszentrum Juelich
> > GmbH
> >
> > mail b.schuller@fz-juelich.de
> > phone +49 2461 61 8736
> > fax +49 2461 61 6656
> > blog http://www.jroller.com/page/gridhaus
> >
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
RE: Support for stateful services in CXF
Posted by "Tully, Gary" <Ga...@iona.com>.
Have it on my to-do list so will get it there shortly.
Gary.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 20 April 2007 20:19
> To: cxf-dev@incubator.apache.org
> Subject: Re: Support for stateful services in CXF
>
> Gary - any chance you could add a quick write up of how it
> works to the user's guide? Maybe a quick How-To?
>
> - Dan
>
> On 4/20/07, Bernd Schuller <b....@fz-juelich.de> wrote:
> >
> > Hi Gary and CXF crowd,
> >
> > thank you :)
> >
> > Glynn, Eoghan wrote:
> > > Thanks Gary, lovely green bar on Linux for the latest
> version of the
> > > patch, committing now ...
> > >
> > > -----Original Message-----
> > >> From: Tully, Gary [mailto:Gary.Tully@iona.com]
> > >> Sent: 19 April 2007 20:11
> > >> To: cxf-dev@incubator.apache.org
> > >> Subject: RE: Support for stateful services in CXF
> > >>
> > >> Hi,
> > >> I have submitted a patch[1] via
> > >> https://issues.apache.org/jira/browse/CXF-542 that provides
> > >>support for stateful services.
> > >>[...]
> >
> > --
> > Dr. Bernd Schuller
> >
> > Central Institute for Applied Mathematics Forschungszentrum Juelich
> > GmbH
> >
> > mail b.schuller@fz-juelich.de
> > phone +49 2461 61 8736
> > fax +49 2461 61 6656
> > blog http://www.jroller.com/page/gridhaus
> >
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Support for stateful services in CXF
Posted by Dan Diephouse <da...@envoisolutions.com>.
Gary - any chance you could add a quick write up of how it works to the
user's guide? Maybe a quick How-To?
- Dan
On 4/20/07, Bernd Schuller <b....@fz-juelich.de> wrote:
>
> Hi Gary and CXF crowd,
>
> thank you :)
>
> Glynn, Eoghan wrote:
> > Thanks Gary, lovely green bar on Linux for the latest version of the
> > patch, committing now ...
> >
> > -----Original Message-----
> >> From: Tully, Gary [mailto:Gary.Tully@iona.com]
> >> Sent: 19 April 2007 20:11
> >> To: cxf-dev@incubator.apache.org
> >> Subject: RE: Support for stateful services in CXF
> >>
> >> Hi,
> >> I have submitted a patch[1] via
> >> https://issues.apache.org/jira/browse/CXF-542 that provides
> >> support for stateful services.
> >>[...]
>
> --
> Dr. Bernd Schuller
>
> Central Institute for Applied Mathematics
> Forschungszentrum Juelich GmbH
>
> mail b.schuller@fz-juelich.de
> phone +49 2461 61 8736
> fax +49 2461 61 6656
> blog http://www.jroller.com/page/gridhaus
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Support for stateful services in CXF
Posted by Bernd Schuller <b....@fz-juelich.de>.
Hi Gary and CXF crowd,
thank you :)
Glynn, Eoghan wrote:
> Thanks Gary, lovely green bar on Linux for the latest version of the
> patch, committing now ...
>
> -----Original Message-----
>> From: Tully, Gary [mailto:Gary.Tully@iona.com]
>> Sent: 19 April 2007 20:11
>> To: cxf-dev@incubator.apache.org
>> Subject: RE: Support for stateful services in CXF
>>
>> Hi,
>> I have submitted a patch[1] via
>> https://issues.apache.org/jira/browse/CXF-542 that provides
>> support for stateful services.
>>[...]
--
Dr. Bernd Schuller
Central Institute for Applied Mathematics
Forschungszentrum Juelich GmbH
mail b.schuller@fz-juelich.de
phone +49 2461 61 8736
fax +49 2461 61 6656
blog http://www.jroller.com/page/gridhaus
RE: Support for stateful services in CXF
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Thanks Gary, lovely green bar on Linux for the latest version of the
patch, committing now ...
Cheers,
Eoghan
> -----Original Message-----
> From: Tully, Gary [mailto:Gary.Tully@iona.com]
> Sent: 19 April 2007 20:11
> To: cxf-dev@incubator.apache.org
> Subject: RE: Support for stateful services in CXF
>
> Hi,
> I have submitted a patch[1] via
> https://issues.apache.org/jira/browse/CXF-542 that provides
> support for stateful services.
> The implementation uses WS-A referenceParameters to encode
> the state which is provided in the form of a String. It works
> for HTTP and JMS and any other transport that want to extend
> AbstractMultiplexDestination.
> The HTTP destination supports a config attribute called
> multiplexWithAddress which forces it to embesd the id in the
> URL context and negates the need for WS-A. This property is
> false by default.
>
> The API used by application programmers is in EndpointReferenceUtils.
> Once a single template or multiplex service is published, the
> getEndpointReferenceWithId() method allows unique (identified
> by a String id) references to this service to be generated.
> During dispatch, the template or multiplex service can
> determine the current id using getEndpointReferenceId(). This
> state can then be used to service the request. A typical
> scenario would use the state as a key to a database table.
>
> The salient server side API is as follows:
>
> /**
> * Obtain a multiplexed endpoint reference for the
> deployed service that contains the provided id
> * @param serviceQName identified the target service
> * @param portName identifies a particular port of the
> service, may be null
> * @param id that must be embedded in the returned reference
> * @param bus the current bus
> * @return a new reference or null if the target
> destination does not support destination multiplexing
> */
> public static EndpointReferenceType
> getEndpointReferenceWithId(QName serviceQName,
>
> String portName,
>
> String id,
>
> Bus bus);
>
> /**
> * Obtain the id String from the endpoint reference of
> the current dispatch.
> * @param contextMap the current message context
> * @return the id embedded in the current endpoint
> reference or null if not found
> */
> public static String getEndpointReferenceId(Map messageContext);
>
>
> On the client, ServiceImpl now supports
> getPort(EndpointReferenceType), an API that is not unlike
> JAX-WS 2.0 that makes it easy for a client to directly use an
> EndpointReference. More details can be found below in this thread.
>
> I had a quick chat with Eoghan via IM who will give this the
> once over tomorrow and with a bit of luck the required blessing.
> Comments welcome.
>
> Thanks,
> Gary.
>
> [1]
> https://issues.apache.org/jira/secure/attachment/12355834/mult
> iplex-cxf-
> 542.1.patch
>
> > -----Original Message-----
> > From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> > Sent: 05 April 2007 11:16
> > To: cxf-dev@incubator.apache.org
> > Subject: RE: Support for stateful services in CXF
> >
> >
> >
> > All good stuff, Gary.
> >
> > Just one small point to clarify ... suppose the transport
> in use (say
> > HTTP or CORBA) has a native mechanism for encoding the uniqueID
> > (burned into the URI or object key). Would it make sense to *also*
> > slap the uniqueID in the EPR reference params, so that if
> the client
> > happens to have WS-A enabled, then the uniqueID is passed in the
> > transport neutral way?
> > Whereas if WS-A is not enabled in the client-side dispatch
> chain, then
> > the "redundant" reference params in the EPR have no real
> effect on the
> > client processing, so no harm done.
> > This belt'n'braces approach could be configurably enabled.
> >
> > Or maybe it would make more sense to just allow these special-case
> > transports (HTTP or CORBA) to choose either the native XOR the
> > transport-neutral uniqueId encodings, again driven by config.
> >
> > Cheers,
> > Eoghan
> >
> >
> > > -----Original Message-----
> > > From: Tully, Gary [mailto:Gary.Tully@iona.com]
> > > Sent: 04 April 2007 17:40
> > > To: cxf-dev@incubator.apache.org
> > > Subject: RE: Support for stateful services in CXF
> > >
> > > Hi Bernd, all,
> > >
> > > I have been toying around with my default servant test cases and
> > > implementing as I go. My test case determines if Numbers
> > are even by
> > > accessing a particular Number instance from a NumberFactory (via
> > > create) and using the returned reference to invoke the isEven()
> > > operation.
> > > Trivial but illustrative I hope.
> > > To make the implementation work/scale on the Server, a single
> > > stateless servant represents all possible numbers and
> > determines its
> > > current identity based on the details of its current/target
> > Endpoint
> > > Reference.
> > >
> > > My client code does the following:
> > >
> > > NumberFactoryService service = new NumberFactoryService();
> > > NumberFactory factory = service.getNumberFactoryPort();
> > >
> > >
> > > EndpointReferenceType numberTwoRef = factory.create("2");
> > >
> > > NumberService numService = new NumberService();
> > > A. ServiceImpl serviceImpl =
> > > ServiceDelegateAccessor.get(numService);
> > >
> > > B. Number num = (Number)serviceImpl.getPort(numberTwoRef,
> > > Number.class);
> > > assertTrue("2 is even", num.isEven().isEven());
> > >
> > > Of interest here is:
> > > A: JAX-WS is correctly particular about denying access to the
> > > underlying implementation and with 2.1, EndpointReferences
> > are first
> > > class citizens so the need will no longer arise.
> > > Long term we probably need to start a jax-ws-2.1-frontend.
> > > Short term, implementing the functionality in the CXF
> > implementation
> > > objects and providing this accessor is a fast win.
> > > B: the ServiceImpl.getPort(EndpointReferenceType epr,..)
> > simply uses
> > > the address info of the epr to override the address of the
> > > EndpointInfo.
> > > There is an issue with duplication of information between
> > EndpointInfo
> > > and EPRs in the Conduit that I will address in another post.
> > >
> > >
> > > The Server side is more interesting.
> > > NumberFactoryServiceImpl.create() needs to produce
> > > EndpointReferenceTypes (EPRs) for the NumberService that
> identity a
> > > particular number. First it inits and publishes a
> NumerServiceImpl
> > > servant. On the trunk this requires working with
> > > EndpointReferenceUtils to flesh out a valid EPR. My default
> > > implementation uses EPR referenceParameters to contain the
> > unique Id
> > > and WS-A to propagate the target address. This has the
> advantage of
> > > being transport neutral but it is over kill for some
> > transports. For
> > > example, for a transport like http or Yoko, it is
> possible to embed
> > > the unique Id into the endpoint address, append it to the
> > context in
> > > http (context match based on
> > > startsWith) or for Yoko, burn it into a default servant
> object key.
> > > Then the need for WS-A disappears. This pushes the detail of EPR
> > > creation with a unique Id onto the transport/Destination.
> > >
> > > I am thinking along the lines of an extension to Destination that
> > > transports can optionally support.
> > >
> > > /**
> > > * A MultiplexDestination is a transport-level endpoint
> capable of
> > > receiving
> > > * unsolicited incoming messages from different peers for
> multiple
> > > targets
> > > * identified by a unique id.
> > > * The disambiguation of targets is handled by higher
> layers as the
> > > target
> > > * address is made available as a context property or as
> a WS-A-To
> > > header */
> > >
> > > public interface MultiplexDestination extends Destination {
> > >
> > > /**
> > > * @return the a reference containing the id that is
> > > * associated with this Destination
> > > */
> > > EndpointReferenceType getAddressWithId(String id);
> > >
> > > /**
> > > * @param contextMap for this invocation, for example from
> > > * JAX-WS WebServiceContext.getMessageContext(). The
> > context will
> > > * either contain the WS-A To content and/or some
> property that
> > > * identifies the target address, eg
> > MessageContext.PATH_INFO for
> > > * the current invocation
> > > * @return the id associated with the current invocation
> > > */
> > > String getId(Map contextMap);
> > > }
> > >
> > > The default implementation in AbstractMultiplexDestination
> > can map the
> > > uniqueId to an EPR referenceParameter and propagate via WSA in a
> > > transport neutral way.
> > > AbstractHttpDestination can optionally override the
> default to make
> > > use of the address context for a more efficient and natural http
> > > implementation.
> > >
> > > From a users perspective, a unique server side epr would be
> > > resolved/created from a existing published service using
> > >
> > > EndpointRefernceType epr =
> > >
> > > EndpointReferenceUtils.getEndpointReferenceWithId(NUMBER_SERVI
> > > CE_QNAME,
> > > null, // portName
> > > uniqueId,
> > > BusFactory.getDefaultBus());
> > >
> > > Note: The portName should allow a particular port among many in a
> > > service, to be identified.
> > >
> > > Where EndpointReferenceUtils goes as follows:
> > >
> > > public static EndpointReferenceType
> > > getEndpointReferenceWithId(QName serviceQName, String
> > portMame, String
> > > id, Bus bus) {
> > > EndpointReferenceType epr = null;
> > > ServerRegistry serverRegistry = (ServerRegistry)
> > > bus.getExtension(ServerRegistry.class);
> > > List<Server> servers = serverRegistry.getServers();
> > > for (Server s : servers) {
> > > QName targetServiceQName =
> > > s.getEndpoint().getEndpointInfo().getService().getName();
> > > if (serviceQName.equals(targetServiceQName)) {
> > > Destination dest = s.getDestination();
> > > if (dest instanceof MultiplexDestination) {
> > > epr =
> > > ((MultiplexDestination)dest).getEndpointReferenceWithId(id);
> > > break;
> > > }
> > > }
> > > return epr;
> > >
> > > Also
> > > public static String getCurrentEndpointReferenceId(Map
> context, Bus
> > > bus) {
> > > ...
> > > }
> > >
> > > During an invocation (server dispatch) accessing the
> current target
> > > EndpointReference needs a little work however. The JAX-WS
> > > MessageContext Map contains all the required information as
> > > properties. The MultiplexedDestination can use this
> information to
> > > locate and extract the uniqueId for this current request.
> > The use of
> > > Map in the api keeps the EndpointReferenceUtils front-end
> > neutral and
> > > the MultiplexedDestination transport neutral.
> > >
> > >
> > > Having to traverse the list of registered services in is a bit
> > > cumbersome, would it be possible to have services registered by
> > > Service QName? Or would that restrict us to single instance
> > > services. It could be map<QName, List<Service>>.
> > >
> > >
> > > Bernd, does this nail your use case?
> > >
> > > All, Does it make sense?
> > >
> > > Comments appreciated, I would like to further this into a
> proposal
> > > in the near future.
> > >
> > > Thanks,
> > > Gary.
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> > > > Sent: 23 March 2007 13:13
> > > > To: cxf-dev@incubator.apache.org
> > > > Subject: Re: Support for stateful services in CXF
> > > >
> > > > Hi Gary,
> > > >
> > > > thanks a lot for your reply.
> > > >
> > > > Tully, Gary wrote:
> > > > >
> > > > > Only yesterday I started to investigate providing simple
> > > > support for a
> > > > > single instance service that can represent many WS-addressing
> > > > > identities.
> > > > >
> > > > > What I am after at the moment is a simpler version of what is
> > > > > supported by @Stateful in the JAX-WS RI. The only state is
> > > > a unique-id
> > > > > that is encapsulated in the WS-Address.
> > > >
> > > > That looks like a starting point...
> > > >
> > > > [...]
> > > >
> > > > > At the moment I am capturing the FactoryPattern use-case as
> > > > a system
> > > > > test in order to provide a starting proof-point for an
> > > > implementation.
> > > > >
> > > > > The use of WS-Context (thanks Sergey) or HTTP session
> > > > information as a
> > > > > means of determining unique id would be neat but I
> > think this is
> > > > > orthogonal.
> > > >
> > > > agreed.
> > > >
> > > > > From a WS-RF point of view, what are the usage scenarios
> > > > that you will
> > > > > need? Do they lend them selves to capture as system tests?
> > > >
> > > > The basic scenario is approximately
> > > > - allow for instance creation on a stateful service,
> > for example
> > > > using a
> > > > Factory service
> > > > - deal with state, e.g. persist instances to some
> > > permanent storage
> > > > - manage instance lifecycle, manage their lifetime,
> destroy them
> > > > - allow clients to access instances by EPR /
> > > WS-Addressing This can
> > > > be captured by system tests, I guess.
> > > >
> > > > > Like you, I am learning as I go here, so any input is
> > > appreciated,
> > > > > especially your ideas on improving @Stateful and your
> > experiences
> > > > > doing something similar with Xfire.
> > > >
> > > > My main improvements on the JAX-WS RI @Stateful would be
> > to try and
> > > > make the whole instance resolving process, instance lifecycle
> > > > management and EPR creation much more flexible, and give
> > > more control
> > > > to the application programmer.
> > > > Of course all this should fit in as nicely as possible
> in the CXF
> > > > environment, which I unfortunately don't know much about yet...
> > > >
> > > > In my XFire implementation, things were fairly easy,
> > > because I could
> > > > hook into the mechanism that XFire uses to get the service
> > > object (the
> > > > Invoker). Figure out the unique id from the message
> > > context, re-create
> > > > the requested service instance from permanent storage,
> > restore its
> > > > state, and invoke the operation.
> > > >
> > > > Maybe something similar can be done in CXF.
> > > >
> > > > > As I am only starting on my quest for a design, you may as
> > > > well give
> > > > > it a try from your perspective. We can swap ideas or
> > > experiences to
> > > > > come up with a working solution. It need not be a race :-)
> > > >
> > > > Perfect!
> > > >
> > > > Thanks, and best regards,
> > > > Bernd.
> > > >
> > > >
> > > > >> -----Original Message-----
> > > > >> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> > > > >> Sent: 23 March 2007 07:36
> > > > >> To: CXF devel
> > > > >> Subject: Support for stateful services in CXF [...] 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 b.schuller@fz-juelich.de
> > > > phone +49 2461 61 8736
> > > > fax +49 2461 61 6656
> > > > blog http://www.jroller.com/page/gridhaus
> > > >
> > > >
> > >
> >
>
RE: Support for stateful services in CXF
Posted by "Tully, Gary" <Ga...@iona.com>.
Hi,
I have submitted a patch[1] via
https://issues.apache.org/jira/browse/CXF-542 that provides support for
stateful services.
The implementation uses WS-A referenceParameters to encode the state
which is provided in the form of a String. It works for HTTP and JMS and
any other transport that want to extend AbstractMultiplexDestination.
The HTTP destination supports a config attribute called
multiplexWithAddress which forces it to embesd the id in the URL context
and negates the need for WS-A. This property is false by default.
The API used by application programmers is in EndpointReferenceUtils.
Once a single template or multiplex service is published, the
getEndpointReferenceWithId() method allows unique (identified by a
String id) references to this service to be generated. During dispatch,
the template or multiplex service can determine the current id using
getEndpointReferenceId(). This state can then be used to service the
request. A typical scenario would use the state as a key to a database
table.
The salient server side API is as follows:
/**
* Obtain a multiplexed endpoint reference for the deployed service
that contains the provided id
* @param serviceQName identified the target service
* @param portName identifies a particular port of the service, may
be null
* @param id that must be embedded in the returned reference
* @param bus the current bus
* @return a new reference or null if the target destination does
not support destination multiplexing
*/
public static EndpointReferenceType getEndpointReferenceWithId(QName
serviceQName,
String portName,
String id,
Bus
bus);
/**
* Obtain the id String from the endpoint reference of the current
dispatch.
* @param contextMap the current message context
* @return the id embedded in the current endpoint reference or null
if not found
*/
public static String getEndpointReferenceId(Map messageContext);
On the client, ServiceImpl now supports getPort(EndpointReferenceType),
an API that is not unlike JAX-WS 2.0 that makes it easy for a client to
directly use an EndpointReference. More details can be found below in
this thread.
I had a quick chat with Eoghan via IM who will give this the once over
tomorrow and with a bit of luck the required blessing.
Comments welcome.
Thanks,
Gary.
[1]
https://issues.apache.org/jira/secure/attachment/12355834/multiplex-cxf-
542.1.patch
> -----Original Message-----
> From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> Sent: 05 April 2007 11:16
> To: cxf-dev@incubator.apache.org
> Subject: RE: Support for stateful services in CXF
>
>
>
> All good stuff, Gary.
>
> Just one small point to clarify ... suppose the transport in
> use (say HTTP or CORBA) has a native mechanism for encoding
> the uniqueID (burned into the URI or object key). Would it
> make sense to *also* slap the uniqueID in the EPR reference
> params, so that if the client happens to have WS-A enabled,
> then the uniqueID is passed in the transport neutral way?
> Whereas if WS-A is not enabled in the client-side dispatch
> chain, then the "redundant" reference params in the EPR have
> no real effect on the client processing, so no harm done.
> This belt'n'braces approach could be configurably enabled.
>
> Or maybe it would make more sense to just allow these
> special-case transports (HTTP or CORBA) to choose either the
> native XOR the transport-neutral uniqueId encodings, again
> driven by config.
>
> Cheers,
> Eoghan
>
>
> > -----Original Message-----
> > From: Tully, Gary [mailto:Gary.Tully@iona.com]
> > Sent: 04 April 2007 17:40
> > To: cxf-dev@incubator.apache.org
> > Subject: RE: Support for stateful services in CXF
> >
> > Hi Bernd, all,
> >
> > I have been toying around with my default servant test cases and
> > implementing as I go. My test case determines if Numbers
> are even by
> > accessing a particular Number instance from a NumberFactory (via
> > create) and using the returned reference to invoke the isEven()
> > operation.
> > Trivial but illustrative I hope.
> > To make the implementation work/scale on the Server, a single
> > stateless servant represents all possible numbers and
> determines its
> > current identity based on the details of its current/target
> Endpoint
> > Reference.
> >
> > My client code does the following:
> >
> > NumberFactoryService service = new NumberFactoryService();
> > NumberFactory factory = service.getNumberFactoryPort();
> >
> >
> > EndpointReferenceType numberTwoRef = factory.create("2");
> >
> > NumberService numService = new NumberService();
> > A. ServiceImpl serviceImpl =
> > ServiceDelegateAccessor.get(numService);
> >
> > B. Number num = (Number)serviceImpl.getPort(numberTwoRef,
> > Number.class);
> > assertTrue("2 is even", num.isEven().isEven());
> >
> > Of interest here is:
> > A: JAX-WS is correctly particular about denying access to the
> > underlying implementation and with 2.1, EndpointReferences
> are first
> > class citizens so the need will no longer arise.
> > Long term we probably need to start a jax-ws-2.1-frontend.
> > Short term, implementing the functionality in the CXF
> implementation
> > objects and providing this accessor is a fast win.
> > B: the ServiceImpl.getPort(EndpointReferenceType epr,..)
> simply uses
> > the address info of the epr to override the address of the
> > EndpointInfo.
> > There is an issue with duplication of information between
> EndpointInfo
> > and EPRs in the Conduit that I will address in another post.
> >
> >
> > The Server side is more interesting.
> > NumberFactoryServiceImpl.create() needs to produce
> > EndpointReferenceTypes (EPRs) for the NumberService that identity a
> > particular number. First it inits and publishes a NumerServiceImpl
> > servant. On the trunk this requires working with
> > EndpointReferenceUtils to flesh out a valid EPR. My default
> > implementation uses EPR referenceParameters to contain the
> unique Id
> > and WS-A to propagate the target address. This has the advantage of
> > being transport neutral but it is over kill for some
> transports. For
> > example, for a transport like http or Yoko, it is possible to embed
> > the unique Id into the endpoint address, append it to the
> context in
> > http (context match based on
> > startsWith) or for Yoko, burn it into a default servant object key.
> > Then the need for WS-A disappears. This pushes the detail of EPR
> > creation with a unique Id onto the transport/Destination.
> >
> > I am thinking along the lines of an extension to Destination that
> > transports can optionally support.
> >
> > /**
> > * A MultiplexDestination is a transport-level endpoint capable of
> > receiving
> > * unsolicited incoming messages from different peers for multiple
> > targets
> > * identified by a unique id.
> > * The disambiguation of targets is handled by higher layers as the
> > target
> > * address is made available as a context property or as a WS-A-To
> > header */
> >
> > public interface MultiplexDestination extends Destination {
> >
> > /**
> > * @return the a reference containing the id that is
> > * associated with this Destination
> > */
> > EndpointReferenceType getAddressWithId(String id);
> >
> > /**
> > * @param contextMap for this invocation, for example from
> > * JAX-WS WebServiceContext.getMessageContext(). The
> context will
> > * either contain the WS-A To content and/or some property that
> > * identifies the target address, eg
> MessageContext.PATH_INFO for
> > * the current invocation
> > * @return the id associated with the current invocation
> > */
> > String getId(Map contextMap);
> > }
> >
> > The default implementation in AbstractMultiplexDestination
> can map the
> > uniqueId to an EPR referenceParameter and propagate via WSA in a
> > transport neutral way.
> > AbstractHttpDestination can optionally override the default to make
> > use of the address context for a more efficient and natural http
> > implementation.
> >
> > From a users perspective, a unique server side epr would be
> > resolved/created from a existing published service using
> >
> > EndpointRefernceType epr =
> >
> > EndpointReferenceUtils.getEndpointReferenceWithId(NUMBER_SERVI
> > CE_QNAME,
> > null, // portName
> > uniqueId,
> > BusFactory.getDefaultBus());
> >
> > Note: The portName should allow a particular port among many in a
> > service, to be identified.
> >
> > Where EndpointReferenceUtils goes as follows:
> >
> > public static EndpointReferenceType
> > getEndpointReferenceWithId(QName serviceQName, String
> portMame, String
> > id, Bus bus) {
> > EndpointReferenceType epr = null;
> > ServerRegistry serverRegistry = (ServerRegistry)
> > bus.getExtension(ServerRegistry.class);
> > List<Server> servers = serverRegistry.getServers();
> > for (Server s : servers) {
> > QName targetServiceQName =
> > s.getEndpoint().getEndpointInfo().getService().getName();
> > if (serviceQName.equals(targetServiceQName)) {
> > Destination dest = s.getDestination();
> > if (dest instanceof MultiplexDestination) {
> > epr =
> > ((MultiplexDestination)dest).getEndpointReferenceWithId(id);
> > break;
> > }
> > }
> > return epr;
> >
> > Also
> > public static String getCurrentEndpointReferenceId(Map context, Bus
> > bus) {
> > ...
> > }
> >
> > During an invocation (server dispatch) accessing the current target
> > EndpointReference needs a little work however. The JAX-WS
> > MessageContext Map contains all the required information as
> > properties. The MultiplexedDestination can use this information to
> > locate and extract the uniqueId for this current request.
> The use of
> > Map in the api keeps the EndpointReferenceUtils front-end
> neutral and
> > the MultiplexedDestination transport neutral.
> >
> >
> > Having to traverse the list of registered services in is a
> > bit cumbersome, would it be possible to have services
> > registered by Service QName? Or would that restrict us to
> > single instance services. It could be map<QName, List<Service>>.
> >
> >
> > Bernd, does this nail your use case?
> >
> > All, Does it make sense?
> >
> > Comments appreciated, I would like to further this into a
> > proposal in the near future.
> >
> > Thanks,
> > Gary.
> >
> >
> >
> > > -----Original Message-----
> > > From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> > > Sent: 23 March 2007 13:13
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: Support for stateful services in CXF
> > >
> > > Hi Gary,
> > >
> > > thanks a lot for your reply.
> > >
> > > Tully, Gary wrote:
> > > >
> > > > Only yesterday I started to investigate providing simple
> > > support for a
> > > > single instance service that can represent many WS-addressing
> > > > identities.
> > > >
> > > > What I am after at the moment is a simpler version of what is
> > > > supported by @Stateful in the JAX-WS RI. The only state is
> > > a unique-id
> > > > that is encapsulated in the WS-Address.
> > >
> > > That looks like a starting point...
> > >
> > > [...]
> > >
> > > > At the moment I am capturing the FactoryPattern use-case as
> > > a system
> > > > test in order to provide a starting proof-point for an
> > > implementation.
> > > >
> > > > The use of WS-Context (thanks Sergey) or HTTP session
> > > information as a
> > > > means of determining unique id would be neat but I
> think this is
> > > > orthogonal.
> > >
> > > agreed.
> > >
> > > > From a WS-RF point of view, what are the usage scenarios
> > > that you will
> > > > need? Do they lend them selves to capture as system tests?
> > >
> > > The basic scenario is approximately
> > > - allow for instance creation on a stateful service,
> for example
> > > using a
> > > Factory service
> > > - deal with state, e.g. persist instances to some
> > permanent storage
> > > - manage instance lifecycle, manage their lifetime, destroy them
> > > - allow clients to access instances by EPR /
> > WS-Addressing This can
> > > be captured by system tests, I guess.
> > >
> > > > Like you, I am learning as I go here, so any input is
> > appreciated,
> > > > especially your ideas on improving @Stateful and your
> experiences
> > > > doing something similar with Xfire.
> > >
> > > My main improvements on the JAX-WS RI @Stateful would be
> to try and
> > > make the whole instance resolving process, instance lifecycle
> > > management and EPR creation much more flexible, and give
> > more control
> > > to the application programmer.
> > > Of course all this should fit in as nicely as possible in the CXF
> > > environment, which I unfortunately don't know much about yet...
> > >
> > > In my XFire implementation, things were fairly easy,
> > because I could
> > > hook into the mechanism that XFire uses to get the service
> > object (the
> > > Invoker). Figure out the unique id from the message
> > context, re-create
> > > the requested service instance from permanent storage,
> restore its
> > > state, and invoke the operation.
> > >
> > > Maybe something similar can be done in CXF.
> > >
> > > > As I am only starting on my quest for a design, you may as
> > > well give
> > > > it a try from your perspective. We can swap ideas or
> > experiences to
> > > > come up with a working solution. It need not be a race :-)
> > >
> > > Perfect!
> > >
> > > Thanks, and best regards,
> > > Bernd.
> > >
> > >
> > > >> -----Original Message-----
> > > >> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> > > >> Sent: 23 March 2007 07:36
> > > >> To: CXF devel
> > > >> Subject: Support for stateful services in CXF [...] 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 b.schuller@fz-juelich.de
> > > phone +49 2461 61 8736
> > > fax +49 2461 61 6656
> > > blog http://www.jroller.com/page/gridhaus
> > >
> > >
> >
>
RE: Support for stateful services in CXF
Posted by "Glynn, Eoghan" <eo...@iona.com>.
All good stuff, Gary.
Just one small point to clarify ... suppose the transport in use (say
HTTP or CORBA) has a native mechanism for encoding the uniqueID (burned
into the URI or object key). Would it make sense to *also* slap the
uniqueID in the EPR reference params, so that if the client happens to
have WS-A enabled, then the uniqueID is passed in the transport neutral
way? Whereas if WS-A is not enabled in the client-side dispatch chain,
then the "redundant" reference params in the EPR have no real effect on
the client processing, so no harm done. This belt'n'braces approach
could be configurably enabled.
Or maybe it would make more sense to just allow these special-case
transports (HTTP or CORBA) to choose either the native XOR the
transport-neutral uniqueId encodings, again driven by config.
Cheers,
Eoghan
> -----Original Message-----
> From: Tully, Gary [mailto:Gary.Tully@iona.com]
> Sent: 04 April 2007 17:40
> To: cxf-dev@incubator.apache.org
> Subject: RE: Support for stateful services in CXF
>
> Hi Bernd, all,
>
> I have been toying around with my default servant test cases
> and implementing as I go. My test case determines if Numbers
> are even by accessing a particular Number instance from a
> NumberFactory (via create) and using the returned reference
> to invoke the isEven() operation.
> Trivial but illustrative I hope.
> To make the implementation work/scale on the Server, a single
> stateless servant represents all possible numbers and
> determines its current identity based on the details of its
> current/target Endpoint Reference.
>
> My client code does the following:
>
> NumberFactoryService service = new NumberFactoryService();
> NumberFactory factory = service.getNumberFactoryPort();
>
>
> EndpointReferenceType numberTwoRef = factory.create("2");
>
> NumberService numService = new NumberService();
> A. ServiceImpl serviceImpl =
> ServiceDelegateAccessor.get(numService);
>
> B. Number num = (Number)serviceImpl.getPort(numberTwoRef,
> Number.class);
> assertTrue("2 is even", num.isEven().isEven());
>
> Of interest here is:
> A: JAX-WS is correctly particular about denying access to the
> underlying implementation and with 2.1, EndpointReferences
> are first class citizens so the need will no longer arise.
> Long term we probably need to start a jax-ws-2.1-frontend.
> Short term, implementing the functionality in the CXF
> implementation objects and providing this accessor is a fast win.
> B: the ServiceImpl.getPort(EndpointReferenceType epr,..)
> simply uses the address info of the epr to override the
> address of the EndpointInfo.
> There is an issue with duplication of information between
> EndpointInfo and EPRs in the Conduit that I will address in
> another post.
>
>
> The Server side is more interesting.
> NumberFactoryServiceImpl.create() needs to produce
> EndpointReferenceTypes (EPRs) for the NumberService that
> identity a particular number. First it inits and publishes a
> NumerServiceImpl servant. On the trunk this requires working
> with EndpointReferenceUtils to flesh out a valid EPR. My
> default implementation uses EPR referenceParameters to
> contain the unique Id and WS-A to propagate the target
> address. This has the advantage of being transport neutral
> but it is over kill for some transports. For example, for a
> transport like http or Yoko, it is possible to embed the
> unique Id into the endpoint address, append it to the context
> in http (context match based on
> startsWith) or for Yoko, burn it into a default servant
> object key. Then the need for WS-A disappears. This pushes
> the detail of EPR creation with a unique Id onto the
> transport/Destination.
>
> I am thinking along the lines of an extension to Destination
> that transports can optionally support.
>
> /**
> * A MultiplexDestination is a transport-level endpoint
> capable of receiving
> * unsolicited incoming messages from different peers for
> multiple targets
> * identified by a unique id.
> * The disambiguation of targets is handled by higher layers
> as the target
> * address is made available as a context property or as a
> WS-A-To header */
>
> public interface MultiplexDestination extends Destination {
>
> /**
> * @return the a reference containing the id that is
> * associated with this Destination
> */
> EndpointReferenceType getAddressWithId(String id);
>
> /**
> * @param contextMap for this invocation, for example from
> * JAX-WS WebServiceContext.getMessageContext(). The context will
> * either contain the WS-A To content and/or some property that
> * identifies the target address, eg MessageContext.PATH_INFO for
> * the current invocation
> * @return the id associated with the current invocation
> */
> String getId(Map contextMap);
> }
>
> The default implementation in AbstractMultiplexDestination
> can map the uniqueId to an EPR referenceParameter and
> propagate via WSA in a transport neutral way.
> AbstractHttpDestination can optionally override the default
> to make use of the address context for a more efficient and
> natural http implementation.
>
> From a users perspective, a unique server side epr would be
> resolved/created from a existing published service using
>
> EndpointRefernceType epr =
>
> EndpointReferenceUtils.getEndpointReferenceWithId(NUMBER_SERVI
> CE_QNAME,
> null, // portName
> uniqueId,
> BusFactory.getDefaultBus());
>
> Note: The portName should allow a particular port among many
> in a service, to be identified.
>
> Where EndpointReferenceUtils goes as follows:
>
> public static EndpointReferenceType
> getEndpointReferenceWithId(QName serviceQName, String
> portMame, String id, Bus bus) {
> EndpointReferenceType epr = null;
> ServerRegistry serverRegistry = (ServerRegistry)
> bus.getExtension(ServerRegistry.class);
> List<Server> servers = serverRegistry.getServers();
> for (Server s : servers) {
> QName targetServiceQName =
> s.getEndpoint().getEndpointInfo().getService().getName();
> if (serviceQName.equals(targetServiceQName)) {
> Destination dest = s.getDestination();
> if (dest instanceof MultiplexDestination) {
> epr =
> ((MultiplexDestination)dest).getEndpointReferenceWithId(id);
> break;
> }
> }
> return epr;
>
> Also
> public static String getCurrentEndpointReferenceId(Map context, Bus
> bus) {
> ...
> }
>
> During an invocation (server dispatch) accessing the current
> target EndpointReference needs a little work however. The
> JAX-WS MessageContext Map contains all the required
> information as properties. The MultiplexedDestination can use
> this information to locate and extract the uniqueId for this
> current request. The use of Map in the api keeps the
> EndpointReferenceUtils front-end neutral and the
> MultiplexedDestination transport neutral.
>
>
> Having to traverse the list of registered services in is a
> bit cumbersome, would it be possible to have services
> registered by Service QName? Or would that restrict us to
> single instance services. It could be map<QName, List<Service>>.
>
>
> Bernd, does this nail your use case?
>
> All, Does it make sense?
>
> Comments appreciated, I would like to further this into a
> proposal in the near future.
>
> Thanks,
> Gary.
>
>
>
> > -----Original Message-----
> > From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> > Sent: 23 March 2007 13:13
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Support for stateful services in CXF
> >
> > Hi Gary,
> >
> > thanks a lot for your reply.
> >
> > Tully, Gary wrote:
> > >
> > > Only yesterday I started to investigate providing simple
> > support for a
> > > single instance service that can represent many WS-addressing
> > > identities.
> > >
> > > What I am after at the moment is a simpler version of what is
> > > supported by @Stateful in the JAX-WS RI. The only state is
> > a unique-id
> > > that is encapsulated in the WS-Address.
> >
> > That looks like a starting point...
> >
> > [...]
> >
> > > At the moment I am capturing the FactoryPattern use-case as
> > a system
> > > test in order to provide a starting proof-point for an
> > implementation.
> > >
> > > The use of WS-Context (thanks Sergey) or HTTP session
> > information as a
> > > means of determining unique id would be neat but I think this is
> > > orthogonal.
> >
> > agreed.
> >
> > > From a WS-RF point of view, what are the usage scenarios
> > that you will
> > > need? Do they lend them selves to capture as system tests?
> >
> > The basic scenario is approximately
> > - allow for instance creation on a stateful service, for example
> > using a
> > Factory service
> > - deal with state, e.g. persist instances to some
> permanent storage
> > - manage instance lifecycle, manage their lifetime, destroy them
> > - allow clients to access instances by EPR /
> WS-Addressing This can
> > be captured by system tests, I guess.
> >
> > > Like you, I am learning as I go here, so any input is
> appreciated,
> > > especially your ideas on improving @Stateful and your experiences
> > > doing something similar with Xfire.
> >
> > My main improvements on the JAX-WS RI @Stateful would be to try and
> > make the whole instance resolving process, instance lifecycle
> > management and EPR creation much more flexible, and give
> more control
> > to the application programmer.
> > Of course all this should fit in as nicely as possible in the CXF
> > environment, which I unfortunately don't know much about yet...
> >
> > In my XFire implementation, things were fairly easy,
> because I could
> > hook into the mechanism that XFire uses to get the service
> object (the
> > Invoker). Figure out the unique id from the message
> context, re-create
> > the requested service instance from permanent storage, restore its
> > state, and invoke the operation.
> >
> > Maybe something similar can be done in CXF.
> >
> > > As I am only starting on my quest for a design, you may as
> > well give
> > > it a try from your perspective. We can swap ideas or
> experiences to
> > > come up with a working solution. It need not be a race :-)
> >
> > Perfect!
> >
> > Thanks, and best regards,
> > Bernd.
> >
> >
> > >> -----Original Message-----
> > >> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> > >> Sent: 23 March 2007 07:36
> > >> To: CXF devel
> > >> Subject: Support for stateful services in CXF [...] 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 b.schuller@fz-juelich.de
> > phone +49 2461 61 8736
> > fax +49 2461 61 6656
> > blog http://www.jroller.com/page/gridhaus
> >
> >
>
RE: Support for stateful services in CXF
Posted by "Tully, Gary" <Ga...@iona.com>.
Hi Bernd, all,
I have been toying around with my default servant test cases and
implementing as I go. My test case determines if Numbers are even by
accessing a particular Number instance from a NumberFactory (via create)
and using the returned reference to invoke the isEven() operation.
Trivial but illustrative I hope.
To make the implementation work/scale on the Server, a single stateless
servant represents all possible numbers and determines its current
identity based on the details of its current/target Endpoint Reference.
My client code does the following:
NumberFactoryService service = new NumberFactoryService();
NumberFactory factory = service.getNumberFactoryPort();
EndpointReferenceType numberTwoRef = factory.create("2");
NumberService numService = new NumberService();
A. ServiceImpl serviceImpl =
ServiceDelegateAccessor.get(numService);
B. Number num = (Number)serviceImpl.getPort(numberTwoRef,
Number.class);
assertTrue("2 is even", num.isEven().isEven());
Of interest here is:
A: JAX-WS is correctly particular about denying access to the underlying
implementation and with 2.1, EndpointReferences are first class citizens
so the need will no longer arise. Long term we probably need to start a
jax-ws-2.1-frontend. Short term, implementing the functionality in the
CXF implementation objects and providing this accessor is a fast win.
B: the ServiceImpl.getPort(EndpointReferenceType epr,..) simply uses the
address info of the epr to override the address of the EndpointInfo.
There is an issue with duplication of information between EndpointInfo
and EPRs in the Conduit that I will address in another post.
The Server side is more interesting.
NumberFactoryServiceImpl.create() needs to produce
EndpointReferenceTypes (EPRs) for the NumberService that identity a
particular number. First it inits and publishes a NumerServiceImpl
servant. On the trunk this requires working with EndpointReferenceUtils
to flesh out a valid EPR. My default implementation uses EPR
referenceParameters to contain the unique Id and WS-A to propagate the
target address. This has the advantage of being transport neutral but it
is over kill for some transports. For example, for a transport like http
or Yoko, it is possible to embed the unique Id into the endpoint
address, append it to the context in http (context match based on
startsWith) or for Yoko, burn it into a default servant object key. Then
the need for WS-A disappears. This pushes the detail of EPR creation
with a unique Id onto the transport/Destination.
I am thinking along the lines of an extension to Destination that
transports can optionally support.
/**
* A MultiplexDestination is a transport-level endpoint capable of
receiving
* unsolicited incoming messages from different peers for multiple
targets
* identified by a unique id.
* The disambiguation of targets is handled by higher layers as the
target
* address is made available as a context property or as a WS-A-To
header
*/
public interface MultiplexDestination extends Destination {
/**
* @return the a reference containing the id that is
* associated with this Destination
*/
EndpointReferenceType getAddressWithId(String id);
/**
* @param contextMap for this invocation, for example from
* JAX-WS WebServiceContext.getMessageContext(). The context will
* either contain the WS-A To content and/or some property that
* identifies the target address, eg MessageContext.PATH_INFO for
* the current invocation
* @return the id associated with the current invocation
*/
String getId(Map contextMap);
}
The default implementation in AbstractMultiplexDestination can map the
uniqueId to an EPR referenceParameter and propagate via WSA in a
transport neutral way. AbstractHttpDestination can optionally override
the default to make use of the address context for a more efficient and
natural http implementation.
>From a users perspective, a unique server side epr would be
resolved/created from a existing published service using
EndpointRefernceType epr =
EndpointReferenceUtils.getEndpointReferenceWithId(NUMBER_SERVICE_QNAME,
null, // portName
uniqueId,
BusFactory.getDefaultBus());
Note: The portName should allow a particular port among many in a
service, to be identified.
Where EndpointReferenceUtils goes as follows:
public static EndpointReferenceType getEndpointReferenceWithId(QName
serviceQName, String portMame, String id, Bus bus) {
EndpointReferenceType epr = null;
ServerRegistry serverRegistry = (ServerRegistry)
bus.getExtension(ServerRegistry.class);
List<Server> servers = serverRegistry.getServers();
for (Server s : servers) {
QName targetServiceQName =
s.getEndpoint().getEndpointInfo().getService().getName();
if (serviceQName.equals(targetServiceQName)) {
Destination dest = s.getDestination();
if (dest instanceof MultiplexDestination) {
epr =
((MultiplexDestination)dest).getEndpointReferenceWithId(id);
break;
}
}
return epr;
Also
public static String getCurrentEndpointReferenceId(Map context, Bus
bus) {
...
}
During an invocation (server dispatch) accessing the current target
EndpointReference needs a little work however. The JAX-WS MessageContext
Map contains all the required information as properties. The
MultiplexedDestination can use this information to locate and extract
the uniqueId for this current request. The use of Map in the api keeps
the EndpointReferenceUtils front-end neutral and the
MultiplexedDestination transport neutral.
Having to traverse the list of registered services in is a bit
cumbersome, would it be possible to have services registered by Service
QName? Or would that restrict us to single instance services. It could
be map<QName, List<Service>>.
Bernd, does this nail your use case?
All, Does it make sense?
Comments appreciated, I would like to further this into a proposal in
the near future.
Thanks,
Gary.
> -----Original Message-----
> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> Sent: 23 March 2007 13:13
> To: cxf-dev@incubator.apache.org
> Subject: Re: Support for stateful services in CXF
>
> Hi Gary,
>
> thanks a lot for your reply.
>
> Tully, Gary wrote:
> >
> > Only yesterday I started to investigate providing simple
> support for a
> > single instance service that can represent many WS-addressing
> > identities.
> >
> > What I am after at the moment is a simpler version of what is
> > supported by @Stateful in the JAX-WS RI. The only state is
> a unique-id
> > that is encapsulated in the WS-Address.
>
> That looks like a starting point...
>
> [...]
>
> > At the moment I am capturing the FactoryPattern use-case as
> a system
> > test in order to provide a starting proof-point for an
> implementation.
> >
> > The use of WS-Context (thanks Sergey) or HTTP session
> information as a
> > means of determining unique id would be neat but I think this is
> > orthogonal.
>
> agreed.
>
> > From a WS-RF point of view, what are the usage scenarios
> that you will
> > need? Do they lend them selves to capture as system tests?
>
> The basic scenario is approximately
> - allow for instance creation on a stateful service, for
> example using a
> Factory service
> - deal with state, e.g. persist instances to some permanent storage
> - manage instance lifecycle, manage their lifetime, destroy them
> - allow clients to access instances by EPR / WS-Addressing
> This can be captured by system tests, I guess.
>
> > Like you, I am learning as I go here, so any input is appreciated,
> > especially your ideas on improving @Stateful and your experiences
> > doing something similar with Xfire.
>
> My main improvements on the JAX-WS RI @Stateful would be to
> try and make the whole instance resolving process, instance
> lifecycle management and EPR creation much more flexible, and
> give more control to the application programmer.
> Of course all this should fit in as nicely as possible in the
> CXF environment, which I unfortunately don't know much about yet...
>
> In my XFire implementation, things were fairly easy, because
> I could hook into the mechanism that XFire uses to get the
> service object (the Invoker). Figure out the unique id from
> the message context, re-create the requested service instance
> from permanent storage, restore its state, and invoke the operation.
>
> Maybe something similar can be done in CXF.
>
> > As I am only starting on my quest for a design, you may as
> well give
> > it a try from your perspective. We can swap ideas or experiences to
> > come up with a working solution. It need not be a race :-)
>
> Perfect!
>
> Thanks, and best regards,
> Bernd.
>
>
> >> -----Original Message-----
> >> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> >> Sent: 23 March 2007 07:36
> >> To: CXF devel
> >> Subject: Support for stateful services in CXF [...] 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 b.schuller@fz-juelich.de
> phone +49 2461 61 8736
> fax +49 2461 61 6656
> blog http://www.jroller.com/page/gridhaus
>
>
Re: Support for stateful services in CXF
Posted by Bernd Schuller <b....@fz-juelich.de>.
Hi Gary,
thanks a lot for your reply.
Tully, Gary wrote:
>
> Only yesterday I started to investigate providing simple support for a
> single instance service that can represent many WS-addressing
> identities.
>
> What I am after at the moment is a simpler version of what is supported
> by @Stateful in the JAX-WS RI. The only state is a unique-id that is
> encapsulated in the WS-Address.
That looks like a starting point...
[...]
> At the moment I am capturing the FactoryPattern use-case as a system
> test in order to provide a starting proof-point for an implementation.
>
> The use of WS-Context (thanks Sergey) or HTTP session information as a
> means of determining unique id would be neat but I think this is
> orthogonal.
agreed.
> From a WS-RF point of view, what are the usage scenarios that you will
> need? Do they lend them selves to capture as system tests?
The basic scenario is approximately
- allow for instance creation on a stateful service, for example using a
Factory service
- deal with state, e.g. persist instances to some permanent storage
- manage instance lifecycle, manage their lifetime, destroy them
- allow clients to access instances by EPR / WS-Addressing
This can be captured by system tests, I guess.
> Like you, I am learning as I go here, so any input is appreciated,
> especially your ideas on improving @Stateful and your experiences doing
> something similar with Xfire.
My main improvements on the JAX-WS RI @Stateful would be to try and make the
whole instance resolving process, instance lifecycle management and EPR creation
much more flexible, and give more control to the application programmer.
Of course all this should fit in as nicely as possible in the CXF environment,
which I unfortunately don't know much about yet...
In my XFire implementation, things were fairly easy, because I could hook into the mechanism
that XFire uses to get the service object (the Invoker). Figure out the unique id from the
message context, re-create the requested service instance from permanent storage, restore its state,
and invoke the operation.
Maybe something similar can be done in CXF.
> As I am only starting on my quest for a design, you may as well give it
> a try from your perspective. We can swap ideas or experiences to come up
> with a working solution. It need not be a race :-)
Perfect!
Thanks, and best regards,
Bernd.
>> -----Original Message-----
>> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
>> Sent: 23 March 2007 07:36
>> To: CXF devel
>> Subject: Support for stateful services in CXF
>> [...]
>> 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 b.schuller@fz-juelich.de
phone +49 2461 61 8736
fax +49 2461 61 6656
blog http://www.jroller.com/page/gridhaus
RE: Support for stateful services in CXF
Posted by "Tully, Gary" <Ga...@iona.com>.
Hi Bernd,
Only yesterday I started to investigate providing simple support for a
single instance service that can represent many WS-addressing
identities.
What I am after at the moment is a simpler version of what is supported
by @Stateful in the JAX-WS RI. The only state is a unique-id that is
encapsulated in the WS-Address.
My use case comes from the use of the FactoryPattern in back-end
services that I want to expose as WS.
>From a HTTP perspective, cxf already supports listening for requests on
a context "startsWith" basis rather than a on a perfect match, so
multiple EPRs can be directed to a single service. I think the
WebContext will provide enough information to allow the service to
determine its identity during dispatch from the target address. Things
like WSDL generation will need a bit of thought and work.
At the moment I am capturing the FactoryPattern use-case as a system
test in order to provide a starting proof-point for an implementation.
The use of WS-Context (thanks Sergey) or HTTP session information as a
means of determining unique id would be neat but I think this is
orthogonal.
>From a WS-RF point of view, what are the usage scenarios that you will
need? Do they lend them selves to capture as system tests?
Like you, I am learning as I go here, so any input is appreciated,
especially your ideas on improving @Stateful and your experiences doing
something similar with Xfire.
As I am only starting on my quest for a design, you may as well give it
a try from your perspective. We can swap ideas or experiences to come up
with a working solution. It need not be a race :-)
Best regards,
Gary.
> -----Original Message-----
> From: Bernd Schuller [mailto:b.schuller@fz-juelich.de]
> Sent: 23 March 2007 07:36
> To: CXF devel
> Subject: Support for stateful services in CXF
>
> Hi all,
>
> first, I'm new to CXF, so forgive my lack of detailed knowledge.
>
> 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.
>
>
> What do you think?
>
>
> Best regards,
> Bernd.
>
> --
> Dr. Bernd Schuller
>
> Central Institute for Applied Mathematics Forschungszentrum
> Juelich GmbH
>
> mail b.schuller@fz-juelich.de
> phone +49 2461 61 8736
> fax +49 2461 61 6656
> blog http://www.jroller.com/page/gridhaus
>
>