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:[EMAIL PROTECTED]
Sent: 23 March 2007 13:13
To: [email protected]
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:[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
phone +49 2461 61 8736
fax +49 2461 61 6656
blog http://www.jroller.com/page/gridhaus
