自从体会到DSO在SQL Server2005 中的险境以来,这一个多月的工作都围绕着它所进行着。不知道是不是因为国内做基于Analysis Services的产品较少的缘故,似乎对DSO之类的讨论非常少。但是对于我们Team现在,DSO十足是一个心病。

大家都认识到微软的SQL Server 2005发布的重要性,如果我们的产品不能及早支持这个平台,很快将会在队伍中消亡。DSO之所以是个心病,是因为在以前的版本中,我们太依赖它了。在基于Analysis Service 2000的平台上,我们利用DSO几乎实现了它所能实现的所有功能(我们以前的平台是ASP+COM+SQL/AS2k)。从创建数据库,维度,立方体,到Partition,Roles,Level等所有对象的创建和维护,我们在代码中都实现了。由于在 2005上面不能再使用DSO的缘故,我们列出了四条出路:

1. 借助2005中自带的Migration程序把2000的数据库迁移过来,并希望DSO仍能被迁移版本支持。
  结果是令人失望的,一是没有能成功迁移数据库(旧数据库我们实现了Virtual Cube等很多不兼容或不被支持的特性),二是由于旧版本基于Meta Data 服务的Repository的概念消失,导致DSO的功能单向不能继续使用。

2. 如果数据库不能迁移,我们自己创建一个操作AS2005的管理平台(类似Management Studio),操作2005数据的同时,像2000一样同时更新一个存在SQL Database中的Repository。
  这个任务如果采用,可行性和难度都是非常大的,而且我们不可能让用户也使用这个平台去操作他们的数据库。

3. 用托管代码操作AMO来包装DSO的所有接口,并通过CCW在COM中使用。
看似有一定难度,工作量不是很大,因为如果能实现这个DSO的Wrapper,并保证接口都不改变,那么表现层,中间层的代码我们都不需要改变。

4. 利用AMO,修改所有表现层,中间层,和数据层的代码。
第四种方案就是实现一个新的系统了,所有旧的ASP框架将被重构。工作量大,周期长。

我们的目标是要尽可能快地完成到2005的迁移,基本保持产品所有功能都能使用。最后鉴于各方面情况的考虑,我们采用了第三条方案。

现在我就在这个方案的实施中煎熬...

我们面临的第一个挑战就是.NET 2.0被COM的顺利调用,似乎很顺利,我们在VS2005的平台上的CCW论证的很成功,也具有了一定的说服性。

其次面临的问题是DSO的Wrapper,这个最艰巨的任务。我们从DSO实现接口开始,通过RCW反编译.NET代码开始,把DSO实现的所有接口都在UML类图中表示出来(如果有朋友需要的话,我可以提供该类图的Visio版本)。并罗列了系统中用到的所有DSO接口使用。这些只是一个需求工作的开始。然后我们不切实际地用DSO的架构准备作为新类库的开发。这里我遗憾地是没有提早做AMO和AS2005细节的Research,以至于这个为新类库的架构工作毫无用处。(待续)

Posted on 2005-11-16 20:37 Chagel 阅读(...) 评论(...) 编辑 收藏
本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。

©2005-2009. Chen Gang