jbi规范110.docx
- 文档编号:30206652
- 上传时间:2023-08-07
- 格式:DOCX
- 页数:100
- 大小:1.12MB
jbi规范110.docx
《jbi规范110.docx》由会员分享,可在线阅读,更多相关《jbi规范110.docx(100页珍藏版)》请在冰豆网上搜索。
jbi规范110
目录
1概述3
1.1定义4
1.2基本概念和假设4
1.3目标4
1.4与其他规范和技术的关系5
1.5角色5
1.5.1引擎开发者5
1.5.2绑定开发者5
1.5.3JBI环境提供商5
1.5.4J2EE平台提供商5
1.5.5JBI应用开发者6
2JBI环境的结构6
2.1基于WSDL的通信模型6
2.1.1抽象服务模型6
2.1.2具体服务模型6
2.2规格化消息7
2.3顶层架构7
2.4规格化消息交换8
2.5管理8
2.5.1组件安装9
2.5.2生命周期管理9
2.5.3服务单元部署9
2.6组件框架9
2.7规格化消息路由9
2.8组件10
2.8.1服务引擎10
2.8.2绑定组件10
3规格化消息路由10
3.1关键概念10
3.1.1服务消费者和提供者11
3.1.2规格化消息11
3.1.3分发通道(DC)11
3.1.4运行时端点激活11
3.1.5服务调用和消息交换模式(MEP)12
3.1.6消息交换(ME)12
3.1.7端点(endpoint)14
3.2ME的组成元素15
3.2.1交换摘要15
3.3规格化消息17
3.3.1规格化定义17
3.3.2规范化消息的结构17
3.3.3处理方法17
3.3.4二进制附件17
3.3.5WSDL1.1的支持17
3.4NMR设计18
3.4.1激活18
3.4.2消息交换19
3.4.3路由ME22
3.4.4动态端点引用的使用24
3.5NMRAPI25
3.5.1MessageAPI25
3.5.2ServiceAPI29
3.5.3查询已激活的端点36
3.5.4EndpointReferenceAPI36
3.5.5应用举例37
3.5.6服务提供者元数据37
4管理38
4.1概述38
4.2关键概念38
4.2.1组件安装38
4.2.2共享库安装39
4.2.3部署39
4.2.4部署的生命周期40
4.2.5组件的生命周期41
4.2.6类的装载41
4.2.7JMX的使用41
4.2.8ApacheAnt的使用42
4.3包装42
4.3.1安装和部署描述信息42
4.3.2安装包47
4.3.3服务部件(SA)包48
4.3.4服务单元(SU)包49
4.4安装服务49
4.4.1共享库安装49
4.4.2组件安装50
4.4.3组件卸载52
4.5组件生命周期52
4.6部署服务55
4.6.1SU部署处理56
4.6.2SA解除部署处理56
4.6.3连接元数据处理56
4.7SU生命周期57
4.8SA的生命周期58
4.9MBean的状态和结果字符串59
4.10ANT脚本支持61
4.10.1Including任务定义62
4.10.2异常处理62
4.10.3错误报告62
4.10.4ErrorSuppression62
4.10.5JBI环境远程访问:
URL模版62
4.10.6Ant任务62
5框架65
5.1组件提供的管理服务65
5.1.1Bootstrapper65
5.1.2组件接口66
5.1.3组件生命周期66
5.1.4SU管理68
5.2JBI提供的环境特性68
5.2.1组件上下文68
5.2.2安装(Bootstrap)70
5.2.3Loggers70
5.3类装载71
5.3.1类和资源的加载方式和加载顺序71
5.3.2共享库72
5.3.3ExecutionClassLoader72
5.3.4BootstrapClassLoader74
5.4错误提示74
6附录:
事务的使用75
6.1服务质量(QoS)75
6.1.1可靠性75
6.1.2事务75
6.1.3持久化76
1概述
服务的提供者和消费者从不共享同一个线程!
JBI可插入式的组件可以提供服务和消费服务,为了提供服务,组件需要提供一个(或一组)功能(function)。
这些功能在wsdl2.0中成为操作(operations)。
这些操作可以交换一个或多个消息(message)。
MEPs,基本信息交换模式,定义了一个操作执行过程中的消息的顺序。
组件提供的服务由组件向JBI说明,使用WSDL1.1或2.0提供一个抽象的,技术无关的描述,同时,还要相关的服务消费者和JBI提供有关服务的元数据描述,组件可以通过向JBI查询得到基于WSDL描述的可用服务。
组件分为两种类型:
1、服务引擎(SE),为其他组件提供业务逻辑或数据转换服务,他们之间也可互相调用,互为消费者和提供者。
SE可以集成基于JAVA的应用(或资源),也可以集成提供了JAVAapi的应用。
2、绑定组件(BC),为外部的组件(可以是服务提供或消费)提供到JBI环境的连接。
可以是通讯协议或EIS提供的服务。
BC可以集成通过远程访问技术(不能直接使用JAVA)进行访问的应用。
将业务逻辑从通讯中分离出来降低了实现的复杂程度提高了灵活性。
除了消息系统之外,JBI还定义了一个基于JMX的管理架构,提供了标准的机制,包括安装组件、管理组件的生命周期(启动、停止等等)和为组件提供服务信息的部属工具。
部署(deployment),是指向已安装组件添加组件功能描述说明的过程,用以区分组件的安装。
这样可以为组件增加新的服务功能。
JBI将部署工具和相关的元数据的集合成为服务部件(serviceassembly),有的地方也称之为组合服务描述(CSD)。
1.1定义
1.2基本概念和假设
1.3目标
本规范的目标包括:
1、建立一个标准的SPI,帮助开发人员实现SE和BC。
2、开发抽象的协议无关的消息交换(MessageExchange)和规格化消息(NormalizedMassage)。
3、为消息交换在JBI组件中的流转提供一套标准的机制。
4、为JBI组件的封装以及部署服务工具提供一个标准。
5、定义管理钩子(Hooks),例如一套工具用于解决今后在特定的问题域中暴露出来的问题。
6、提供SE和BC实现的灵活性和多样性,必须允许不同的提供商提供SE和BC或全部,这些组件之间可以可靠的交互,由这些组件组成的系统必须能够集中管理。
1.4与其他规范和技术的关系
JBI的实现依赖于J2se1.4或J2ee1.4
JBI使用WSDL2.0和1.1作为服务描述语言,WSDL2.0还作为插件交互的基础模型。
交互使用基于XML的消息,XML的处理遵循JAX-RPC2.0模型。
JBI依赖于JMX。
JBI在ESB中定义了服务容器的概念。
1.5角色
1.5.1引擎开发者
一个JBI兼容的SE需要实现规格化路由(NMR)协议,而且必须实现组件生命周期和管理接口,如果必要还要实现部署接口。
如果SE作为某种容器的话,开发者还要提供任何必要的工具用于方便部署SE描述工具。
1.5.2绑定开发者
一个JBI兼容的BC需要实现和SE一样的协议。
1.5.3JBI环境提供商
提供商必须提供本规范中定义的所有标准化的接口。
提供商可以选择使用J2ee1.4或更新的版本,但不是必须的,如果不支持J2ee1.4,那么必须支持J2se1.4或更新的版本。
JBI兼容环境必须至少支持一个兼容WS-IBasicProfile1.1(http:
//www.ws-i.org/Profiles/BasicProfile-1.1.html)的BC实现。
一个JBI兼容的环境可以分发一个SE的实现,但不是必须的。
1.5.4J2EE平台提供商
1.5.5JBI应用开发者
2JBI环境的结构
2.1基于WSDL的通信模型
WSDL在两个层面上提供了以说明性的基于消息的服务模型,他们是:
1、抽象服务模型:
一个被定义为使用抽象通信模型的服务,它与具体的协议无关,也不绑定具体的编码。
2、具体模型:
一个绑定具体协议或通信终端的抽象服务。
JBI使用抽象服务模型作为组件交互的基础。
WSDL使用名称引用不同的模型组件,有两种形式被使用:
1、限定名(Qualifiednames),由命名空间和简单名组成。
2、简单名,顾名思义,没有命名空间,只能用在小范围内或肯定不会发生冲突的情况下。
2.1.1抽象服务模型
1、抽象消息类型:
消息类型描述了有效消息的结构和约束,使用XMLSchema。
包括两种:
Normal和Fault。
2、抽象操作:
一次服务的交互操作,发生在提供者和消费者之间。
包括操作名、消息交换模式(顺序、方向和基数等等)和消息类型
3、抽象服务类型:
一组相关的抽象操作称为抽象服务类型,在WSDL2.0中定义为接口,WSDL1.0中定义为端口类型(portType)。
这与JAVA中接口不一样。
Ø接口名称:
限定名标识,在JBI中进行了引申,作为服务类型的标识符。
Ø扩展接口:
类似于JAVA中的接口,一个服务类型可以是另一个服务类型的扩展。
2.1.2具体服务模型
提供从抽象定义到具体通信协议和终端的映射所需的信息。
组件间的交互被定义为具体服务模型(为了和WSDL兼容),在JBI中,多数情况下可以将其等同于抽象模型。
具体模型定义了如下的内容:
1、绑定类型:
标识服务所绑定的协议的类型。
2、端点(endPoints):
为服务消费者和服务提供者之间通过特定的协议互动提供所需的通信端点信息。
在JBI中,端点是形式上的,在内部唯一被使用的协议是基于JAVA的JBI通信契约,不包含通常的通信协议。
JBI定义了两个内容:
Ø端点名称:
简单名,用于将端点指派到服务中。
Ø绑定类型:
端点关联的绑定类型。
3、服务:
一组端点的集合用于访问该端点。
一个服务“实现”了一个服务类型(接口),他定义了如下的内容:
Ø服务名称:
一个限定名,标识一个特定的服务实现。
Ø服务类型名称:
被服务实现的接口的名字。
Ø端点(Endpoints):
服务包含一个或多个端点,每个端点都单独提供访问具体服务的功能。
通常,可以用服务名称和端点名称的组合来标识端点,这种组合形式称为服务端点。
2.2规格化消息
规格化消息包括两部分:
一个是上面提到的抽象XML消息;另一个是消息元数据。
2.3顶层架构
SE用来放置WSDL定义的服务消费者和提供者。
这个图展示了JBI的主要结构组件,这些组件的集合成为JBI环境。
在每一个JBI环境中,都有一组服务集用于提供运行支持。
这些服务的关键是规格化路由(NMR),用来提供消息交换的基础,从而允许组件交互操作。
另外,JBI定义了一个框架,它为增加SE和协议BC提供了可插入的基础架构,在图中用黄色的C型多边形表示。
消息交换的核心概念实现了WSDL通信,服务请求被消费组件产生,由NMR路由,然后分发到提供组件。
所有提供服务都通过WSDL描述的服务进行发布(端点),SE和BC都可以用端点的形式描述,从而以一种统一的形式进行描述。
服务消费者可以通过WSDL服务名而不是端点地址来识别所需的服务。
当然,服务消费者也可以通过解析端点引用(reference)来识别服务,
2.4规格化消息交换
JBI环境的一个主要功能就是在不同的组件之间路由规格化消息交换。
绑定组件必须将绑定消息(特定的传输格式和协议)转换为规格化的形式,如下图
BC和SE是通过DeliveryChannel(DC)和NMR进行交互的。
服务请求者发送请求到BC,BC将请求转换为规格化的形式,接着,BC创建ME(一种包含了不同交换模式消息的容器),BC设置了ME的元数据,描述需要的服务和操作。
最后BC通过DC将ME发送到NMR,从而将请求发送到服务的提供者。
NMR会选择适当的提供者,路由ME,提供者必须从DC中主动接收(拉)ME。
反方向的也是相似的。
只不过ME是通过服务端点定位到外部的提供者。
2.5管理
JBI环境包括BC和ME,都需要通过JMX进行管理。
管理接口提供的主要功能有:
1、SE和BC的安装。
2、组件的生命周期管理(启动、停止)。
3、为BC和SE部署组件描述工具(artifacts),这样可以支持在内部的运行环境中动态添加内容。
4、监控。
2.5.1组件安装
BC和SE必须通过管理接口进行安装,这里使用“安装”这个词,指的是二进制的文件和相关的说明的安装,有别于部署。
2.5.2生命周期管理
一旦组件安装,就可以通过MBean接口控制启动或是停止。
2.5.3服务单元部署
如上说述,部署是指为安装的组件添加组件功能说明(用来订制组件的功能)。
这些说明(artifacts)称作服务单元,他们对于JBI来说完全不透明,而且本规范并未给出任何定义。
服务单元被组织到一个称作服务部件(ServiceAssembly)的文件中,它包括一个部署描述信息用以说明每一个SU要部署的目标组件。
2.6组件框架
组件框架为所有的JBI服务提供接口,这种组件接口有两种机制:
SPIs(服务提供者接口)和APIs。
SPIs是由BC和SE实现的接口;APIs是组件框架暴露给BC和SE的接口
2.7规格化消息路由
规格化消息交换(ME)主要依赖于NMR提供的路由,NMR支持多种品质的路由服务,包括:
1、最大努力:
消息可能被丢弃或分发多次。
2、至少一次:
消息不能被丢弃,但有可能被分发多次。
3、有且只有一次:
消息被保证只被分发一次。
2.8组件
JBI有两种组件形式,BC和SE,他们的模型和API是一样的,JBI只是通过一个标记区分他们。
只不过在规范中他们实现不同功能,管理接口也同样适用这样的区分方式。
2.8.1服务引擎
SE是JBI系统业务逻辑驱动器,它可以编排服务的消费和供应。
例如在一个长业务活动中组织其他的SE的服务等等,其他的SE可能只提供简单的服务(例如数据转换),或是更为复杂的路由和数据交换服务。
SE可以通过集成其他服务创建新的服务。
通过合成其他服务来组织更为复杂的服务,WS-BEPL这种语言正是这一合成模式的关键。
2.8.2绑定组件
BC是利用特定的协议和方式发送和接收消息的组件,他们通过将特定协议的消息规格化和反规格化,从而使JBI环境和特定的协议分离开,JBI环境只需处理规格化的消息。
需要注意的是,特定协议的元数据可以绑定在规格化消息里或ME中,这些元数据可以以一种形式在某一BC和SE之间传输特定协议的信息,而这一形式对于JBI环境中的其他组件是不透明的。
3规格化消息路由
3.1关键概念
这些WSDL的概念都在前面的JBI架构有所描述,他们用于为JBI的SPIs和APIs建模。
值得一提的是,JBI扩展了WSDL抽象消息模型的应用,可以认为NMR就是抽象的WSDL消息系统的基础,BC和SE在这个平台上消费和提供WSDL定义的服务。
WSDL在消费者和提供者之间定义了消息交换的服务,这个操作参照参与者都能理解的交换模式来完成。
一些列的操作被定义为接口,服务实现这些接口。
一个服务有一至多个端点,用来通过不同协议访问服务。
3.1.1服务消费者和提供者
服务的提供者通过端点提供一个WSDL描述的服务,消费者通过调用特定的操作启动ME来消费服务。
一个服务“实现”了一个WSDL的接口,该接口就是一组交换抽象消息的一系列相关操作集合。
消费者和提供者是解耦的,通常只共享(抽象)服务定义而不是端点信息,这样将消费者和服务提供者的实现分离开(如协议等)。
一个WSDL接口可以被多个服务实现,一个消费者会查找到多个接口的提供者(服务和相关联的端点)。
3.1.2规格化消息
JBI在消费者和提供者之间的交互中使用“规格化”消息的概念,它主要包括:
1、有效信息或裸消息:
一个符合抽象WSDL消息类型,没有和特定协议格式或编码绑定的XML文档。
这不是一个消息的规范格式。
2、消息属性(有时称为元数据):
它包含了从消息处理中得到的与消息相关的额外的信息。
这些属性可以包含安全信息(例如消息的数字签名中的安全主体)、事务上下文以及组件特定信息。
3、消息附件:
是消息的有效信息的一部分,由附件组成,被有效消息引用,并且包含处理附件内容数据处理器。
附件可以不是XML格式的数据。
3.1.3分发通道(DC)
DC表示用于BC和SE同NMR通信的双向通信管道。
DC形成了消费者、提供者和NMR之间的API契约。
一个消费者通过一个DC启动服务调用,提供者通过另一个DC接收这个调用;既是消费者又是提供者的组件通过同一个DC来通信(和NMR)。
每一个组件都只有唯一的DC,因此DC的实现必须支持多线程情况下的并发应用。
3.1.4运行时端点激活
运行时激活是一个服务提供者激活实际服务的过程,使这些服务被NMR知道以便让NMR能够让服务调用路由到该服务。
激活动作分为两步:
1、向NMR声明一个服务端点;
2、提供端点定义的元数据描述信息。
声明是BC和SE向NMR激活端点名称的过程,这些端点名称必须支持元数据描述详细的注册信息,这些详细信息由组件的SPI单独的提供。
3.1.5服务调用和消息交换模式(MEP)
服务调用指的是服务消费者和提供者之间端对端交互的一个实例。
尽管不可能在JBI中定义出全部的服务调用模式,但是JBI的实现必须支持下列的交互方式:
1、单向(one-way):
消费者向提供者提出请求,但提供者不返回错误。
2、可靠单向(Reliableone-way):
消费者向提供者提出请求,提供者在出现错误时返回错误信息。
3、请求和响应(RequestResponse):
消费者向提供者提出请求,提供者回复响应,提供者在出现错误时返回错误信息。
4、请求和可选的响应(RequestOptional-Response):
消费者向提供者提出请求,提供者可能会返回响应信息。
提供者和消费者都可以选择是否在接收消息出错时发送错误信息。
WSDL2.0扩展定义了MEPs,JBI沿用这一定义。
消费者和提供者分别代表两个节点,MEP在消息类型(Normal和Fault)以及方向上进行了定义。
MEPs总是反映提供者的视点。
例如在请求-响应互动中,MEPs代表进-出流。
3.1.6消息交换(ME)
一个ME是服务调用的一部分,可以看作是规格化消息的容器。
它不仅封装了其实现的MEP中IN和OUT代表的规格化消息,而且还包含了这在进行的交换所涉及元数据和状态信息。
ME代表了JBI本地的服务调用的一部分,下表描述了服务调用和MEP之间的关系。
ServiceInvocation
MessageExchangePattern(ProviderView)
One-Way
In-Only
ReliableOne-Way
RobustIn-Only
Request-Response
In-Out
RequestOptional-Response
InOptional-Out
下面的活动图描述了两个本地SE之间单向服务调用的过程,还包括了一个ME实例。
需要注意的是该图并不意味着调用者必须阻塞当前线程的执行,并等到交换完成才继续执行。
调用者在发送和接收消息交换时采用事件驱动(Event-driven),如上图所示,SE内部状态的推进不必和线程资源绑定。
下面的图描述了在两个JBI环境中进行可靠单向传输的例子。
注意,在创建ME实例的过程中,NMR分配了一个唯一标识符“X”。
下面的图描述了JBI环境下的SE和环境外的服务提供者之间进行请求-响应服务调用的例子。
需要注意的是,外部服务提供者在处理完毕后会将结果(响应,Normal或Fault)传递给BC,BC将其规格化并加入到In-outME中。
3.1.7端点(endpoint)
端点,在WSDL2.0中指通过特定的协议访问到的特定的地址,从而访问特定的服务。
JBI沿用这一概念,包括两种类型:
1、外部:
JBI环境之外的端点。
Ø外部服务提供者暴露的端点
Ø由BC暴露的外部端点,用于外部服务消费者
2、内部:
由JBI环境内的服务提供者暴露的,他们可以通过NMR的APIs访问到。
BC用来在内部端点和外部端点之间建立映射。
在JBI中端点可以通过三种方式引用(或定位):
1、隐式调用:
JBI基于服务类型选择服务提供者的端点。
2、显示调用:
消费者基于自身的逻辑或配置选择服务提供者的端点。
3、动态调用:
在ME中使用端点引用(EPR)用来提供一个“回调”地址,服务提供者可以使用这个地址发送与当前应用级的对话相关的进一步的ME。
EPR在JBI中有两种用法:
ØEPR构建:
希望在ME中提供回调地址的组件必须构建适当的EPR。
ØEPR解析:
为了发送ME到适当的端点(通常是外部服务提供者),收到EPR的组件必须解析(例如将其转换为可用的端点)。
3.2ME的组成元素
1、模式:
每一个ME都由一个模式加以说明,说明方向、顺序、基数和传送消息的名称(Normal和Fault)
2、启动者:
创建ME的组件,服务消费者在所有JBI定义的MEPs中作为启动者。
3、服务程序:
为ME提供服务的组件,服务提供者就是服务程序。
4、角色:
组件在“拥有”一个ME的实例时所扮演的角色。
Ø提供者:
提供ME请求的服务的组件。
Ø消费者:
向一个提供者请求服务的组件。
5、寻址定位:
一个服务引用、端点引用和一个NMR用来路由ME的逻辑地址的操作名称。
6、消息:
ME携带的一个或多个消息。
7、故障(fault):
一个ME最多携带一个故障信息,是一种特殊的消息。
8、状态:
描述ME的状态:
错误(error)、完成(done)和活动(active)。
9、错误(error):
一个JAVAException对象用来描述错误状态的来源和原始状态。
10、属性(properties):
ME的发起者和服务程序可以和ME有任意多个联系的属性,NMR可以保留某些属性名称用来声明QoS、安全、事务或其他的操作元数据。
ME实例的生命周期短,在系统关闭和失败后就不存在了,组件提供的高级别的错误恢复逻辑必须能够处理这些错误情况。
允许JBI提供可恢复的持久的ME实例将在JBI2.0中考虑。
3.2.1交换摘要
PatternName
MessageSequence
FaultRule
WSDL1.1Operation
In-Only
in
none
One-way
RobustIn-Only
in
onin
-
In-Out
in,out
replacesout
Request-response
InOptional-Out
in,out
oninorout
-
3.3规格化消息
规格化消息是JBIME的消息。
3.3.1规格化定义
1、规格化
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- jbi 规范 110