建模过程的盲点:软件集成中的软知识

下载本文示例代码
　　讲在前面的故事 　　伊利诺伊州，芝加哥：正如Cap Gemini Ernst & Young(CGEY)的解决方案设计师经理在芝加哥加速开发中心所声称的，Ashvin Vellody的工作围绕着使企业软件系统相互对话。“我们开发的大型项目，需要以不同的行业规范类型提供给客户，”Ashvin解释道。“CGEY使用了世界上遵循CMM 3和ISO 9000的开发工具来提供任何类型的软件项目—自定义编码的J2EE产品、PeopleSoft打包实施、集成项目或任何可能的情况。在我们的中心，我们提供方法、工具和人员以可预知的方式快速提供复杂系统。” 　　加速开发中心是CGEY交付方法学中的一个重要组件。它不仅提供专业环境中的基础架构、过程和人员，“界面外观的问题在B2B集成项目中并不总是很重要，但由于目标是简化做事的旧方法，因此涉及到的过程更加复杂。” 　　有助于满足合约中客户的严格最终期限，还为其设计人员提供工具和技术，通过更高的生产率支持加速交付。Ashvin说，“由于环境很灵活，所以人们来到中心工作；您可以在利用我们的工具和环境的同时配置自己的项目小组工作空间。诸如此类的微小改变会带来生产率显而易见的提升，并可提供卓越的工作空间。还有一个完整的工具小组坐镇后方，帮助多个项目成功地完成交付。” 　　中心大部分的时间和资源都投入到构建系统间的连接。这就意味着为自定义构建的连接器进行编码，或使用即取即用的集成解决方案，或通常两者兼有。但对于所有进行中的编码和软件工作来说，Ashvin的大部分时间都投入到了不涉及削减代码的任务；诸如计划、建模、设计，甚至协议之类的任务—软件集成后的“软知识”。 　　不同对象的不同集成需要 　　开始一个项目时，Ashvin多项任务中的首要任务之一是，当新的集成系统完成时评估它的首要业务目标，以及什么类型的对象使用它—系统将首先服务内部用户、其它业务，还是服务终端客户？ 　　“企业到企业(B2B)系统与企业到消费者(B2C)系统完全不同，”Ashvin 解释说。“B2C系统就是我们通常说的“深入接触”系统。它直接与终端客户交互，因此它必须是面向用户的；界面外观应该十分友好，这就意味着格外注意用户界面。B2C系统还提供对大量人员的服务。它的事务处理量不会很大，但会有大量人员利用这些服务。” 　　Ashvin将此系统与B2B系统进行了比较，后者通常意味着简化复杂的商务处理，如自动化库存和订购，通常基于纸张（至少一部分）的过程，以及或许涉及到的旧的原有系统。 　　“界面外观的问题在B2B集成项目中并不总是很重要，但由于目标是简化做事的旧方法，因此涉及到的过程更加复杂。”Ashvin说。“例如，我最近项目的客户是一家电信公司。该公司希望更好地处理客户的呼叫，使其呼叫中心的操作与后端计费系统之间的过程更加自动化。因此我们紧张忙碌了11个月，对CRM前端、后端计费系统进行了评估，并将一些体系结构部署到位。该项目用来简化商务过程，并且处理两个系统（原有计费系统和更现代化的CRM）间的复杂事务。” 　　原有系统、Spaghetti 代码、金苹果，以及大的飞跃 　　根据Ashvin的说法，CGEY已经看到了公司整个客户群集成项目的增长。这些集成中的大部分分为两大类—客户或者扩展原有系统，或者自动化过程，努力争取提高生产率。有时二者都需要。 　　由于目前预算紧缩的现实，各公司正试图一丝不漏地发掘原有系统的全部生产力。旧的应用程序并不总是在头脑中用现代的体系结构构建，并且将新旧应用程序相混合几乎是疯狂的。 　　Ashvin说，“我们所面临的集成原有系统的挑战是双重的。首先，我们必须从系统中抽取出spaghetti代码和逻辑，而系统在过去的30年中可能已被反复构建或修改过多次。了解系统的人不总是可以接受改变，他们也可能不愿意共享知识。另一个挑战是识别所谓的项目“金成果”—新的做事方法的前提或全部意义。” 　　Ashvin针对其最近的电信公司计费系统的项目指出，“计费十分复杂，一个过程可能涉及20个不同的领域。 　　一些部门可能每星期更新一次原有计费系统。其它部门可能每日更新，不论怎样，这些过程一段时间后都一起进入了spaghetti代码集，我们必须从该代码集抽取逻辑。确定谁拥有这些数据，以及数据如何以一种简单的、“黄金标准”的方式在各部门间共享—为解决此问题，我们奔波了两个半月。” 　　当公司试图大幅提高生产率而集成系统时，其它的集成难题出现了。Ashvin主持的一个有关汽车金融问题的现有项目就是一个很好的例子。 　　Ashvin解释说，“该项目旨在根据汽车购买经验以及取得信贷审批来自动化客户和经销商交互的方式。这是三个汽车制造商的经销商协作努力的结果。假设一位客户想要购买一辆通用汽车公司的卡车或一辆福特轿车，不论情况怎样。通过此项目，经销商可以迅速地对贷款应用程序、信贷审批及APR等级等事物做出反应。该项目还可以确保三大汽车制造商的任何一个后端系统能够以一致的格式接收信息，并一致地向任何经销商发回信息。” 　　这样的项目通过自动化过程减少了书面工作和低效率的过程，从而获得了生产力的巨大飞跃。要确保经销商和汽车制造商都使用类似的数据、类似的格式，并通过类似的过程使用数据—获得生产力的飞跃—需要清楚的了解B2B集成问题。 　　了解B2B系统 　　汽车行业是面临集成挑战这一大趋势的行业之一。要帮助厂家和公司构建交互式B2B系统，一些行业提出了他们自己的标准—如汽车行业的STAR标准。 　　Ashvin说，“STAR是特定于汽车零售行业的、符合SOAP的最出色的XML模式。例如，另一个纵向标准用于商业采购供应空间—那就是ebXML标准。” 　　这些纵向标准说明了系统如何定义数据，需要什么数据，什么数据是可选的，以及应该如何管理消息。其它行业正在采用诸如RosettaNet一类的通用标准。根据客户端状况，一个或多个这种标准的要求可以支配适用于设计人员的集成方法。 　　其它B2B集成方法包括通常所说的私有交易，其中行业中的某个大公司有足够的惯性要求其供应商仅采用一个基础架构。“私有交易由一个具有金融和行业影响力的主要参与者建立‘这就是我作为企业与你交流的方式’”Ashvin 解释说。图：集成体系结构 　　Ashvin将沃尔玛作为实践中一个私有交易的实例。“沃尔玛说，其所有的供应商都必须使用这种电子交易系统来与沃尔玛进行交易。然后供应商必须实施特定的一年或一段时间，并准备好通过沃尔玛的交易系统进行交易。这一切仅通过邀请来实现，并且进行集成相对比较容易”。但是Ashvin很快解释了沃尔玛工作的内部系统决定了集成过程，而不是单一的外部方法（如ebXML）。 　　解决B2B集成难题的另一方面是了解贸易合作伙伴管理(TPM)。TPM是B2B过程的集合，它明确地解决了供应商和厂商交易过程中的工作流和交互问题。TPM还提供一致的方法与商务处理通信。Ashvin说“TPM设计用于解决公司的销售和供应链问题。例如，作为公司怎样在供应链中管理所有不同的贸易合作伙伴？怎样维护他们？怎样与他们进行交易？与他们进行调解的过程怎样？TPM是B2B集成中的一个重要部分”。建模的重要性 　　不论您集成了行业标准、开放标准，还是受限于私有交易的体系结构，作为设计人员最终您必须开始定义数据、创建对象，并且开发出管理其余项目的模型。 　　“这是我最无法忍受的事情，” Ashvin说。“集成项目的一大难题是确定真实的记录和实体存在何处。例如，一家电话公司有十个不同的部门与名为“客户”的抽象对象交互。每个部门组织客户的方式不同，识别客户的方式也不同。对这些不同的部门采用一个通用的定义很难。” 　　Ashvin最近的电信公司计费系统项目证实了建模是十分复杂的工作。“在知道了客户的地址和位置的前提下我们才能为他们建模。这对所有的部门都适用，在计划过程中所有的商业用户也都适用，但是没有人了解直到我们开始实施它才能起作用。如果您仅通过一个人居住的位置来识别他/她，那么如果他们换了地方该怎么办？你打算获得多条记录，然后通过两个不同的位置识别那个人？这是关于人们的电力计费的系统，因此系统中的问题将影响到人们的日常生活。” 　　Ashvin的小组最终构建了一个变通方法，经过一夜的努力解决了地址/位置的难题。这种现实世界的实例说明了在实施开始前和整个实施过程中，完全在系统模型上工作非常重要。建模应该是优先考虑的问题，并且应该从尽可能多的角度对工作流和过程检查给予预期时间。Ashvin建议，对于一个历时1年的复杂项目来说，在编写代码前应该花费大约3个月的时间来为工作流和过程建模。 　　商务过程管理 　　新的商务过程管理(BPM)工具有助于公司组织模型以及商务过程在应用程序中工作。Ashvin解释道，“BPM是一层说明，它位于集成代码之上。BPM为商务用户提供调整模型和改变工作流的功能。BPM工具是十分图形化的，并且探查代码更改在底层透明地进行—或者至少应该透明地进行。BPM出现的时间尚短，但这些工具为商务用户提供了用图形化方式处理事务的能力，例如改变购买订单的工作流。一个商务用户—并且从事此行的人应该非常具有商业头脑—可以改变PO过程，因此能够通过在BPM工具中改变图形模型在不同的部门中共享PO。” 　　Ashvin指出，只需使用即取即用的解决方案（如webMethods或SeeBeyond）就可以很好地连接代码，但是应用程序会发展或改变，因此商务用户需要能够管理那些改变并相应地改变商务过程。这就是增加的BPM对集成设计师的增值所在。它允许工作流为商务用户“按订单生产”。 　　　改变准备就绪 　　设计人员应该意识到，集成涉及人员的程度与涉及J2EE和XML代码的程度是一样的，这一点也很重要。“您必须评估客户对待改变的态度，以及组织可以吸收多少他们的技术，”Ashvin解释道。“如果人们并不想放弃原有的后端，您必须做好准备提供创造性的解决方案。例如，在近期的一个包括CICS后端的项目中，我们对后端只进行了大约20%的修改，其余的我们在用户输入数据后通过创造性的屏幕导航和屏幕抓取进行管理。这延长了不良部分的寿命，但通过抽取该处的逻辑，我们使之继续保存在系统中，同时使其对原有系统的影响降低到最小。” 　　Ashvin也曾经遇到过有关第一线IT工人的领域问题。“人就是人，他们认为，‘这就是我所属的领域。我曾经做过客户数据库X，但现在另有他人在做。这对我意味着什么？’您不能忽视您丧失了集成项目的所有权。设计人员需要尽早参加商务讨论，并利用该机会减少担心。冲在前面，越早越好。” 　　设计人员的建议 　　Ashvin的建议直截了当：“切勿过度设计，特别对于那些第一次进行企业集成的组织。不要推出一组技术后只是引起争议，或者让一个主机工作室去吸收。在您首先推出基本元素（如XML）时，分小块进行。然后推出SOAP XML。接着可能进行Secure XML。然后进行Assemble Assertions，再接着可以进行SOAP服务器系统。不要试图通过同步Web服务开始SOAP XML。这可能太多、太快。 　　“至于用户，倘若采取适当的方式，告知他们可以为其提供哪些集成工具和过程，则有助于他们接受这种改变。不要以那种软件-销售人员-市场的口吻说话。不要告诉他们这将解决他们的所有问题。帮助他们了解，如果一个用户有两个社会保险代码，集成不会神奇地解决此问题。帮助维持合理的期望值，期望值不要太高。 　　“毕竟，企业集成是帮助确保客户运营和企业获得效率的一部分。这首先是集成的全部目标。” 　　注：Ashvin Vellody是位于芝加哥的Cap Gemini Ernst & Young公司加速开发中心的经理。他有超过九年的IT咨询经验，曾经参与过SDLC的所有过程-从技术项目管理、需求定义，到n层系统开发和测试。他是获得项目管理协会(PMI)认证的项目管理专业人员。他的核心能力是使用标准技术（如J2EE、XML和EAI）设计企业范围的EAI和B2B解决方案以解决商务难题。他曾经就职于美国、欧洲和亚洲的金融服务、能源及公共设施，以及客户服务和零售业领域。他目前的主要兴趣是面向服务的体系结构安全性。 　　讲在前面的故事 　　伊利诺伊州，芝加哥：正如Cap Gemini Ernst & Young(CGEY)的解决方案设计师经理在芝加哥加速开发中心所声称的，Ashvin Vellody的工作围绕着使企业软件系统相互对话。“我们开发的大型项目，需要以不同的行业规范类型提供给客户，”Ashvin解释道。“CGEY使用了世界上遵循CMM 3和ISO 9000的开发工具来提供任何类型的软件项目—自定义编码的J2EE产品、PeopleSoft打包实施、集成项目或任何可能的情况。在我们的中心，我们提供方法、工具和人员以可预知的方式快速提供复杂系统。” 　　加速开发中心是CGEY交付方法学中的一个重要组件。它不仅提供专业环境中的基础架构、过程和人员，“界面外观的问题在B2B集成项目中并不总是很重要，但由于目标是简化做事的旧方法，因此涉及到的过程更加复杂。” 　　有助于满足合约中客户的严格最终期限，还为其设计人员提供工具和技术，通过更高的生产率支持加速交付。Ashvin说，“由于环境很灵活，所以人们来到中心工作；您可以在利用我们的工具和环境的同时配置自己的项目小组工作空间。诸如此类的微小改变会带来生产率显而易见的提升，并可提供卓越的工作空间。还有一个完整的工具小组坐镇后方，帮助多个项目成功地完成交付。” 　　中心大部分的时间和资源都投入到构建系统间的连接。这就意味着为自定义构建的连接器进行编码，或使用即取即用的集成解决方案，或通常两者兼有。但对于所有进行中的编码和软件工作来说，Ashvin的大部分时间都投入到了不涉及削减代码的任务；诸如计划、建模、设计，甚至协议之类的任务—软件集成后的“软知识”。 　　不同对象的不同集成需要 　　开始一个项目时，Ashvin多项任务中的首要任务之一是，当新的集成系统完成时评估它的首要业务目标，以及什么类型的对象使用它—系统将首先服务内部用户、其它业务，还是服务终端客户？ 　　“企业到企业(B2B)系统与企业到消费者(B2C)系统完全不同，”Ashvin 解释说。“B2C系统就是我们通常说的“深入接触”系统。它直接与终端客户交互，因此它必须是面向用户的；界面外观应该十分友好，这就意味着格外注意用户界面。B2C系统还提供对大量人员的服务。它的事务处理量不会很大，但会有大量人员利用这些服务。” 　　Ashvin将此系统与B2B系统进行了比较，后者通常意味着简化复杂的商务处理，如自动化库存和订购，通常基于纸张（至少一部分）的过程，以及或许涉及到的旧的原有系统。 　　“界面外观的问题在B2B集成项目中并不总是很重要，但由于目标是简化做事的旧方法，因此涉及到的过程更加复杂。”Ashvin说。“例如，我最近项目的客户是一家电信公司。该公司希望更好地处理客户的呼叫，使其呼叫中心的操作与后端计费系统之间的过程更加自动化。因此我们紧张忙碌了11个月，对CRM前端、后端计费系统进行了评估，并将一些体系结构部署到位。该项目用来简化商务过程，并且处理两个系统（原有计费系统和更现代化的CRM）间的复杂事务。” 　　原有系统、Spaghetti 代码、金苹果，以及大的飞跃 　　根据Ashvin的说法，CGEY已经看到了公司整个客户群集成项目的增长。这些集成中的大部分分为两大类—客户或者扩展原有系统，或者自动化过程，努力争取提高生产率。有时二者都需要。 　　由于目前预算紧缩的现实，各公司正试图一丝不漏地发掘原有系统的全部生产力。旧的应用程序并不总是在头脑中用现代的体系结构构建，并且将新旧应用程序相混合几乎是疯狂的。 　　Ashvin说，“我们所面临的集成原有系统的挑战是双重的。首先，我们必须从系统中抽取出spaghetti代码和逻辑，而系统在过去的30年中可能已被反复构建或修改过多次。了解系统的人不总是可以接受改变，他们也可能不愿意共享知识。另一个挑战是识别所谓的项目“金成果”—新的做事方法的前提或全部意义。” 　　Ashvin针对其最近的电信公司计费系统的项目指出，“计费十分复杂，一个过程可能涉及20个不同的领域。 　　一些部门可能每星期更新一次原有计费系统。其它部门可能每日更新，不论怎样，这些过程一段时间后都一起进入了spaghetti代码集，我们必须从该代码集抽取逻辑。确定谁拥有这些数据，以及数据如何以一种简单的、“黄金标准”的方式在各部门间共享—为解决此问题，我们奔波了两个半月。” 　　当公司试图大幅提高生产率而集成系统时，其它的集成难题出现了。Ashvin主持的一个有关汽车金融问题的现有项目就是一个很好的例子。 　　Ashvin解释说，“该项目旨在根据汽车购买经验以及取得信贷审批来自动化客户和经销商交互的方式。这是三个汽车制造商的经销商协作努力的结果。假设一位客户想要购买一辆通用汽车公司的卡车或一辆福特轿车，不论情况怎样。通过此项目，经销商可以迅速地对贷款应用程序、信贷审批及APR等级等事物做出反应。该项目还可以确保三大汽车制造商的任何一个后端系统能够以一致的格式接收信息，并一致地向任何经销商发回信息。” 　　这样的项目通过自动化过程减少了书面工作和低效率的过程，从而获得了生产力的巨大飞跃。要确保经销商和汽车制造商都使用类似的数据、类似的格式，并通过类似的过程使用数据—获得生产力的飞跃—需要清楚的了解B2B集成问题。 　　了解B2B系统 　　汽车行业是面临集成挑战这一大趋势的行业之一。要帮助厂家和公司构建交互式B2B系统，一些行业提出了他们自己的标准—如汽车行业的STAR标准。 　　Ashvin说，“STAR是特定于汽车零售行业的、符合SOAP的最出色的XML模式。例如，另一个纵向标准用于商业采购供应空间—那就是ebXML标准。” 　　这些纵向标准说明了系统如何定义数据，需要什么数据，什么数据是可选的，以及应该如何管理消息。其它行业正在采用诸如RosettaNet一类的通用标准。根据客户端状况，一个或多个这种标准的要求可以支配适用于设计人员的集成方法。 　　其它B2B集成方法包括通常所说的私有交易，其中行业中的某个大公司有足够的惯性要求其供应商仅采用一个基础架构。“私有交易由一个具有金融和行业影响力的主要参与者建立‘这就是我作为企业与你交流的方式’”Ashvin 解释说。图：集成体系结构 　　Ashvin将沃尔玛作为实践中一个私有交易的实例。“沃尔玛说，其所有的供应商都必须使用这种电子交易系统来与沃尔玛进行交易。然后供应商必须实施特定的一年或一段时间，并准备好通过沃尔玛的交易系统进行交易。这一切仅通过邀请来实现，并且进行集成相对比较容易”。但是Ashvin很快解释了沃尔玛工作的内部系统决定了集成过程，而不是单一的外部方法（如ebXML）。 　　解决B2B集成难题的另一方面是了解贸易合作伙伴管理(TPM)。TPM是B2B过程的集合，它明确地解决了供应商和厂商交易过程中的工作流和交互问题。TPM还提供一致的方法与商务处理通信。Ashvin说“TPM设计用于解决公司的销售和供应链问题。例如，作为公司怎样在供应链中管理所有不同的贸易合作伙伴？怎样维护他们？怎样与他们进行交易？与他们进行调解的过程怎样？TPM是B2B集成中的一个重要部分”。建模的重要性 　　不论您集成了行业标准、开放标准，还是受限于私有交易的体系结构，作为设计人员最终您必须开始定义数据、创建对象，并且开发出管理其余项目的模型。 　　“这是我最无法忍受的事情，” Ashvin说。“集成项目的一大难题是确定真实的记录和实体存在何处。例如，一家电话公司有十个不同的部门与名为“客户”的抽象对象交互。每个部门组织客户的方式不同，识别客户的方式也不同。对这些不同的部门采用一个通用的定义很难。” 　　Ashvin最近的电信公司计费系统项目证实了建模是十分复杂的工作。“在知道了客户的地址和位置的前提下我们才能为他们建模。这对所有的部门都适用，在计划过程中所有的商业用户也都适用，但是没有人了解直到我们开始实施它才能起作用。如果您仅通过一个人居住的位置来识别他/她，那么如果他们换了地方该怎么办？你打算获得多条记录，然后通过两个不同的位置识别那个人？这是关于人们的电力计费的系统，因此系统中的问题将影响到人们的日常生活。” 　　Ashvin的小组最终构建了一个变通方法，经过一夜的努力解决了地址/位置的难题。这种现实世界的实例说明了在实施开始前和整个实施过程中，完全在系统模型上工作非常重要。建模应该是优先考虑的问题，并且应该从尽可能多的角度对工作流和过程检查给予预期时间。Ashvin建议，对于一个历时1年的复杂项目来说，在编写代码前应该花费大约3个月的时间来为工作流和过程建模。 　　商务过程管理 　　新的商务过程管理(BPM)工具有助于公司组织模型以及商务过程在应用程序中工作。Ashvin解释道，“BPM是一层说明，它位于集成代码之上。BPM为商务用户提供调整模型和改变工作流的功能。BPM工具是十分图形化的，并且探查代码更改在底层透明地进行—或者至少应该透明地进行。BPM出现的时间尚短，但这些工具为商务用户提供了用图形化方式处理事务的能力，例如改变购买订单的工作流。一个商务用户—并且从事此行的人应该非常具有商业头脑—可以改变PO过程，因此能够通过在BPM工具中改变图形模型在不同的部门中共享PO。” 　　Ashvin指出，只需使用即取即用的解决方案（如webMethods或SeeBeyond）就可以很好地连接代码，但是应用程序会发展或改变，因此商务用户需要能够管理那些改变并相应地改变商务过程。这就是增加的BPM对集成设计师的增值所在。它允许工作流为商务用户“按订单生产”。 　　　改变准备就绪 　　设计人员应该意识到，集成涉及人员的程度与涉及J2EE和XML代码的程度是一样的，这一点也很重要。“您必须评估客户对待改变的态度，以及组织可以吸收多少他们的技术，”Ashvin解释道。“如果人们并不想放弃原有的后端，您必须做好准备提供创造性的解决方案。例如，在近期的一个包括CICS后端的项目中，我们对后端只进行了大约20%的修改，其余的我们在用户输入数据后通过创造性的屏幕导航和屏幕抓取进行管理。这延长了不良部分的寿命，但通过抽取该处的逻辑，我们使之继续保存在系统中，同时使其对原有系统的影响降低到最小。” 　　Ashvin也曾经遇到过有关第一线IT工人的领域问题。“人就是人，他们认为，‘这就是我所属的领域。我曾经做过客户数据库X，但现在另有他人在做。这对我意味着什么？’您不能忽视您丧失了集成项目的所有权。设计人员需要尽早参加商务讨论，并利用该机会减少担心。冲在前面，越早越好。” 　　设计人员的建议 　　Ashvin的建议直截了当：“切勿过度设计，特别对于那些第一次进行企业集成的组织。不要推出一组技术后只是引起争议，或者让一个主机工作室去吸收。在您首先推出基本元素（如XML）时，分小块进行。然后推出SOAP XML。接着可能进行Secure XML。然后进行Assemble Assertions，再接着可以进行SOAP服务器系统。不要试图通过同步Web服务开始SOAP XML。这可能太多、太快。 　　“至于用户，倘若采取适当的方式，告知他们可以为其提供哪些集成工具和过程，则有助于他们接受这种改变。不要以那种软件-销售人员-市场的口吻说话。不要告诉他们这将解决他们的所有问题。帮助他们了解，如果一个用户有两个社会保险代码，集成不会神奇地解决此问题。帮助维持合理的期望值，期望值不要太高。 　　“毕竟，企业集成是帮助确保客户运营和企业获得效率的一部分。这首先是集成的全部目标。” 　　注：Ashvin Vellody是位于芝加哥的Cap Gemini Ernst & Young公司加速开发中心的经理。他有超过九年的IT咨询经验，曾经参与过SDLC的所有过程-从技术项目管理、需求定义，到n层系统开发和测试。他是获得项目管理协会(PMI)认证的项目管理专业人员。他的核心能力是使用标准技术（如J2EE、XML和EAI）设计企业范围的EAI和B2B解决方案以解决商务难题。他曾经就职于美国、欧洲和亚洲的金融服务、能源及公共设施，以及客户服务和零售业领域。他目前的主要兴趣是面向服务的体系结构安全性。 下载本文示例代码


建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识建模过程的盲点:软件集成中的软知识