Jump to: navigation, search

Umlaut Technical Overview

1,224 bytes added, 20:05, 6 February 2008
Methods implemented by a service adaptor
That class holding the service logic is called a "service adaptor", or somewhat ambiguously, sometimes times just a "service". Service adaptors live in lib/service_adaptors, and extend [ Service].
====Methods implemented Service adaptor implementation==== =====Statelessness===== Service logic should generally be written to be state-less. The same Service object, defined in services.yml, is initialized once and generally re-used for the life of an application instance (cached by ServiceList). So any state you store can end up persisting from request to request and session to session, which you probably don't intend. Umlaut architecture for background services also involves threads and forks, and while there's normally no reason a given service adaptorobject would be in two threads simultaneously, better safe than sorry. It's safest to store no non-universal state in the service object.  =====Disclosure methods=====
A service adaptor must define [ service_types_generated()] to return an Array of ServiceTypeValues constituting the types of ServiceResponses the service
: required_config_params :api_key, :base_url
url handling=====The handle method===== The heart of a typical service is in implementing the [ handle] method. When Umlaut wants a service to do it's thing, Umlaut will pass the request in, and it's up to the Service to do it's work.
Avoid stateful-nessThe service can examine all metadata from the request, object is re-used accross requestsand even examine ServiceResponses generated by other services, and due to possible multi-threaded implementationthe status of other services in progress or finished. (See [ Request#dispatched_services], may even be used concurrently[ Request#dispatched], so write thread-safe[http://umlaut. Or avoid state Request#services_in_progress], etc.)

Navigation menu