Page History
...
The DSpace Services Framework is a back-porting of the DSpace 2.0 Development Group's work in creating a reasonable and simple "Core Services" layer for DSpace. The Services Framework provides a means for application developers to both lookup and register their own "services" or JAVA objects that can be referred to by the application.
What are services?
Answer: services are a generic term for the business actions that provide functionality that will complete a specific task in the application.
In DSpace Services are conceptually similar to OSGi Services , where an addon library (a OSGi Bundle) delivers a singleton instance of a class as a service for other application code to utilize. In OSGi the Service often has a Java Interface class and constitutes a "Contract" for the application.
From a Design Standpoint, The Service Manager is a Service Locator Pattern that shifts the . This shift represents a "best practice" for new DSpace architecture and the implementation of extensions to the DSpace application. DSpace Services are best described as a "Simple Registry" where plugins FIXME. The DS2 Registry" of Services that are delivered to the application for use by the use of a Spring Application Context. The original (DSpace 2.0 ) core services are the main services that make up a DS2 DSpace Service Manager system. These includes services for things include services for the application "Configuration", "Transactional Context", "Requests" and user "Session", "Persistence" things like user and permissions management and storage and caching. These services can be used by any developer writing DS2 plugins (e.g. statistics), providers (e.g. authentication), or user interfaces (e.g. JSPUI).
...
An OSGi service is a java object instance, registered into an OSGi framework with a set of properties. Any java object can be registered as a service, but typically it implements a well-known interface. Considerable has evolved in both the Spring and OSGi Communities.
What is Spring?
The Service Manager
The ServiceManager provides a developer API of service lookups and manages the overall lifecycle control for the DSpace Application. During this Lifecycle it also manages the configuration of services by allowing properties to be pushed into the services as they start up (mostly from the ConfigurationService). The ServiceManagerSystem abstraction allows the DSpace ServiceManager to use different systems to manage its services. The current implementation is Spring Framework based. The original design intent of the Service Manager was to support more than one IoC/DI Solution and and implementation that included Google Guice was provided. This allows DSpace to have very little service management code but still be flexible and not tied to specific technology. Developers who are comfortable with these API can consume the services from a parent Spring ApplicationContext or a parent Guice Module without an awarness that they are doing so. The abstraction also means that we can replace Spring/Guice or add other dependency injection systems later without requiring developers to change their code. The interface provides simple methods for looking up services by interface type for developers who do not want to have to use or learn a dependency injection system or are using one which is not currently supported.
Spring is an Inversion of Control (IoC) container that utilizes Dependency Injection (a fancy way of just saying that Spring creates and hands the JAVA object you would use in your own code to you. As a brief example Here is a class that does not use Dependency Injection, it calls "new ArrayList" directly in its constructor.
| Code Block |
|---|
public class Example {
private SomeOtherClass myObject = null;
public Example(){
myObject = new SomeOtherClass();
}
}
|
Here is an example of a better coding practice, where we give up the responsibility for the creation of the class and allow the IoC/DI container to be responsible for its creation.
| Code Block |
|---|
public class Example {
private SomeOtherClass myObject = null;
public Example(SomeOtherClass object){
this.myObject = object;
}
} |
This immediately opens the door for "SomeOtherClass" to be changed out with new/other subclasses of "SomeOtherClass". In Spring, the injections might look like this:
| Code Block |
|---|
<?xml version="1.0" encoding="UTF-8"?>
<beans>
<bean id="someObject" class="com.example.SomeOtherClass"/>
<bean class="com.example.Example">
<constructor-arg ref="someObject"/>
</bean>
</beans> |
Where, when the ServiceManager is started, two beans are instantiated by Spring, and one is used in the constructor argument of the other.
Future Direction of Spring and OSGi
The Service Manager
The ServiceManager provides a developer API of service lookups and manages the overall lifecycle control for the DSpace Application. During this Lifecycle it also manages the configuration of services by allowing properties to be pushed into the services as they start up (mostly from the ConfigurationService).
The ServiceManagerSystem abstraction allows the DSpace ServiceManager to use different systems to manage its services. The current implementation is Spring Framework based. The original design intent of the Service Manager was to support more than one IoC/DI Solution, however, as work has progressed with DSpace, it has become clear that there are trade offs to consider in its usage.
- Spring Injection, when used properly, means we do not need to make "lookup calls" to a central "ServiceManager" or "DSpace" object to acquire the service beans we our own code to work with.
- Fewer lookups mean less centralized dependencies
- Fewer Centralized Dependencies means fewer bottlenecks in source Code Dependency Management.
- Fewer Bottlenecks means greater modularity and encapsulation, less need to carry around all the source code when overriding and customizing "dspace".
- More use of binary distributions means greater ease in upgrading DSpace.
Caveat: It is clear that Spring has become quite dominant a solution in DSpace with the adoption of Apache Cocoon 2.2 for the Manakin XMLUI and Spring MVC for the Freemarker Prototype Webapplication currently under Development. Spring is even being considered for use in the
Allows for non-specific access to the core services. No dependency on the underlying mechanism is exposed. Allows the developer to register and lookup references to desired Service Objects
The DSpace Application Lifecycle
The life cycle of the container and the services therein is controlled by the Web-application context or the DSpace CLI ScriptLauncher main executable in which the servlet has been deployed. The Lifecycle assures that when the Service managers (and specifically Spring in this case) are initialized, the required core and addon services are wired and made available to your application.
The ServiceManager Request Cycle
The ServiceManager Request Cycle is similar to the Webapplication Request Cycle. In the case of the Service Request, There is an incoming "Request" object with the state of the a call from the client, this Request is then enterpreted by the Container and mapped to a specific Servlet, which executes to completion, On Completion, the Serlvet Generates a
When a request is made by either the Webapplication or the CLI initialization, then the Request Lifecycle is engaged:
DSpace Kernel
.2 for the Manakin XMLUI and Spring MVC for the Freemarker Prototype Webapplication currently under Development in the community.
This leads us to our first best practice:
| Tip |
|---|
Best Practice 1: If possible, do use Dependency Injection to acquire your services. This will be of benefit down the road if we make changes to the service manager architecture. |
In creating classes that work within the system, the ServiceManager will inject those services you need for you.
| Code Block |
|---|
public class Example {
ConfigurationService configurationService;
RequestService requestService;
public Example(ConfigurationService cs, RequestService rs)
{
this.configurationService = cs;
this.requestService = rs;
}
} |
Where in our spring configuration we would register this Service via the following configuration:
| Code Block |
|---|
<bean class="org.dspace.MyService" autowire="byType"/>
|
Spring AutoWiring looks for other bean of our specific type elsewhere in our configuration and injects them into our service. This is the basic mechanism whereby Addon Modules can reuse existing services or even services provided by other third party modules without having to explicitly depend on any specific implementation of those services.
The DSpace Application Lifecycle
The life cycle of the container and the services therein is controlled by the Web-application context or the DSpace CLI ScriptLauncher main executable in which the servlet has been deployed. The Lifecycle assures that when the Service managers (and specifically Spring in this case) are initialized, the required core and addon services are wired and made available to your application.
The ServiceManager Request Cycle
The ServiceManager Request Cycle is similar to the Webapplication Request Cycle. In the case of the Service Request, There is an incoming "Request" object with the state of the a call from the client, this Request is then enterpreted by the Container and mapped to a specific Servlet, which executes to completion, On Completion, the Serlvet Generates a
When a request is made by either the Webapplication or the CLI initialization, then the Request Lifecycle is engaged:The DSpace Kernel manages the start up and access services in the DSpace Services framework. It is meant to allow for a simple way to control the core parts of DSpace and allow for flexible ways to startup the kernel. For example, the kernel can be run inside a single webapp along with a frontend piece (like JSPUI) or it can be started as part of the servlet container so that multiple webapps can use a single kernel (this increases speed and efficiency). The kernel is also designed to happily allow multiple kernels to run in a single servlet container using identifier keys.
Basic Usage
To use the Framework you must begin by instantiating and starting a DSpaceKernel. The kernel will give you references to the ServiceManager and the ConfigurationService. The ServiceManager can be used to get references to other services and to register services which are not part of the core set. For standalone applications, access to the kernel is provided via the Kernel Manager and the DSpace object which will locate the kernel object and allow it to be used.
...
Overview
Content Tools