Can a session facade have both local and remote interfaces at the same time? In particular for a stateful session facade can I access both the remote and local bean that hold the same state? In the pet store sample application, both the web server and the EJB container are assumed to be running in the same virtual machine. If the web server runs in another machine, then the ShoppingClientFacade needs a remote interface to make it accessible to the web server side. In the mean time this facade also has to be accessible by the EJBController, which resides in the EJB side. So a local interface is also needed for this facade. The Core J2EEPattern book only talks about remote session facade. But from a pure OO point of view it is quite reasonable to have a facade to encapsulate some components so that others (either remote or local) access these components through this facade alone. TIA,
Um, hold on there, Pradeep -- that answer might be a bit too terse. The spec CERTAINLY allows a single bean to have both remote and local interfaces. However, I think you're right to say that once you create a particular bean instance with one you can't use the other for that instance. However nothing would stop you from creating "California" with a Remote Home and getting back a Remote interface to it, while creating "Colorado" with a Local home and getting back a local interface to that one. Kyle
Originally posted by Isaac Liu: Can a session facade have both local and remote interfaces at the same time? In particular for a stateful session facade can I access both the remote and local bean that hold the same state? The Core J2EE Pattern book only talks about remote session facade. TIA,
I thought one of the main benefits of using a Session Facade with remote interfaces is to limit the number of calls to an entity bean having a remote interface. Is Session Facade pattern applicable to session/entity beans with local interfaces as well?
Joined: Nov 29, 2003
Thank you very much for your replies! I am clear about the remote and local bean instances now. But in a typical shopping web site design there is a shopping cart stateful session bean. This needs to be accessible from both EJB side and web server side. How should I model the session facade? TIA, [ December 22, 2003: Message edited by: Isaac Liu ]
Is Session Facade pattern applicable to session/entity beans with local interfaces as well?
Well Vish, what if you want to hide all the lookup code from the client? In this case you may use the Business Delegate pattern which uses plain java classes that delegate the calls from the clients to the session beans. This business delegate classes will run inside the same JVM as the Session Beans so it is better to make the calls through the Local interfaces. Sergiu.
1. I am shopping at your site. 2. I have decided that I have picked out as many items as I want. 3. I clicked pay with credit card. Now you have some sort of interface to a credit card clearing house. Obviously this operation is coupled to the shopping cart. If you build this interface as a synchronous operation I foresee only troubles. There's a network between your system and the CC server that can fail. The CC server is going to crash every once in a while. The cc server could get way behind business on Black Friday and your transactions will be long running and jamming up performance. To avoid these problems you set up a JMS system. You put your authorization requests in a queue. When your payment is through processing you get an OnMessage event at your server. Does this senario sound unreasonable? You know there may be times when the credit card processing is a long running transaction. You have created a design that deal with it. But if you save your shopping cart in a session bean and your server crashes do you have an enterprise quality system?
Joined: Aug 10, 2001
OK, there's a couple of things to clarify here. (1) Local Interfaces CAN be used from a co-deployed Web Container. What you lose if you only give your Session Facade a local interface is the ability to separate the Web and EJB containers into different application servers later. (2) Session Facades are STILL required for co-deployed containers because of transaction scope. You still want to have your session bean be the one that controls when transactions start/commit/rollback. If you pass a local Entity bean to a Servlet (which you could do) then either the Servlet is responsible for doing its own JTA transaction scoping (not a good idea) or each method call to the entity bean is its own transaction (also not a good idea due to the overhead involved). Kyle
subject: Local and remote interfaces for session facade?