Ronan Bradley did a great job in his recent post: Data: The heart of SOA.
"Within a SOA, the data models built are then exposed through the service definitions. The requesting applications must either formulate the request using the data model of the service provider or more commonly rely on an intermediary such as an ESB to bridge the gap (something I refer to as mediation).."
Certainly, data is the heart of any information system, including SOA. Indeed, semantic mediation, transactional binding, exception management, and certainly abstraction are all in that mix as well. However, I put forth that the real value of SOA goes well beyond the data when considering the true value of services.
Truth-be-told, services can be anything really. They can abstract data, they can produce or consume data, even restrict access to data. However, considering the notion of reuse, the most ROI from the creation of services is the ability to provide true behavior or more simply put: application functions with data bound to those functions.
For instance:
Calculate_Risk();
Validate_Credit():
Is_Address_Real();
In my now outdated EAI book (that continues to sell well by the way), I called this method vs. information integration, pointing out the differences between simple information replication and mediation, versus dealing with true application behavior. Today I call this service-oriented integration versus information-oriented integration, and point out many of the same differences.
While data is always there, the heart of a SOA needs to be services that represent both information and behavior. Services that represent data are clearly required, but the real value of SOA is providing the architect and the developer with the ability to mix and match application services to create and refine business solutions, data is only a part of the story there.
Hmm...I guess it really depends. I would argue that many, many common Web Services are data-centric: get quote, show pipeline, list cheap DVDs.
Interestingly, it's also quite likely that in the examples above there is a heavy data integration component behind those functions. So "functional services" would likely be calling "data services," still giving architects the flexibility they are looking for. For example, in a bank, calculating risk often involves combining data from a positions database, a reference database or service, and a risk application. Making all of this data available as a Get_Risk_Data service available to the Calculate_Risk() function seems quite elegant and likely.
Most services leverage data, but that does not make them data services. I would say data services do what they sound like they do, abstract data. I’m asserting that there are another level of services that are more focused on application behavior, with that behavior of course being bound to the data. Those services have more value, and should have more focus when building a SOA.
Data is of course still needed but it is not sufficient. If we just focus on data we end up designing database schemas (or XSD today). It is more important to categorize the functionality you need to act upon your data. A good way to do that is to organise this functionality as services. Therefore I agree with your statement that SOA is more than just data.
I do agree that SOA is more than just data. Lets not forget that the real value of SOA is in aligning business with IT. How do we accomplish this...? By speaking the parlance of business i.e. exposing services which perform a business function. These services may be fine grained or coarse grained and may require a composition of different services to a acheive a business function. Also the service layer has to be flexible to cater to the vagaries of business.
Yes, eventualy data is being exposed, packaged, abstracted as a service, but we have to be cognizant of the higher layer: the business services layer which gives bang for the buck!