Bill, I agree with you 100%. In addition to that, I think general vs. specific is not a good factor to measure "well-designedness".
Extending a system that ships Pizzas to also ship Sandwiches would be a good idea if Sandwiches and Pizzas do have lots of similarities in their shipping process but also in their own nature (which might be the case here). If extending the Pizzas service to support Sandwiches result in an increase of interface complexity; red-alert, it's a bad design decision. In that case, it would be better to separate Pizzas from Sandwiches and consider those 2 as different services. An intermediate option would be to bundle operations for Pizzas and Sandwiches with operations that are truly Pizza or Sandwich independent in a single service. Not a black and white decision, this is not architecture but design. Robin http://blogs.ittoolbox.com/eai/applications/ --- In [email protected], "Bill Appleton" <[EMAIL PROTECTED]> wrote: > > There is a total trade off between being specific and powerful and being > general purpose and requiring lots of additional work. The more universal an > interface is the less chance anyone is going to use it, it would be too > hard. There are a bunch of w3c standards no one uses for this reason. The > most used services (at least for us) do a specific thing for a specific > vendor. > > Bill Appleton > CTO > DreamFactory Software > tel. 408-399-7454 x 102 > fax. 408-351-9005 > cel. 408-656-3024 > <BLOCKED::mailto:[EMAIL PROTECTED]> > [EMAIL PROTECTED] 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/
