> 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?
SQL "views" are like "interfaces" in programming languages. They provide a
useful abstraction of the underlying data, but the implementation can change.
Anytime that you export "data", it's very good practice to create a "view". In
the Java programming language, services should use "interfaces" to create the
same level of abstraction.
Gregg Wonderly
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.
