On May 31, 2006, at 1:39 PM, Radovan Janecek wrote: Hey Stefan,
I guess you have persistent challege, right? (http://groups.yahoo.com/group/service-orientated-architecture/message/4084 )
Hi Radovan, no, not really. Back then, I was asking about pure DWH, BI, OLAP needs - analysis, reporting, that sort of thing (sort of what Jan addressed in his posting as well.) This time, it's about (our definition of) an ODS: A source for current, up-to-date, consistent maintained business data (such as e.g. the current customer record) -- and in particular, not only for BI purposes.
For example, when a service needs to know something about a customer and an account, it can
(a) go to both CustomerManagement and AccountManagement and correlate the data itself (b) go to ODS and retrieve the aggregated information
Approach (a) would support a strong concept of data ownership and autonomy, which I like very much. Scenario (b), though, is very attractive for many because it consolidates the data integration logic in a single place. For this purpose, I'm not as much concerned with how the data gets into the ODS (via data replication, Web service calls or RSS/Atom feeds). I'm unsure whether putting a single "know-all" entity in the center is such a good idea ...
Stefan
I think ideal SOA way requires ODS _service_ works with _copy_ of the data owned by other services. Then, ODS _service_ is loosely coupled (independent). I would compare it to Google working with copy of the data from my and your blogs. It does not depend on databases our blogs run on. It uses our blog services interfaces (RSS/HTTP).
The showstopper problem to this approach is that you have to have services first (that expose the data) and then you can do ODS. While in reality you likely have opposite situation: you need ODS and you don't have all data 'servicized'. In such case I would try to establish new ODS Service that would syndicate data from few first services into its own (RDBMS) database. And then I would use this new database as one of datasources to some traditional OLAP system. You will likely get hibrid that is even more complicated but there would be a clear incremental path to having one ODS Service at some point.
I'm not experienced OLAP guy so I hope it's not completely stupid ;-)
Best,
Radovan
On 5/31/06, Stefan Tilkov < [EMAIL PROTECTED]> wrote: I'm looking for thoughts on possible integration/co-existence/ conflict issues of SOA and ODS (Operational Data Store) concepts. An ODS as a centralized, up-to-date, hybrid OLAP/OLTP store for status data (without history) is appealing because it can be the point of consolidation for information spread throughout the company (e.g. for issues such as fraud detection, compliance issues etc.). On the other hand, it seems to violate the idea of loosely-coupled, independent services with managed dependencies -- after all, the central storage might be abused (on purpose or accidentally) for integration tasks. What do you think? Is an ODS something that you would avoid in an ideal SOA scenario? Or do you consider it a vital piece an any decent company's IT environment? Personally, I'm still undecided. I have a strong fear of creating a huge, monolithic, centralized bottleneck and maintenance issue, while on the other hand I can't seem to be able to find a good "pure SOA" alternative. Thanks, Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ SPONSORED LINKS
YAHOO! GROUPS LINKS
--
Radovan Janecek
http://radovanjanecek.net/blog
SPONSORED LINKS
YAHOO! GROUPS LINKS
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
