Page History
...
The objectives of this tutorial are to provide the general DSpace Developer with an understanding of what the DSpace Service Manager is and what we are attempting to attain through its usage and some basic software development practices and design principles. The tutorial will break these practices and the overall development platform down into developer centric terms that should, if successful, give the developer a reference for how to best design their code.
DSpace Service Manager
Goals Goals of the Service Manager are to assist in separating the dependencies of individual functional areas of DSpace on one another, by eliminating significant dependencies on on other parts of the codebase and the prevalence of "StaticManager" Classes.
The DSpace Services Framework is a backporting 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.
...
In DSpace Services are conceptually similar to OSGi Services. An 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.
represents a "best practice" for new DSpace architecture and implementation of extensions to the DSpace application. DSpace Services are best described as a "Simple Registry" where plugins FIXME. The DS2 (DSpace 2.0) core services are the main services that make up a DS2 system. These includes services for 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).
The Service Manager
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 Service Manager Interface is defined as follows:
Get Service By Type:
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.
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
- Kernel Initialization
- Service Manager Startup
- Service Registration
- Service Manager Shutdown
- Service Manager Startup
The life cycle of a servlet is controlled by the container in which the servlet has been deployed. When a request is mapped to a servlet, the container performs the following steps.
- If an instance of the servlet does not exist, the Web container
- Loads the servlet class.
- Creates an instance of the servlet class.
- Initializes the servlet instance by calling the init method. Initialization is covered in Initializing a Servlet.
- Invokes the service method, passing a request and response object. Service methods are discussed in the section Writing Service Methods.
If the container needs to remove the servlet, it finalizes the servlet by calling the servlet's destroy method. Finalization is discussed in Finalizing a Servlet.
The Service Manager Interface is defined as follows:
Get Service By Type
Allows developers to get the desired service singleton by the provided type. This should return all instantiated objects of the type specified (may not all be singletons). Accepts a type for the requested service (this will typically be the interface class but can be Allows developers to get the desired service singleton by the provided type. This should return all instantiated objects of the type specified (may not all be singletons). Accepts a type for the requested service (this will typically be the interface class but can be concrete as well) The return the list of service singletons OR empty list if none is found.
| Code Block |
|---|
public <T> List<T> getServicesByType(Class<T> type); |
Get Service By Name
...
Allows developers to get the desired service singleton by the provided name and type.
...
| Code Block |
|---|
public <T> T getServiceByName(String name, Class<T> type); |
Check If Service Exists
Will verify if a service of a specific name exists int he configuration.
| Code Block |
|---|
public boolean isServiceExists(String name); |
Get Service Names:
Get the names of all registered service singletons. By convention, the name typically matches the fully qualified class name.
...
The XMLUI OVERLAY
AspectS
Consectetuer arcu ipsum ornare pellentesque vehicula, in vehicula diam, ornare magna erat felis wisi a risus. Justo fermentum id.
THEME RESOURCES
Developing with DSpace
Architectural Introduction
Maven Archetype
Project Generation
Maven Module Wiring
Dependencies
Tiers
Persisitence
Business
Application
Tools
Maven
Jar Projects
Dependencies
Inheritance
modularity
War Projects
overlays
modularity
Spring
ServiceManager
Core Services
ConfigurationService
Configuration via Spring vs. ConfigurationService
DatabaseService
Opening Doors to Persistence Frameworks
DAO Repositories
Defining, Replacing and Augmenting Storage
Whats a Service?
Defining and Replacing Business Services
Creating Your Own Services
Webapplications
XMLUI / Cocoon
JSPUI (WebMVC)
Example
Facebook Authentication for DSpace
Spring Security
OAuth 2.0 for Spring Security
Facebook Authentication
Implementation
Spring Security Authenticator
Authentication Service
Architectural Overview
DSpace Kernel
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.
Kernel registration
The kernel will automatically register itself as an MBean when it starts up so that it can be managed via JMX. It allows startup and shutdown and provides direct access to the ServiceManager and the ConfigurationService. All the other core services can be retrieved from the ServiceManager by their APIs. 
Service Manager
...
Storage
Whats a Service?
Defining and Replacing Business Services
Creating Your Own Services
Webapplications
XMLUI / Cocoon
JSPUI (WebMVC)
Example
Facebook Authentication for DSpace
Spring Security
OAuth 2.0 for Spring Security
Facebook Authentication
Implementation
Spring Security Authenticator
Authentication Service
Architectural Overview
DSpace Kernel
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.
Kernel registration
The kernel will automatically register itself as an MBean when it starts up so that it can be managed via JMX. It allows startup and shutdown and provides direct access to the ServiceManager and the ConfigurationService. All the other core services can be retrieved from the ServiceManager by their APIs.
Service Manager
The DS2 kernel is compact so it can be completely started up in a unit test (technically integration test) environment. (This is how we test the kernel and core services currently). This allows developers to execute code against a fully functional kernel while developing and then deploy their code with high confidence.
...
Overview
Content Tools