I am writing a client library for a web service using CXF. The service uses a mutable key to manage sessions and, optionally, allows a session to be kept alive.
I have built a client Client
and I want to provide the ability for uses of the library to choose their type of session management i.e. either a manager which just manages keys but does not attempt to keep alive and a manager which manages keys and k开发者_如何转开发eeps the session alive.
I had thought of having a SessionManager
field in the Client
class (with a SimpleSessionManager
class and a KeepAliveSessionManager
class) but, in order to keep the session alive, the KeepAliveSessionManger
would have to call a method of the Client
class. That would mean that the Client
class has a reference to the SessionManager
class and the SessionManager
class would have a reference to the Client
class - which is obviously an inelegant design.
Can you suggest a design pattern (or altnernate implementation) that would let me implement these features in a 'better' way?
Cheers,
Pete
You could use the SessionManager as a factory for "clients" that would return an interface for the client. The client wouldn't need to "know" the SessionManager. And if the SessionMaAnager was a KeepAliveSessionMaanger, it would internally keep the session alive.
Something like this:
SessionManager sm = new KeepAliveSessionManager(int keepAliveTimeout);
IClient client = sm.GetClient();
client.InvokeSomeMethod();
The SessionManager internally uses a thread (or something) and the client to keep the session alive. The client never "knows" about the SessionManager..
BTW, i'm thinking in .NET but it should translate to java...
精彩评论