• Save
XOOPS 2.6.0  Service Manager
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

XOOPS 2.6.0 Service Manager

  • 12,816 views
Uploaded on

XOOPS 2.6.0 alpha 3 introduces a Service Manager component: ...

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.

More in: Software , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
12,816
On Slideshare
1,434
From Embeds
11,382
Number of Embeds
1,015

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 11,382

http://www.myxoops.org 5,417
http://xoops.org 2,765
http://localhost 351
http://www.xoops.pl 211
http://xoops.pl 199
http://www.limhamn.nu 133
http://127.0.0.1 103
http://www.xoops.org 101
http://feeds2read.net 100
http://www.templeofthejediforce.org 55
http://www.nlxoops.nl 50
http://ixthemes.com 46
http://planet.cms-quebec.com 28
http://www.hsps.ylc.edu.tw 25
http://www.pmonline.com.br 22
http://templeofthejediforce.org 21
http://www.xiao.ca 19
http://five-thirsty.com 15
http://www.affiliatetalk.de 15
http://earth-power.boy.jp 14
http://www.civilstart.nl 14
http://www.rogivue.com 13
http://www.churchhall.co.uk 13
http://setimoceu.com.br 13
http://tv.xoofoo.org 12
http://www.sibagal.com.ec 12
http://www.izzatomar.com 11
http://163.17.237.100 11
http://www.libreopinion.com 10
http://bbhos.com 10
http://www.sos-enfants.org 9
http://yakoh.s58.xrea.com 9
http://www.south-gate.org.tw 9
http://f-wood.net 9
http://163.32.98.35 9
http://www.lite.4x.lv 8
http://203.74.123.49 8
http://www.shabu-shabu.com.tw 8
http://dijitalevren.com 7
http://ecmcu.no-ip.org 7
http://www.wilden.es 7
http://sole.aplord.com 7
http://www.fore.me.uk 7
http://www.saintpauldevence.org 7
http://bassmanthemes.com 7
http://www.lreat.org.tw 7
http://www.c-labs-wt.com 7
http://culture.lotong.gov.tw 7
http://www.hotspot-zone.com 6
http://www.mp3-arabe.com 6

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. © 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 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. © 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, 'XoopsCoreServiceProvider')) { $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 XoopsCoreServiceAbstractContract; use XoopsCoreServiceContractAvatarInterface; class AvatarsProvider extends AbstractContract implements AvatarInterface { // implementation goes here }
  • 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. © 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 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