The official documentation is at: http://docs.alfresco.com
Table of Contents
- 1 Introduction
- 2 Requirements
- 3 Service Framework Model
- 4 Store Protocols and Node References
- 5 Service Registry (Public)
- 6 Policy Component (Internal)
- 7 Spring Support
The Services Framework provides a pattern for encapsulating Repository behaviour at the Service, Aspect and Type level.
Support the following Repository developer roles:
- Service Implementor - responsible for developing new Repository services (and optionally) exposing them as part of the Repository public API
- Content Modeler - responsible for defining the structure and behaviour of Content Types
- Application Developer - responsible for developing content applications (user of the Repository API and Content Types)
Service Implementors are Java developers. The Services Framework provides them a pattern for defining, implementing and exposing the Repository API (i.e. Repository Services). The pattern promotes an extensible and pluggable Repository architecture.
- Definition and registration of public API interfaces
- Registration of public API implementations
- Service vs. Aspect oriented components
- Definition and registration of component policies (callbacks associated with Content Model)
- Encapsulation of Content Model behaviour in a component (e.g. policy logic implemented in java)
- Registration of internal components (supporting building blocks)
- Change existing component behaviour (override or replace)
- Implement components in Java
- Implement components in script
- Dependencies between components
- Component specific configuration (XML)
- Packaging of services (for install/uninstall)
Content Modellers are knowledgeable of the business domain. Technical knowledge varies. From least to most technical there are:
- end users - define data structures (i.e. types and properties)
- advanced administrator/users - define data structures and behaviours (i.e. types, properties and business logic)
- developers - define data structures and behaviours
The Service Framework is not responsible for maintaining Content Type meta data. Instead, the Type Mechanism component will provide meta data definition and query. Out of the box, the Repository is pre-installed with Content Type meta data for common content scenarios, such as File System & Collaboration.
The Service Framework interacts closely with Content Type meta data to bring Types to life! That is, it provides a mechanism for tying behaviour to Types. To support this, the framework provides:
- Definition and registration of policies i.e. points for introducing type level behaviour (as defined by a service implementor). Policies are associated with the meta-model e.g.
- Class Policy (Type and Aspect)
- Property Policy
- Relationship Policy
- Class Policy (Type and Aspect)
- Registration of behaviour (business logic) for Type, Property and Relationship policies
- Developed in script (declarative registration)
- Developed in Java (programmatic registration)
- Developed in script (declarative registration)
- Polymorphic invocation of behaviour based on Content Type
- Override behaviour
- Access to super.behaviour (Could?)
- Override behaviour
- Access to Policy meta-data for tool support
Application developers are technically oriented. However, the Repository should provide access for all types of application developers - enterprise, LAMP and .NET.
The Service framework allows:
- The discovery of and access to Repository public services (APIs)
- Consumption of Repository Services by a number of languages
- Java (primary)
- Scripting Language
- Java (primary)
- Availability of Repository Services in
- Application Server
- Web Container
- Stand-alone Application
Service Framework Model
The public Repository API is a collection of service oriented interfaces. Each service is named and has an associated Java interface. Each Repository exposes a Service registry allowing a client to examine the list of available services. A core set of well-known services are packaged by default. New services may be deployed extending the capabilities of the Repository. Clients access a service by name.
Note: A service oriented API (as opposed to a fully object-oriented API) provides a relatively simple interface to Repository services (similar to WebDAV). It lends itself towards a stateless approach, and as such, each method on an interface requires all state to be passed in e.g. any objects to operate on.
Service interfaces are backed by an implementation component. Typically, this is a Java class, but could also be script. The Service registry identifies the implementation component for each service. This indirection allows the implementation of any service to be switched without client knowledge.
A component may also be implemented as an internal Repository building block. In this case, it is not registered with any public Service, but can be still be referred to internally.
Components depend on other components; dependencies are resolved via dependency injection.
There are two different type of Component: ServiceComponent and ClassComponent. Either can be exposed a public Repository Service.
A Class based Component is one which is tied to a specific class in the meta model. The class may be a Type or Mixin, although it's much more useful for Mixin. The exposed component API provides class specific behaviour e.g. Folder, Version or Lock. When tying a Component to a Mixin, it's possible to provide automatic introduction of the Mixin to any Nodes that are operated on by the Component. This is controlled by the ClassBinding value in the above diagram:
- Check - if the Node does not support the Mixin, report an error
- Apply - if the Node does not support the Mixin, introduce it to the Node before invoking the Service implementation
- Defer - let the implementation component decide on the outcome
Note: The apply behaviour can only be supported by a Repository whose implementation supports the introduction of a Mixin to a node at run-time.
Component implementations may defer to Content Types to allow for model specific behaviour to be injected into their process. The component implementor is responsible for the contract which describes how to inject and when to inject. This contract is known as a 'policy'. For example, the Node component may define policies such as onCreateNode, beforeDeleteNode, onUpdateProperties, etc. The CheckOutCheckIn component may define policies such as onCheckOut, onCheckIn, onCancelCheckOut, etc.
Each policy is named extends one of the following interfaces: ClassPolicy, AssociationPolicy or PropertyPolicy. The contract is defined via the 'Policy' Java Interface.
The registration of policies is performed during Component initialisation. An internal Repository component (PolicyComponent) provides the interface for registration.
Note: It is unlikely that there will be a persistent representation of policies. A Repository can be queried for a list of registered policies, but that list will depend on the initialised components/services. Content Type meta data (including behaviour) will be persisted and may be transferred from one Repository to another. It's possible for a Content Type to support a behaviour for a policy which is not registered (because it does not support the service which defines the policy). In this case, the Repository will ignore the behaviour.
Model behaviours are snippets of logic which provide Content Type specific behaviour for a given policy. The logic may be encapsulated within a Java class (which supports the policy defined Java interface) or script. Service implementors are likely to provide Java implementations, whilst Content Modellers are likely to provide Script implementations.
In the scripting case, the script must provide the appropriate function(s) to fulfill the Java interface contract. JSR 223 (and BSF) provide mechanisms to present a Java interface facade on top of a script. Note: It is not clear if the Content Modeller will need to provide the complete function definition in the script, or whether the Repository can generate a function wrapper around their hand-coded logic.
Behaviours may have dependencies on Repository Services. Java developers can use standard Dependency Injection techniques. Script developers can be provided with well known global variables; one for each published Repository Service.
Registration of behaviours is performed through an internal Repository component (PolicyRuntimeService). This can be achieved programmatically or driven by Content Type meta data developed by hand or generated by an administration tool. The PolicyRuntimeService is also responsible for dynamically dispatching to the appropriate behaviour based on Content Class (Type and Aspect) and in the future, possibly other context values.
Internal Class Components
Not every component is exposed as a public service, and this is true for a Class based component too. An internal class component allows for default type specific behaviours to be encapsulated and registered with the Repository (during the class component initialisation). Typically, a Java implementation is chosen, allowing for sophisticated behaviours (which rely on obscure Java APIs or internal Repository components). Each behaviour could be implemented as an inner class.
This technique is particularly useful for Aspects which do not expose a specific public Repository API, but do encapsulate behaviour. For example, Dublin Core or Auditable. Each of these Aspects have a corresponding Mixin which define a set of attributes. The internal Class component can register behaviours for policies such as onChanged etc which automatically assign values to lastUpdatedDate or changedBy attributes as defined by the Mixin.
Default behaviours defined by Class components can still be replaced by scripted versions as defined by less technical Content Modellers.
By taking a Service oriented approach to our API, it is relatively easy to provide remote access to the Repository. In some cases, services may be remotable without change, but others may have to expose a simple facade to improve latency or serialization issues.
Exporting a Web Service layer allows for the Repository to be used in a much wider set of scenarios such as LAMP integration or business process integration.
Content Meta Data
The Content Type meta data schema has yet to be defined, but the assumption is that something similar to Paul's XML definition will exist.
There is a loose dependency on the Content meta-meta model. An assumption is that concepts such as Type def, Property def and Relationship def exist. The existence of such concepts will drive the Policy types available in the framework.
Store Protocols and Node References
Service Registry (Public)
The Service Registry provides a means for defining and discovering Repository services. Effectively, it's the equivalent of UDDI in the Web Services world.
* Get Services provided by Repository
* @return list of provided Services
* Is Service Provided?
* @param serviceName name of service to test provision of
* @return true => provided, false => not provided
boolean isServiceProvided(string serviceName);
* Get Service Meta Data
* @param serviceName name of service to retrieve meta data for
* @return the service meta data
ServiceDescriptor getServiceDescriptor( string serviceName );
* Get Service Interface
* @param serviceName name of service to retrieve
* @return the service interface
Object getService(string serviceName);
// Core Service Locators (typed)
// Note: May return null if service is not provided
string Service Name
class Service Interface Class
store Supported Store Protocols??
Access to ServiceRegistry
- Spring Application Context...
ServiceRegistry registry = applicationContext.get('ServiceRegistry');
ServiceRegistry registry = new DefaultServiceRegistry(BeanFactory serviceFactory);
Policy Component (Internal)
The Service Framework can utilise Spring as follows:
- Define components as Beans
- Wire up dependencies between components
- XML definition of component properties
- Java or script implementation
- Swappable Implementations
- Wire up dependencies between components
- Attach Transactional behaviour to components
- Attach Access Control to Service Interfaces
- Provide a Service Registry on top of a selected number of Beans
- Export Services via remote protocols (including SOAP)
- Use Aspects for concepts such as ClassBinding (e.g. introduce mixin automatically on service call)
Initially, the definition of Repository components/services etc will be expressed using Spring syntax. This will effectively expose Spring to the Service Implementor role. However, with the introduction of Spring 1.2? (XML schema support) it will be possible to define a Content Repository specific XML schema for the definition of components and services. At this point, it won't be necessary to expose the Spring dependency to our development community.
An example generic service (i.e. not tied to a specific class definition)...
Interface: org.alfresco.repository.NodeService (java)
Implementation: DefaultNodeService (name of component implementing the interface)
Example interface (see Node Service API Design for detail)...
id createNode(workspace, parent, name, type, ...)
void setProperties(workspace, node, properties, ...)
Implementation: org.alfresco....NodeServiceImpl (java)
Dependencies: PolicyDefinition, PolicyRuntime
An example aspect based service...
Interface: org.alfresco.repository.Lock (java)
Implementation: DefaultLockAspect (name of component implementing the interface)
ClassBinding: Lock Aspect Definition + auto apply aspect
Example interface (see Lock Aspect for detail)...
lock(workspace, node, owner, ...)
release(workspace, node, ...)
Implementation: org.alfresco....LockAspectImpl (java)
Some example Policies exposed via the Node Service implementation...
Example CreatePolicy interface...
void onCreate(workspace, node, ...)
Example BeforePropertySetPolicy interface...
void beforePropertySet(workspace, node, property, newvalue, ...)
Example registration of policies (by NodeService implementation)...
// policyDefinitionComponent set via Dependency Injection
Behaviour (File beforePropertyChanged of Name)
Example declarative registration of (scripted) behaviour (note: the exact form of registering Content Type meta data has yet to be defined)...
throw new Exception('File name ' + newValue + ' is invalid - it cannot contain a full stop');
The above declaration expands to the following registration...
policyRuntimeComponent.registerPropertyBehaviour(type.File, property.name, new ScriptedBehaviour(...));
Example invocation of behaviour from service implementation...
node | type, property);
behaviour.beforePropertySet(workspace, node, property, value);
Note: We could possibly make use of Java 1.5 generics to support the above registration and retrieval of Policy specific interfaces.
Internal Class Component (Auditable)
Example of an Aspect based component which itself does not expose a public interface, but does provide default behaviour for the aspect...
Implementation: org.alfresco.repository...DefaultAuditableImpl (java)
ClassBinding: Auditable Aspect definition
Example implementation (in java, but could equally be defined in script too)...
public class DefaultAuditableImpl
// provide setters for dependency injection
public void setSessionManager(SessionManager sessionMgr) ...
public void setNodeService(NodeService nodeService) ...
public class AuditableCreatePolicy implements CreatePolicy
public void onCreate(...)
nodeService.setProperty(workspace, node, 'createdDate', now);
nodeService.setProperty(workspace, node, 'createdBy', sessionMgr.getOwner());
public class AuditableSetPropertyPolicy implements SetPropertyPolicy
public void onSetProperty(...)
if (property.name != 'updatedDate')
nodeService.setProperty(workspace, node, 'updatedDate', now);
public class AuditableIntroducePolicy implements IntroducePolicy
nodeService.setProperty(workspace, node, 'auditStartDate', now);
public void init()
policyRuntimeComponent.registerClassBehaviour(type.Auditable, new AuditableIntroducePolicy());
policyRuntimeComponent.registerClassBehaviour(type.Auditable, new AuditableCreatePolicy());