Deconstructing the Data Services

So far we have seen a number of calls to the data services provided by the forum-services module. We shall now briefly explore their implementation.

If you examine the module.xml definition for the forum-services module you'll see that it has a public interface which promises to service all requests in the ffcpl:/forum-.* URI space...

Inside the mapping section we see there is a rewrite rule in which all ffcpl:/forum-.* requests result in the execution of the mapper with the service to be resolved using the ffcpl:/links.xml links declarations...

This is an example of module interface delegation. There are actually a large number of services that this module exposes on its public interface - but it would be very tedious and unduly complex to expose each one explicitly on the public interface in the module definition. Instead, the complete space of services is promised and the mapper is made responsible for mapping the requested service to its implementation. This is another example of the mapper pattern.

Lets look at the first service we used when we deconstructed the topic channel. It requests the metadata for a topic by calling the service ffcpl:/forum-main-getTopicMeta. We can see that this URI matches the public interface of the services module and so is routed from the forum-web module into the forum-services module. There it is delegated to the mapper and so if we look in the links.xml file we find a link for the implementation of the service...

This executes a DPML script which performs the SQL query against the RDBMS to retrieve the metadata for the topic. We will not examine in detail the scripted implementation of the data services since they are all uniformly similar in that they just perform a simple sequence of accessor to perform queries of the database.

The only other interesting feature of the services module is that it provides its own management web-application - located in the /forum/admin/ directory. This interface is exposed via entrypoint.xml metadata and appears as a plugin application panel in the backend tools. It uses the same XRL mapper and XRL template recursion to implement the application. This partitioning is noteworthy in that all of the forum application's admin services are exposed only through the backend transport. It is highly desirable not to mix sensitive admin applications with the public application interface presented by the forum-web module.