• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Service Locator

 
Ranch Hand
Posts: 153
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As per J2EE design patterns, "the Service Locator pattern centralizes distributed service object lookups, provides a centralized point of control, and may act as a cache that eliminates redundant lookups"

Am going a bit off from the topic, but it interests me know that if we create a cache for the ServiceLocator, do we need to take care of how the application server has implemented the JNDI tree. For e.g. we need to know that is there a single JNDI server or multiple, if they are multiple are they synchronised.

How can the 'servicelocator' which we use in different parts of our code in real project be fault tolerant ? Assume that we have a Websphere Cluster (of 2 servers) and a real app is deployed in both the instances of the cluster. If one of the server goes down, will the servicelocator still work..assuming that it has cached the context of the jndi tree.

My question is actually since we are caching the JNDI context and references from a JNDI tree on a particular server in a cluster, it will always fail even though the app is running on a different cluster. Do note that though JNDI is a standard in J2EE, how the JNDI servers are part of the vendors implementation as a container service. It may be centrally managed or distributed across. Bit confused on this. Anyone have any experiences or ideas.

Or my assumption is wrong
thanks.
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Suekar,

"Core J2EE Patterns" speaks about this issue on page #316:

A Service Locator is typically implemented as a Singleton. However, J2EE applications run a J2EE container that typically uses multiple class loaders and JVMs, making it impossible to have a true Singleton with only one instance. Therefore, you might need multiple instances of the Service Locator in a distributed environment. However, since the Service Locator does not cache any data that needs to be concurrently accessed, you don't need to replicate and synchronize changes across these multiple instances.



Regards,
Dan
 
suekar meredilko
Ranch Hand
Posts: 153
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks.

Can I know How did you interpret this ?
 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Suekar,

Originally posted by suekar meredilko:
... if we create a cache for the ServiceLocator,


I do not know what this could mean. I just know looking up services like EJBs, narrowing and cast them and then finally convert them to Handles that can be locally stored in the client, i.e. cached, for not needing narrowing etc. the next time.


Originally posted by suekar meredilko:
... do we need to take care of how the application server has implemented the JNDI tree.


Each J2EE compliant application server comes with a JNDI server implementation.
But you need not use this one, you could use any LDAP server or any other JNDI implementor instead.
LDAP realizes JNDI.


Originally posted by suekar meredilko:
For e.g. we need to know that is there a single JNDI server or multiple, if they are multiple are they synchronised.


The Service Locator runs at client-side.
Each Service Locator [usually] knows only one [virtual] JNDI server address it has to connect to, regardless of clustering or not.
Note that in front of each _clustered_ JNDI server (or whatever clustered server) there is a load balancer (a little UNIX PC ... or specialized hardware).
The load balancer provides the address of the virtual (clustered) JNDI service, called VIP (Virtual IP).
A Load Balancer (like a database) per se is a Single Point of Failure that you need to mirror on the one VIP (instead of clustering multiple Load Balancers).
The JNDI servers themselves behind the Load Balancer may be clustered then (fail safe).


Originally posted by suekar meredilko:
If one of the server goes down, will the servicelocator still work..assuming that it has cached the context of the jndi tree.


The Service Locator just caches the handle of a reference to an EJB, not the whole "context of the jndi tree".
If the application server / EJB container that hosts that physical EJB goes down, its client gets an exception _once_ , but after that any new load will immediately be distributed to the remaining server[s] and the system immediately is sane again.
Therefore the client-side Service Locator will get the one Exception and than will immediately be redirected to a sane server, because the Service Locator knows only the VIP anyway.


Originally posted by suekar meredilko:
... it will always fail even though the app is running on a different cluster.


As far as I know even in destributed processing the distributed servers are behind one single Load Balancer with one VIP visible to the Service Locators.

(The Service Locator being a Singleton is a client-side optimization only.)


Originally posted by suekar meredilko:
Do note that though JNDI is a standard in J2EE, how the JNDI servers are part of the vendors implementation as a container service. It may be centrally managed or distributed across.


As said above, any JNDI implementation of the J2EE server needs not even be used.
We just need any JNDI service provider. There are some few publicly availyble: Sun, HP, IBM, ... .
And all the little companies not willing to pay their services can put a LDAP server [cluster] anywhere and give it a VIP and tell their Service Locators that VIP.

Thomas
 
suekar meredilko
Ranch Hand
Posts: 153
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
<qt>As far as I know even in destributed processing the distributed servers are behind one single Load Balancer with one VIP visible to the Service Locators.</qt>

Thanks for taking time to explain!

How about J2EE servers providing clusters. In a cluster there is no Load balancer concept. For e.g. in Websphere you may create a cluster containing to WAS Servers. Deploy your applications in both the servers..that ways makes them more available.

Sorry...getting a bit deep here.
--------------------------------
Now if a serviceLocator is part of an EAR which is deployed in both servers. You meant to say that a singleton ServiceLocator will be then deployed in both the servers.

a Service locator could do the following

1) Get the JNDI Context
2) Use the JNDI context to return Reference of Home (by which you can go ahead and store handles for later use and so on)

Now, what happens if I cache the JNDI context. If there is no load balancer am I right to say that servicelocator could pose problem if I start caching the context.

How is it done in real world.

Ok, in my company what we have done is..though we have an external LDAP (IBM Secureway) but we do not use it as the JNDI context for storing EJB Home. Instead we use the J2EE server's (Websphere) provided one and there is no Load Balancer in place because the container itself provides the services. In a cluster, I am assuming there will be 2 instances of jndi server then if a cluster contains 2 servers.

So is my remark correct that if you use J2EE servers JNDI implementation and if you have cached the context(InitialContext ic = new InitialContext()) for later use when performing look-ups. If the jndi server is down for some reason..this caching can lead you to problems ?
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

Originally posted by suekar meredilko:
How about J2EE servers providing clusters. In a cluster there is no Load balancer concept.


One of the app servers might take the additional role of a Load Balancer for all app servers of that cluster. I.g. SAP WebAS 6.40 does so.


Originally posted by suekar meredilko:
Sorry...getting a bit deep here.


... deep and interisting - no reason to be sorry.


Originally posted by suekar meredilko:
Now if a serviceLocator is part of an EAR which is deployed in both servers.


Because a Service Locator is a client-side thing, a Service Locator may be part of clients' .jar or a .war but a Service Locator typically will not be part of a .ear .


Originally posted by suekar meredilko:
You meant to say that a singleton ServiceLocator will be then deployed in both the servers.


A singleton should not be deployed to any J2EE container - for other reasons (static ...).
A Service Locator typically will not be deployed to a EJB container, as mentioned above.


Originally posted by suekar meredilko:
a Service locator could do the following
1) Get the JNDI Context
2) Use the JNDI context to return Reference of Home (by which you can go ahead and store handles for later use and so on)
Now, what happens if I cache the JNDI context. If there is no load balancer am I right to say that servicelocator could pose problem if I start caching the context.


Isn't that JNDI Context a client-side thing?
As said if a container went down you will once get an exception. On this Exception we could throw off the old JNDI context and get a new one, but I do not even think that this is needed. What happens when we say


is that we tell the client (using the InitialContext) the JNDI provider URL and the JNDI factory class.
(When we use new InitialContext() without parameter then this works only if the provider url etc. is known by default.)
As long as the URL (or VIP) of the JNDI provider does not change, everything behind may change - resulting in some few exceptions only.

Thomas
 
suekar meredilko
Ranch Hand
Posts: 153
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

quote: Thomas wrote
---------------------------------------------------------------------------
One of the app servers might take the additional role of a Load Balancer for all app servers of that cluster. I.g. SAP WebAS 6.40 does so.
---------------------------------------------------------------------------
COOOOOL !


quote: Thomas wrote
---------------------------------------------------------------------------
Because a Service Locator is a client-side thing, a Service Locator may be part of clients' .jar or a .war but a Service Locator typically will not be part of a .ear .
---------------------------------------------------------------------------
Thomas, I dont agree with you here. Because even EJB calling other EJBs will use the JNDI context, look ups etc. Service Locator would be used even then. So it will be part of the EAR.



quote: Thomas wrote
---------------------------------------------------------------------------
A singleton should not be deployed to any J2EE container - for other reasons (static ...).
A Service Locator typically will not be deployed to a EJB container, as mentioned above.
---------------------------------------------------------------------------

I think its a good practice to avoid Singletons as much. I agree. But again like I mentioned above ServiceLocator would be required by EJBs calling other EJBs.




quote: Thomas wrote
---------------------------------------------------------------------------
Isn't that JNDI Context a client-side thing?
As said if a container went down you will once get an exception. On this Exception we could throw off the old JNDI context and get a new one, but I do not even think that this is needed. What happens when we say
---------------------------------------------------------------------------


Yes, if there is a load balancer in place it will swing. Agreed with you.
No, if tehre is no load balancer, problems will arise.
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by suekar meredilko:
But again like I mentioned above ServiceLocator would be required by EJBs calling other EJBs.


Hello Suekar,
you are right that in case
- a Session EJB calls Entity EJBs
- AND both kinds of EJBs are in the same .ear
then the Service Locator provided for and used by the client (= Session EJB) is in the same .ear .

What I wanted to point out with "typically" is that the Service Locator is in the clients' .jar (also if being a .war or a cummulative .ear).

Ok, I got your point.
Thomas
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by suekar meredilko:
No, if tehre is no load balancer, problems will arise.


Suekar, I would like to understand:
- Which problems will arrise
- where and
- on which defects in which node?

Thomas
 
suekar meredilko
Ranch Hand
Posts: 153
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Thomas Taeger:

Suekar, I would like to understand:
- Which problems will arrise
- where and
- on which defects in which node?

Thomas




- I meant problems pertaining to availability since we cache the context for reusing and not making connections. If there is no load balancer then this caching in a serviceLocator will affect the client looking up and failing again and again.

- Where --> In the client using the ServiceLocator
- The application client or ejb hosting node
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by suekar meredilko:
If there is no load balancer [...]


Yes, Suekar,
and that was my reason to mention that a Load Balancer is a Single Point of Failure. If the Load Balancer the VIP points to is defective and there is no mirroring Load Balancer on the same VIP then the client-side Service Locater has no chance to reaqch the server behind the Load Balancer.

That shows the importance of
- mirroring each Load Balancer and
- all in all having a reliable network

Thomas
 
You save more money with a clothesline than dozens of light bulb purchases. Tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic