请问各位大侠在设计上如何利用uddi中的分类法

我现在的想法是将一类文件或者说是目录当作是一个service，而将每个文件当作是一个bindingTemplate，其标识就是bindingKey，文件名以及其他文件属性可以放在description中，放在相应的service下。但是这样子不能形成一个树型结构，只是简单的两层结构。
    当然，如果我们利用tModel的话可以作以下想法：
    创建三个tModel，分别叫做root（根）、node（非叶子节点）、leaf（叶子节点），
然后每个文件（即bindingTemplate）中的tModelInfo中可以引用这些tModel的key，然后在InstanceInfoParam里填写的是其父的bindingKey，对于root节点的父就是其上的service的key。而这种方法可以从子索引到父，但是从父索引到子会比较繁琐。
    因此我又想，再创建一个tModel叫做children。对于每个具有孩子的文件（即具有root或者node的tModelInfo的bingdingTemplate，在此可能称作目录更恰当），每当其新增一个孩子节点时便插入一个children的tModel的key，其InstanceInfoParam便是其孩子节点文件的bindingKey，这样子的话就可以实现从父到子的索引。
    按照这样的思想，每一个service就是一个大类（主目录），而每个service下有若干个bindingTemplate，其中部分拥有root的tModel，这些看作是主目录下的直接子目录，而其余的拥有node或者leaf的tModel，这些被看作是直接子目录下的各层目录直至最终的文件。
    但由于uddi本身的目的并不是为了建立这样一种树状结果，所以其提供的查找api的能力有限，我们暂时通过find_service来得到主目录，通过find_binding来得到各层子目录。但是对于find_binding来说，我们能利用他来直接查找的结果是：哪些是root，哪些是node，哪些是leaf，但是如果说我要根据名字来查找一个文件/目录的话并不能很好的实现，我们只能将所有的bindingTemplate取出来，然后再对其中的description进行匹配操作，这是因为bindingTemplate没有名字这个概念而且find_binding并不能将bindingTemplate里的更详细的信息设为查询条件。而如果这样进行查询的话会很浪费资源。
    鉴于上述的问题，一种改进方法是将所有的目录/文件放在service这一层次上，即我们要搜索的只是service，而其中的bindingTemplate只提供一种附加信息（可以暂时不考虑），由于find_service可以提供对service的name进行搜索的功能，而且我们还可以利用categorybag的功能来进一步扩展。
    不知各位大侠有何想法，不妨讨论讨论？
    来者有分，但不要只是给个up字吧，：－）