Services were document oriented but were not generic as previously described in this thread. But process-generic well, as much as it was possible.
The services were quite never returning back a new version of something present in the request, as you mentionned. There were several service "patterns": - services that were just returning data, getting full customer info, getting a customer address, the list of services a customer had, getting the last bill, etc etc, only read-only stuff. - services that were modifying something, like updating or creating reference data or triggering a process. Ex: "create order" There was not a single create order service for example, the nature of the service request data was so depending on the nature of the order that those were different services according to the case. - basic services involving on one single application service - composite services = a composition of existing services (= a mini-process on their own) - legacy wrapper services, services that were just mapping existing mainframe transactrions etc etc More or less similar to David Linthicum's service operational patterns http://www.ftponline.com/ea/magazine/summer2005/features/dlinthicum/default_pf.aspx I am not sure to understand what you mean by filters and decorators. Filters is something we are currently looking in my new SOA project. We build an operation that can return a customer with all possible attached details, for example: addresses, list of contracts,... Of course, the response can be huge and the operation processing might consume lot of power before returning a reply because of the potentially large number of entities traversed in the customer database. Filtering is used here to narrow the operation call on that service. So 2 service consumers use the same operation in the same service but one asks for having the customer and the list of contracts while the other asks for the customer and the addresses and so forth. Filtering as I see it is more an operational day-saver. What we are discussing about now is Service design. How to create a service right which is, I believe, critical for a successful SOA. --- In [email protected], Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote: > > > That's interesting. Can you say anything about the nature of the > operations? > > Having only one operation per service suggests that they were > document-oriented - e.g, "here's a purchase order, do something to it > and give the updated version back (or pass it on)". Such a REST-like > style seems well-suited to the cross-cutting approach approach to SOA > that Anne described (services as filters or decorators). 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/
