One session bean cannot implement multiple endpoints?

Question

Hi.
I have a stateless session bean, and I wanted it to implement two endpoints.
So, the bean had to be responsible for two web services.
However, this does not seem to be possible.
I do not know enough of J2EE to understand why this is, could anyone please enlighten me? :)
But more important, what should I do now?
The first webservice consists of a stateless session bean as endpoint which contains a static object, which manages the information needed for the bean to perform it's task. The object is static, because there can only be one instance of the information.
The second webservice is used to alter the information that the beans of the other webservice use. Thus, the bean that implements this webservice needs to acquire a reference to the information object of the other webservice's beans.
As you can image, it would have been very handy if both webservices were implemented by the same bean...
In short, I have two beans that both have to be able to access a single object.
The best idea I have now is to create a third bean which manages the information, and have both other beans connect to this bean using local interfaces to manage the information? Is this possible?
Although it's kind of stupid to create a bean for managing the information, as there may only be one instance of the information ... If I would do it with a bean, I would let it have a static field containing the information.
But that kind of defeats the use of beans right?
If beans are meant to be pooled, isn't it kind of stupid if they all access a shared object? Why use a bean to represent the information if there can only be one instance of the information? :s
I'm also thinking of the concurrency ... I suppose x threads changing the fields of that object at the same time isn't really healty ... And locking is so dirty :s .
However, 99% of the accesses to this object will be read accesses, and the information in the object is expected to be updated only on a daily basis or so ...
Which makes locking not that dirty after all...
Anyway, you can see that I'm stuck here!
Any advice would be really great!

Answer 1

My original motivation for the use of one object that manages the information needed for the beans to operate was to prevent DB accesses.
All the session beans need the same information to operate, so it would be stupid to let every bean get it's information from the database if you can read it once into an object and let the beans get their information from the object.
In other words: do caching for the database.
However, I'm wondering if this motivation is correct:
I can imagine the DB does it's own caching at some point, so I wonder if it even has advantages to do any extra caching...
However, the caching object knows exactly when it needs to update it's information, so it has an advantage...
Anyway, the idea of having shared information (in the static field of the bean) might seem like a bad idea, I can't really think of a valid reason why it should be.
99% of the accesses to the shared information will be read accesses, so thread-wise that's no problem. And the writes will be synchronized.
Anyway I'm going ahead with my initial design, until I get a better suggestion...
About your suggestions:
1. -> That resembles the situation where each bean accesses the DB directly I guess.
2 & 3: -> If you bind an object in JNDI, aren't you just adding extra complexity to your application? Why would I do that if I can access the object directly?
4: -> How do you mean different position? To access the same bean from two different URI's is exactly what I wanted, but that doesn't seem to be possible.
5: -> Multi-threading, bah! Nah I'm avoiding that like a big smelly pile of poo :p .