--- In [email protected], "htshozawa" <[EMAIL PROTECTED]> wrote: > > The book seems to be better titled "Practical Web Service > Implementation". Chapter 2 would have been better > titled "Designing Web Services", and chapter 3 would have been > better titled "UDDI".
I had a very similar thought. Very WS heavy. > I really didn't understand about the "data service" > and "transaction service". I too had issues with this particular segmentation. And it was unclear what the author thought was the right level of service--in one case "retrieveOrdersForCustomer" was a service (seems like an operation to me) and in another "AccountsReceivableAging" was a service (seems about right). This is where I had hoped to get opinions of others--what's the "right" level of abstraction for a service? > As data services just services based on > a simple query while transactional service are those involving > transactions? In a typical modification process, we usually do a > query to get the current data and do some modification and them > commit the change. In this situation, are there 2 services to > retrieve the current data - a data service just for an inquiry and > transactional for the modification? Yeah, this seemed quite odd. And we touched on some of this in the recent data services/data access layer discussion. I actually took issue with the very first sentence of chapter 2: "In a service oriented architecture, services provide the basis for communications between systems and technologies." That sounds too integration-y. The central focus of SOA isn't about communication (although communication is important). -Rob
