There has been a lot of interest lately in modeling data access in the context of SOA, and few understand how to do it. Indeed, many of the same "traditional" data modeling techniques still apply, but SOA brings its own complexities. At the core of the issue are models for access, or the way in which we view and access data and information at different levels within the SOA. Within a typical SOA we have levels t There has been a lot of interest lately in modeling data access in the context of SOA, and few understand how to do it. Indeed, many of the same “traditional” data modeling techniques still apply, but SOA brings its own complexities. At the core of the issue are models for access, or the way in which we view and access data and information at different levels within the SOA. Within a typical SOA we have levels to consider: Physical, referring to visibility at the actual physical database level, in essence going after the raw data. Schema, referring to visibility to the schema, in essence putting structure around the data. Abstraction, referring to the remapping of the schema so it’s more workable and logical for the SOA. Semantic, referring to visibility into the meaning of the data. Service, referring to exposure of the data through services. Transaction, referring to the binding of the data and/or data service(s) to transactional service(s). The core point here is around the different views, or models, leveraged at each level. Which model to employ when, depends on how you want to view and process the data in the context of your SOA. What’s key here is that you select and define those views, including models employed and enabling technology and standards for access. We’ll have to dig a bit deeper here within future posts. Any comments are welcomed at this point. Software Development