XOOPS 2.6.0 Service Manager

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
- 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.
- 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.

Transcript

1. XOOPS 2.6.0 XOOPS 2.6.0 Education Series Education Series XOOPS 2.6.0 XOOPS 2.6.0 Education Series Education Series Introduction to Introduction to Service Manager Service Manager In XOOPS CMS Environment In XOOPS CMS Environment Richard Griffith XOOPS Core Team Leader May 2014 © 2014 XOOPS Foundation www.xoops.org
2. © 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
3. © 2014 XOOPS Foundation www.xoops.org 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.
4. © 2014 XOOPS Foundation www.xoops.org 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
5. © 2014 XOOPS Foundation www.xoops.org 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
6. © 2014 XOOPS Foundation www.xoops.org 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
7. © 2014 XOOPS Foundation www.xoops.org 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.
8. © 2014 XOOPS Foundation www.xoops.org 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
9. © 2014 XOOPS Foundation www.xoops.org Service Manager Components namespace Xoops\Core\Service; 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 Xoops\Core\Service\Contract; This namespace holds interfaces that define all named services. For example, a contract for an 'Avatar' service would be Xoops\Core\Service\Contract\AvatarInterface
10. © 2014 XOOPS Foundation www.xoops.org 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.
11. © 2014 XOOPS Foundation www.xoops.org 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, '\Xoops\Core\Service\Provider')) { $path = dirname(dirname(__FILE__)) . '/class/AvatarsProvider.php'; require $path; $object = new AvatarsProvider(); $provider->register($object); } }
12. © 2014 XOOPS Foundation www.xoops.org Service Provider Implementation Avatar example: use Xoops\Core\Service\AbstractContract; use Xoops\Core\Service\Contract\AvatarInterface; class AvatarsProvider extends AbstractContract implements AvatarInterface { // implementation goes here }
13. © 2014 XOOPS Foundation www.xoops.org Service Contract Example namespace Xoops\Core\Service\Contract; interface AvatarInterface { const MODE = \Xoops\Core\Service\Manager::MODE_EXCLUSIVE; /** * @param Response $response \Xoops\Core\Service\Response object * @param mixed $userinfo XoopsUser object * * @return void - response->value absolute URL to avatar image */ public function getAvatarUrl($response, $userinfo); /** * @param Response $response \Xoops\Core\Service\Response object * @param mixed $userinfo XoopsUser object * * @return void - response->value absolute URL to edit function */ public function getAvatarEditUrl($response, $userinfo); }
14. © 2014 XOOPS Foundation www.xoops.org 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();
15. © 2014 XOOPS Foundation www.xoops.org 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
16. © 2014 XOOPS Foundation www.xoops.org Contract Methods and Response Objects The service manager handles all response objects and calls to 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);
17. © 2014 XOOPS Foundation www.xoops.org 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.
18. © 2014 XOOPS Foundation www.xoops.org 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
19. © 2014 XOOPS Foundation www.xoops.org 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. 20 © 2014 XOOPS Foundation www.xoops.org 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