XOOPS 2.6.0 Service Manager

XOOPS 2.6.0XOOPS 2.6.0
Education SeriesEducation Series
XOOPS 2.6.0XOOPS 2.6.0
Education SeriesEducation Series
Introduction toIntroduction to
Service ManagerService Manager
In XOOPS CMS EnvironmentIn XOOPS CMS Environment
Richard Griffith
XOOPS Core Team Leader
May 2014© 2014 XOOPS Foundation www.xoops.org

© 2014 XOOPS Foundation www.xoops.org
Service Management
In XOOPS 2.6.0 alpha 2, some familiar services
that were traditionally internal parts of the core
were separated into modules.
Some examples are:
avatars, comments, and notifications

Separated Module Benefits
The separated module approach achieves
some important benefits:
●
Modules can be updated independently.
●
Modules can have private resources, such as
templates, configurations, maintenance pages.
●
Modules can be omitted if not needed, saving
some resources.

Problems with Separation
There are potential benefits to separation that
were not realized:
●
The service modules were not easily replaced
with alternate implementations
●
References using hard coded module names
litter the entire system wherever a service is
needed

Direct Module Connection
●
Each time the service
is used, the calling
code must check to
see if module is
installed
●
Usage generally
requires intimate
knowledge of the
service internals

Service Manager
To achieve the full benefit of the separation,
XOOPS 2.6.0 alpha 3 introduces a Service
Manager component.
●
Services located by service name, not provider
●
Service interface established by Contract
●
Returns a standardized Response object that
includes result, status and messages

Service Manager Connection
●
Request is based on a well
known interface
●
Actual provider does not matter
to caller
●
No need to check for a specific
module
●
If the service is not available,
that status is returned just like
any other error condition.

if ($xoops->isActiveModule('notifications')) {
$notification_handler = Notifications::getInstance()->getHandlerNotification();
$notification_handler->triggerEvent('global', 0, 'category_created', $tags);
}
Code Simplification
$xoops->service('Notify')->triggerEvent('global', 0, 'category_created', $tags);
Direct Module Connection
Service Manager Connection

Service Manager Components
namespace XoopsCoreService;
AbstractContract.php Abstract Class Contract boilerplate
Manager.php Class Manages service providers
NullProvider.php Class Provider used when no provider is installed
Provider.php Class Basic Provider support
Response.php Class Response used by all service providers
namespace XoopsCoreServiceContract;
This namespace holds interfaces that define all named
services. For example, a contract for an 'Avatar' service
would be XoopsCoreServiceContractAvatarInterface

Service Provider
Any module can implement a service provider.
To provide a service, the module must respond to
a core.service.locate.name event. This is
usually accomplished using a PreloadItem.
The locate event will supply a Provider object,
and the module listener is expected to invoke the
register() method of that object with an instance of
its own provider implementation.

Registering a Service Provider
Avatar preload example:
/**
* listen for core.service.locate.avatar event
*
* @param Provider $provider - provider object for requested service
*
* @return void
*/
public static function eventCoreServiceLocateAvatar(Provider $provider)
{
if (is_a($provider, 'XoopsCoreServiceProvider')) {
$path = dirname(dirname(__FILE__)) . '/class/AvatarsProvider.php';
require $path;
$object = new AvatarsProvider();
$provider->register($object);
}
}

Service Provider Implementation
Avatar example:
use XoopsCoreServiceAbstractContract;
use XoopsCoreServiceContractAvatarInterface;
class AvatarsProvider extends AbstractContract implements AvatarInterface
{
// implementation goes here
}

Service Contract Example
namespace XoopsCoreServiceContract;
interface AvatarInterface
{
const MODE = XoopsCoreServiceManager::MODE_EXCLUSIVE;
/**
* @param Response $response XoopsCoreServiceResponse object
* @param mixed $userinfo XoopsUser object
*
* @return void - response->value absolute URL to avatar image
*/
public function getAvatarUrl($response, $userinfo);
/**
* @param Response $response XoopsCoreServiceResponse object
* @param mixed $userinfo XoopsUser object
*
* @return void - response->value absolute URL to edit function
*/
public function getAvatarEditUrl($response, $userinfo);
}

Using a Service
// get Xoops object
$xoops = Xoops::getInstance();
// get provider
$provider = $xoops->service('Avatar');
// call contract method
$response = $provider->getAvatarUrl($user);
// get value from response
$avatar = $response->getValue();
// all together
$avatar = $xoops->service('Avatar')->getAvatarUrl($user)->getValue();

Response Object
●
Response objects are managed automatically, so you should never need to
instantiate one.
●
Useful methods when consuming a service
– isSuccess() - true if service call was a success
– getValue() - get the value set by the call, can be any PHP type (scalar, array,
object, etc.) If no provider is available, getValue() will return NULL.
– getErrorMessage – get array of messages
●
A Response object is the first argument to all Contract methods, but never
included in the service() call
– A program calls the service manager
– The service manager:
• creates a response object
• calls the contract method
• returns the response object to the caller

Contract Methods and
Response Objects
The service manager handles all response
objects and calls the contract providers. To isolate
the responsibilities for the response object, it is
passed to the contract methods. As a result, the
call to the service manager and the call to the
contract implementation are different:
Service call:
$response = $xoops->service("Avatar")->getAvatarUrl($userinfo);
Contract definition:
public function getAvatarUrl($response, $userinfo);

Lazy Service Location
Service providers are only instantiated when explicitly
requested, and then kept for the duration of the PHP run.
A locate event is not triggered until a named service is
first requested, so if a service is not used, it has no
overhead cost.
If no providers for a service are installed, the locate
trigger has little cost, and any subsequent calls go
straight to a NullProvider that minimizes resource use.

Service Manager Administration
– For simple cases, just install the provider module / extension and
it will just work.
– For more complex cases use the services section in the
administration area

Future of Service Manager
●
User side interface to choose a specific provider for MODE_PREFERENCE, for
example:
– Editors
●
Implement MODE_MULTIPLE support, calling multiple providers in sequence. Some
possible uses are:
– Security inspections
– Spam prevention lookups
●
Complete conversions and separate additional services
– Presently only Avatar provider is implemented
– Comments and Notifications to follow
– Other possibilities
●
Mailer
●
Editors
●
Captcha
●
Image library
●
Important part of “everything is a module” strategy

20
If you have any suggestions,
comments or questions, please make
them known.
You can contact the author here :
richard@geekwright.com
IDEAS ? QUESTIONS ?
www.xoops.org

XOOPS 2.6.0 Service Manager

More Related Content

What's hot

Similar to XOOPS 2.6.0 Service Manager

Recently uploaded

XOOPS 2.6.0 Service Manager