|
Home > Archive > WebSphere Application Server > April 2005 > NameSpace isolation between servers within a node
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
NameSpace isolation between servers within a node
|
|
|
| Hi,
We've encountered in WAS 5.1 that ejb registered on one server are not accessible by the ejb's on another server
within a node which is not federated into a cell. Does
anybody know why this is the case?
Another related thing is why namespacebindings which are
stored in namebindings.xml are not available for all
servers due to the fact that they are stored in node
persistent root. It looks like attribute bindingLocation which is set to SINGLESERVER should have another value to make have the name space bindings entered in every server's
nameserver.
Regards,
Jan
| |
| Paul Ilechko 2005-04-28, 6:01 pm |
| j.j.brunia@chello.nl wrote:
> Hi,
>
> We've encountered in WAS 5.1 that ejb registered on one server are
> not accessible by the ejb's on another server within a node which is
> not federated into a cell. Does anybody know why this is the case?
Are you using the correct providerURL for the remote server?
>
> Another related thing is why namespacebindings which are stored in
> namebindings.xml are not available for all servers due to the fact
> that they are stored in node persistent root. It looks like attribute
> bindingLocation which is set to SINGLESERVER should have another
> value to make have the name space bindings entered in every server's
> nameserver.
If you're not in a cell, you don't have a federated namespace, so this
sounds right.
A more elegant way to handle this, rather than hard coding provider
URLs, is to create an indirect reference - the following info is written
for cross-cell EJB access, but it should be similar in your case, other
than your binding locations. Rather than cell/clusters you will
presumably be binding to the node persistent namespace:
You can perform JNDI lookups using your current appServer(no providerURL
given in InitialContext creation) for applications within and outside
your cell.
For either case, the client module(web module or ejb) would have an EJB
Reference in its deployment descriptor.
If the EJB Reference was "ejb/StockService", then the application code
would perform the JNDI lookup using "java:comp/env/ejb/StockService"
At deploy time(default values are put into the deployment descriptor,
but can be overriden during application deployment), the local EJB
references are bound to a global JNDI name.
1) For a server in the same cell as the ServerCluster hosting the
remote EJB, assuming the remote EJB was bound into "ClusterA" with JNDI
name "ejb/MyStockService", the client EJB reference would be bound to:
"cell/clusters/ClusterA/ejb/MyStockService"
Later, if the remote service gets moved to a different server cluster,
then the client application bindings would have to be updated.
2) For a server in a different cell as the ServerCluster hosting the
remote EJB,
assuming the remote EJB was bound into "ClusterB" with JNDI name
"ejb/CellBService",
then you would create an indirect reference through the WAS Admin
console for the client cell.
The indirect reference would be stored in the cell-persistent area of
the namespace.
From AdminConsole->Environment->Naming->Name Space Bindings -> New(leave
at cell scope)
The properties you would set are:
Binding Type: Indirect
Binding Identifier: My outside cell serviceX
Name in Name Space: "ejb/OutsideCellService" -> this is what the client
bindings use for mapping
Proivder URL: "iiop://cellBHost:2819" where cellBHost is a server in
the outside cell and 2819 is its bootstrap port
JNDI Name: "cell/clusters/ClusterB/ejb/CellBService"
The client EJB reference would be bound to:
"cell/persistent/ejb/OutsideCellService"
Later, if the remote service gets moved to a different server cluster,
then the indirect bindings would have to be updated.
|
|
|
|
|