BusinessDelate & ServiceLocator

Hi,
I just started reading a bit about BusinessDelegate pattern and I am wondering whether it is still being used with ejb3.0. Besides providing abstraction layer to the session facade some of the benefits of using a delegate was to cache EJBHome, or to provide client with the byteCode for the serialized ejb Handles and to abstract ejb/rmi exception from the client code.
Is this pattern still applicable to ejb3.0 since now we don't use ejbHome, ejb/rmi exceptions are not visible and you have dependency injection. In ejb3.0 is the approach of serializing ebj handle still viable?
Thanks for your help, I am new to both ejb2/ejb3.0.
Thanks,

There is less need for the BusinessDelegate and EJB 2.x Home view within EJB 3.0. The easiest
approach is to simply inject or lookup a reference to the session bean remote business interface
within the client.
Handle functionality is one case where you would need to fall back on the 2.x Home view. If
you need to persist the remote ejb reference itself there's no way to do that with the EJB 3.0
remote business view.
--ken

Similar Messages

ServiceLocator for swing app

can anyone show me way how to speedup ejb invocation from remote swing app?
I read about servicelocator for jsp application, but can no find topic about remote swing app servicelocator.
my network call to remote ejb methods is dramatically slow :(
thanks !

Yes, good question, on my remote app it is very slow too....

ServiceLocator design flaw in Petstore 1.3

Hello.
As far as I can understand, there seems to be a design flaw in the Petstore 1.3 implementation of the Service Locator.
The ServiceLocatorImpl class, which is the base class of ShoppingClientServiceLocatorImpl has an attribute session, that holds the HttpSession object passed with the sessionCreated method call. It uses the session to store there the WebClientController reference.
The problem seems to be that it uses the session member object to get back the WebClientController in the getWebClientController method. But isn't it only one instance of the ServiceLocatorImpl per application? It seems like there should be only one ... And if this is true, then this means that when a new client session begins, the session member object is overriden, and you will never find the data from other sessions, and the lookup will be done for each call to getWebClientController....
Am I right or totally wrong with the number of instances of ServiceLocatorImpl?
Regards,
Cristian

i think you are wrong.
They are several instances of serviceLocator per application. In fact, one for each client.
There is one client web controller per client which lets handles event to the EJB ontroller (but there is only one ejb controller which is accesed throught its remote interface, this why the methods are synchronized).

ServiceLocator & EJB's on different machines

Hi,
How can you adapt the servicelocator pattern so that it enables the lookup of EJB's on different servers? The problem is that the iiop adress (providerURL) of these beans can vary which means that the InitialContext needs to change. You somehow want to store this (iiop address) in a properties-file but i don't know how to incorporate this is the servicelocator pattern.
In my application i need to use 5 EJB's on 3 servers, 2 on my own (WAS) and the other three on three other servers.
Is there a flexible and fast way to do this?
Thank,
Maarten

I tried something which worked but it is not recommended because the Workload Manager has trouble with this if you cache the InitialContext over multiple sessions.
What i did was create a hashtable which could hold multiple Initialcontext and were stored based on the JNDI-name, i also had another hashtable which stored objects that held information about the EJB (jndiName, classname, providerURL, caching). So what i did was when you call the ServiceLocator for the first time, 2 hashtables were created and filled based on an xml-file. Then if a client wants to access an EJB all it had to do was give the JNDI name, from one hashtable an object was retrieved, check if that objects holds an providerURL, if not use the standard, if so get the InitialContext from the second hashtable and perform a lookup. Works perfectly but again not recommended.
Cheers,
Maarten

DAO Pattern and the ServiceLocator

I have been developing a lightweight framework for working with AIR and the SQL API. This framework has no dependencies on Cairngorm however it is built around a typical DAO implementation.
While developing this I considered how it should be integrated with Cairngorm, which lead me to wonder if a simple DAO marker interface which could be retrieved from the ServiceLocator (and cast to the correct abstraction by a business delegate) would not be all that is needed to have a rather flexible service layer in Cairngorm?
For example, consider the following pseudo code which is what I would imagine a business delegate to look like:
class FooDelegate {
protected fooDAO:IFooDAO;
public FooDelegate(responder:IResponder) {
fooDAO = ServiceLocator.getinstance().getDAO(Service.FOODAO) as IFooDAO;
fooDAO.addResponder( responder );
public getFoo() void {
fooDAO.getFoo();
public addFoo(foo:IFoo) {
fooDAO.addFoo(foo);
public deleteFoo(foo:IFoo) {
fooDAO.deleteFoo(foo);
As you can see the delegate would cast the dao to the correct abstraction and then just wrap the DAOs API (somewhat similar to an Assembler in LCDS).
A custom DAO interface would extend the DAO marker interface so that the ServiceLocator could find it:
interface IFooDAO extends IDAO
getFoo() void;
addFoo(foo:IFoo);
deleteFoo(foo:IFoo);
Service.mxml would define an instance of the dao as an abstraction and then call a factory to get the appropriate implementation:
public fooDAO:IFooDAO = DAOFactory.getDAO("foo");
I see much potential in this type of implementation as it would allow services to be swaped out with different implementations via a config or with an IoC implementation etc, thus allowing the services themselves to be completely transparent to client code.
I wanted to see if anyone had any thoughts on this as well?
Best,
Eric

Thanks, duffymo, that makes sense. However ... having read through numerous threads in which you voice your opinion of the DAO World According to Sun, I'd be interested to know your thoughts on the following ...
Basically, I'm in the process of proposing an enterprise system architecture, which will use DAO as the primary persistence abstraction, and DAO + JPA in the particular case of persistence to a RDBMS. In doing so, I'd like to illustrate the various elements of the DAO pattern, a la the standard class diagram that relates BusinessObject / DataAccessObject / DataSource / TransferObject (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html). With reference to this model, I know that you have a view on the concept of TransferObject (aka ValueObject?) - how would you depict the DAO pattern in its most generic form? Or is the concept of a generic DAO pattern compromised by the specific implementation that is used (in this case JPA)?

Question about ServiceLocator pattern

Hi,
I was wondering what would be the most approproate way to modify the serviceLocator pattern (from the core j2ee patterns book) to handle multiple initialContext? I.e, how do I modify the ServiceLocator to get the home from multiple remote servers?
Do I get the client to pass in the InitialContext to be used?
If I cache the homes - what should you use as the key? I.e. what can uniqeuly identify an InitialContext?
Cheers,
Nim

An InitialContext is probably uniquely identified by the provider URL. I'd rather set up some kind of mapping, though, so that you just say "service this" and "service that", and the ServiceLocator, through configuration info, figures out what JNDI service to lookup as well as what to ask for.

ServiceLocator - InitialContext - ThreadSafety

Hi,
on otn I found an implementation of the ServiceLocator pattern:
http://otn.oracle.com/sample_code/tech/java/ejb_corba/vsm/files/src/oracle/otnsamples/util/ServiceLocator.java.html
It uses an InitialContext shared by all Threads.
In the Javadoc of InitialContext I found the following:
"An InitialContext instance is not synchronized against concurrent access by multiple threads. Multiple threads each manipulating a different InitialContext instance need not synchronize. Threads that need to access a single InitialContext instance concurrently should synchronize amongst themselves and provide the necessary locking."
Do I have to expect problems when I use this ServiceLocator implementation?
Thanks for your comments
Guenther

Guenther,
In that sample they have assumed that InitialContext configuration wont change at any time.
So i dont think there is a need for synchronization..(in their implementation)
In your application, if each thread adds/modifies their InitialContext configuration, then synchronization has to be taken care...
One more thing regarding caching of InitialContext is that, if the InitialContext gets modified(by add/modify JNDI entries- using hot deployment or somthing) at runtime, then you will have to refresh InitialContext often....so you cant cache them...
Correct me if i am wrong...
Cheers
--Venky
Hi,
on otn I found an implementation of the ServiceLocator pattern:
http://otn.oracle.com/sample_code/tech/java/ejb_corba/vsm/files/src/oracle/otnsamples/util/ServiceLocator.java.html
It uses an InitialContext shared by all Threads.
In the Javadoc of InitialContext I found the following:
"An InitialContext instance is not synchronized against concurrent access by multiple threads. Multiple threads each manipulating a different InitialContext instance need not synchronize. Threads that need to access a single InitialContext instance concurrently should synchronize amongst themselves and provide the necessary locking."
Do I have to expect problems when I use this ServiceLocator implementation?
Thanks for your comments
Guenther

JAAS and ServiceLocator

Hi,
does JAAS authentication on the client somehow knock off the need for a ServiceLocator pattern?
Scenario:
1) I request reference to a stateful session ejb via ServiceLocator
2) ServiceLocator authenticates with user "anonymous" and creates that ejb and returns the reference to it, as well as my "subject" object.
3) I make some calls using Subject.Doas
4) at some point, I decide to switch identity, therefore re-authenticating to the server
5) I do method calls on the same ejb as before
Doubts about ServiceLocator pattern integration with JAAS:
a) in this scenario, ServiceLocator looks up the bean for me. Have I got to provide any URL for logging in also ? I guess I must somehow decide - just as with EJBs - where to find the server to authenticate to, am I right ? If yes, will I need to write servicelocator functionality for looking up the "URL" of the service/server to authenticate to ?
If I need no URL for logging in, then this doubt is of no importance
b) in step 4, I decide to switch identity by re-authenticating to the server. Well - same problem: ServiceLocator gave me the proper EJB reference. So I guess it should also know - and only ServiceLocator should know - where to re-authenticate to.
The most important doubt:
c) to call methods on EJBs in this way, I have to use the Subject.doAs(subject, action) construct. This means that I will have to define one action object for each method which can be called on the stateful sessoin EJB by the client. For creating my stateful session EJB, then, I could create a "create" action right away, without the ServiceLocator needing to be involved. That "create" action would hand me back the reference to the EJB, and I could authenticate prior to doing that. In fact, only the "create" action needs to access ServiceLocator functionality with this design. So - is it still useful for anything ?
How would you combine ServiceLocator pattern with JAAS, in the case of the above scenario ?
Thanks,
J

Hi,
does JAAS authentication on the client somehow knock off the need for a ServiceLocator pattern?
Scenario:
1) I request reference to a stateful session ejb via ServiceLocator
2) ServiceLocator authenticates with user "anonymous" and creates that ejb and returns the reference to it, as well as my "subject" object.
3) I make some calls using Subject.Doas
4) at some point, I decide to switch identity, therefore re-authenticating to the server
5) I do method calls on the same ejb as before
Doubts about ServiceLocator pattern integration with JAAS:
a) in this scenario, ServiceLocator looks up the bean for me. Have I got to provide any URL for logging in also ? I guess I must somehow decide - just as with EJBs - where to find the server to authenticate to, am I right ? If yes, will I need to write servicelocator functionality for looking up the "URL" of the service/server to authenticate to ?
If I need no URL for logging in, then this doubt is of no importance
b) in step 4, I decide to switch identity by re-authenticating to the server. Well - same problem: ServiceLocator gave me the proper EJB reference. So I guess it should also know - and only ServiceLocator should know - where to re-authenticate to.
The most important doubt:
c) to call methods on EJBs in this way, I have to use the Subject.doAs(subject, action) construct. This means that I will have to define one action object for each method which can be called on the stateful sessoin EJB by the client. For creating my stateful session EJB, then, I could create a "create" action right away, without the ServiceLocator needing to be involved. That "create" action would hand me back the reference to the EJB, and I could authenticate prior to doing that. In fact, only the "create" action needs to access ServiceLocator functionality with this design. So - is it still useful for anything ?
How would you combine ServiceLocator pattern with JAAS, in the case of the above scenario ?
Thanks,
J

ServiceLocator on clustered environments

Hi!
I want to implement a ServiceLocator with an EJBHome caching mechanism.
It's clear that in a standalone OC4J instance it will improve performance, but what would happen in a clustered environment (oracle 9ias enterprise edition)?
I don't want to lose the ability to load balance bean creation and invocation, but I want to reduce initial context creation and JNDI lookup.
If I cache the EJBHome instances, does that mean that each subsequent call will be directed to the same oc4j instance?
Thanks
Franco Catrin
TUXPAN

Caching in clusters should work with a distributed caching system like JCACHE. A forerunner of JCACHE this is already integraed in oc4j ($OC4J_HOME/javacache) search the site about "Oracle Caching Service For Java (ocs4j)".
I haven't try this yet but I guess this cache is used for EntityBeans so it should or may work in the clustered version as well. :-)
Don't forget to synchronize your ServiceLocator if it is a singleton.

LocalHome caching in ServiceLocator - security credentials lost at runtime

I got a nasty exception when trying to use cached localhomes, which had been looked up after constructing an InitialContext with Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS:
javax.ejb.AccessLocalException: [EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB: ...
I finally had to disable localhome caching in my ServiceLocator, if security credentials were needed.
AppServer: WebLogic Server 8.1 SP3

I have the very same error using Weblogic Server 8.1 SP4. For now, caching in the ServiceLocator had to be removed. Debugging the server-code showed that the beans setContext-method is not called before entering the method requested by the client. The call fails when the first bean executes a remote-call to a second bean.

ServiceLocator made as Singleton

In my application ,there is a Servlet calling a ServiceLocator class which is responsible for caching and returning the JNDI reference , for accessing EJB .This ServiceLocator is made up of singleton and consisting of a static method for this .
I read that we can create only one object for a singleton .
I just wanted to know will this not be a bottleneck in a web application where all threads/requests are trying to access any operation ??
I dont know where to post this question .I am sorry if this is not an appropiate form.

Ok in that my answer is it depends on once requirements and what kind services we trying to access by using that singleton object.
But in general it will only reduce concurrency if the relevant methods are synchronized. There is no limit to the number of threads that can concurrently execute in a threadsafe object. If your objects are naturally threadsafe, any shared non-synchronized object will outperform any kind object pooling strategy, as there is no chance of contention factor being involved.
Therefore, in general i'd give a nod to pooling methodologies. However, as i said sometimes it depends on what the systems can offers.
REGARDS,
RaHuL

Service Paremeter and ServiceLocal parameter

What is the main difference between service parameter and service local parameter can any one tell me with good example

this post will help you in understanding .
Re: ATG Servlet Beans - serviceLocalParameter vs serviceParameter

Lookup on multiple ejb instances accross servers using servicelocator

Hi all,
i have a weird problem. I have to hit multiple ejbs hosted in diffrent server.
The problem is with the lookup and accessing..
some server's components have username and passwords and other server donot have.
So though i create a new Initial context instance with diffrent parameters.. it
is getting messed up inside. ie it is passing server A username and password to
server B's method call as for B i donot set username and password there is no
need of username and password.
the service locator will server for only one server's objects lookup. but here
we have multiple components in diffrent so different provider_URL INITIAL_CONTEXT_FACTORY,
SECURITY_PRINCIPAL, SECURITY_CREDENTIALS
and the for each i have a seperate sericelocator.. like each one for componet
A, B, C etc. in diffrent servers
and they inturn have InitialContext instance of their own. .. and these are initilized
with the factory, url, username and credentials...
this can be set as the system property also using -D option. thatz why .. when
i create for one component.... the already created Initial context factory is
getting affected with the new values. ;(((
one solution is every time create the Initial context... do not hold the reference
of contexts and donot hold reference of home handles..
but i need to cache atleast the home handles, if i am not caching.. the performance
is really bad.
on the cached handle if i call method i get a java.rmi.AccessException: Security
violation: insufficient permission to access method, though it worked for first
time,
and on the servers it which does not need passwords, method call is throwing java.lang.SecurityException:
Authentication for user ServerAUser denied in realm wl_realm
but the serverAUser belongs to server A, i get this error when i call a componets
method on Server B.
Is this a bug, or the Initial Context working it self is this way, the behind
the scence provider class is messing up. bea guys please reply if u know to solve
this problem, it will be of real help.
reagrds,
Arun.N

Problem resolved as this is an stateless session bean issues.

Missing files in SRDEMO ServiceLocator and UserInfo

Hi there
Using jdev 10.1.3.1 and working my way through the JavaEE_Tutorial[.pdf]. On page 67 it refers to two files: ServiceLocatorJava.txt and UserInfoJava.txt that contain the code for the two corresponding classes. I cannot find these anywhere and I've done a fairly extensive search. I prepared to be shown up as a numpty, but would quite like to get a copy of this files.
Also this CRUCIAL link appears to be broken:
http://download.oracle.com/otndocs/products/jdev/10131/JavaEE_tutorial_setup.zip
Thanks for your help
Jay

Okay - problem solved, the link is working again.

BusinessDelegate and ServiceLocator Design Pattern

Hi guys,
I have a question about the BusinessDelegate Pattern.
I would like to know where the BusinessDelegate and the ServerLocator implementation must be done?
On the client or on the server side.
Let's suppose I have a simple java client which calls a method on a Remote EJB deployed on an EJB server on a different machine.
The BusinessDelegate and the ServerLocator implementation must be either bundled with the client jar or
in the client classpath.
Is it correct??
Otherwise, if they are on the server side (part of the EJB jar) the client will never succeed in calling the BusinessDelegate method because the JNDI Lookup is done on the server side and the client has no way to see the BusinessDelegate on the Remote server.
Is it correct??
Please, help me understand this pattern.
I see all the time on the Diagrams the BusinessDelegate and the ServerLocator on the server side.
Thank you very much.
iako73

Hi,
The business delegate's purpose is to abstract the business tier implementation from the client.
It is used in the web tier (or any presentation tier) to hide the business service behind an interface, reducing the coupling between application layers.
If the business tier is implemented as EJB's or any J2EE container service accessible through JNDI. The Business delegate implementation uses the Service locator pattern to abstract and hide all JNDI calls from the delegate.
Hence both patterns are applicable and used in the presentation tier.
See core J2EE patterns for full description : http://java.sun.com/blueprints/corej2eepatterns/Patterns/

BusinessDelate & ServiceLocator

Similar Messages

Maybe you are looking for