Verb Mechanism

Many of the web services that are created take on the form of "VerbMechanism"; that is, they specify a verb and the mechanism in which to accomplish the task, then they usually require the 'who' and the 'what' to be passed in:
sendEmail ( 'to bob', 'the status report')
sendFax( 'to bob', 'the status report')
sendInstantMessage( 'to bob', 'the status report')

Here, the mechanism is 'Email', 'Fax' and 'InstantMessage".

Another way of writing this is by using 'via':
"send the status report to bob via email"

When specifying a mechanism, we will likely have preconditions on the mechanism. "via email" requires four pieces of information (email server, email credentials, email destination, email payload); The data related preconditions can be expressed in a declarative manner on each mechanism. Currently, we push these data nuggets into the signature of the VerbMechanism. But usually there is an overlap between the verb and the mechanism (it was 'send' that required two of the pieces of information (destination, payload); the mechanism required the other two pieces (server , credentials).

A mechanism is a way to overload an operation. The verb I'm overloading is 'send' and the mechanism is 'Email". When we overload in object oriented systems, we usually just grow the signature: send(destination, payload); send(server, credentials, destination, payload); I'm not a fan of this... I prefer the declarative OCL like approach but with an 'implied signature' based on the overloading with a mechanism.

Another issue to consider is the 'invisible mechanism' or 'implicit mechanism'. Consider:
savePurchaseOrder(...);
Here, the designer intentionally hides the implementation mechanism from the user of the operation.
Save Purchase Order via Relational Database
Save Purchase Order via Flat File

Now, I agree that it is a good practice to not burden the user of a service with mechanism. However, I'm not sure that it is always a good idea to hide it from them (burden them versus inform them).
Again we see that each mechanism will require a set of preconditions:
"via Relational Database" needs (a JDBC Driver, a connection string, credentials, etc.)

I'll save "Reliably Save the Purchase Order via Relational Database" for another morning.