axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Ruiz <rr...@gridsystems.com>
Subject Re: Bug? Stateful Session EJB support
Date Thu, 04 Dec 2003 16:59:29 GMT
Keith, have you considered a refactoring on your web service interface? 
You could extract some ideas from OGSA (Open Grid Services Arquitecture).

Here it is my little proposal (I'm not saying it is easy or fast to 
implement ;-) )

For each stateful EJB, create two services:
- A "Factory" service, that creates the EJB and returns a String 
containing a base64 encoded serialization of the EJB handler (I'll call 
it the ID). It would also have a method for removing an EJB by giving it 
the ID of the EJB you want to destroy.
- An "Instance" service that have the same operations than your EJB, but 
with an additional first argument: the ID.

You could generate only the service implementations from the EJB 
interface, and let Java2WSDL and WSDL2Java do the rest of the work :-)

The disadvantage is clear: you have to write a lot more code.
The advantages:
  - you stick to web services standards: your web service is stateless
  - your code is portable to the provider you like most

The process of these services creation can be automatized, for example, 
through perl scripts, or through a java doclet.

My two cents ;-)
Rodrigo Ruiz

Keith Hatton wrote:

>Hi Rodrigo,
>
>I have to admit, I haven't tried two clients, but can't see any reason why that shouldn't
work.
>
>The EJB in question does a search on a database and pages the result set to the client,
that is how I know that the statefulness of the EJB is exposed successfully through Axis.
>
>  
>
>>>perhaps invalidating the session will make the provider to call the remove() method
for you
>>>      
>>>
>A nice idea, but "remove" doesn't appear anywhere in the EJB provider. Obviously it was
written first and foremost for stateless session EJBs.
>
>Although JSR109 only deals with stateless EJBs, there seems no fundamental reason not
to expose stateful EJBs if you want to (so long as it doesn't interfere with anything in that
spec). All it requires is a client that can handle state too. We are using Axis because it
seems to support stateful EJBs better than other providers (GLUE, WASP) and because we want
to offer our EJB functionality to .NET and other clients.
>
>Keith
>
>
>-----Original Message-----
>From: Rodrigo Ruiz [mailto:rruiz@gridsystems.com]
>Sent: 04 December 2003 16:30
>To: axis-user@ws.apache.org
>Subject: Re: Bug? Stateful Session EJB support
>
>
>Hi Keith, some time ago I did some tests on maintaining more than one 
>session from the same client, but I was unsuccessful. How do you manage 
>to maintain two instances of your EJB web service? I only managed to 
>maintain one instance, as I couldn't get two separate sessions :-(
>
>BTW, perhaps invalidating the session will make the provider to call the 
>remove() method for you (I haven't read the EJBProvider code). If it is 
>so, you could modify your client wrapper to encapsulate the session 
>invalidation in a remove() method :-)
>
>Cheers,
>Rodrigo Ruiz
>
>Keith Hatton wrote:
>
>  
>
>>Well, I didn't see anything saying that only stateless EJBs were supported ... and
stateful beans do work if the client maintains a session, and the server scope is set to session.
>>
>>Keith
>>
>>-----Original Message-----
>>From: Ekbote, Niranjan [mailto:NEkbote@doubleclick.net]
>>Sent: 04 December 2003 15:25
>>To: 'axis-user@ws.apache.org'
>>Subject: RE: Bug? Stateful Session EJB support
>>
>>
>>Has Axis started supporting "Stateful" session beans? I thought for the EJB
>>provider, you can only work with "Stateless" session beans. 
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>  
>



Mime
View raw message