Tapestry applications will need to define new engine services when a page must be referenced from outside the Tapestry application

This is best explained by example. It is reasonable in an e-commerce system that there is a particular page that shows product information for a particular product. This information includes description, price, availability, user reviews, etc. A user may want to bookmark that page and return to it on a later session.

Tapestry doesn't normally allow this; the page may be bookmarked, but when the bookmark is triggered, the page may not render correctly, because it will not know which product to display. The URLs normally generated in a Tapestry application are very context sensitive; they are only meaningful in terms of the user's navigation throughout the application, starting with the Home page. When bookmarked, that context is lost.

By defining a new engine service, the necessary context can be encoded directly into the URL, in a way similar to how the direct action works. This is partially a step backwards towards typical servlet or JSP development, but even here Tapestry offers superior services. In the e-commerce example, the service URL could encode some form of product identifier.

An example of this is in the Virtual Library application. In order to make certain pages bookmarkable, a new service named "external" was created.

The external service includes the name of a page and the primary key of an object that page displays (this was simplified by the design of the Vlib entity beans, which always use an Integer as the primary key).

The external service works much the same was as the page service, except that it invokes an additional method on the page, setup(), which is passed the primary key extracted from the URL.

The end result is that when a user arrives at such a page, the URL used identifies the page and the primary key. Bookmarking the page stores the URL so that when the bookmark is later opened, the correct data is read and displayed.