在SOA中,您可以适应
Biztalk或
SAP BusinessObjects Data Integrator的处理方式.基本上,它是一个调度程序作业/ Windows服务,或类似的东西.您提供两个服务点,1个为调度程序检索数据,另一个为调度程序发送数据.调度程序在这里的责任只是定期运行和转换数据.
所以,基本步骤是:
步骤1:调度程序运行并从服务A获取数据
Scheduler --get--> Service A
Service A --data--> Scheduler
步骤2:调度器进行数据转换
[ Conversion --> Conversion --> Conversion --> Conversion ]
步骤3:调度程序将数据发送到另一个服务
Scheduler --data--> Service B
在Biztalk和SAP BusinessObject Data Integrator中,这些步骤是可配置的(它们可以从任何服务中检索,并且可以进行脚本数据转换),因此它更加灵活.
然而,仍然存在ETL处理可能会发生的常见问题.例如:数据太大,网络性能影响,RTO,重复数据等.因此,ETL最佳实践在这里仍然是一个要求(使用分段表,日志记录等).
But are the performance degradation and additional points of failure
worth it?
性能影响将会发生,因为现在您有额外的连接/认证步骤(webservice)和运输步骤(通过协议的web服务调度程序).但是出于容易出错的问题,我认为与其他服务调用需要处理的错误相同.
这值得么?这取决于.如果您在相同的环境中工作(相同的数据库),那么这是有争议的.如果您在不同的环境中工作(例如,从Asp.Net到SAP或至少不同的数据库实例两个不同的系统),那么这种体系结构是处理ETL的最佳选择.