|
|
| Service Oriented Enterprise |
|
|
Wednesday, March 24, 2004 Verb Only (when the verb acts the same on all subjects - e.g., save (x), save(y) Verb Noun (when the verb acts differently (different logic) on each subject processPurchaseOrder(), processSalesCommission() Qualified Verb (Bidirectionally Link(x,y)) versus link(x,y); used to qualify the intent of the verb (changes functional requirement, unlike most adverbs which only apply to NFR) Verb Mechanism (when the logic is changed more by the mechanism than by the subject) posted by jeff | 1:17 AM 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. posted by jeff | 12:14 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
