Hi Andrew,
Hi
Lukas,
Maybe I'm missing something in what you said, but have you exposed Web
services interfaces which you've now integrated into the same overall
approach to the problem?
Our application consumes data from all major banking systems.
It has following solutions:
a) integrate with all of them via services (WS) (bank may have
clients&accounts in four different systems - bank that bought
another banks)
b) integrate with all of them via specific API (database)
c) integrate with DHW containing consolidated data from all of them
(using SQL or WS)
d) integrate with services that integrate services with similar content
(eg. account&clients)
e) provide interface for our application queries queue (WS or SQL)
f) create our application's ODS where are replicated consolidated data
from all of them
(integrate means read data from, all of them means different banking IS)
Current version use (e - SQL) or (f) because:
- lack of services support in banks
- lack of consolidated DWH's
>From my point of view, the best is (c).
(d) is almost impossible - for example there is no unique person
identifier over differents IS(eg. 4x accounts IS, 2x safebox IS, credit
card IS, stock and bond IS, ....). So integrating service must have
some place where to store resolved conflicts... and it becomes WS over
DWH.
Is
it possible to generate triggers on the
databases which will push updates to the centralized repository as they
happen so the data is always "just there"? Maybe not.
Suppose some IS are black boxes (third party closed source). It has
only interfaces with limited functionality or you can directly access
it's database. But you need to query data from that IS.
SOA isn't really an architectural style designed for batch processing
types of activities.
I agree. I mean that I understand ideas behind SOA.
I just wanted to point out that there are some business areas that need
DWH od ODS.
- batch processing
- integrating legacy applications with duplicated data
Thanks for discussing,
Lukas
What you want to do is isolate the data you need
to move and the move it when it changes (providing you've already
decided you want/need to replicate it), or you just aggregate meta-data
about the data and then go fetch it as you are actually going to use it.
SOA is as much about re-thinking the problem as it is loose coupling and
Web services.
Cheers,
ast
On Thu, 2006-06-01 at 22:10, Lukas Barton wrote:
> Hi,
>
> I am a developer of software that queries banks' data (eg. ask
> executors, tax burear etc. questions about clients property).
> It is now uses in 16 banks. In most of them we integrate through
"SQL
> interface" - tables which are cache of canonicalized distributed
data
> (eg. 3 or more banking IS - accounts, safe boxes, credit card,
stocks
> and bonds...). Quite interesting and specific application from EAI
view
> ;-) (integrate with all important IS)
> Now we're transfering from database to web services and we face
up
> performance issues:
> - replicating database takes at most tens of minutes (AS/400, 5
mil
> rows) performed nightly
> - answering one query takse 10-20 ms (eg. 3 inserst via INSERT
INTO
> ... SELECT FROM ...)
> - using web service against live system means (per query)
> - WS call means
> - WS encapsulates EJB
> - EJB encapsulates COBOL
> - COBOL read from more than one database
> - for each query we have at least 5 WS calls over local
network
> (that's how WS usualy work when you have legacy systems)
>
> Other benefits:
> - using web services is not yet quite common practice, while
using
> databases is - every one knows SQL
> - they can store derived fields that computes long time or it's
> imposible to have it computed online - eg. last transaction on
account
> - you can do some trick that web services usually does not
support -
> like with *,?; seach by every column you want
>
> But we view our tables as well defined interface between bank and
our
> application. It does not change between minor versions. Of course
it
> does between main version. The last version of application is
independet
> of tables structure (it could be used for queries over bank
accounts, in
> telecomunication company, insurance company etc.).
>
> BI viewpoint:
> You must have some DWH for BI, eg. DWH hidden behind services.
Some
> data cannot be computed online from other services.
>
> Lukas
>
> http://www.archaebacteria.net
>
> >
> > In the context of SOA-based "master data management", one
can do
> > parallel service invocations out to the "freshest data",
certainly.
> > But there are some areas where an ODS is still needed:
> > - a persistent cross-reference
> > - master key management
> > - a cache of canonicalized distributed data
> > - a store for derived and/or invented fields (such as those
created by
> > a cleansing process)
> >
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
***************************************************************************************************
The information in this email is confidential and may be legally
privileged Access to this email by anyone other than the intended
addressee is unauthorized. If you are not the intended recipient of
this message, any review, disclosure, copying, distribution, retention,
or any action taken or omitted to be taken in reliance on it is
prohibited and may be unlawful. If you are not the intended recipient,
please reply to or forward a copy of this message to the sender and
delete the message, any attachments, and any copies thereof from your
system.
***************************************************************************************************
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
