2 technical questions for the techies

[Richard Duglora�]

- Is RMI-IIOP over SSL possible and if yes is it common ?

- If I have 2 EJBs A and B, is it possible to transmit to a (remote) client a local (EJBLocalObject) ref to B, then have the client pass to A the local ref to B (as an argument in a call), and make A call B via this ref ?

Richard

[calvin zhu]

Originally posted by Richard Duglora�:
- Is RMI-IIOP over SSL possible and if yes is it common ?

- If I have 2 EJBs A and B, is it possible to transmit to a (remote) client a local (EJBLocalObject) ref to B, then have the client pass to A the local ref to B (as an argument in a call), and make A call B via this ref ?

Richard

The first one is yes. I'm not sure if it's common. I find this on IBM website.http://www-106.ibm.com/developerworks/websphere/WASInfoCenter/infocenter/wasa_content/rnSSL.html

Overview: WebSphere Application Server's use of Secure Socket Layer
Secure Socket Layer (SSL) provides secure communication for several WebSphere Application Server components. In particular, SSL is used between:

The Web server WebSphere Application Server plug-in acting as an SSL client, and an application server Web container acting as an SSL server using HTTPS.
Am EJB client acting as an SSL client, and an application server acting as an SSL server using RMI/IIOP over SSL.
A Web component, including servlets and Java Server Page (JSP) files, acting as an SSL client, and an external SSL secured Web site acting as an SSL server using HTTPS.
An enterprise bean in an application server acting as an SSL client, and an external SSL secured EJB server acting as an SSL server using RMI/IIOP over SSL.
Internal administrative and application server processes using RMI/IIOP over SSL on WebSphere Application Server Advanced Edition.
Administrative clients, including the administrative console, XMLConfig, and WSCP, acting as an SSL client, and the administrative server acting as an SSL server using RMI/IIOP over SSL on WebSphere Application Server Advanced Edition.
Administrative and application servers acting as an SSL client, and an SSL secured Lightweight Directory Access (LDAP) server acting as an SSL server over LDAPS on WebSphere Application Server Advanced Edition.

[calvin zhu]

I think the second should work too, why not? As long as your local reference implements Serializable interface.

I didn't test it and would like to know the answers too. Maybe you can ask Parag Doshi, seems to me he is taking the same approach in assignment.

[Ajith Kallambella]

- If I have 2 EJBs A and B, is it possible to transmit to a (remote) client a local (EJBLocalObject) ref to B, then have the client pass to A the local ref to B (as an argument in a call), and make A call B via this ref ?

Whoa...that is certainly a distorted approach I am not sure why such a thing is neede, and not least of all, if you had to do this, you should be questioning your design decision to make B local.

Anyways, passing a EJBLocalObject ref of a local EJB outside the JVM is discouraged. Read the EJB spec, it should be somewhere in section 6. I don't know if any app server implementation catch this error, but you get the point. It simply should not be done.
[ September 23, 2004: Message edited by: Ajith Kallambella ]

[Richard Duglora�]

Ajith,

Originally posted by Ajith Kallambella:

Whoa...that is certainly a distorted approach I am not sure why such a thing is neede, and not least of all, if you had to do this, you should be questioning your design decision to make B local.

Well, let's say A is a Stateless Session Facade and B a Stateful Session Bean, and A and B are in the same JVM. You want to have a stateless facade rather than a stateful one because 1-it's lighter 2- some business services are non conversational (in which case you don't need any session state) so in these cases a stateless bean is likely to achieve a better performance.

To implement the idea, you have to pass a ref to B (the stateful bean) as an arg in every call to a "stateful" service. It can be a remote reference to B, but since this ref will only be used locally by the facade A, I was wondering if an optimisation was possible by using a local ref rather than a remote one.

Now if Sun forbids it, I can imagine an alternate solution like using a helper with a local map: someSessionId -> local ref to B on the EJB tier, passing someSessionId to the fa�ade that would use the helper to get the local ref to B. Even if it may look twisted, it's probably faster that to use a remote ref.

Maybe I'm entirely missing the point. Your opinions are welcome.

Richard

[Parag Doshi]

Originally posted by Richard Duglora�:
Ajith,



Well, let's say A is a Stateless Session Facade and B a Stateful Session Bean, and A and B are in the same JVM. You want to have a stateless facade rather than a stateful one because 1-it's lighter 2- some business services are non conversational (in which case you don't need any session state) so in these cases a stateless bean is likely to achieve a better performance.

To implement the idea, you have to pass a ref to B (the stateful bean) as an arg in every call to a "stateful" service. It can be a remote reference to B, but since this ref will only be used locally by the facade A, I was wondering if an optimisation was possible by using a local ref rather than a remote one.

Now if Sun forbids it, I can imagine an alternate solution like using a helper with a local map: someSessionId -> local ref to B on the EJB tier, passing someSessionId to the fa�ade that would use the helper to get the local ref to B. Even if it may look twisted, it's probably faster that to use a remote ref.

Maybe I'm entirely missing the point. Your opinions are welcome.

Richard

Richard,
I am following a similar concept as outlined by you above. But, I am using a remote stateful session bean with a stateless facade, as I want to pass the handle across to the web tier for reasons we are already aware of. The reason I didnt bother with local or remote interface was because I know app servers (atleast 2 of them - Borland, Weblogic) which do co-located call optimization implicitly. i.e. if it senses that the call to a ejb is co-located in the same jvm, then it does the necessary optimization which is quite similar to using local interfaces. And if these 2 are providing that service, I can imagine others also providing the same.

I know I shouldnt be architecting my solution based on some proprietory app server feature, but its easier to justify the decision this way than trying to write a custom hastable based implementation. Not that it wouldnt work, but I would rather rely on the fact that app servers would provide this service than writing my own home grown solution. And realistically, at the end of the day, the ejbs are gonna be deployed on some app server and quite possibly that app server would provide this functionality for free.


Just my 2 cents..

Parag

[Richard Duglora�]

Parag:

Originally posted by Parag Doshi:


The reason I didnt bother with local or remote interface was because I know app servers (atleast 2 of them - Borland, Weblogic) which do co-located call optimization implicitly. i.e. if it senses that the call to a ejb is co-located in the same jvm, then it does the necessary optimization which is quite similar to using local interfaces. And if these 2 are providing that service, I can imagine others also providing the same.

Thanks for the info, that's useful. I'm a not a beginner in Architecture but I do lack concrete experience with the EJBs.
To me a double remote call (client->Facade and Facade->SFSB) seemed to void the benefit of the SLSB fa�ade, hence my efforts to use the local ref. But if it can be optimized automatically by a smart container...

BTW, I borrowed the SLSB facade idea from... one of your post

Richard

[Parag Doshi]

Originally posted by Richard Duglora�:
Parag:



Thanks for the info, that's useful. I'm a not a beginner in Architecture but I do lack concrete experience with the EJBs.
To me a double remote call (client->Facade and Facade->SFSB) seemed to void the benefit of the SLSB fa�ade, hence my efforts to use the local ref. But if it can be optimized automatically by a smart container...

BTW, I borrowed the SLSB facade idea from... one of your post

Richard

Richard,
Having stateless SF seemed to be more logical than having loads of stateful session beans around. Anyway, I am new to architecture and also new to ejb , so it would be interesting to see what I end up with !

Btw, I am now contemplating about unpaid itinerary persistence, after reading one of your post and also Harbo's. I have already designed the persistence of it..so now am feeling lazy to undo it

Parag
[ September 23, 2004: Message edited by: Parag Doshi ]

[Ajith Kallambella]

My favourite quote - "Premature optimization is root of all evil".

Sure, SFSBs are heavier than Stateless SBs, but no body says you should completely stop using them right? SFSBs are there for a reason and I am reluctant to take the statement" stateless bean is likely to achieve a better performance" at its face value. It is too broad.

I pefectly understand the scenario you are describing and I'd not hesitate to SFSBs to front the local SLSBs( ofcourse, in the absence of explicit business requirements, available Technical Infrastructure and scope for horizontal scaling). Although your approach may work, it seems that the juice is not worth the squeeze - to gain this tiny little optimization SLSBs offer over SFSBs, you may be just making things more complex and unmanageable.

In your scenario, if maintaining the client conversation is a business requirement, I will gladly use a SFSB. If you are expecting thousands of concurrent users, then you might have to think a step further. Again what are the business requirements and expected load?


Last but not the lest, App Servers have learned to optimize them for performance. That's why we all pay huge money for the state of the art app servers


Cheers,

[calvin zhu]

I agree with Ajith.
The truth is I did think about which approach to take for facade after reading Parag's approach few days ago. Then I looked at pet store's example, found it also use SFSB as facade, which makes me think is using SFSB as facade such a bad choice?

Allow me do a simple calculation here:
Using SFSB as facade, that's is enough for keeping session.
Using SLSB as facade, u still have to create a SFSB to keep the session. So it's SLSB + SFSB vs SFSB.

Using SFSB as facade, when serving more user than the instance limits, container will do the serialization for u under necessary situation.

Using SLSB as facade, everytime the reference pass in and out need to be serialized.

So I will go for the SFSB facade choice.

[Richard Duglora�]

Actually a SFSB was my first choice but I started doubting when I realized that performance seemed to be a major requirement in the specs (20 travel agents + 600 web users max concurrently). Some books recommend to go for SLSB when you need performance. As I already mentioned I also lack concrete experience with the EJBs, which makes hard to compare and weight the different options.

But you have enlightened me, and I'm ready to adopt a SFSB now.

Thanks for the hints

Richard

[D. Rose]

I did not get the point of passing handles of SFSB across web tier. I think, it is better to use SFSB then as we are not making a real facade.

Facade is useful only if we hide the implementation.
[ September 23, 2004: Message edited by: D. Rose ]

[Parag Doshi]

Time to justify my design Its good, I can use this as a rehersal for my final documentation ok..here goes..

Lets start with the petstore application. Petstore has 3 stateful session beans: ShoppingController, ShoppingClientFacadeLocal and ShoppingCartLocal.
One significant point to see is that all these are stateful session beans and all are "local".
The ShoppingController is used to access the ShoppingClientFacade which holds the customer and the shoppingcart as its state. The shoppingcart has the actual methods for adding, deleting, updating items which are stored in a Map. So, all these 3 stateful session beans are linked to each other to provide a shopping client solution.

The way the facade is used in petstore and the way I was describing is entirely different. The petstore facade has basically getters/setters for userId, getCustomer, createCustomer and getShoppingCart. The point I am trying to make is that its less of a "facade" and more of a "helper" class to the controller and other EJBAction object. My facade (atleast the way I see it) is managing the workflow and sheilding the complex subsystem from the web tier. In petstore, the facade provides access to the shoppingcart and does not contain the actual working of the shopping cart. its just a holder for the shoppingcart and the customer object. It does not contain any workflow related methods as those are defined in the EJBAction Command objects. If your design includes a similar EJBAction based Command objects, then it would make sense to use the session beans as stateful and as local objects.

Coming back to our scenario, if the session facade is stateful, it has atleast 3 responsibilities, first, managing the workflow (basic intent of facade),second managing the shopping state and third managing the customer. Petstore has divided these responsibilities in 2 stateful session beans(ShoppingClientFacade and ShoppingCart). I chose to divide it between a stateless session facade(to manage the workflow) and a stateful one to manage the customer and shopping experience. Now, the choice to go for a stateless session facade was not only to improve performance,but as the state is now shifted to a stateful session bean, the facade simply doesnt need to be stateful ! Unless we stuff all the 3 responsibility in one big stateful session facade (which is not a good idea), there is a need for atleast 2 session beans to take care of the above mentioned responisibility. Making them both stateful is one choice which petstore made but also counter balanced it by making them "local" ejbs.

Another point to note is that the petstore has only 1 session facade, my system has more than 1 session facade as they represent differnt subsystems or modules. And these session facades collaborate to providing services to the web tier. Hence, it made more sense (to me) to make them stateless.

Again, there is no one right or wrong way to desiging facades. Stateful session facades are used in majority of cases, I chose differently based on my understanding of the system.

Sorry for the long message..

Parag

[D. Rose]

Hi Parag,

I agree with you that petstore facade is not real facade but still passing references from web tier defies logic of hiding subsystem details.

Is there any other implementation choice?

Keeping map on server side? It would be difficult to control multithreading/lifecycle ( remove etc). Can multithreaded access be controlled by transaction settings? Just a thought.

I think keeping 2 facades - 1 stateless/ 1 stateful would be helpful as done in WAF.

[ September 24, 2004: Message edited by: D. Rose ]
[ September 24, 2004: Message edited by: D. Rose ]

[Annie Zhang]

Parag: your design is justified! (just kidding)

Yes, I agree with your approach. The SFSB is to keep track of user's session. This SFSB is also a facade to serveral entity beans. Above all the session beans, there is one SLSB facade which is the single entry point for the client side to the ejb side, and the abstraction of the subsystems (session beans).