让构建过程更平滑

开篇：润墨网以专业的文秘视角，为您筛选了一篇让构建过程更平滑范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

让构建过程更平滑一直是业务经理的梦想，新技术真是让过程晕平滑的良药嘛?

SOA的架构方法中强调可复用业务服务的核心概念，即SOA实施结果所产生的服务可被企业用户理解并使用，以达到构造新的业务流程或调整现有业务流程的目的。

业务服务这一定义，要求实现技术必须满服务接口与实现分离。服务的实现不应当依赖于具体的执行环境和实现语言等要求。满足这一要求的典型代表是WebService。

SOA方法倡导业务服务的可被企业用户复用，并重组业务流程的理念，决定了BPM技术的重要地位――可视化、简单。

构造业务服务的障碍

我们已经知道了SOA方法中所采用的技术――WebService，BPM的处理业务服务的优势。

在业务服务自身的构建活动中所采用技术方式，是否能够保持与SOA方法中所采用的技术方式完全一致?如果因为现实环境的约束导致我们无法完全使用与业务服务流程重组一致的技术方式来解决业务服务自身的构造问题，有没有什么方式可以作为替代选择?

为了回答以上的两个问题，我们需要分析一下SOA构建活动一些可能遇到障碍，并对如何解决这些障碍提出一些要求。

普遍的观点认为颗粒度越小越有利于复用，但同时对“效率”问题的“担心”就会越大，那么如何理解“效率可能达不到要求”这一问题?

SOA技术带来的效率损耗并不是实质原因。实质原因在于开发者担心使用SOA技术而带来的“效率损耗”可能是不可控制的，即在遇到效率瓶颈的点上有没有替代技术以达到效率要求，并且这种替代技术不会超出SOA技术的范畴。

因为一旦超出了SOA所提供的服务构建技术的范畴，开发者势必会回头选择传统企业应用开发以解决现实问题。而传统方式下的问题就在于一旦业务服务的边界划分不当，重新调整将可能是无法接受的开销。

为了给这一问题寻找答案，我们需要分析一下使用SOA技术的时候可能遇到的效率点有哪些，然后再尝试对可能的替代技术提出要求。

SOA的开发通常会使用SOA工具中提供的适配器或mediator工具将传统技术组件接人SOA域，然后再使用SOA的方式进行组合。(这个说法是只关注了应用集成，暂时忽略了其它类型集成)

我们将视角拉近，分析一下具体的效率损耗来源：适配器/mediator负责与传统组件交互并将消息转换为SOA域内的xml消息。SOA域内组件的交互是xml的，在进程内交互也是如此，业务流程基于BPM。

适配器/mediator――首先必须声明，在SOA中完全取消适配器或mediator是不可能的，这是由于传统技术，历史遗留组件的多样性所导致。

不过SOA项目的实施过程中，可能出于项目自身需要，开发新的企业应用组件以解决具体技术问题，对于这一类组件是有可能直接接人SOA域的。

为此需要扩充SOA技术，允许SOA组件对常用企业应用标准的直通接入，这种直通接入可能需要以下扩展：首先是扩充对企业应用标准所使用协议或接口的直接通信能力，并且不影响SOA服务的实现。其次是同一个SOA服务接口具有多种描述外观；wsdl描述外观，企业应用的native语言接口描述外观――譬如JAVA接口。以便企业应用开发可以直接基于服务接口的native语言描述外观进行开发。

进程内SOA服务的交互使用xml――有可能扩充SOA技术，追求进程内组件交互的效率最大化：直接基于native对象进行交互。为此需要扩充SOA技术，因此SOA域内服务的实现应当不限定BPM一种语言，至少应当提供一种常用的Native的语言实现方式，其次应该支持SOA服务接口的native语言描述外观。最后SOA运行系统可识别SOA服务的部署边界并自动进行数据转换的优化

业务流程基于BPM：在较低的业务逻辑层次，使用BPM编排底层服务构成逻辑层次相对高的业务服务，确实可能出现效率问题。需要：使用Native语言实现服务逻辑，而不是BPM，native方式实现得到的服务可以与BPM有机融合。

SOA实施域的服务分为两类，一类是SOA的核心，业务服务。另外一类是处理与具体的IT设施，技术交互的支撑服务：比如适配器或mediator，界面服务等。但是S。A域的支撑服务通常会受到SOA工具的限制。如果无法满足实际项目的需要，需要开发独立的企业应用组件。

因此我们希望，SOA技术可以提供一套具体的技术实施规范、以及必要的技术扩充，使得开发者可以在此规范的限定之下开发根据SOA业务需要开发企业应用，并且得到的企业应用可以与SOA域的服务直连。进一步的要求，我们希望此类企业应用可以与SOA服务统一的进行治理。

SOA工具通常会提供服务级的策略，企业应用运行环境也会有自己的策略定义。

因此存在SOA服务策略与企业应用策略的执行上下文内能否保持一致性的问题。前面我们提到，难免在SOA项目实施的时候，因为一些具体的技术要求而使用企业应用技术开发组件，

以事务策略为例，这些组件连接到SOA域后，SOA流程的事务可能没有办法被企业应用组件的执行上下文感知，而导致外部组件的运行不受SOA流程的事务控制之下。

这一问题没有妥善的解决办法，需要依赖具体的SOA工具。可能的选择包括：SOA产品可以支持某种特殊的应用服务器的策略延伸，并且我们不介意绑定在这种应用服务器上进行企业应用开发。尽可能少的在SOA工具边界创建企业应用组件。而是通过适配器与系统部件的数据交互。不得不使用企业应用技术开发组件的时候，将事务边界封闭在企业应用技术实施范围以内。如果需要，定义补偿接口。

SCA让构建过程更平滑

SCA(Service ComponentArchitecture)是一种规范，它使开发人员可以将注意力集中在业务逻辑的编写上。更直接地说，它是一种大大改进了的部署描述符。它可以使用任何语言而不限于Java。此外，您还可以使用编程式语言和声明式语言，比如BPEL和XSLT。SCA的特别之处在于，它对安全性、事务和可靠消息传递之类的特性使用了声明式策略的理念。

前面提到的障碍，大多在SCA技术中已经得到了妥善的解决。下面我们近距离观察一下SCA的具体做法以及如何运用。

服务的接口有JAVA，WSDL两类(WSDL1.1 PORTTYPE，WSDL2.0 INTERFACE)描述方式，只要两个接口的描述只要等价，服务就可以互相交互，不需要 双方都使用同种描述方式。

为了有效地利用SCA提供的特性，我们可能需要遵从一下原则：首先是选择一致的数据绑定：JAXB或者SDO。考虑到企业应用开发EJB技术的发展趋势，建议最好是采用JAXB。其次是建议自上而下的构建系统――先定义接口，然后实现。不只是业务分析的需要，同时也是为了有效管理SCA中同一个逻辑接口多种描述方式的复杂性。最后是合理的使用代码与项目管理方式，管理好逻辑接口，尽量做到同一个逻辑接口的不同描述方式只有一份。并在调用方与被调用方之间一致的使用。

SCA服务的实现不会受到具体语言的约束，可以是Java，也可以是BPEL，甚至是C++，PHP等语言，也可以扩充以支持XPDL的实现方式，而且使用非BPM语言构造的服务可以与BPM直接集成。由于实现多样，我们可以根据业务逻辑，执行效率的要求去平衡，采用最恰当的方式实现服务的内部逻辑。

需要注意的是虽然我们可以选择不同语言来实现服务，但语言的选择会影响到语言的执行环境，从而会间接影响效率，策略等方面的问题。需要开发者了解所使用的SCA工具中各种实现方式所依赖的执行环境与运行容器之间的关系。

通过SCA规范预定义的binding，以及扩充binding，可以做到SCA服务之间的交互不会受到具体协议的制约。

作为典型的企业应用技术EJB Session Bean，SCA提供了有效的直通式连接手段。并且有可能做到，可以在SCA的技术框架约束之下，根据上层SOA业务的对下层具体技术实施的需要，构建与SOA域的服务直通的企业应用组件。

为此我们需要：按照SOA的业务，自上而下定义接口。并为接口定义jaVa描述方式的服务接口，建议使用JAXB数据binding；将接口的java描述作为企业应用的具体技术接口；SCA域使用EJBbinding与企业应用直通。

不过需要注意我们讨论过的策略一致性的问题。另外虽然SCA的服务与实现无关，但是由于语言会影响服务的执行环境，所以需要注意正确选择与企业应用直连的SCA服务本身的实现语言。

SCA通过在组装模型中集中描述部署相关的特性，将这些特性与实现隔离开来。这一特性意味着我们可能集中的使用一种部署模型，来统一的部署和管理所有类型的组件。不管服务的实现语言是bpel、Java或者其它，不管服务的运行特性是WebService、EJB或者其它。我们都可以使用同一的方式部署和管理。

当然这一结论可能下的过早，未来如何还需要依赖SOA工具的实现情况。不过从目前的发展来看已经呈现这一趋势。比如通过修改部署描述而不需要调整实现，就可以将一个服务成为一个WebService，或者EJB。

未来部署管理一致的重要意义可能在于，一方面扩展了服务的治理的范围。因为当我们统一的管理SCA的服务时候，间接的也统一管理了WebServ ice，EJB等不同规范的组件/服务。

另外一方面有利于让SCA服务获得某些企业应用容器的特性，比如EJB。从而在SCA服务内获得企业应用运行环境策略的支持。具体如何，还需要等待。

SCA技术提供了多种选择以克服SOA项目实施的障碍。并且SCA技术框架下，开发者做出的不同技术选择不会影响服务的基本定义，可以与BPM、WebService有机的融合。

因此合理使用SCA技术，意味着我们在SOA项目的实施过程，不管是自上而下的分析业务、定义服务的过程，还是自下而上的构造服务的过程，都可以使用一致的方式进行，并且在同一个技术框架下有多种手段去平衡业务与执行环境的要求。最终使得我们的SOA项目的构建以一种平滑的方式进行，这种平滑的方式将为最终实施的成功提供可靠的技术保障。