Endeca 自从被Oracle收购过后，它和ATG的集成也就只是个时间的问题，笔者经历了ATG 9.0-ATG10.2各版本的Endeca集成过程，其中虽然有不乏痛苦的经历，但更多的是看到了ATG对Endeca的一次又一次的合理的整合和完善。
ATG9.0 笔者是在用ATG9.0的时候开始接触Endeca，其实当时可以说ATG９几乎和Endeca没有任何的关系，Endeca的Query框架也是基于Spring的模型，而笔者当时所要做的任务不仅仅是研究Endeca，还要考虑Endeca与ATG的整合方案，当时众说纷纭之下，其实只有两种方案，一种是在Store端同时有Spring与ATG容器的并存，一种是并Endeca的Query框架有所选择的迁移过来。 二者其实各有优劣， 总的说来，如果要快速完成框架整合，其实两种容器并存的Effort将会是最低的，而且风险也会更低，因为Spring容器的Query本身就是一个成熟的API框架，你不需要对他进行过多的修改就可以直接上线，而我们所做的仅仅需要建立一个良好有效的通道来连接此两个隔离的容器而已。
但是笔者还是试着将Endeca Query的框架硬性的移植到ATG容器之中，前后差不多两周的时间，修修补补，一个简单的ATG With Endeca的电商Demo起来了，现在想起来，其实当时的很多方案和做法是很挫劣的。
幸运的是，后来ATG升级到了10.x。当纵观这次升级，会很欣喜的发现ATG为了与Endeca的集成做出的努力，你可以很清晰的看到各大主要模块的划分：Base , Index , Assemble.
虽然你可以发现有一些的不足与待改进之处，但是通过这些模块的快速的集成，你能很轻松的搭起一个ATG & Endeca 的Demo站点。
但是随着与ATG模块的深入了解过后，其实也渐渐的开始对其有所保留。 比如Index模块，ATG的Index模块几乎与ATG Search同出一辙，采用类似于Repository的建模方式建立映射，同时默认采用与CAS的对接，而Endeca端的record store adapter直接指向CAS 进行数据采集，其实这一流程从理论上来说是非常良好的流程设计，但是往往项目中因数据来源与需求上的特异性，导致这个Index模块几乎被弃置。而谈到Assembler模块，这个确实有点不好细说，ATG几乎没有任何策略，只是简单的将Endeca Assembler模块直接改造过来，当然这样做也是为了给非ATG平台转向ATG平台的Endeca模块提供更强的兼容性。
但是也不得不说的是，ATG在引入Assembler模块做的比较好的地方是引入了Filter 与 Cahce策略。 Filter可以说是完全符合了ATG一向的风格，设想，当你需要保证查询出来的数据是有效的，同时只查当前Site或者当前类别的数据，你需要去构造一些稍微有点点复杂的EQL ，而ATG Eneca Filter 可以让你几乎只需配几个映射字段就可以实现，而每次查询的时候默认会加载这些Filter去过滤.
而Cache策略也是为了解决因为特殊需求不断的向Endeca发送请求的开销。一般来说，Commerce Site 上面的导航条就是各种不同的维度的集合，假设没有Cache的情况，用户在每一次访问页面是都需要去Load 一次导航维度的数据，而这种维度的获取可以是基于一定的规则进行深度搜索而来，这种单次开销如果加上一个时间和用户人数的单位量的话，就是一个巨大的引患。而ATG的cache策略可以将所需的维度全部缓存起来，但是美中不足的是，ATG 的导航维度Cache策略，只支持Catalog的单向读取，不支持双向。因为这个不足，往往在真实项目中成为空中楼阁，弃之不能用。
以上只是一些饭后淡资。