XOOPS 2.6.0XOOPS 2.6.0
Education SeriesEducation Series
XOOPS 2.6.0XOOPS 2.6.0
Education SeriesEducation Series
Introducti...
© 2014 XOOPS Foundation www.xoops.org
Service Management
In XOOPS 2.6.0 alpha 2, some familiar services
that were traditio...
© 2014 XOOPS Foundation www.xoops.org
Separated Module Benefits
The separated module approach achieves
some important bene...
© 2014 XOOPS Foundation www.xoops.org
Problems with Separation
There are potential benefits to separation that
were not re...
© 2014 XOOPS Foundation www.xoops.org
Direct Module Connection
●
Each time the service
is used, the calling
code must chec...
© 2014 XOOPS Foundation www.xoops.org
Service Manager
To achieve the full benefit of the separation,
XOOPS 2.6.0 alpha 3 i...
© 2014 XOOPS Foundation www.xoops.org
Service Manager Connection
●
Request is based on a well
known interface
●
Actual pro...
© 2014 XOOPS Foundation www.xoops.org
if ($xoops->isActiveModule('notifications')) {
$notification_handler = Notifications...
© 2014 XOOPS Foundation www.xoops.org
Service Manager Components
namespace XoopsCoreService;
AbstractContract.php Abstract...
© 2014 XOOPS Foundation www.xoops.org
Service Provider
Any module can implement a service provider.
To provide a service, ...
© 2014 XOOPS Foundation www.xoops.org
Registering a Service Provider
Avatar preload example:
/**
* listen for core.service...
© 2014 XOOPS Foundation www.xoops.org
Service Provider Implementation
Avatar example:
use XoopsCoreServiceAbstractContract...
© 2014 XOOPS Foundation www.xoops.org
Service Contract Example
namespace XoopsCoreServiceContract;
interface AvatarInterfa...
© 2014 XOOPS Foundation www.xoops.org
Using a Service
// get Xoops object
$xoops = Xoops::getInstance();
// get provider
$...
© 2014 XOOPS Foundation www.xoops.org
Response Object
●
Response objects are managed automatically, so you should never ne...
© 2014 XOOPS Foundation www.xoops.org
Contract Methods and
Response Objects
The service manager handles all response
objec...
© 2014 XOOPS Foundation www.xoops.org
Lazy Service Location
Service providers are only instantiated when explicitly
reques...
© 2014 XOOPS Foundation www.xoops.org
Service Manager Administration
– For simple cases, just install the provider module ...
© 2014 XOOPS Foundation www.xoops.org
Future of Service Manager
●
User side interface to choose a specific provider for MO...
20
© 2014 XOOPS Foundation www.xoops.org
If you have any suggestions,
comments or questions, please make
them known.
You c...
Upcoming SlideShare
Loading in …5
×

XOOPS 2.6.0 Service Manager

17,257 views

Published on

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.

Published in: Software, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
17,257
On SlideShare
0
From Embeds
0
Number of Embeds
14,342
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

XOOPS 2.6.0 Service Manager

  1. 1. 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
  2. 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. 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. 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. 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. 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. 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. 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. 9. © 2014 XOOPS Foundation www.xoops.org 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
  10. 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. 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, 'XoopsCoreServiceProvider')) { $path = dirname(dirname(__FILE__)) . '/class/AvatarsProvider.php'; require $path; $object = new AvatarsProvider(); $provider->register($object); } }
  12. 12. © 2014 XOOPS Foundation www.xoops.org Service Provider Implementation Avatar example: use XoopsCoreServiceAbstractContract; use XoopsCoreServiceContractAvatarInterface; class AvatarsProvider extends AbstractContract implements AvatarInterface { // implementation goes here }
  13. 13. © 2014 XOOPS Foundation www.xoops.org 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); }
  14. 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. 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. 16. © 2014 XOOPS Foundation www.xoops.org 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);
  17. 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. 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. 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. 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

×