Viewpoint is built with two major components in its overall architecture. There is the back-end, which talks via SOAP messages to the Exchange Web Services (EWS) endpoint and the front-end which provides an easier-to-use interface and is intended as the main point of user interaction. The front-end was not intended to fulfill all of the capabilities that EWS provides but give users and path with little resistance to get most tasks done. Should someone need to reach into the depths of the more obscure the back-end could be tapped to help out with those instances.
The original version used SOAP4r to auto-generate most of the code. This made it nice to get up and going but the code generated was unwieldy and made it hard to tweak. This was exacerbated by new versions of EWS and having to regenerate code over the code that had been customized.
Handsoap quickly replaced the SOAP4r code. It acted as a nice communication layer for SOAP services but it had a fatal flaw that the service code had to be a Singleton. This made multi-tasking between users hard and sometimes impossible but this code base allowed for the concept of the Builders and Parsers to form that you can read about in the Back-end section.
The current code did away with Handsoap in favor of a custom client library that currently uses HTTPClient. This allowed the code to move away from the Singleton pattern and allow multiple instances to EWS to exist simultaneously. At some point it would be nice to extract the actually HTTP library but not all of them have as good of support for NTLM authentication as HTTPClient.
The back-end code is not really intended for the end-user to use directly. Most people will interact with Viewpoint from the front-end classes. However, if someone should need to utilize EWS for an uncommon scenario he or she should be able to tap into the back-end code and do pretty much anything EWS allows.
Services are at the heart of Viewpoint. They are a thin veil between the EWS SOAP messages and the Viewpoint. In fact most Viewpoint service methods map 1-to-1 back to EWS. Where this is true there is a comment to the MSDN documentation for that method. If you read the source for the services you will see a pattern of [build - send - parse] and not much more.
Builders help compose EWS Types and wrap them appropriately for the outgoing messages (RequestMessages) in the Services. They use Nokogiri to build the nodes and for the most part are very straight forward. There are occaisions where EWS uses the same type with different namespaces in different services. For these builders there is a parameter that represents the namespace and typically has a default set to the most common usage. I will direct you to the corresponding MSDN documentation for each type that is linked to in the source code.
Parsers not surprisingly help parse the incoming messages (ResponseMessages). This part of Viewpoint isn't as simple as the Builders and could probably use some rethinking. The responses tend to vary from message to message so it's a little harder to abstract them in the same way the builders are.
The client represents the authenticated connection to EWS. It includes modules known as accessors to fetch and interact with EWS objects. For instance one might use an accessor to fetch a Folder or Calendar, create a new e-mail or look-up a user. Once the accessor does its part most of the functionality is within each model.
The models are simply the various EWS types. This could be a folder, a task, an individual message or any number of other items. At the center of each model is the Types module. It does the dirty work of keeping state and accessing the various data structures for each model.
Templates are used in the creation of new EWS objects like an e-mail or calendar item. They fill in the necessary data structures and add a level of abstraction to ease in item creation.