A behavior mechanism connects a behavior definition (list of methods) with services that implement the methods.
Behavior mechanisms have many restrictions, and it is not always obvious when these restrictions will cause you problems. The best approach is to only use Fedora's internal processing for simple datastream retrievals and single XSL transformations. For anything moderately complex, the mechanism should simply pass the appropriate datastreams to an external service/servlet.
For a mechanism that simply returns a datastream, put the stream name in parentheses (SCREEN), and reference it as a DATASTREAM parameter passed by URL-REF. For a mechanism that performs some operation, enter the URL of the service, adding any data references in parentheses.
When creating a mechanism, you can pass three types of parameters to the target web service:
The most frequently used service is Saxon: http://\[hostname\]:\[portNumber\]/saxon/SaxonServlet?source=\[xmlSource\]&style=\[xslStylesheet\]&clear-stylesheet-cache=yes
To pass an object's PID, declare the parameter to be type DEFAULT, but use the default value "$pid" (without quotes). To pass a PID in URI form, use the default value "$objuri".
Although it is possible to pass an object's datastreams to the service the bmech represents, making use of the object's contents within the bmech (before the service is invoked) almost always impossible. You cannot insert the value of a datastream directly into the service URL; it can only be passed to the service by reference. You cannot use the value of a dissemination in a mechanism, unless you have created a datastream that redirects to the dissemination. Again, the best you can do is gather up the relevant information and pass it to an external servlet that does the real work.
Disseminators without datastreams: Sometimes, it is useful to write a bmech that doesn't use any datastreams. For example, you may want a utility a mechanism that connects directly to some external site, or one that operates solely on the ResourceIndex. Fedora requires each bmech to reference at least one DATASTREAM parameter, or the Fedora internals will not correctly find/run this behavior. The preferred method of getting around this is to use a datastream called "NULLBIND", which simply maps to the default DC.
Disseminator chaining: You can "chain" disseminators, but it is somewhat clumsy. Object A provides a dissemination. Object B contains a datastream that redirects to A's dissemination. Then B may have a mechanism make use of the datastream, effectively having B's disseminator work off of A's disseminator.
Disseminator redirection: This trick depends on undocumented Fedora features. It may not work with future releases. You cannot explicitly mark a disseminator to redirect. By default, disseminators will always pipe their results back through Fedora, so disseminators that result in HTML with relative references will not work correctly. To force a disseminator to redirect, the mechanism should include a dummy datastream that uses the "redirect" content type. This will force the entire disseminator to redirect. (By convention, we use some form of REDIRECT as the name for datastreams of this type.)
Fedora doesn't make it easy to modify the definition of a behavior mechanism, but it is possible.
Making changes to a mechanism's datastreams can sometimes corrupt the mechanism and/or the database contents, rendering the associated behaviors unusable. Use with care!
In some cases, the internal contents of the mechanism can be changed, but this is difficult because the datastreams generated by the mechanism builder don't have the same structure as the GUI in the mechanism builder. For some reason, most of these datastreams aren't editable in the admin interface, but they can be edited in the raw XML and re-imported. That is, the individual datastreams can be re-imported, but not the entire mechanism. A summary of the datastream contents:
DS1 – documentation
WSDL – basic outline of the service and the URLs used to fulfill the service.
SERVICE-PROFILE – listing of all input and output formats, not attached to any particular behavior
DC – basic DC data
DSINPUTSPEC – names and MIME types of datastreams this mechanism needs for input
METHODMAP – parameter configuration for all behaviors
A relatively safe process for changing mechanisms is to migrate objects between mechanisms. This takes some time, and adds relatively uninformative information to the audit logs, but it's currently the best way to modify mechanisms.
If the change you're contemplating would impact the behavior definition (API), a similar process should work.