Just to clarify I am not saying that granularity is an easy thing and perhaps the way to look at it from a high level is the operations you choose is something of balance between pace of change at the interface level and segmentation of the service based on the data that is needed.
Having a generic operation is less useful so you can go to high and yet having operations that are too specific is going to far the other way as they may change too much. So a happy medium is needed. The benefit of having more distinct operations is really about capturing meaning and making the architecture cleaner and clearer - so transparency is a key. A "doit" operation does not help but having "doA" followed by "doB" makes in clear that A preceeds B. Having "doit" and "doit" does not make it clear at all so we can see that it does not help with understanding or clarity. Cheers Steve T On 28 Feb 2006, at 13:41, Steve Ross-Talbot wrote: > Not sure I agree with you Mark. > > You are correct of course in stating that the less assumption made the > looser the coupling. > But there is still a coupling at the message level. If you have just > "submit" you are requiring > the sender to fill in a message with the necessary information as to > what is being ordered > and the receiver the reverse. > > Would it not be better to promote this detail into the operation > rather > than hide it in the message > because this make visible what you are doing and what the service can > provide. This way the number > of data errors is less because that part of the data is promoted into > the op name. > > Cheers > > Steve T > > On 28 Feb 2006, at 09:18, Mark Baker wrote: > > > Todd, > > > > On 2/27/06, Todd Biske <[EMAIL PROTECTED]> wrote: > > > Personally, I disagree with this comment. The extent to which > > > general vs. specific is a measurement of a well-defined > interface is > > > dependent on whether or not the service is general purpose or > for a > > > specific purpose. > > > > I don't think so. Whether your interface is submitPizzaOrder, > > submitOrder, submit, submitPepperoniPizzaOrder, or > > submitPepperoniAndAnchovyPizzaOrder, you can use any of those to > order > > an anchovy and pepperoni pizza. What you can't do though, is > order a > > snake, crocodile, and kangaroo pizza (yes, I've had one 8-) with > > submitPepperoniAndAnchovyPizzaOrder. Do you disagree? > > > > What some of us are saying is that the more generic the interface, > the > > better separated are the concerns of implementation and interface, > and > > therefore the more loosely coupled the relationship between clients > > and services; that in the above set of options "submit" is the > "best" > > option in this regard because it makes the least number of > assumptions > > about the implementation. I think we're all aware of the benefits > of > > loose coupling. > > > > > As things change, so must the service > > > interfaces. > > > > Respectfully, I think that's entirely counter to the objectives of > SOA > > and large scale systems in general. The separation of interface > and > > implementation is paramount. > > > > Mark. > > -- > > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > > > > > > > > > > > > SPONSORED LINKS > > Computer software > > Computer aided design software > > Computer job > > Soa > > Service-oriented architecture > > > > YAHOO! GROUPS LINKS > > > > ▪ Visit your group "service-orientated-architecture" > on the web. > > > > ▪ To unsubscribe from this group, send an email to: > > [EMAIL PROTECTED] > > > > ▪ Your use of Yahoo! Groups is subject to the Yahoo! > Terms of > > Service. > > > > > > > > > > SPONSORED LINKS > Computer software > Computer aided design software > Computer job > Soa > Service-oriented architecture > > YAHOO! GROUPS LINKS > > ▪ Visit your group "service-orientated-architecture" on the web. > > ▪ To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
