200
edits
Changes
no edit summary
=WARNING: This is Outdated Documentation!!!!=
'''THIS IS OUTDATED DOCUMENTATION''' See new Umlaut documentation at http://github.com/team-umlaut/umlaut/wiki
---------
Part of [[Umlaut Technical Overview]]
===Statelessness===
(Not sure this is actually true any longer, working to make it not so. jrochkind jan 2010). 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 object 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===
===The handle method===
The heart of a typical service is in implementing the [http://umlaut.rubyforge.org/api/classes/Service.html#handle 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. Note that while the individual umlaut request is passed into handle() as an argument for legacy purposes, it's also available from Service#request at any time, the argument isn't really necessary.
The service can examine all metadata from the request, and even examine ServiceResponses generated by other services, and the status of other services in progress or finished. (See [http://umlaut.rubyforge.org/api/classes/Request.html Request#dispatched_services], Request#dispatched, Request#services_in_progress, etc.)
