Blog

Created on Thursday, 04 August 2005 15:42

Written by Larry Grey

Another question from ITTOOLBOX.COM

The answer to this question is contained in a previous post to this weblog.

However, database links may not be an available option to you (either due to policy considerations or due to dabase platform limitations).

Believe it or not, this issue sparked much debate in the PeopleTools team when scoping PeopleTools 9 (not the Peopletools 8.48 version that will be coming out under Oracle but the Tools 9/Tools X release that PeopleSoft was working on prior to the Oracle acquisition). There were several use cases that our applications wanted to solve that required remote access to another PeopleSoft database (such as using a KPI from EPM to control processing in a transaction system, looking up a credit rating from AR in the CRM order entry application, etc.).

The PeopleSoft application development teams wanted a feature called "remote data objects", which essentially allowed a remote table to be accessed as if it were a local table without having to get a DBA involved. As the person responsible for the Data Objects feature in release 9, I was part of these discussions.

In the end, we realized that although it would be convenient, remote data objects was not a good feature to deliver. This was because of the following:

1. It introduced a dependency between two different systems that was too difficult to manage. Without a standard interface between the two systems, a simple upgrade or change to one system could bring the other down. This was even more risky because the administrator of the system depended on would have no idea that the dependency existed.
2. It also created a potential performance issue. This is because database links can be poor performing, because data must be moved between database servers that wouldn't otherwise have to be moved if the data were local (and the current methodology in Peoplesoft applications is generally to replicate the data to a local table and then use it).

The resulting decision was that SOA would be a much better way of accomplishing this level of integration. By having well-defined services, a program can request through a well-defined interface, the information it needed. Upon upgrade, as long as the source system maintained the same interface, the consuming system would continue to work. Thus the interest in services oriented architectures.

Unfortunately, SOA has a long way to go to be as effective as a SQL statement. This is because the services are not designed for the type of access that a SQL statement supports. This means that SOA does not support reporting or batch programs in its current incarnation (we kicked around defining a standard for this type of service, but never got off the ground).

Labels: Database