How should one model an ExchangeService object (in ews-java-api) for sharing MS Exchange connections?

Question

I am creating an application which uses ews-java-api to connect to an MS Exchange server. Once the connection is authenticated, the api dictates use of ExchangeService object for searching mailboxes, fetching mails and then reading its contents.

The emails are read by different classes down the line for analysis and actions depending upon email content. All these classes must need one pre-authenticated instance of ExchangeService object.

The instance of the object is obtained as -

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010_SP2);
ExchangeCredentials credentials = new WebCredentials("emailAddress", "password");
service.setCredentials(credentials);

In future there may be requirements to add more classes down the line as needed for more functionalities. All of them would be using the same instance of ExchangeService object.

My question is how should I design the sharing of ExchangeService instance among all these classes down the line? Keeping in mind that no one should inadvertently call the "close()" method on that instance, until whole of the application finishes.

On first look it might appear as a Database connection pool design sort of stuff, but its not. This application runs periodically every 5 minutes and connects to the Exchange server, does its job of analyzing unread mails (with all behavioral classes) and then ideally should close the connection.

One thought of singleton pattern also crossed my mind, but the issue of calling the "close()" method still remains.

Any design suggestion to simplify the system?

Thanks in Advance!

Answer 1

I would personally favor declaring an interface that you want your clients to use. Start out with just what is needed now, and expose more functionality later.

Your interface would ensure that the close() method is not available.

Your one implementation would handle the negotiation with the server and decide when/if to close the connection.

The remainder of your app gets a reference to the object either using dependency injection or your Singleton pattern. The important thing is that you are only exposing that interface.

This also gives you the option to change how you handle your connections in the future, automatically closing the connection when there is a period of inactivity, then re-establishing the connection on demand.

Answer 2

Do all the classes really need access to the entire object? Otherwise, this looks like a correctness problem (but not in a bad way), rather than a design problem. One approach is to consider a code contract enforced by a caller:

f(g, exchange-object) { 
   /* pre-condition/invariant */
   assert(exchange-object.open() == true);
   g(exchange-object);
   /* post-condition/invariant */
   assert(exchange-object.open() == true);
   }
..
f ( obj-on-the-line.g, exchange-object )
..

More info: http://c2.com/cgi/wiki?DesignByContract