Radovan
On 4/19/06, stilkov <[EMAIL PROTECTED]> wrote:
My view is that services, at least those on a sufficiently high level -- let's call them
business services -- should own their data. That means that the only way to get to their
data is through their public (and published) service interface, not through some
"backdoor". The data they expose through their message-based interface may be quite
different from what they store in some underlying persistency mechanism (for a good
discussion of this, see Pat Helland's article [1]).
How, then, does one address business intelligence/data warehousing/ODS/general OLAP
issues? Forbidding the BI folks to directly access the underlying data via SQL is not going
to make them your friends, and alternatives such as providing them with the message/
XML-level access only is not what they're looking for, either.
My current thinking is to provide a read-only SQL view for services that maintain some
data; this view would be decoupled from the actual relational data representation, its
definition would be versioned, its lifecycle would be governed by the same means as the
"normal" service interface, it would be stored in the registry, etc.
Thoughts?
--
Stefan Tilkov, http://www.innoq.com/blog/st/
[1] http://msdn.microsoft.com/library/default.asp?url=""
dataoutsideinside.asp
SPONSORED LINKS
Computer software Computer aided design software Computer job Soa Service-oriented architecture
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture " on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .
--
Radovan Janecek
http://radovanjanecek.net/blog
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
