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.
>
>





 
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/
 


Reply via email to