Tapestry has evolved its own jargon over time.
The Engine is a central object, it occupies the same semantic space in Tapestry that the HttpSession does in the Servlet API. The Engine is ultimately responsible for storing the persistant state of the application (properties that exist from one request to the next), and this is accomplished by storing the Engine into the HttpSession. This document will largely discuss the default implementation, with notes about how the default implementation may be extended or overriden, where appropriate.
Engine services are the bridge between servlets and URLs and the rest of Tapestry. Engine services are responsible for encoding URLs, providing query parameters that identify, to the framework, the exact operation that should occur when the generated URL is triggered (by the end user clicking a link or submitting a form). Services are also responsible for dispatching those incoming requests. This encapsulation of URL encoding and decoding inside a single class is key to how Tapestry components can flexibily operate without concern for how they are contained and on which page ... the services take into account page and location when formulating URLs.
The Visit is not a particular object, it is an application-defined object that acts as a focal point for all server-side state (not associated with any single page). Individual applications define for themselves the class of the Visit object. The Visit is stored as a property of the Engine, and so is ultimately stored persistantly in the HttpSession