Service Locator EJB Component - Clustering -oracle9iAS

hi all,
Anyone has idea on how to implement the service locator (EJBHomeCache) component to make it cluster aware. I am using the oracle9iAS server.
thanks,
Viral

Anyone has idea on how to implement the service
locator (EJBHomeCache) component to make it cluster
aware. I am using the oracle9iAS server.What do you mean when you refer to cluster awareness?

Similar Messages

Web-services.xml for EJB component and SOAP Message Handler Chain

I have used the following example for my own web service with EJB component and SOAP
Message Handler Chain:
http://e-docs.bea.com/wls/docs70/webServices/dd.html#1058208
I have a deployment error:
javax.naming.NameNotFoundException: Unable to resolve 'app/ejb/DocumentService.j
ar#DocumentService/home' Resolved: 'app/ejb' Unresolved:'DocumentService.jar#Doc
umentService' ; remaining name 'DocumentService.jar#DocumentService/home'
In attachement is the ear file.
Is there a problem in web-services.xml?
Thanks
[ws_dox_sdi.ear]

It works. Thanks,
Ioana
"Neal Yin" <[email protected]> wrote:
The error means your EJB is not deployed.
Adding a EJB module to your application.xml file of the ear should fixe
it.
<application>
<display-name />
<module>
<web>
<web-uri>dox_sdi.war</web-uri>
</web>
</module>
<module>
<ejb>DocumentService.jar</ejb>
</module>
</application>
"Ioana Meissner" <[email protected]> wrote in message
news:3cf640cc$[email protected]..
I have used the following example for my own web service with EJBcomponent and SOAP
Message Handler Chain:
http://e-docs.bea.com/wls/docs70/webServices/dd.html#1058208
I have a deployment error:
javax.naming.NameNotFoundException: Unable to resolve'app/ejb/DocumentService.j
ar#DocumentService/home' Resolved: 'app/ejb'Unresolved:'DocumentService.jar#Doc
umentService' ; remaining name 'DocumentService.jar#DocumentService/home'
In attachement is the ear file.
Is there a problem in web-services.xml?
Thanks

Using service Locator pattern to dynamically access remote EJBs

Hi All,
Please help to guide me how I can use a service locator to retrieve a remote object (residing on another application but on same domain) .
I do not want to use Dependency Injection since I want to dynamically discover them ( there are many implementations of same interface (POJO)). Each EJB implementation implements its own remote/local interface that extends this global POJO interface.
I have two J2ee-Applications on same domain. J2EE-Application 1 has an EJB module (EJB Module 1) that intends to access an EJB Module (EJB Module 2) in J2EE-Application 2. Following observations:
1. Dependency Injection fails if (include the EJB Module 2 jar in J2EE-Application 1). Reason App Server complains the EJB has been deployed (Deployment fails)
2. Dependency Injection works if (exclude the EJB Module 2 jar in J2EE-Application 1) and include the Remote Interface in EJB Module 1(J2EE-Application 1).Positive Observation (Deployment success and DI also success)
3.Using Service Locator to retrieve the remote object if (exclude the EJB Module 2 jar in J2EE-Application 1) and include the Remote Interface in EJB Module 1(J2EE-Application 1). Negative and Positive Observation.
Positive Observation: Using dependency injection I can still retrieve the Remote Object
Another Positive: The Service Locator remote lookup to another Bean in same Application but different EJB Module is successful.
Negative Observation:
The Service Locator lookup to this same remote object with Successful Dependency Injection fails (An Ejb in a different application).
Can't retrieve the Remote Object with Service Locator. Message from Server:.
NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial.
Thanks in advance

"I do not want to use Dependency Injection since I want to dynamically discover them ( there are many implementations of same interface (POJO))"
If you're calling ejbs from other ejbs or servlets, the same could probably be acomplished by using dependency injection (@EJB) in a number of instance variables typed with different remote/local interfaces or even with different beanName attributes (for when more than one bean implements the same managed interface in the same app - not sure how it works outside the same jee app...) , and dinamically selecting one of them; or encapsulating those injected variables into a stateless ejb as your service locator to make them accessible from POJOs too (which, due to concurrent acess, wouldn't work for statefull ejbs references...).
Anyway, using the jndi lookup service locator pattern seems ok in this case.
What doesn't seem ok, given the nature of the error for the negative observation - jndi context initialization - is that
Another Positive: The Service Locator remote lookup to another Bean in same Application but different EJB Module is successful.
Can you check your code and reconfirm that you're using the same context initialization code for both the positive and negative observations ?

EJB 3.x business delegate & service locater

Hi all
are business delegate & service locater patterns still relevant when considering EJB 3.x? Why or why not?
Does dependency inversion replaces service locater? was there dependency inversion in EJB 2.x??
Thx a lot

Hello,
Business Delegate is still relevant while using EJB 3.0
Business Delegate reduces coupling between presentation-tier clients and business services, that does not change with EJB 3.0.
However, Service Locator can be avoided by the Dependency injection provided by java EE5.
But, remember, Dependency injection works only for object managed by the container, so, Service locator can yet be useful in ejb 3.0.
Regards,
Sebastien Degardin

Service Locator and session facade pattern

What are differences between Service Locator and session facade pattern?
For me it seems one and the same.
Please explain me in detail. Expecting kind help.
Thanks,
Rahul
Edited by: rahulb1 on Feb 26, 2008 5:07 PM

rdoekes wrote:
The ServiceLocator Pattern is a singleton which hold a map of used DataSources. The idea is that you perform a lookup once and use the cache afterwards. The session facade is just one DataSource lookup.huh? Those J2EE patterns are not really reduced to datasources and the SessionFacade has actually nothing to do with datasources.
Session Facade
It has Facade in it and a Facade is usually used to give a simple entrypoint by providing a standartized interface. The same is now with the Session Facade. You have a Session bean that represents a high-level business component that interacts and calls lower-level business components.
Imagine having client a accessing 5 business objects with the remote calls, which is not an efficient way (network latency) or accessing the SessionFace and the session face is doing all the work through local access.
Service Locator
As J2EE components are using JDNI to lookup for ejb interfaces,DataSources, JMS components, connections etc. isntead of writing all the lookup in many code piecess across the project, you write a service locator that gives you a centralized place to handle the lookup's. It's easier to maintain and to control such a setup.
As you can see there's quite a big difference ;-)
cya,
Nail

SERVICE LOCATOR ?? Is it really an interesting Design pattern??

Hi everybody,
i've a problem with the J2EE Design Pattern "Services locator" (it's a singleton).
It is said that by making use of a Service Locator we can :
- hide to the client the complexities of initial context creation, EJB home object lookup,and EJB objectre-creation.
- multiple clients can reuse the Service Locator object to reduce code complexity, provide a single point of control, and improve performance by providing a caching facility.
But i would like to understand at which side should that service locator object reside??!!??
If it is at server side then the clients need well an initial context in order to make a lookup on that object.
Conclusion :
the service locator doesn't hide the complexities of initial context!!
Furthermore the client has to perform a look-up on that service locator object!! The only advantage left is caching facility.
If it is at client side, each client needs his own services locator object
Conclusion :
multiple client don't reuse the same service locator. What's the advantage to be a singleton ???
There is certainly something that i don't understand so help me please!! Thanks.

Hi Yves,
But i would like to understand at which side should
that service locator object reside??!!??
If it is at client side, each client needs his own
services locator object
Conclusion :
multiple client don't reuse the same service locator.
What's the advantage to be a singleton ???The service locator resides on the client side and is implemented as
a singleton. Since it is possible that there could be multiple
class loaders/JVMs on the client side, and therefore, multiple
instances of the "singleton" service locator. This is typical
in a distributed environment (e.g. servlets/JSPs in a web-tier
cluster using service locator). Thus service locator is not
a truly "distributed singleton" object. But, the empahsis
is to design the service locator such that it does not hold
any state that needs to be replicated across multiple
instances across different JVMs as mentioned. Thus, there
is no need for multiple clients to use the "same" service locator,
but still the benefits of implementing this pattern is realized.
By making it a singleton, and keeping it from holding state
that needs to be replicated, we realize the benefits of this pattern.
You may also want to visit the J2EE Pattern interest list
and see these relevant discussions :
Topic: Service Locator and passivation
http://archives.java.sun.com/cgi-bin/wa?A2=ind0106&L=j2eepatterns-interest&F=&S=&P=1026
Topic: Caching EJBHome interfaces
http://archives.java.sun.com/cgi-bin/wa?A2=ind0106&L=j2eepatterns-interest&F=&S=&P=9226
Topic: Using Service Locator for Data Source caching
http://archives.java.sun.com/cgi-bin/wa?A1=ind0106&L=j2eepatterns-interest#31
hope this helps,
thanks,
-deepak

How to give Service locator in flash builder 4.5

hi friends,
In flex 3.0 we are giving service locator like this
<?xml version="1.0" encoding="utf-8"?>
<cairngorm:ServiceLocator xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:cairngorm="com.adobe.cairngorm.business.*">
</cairngorm:ServiceLocator>
How to give in flash builder 4.5 i tried in same way it is not recognizing ServiceLocator.
How to do in 4.5

Ya i tried by keeping <fx:Declarations> part but still it is throwing error,
In flex3 we are making a component ex: <mx:canvas> and changeing that component to
<cairngorm:ServiceLocator xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:cairngorm="com.adobe.cairngorm.business.*">
</cairngorm:ServiceLocator>
if any one used 4.5 with cairngorm let me know
thanks

NoSuchMethodError when invoking EJB Component From BPM Process

Hi,
I created BPM process which contains global creation activity and user interactive activity and catalogued ejb component. In user interactive activity i wrote the Process Business Language to invoke Remote EJB deployed in weblogic server. When i tried to execute user interactive activity, i got the following exception.
Caused by: java.lang.NoSuchMethodError: weblogic.kernel.KernelStatus.isThinIIOPClient()Z
     at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.readObject(RemoteBusinessIntfProxy.java:192)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at java.io.ObjectStreamClass.invokeReadObject(Unknown Source)
     at java.io.ObjectInputStream.readSerialData(Unknown Source)
     at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
     at java.io.ObjectInputStream.readObject0(Unknown Source)
     at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
     at java.io.ObjectInputStream.readSerialData(Unknown Source)
     at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
     at java.io.ObjectInputStream.readObject0(Unknown Source)
     at java.io.ObjectInputStream.readObject(Unknown Source)
     at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:195)
     at weblogic.rjvm.MsgAbbrevInputStream.readObject(MsgAbbrevInputStream.java:565)
     at weblogic.utils.io.ChunkedObjectInputStream.readObject(ChunkedObjectInputStream.java:191)
     at weblogic.rmi.internal.ObjectIO.readObject(ObjectIO.java:62)
     at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:201)
     at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:338)
     at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:252)
     at weblogic.jndi.internal.ServerNamingNode_921_WLStub.lookup(Unknown Source)
     at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:374)
     at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:362)
     at javax.naming.InitialContext.lookup(Unknown Source)
     at fuego.jndi.FaultTolerantContext.lookup(FaultTolerantContext.java:515)
     at fuego.connector.impl.BaseRemoteConnector.getReferencedObject(BaseRemoteConnector.java:116)
     at fuego.connector.impl.BaseRemoteConnector.getReferencedObject(BaseRemoteConnector.java:107)
     at fuego.ejb.EJBConnector.getEJBHome(EJBConnector.java:62)
     at fuego.ejb.EJBConnector.getEJBHome(EJBConnector.java:52)
     at fuego.ejb.EJBConnector.getResource(EJBConnector.java:101)
     at fuego.ejb.EJBConnector.getResource(EJBConnector.java:91)
     at fuego.ejb.EJBConnector.getResource(EJBConnector.java:79)
     at fuego.connector.ConnectorTransaction.getResource(ConnectorTransaction.java:276)
     at fuego.connector.EJBHelper.getEJBHome(EJBHelper.java:36)
     at fuego.connector.EJBHelper.getEJBHome(EJBHelper.java:30)
     at fuego.ejb.EJBHome.locate(EJBHome.java:119)
     at OrderManagement.SampleOrderProcess.Default_1_0.Instance.CIL_submitOrder(Instance.xcdl:1)
     at OrderManagement.SampleOrderProcess.Default_1_0.Instance.CIL_submitOrder(Instance.xcdl)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at fuego.component.ExecutionThreadContext.invokeMethod(ExecutionThreadContext.java:512)
what i noticed here is in Oracle BPM Studio there is weblogic jar file which contains Kernel status file. The KernelStatus file do not have "isThinIIOPClient method". But in wlclient jar file there is Kernel status class which contains "isThinIIOPClient" method.
How can I override the weblogic.jar and wlclient.jar for Oracle BPM?
Please help me to resolve this problem.
Thanks and Regards
Mahesh Babu

I resolved the above issue by generating ejb2.1 session bean and ejb2.1 client. But When i tried to invoke ejb2.1 session bean from process using Process Business Language, it throws the following exception.
Task failed.
Caused by: Task '0' in activity '/SampleOrderProcess#Default-1.0/Interactive[SubmitOrder]' for instance '/SampleOrderProcess#Default-1.0/1/0' could not be successfully executed. The task failed while executing method 'submitOrder'.
Caused by: The method 'CIL_submitOrder' from class 'OrderManagement.SampleOrderProcess.Default_1_0.Instance' could not be successfully executed.
Caused by: java.lang.IncompatibleClassChangeError
Caused by: fuego.lang.ComponentExecutionException: The method 'CIL_submitOrder' from class 'OrderManagement.SampleOrderProcess.Default_1_0.Instance' could not be successfully executed.
     at fuego.component.ExecutionThreadContext.invokeMethod(ExecutionThreadContext.java:519)
     at fuego.component.ExecutionThreadContext.invokeMethod(ExecutionThreadContext.java:273)
     at fuego.fengine.FEEngineExecutionContext.invokeMethodAsCil(FEEngineExecutionContext.java:219)
     at fuego.server.execution.EngineExecutionContext.runCil(EngineExecutionContext.java:1280)
     at fuego.server.execution.TaskExecution.invoke(TaskExecution.java:401)
     at fuego.server.execution.InteractiveNormalCilExecution.invoke(InteractiveNormalCilExecution.java:425)
     at fuego.server.execution.TaskExecution.executeCIL(TaskExecution.java:513)
     at fuego.server.execution.TaskExecution.executeTask(TaskExecution.java:697)
     at fuego.server.execution.TaskExecution.executeTask(TaskExecution.java:657)
     at fuego.server.execution.TaskExecution.executeTask(TaskExecution.java:154)
     at fuego.server.execution.microactivity.InteractiveMicroActivity.executeNormalCil(InteractiveMicroActivity.java:501)
     at fuego.server.execution.microactivity.InteractiveMicroActivity.executeItem(InteractiveMicroActivity.java:454)
     at fuego.server.execution.microactivity.InteractiveMicroActivity.execute(InteractiveMicroActivity.java:104)
     at fuego.server.AbstractProcessBean$48.execute(AbstractProcessBean.java:3184)
     at fuego.server.execution.DefaultEngineExecution$AtomicExecutionTA.runTransaction(DefaultEngineExecution.java:304)
     at fuego.transaction.TransactionAction.startBaseTransaction(TransactionAction.java:470)
     at fuego.transaction.TransactionAction.startTransaction(TransactionAction.java:551)
     at fuego.transaction.TransactionAction.start(TransactionAction.java:212)
     at fuego.server.execution.DefaultEngineExecution.executeImmediate(DefaultEngineExecution.java:123)
     at fuego.server.execution.EngineExecution.executeImmediate(EngineExecution.java:66)
     at fuego.server.AbstractProcessBean.runTask(AbstractProcessBean.java:3188)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at fuego.lang.JavaClass.invokeMethod(JavaClass.java:1410)
     at fuego.lang.JavaObject.invoke(JavaObject.java:227)
     at fuego.component.Message.process(Message.java:585)
     at fuego.component.ExecutionThread.processMessage(ExecutionThread.java:780)
     at fuego.component.ExecutionThread.processBatch(ExecutionThread.java:755)
     at fuego.component.ExecutionThread.doProcessBatch(ExecutionThread.java:142)
     at fuego.component.ExecutionThread.doProcessBatch(ExecutionThread.java:134)
     at fuego.fengine.FEngineProcessBean.processBatch(FEngineProcessBean.java:244)
     at fuego.component.ExecutionThread.work(ExecutionThread.java:839)
     at fuego.component.ExecutionThread.run(ExecutionThread.java:408)
Caused by: java.lang.IncompatibleClassChangeError
     at OrderManagement.SampleOrderProcess.Default_1_0.Instance.CIL_submitOrder(Instance.xcdl:5)
     at OrderManagement.SampleOrderProcess.Default_1_0.Instance.CIL_submitOrder(Instance.xcdl)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at fuego.component.ExecutionThreadContext.invokeMethod(ExecutionThreadContext.java:512)
     ... 34 more
Please help me to resolve this issue.
Thanks and Regards
Mahesh Babu

Adaptative web service or EJB ?

Hi everybody,
I want consume a web service from a system SAP R/3.
Apparently, we can consume with component EJB ...
What is the difference between a adaptative web service and EJB ?
More security with EJB ?
Thanks
Rodolphe.

Hi,
We use for ejbs when we have to store data in database..
if ejbs r like a medium for data transfer..where session bean contain ur business logic..
u cn use webdynpro interface as well as jsp interface wid ejb..
if u r using ejb u'll have to create an ejb projct first then u'll hav to create java proct which will contain ur wrapper class for fields.later on u'll have to create one application project tht wud b an Ear projct.nw u create a web service for session bean ..aftr doin this all u can test webservice which will b executed for ur business method.
for more security u can use ejb security model :[http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security.html]
Web services r created for session bean..so that u cn directly access ur methods via url..
for a detailed description of web service go through :- [http://help.sap.com/saphelp_nw04/helpdata/en/d6/f9bc3d52f39d33e10000000a11405a/content.htm]
for ejb project go through this1 :[https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/ca4a9c90-0201-0010-c389-8738cd51a88e]
Regards,
Khushboo

Can we implement "Service Locator" in Stateless Session Bean??

Hi,
My enterprise application is using Stateless Session Bean. To increase the performace , I think of implementing "service Locator" pattern so as to cache the EJBHome objects in order to avoid looking up Home object every time. I want to know whether this will work out in case of stateless session bean??
Thanks for ur help.

Hi,
The purpose of service locator is to abstract the lookup of the server side services like ejb and DSNs. It should be a normal java class but as such there is no such restriction. You can have a look at the service locator patter at the j2ee blue prints.
/Ashwani

Service Locator and Performance?

We currently have an application with numerious EJBs. Obviously, this in turn involves
numerous JNDI look ups for these EJBs. Both the client (a web application) and
the EJBs run within the same JVM, however not as part of a singe EAR application
(the EJBs are deployed as standalone application modules). We do not have any
Service Locator (J2EE pattern) implemented. My question is, given this scenario,
will there be a performance enhancement if a Service locator is implemented to
cache JNDI look-ups? If so, Will this come into play if we deploy the app as an
EAR?
Thanks,
Krish

There are a lot of tools out there.
Here's what I've used:
On Windows/Linux, OptimizeIt and Jprobe are pretty common.
If you're using jrockit, try JRA
http://dev2dev.com/products/wljrockit81/analyzer.jsp
On HP-UX, I like HP's JMeter:
http://www.hpjmeter.com
-- Rob
Krish wrote:
Is there a Profiling tool that I could use to identify where most of the time is
being spent?
Thx,
Rob Woollen <[email protected]> wrote:
If your end goal is to improve performance, then I'd strongly encourage
you to spend some time tracking down where time is currently being spent.
In my experience, creating InitialContext objects can be expensive.
Lookups generally aren't that bad, but it's a reasonable approach to
cache both.
Basically, if you're spending a lot of time in JNDI lookups, then I'd
suggest doing the Service Locator pattern. If your time is being mainly
spent elsewhere, attack that first.
-- Rob
Krish wrote:
We currently have an application with numerious EJBs. Obviously, thisin turn involves
numerous JNDI look ups for these EJBs. Both the client (a web application)and
the EJBs run within the same JVM, however not as part of a singe EARapplication
(the EJBs are deployed as standalone application modules). We do nothave any
Service Locator (J2EE pattern) implemented. My question is, given thisscenario,
will there be a performance enhancement if a Service locator is implementedto
cache JNDI look-ups? If so, Will this come into play if we deploy theapp as an
EAR?
Thanks,
Krish

Using Service Locator in Struts app without ant eejb components

Hi
We are developing a Struts application witjout any EJB components.
But we may go for EJB in future.
Keeping that in mind we want to introduce a service locator between the action class and the business logic. So it may be easier to acomodate in future.
But how do i do that ? Can anyone help me in this?
Since all the Service locator example which i have seen is implemented using ejb
Please do help me in this
Thanks
Ottran

Controller (Action class) gets reference to Business Delegate (BD) and calls a particular business method.
The BD gets reference to Service Locator (from JNDI tree) to access a business service. The business sevice can be implemented using EJB, POJO, Web Service, legacy app, etc.
A UML diagram is available at
http://www.softwareleadership.org/docs/J2EEDesignPatterns.html
Click on Business Delegate to view diagram with Service Locator.

Service locator

OK - this may take some time.....
We have an application split across multple projects. We use XDoclet as a start point to generate EJB/Web deployment descriptors.
We do not want to annotate the EJB java source with @ejb-ref and @ejb-local-ref's because of potential future changes. In other words if a utility class were changed to use an EJB, then all EJB's that use that utility class need to have an ejb-ref or ejb-local-ref added to their deployment descriptor, which if you are using XDoclet means updating the EJB java source.
So, we use XDoclet to generate most of the deployment descriptor content, and take responsibility for working out what ejb-ref or ejb-local-refs are required for each EJB as part of our packaging step in our build. We do this by using BCEL to build up a cross-reference of the inter-relationships between classes, and identify which classes have strings that begin java:comp/env/ejb/. Starting at the implementation class of an EJB, we exhaust all classes that are used by the EJB, accumulating all the lookup strings along the way. This may seem like overkill, but it works.
OK, we're getting closer to the question.
It has been suggested that we can remove this step of the build process by enhancing our service locator. Since all of our lookups are routed through this locator, the proposal is to put the actual lookup for the required EJB inside a new stateless session bean that is invoked from the service locator. The cache of EJBHomes is still in the service locator, and the new session bean will implement a local interface only.
This means that effectively all of our EJBs except the new session bean only have to have an ejb-local-ref for the new session bean, and the new session bean simply has all ejb-ref/ejb-local-ref's required by the application.
So my question is, is this an acceptable suggestion? We are talking about returning EJBHome objects from another EJB's context for use in the requesting EJB's context. Can anyone think of a problem with this? Apparently this has been mocked up and seems to work. I just have a nagging reservation about going ahead with this.
Our ref names are consistent across all of our EJB's, so java:comp/env/ejb/Fred always results in the same JNDI name regardless of which EJB is used, and this would not change in the future.
We are targeting J2EE 1.4/J2SE1.4.2
Got there in the end....
Many thanks for any views on this.

cpallab wrote:
A service can be offered by objects, or objectCould you explain what that even means?

Service Locator pattern question.

Hi,
We have this kind of service locator which provides the caller a reference to a remote interface instead of to the home interface of the session bean. We're working with weblogic 6.1. My question, is it ok to store a reference to a remote interface in the service locator or is it better to store a reference to the home interface or .... is it better to not store them but every time create one when a client wants one. What is the best way and the pros and cons.
Cheers!

Hi,
typically it is more common to just cache Homes and Factories in the ServiceLocator pattern.
We have a detailed example of the Service Locator pattern applied in an application at http://java.sun.com/blueprints/patterns/ServiceLocator.html
We cache the EJB Homes and other Factories.
http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servicelocator/web/ServiceLocator.java.html
This allows the Service Locator to be used as a utility class. We have a Service Locator used by the web tier, and also one used by the EJB tier to lookup other EJBs and resources.
hope that helps,
Sean

Server-side Service-Locator

Hi,
i have written a ServiceLocator for the web-tier. This Service-Locator uses a cash for the EJB-Homes to increase performance.
Is it intelligent to write a ServiceLocator like this for the ejb-container?
Makes a cash of EJB-Homes in the ejb-container sense?
Can i estimate performace Enhancements?
best regards
Daniel Niklas

Daniel Niklas wrote:
Is it intelligent to write a ServiceLocator like this
for the ejb-container?Yes, but be very careful in doing so. You need to understand class loading and the finer pitfalls of working with classes in EJB-space.
Makes a cash of EJB-Homes in the ejb-container sense?I think you mean cache - sounds the same, but two different meanings... However, you shouldn't cache the Home implementations themselves. It's much safer to use the HomeHandle objects.
Can i estimate performace Enhancements?My own benchmarks showed a performance increase of about 2x to 3x: about 30 ms for a full lookup vs. about 13 for the cache. You should do your own benchmarking - vendor implementations are not all created equal.
=============
Christian wrote:
The following implementations are standard:Since when? I can't seem to find any standards document listing those. If you mean typical, then I might agree that some of them are.

Service Locator EJB Component - Clustering -oracle9iAS

Similar Messages

Maybe you are looking for