CMSEntity之一，各种Job和VO

contentFetcherJob
ContentProcessorJob

ProductInfoFetchJob
ProductProcessJob

com.chinatelecom.ismp.contentpublish.req包的类ContentSyncNotifyReq

com.chinatelecom.ismp.contentpublish.ContentPublishedReqAdapter
com.chinatelecom.ismp.contentpublish包里的方法ContentPublishedReqAdapterSoapBindingImpl::contentSyncNotify

前 面的关系有点乱，到现在还没理清，按流程应该是ISMP先给BSG发一个contentSyncNotify（一个SOAP call），BSG收到这个notify后去解析它的内容，获得content description文件的存放地址和目录，但是现在还不知道是在哪里处理这个notify的，本以为是在 com.qualcomm.bss.bsg.cms.servicelaye.BSGWebServiceServlet处理这个notify的，但是看 了这个类的doGet方法，感觉这个方法没有处理notify。CMSWebServices和CMSEntity两个工程里面都没找到，这个暂且放下， 以后再找找。

目前看com.chinatelecom.ismp.contentpublish。ContentPublishedReqAdapterSoapBindingImpl::contentSyncNotify是处理notify的（但不知道它是如何被调用的，好像用了一个axis2的东西，google了一下，这是Apache的一个包，但是它是干什么用的没细看）。
方法contentSyncNotify使用了contentSyncNotifyReq， 这个类其实无甚特别，但是其中有一段代码搞得我很迷惑：static{... ...}，这段代码和org.apache.axis.description有关，不知道是干嘛的，留到后面再研究。然后 contentSyncNotify调用saveContentSyncInfo将得到的信息保存到数据库中，这个应该是content description文件的存放地址和目录。

com.qualcomm.bss.bsg.cms.parser是一个接口，类CDParserImpl实现了这个接口，里面有个方法：parseCDFile，这个方法就是用来解析content description文件的。
com.qualcomm.bss.bsg.cms.process.ContentAdaptor类中的方法：invokeProcess，调用了parseCDFile。
然 后com.qualcomm.bss.bsg.cms.job.ContentFetcherJob的方法execute中会调用 contentAdaptor.invokeProcess。这个ContentFetcherJob是从StatefulJob继承的类，也就是它是一 个Quterz的类，周期性地执行，
在com.qualcomm.bss.bsg.cms.servicelayer.BSGCMSServlet的init方法中会创建ContentFetcherJob，并对它进行调度。

所 以这几步的流程 是：com.qualcomm.bss.bsg.cms.servicelayer.BSGCMSServlet.init->com.qualcomm.bss.bsg.cms.job.ContentFetcherJob.execute->com.qualcomm.bss.bsg.cms.process.ContentAdaptor.invokeProcess
->com.qualcomm.bss.bsg.cms.CDParserImpl.parseCDFile。

在 ContentAdaptor类里有个方法fetchFile，这个方法其实就是从给定的地址中用FTP去取文件，invokeProcess调用 fetchFile去获取content description文件，content description文件的地址，在前面提到，content description文件的存放地址和目录已经保存在数据库中了。

content description文件解析完后，ContentAdaptor::invokeProcess会调用fetchZipFile去获取zip文件，这 些zip文件就是product_info.map，content_product.map和charge_info.map文件了。文件被取回 后，ContentAdaptor::invokeProcess还调用了：
batchStatusVO.setProcStatCodeID(Constants.BATCH_STATUS_SAVED);
updateBatchStatus(batchStatusVO);
这 两个调用貌似很重要，因为zip文件取回后就要进入下一步的处理，即将这三个map文件解析并将相应的内容填到数据库中，但是处理三个map文件也是一个 job，即ContentProcessJob，这个job也是在 com.qualcomm.bss.bsg.cms.servicelayer.BSGCMSServlet.init被创建初始化并调度的。也就是说， 它一直周期性地试图去处理三个map文件，但是并不是时时刻刻都有map文件需要处理（因为不是每时每刻都有产品要提交到BMC上去），所以当有新的 map文件被取回后，必须要有一种方法通知ContentProcessJob，现在有新的map文件需要处理了。这个方法应该就是 ContentAdaptor::invokeProcess在取回map文件后，向数据库里写了某些信息，就相当于置了某些标志位，然后 ContentProcessJob在处理过程中首先是查询数据库，获得信息得知是否有新的map文件需要处理。

com.qualcomm.bss.bsg.cms.job.ContentProcessorJob
com.qualcomm.bss.bsg.cms.process.invokeProcess
com.qualcomm.bss.bsg.cms.process.getSuitableBatch

ISMPItemVO
ContentItemVO