Thanks for your ideas, Rodrigo. I am going to sleep on it.

I like the idea as it forms a design pattern and as you say, allows the client to take 
a more standard approach to the service, and also because over the past few days I 
have discovered some of the delights of working with stateful EJBs through Web 
Services (having also discovered the non-delights of other providers not supporting 
them at all). The downside as I see it, is not so much the writing of code (I seem to 
be doing a lot of that anyway - our value objects are not generally straightforward 
Java Beans), but that "management" believes that exposing all the EJBs as Web Services 
is a 5-minute task. (I think I'll omit to mention the base64-encoding of the EJB 
handle, as base64 always gets the folks round here "excited", if you know what I mean).

Thanks
Keith


-----Original Message-----
From: Rodrigo Ruiz [mailto:[EMAIL PROTECTED]
Sent: 04 December 2003 16:59
To: [EMAIL PROTECTED]
Subject: Re: Bug? Stateful Session EJB support


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:[EMAIL PROTECTED]
>Sent: 04 December 2003 16:30
>To: [EMAIL PROTECTED]
>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:[EMAIL PROTECTED]
>>Sent: 04 December 2003 15:25
>>To: '[EMAIL PROTECTED]'
>>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. 
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>  
>


Reply via email to