Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of sergey.beryozkin@iona.com
 designates 62.221.12.55 as permitted sender)
Message-ID: <003b01c7aea0$01be0820$c301020a@pcgroupiona.com>
From: "Sergey Beryozkin" <sergey.beryozkin@iona.com>
To: <cxf-dev@incubator.apache.org>,
	<jgenender@apache.org>
References: <1D195F515BDFE04EA40FA8D046308D6A0302AB@emea-ems1.IONAGLOBAL.com>
 <003001c7ae7b$15083ba0$c301020a@pcgroupiona.com>
 <46714AAF.3060302@apache.org>
Subject: Re: Support for stateful services in CXF
Date: Thu, 14 Jun 2007 17:21:04 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0038_01C7AEA8.637B4430"

------=_NextPart_000_0038_01C7AEA8.637B4430
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I was rather hoping to initiate some discussion on how stateful web service=
s 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.=20
I'm really after trying to explore if there's anything that can be learnt o=
r borrowed from the WS-Context spec and put into the practical surface, as =
far as bulding stateful services is concerned.=20
WS-Context is about supporting distributed activities (those spanning mulip=
le services), so I'm wondering, can it all be applied to the issue of suppo=
rting the application-level stateful interactions or not...as the alternate=
 strategy
Thanks, Sergey=20

----- Original Message -----=20
From: "Jeff Genender" <jgenender@apache.org>
To: <cxf-dev@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.
>=20
> You can enable stateful WS by setting:
>=20
> requestContext.put(BindingProvider.SESSION_MAINTAIN_PROPERTY, Boolean.TRU=
E);
>=20
> Thanks,
>=20
> Jeff
>=20
>=20
> Sergey Beryozkin wrote:
>> Hi Gary
>>=20
>> I'd like to revive this thread for a bit :-)
>> As you mentioned,=20
>>=20
>>> 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.
>>=20
>> 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 providin=
g an alternate
>> implementation built around WS-Context so that people can choose between=
 the two ones ?
>>=20
>> 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 t=
he WS-Services world. I think with WS-Context one might afford for a more l=
oose interaction model between the client and the service endpoint...
>>=20
>> Cheers, Sergey
>>=20
>>=20
>> [1] http://weblogs.java.net/blog/kohsuke/archive/2007/06/stateful_web_se=
_1.html
>>=20
>>=20
>> ----- Original Message -----=20
>> From: "Tully, Gary" <Gary.Tully@iona.com>
>> To: <cxf-dev@incubator.apache.org>
>> Sent: Thursday, April 05, 2007 10:24 AM
>> Subject: RE: Support for stateful services in CXF
>>=20
>>=20
>> 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.=20
>> 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.
>>=20
>>=20
>> 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.=20
>> 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.
>>=20
>> Thanks for the input, academic? No :-)
>> Gary.
>>=20
>>> -----Original Message-----
>>> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]=20
>>> 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=20
>>> transport like http or Yoko, it is possible to embed the=20
>>> unique Id into the endpoint address" ...
>>>
>>> IMHO this is what should happen for HTTP because this will=20
>>> make individul number services addressable...Using EPR=20
>>> parameters to convey the unique id looses the identity of the=20
>>> service endpoint.
>>> Sorry if my comments would seem a bit academic in the scope=20
>>> of your very interesting and more important, *practical*=20
>>> proposal. It's just that CXF shows the lead in letting people=20
>>> to build resful services, etc, so I feel that trying to=20
>>> pursue the general idea of bringing even purely SOAP-based=20
>>> services closer to the web, when possible, would be good. We=20
>>> can imagine then SOAP Number services being able to GET-reply=20
>>> with their state while still being able to process soap post=20
>>> increment/decrement requests, etc...This will increase the=20
>>> value of the Number service. Actually, have just seen your=20
>>> comment that AbstractHTTPDestination can be used for this,=20
>>> sounds great, perhaps this can be used to enhance the way=20
>>> things work with http in the future !
>>> If even for HTTP the WSA header will be sent to the service=20
>>> to indicate what instance the invocation should be made=20
>>> againt then it would be in general mean the explicit context=20
>>> is used, which is good, but I hope you can see now why I was=20
>>> referring to WS-Context earlier, one can imagine passing a=20
>>> WS_Context header to the Number service indicating an=20
>>> application level context, the number on which the service=20
>>> should perform the even check....so even though WS-Context is=20
>>> probably more natural for dealing with higher-level=20
>>> activities, it may work with the application-level ones too
>>>
>>> Overall it's a great start...
>>>
>>> Thanks, Sergey
>>>
>>> ----- Original Message -----
>>> From: "Tully, Gary" <Gary.Tully@iona.com>
>>> To: <cxf-dev@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=20
>>> (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=20
>>> stateless
>>> servant represents all possible numbers and determines its current
>>> identity based on the details of its current/target Endpoint=20
>>> Reference.
>>>
>>> My client code does the following:
>>>
>>>         NumberFactoryService service =3D new NumberFactoryService();
>>>         NumberFactory factory =3D service.getNumberFactoryPort();
>>>
>>>
>>>   EndpointReferenceType numberTwoRef =3D factory.create("2");
>>>
>>>         NumberService numService =3D new NumberService();
>>> A.      ServiceImpl serviceImpl =3D
>>> ServiceDelegateAccessor.get(numService);
>>>
>>> B.      Number num =3D  (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=20
>>> underlying
>>> implementation and with 2.1, EndpointReferences are first=20
>>> class citizens
>>> so the need will no longer arise. Long term we probably need=20
>>> 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,..)=20
>>> 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=20
>>> 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=20
>>> neutral but it
>>> is over kill for some transports. For example, for a=20
>>> 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=20
>>> 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=20
>>> 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 =3D
>>>
>>> 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 =3D null;
>>>         ServerRegistry serverRegistry =3D (ServerRegistry)
>>> bus.getExtension(ServerRegistry.class);
>>>         List<Server> servers =3D serverRegistry.getServers();
>>>         for (Server s : servers) {
>>>             QName targetServiceQName =3D
>>> s.getEndpoint().getEndpointInfo().getService().getName();
>>>             if (serviceQName.equals(targetServiceQName)) {
>>>                 Destination dest =3D s.getDestination();
>>>                 if (dest instanceof MultiplexDestination) {
>>>                     epr =3D
>>> ((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=20
>>> 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=20
>>> 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=20
>>> 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=20
>>> 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
>>>>
>>>>
>>>
>>=20
>> ----------------------------
>> 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

------=_NextPart_000_0038_01C7AEA8.637B4430--