abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Server Refactoring - Overview
Date Tue, 22 Jan 2008 06:40:59 GMT
Ok, the server refactoring is coming along very well I think.  Thus far, 
I've been able to greatly simplify the overall design, as well as 
integrate the approaches implemented by Dan and the google feed-server 
team while still maintaining the flexibility of the original framework.

The main components of the refactored design are:

  * AbderaServlet
  * ServiceContext
  * Provider
  * WorkspaceManager
  * CollectionAdapter
  * RequestContext
  * ResponseContext
  * Target
  * Resolver<Target>
  * Resolver<Subject>

For the overwhelming majority of implementations, all an end developer 
will need to do is implement a CollectionAdapter, provide a 
TargetResolver, and glue the two together using a ServiceContext.

The examples in the server_refactor test cases illustrates the three 
fundamental approaches.

The application flow is simple:

  * The AbderaServlet receives a request and creates a ServiceContext
  * The ServiceContext creates a Provider instance
  * The Provider instance uses it's associated WorkspaceManager to
    select a CollectionAdapter.
  * Once the CollectionAdapter is selected, the Provider forwards the
    request on to the appropriate method

In some cases, the Provider and the WorkspaceManager will be the same 
object.  In other cases, the Provider and the WorkspaceManager will be 
separate.

Simple
------

In the Simple example, the developer implements a CollectionAdapter, a 
Provider and a ServiceContext.

The CollectionAdapter provides the guts of the implementation, providing 
implementations for each of the main prototocol operations such as 
getFeed, getEntry, etc.  These are the methods that used to exist on the 
old style provider interface.

The Provider extends AbstractWorkspaceProvider which means the Provider 
is acting as it's own WorkspaceManager.

The Provider/WorkspaceManager dispatches requests to the SimpleAdapter 
implementation.

The SimpleServiceContext glues the Provider to the appropriate target 
resolver.

Default
-------

In the Default example, the developer uses the same CollectionAdapter 
implementation used in the simple example but uses the DefaultProvider 
class.

The Default example is similar in nature to the CollectionProvider stuff 
implemented by Dan in that it is the DefaultProvider's job to handle 
things like the creation of the Service document based on metadata 
provided by the developer.

The simple and default examples are nearly identical with the exception 
that the default example supports multiple workspaces and collections.

Basic
-----

The basic example (which is poorly named, I know) is essentially the 
google feed-server stuff, slightly modified so that it sits on top of 
the default provider implementation.

The properties file based deployment is kept intact, but the Adapter 
interface is replaced by the BasicAdapter abstract class, which is an 
abstract CollectionAdapter implementation that defines the same abstract 
methods defined by the google feed-server Adapter interface.  Existing 
google feed-server Adapter implementations can be ported to this design 
simply by replacing "implements Adapter" with "extends BasicAdapter".

The implementation has been further modified to support the creation of 
a service document.  The code will read all of the *.properties files 
for the adapters and will generate a service document with one workspace 
and one collection per configured adapter.

Service Documents
-----------------

In this design, the Provider is responsible for serving the service 
documents.  This means that the service document support will vary 
depending on the capabilities of the Provider implementation.

CollectionAdapters
------------------

In each of the three approaches, the same CollectionAdapter interface is 
used.  Also, with the possible exception of URI patterns used for links, 
CollectionAdapters should be independent of the Provider implementation 
used.  We need to find a more elegant way of tying Target Resolvers and 
Collection Adapters together while at the same time making it easier to 
manage links, but that can come later.  The more important thing is that 
once a CollectionAdapter is implementation, we should be able to use it 
regardless of which of the three models are selected.

Media Collections
-----------------

The basic CollectionAdapter interface does not support media operations. 
  If you want to implement support for media collections, the 
CollectionAdapter has to implement the MediaCollectionAdapter interface. 
  The reason for this separation is to reduce the complexity of the 
simplest Atompub implementations that will only ever support Atom entries.

Transactional
-------------

CollectionAdapter implementations can implement the Transactional 
interface if they wish to support transactional start/end/compensate 
semantics.  Provider implementations SHOULD call Transactional.start() 
before delegating to the CollectionAdapter method and 
Transactional.end() after delegating.  If an error occurs, the Provider 
SHOULD call Transactional.compensate().

- James

Mime
View raw message